论文：Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity
⭐⭐⭐⭐
Code：github.com/starsuzi/Adaptive-RAG
NAACL 2024，arXiv:2403.14403

一、论文速读

这篇论文提出了 Adaptive-RAG 方案，特点是在 QA 场景中，能够自适应地根据 user query 的难度选择合适的 RAG 模型来解决，比如对于直接性的 query，就可以直接让 LLM 回答，对于简单的 query，只需要一轮 retrieval 就可以让 LLM 完成回答，而对于复杂的需要 multi-hop 的 query，则需要多轮 retrieval 才能让 LLM 完成回答。

本论文指出了以下两个观察到的现象：

• 用户大多数的问题都是简单的问题，少数情况下才是需要多条推理的复杂问题
• 简单的问题使用复杂的 RAG 模型存在开销的浪费，而复杂的问题又无法用简单的 RAG 模型来解决

为此，本论文才提出了如下的方案（最右边的 C 就是本论文提出的 Adaptive-RAG 的思路）：

如上图，在 C 所示的思路中，存在一个 classifier 来对 user query 做困难度分类，然后再交由三种用于处理不同复杂的 RAG 模型的其中一个来完成解决。

二、实现细节

2.1 三种难度的 user query

本工作将 user query 的难度分为了三种，并给出了三种对应的解决策略：

1. Non Retrieval for QA：对于 Straightforward Query，不需要经过检索，直接由 LLM 回答即可。
2. Single-step Approach for QA：对于 Simple Query，只需要经过一轮检索即可获取支持 LLM 回复的 doc
3. Multi-step Approach for QA：对于 Complex Query，需要多步、复杂的检索才能得到答案

2.2 user query 的难度分类

我们已经定义了 user query 的难度有三类，对于一个具体的 user query，如何将其分类呢？

这里就是训练了一个小语言模型作为 classifier，输入是 user query，输出是 query 的难度。原论文使用了 T5-large 并再训练得到的 classifier。

但是，目前并没有可用的 query-complexity pairs 数据集，因此，论文介绍了该工作是如何收集到用于训练 classifier 数据集的。query-complexity paris 是借助于已有的 QA 数据集来构建，为已有的 QA 数据集的 pair 标注 complexity label 来构建本实验所需的数据集。该数据集的收集主要包括两个过程：

1. Generate silver data from predicted outcomes of models：意思是说，假如难度分成 [A, B, C] 三个等级，A 最简单，C 最困难，那么给定一个 query，首先先让 LLM 直接回答，如果 LLM 回答正确，则将 query 标记为 A；如果 LLM 经过一轮检索后生成正确答案，则将 query 标记为 B；如果 LLM 经过多轮检索后生成正确答案，则将 query 标记为 C。
2. Utilize inductive bias in datasets：经过第一个过程，有些 query 仍然无法被标记，因为可能三种 RAG 模型都没有生成正确答案，这个时候只能利用这个过程来完成标注。这时候利用一个特点：这些 benchmark datasets 的数据都有一定的偏向性，比如一个 dataset 可能都比较偏 single-hop，而另一个 dataset 可能就都比较偏 multi-hop，对于偏 single-hop 的则直接标为 B，否则直接标为 C。

经过以上两个过程，我们的数据集就构建出来了。

三、实验结果及分析

这里作者做了不少的工作，甚至还包括了 classifier 的模型效果。

3.1 Adaptive-RAG 的模型效果

作者选用的数据集都有点旧了，single-hop 用的是 SQuAD、Natural Questions、TriviaQA，multi-hop 用的是 MuSiQue、HotpotQA、WikiMultiHopQA。

baseline 主要选择的是 No Retrieval、Self-RAG 和 Multi-step Approach：

• 相比于 Self-RAG，准确率等效果提升很明显，但由于需要做更多的检索和预测，耗时上有了稍微明显的提升
• 相比于 Multi-step Approach，耗时明显降低了，至于效果也降低了一些

总体上来看，Adaptive RAG 算是有效的提升了，它以少量时间为代价，提升了最终的问答效果。

这里有个小问题，论文给出的数据中，Self-RAG 的效果也有点太差了。。

3.2 classifier 的效果

如下是论文给出的不同 size 的 classifier 的效果对比：

额，，其实这算是文本分类的 classifier 模型，但效果确实不太行，整体 ACC 只有 54.52%。

另外可以看出，classifier 的模型大小对效果影响并不大（都表现一般），这就可以根据实际部署情况来决定了。

总结

论文指出的观察到的现象确实是存在的，即用户大多数的问题都是简单问题，少数情况下才是复杂的问题，本工作提出的根据 user query 的复杂程度来选择 RAG 模型能够有效的在 effectiveness 和 efficiency 之间取得一个平衡。

另外，觉得公众号 Adaptive-RAG:根据难度自适应检索方案 | 叉烧 给出的总结与反思很不错，这里做一个引用摘抄：

---

论文读完了，聊一下本文读完的感想，后续会有文章展开聊。

• 多次查询确实是有问题的，有些查询可能并不需要那么多，可能是多余的甚至是反效果的，本文的自适应确实是有一定收益。
• 新增一种划分策略的思路，可以通过难度来划分应对策略，这个不仅在处理性能上有收益，在最终效果上也有收益。
• 分类这块，可以看到这个分类的效果确实比较差，个人感觉原因主要是在分类问题的定义上，难度和大模型、和知识库支持、和问题领域之类的差异会比较大，本身分类效果不好应该是意料之中，不过好奇是这个分类器的优化会给RAG整体效果带来多大收益仍未可知。
• self-rag被放进来进行对比，结果发现非常拉胯，有些让人出乎意外。感觉这里有打开方式、适应场景等的问题，有展开分析的价值。

最近读的几篇论文，大都是围绕着选择适配大模型的知识的策略，内部进行组件的划分，从而提升最终的预测效果，配合目前工业界对业务落地RAG的观察，我自己能看到后续RAG在工业界形成的一种范式，原来是有模糊提到的，但是现在的信心，应该是越来越足了。

• 检索和大模型之间是先后的关系，先检索后大模型推理，当然这个应该是显而易见的，但从整体架构而言，这点绕不开。
• 检索横向铺开，根据不同的业务需求和资源定制不同的检索策略，因为横向，所以允许多标签，形成多路召回。
• 检索结果出来后，进行多内容的合并、筛选和判别，选择最合适的结果送入大模型，呼应第一条里提及检索模块和大模型模块之间的先后关系。