RAG结构思考：搜索系统范式和大模型作用压缩

先说一个核心判断：RAG（检索增强生成）发展到现在，其架构思路已经出现了一个明显的分水岭。不少人可能还停留在“向量检索 + 大模型”的初级阶段，但更务实、更高效的玩法，其实正在向经典的“搜索系统 + 大模型”范式演进。这篇文章的核心目的，就是想把我最近的思考脉络和推导过程理清楚，最后落到一个比较简单的结论上：RAG中的那个“R”，完全有理由成为一个独立、完整的搜索系统。

那么，我们具体要聊哪几个事？

• 首先，看看现在学术界和工业界，大家研究RAG的思路都走到哪一步了。
• 其次，经典的搜索系统长什么样？它的内部结构到底有何精妙之处？
• 再次，基于这个结构，RAG中的“R”应该遵循哪种范式？
• 最后，在这个新范式下，大模型的核心作用又是如何被压缩和再定义的？

现阶段RAG的研究思路

学术界讨论

之前我们聊过几篇很有代表性的文章，比如Self-RAG、CRAG、Adaptive-RAG。这几篇文章的思路各成一派，但从技术演进的路线来看，里面藏着非常共通的几个迹象。

第一个共识：把“检索”和“大模型”简单地拼在一起，天花板太低了，很难做出效果非常好的东西。这一点几乎不需要争论。无论是综述文章还是各种架构讨论，都提到了Advanced RAG和模块化RAG的概念。为了提升效果，我们必须在中间插入更多的组件。而这些组件的设计，也成了目前RAG论文的主要创新点。这其实侧面说明了一个被工业界反复验证的道理：非端到端、系统功能任务的解构拆分，是效果提升的重要手段。不说别的，现在成熟的对话系统、推荐系统、搜索系统，哪个不是按照这个思路一步步演进过来的？这也是它们与学术界主流的端到端方案分道扬镳的地方。

第二个迹象：为了让RAG的结果更可靠，几乎所有的方案都会对检索结果进行二次判别、校验甚至后处理。这反过来也说明，检索结果的质量，直接决定了RAG的最终效果。Self-RAG用自己的模型来判断是否需要检索、结果是否相关，CRAG则更直接，对检索结果的可信度进行分级打分，决定是接续搜索还是直接放弃。

第三个迹象：对用户的query和检索结果需要分情况讨论，不同的情况要有不同的处理方案。Adaptive-RAG会根据问题的难度，动态决策是否需要检索，简单的甚至不检索直接回答；CRAG则根据判别结果，对高可靠性的结果直接用，对不可靠的会结合网络搜索来修正，对完全不可靠的干脆放弃。

开源项目

如果你觉得学术界的东西还太飘，那看看工业界的落地项目，就更清晰了。比如网易有道开源的QAnything，其设计思路几乎完美印证了上面的发现。

首先，对检索结果的再判，在QAnything里是一个叫做“Rerank”的明确模块。作者在文档里讲得很清楚：在大规模知识库场景下，两阶段架构的优势非常明显。如果只用第一阶段向量召回，数据量一上来，效果会直线下降（就像文档里那张图里的绿线）。但引入第二阶段的Rerank后，准确率就能实现稳定增长，数据越多，效果越好。

另外，虽然QAnything的分享里没有专门去聊“分情况讨论”这件事，但在它的架构图中，明确出现了“Query Understanding”模块。这说明在系统设计时，query理解是必不可少的一步，它要做的就是为后面的检索和排序服务。

现阶段搜索系统的一般范式

搜索系统发展至今，从2000年左右的百度，到更早的谷歌，架构层面已经形成了一个高度共识的基础结构。我之前聊腾讯搜索时提到过一些，现在把更详细的架构图重新摆出来。

这个通用范式就是：

。我们来拆开看每一环的作用。

首先是Query理解，也就是用户意图理解。感性地看，它是要对用户输入的query进行结构化或非结构化的信息抽取，搞清楚用户到底想要什么。搜索对准确性的要求极高，用户的需求很明确，一旦有偏差，体验就会很差。理性地看，Query理解是为下游的召回和排序服务的。比如，通过意图识别，我们可以决定是去搜音乐库、调用天气API还是查人物百科；通过实体抽取，我们可以确保搜“周杰”时不出“周杰伦”，甚至在排序阶段，抽取出的实体也能作为重要特征。

然后是召回。现实世界的召回场景，一定是多路的。这和前面说的“分情况讨论”不谋而合。召回路的设计依据可以有很多种，思路千万别被局限住。比如，根据索引类型，可以有字面召回、向量召回，甚至针对地理位置用geohash；同样是向量召回，可以用不同模型来生成向量，语义的、协同过滤的，形成多路；根据业务和数据库划分，音乐库里有歌手、作曲、专辑，电影库里有导演、演员，需要为不同的库设计不同的召回路。

至于排序，完善的系统里通常有粗排和精排。粗排通常和召回绑定，目标是从召回的众多结果里快速过滤掉明显不对的，选出最相关的TopN。精排则是在粗排基础上做“优中选优”，目标是区分“谁更好”，需要体现排序性。这其实和我之前聊过的“准招分治”思想是一致的：把“是否相关”和“谁更相关”分开处理，思路清晰，效果也更好。

RAG中R的一种范式

搜索系统经过多年的摸索才形成了这套“理解-召回-排序”的范式。结合当下RAG发展中的迹象，我越来越确信，RAG中的那个“R”，也必然朝着这个方向演进。

• 理解
  ：从用户的query中抽取关键信息，为下游模块服务。具体抽什么，取决于下游需要什么。如果需要关键词召回，就做关键词抽取；如果需要根据意图选择数据库，就做意图识别。

• 召回
  ：结合数据结构来设计。字面召回和向量召回都要考虑，具体用哪个还是全上，得看数据的特点。

• 排序
  ：在召回内部，一般有粗排算法，比如BM25对应字面、余弦相似度对应向量。精排层则根据已有特征设计，纯文本场景用句子对相似度模型（BERT级别）效果就不错。但不要局限于纯文本，有时候挖掘一些结构化特征来辅助排序，是很重要的优化手段。

这个范式，是我基于实战思考得出的解耦思路，和前面提到的Self-RAG、CRAG等方案不同。基于这个范式，我们还需要聊它的迭代思路、优势，以及为什么今天它还没被广泛应用。

迭代思路

一个完整的系统不是一天建成的。它的演进是螺旋上升的，在不断解决问题和暴露新问题的过程中迭代。

：从零到一，搭起基础RAG。就是最简陋的那个结构：只有向量召回，没有理解和排序，大模型就是简单的prompt拼接。但这足够了，先跑通再说。

：扩展召回路，搭建Query理解模块。做过项目的人都知道，向量召回的效果很难调优，特别是准确率。而准确率最好保证的就是规则。所以，当遇到“easy case”效果不好时，引入规则就成了自然选择，而海量规则就演化成了字面检索，对应的Query理解模块也就随之产生了。最开始可能是一句规则“如果用户包含‘周杰伦’，就去搜音乐”，后来发现歌手是个常用实体，音乐又是独立库，那就新增一路召回，并配合实体抽取模块。

：引入精排模型。当一个意图下的召回路越来越多，返回的内容相似度太高或排序不合理时，精排模型就该登场了。

走到第三阶段，整个检索模块就俨然是一个功能完整的搜索系统了。

优势

这个范式的好处显而易见。

• 结构清晰，问题定位快
  ：RAG效果不好，定位问题范围。是R出错了，那就看R内部，意图识别、召回、排序，哪一环出问题一目了然。

• 迭代流畅，风险小
  ：整个流程是往系统里加模块，而不是大改架构，每次迭代的目标都很明确，也降低了“本次迭代毁掉上一轮效果”的风险。

• 人力分工明确
  ：可以按意图横向拆分，每人负责一个业务场景；也可以按功能层拆分，有人专门搞意图识别，有人专门搞召回。分工明确，避免团队所有人对着同一个模型较劲，相互掣肘。

为什么现在还没广泛应用

我觉得主要有这几个原因。

• 目前做RAG的人，很多没有做搜索的经验，对搜索的理解不够深。大部分人的视角还是停留在RAG本身，而RAG的研究积累本身也不多。现在还处于“只要有修改大概率就有提升”的蛮荒阶段，意识还没转到把“R”作为一个独立系统来研究。
• 目前主流的声音都是开放域的通用研究，讲究泛用和端到端。类似意图识别、问题的横向拆解，这类研究在学术界看起来“不够性感”，也不太“整治正确”。大家更愿意研究如何纵向拆解RAG（比如如何改进检索），而不是横向着去想“不同的问题应该如何用不同的流程来处理”。
• 根据之前的经验，很多项目根本走不到搜索系统的完整形态那个阶段。成功的案例不够多，也就难以形成像推荐系统、搜索系统那样丰富的分享共识。

但是，我的观察是，其实已经有不少团队和个人，在无意识或有意识地向这个范式靠拢，努力提升RAG的效果。

大模型作用的压缩

聊了半天搜索和“R”，那么大模型到底在哪儿？我想聊的正是这个：

你发现没有，我们在实践中，似乎总在尝试把某些功能从大模型里抽出来。比如：

• 担心大模型输出幻觉，就构造知识库，提升知识库质量，让大模型只做信息提取和整合，不进行回忆和创造。这就是RAG出现的原因。
• 担心大模型处理太多噪音，就做精排，筛选出最相关的知识输入给大模型。
• 想让回复有特定风格，就把风格配置放在意图或对话策略里，在prompt里直接要求大模型执行，而不是让它自己决定。

这样一来，大模型在RAG中的核心作用，就被压缩成了小范围的内容抽取、风格迁移这些“小活”。它只需要利用其世界知识和推理能力，做好简单的“转述”工作。极端情况下，如果一个小模型也能完美地完成这些任务，那么大模型就会被完全替代。

也许有人会问，大模型也能用在检索模块里啊，比如Self-RAG就用在了多个内部环节。当然可以。但我们得想清楚，我们的目标到底是“用大模型”还是“解决问题”？如果是工具导向，那没问题。但如果我们是结果导向（大部分情况下我们确实都是），那么大模型就只是一个工具，一个方法，而不是唯一的选择。在数据匮乏、无法训练的情况下，大模型确实是不错的选择；但如果能通过训练一个更小、更快的模型来解决，效果可能更好。

我之前在聊Self-RAG时就提到过，对其中用大模型做评论模型这件事存疑，因为论文里没有做过对比实验。而在CRAG中，作者用的是T5-Large（虽然需要训练），但在多个指标上全面超越了ChatGPT及其变种。这从侧面说明，大模型在某些方面的优势，并没有被我们想象得那么大。

大家真得多去做实验，多看各种材料，把自己手里的“工具箱”扩大，搞清每个工具的优劣势。别一上来发现大模型不管用了就手足无措。面对现实应用中千奇百怪的问题，手里得多备几把称手的家伙。