心法利器[113] | RAG结构思考：搜索系统范式和大模型作用压缩

RAG的文章写的也不少了（心法利器[111] | 近期RAG技术总结和串讲（4w字RAG文章纪念）），除了原有知识的串讲，我还想聊的是在已经阅读的文章里带来的一些新的想法和思考，形成自己的方法论，我自己是挺喜欢这种思考和分析的，一方面锻炼自己独立思考的能力，另一方面也让自己在应用过程中更加顺手熟练。

本文是我的思考、推导和论证路线，结论其实比较简单，就是RAG整体结构可以从“向量检索-大模型”升级到“搜索系统-大模型”的结构，同时，大模型的作用也有必要聊清楚，因此，文章里我会讲明白这几个事：

• 现阶段RAG的研究思路
• 搜索系统的一般结构是什么样的
• RAG中的R的一种范式
• 大模型作用的压缩

现阶段RAG的研究思路

学术界讨论

前面少有地对很多文章进行了讲解，并给出了自己的想法，主要有这些：

• 前沿重器[42] | self-RAG-大模型决策的典型案例探究
• 前沿重器[43] | 谷歌中科院新文：CRAG-可矫正的检索增强生成
• 前沿重器[44] | Adaptive-RAG:根据难度自适应检索方案
  

从这些文章，尽管这些文章的思路各异，也给出了很多丰富的讨论，但我们还是能从中找到一些共性，这是我从几篇论文和分享里发现的几个迹象。

首先，仅仅只有检索和大模型，并将其简单的拼接，是很难达到更高的上限的。这点应该是一个共识。从综述文章以及其他对RAG架构讨论的文章里，都提到了advanced RAG以及模块化RAG的存在，我们需要更多的组件来支撑这个项目，以获得进一步的提升，而组件的设计，就成了目前RAG论文主要的创新点。这个侧面也在说明，非端到端化、系统功能任务的拆解是效果提升的一大重要手段（这个问题似乎有写一篇文章的价值？），在工业界落地具有很大价值，逐步发展而走向成熟的工业对话系统、推荐系统、搜索系统无一都是这个思想下的产物，这也是和学术界端到端方案分道扬镳的分水岭。（叠个甲，并非说端到端就不好）

• 为了让RAG的结果更加可靠，都需要对检索的结果进行进一步判别、校验甚至后处理，侧面也表示了检索结果对RAG的重要性。（self-RAG（前沿重器[42] | self-RAG-大模型决策的典型案例探究）、CRAG（前沿重器[43] | 谷歌中科院新文：CRAG-可矫正的检索增强生成）都有这个倾向）
• 对query、检索结果反馈，需要分情况讨论，并且对不同的情况会有不同的处理方案。Adaptive RAG（前沿重器[44] | Adaptive-RAG:根据难度自适应检索方案）对query有进行分情况讨论，对困难问题提前预判需要多次检索，对简单问题则甚至不需要检索直接出答案；CRAG则对检索结果的可靠性进行判别，对不太可靠的则会选择结合谷歌搜索结果来整合，对完全不可靠的结果则直接放弃检索结果。

开源项目

而现行的一些开源项目，也有对这些思路的应用，这点也印证了我的分析的正确性。来看看最近网易有道开源的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内的信息进行抽取，了解用户的实际需求，针对用户的需求进行检索，提升检索的准确性和可解释性。注意，搜索对准确性的要求极高，因为用户的需求明确，知道自己要什么，因此只要有一点偏差都会带来很差的体验；理性解释，则主要用在召回、排序模块，为召回和排序提供依据，例如意图可以作为检索策略选择的依据，该去搜音乐库、调用天气接口还是人物百科，实体抽取可以协助进行检索，例如要搜周杰的就不会出周杰伦，甚至在排序阶段能够作为特征提供排序参考。

然后是召回，在现实的召回场景，通常是多路的，也是需要进行信息参照的，这个和前面的“分情况讨论”不谋而合，而分多路的依据也是不一样的，大家的思路不要被局限住了。我举几个例子：

• 根据召回所使用的索引方案，可以有字面、向量、数字，甚至地理位置的geohash。
• 同样是向量召回，也可以有不同的模型来支持向量表征，可以是语义向量，也可以是协同过滤构造的特征向量等，从而出现多路召回。
• 根据业务和数据库的划分，会对应不同字段，例如音乐则有歌手、作曲、歌名、专辑等，而电影则有电影名、导演、标签、演员等，存在不同的库里，因此需要划分链路进行召回。

至于排序，在非常完善的推荐系统和搜索系统里，是可能有多轮的排序的，不同的排序会对应不同的结果，根据业务也可能不同。不过一般的，就是分成粗排和精排。

• 粗排更多是和召回绑定的，主要针对的各个链路的召回结果，符合要求的内容众多，但只要最相似的TOPN，一般我们就需要算分和卡阈值。更多的，要判断的是“是否”，即是否匹配，更多是考虑把肯定不对的给干掉。
• 精排则是在粗排的基础上做进一步排序，一般考虑更多的是几个结果的区分度，即“谁更好”，因为要精上加精，所以要体现排序性。一般的learning to rank领域去考虑，对效果提升会更明显。

想起一篇我之前聊到准招分治的文章（心法利器[15] | 准招分治效果调优方案），这篇文章从准确与召的角度很好地诠释了为什么要分开召回和排序，也跟QAnything提到的两阶段效果好的结论是一致的，是一种很好地解释。

RAG中R的一种范式

搜索系统经过多年的探索总结，才形成上述的范式，结合现在RAG发展过程中所体现的一些迹象，我有理由相信RAG中的R很可能也会朝着这个方向去做。参考上面搜索系统的结构，核心逻辑还是理解-召回-排序。

• 理解，从query中抽取关键信息，服务下游。具体需要做哪些模块，由业务需求、下游模块反推，例如要做关键词召回、实体召回，那理解部分就做实体抽取、关键词抽取，下游要分数据库查询、要分回复策略等，那就理解模块就做意图识别。
• 召回，结合实际数据的结构进行设计，字面和向量都需要考虑，具体用哪个还是全都用，参考具体数据综合分析。
• 排序，召回内一般有粗排算法，如BM25对应字面，cos对应向量之类的，精排层则根据目前已有的特征进行设计，如果是纯文本，那用句子对相似度来做就差不多了，bert级别也有不错的效果，但不要只局限在纯文本，有的时候挖掘一些特征来辅助也是可以的。

这个范式，是相比之前聊过的self-RAG、CRAG、adaptiveRAG而言的，他们有各自的拆解思路，而这个是我的拆解思路。这个拆解思路下，还需要展开讨论几个点，分别是迭代思路、优势以及分析为什么现在还没广泛应用。

迭代思路

万丈高楼平地起，完整的系统不是一蹴而就的，而是随着项目的发展，不断暴露各种问题难题，在解决问题和发现问题的交替下螺旋上升的，所以这里还是要专门讲一下这个完整系统的迭代思路。

在项目早期，从无到有，更多是把项目的基础工作搭建起来，基础的RAG要跑起来，这个就是我之前写的这个项目（心法利器[105]  基础RAG-大模型和中控模块代码（含代码）），这是极简的RAG结构，搜索的部分只有一个向量召回，没有理解和排序，大模型部分就是prompt拼接，直接预测就好了。

第二阶段应该是召回链路的拓展以及理解部分的搭建。有过经验的朋友应该知道，一个向量召回想必是不好调优的，尤其是准确率并不好保证，尤其是对easy case的处理，而准确率最好保证的，自然就是规则，而海量通用的规则，就演化成了字面检索，而配合的query理解也就产生了。最开始是要搜包含“周杰伦”所有的音乐，是一条规则，但后续发现，歌手是一个常用实体，音乐是一个库，结合目前音乐是比较独立的检索库，有自己独特的字段，于是新增一路，然后做实体抽取，此时就多了个音乐意图，可以带有歌手实体，需要理解模块的配合才能得到，理解模块就需要建立了。

第三阶段则是精排模型的引入。随着意图、召回链路的增加，每个意图下的处理出现很大的不同，又或者是符合条件的内容过多相似度太高，或者是内容排序效果提升不上去，此时就需要精排模型介入了。到这个位置已经是整个系统搭建已经比较完善的阶段了。

至此，整个检索模块就搭建了起来，成为独立完整的搜索系统，也一样可以成为RAG中关键的R的部位。

优势

下面聊聊这个范式的优势吧，给大家做方案选择提供依据和支持。

• 瀑布式，结构明了，分工明确，问题定位和调优方便。RAG效果不好，进行定位，R出错，看R的内部，意图识别、召回、排序哪里错了，一目了然，意图识别就没进某个管道，召回漏召了，排序出错了，非常清楚，针对性的优化就可以了。
• 迭代流畅。从前面的迭代思路可以看到，整个流程基本都是往原有系统中加小东西，不存在架构大改，而且效果目标明确，大幅度降低“本次迭代导致效果”。
• 人力层面的分工也明确。可以按照意图横向划分，每个人负责一个业务的优化，或者是每个人负责一层，例如意图、召回等，拆解清晰。否则团队所有人都对着一个模型优化，各种纠葛会非常多。

为什么现在还没广泛应用

我的视角理解，主要是这几个原因吧：

• （叠甲，非贬义）目前做RAG的，很多没有原来的搜索经历，或者是对搜索的理解不是很深，这方面的研究也不是很多。大部分人的视角还是在RAG上，而RAG本身的研究积累也不多，而且现在还处于“只要有修改大概率就有提升”的阶段，因此大部分视角和意识还没转到搜索独立研究这块来。
• 目前声音较大的都是开放域通用研究，讲究泛用和端到端，而类似意图识别、问题的横向拆解，是挺“政治不正确”的事，如果直接考虑某个小领域，也鲜有考虑到“如何判断问题是否属于这个领域”这一类问题的研究。这也是为什么RAG的纵向拆解的研究比较多的原因了。
• 根据之前做搜索的经验，其实很多项目压根走不到上面谈到的搜索系统的完整形态这一步，那形成这个范式并且成功的案例也就不够多了，难以形成和原来推荐系统、搜索系统那样的分享，发出声音。

然而我的视角，其实有蛮多人，都在考虑这个范式，致力于提升整个RAG的效果的，亦或者是，无意识的探索最终走向了这个结构。

大模型作用的压缩

有的人可能会说，全文都在聊搜索，在聊RAG中的R，那大模型哪去了。这里我想聊的就是，对大模型作用的压缩，可能会是应用场景下的一种调优思路。

不知道大家有没有发现，就是在现实应用中随着对大模型的逐渐深入应用，我们好像都会尝试把某些功能从大模型里抽出来，让大模型处理的事情更单一，举几个例子：

• 担心大模型回复幻觉，就构造知识库，把知识库质量提升，大模型只做信息整合，不做回忆，于是有了RAG。
• 不考虑信息筛选，不做判别，减少输入大模型的知识数量，前面做精排。
• 要用什么风格，会放在意图或者对话策略里选择，然后prompt直接要求大模型来执行，而不让大模型自己决定，甚至举出例子，让大模型参考着说。

如此一来，大模型在RAG的核心作用，被压缩成小幅度的内容抽取、回复风格迁移之类的简单活了，因为他有最基本的“世界知识”，能做简单的推理和转述，甚至，极端的，如果小模型能做到这个事，很可能大模型的功能也会被干掉。

也可能会有人问，大模型除了用在最后，也可以用在前面的检索模块里，如self-RAG中就有大量应用在检索模块内部，可以是肯定可以的。但我们仔细回想一个问题，我们的目的是“用大模型”还是“解决问题”，如果是工具导向，那无可厚非，但如果我们是结果导向，而且大部分情况我们都可能是结构导向下，大模型就不是唯一的选择了，他始终只是一个方法，一个工具，类似的思考我在这篇文章里也有提到（心法利器[97] | 判断问题是否真的需要大模型来解决），在特定情况下，如数据匮乏，不支持训练下，那大模型是一个不错的选择。

在self-RAG的文章讨论里（前沿重器[42] | self-RAG-大模型决策的典型案例探究），我其实有提到对self-RAG内评论模型等方面使用大模型的质疑，因为此处作者并没有考虑过别的模型，也没有做过对比，在CRAG中作者使用的是T5-Large，尽管他需要训练，但效果确实优于chatgpt、chatgpt-cot、chatgpt-fewshot很多，侧面也就说明，大模型在一些方面的优势并没有那么明显。

大家真要多去做实验测试，也要多看各种材料做知识储备，去拓宽自己的知识面，增加手里的工具，也理解自己手里工具的差异，优劣势在哪里，不能一上来大模型不灵了，效果不好了就束手无策了，尤其面对现实应用中千奇百怪的问题，得有更多拿得出手的武器。