Adaptive-RAG:根据难度自适应检索方案

• 论文：Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity。
• 链接：https://arxiv.org/abs/2403.14403
• github（目前没有代码，说是尽快会有）：https://github.com/starsuzi/Adaptive-RAG
• 参考链接：https://zhuanlan.zhihu.com/p/691008957

目录：

• 核心方案
• 实验
• 补充讨论

核心方案

整体思路

整篇论文的核心思路可以用一张图来展示。针对不同难度的问题，解决起来肯定不容易，简单常识问题应该并不需要检索直接询问大模型即可得到正确答案，而对复杂的问题，则需要依赖RAG进行检索筛选来获得，对更复杂的问题，例如需要多重推理的、依赖多种知识的，则需要查多次，才能够得到正确答案，因此，一视同仁地进行检索然后返回，应该不是一个非常正确的选择。

因此，作者把问题分成了3档：

• 简单（Non Retrieval for QA）：并不需要检索，可以直接返回。
• 中等（Single-step Approach for QA）：只需要简单检索即可获取支持回复的文档信息。
• 困难（Multi-step Approach for QA）：需要多步、复杂的检索才能得到答案。

从文章对这3档划分，背后比较重要的理由就是——资源（检索与反复检索所带来的时间消耗）利用和最终结果的正确的权衡。

由于整个架构上，相比一般的RAG，这里其实就是增加了一个策略划分的插件，把问题进行了拆分，因此我们关注点只有两个，一个是问题怎么拆的，另一个是拆了之后的操作有什么不同。

对于后者，上面的定义已经给出来了，就是根据问题难度进行不同次数的检索，那么剩下的问题，就是问题的拆分工作了。

难度划分问题

现在，我们将问题的视角转到难度划分上，需要回答这2个问题：

• query的简单、中等、复杂，在问题定义层面，是如何区分的。
• 在模型层面，我们是用什么方法来进行划分，模型训练的训练集和测试集从何而来。

问题层面的定义跟测试集测试集的定义，放在一起，具体的标注逻辑论文里通过举例的方式有给出对应的策略：

• 使用非检索方案就得到正确结果的query标为简单。
• 单步检索和多步检索均能得到结果的，出于节省成本，优先考虑单步检索，所以标为中等。
• 只有多步检索才能回答对的，那就标困难。
• 默认情况下，在单步检索的数据集下的数据默认都是中等，多步检索数据集下没预测对的会默认是困难。

这个方法内应该有暗含一些人工标注在里面，不过能整理出来应该也是可以的。

至于分类模型，文中提到了用小语言模型，在实验这块，提到了用的是T5-Large模型，包括学习率、停止条件、学习器

有关实验

实验这块，作者还是做了不少工作的，包括我所期待的有关分类模型效果（之前的两篇论文都没做的很好，这次可以说是狂喜了），我把我关注到的一些重点展开聊吧。

首先是实验的数据，应该是我这几篇看来比较不一样，这里用的几个数据都比较旧， SQuAD v1.1、Natural Questions、TriviaQA、等，基本是20年前的数据了，只有MuSiQue会稍微新一点，和CRAG中用的PopQA、Biography、PubHealth都是23年左右的相比，确实有些旧，当然了，可能是出于对问题难易考量，作者可能并不认为这些数据集合适吧，具体原因没太看出来。

至于效果，那当然是不出意外的好了，作者把self-rag当做关键的baseline作为对比，效果提升还是比较明显的，当然，因为相比self-rag，要做更多的检索和预测，耗时还是有明显提升的，但相比一些多次检索的模型，类似“Multi-step Approach”，耗时确实是明显降低了，至于效果相比论文的模型，还是下降的，所以总体看下来，Adaptive RAG算是有效提升了，以少量时间提升为代价，提升了最终的问答效果。

这里想小小的质疑一下self-RAG的效果，从这里看self-RAG的效果差的也太大了，是这里垫底的存在，不知道是什么方面的原因，感觉值得探索。

至于分类的效果，作者还是大胆给出来了，说实话，确实不那么好看，放一般的文本分类任务里，基本就是不可用的水平，直接看数据，整体的ACC只有50多。比较震惊的还是这个效果下对最终RAG系统仍旧有收益，说明这个系统对有没有，应该是敏感的，但是对分类效果不那么敏感。

作者在这方面还比较严谨，对不同大小的模型进行综合评估。从表格里可以可以看到，其实模型的大小对效果影响不是很大，总之就是很差。

补充讨论

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

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

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

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

有关这个结构的合理性和实践细节，因为不是这篇论文的重点，我会在后续的文章里面展开，敬请期待。