赞
踩
RAG的文章写的也不少了([心法利器[111] | 近期RAG技术总结和串讲(4w字RAG文章纪念)](),除了原有知识的串讲,我还想聊的是在已经阅读的文章里带来的一些新的想法和思考,形成自己的方法论,我自己是挺喜欢这种思考和分析的,一方面锻炼自己独立思考的能力,另一方面也让自己在应用过程中更加顺手熟练。
本文是我的思考、推导和论证路线,结论其实比较简单,就是RAG整体结构可以从“向量检索-大模型”升级到“搜索系统-大模型”的结构,同时,大模型的作用也有必要聊清楚,因此,文章里我会讲明白这几个事:
前面少有地对很多文章进行了讲解,并给出了自己的想法,主要有这些:
从这些文章,尽管这些文章的思路各异,也给出了很多丰富的讨论,但我们还是能从中找到一些共性,这是我从几篇论文和分享里发现的几个迹象。
首先,仅仅只有检索和大模型,并将其简单的拼接,是很难达到更高的上限的。这点应该是一个共识。从综述文章以及其他对RAG架构讨论的文章里,都提到了advanced RAG以及模块化RAG的存在,我们需要更多的组件来支撑这个项目,以获得进一步的提升,而组件的设计,就成了目前RAG论文主要的创新点。这个侧面也在说明,非端到端化、系统功能任务的拆解是效果提升的一大重要手段(这个问题似乎有写一篇文章的价值?),在工业界落地具有很大价值,逐步发展而走向成熟的工业对话系统、推荐系统、搜索系统无一都是这个思想下的产物,这也是和学术界端到端方案分道扬镳的分水岭。(叠个甲,并非说端到端就不好)
而现行的一些开源项目,也有对这些思路的应用,这点也印证了我的分析的正确性。来看看最近网易有道开源的QAnything(QAnything),也是按照这个思路设计的,就对应上面两条的发现。
QAnything结构图
首先,对检索结果的判别,在文档里被称为Rerank,作者也对该设计进行了解释,我直接摘原文:
In scenarios with a large volume of knowledge base data, the advantages of a two-stage approach are very clear. If only a first-stage embedding retrieval is used, there will be a problem of retrieval degradation as the data volume increases, as indicated by the green line in the following graph. However, after the second-stage reranking, there can be a stable increase in accuracy, the more data, the better the performance.
简单的说,在知识库数据量大的情况下,两阶段优势明显,因为数据量增加后向量检索的效果会出现明显下降。
另外,虽然各个分享里面并未提及分情况讨论这个事,但是在图中有专门提到了Query Understanding,说明这里还是有必要做query理解的,这个应该就是为后面的检索和排序服务了。
追溯历史,百度搜索最早是2000年开始的,谷歌搜索还要更早,随着人们的逐步探索,在架构层面,升级已经逐步收敛,目前的共识就是的基础结构,具体的可以参考之前我聊腾讯搜索时候给的分析解释([前沿重器[4] | 腾讯搜索的Quer理解如何直击心灵](),这里我把更加详细的架构图给出来。
我重新展开聊一下“query理解-召回-排序”中各个部分的作用。
首先是query理解,我分感性和理性方向进行解释。感性解释,旨在或结构化、或非结构化地对query内的信息进行抽取,了解用户的实际需求,针对用户的需求进行检索,提升检索的准确性和可解释性。注意,搜索对准确性的要求极高,因为用户的需求明确,知道自己要什么,因此只要有一点偏差都会带来很差的体验;理性解释,则主要用在召回、排序模块,为召回和排序提供依据,例如意图可以作为检索策略选择的依据,该去搜音乐库、调用天气接口还是人物百科,实体抽取可以协助进行检索,例如要搜周杰的就不会出周杰伦,甚至在排序阶段能够作为特征提供排序参考。
然后是召回,在现实的召回场景,通常是多路的,也是需要进行信息参照的,这个和前面的“分情况讨论”不谋而合,而分多路的依据也是不一样的,大家的思路不要被局限住了。我举几个例子:
至于排序,在非常完善的推荐系统和搜索系统里,是可能有多轮的排序的,不同的排序会对应不同的结果,根据业务也可能不同。不过一般的,就是分成粗排和精排。
想起一篇我之前聊到准招分治的文章([心法利器[15] | 准招分治效果调优方案](),这篇文章从准确与召的角度很好地诠释了为什么要分开召回和排序,也跟QAnything提到的两阶段效果好的结论是一致的,是一种很好地解释。
搜索系统经过多年的探索总结,才形成上述的范式,结合现在RAG发展过程中所体现的一些迹象,我有理由相信RAG中的R很可能也会朝着这个方向去做。参考上面搜索系统的结构,核心逻辑还是理解-召回-排序。
这个范式,是相比之前聊过的self-RAG、CRAG、adaptiveRAG而言的,他们有各自的拆解思路,而这个是我的拆解思路。这个拆解思路下,还需要展开讨论几个点,分别是迭代思路、优势以及分析为什么现在还没广泛应用。
万丈高楼平地起,完整的系统不是一蹴而就的,而是随着项目的发展,不断暴露各种问题难题,在解决问题和发现问题的交替下螺旋上升的,所以这里还是要专门讲一下这个完整系统的迭代思路。
在项目早期,从无到有,更多是把项目的基础工作搭建起来,基础的RAG要跑起来,这个就是我之前写的这个项目([心法利器[105] 基础RAG-大模型和中控模块代码(含代码)](),这是极简的RAG结构,搜索的部分只有一个向量召回,没有理解和排序,大模型部分就是prompt拼接,直接预测就好了。
第二阶段应该是召回链路的拓展以及理解部分的搭建。有过经验的朋友应该知道,一个向量召回想必是不好调优的,尤其是准确率并不好保证,尤其是对easy case的处理,而准确率最好保证的,自然就是规则,而海量通用的规则,就演化成了字面检索,而配合的query理解也就产生了。最开始是要搜包含“周杰伦”所有的音乐,是一条规则,但后续发现,歌手是一个常用实体,音乐是一个库,结合目前音乐是比较独立的检索库,有自己独特的字段,于是新增一路,然后做实体抽取,此时就多了个音乐意图,可以带有歌手实体,需要理解模块的配合才能得到,理解模块就需要建立了。
第三阶段则是精排模型的引入。随着意图、召回链路的增加,每个意图下的处理出现很大的不同,又或者是符合条件的内容过多相似度太高,或者是内容排序效果提升不上去,此时就需要精排模型介入了。到这个位置已经是整个系统搭建已经比较完善的阶段了。
至此,整个检索模块就搭建了起来,成为独立完整的搜索系统,也一样可以成为RAG中关键的R的部位。
下面聊聊这个范式的优势吧,给大家做方案选择提供依据和支持。
我的视角理解,主要是这几个原因吧:
然而我的视角,其实有蛮多人,都在考虑这个范式,致力于提升整个RAG的效果的,亦或者是,无意识的探索最终走向了这个结构。
有的人可能会说,全文都在聊搜索,在聊RAG中的R,那大模型哪去了。这里我想聊的就是,对大模型作用的压缩,可能会是应用场景下的一种调优思路。
不知道大家有没有发现,就是在现实应用中随着对大模型的逐渐深入应用,我们好像都会尝试把某些功能从大模型里抽出来,让大模型处理的事情更单一,举几个例子:
如此一来,大模型在RAG的核心作用,被压缩成小幅度的内容抽取、回复风格迁移之类的简单活了,因为他有最基本的“世界知识”,能做简单的推理和转述,甚至,极端的,如果小模型能做到这个事,很可能大模型的功能也会被干掉。
也可能会有人问,大模型除了用在最后,也可以用在前面的检索模块里,如self-RAG中就有大量应用在检索模块内部,可以是肯定可以的。但我们仔细回想一个问题,我们的目的是“用大模型”还是“解决问题”,如果是工具导向,那无可厚非,但如果我们是结果导向,而且大部分情况我们都可能是结构导向下,大模型就不是唯一的选择了,他始终只是一个方法,一个工具,类似的思考我在这篇文章里也有提到([心法利器[97] | 判断问题是否真的需要大模型来解决](),在特定情况下,如数据匮乏,不支持训练下,那大模型是一个不错的选择。
在self-RAG的文章讨论里([前沿重器[42] | self-RAG-大模型决策的典型案例探究](),我其实有提到对self-RAG内评论模型等方面使用大模型的质疑,因为此处作者并没有考虑过别的模型,也没有做过对比,在CRAG中作者使用的是T5-Large,尽管他需要训练,但效果确实优于chatgpt、chatgpt-cot、chatgpt-fewshot很多,侧面也就说明,大模型在一些方面的优势并没有那么明显。
大家真要多去做实验测试,也要多看各种材料做知识储备,去拓宽自己的知识面,增加手里的工具,也理解自己手里工具的差异,优劣势在哪里,不能一上来大模型不灵了,效果不好了就束手无策了,尤其面对现实应用中千奇百怪的问题,得有更多拿得出手的武器。
作为一名热心肠的互联网老兵,我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。
但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的 AI大模型资料
包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。