前沿重器
栏目主要给大家分享各种大厂、顶会的论文和分享,从中抽取关键精华的部分和大家分享,和大家一起把握前沿技术。具体介绍:仓颉专项:飞机大炮我都会,利器心法我还有。(算起来,专项启动已经是20年的事了!)
2023年文章合集发布了!在这里:又添十万字-CS的陋室2023年文章合集来袭
往期回顾
最近RAG的文章,我做了一个串讲,有兴趣可以传送过去了解下:心法利器[111] | 近期RAG技术总结和串讲(4w字RAG文章纪念)
RAG的论文可谓是百花齐放,今天讲一篇有关自适应的RAG,这篇论文认为是不同难度的问题,RAG系统应该有不同的应对策略,因此搭建了这个自适应的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在工业界形成的一种范式,原来是有模糊提到的,但是现在的信心,应该是越来越足了。
检索和大模型之间是先后的关系,先检索后大模型推理,当然这个应该是显而易见的,但从整体架构而言,这点绕不开。
检索横向铺开,根据不同的业务需求和资源定制不同的检索策略,因为横向,所以允许多标签,形成多路召回。
检索结果出来后,进行多内容的合并、筛选和判别,选择最合适的结果送入大模型,呼应第一条里提及检索模块和大模型模块之间的先后关系。
有关这个结构的合理性和实践细节,因为不是这篇论文的重点,我会在后续的文章里面展开,敬请期待。