Rag系统的发展历程，从朴素、高级到模块化

前段时间，一篇关于RAG系统基本原理的文章引起了大家的热烈讨论，不少读者追问：RAG在实际落地时到底会遇到哪些坑？又该怎么填？今天，我们就来系统地梳理一下RAG技术演进过程中的那些关键问题，以及对应的优化思路。

从2020年Meta AI的研究人员提出检索增强生成方法至今，RAG系统其实一直在迭代。总结下来，它经历了三个清晰的阶段：先是最初的朴素型RAG（Naive RAG），接着进化到高级型RAG（Advanced RAG），最后演变成了今天更为灵活的模块化RAG（Modular RAG）。

下面，就沿着这三个阶段的脉络，逐一看看它们各自面临什么挑战，又是如何被逐步解决的。

RAG刚起步时，核心框架由索引、检索和生成三部分构成，这个范式被称作朴素RAG。它的原理非常直观，分三步走：

索引：这一步通常在离线完成。把原始文档清洗、切分成块，再通过嵌入模型（embedding model）把每个块转化为语义向量，建立索引。检索：用户提问后，用同样的嵌入模型计算问题向量和每个文档块向量的相似度，挑出最相似的前N个块，作为增强上下文。生成：把原始问题与检索到的文档块拼接成新提示，交给大语言模型生成答案。如果有多轮对话历史，也可以一并加入。

这个框架虽然简单易懂，但一落到真实场景，问题就全冒出来了。

索引环节：核心关键词很容易被一堆无关信息淹没，导致索引里有效知识占比小、噪声大，最终答案质量自然受影响。另外，内容块的分割方式会影响语义完整性，长文本里重要信息可能出现丢失或掩盖。检索环节：用户原始问题（query）可能语义复杂或涉及专业词汇，难以准确匹配知识库。单纯算向量相似度，缺乏对查询与文档之间深层关系的理解，检索质量不稳定。更麻烦的是，朴素RAG会把所有检索到的块一股脑扔进大模型，冗余信息干扰关键信号，反而更容易出错。生成环节：一旦没检索到相关知识或检索内容质量差，大模型就可能自行胡诌，产生幻觉；或者回答空洞，基本没法用。

要解决这些问题，就得在检索前和检索后做文章，于是高级RAG应运而生。

相比于朴素RAG，高级RAG在检索前、检索中和检索后都加入了针对性优化。下面的对比图可以看得更清楚，优化主要集中在这三个黑框环节。

检索前主要做两件事：建立索引和处理查询。

为了解决核心信息被淹没、语义分割受影响的问题，高级RAG引入了三个手段。索引降噪：根据业务特点剔除索引中的无效成分，突出核心知识。比如原文档中有一句“How can I download source code from github.com”，核心内容就是“下载源码、github”，其他词基本可以忽略。知识切分：先训练一个专门的语义理解小模型，把长文本按语义内聚性切成小块，避免核心知识被截断。元数据：给每个块增加摘要、时间戳、用户可能提出的问题等附加信息（这些元数据本身不向量化），还可以加上章节引用、关键词、小节标题等，帮助提高检索准确度。

为了解决用户意图识别不准的问题，高级RAG引入了查询改写（Query改写），但计算相似度时仍然用嵌入模型。查询改写就是把原始问题转换成更适合知识库检索的形式，常用的有查询分解（把一个复杂问题拆成几个子问题）和查询扩展（把一个问题转成几种不同问法）。

检索阶段的目标是召回最相关的知识。朴素RAG只靠向量相似度，但问题和文档块之间的语义匹配并非总是那么完美。为此，高级RAG对嵌入模型做了微调，把它定制到特定领域，尤其是在专业术语密集的场景下，效果提升明显。

朴素RAG把检索到的所有块直接输入大模型，冗余信息过多。高级RAG从两个方向入手：提示压缩：先删除无关内容、突出重要上下文，减少提示长度和噪声干扰。重新排序：用专门的排序模型重新计算相关性得分，比如Cohere模型，它考虑了查询意图、词汇多重语义、用户历史行为等更多特征。

不过，高级RAG离理想状态还有差距。数据源本身质量差（“垃圾进，垃圾出”），结果自然好不了。而且随着应用场景越来越丰富，数据不再限于非结构化的文本，还要处理表格这种半结构化数据，以及数据库、知识图谱这种结构化数据。高级RAG对实体间的复杂关系和层次结构（比如分析一本书的主旨，或者梳理一篇长论文的概念关系）依然力不从心。于是，模块化RAG登场了。

三个范式并非泾渭分明，而是继承与发展的关系：高级RAG是模块化RAG的一个特例，朴素RAG又是高级RAG的一个特例。模块化RAG本质上仍然是高级的，只是模块划分更清晰，管理更直观。框架与高级RAG类似，包括索引、检索前、检索中、检索后和生成，但增加了一个编排环节，一共六大环节。每个环节的能力都被拆成独立模块，比如索引环节包含块优化（chunk optimization）、结构组织（structural organization）；预检索环节包含查询转化（Query Transformation）、查询扩展（Query Expansion）、查询构建（Query Construction）等。

下面，我们就围绕模块化RAG的每个模块，详细展开每个环节的痛点与解法。

早期RAG的索引环节有三个主要问题：内容表述不完整、块相似性搜索不准确、参考轨迹不明晰。针对这些，模块化RAG将其拆为两个方向：块优化和结构组织。

分块大小对索引影响很大。大块能捕捉更多上下文，但噪声多、成本高；小块噪声少，但可能丢失必要信息。优化方案有三种：滑动窗口：把文档分割成多个重叠的段落窗口，每个窗口包含连续句子并生成嵌入向量，缓解上下文丢失问题，但可能控制不精准。增加元数据：给块添加页码、文件名、作者、时间戳、摘要等问题作为元数据（在高级RAG中已使用，这里继承）。从小到大：把用于检索的块和用于合成的块分开，检索用小块，合成用大块。

结构组织是通过改变索引的组织方式来提升检索速度和准确性。主要的优化方式有：多级索引：创建两个索引——一个由文档摘要组成，另一个由文档块组成。搜索时分两步走：先通过摘要过滤相关文档，再在相关组内检索。这种策略需要配套多级路由机制，比如用户问“最新发表的RAG论文推荐”，系统先路由到论文专题索引，再按时间筛选。知识图谱：嵌入模型难以捕捉实体间的复杂关系和层次结构，导致传统RAG面对复杂查询时力不从心。比如用户问“《跨越鸿沟》这本书的主旨是什么”，传统RAG肯定回答不上来。但知识图谱在建立索引时会提取实体及其关系，构建全局视角，从而大大提升精确度。

朴素RAG直接使用原始query检索，存在三个问题：措辞不当（尤其涉及专业词汇时）、知识库内数据无法直接回答需组合、细节太多导致检索效率低。高级RAG提出了query改写的思路，模块化RAG将其细化为三个方向：查询扩展、查询转换和查询构建。

查询扩展就是把单个查询拓展成多个，为缺失的上下文提供补充。多查询（Multi-Query）：借助prompt engineering让大模型把原始query扩展成多个相似query并行执行。一种有效的方案叫Rag-fusion：先用大模型扩充原始query生成多个改写，然后对每个生成的query做向量搜索形成多路召回，最后用倒数排名融合算法重新排序文档。子查询：通过分解和规划，把复杂问题拆成几个子问题。比如“请详细且全面地介绍RAG”，可以拆成“RAG的概念是什么？”“为什么产生RAG？”“RAG的原理？”“RAG有哪些使用场景？”等。

查询转换是把用户的原始查询转换成一种新形式后再检索，不增加查询数量。查询重写：直接利用大模型重新表述问题。多轮对话中，用户可能指代上文信息，可以把历史信息和当前提问一起交给大模型改写。HYDE：全称Hypothetical Document Embeddings，先用大模型生成一个“假设”答案（即使可能包含虚假信息），再把这个假设答案和原始问题一起用于向量检索。这个假设答案包含大模型认为相关的文档模式，有助于在知识库中找相似文档。Step-Back Prompting：如果原始查询太复杂或返回信息太广泛，可以生成一个抽象层次更高的“退后”问题，和原始问题一起检索。比如“勒布朗·詹姆斯在2005年至2010年在哪些球队？”可以退一步问“勒布朗·詹姆斯的职业生涯是怎么样的？”，再从这个结果中检索具体答案。

与扩展和转换不同，查询构建主要是把自然语言query转化为机器或软件能理解的语言。因为在ChatBI等场景下，需要把用户query转化为SQL语句进行数据库查询（Text-to-SQL）；在工业设计场景下，可能需要转化为设计指令或设备控制指令（Text-to-Cypher）。

检索环节主要优化两个方向：检索器选择和检索器微调。

检索器本质上是计算query和内容块相似度的算子。原始的形态是基于嵌入模型的向量相似度，但可以通过转化算子来优化。稀疏检索器：用统计方法把查询和文档转化为稀疏向量，处理大规模数据集时效率高，但复杂语义捕捉不如密集向量。密集检索器：用预训练语言模型提供密集表示，计算和存储成本更高，但语义表达更精细。可以同时构建这两种检索器，然后通过编排模块在特定query时选择最合适的。

当上下文与预训练语料库差异较大（比如高度专业化的领域），就需要微调检索器。方式有三种：监督微调：基于有标记的领域数据微调检索模型，通常借助对比学习。LM监督检索器：借助语言模型生成的结果作为监督信号，在RAG流程中对嵌入模型微调。适配器：一种轻量级模块，在不改变原始模型结构的情况下增加新功能或调整行为，更好地适配下游任务。

朴素RAG中，系统把所有检索到的块直接输入大模型，导致中间内容丢失、噪声占比高、上下文长度受限等问题。高级RAG给出了提示压缩和重新排序的思路，模块化RAG将其进一步分为三个模块：重排序、压缩和选择。

使用专门的排序模型重新计算相关性得分，考虑查询意图、词汇多重语义、用户历史行为等更多特征，比如Cohere模型。

先删除无关内容、突出重要上下文，减少提示长度，降低冗余信息干扰。

直接移除无关的文档块。一种有效方法是LLM-Critique，在生成最终答案前通过大模型批评机制过滤掉相关性不高的文档。

生成环节可能出现格式错误（比如忽略表格或列表指令）、输出错误或不完整（如比较类问题处理不佳、幻觉）、输出不符合社会偏好或整治不正确等问题。模块化RAG从两个方向解决：生成器微调和验证。

指令微调：当大模型在特定领域缺少数据时，通过微调提供额外知识，并调整输出格式和风格。强化学习：手动标注最终答案，借助强化学习让输出与人类偏好契合。Prompt优化：RAG系统的prompt应明确指出回答仅基于搜索结果，避免大模型自主回答。

知识库验证：通过外部知识直接验证大模型生成的响应。基于模型的验证：训练一个小语言模型，给定输入问题、检索到的知识和生成的答案，判别答案是否正确反映了检索到的知识。

编排模块是模块化RAG与高级RAG最大的区别。有了编排，系统可以在关键节点做决策，依据先前结果动态选择后续步骤，实现自适应流程。比如针对某个query，选择哪个知识库、哪种检索器、适配器和生成器等。模块化RAG将编排分为路由、调度和融合三个模块。

路由的作用是为每个query选择最合适的处理管道，并依据输入或元数据确定启用哪些模块。比如在索引环节引入多重索引后，就需要多级路由机制，引导query到最合适的父级索引。

调度模块在需要复杂规划和反思的场景中至关重要——何时递归、何时迭代、何时反馈、何时停止循环，都由它控制。规则判断：提前设定阈值，评估分数超过阈值时触发后续动作。知识图谱判断：从知识图谱中提取相关信息，构建推理链，每个节点承载关键信息，分别进行检索和生成。Agentic-RAG：RAG应用退化为Agent使用的知识工具。针对一个文档/知识库构建多种RAG引擎——用向量索引回答事实性问题，用摘要索引回答总结性问题，用知识图谱索引回答需要关联性的问题等。

随着RAG发展，单一线性流程已不够用，经常需要扩大检索范围或通过多条流水线增加多样性。融合模块不仅要合并答案，还要确保最终输出内容丰富、反映问题的多维度特性。LLM融合：先对每个分支的答案总结关键信息，再输入LLM，即便长度受限也能保留重要内容。互反排名融合：把多个检索结果的排名合并成一个统一列表，用加权平均提高预测性能和排名精度。

这篇文章系统梳理了RAG技术从朴素到高级再到模块化的演进历程，以及每个阶段遇到的短板和对应的优化方案。RAG系统入门门槛不高，但真正做好、做扎实，需要在实际项目中不断摸索、反复调试。理论终归要为实践服务，希望这些梳理能为大家在落地过程中提供一些参照和启发。