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的重要性。、CRAG都有这个倾向）
• 对query、检索结果反馈，需要分情况讨论，并且对不同的情况会有不同的处理方案。Adaptive RAG对query有进行分情况讨论，对困难问题提前预判需要多次检索，对简单问题则甚至不需要检索直接出答案；CRAG则对检索结果的可靠性进行判别，对不太可靠的则会选择结合谷歌搜索结果来整合，对完全不可靠的结果则直接放弃检索结果。

开源项目

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

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

• 根据召回所使用的索引方案，可以有字面、向量、数字，甚至地理位置的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很多，侧面也就说明，大模型在一些方面的优势并没有那么明显。

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

如何系统的去学习大模型LLM ？

作为一名热心肠的互联网老兵，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。

但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的 AI大模型资料 包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

😝有需要的小伙伴，可以V扫描下方二维码免费领取🆓

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

四、AI大模型商业化落地方案

阶段1：AI大模型时代的基础理解

• 目标：了解AI大模型的基本概念、发展历程和核心原理。
• 内容：
  • L1.1 人工智能简述与大模型起源
  • L1.2 大模型与通用人工智能
  • L1.3 GPT模型的发展历程
  • L1.4 模型工程
    - L1.4.1 知识大模型
    - L1.4.2 生产大模型
    - L1.4.3 模型工程方法论
    - L1.4.4 模型工程实践
  • L1.5 GPT应用案例

阶段2：AI大模型API应用开发工程

• 目标：掌握AI大模型API的使用和开发，以及相关的编程技能。
• 内容：
  • L2.1 API接口
    - L2.1.1 OpenAI API接口
    - L2.1.2 Python接口接入
    - L2.1.3 BOT工具类框架
    - L2.1.4 代码示例
  • L2.2 Prompt框架
    - L2.2.1 什么是Prompt
    - L2.2.2 Prompt框架应用现状
    - L2.2.3 基于GPTAS的Prompt框架
    - L2.2.4 Prompt框架与Thought
    - L2.2.5 Prompt框架与提示词
  • L2.3 流水线工程
    - L2.3.1 流水线工程的概念
    - L2.3.2 流水线工程的优点
    - L2.3.3 流水线工程的应用
  • L2.4 总结与展望

阶段3：AI大模型应用架构实践

• 目标：深入理解AI大模型的应用架构，并能够进行私有化部署。
• 内容：
  • L3.1 Agent模型框架
    - L3.1.1 Agent模型框架的设计理念
    - L3.1.2 Agent模型框架的核心组件
    - L3.1.3 Agent模型框架的实现细节
  • L3.2 MetaGPT
    - L3.2.1 MetaGPT的基本概念
    - L3.2.2 MetaGPT的工作原理
    - L3.2.3 MetaGPT的应用场景
  • L3.3 ChatGLM
    - L3.3.1 ChatGLM的特点
    - L3.3.2 ChatGLM的开发环境
    - L3.3.3 ChatGLM的使用示例
  • L3.4 LLAMA
    - L3.4.1 LLAMA的特点
    - L3.4.2 LLAMA的开发环境
    - L3.4.3 LLAMA的使用示例
  • L3.5 其他大模型介绍

阶段4：AI大模型私有化部署

• 目标：掌握多种AI大模型的私有化部署，包括多模态和特定领域模型。
• 内容：
  • L4.1 模型私有化部署概述
  • L4.2 模型私有化部署的关键技术
  • L4.3 模型私有化部署的实施步骤
  • L4.4 模型私有化部署的应用场景

学习计划：

• 阶段1：1-2个月，建立AI大模型的基础知识体系。
• 阶段2：2-3个月，专注于API应用开发能力的提升。
• 阶段3：3-4个月，深入实践AI大模型的应用架构和私有化部署。
• 阶段4：4-5个月，专注于高级模型的应用和部署。

这份完整版的大模型 LLM 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

😝有需要的小伙伴，可以Vx扫描下方二维码免费领取🆓