简介：本文系统梳理检索增强生成（RAG）的定义、核心价值与演进脉络，从基础 RAG 到 Agentic RAG 共 16 种方案逐层拆解。你将理解每种方案解决什么问题、适用什么场景、彼此如何递进，并获得从技术选型到工程落地的实用判断框架，帮助开发者在 AI 应用开发中避免“只会背名词”，真正建立可迁移的架构认知。
RAG，全称为 Retrieval-Augmented Generation，中文译为“检索增强生成”。它的核心定义可以拆成三个部分来理解：
Retrieval（检索）：在生成回答之前，先从外部知识源中查找与问题相关的信息片段。这个知识源可以是文档库、知识图谱、数据库、网页、API 返回结果等。
Augmented（增强）：把检索到的信息作为上下文补充，与用户原始问题一起送入大语言模型，让模型在“有依据”的条件下进行推理和生成。
Generation（生成）：大语言模型基于增强后的上下文，生成最终的自然语言回答。
用一句话概括：RAG 是一种在生成式模型推理过程中，动态引入外部知识以提升回答准确性、时效性和可追溯性的技术架构。
从技术视角看，RAG 是一种将“参数化知识”（模型训练时学到的内部权重）与“非参数化知识”（外部可查询、可更新的数据源）相结合的混合推理模式。从业务视角看，RAG 让大模型能够回答训练数据覆盖不到的问题，例如企业内部制度、最新行业动态、特定领域的专业文档。从使用视角看，开发者通过 RAG 可以在不重新训练模型的情况下，让同一个基座模型适配不同的知识域。
RAG 解决的核心矛盾是：大语言模型的知识是“冻结”在训练截止时间点之前的，而现实世界的知识是持续演进的。 模型无法知道自己不知道什么，也容易在知识盲区中产生“幻觉”。RAG 通过引入可检索的外部记忆，将模型从“闭卷考试”模式切换为“开卷考试”模式——模型不再需要记住所有答案，而是学会在正确的时间找到正确的参考资料。
理解 RAG 的价值，需要先回到大语言模型的实际应用困境。
第一个困境是知识滞后。 通用大模型的训练数据存在明确的时间边界，训练完成后，世界上发生的新事件、新政策、新研究、新代码库变更，模型都无法感知。对于企业应用来说，内部系统的接口文档、业务规则、运维手册随时在变化，依赖模型“记住”这些信息既不可靠也不现实。
第二个困境是幻觉问题。 大语言模型在缺乏依据时，往往会生成看似合理但实际上错误的内容。这种幻觉在专业场景中后果尤为严重——错误的技术参数、不存在的 API、错误的法律条款，都可能造成实际损失。
第三个困境是知识溯源困难。 用户无法判断模型给出的答案是基于训练数据中的哪个来源，也无法验证其可靠性。在医疗、法律、金融等需要严格合规的领域，不可溯源的回答几乎是不可接受的。
第四个困境是领域适配成本高。 传统的微调（Fine-tuning）虽然能让模型学习特定领域的知识，但成本高、周期长，且每次知识更新都需要重新训练。对于知识变化频繁的场景，微调显然不是可持续的方案。
RAG 的核心价值正是在这样的背景下凸显出来：
从工程角度看，RAG 将“知识管理”与“推理能力”解耦。模型负责理解和推理，外部系统负责存储和检索事实。这种解耦让整个系统的维护和演化变得更加灵活。
一个典型的 RAG 系统由以下五个核心模块构成：
这是 RAG 系统的最上游，负责将各类原始数据转化为可供检索的标准化格式。具体包括：
将文本块转换为向量表示，并构建高效的检索索引。
接收用户查询，从索引中找出最相关的信息片段。
将检索结果与用户查询组装成大模型的输入。
调用大语言模型生成最终回答，并进行质量控制和输出优化。
这五个模块并非固定不变，不同方案会在这五个层面的不同环节进行优化和增强，由此衍生出各种 RAG 变体。
以一个企业知识库问答场景为例，完整描述 RAG 系统处理一次用户请求的流程：
步骤一：用户提交查询。 用户在应用中输入：“公司最新的差旅报销标准是什么？”
步骤二：查询理解与重写。 系统分析查询意图，识别出这是一个关于“差旅报销”的政策查询，且用户强调“最新”，说明时间维度很重要。系统可能将查询重写为“差旅报销标准 最新版 2026”这样的检索友好形式。
步骤三：多路检索。 系统同时执行向量检索（捕捉语义相关的文档块）和关键词检索（精确匹配“差旅报销”等关键词），分别获取候选结果集。
步骤四：融合与重排序。 将两路检索结果合并，去除重复项，使用重排序模型根据查询与文档块的语义匹配度进行重新打分，筛选出排在前 5～10 的文本块。
步骤五：上下文组装。 系统获取这些文本块的完整内容及其元数据（如文档名称、章节、更新时间），按照相关度顺序拼接，并加上系统提示词：“你是一个企业内部助手，请根据以下参考资料回答用户问题。如果参考资料中没有相关信息，请明确说明无法找到。”
步骤六：生成回答。 大语言模型接收组装好的提示，基于检索到的上下文生成结构化的自然语言回答。
步骤七：后处理与返回。 系统在生成的回答中插入引用标记（例如“[1]《差旅管理制度 v3.2》第2章”），经过安全过滤后返回给用户。
整个流程的关键在于：模型生成的每一个事实性陈述，都应当能在检索到的上下文中找到依据。 如果检索层没有找到相关材料，理想的 RAG 系统应当让模型明确表示“未找到相关信息”，而不是强行回答。
RAG 的演进并非线性替代，而是不断在新的维度上增强。以下按照从基础到高级的顺序，梳理 16 种被广泛讨论和使用的 RAG 方案。每种方案都针对前一代方案的特定缺陷提出改进，理解这种“问题驱动”的演进逻辑，比记住名称本身重要得多。
这是最原始的 RAG 形态，流程为“索引—检索—生成”三步走。文档被切分后向量化存入索引，查询到来时直接执行向量检索，将 Top-K 结果拼入提示词，交给模型生成。
局限：检索精度依赖嵌入模型和切分策略，缺乏对查询和文档的深度理解；检索结果的相关性无法保证；上下文直接拼接可能导致信息冗余或冲突；生成质量完全取决于检索结果的质量。
在基础 RAG 的各个阶段引入优化手段。检索前增加查询重写和扩展，检索中使用混合检索策略，检索后增加重排序和上下文压缩。
改进点：通过多路检索和重排序提升召回质量，通过上下文压缩减少噪声，通过查询优化提升检索意图的准确表达。
将 RAG 系统的各个组件设计为可替换、可组合的模块。检索器、生成器、嵌入模型、重排序器、记忆模块等都可以独立替换，形成灵活的架构组合。
改进点：提升了系统的可维护性和可演化性，允许在不同场景下选择不同模块的最佳实现。
在传统文档切分的基础上，引入知识图谱作为额外的结构化知识层。实体和关系被抽取并构建为图结构，检索时不仅匹配文本，还通过图谱中的关系进行知识扩展和推理。
适用场景：问题涉及多跳推理、实体间复杂关系，例如“A 公司的母公司收购的 B 公司的 CEO 是谁”这类需要跨实体关系链的问题。
查询到来时，先用大语言模型生成一个假设性的回答文档，然后将这个“假设文档”转化为向量进行检索，而不是直接用原始查询向量检索。
核心思想：假设性文档比短查询包含更丰富的语义信息，在向量空间中能更准确地命中相关的真实文档。
对用户的原始查询生成多个语义相似但表达不同的查询变体，分别执行检索，然后将多路结果进行融合排序。
改进点：通过多查询覆盖不同的语义角度，降低单一表达方式带来的检索偏见，提升召回率。
在生成过程中引入自我评估机制。模型不仅生成回答，还同时生成“是否需要检索”“检索结果是否相关”“生成内容是否基于检索结果”等评估信号，动态决定是否执行检索以及对检索结果的使用方式。
改进点：让模型对检索的必要性和质量有判断能力，减少不必要的检索噪声注入。
检索完成后，先对检索结果的质量进行评估。如果评估结果低于阈值，则触发纠正机制：重写查询并重新检索，或者从其他知识源补充检索，直到获得满意的上下文。
改进点：显式引入检索质量的检查与纠错环节，避免低质量上下文直接进入生成阶段。
将单次检索—生成扩展为多轮迭代过程。模型在生成过程中发现信息不足时，可以发起新的检索请求，循环进行“检索—生成—评估—再检索”的过程。
改进点：适用于问题复杂、无法通过单次检索获得完整信息的情况，如多步推理、逐步深入的探索性问答。
根据查询的复杂度动态选择检索策略。简单查询可能不需要检索或只需简单检索，复杂查询则启动多轮迭代检索或混合检索策略。
改进点：在效率和效果之间取得平衡，避免对简单问题执行过重的检索流程。
在索引阶段使用较小的文本块（子块）进行精确检索，但在生成阶段返回其所属的较大文本块（父文档）作为上下文。这样既保证了检索的精确匹配，又保证了生成时的上下文完整性。
改进点：解决了“小切分块检索准确但上下文断裂，大切分块上下文完整但检索精度下降”的矛盾。
在检索结果进入生成阶段之前，使用专门的压缩模型或规则，去除与当前查询无关的冗余信息，只保留最关键的句子或短语，在有限的上下文窗口内塞入更多有效信息。
改进点：提升上下文窗口的利用效率，减少注意力分散。
将检索对象从纯文本扩展到图像、音频、视频、表格等多模态数据。不同模态的数据需要有对应的嵌入方式和检索策略，生成阶段则需要考虑如何将多模态信息有效组织给模型。
改进点：将 RAG 的应用范围从文本问答扩展到更丰富的媒体形式，适用于需要对图表、截图、设计稿等进行问答的场景。
在文本检索基础上，显式利用数据库中的结构化数据（如表格、字段、约束关系）来增强回答的事实性。例如将自然语言查询转换为 SQL 查询，从关系型数据库中直接获取精确的结构化答案，再结合文档检索结果共同生成回答。
改进点：对涉及数值计算、统计对比、字段精确匹配的问题，结构化查询的精确性远高于语义检索。
引入对话记忆和长期记忆模块。系统记住用户的历史交互、偏好、历史决策等信息，在检索和生成时将这些记忆信息纳入上下文，实现跨轮次的个性化回答。
改进点：从“无状态问答”升级为“有状态对话”，使 RAG 系统在长时间、多轮交互场景下表现出更高的连贯性。
这是当前最受关注的 RAG 演进方向。Agentic RAG 将 RAG 系统封装为智能体（Agent）的一项工具能力。智能体拥有规划、反思、工具调用、多步骤推理的能力，可以自主决定在什么时机、以什么方式执行检索，检索什么内容，如何评估检索结果，以及是否需要进行多轮检索或切换检索策略。
核心转变：从“固定的检索—生成流水线”升级为“模型驱动的自主决策过程”。Agentic RAG 中的大模型不再是流水线末端的生成器，而是一个贯穿全流程的“决策大脑”。
典型流程：
理解 RAG 的边界，需要厘清它与另外两个常被拿来比较的概念之间的关系。
RAG 与微调（Fine-tuning）：微调是通过在特定领域数据上继续训练模型，改变模型本身的权重，让模型“内化”新知识。RAG 则是保持模型不变，通过动态检索在推理时注入外部知识。微调改变的是“模型知道什么”，RAG 改变的是“模型能查什么”。微调适合学习相对稳定的“能力”和“格式偏好”（如代码风格、输出结构），RAG 适合获取频繁变化的“事实”和“数据”。两者并非互斥，实践中常常组合使用。
RAG 与上下文学习（In-Context Learning）：上下文学习是在单次请求中直接将示例或知识放在提示词里，不经过检索过程。RAG 可以看作一种“自动化了的上下文学习”——知识的选择不依赖用户手动粘贴，而是由检索系统自动完成。上下文学习适合零散的、一次性的知识注入，RAG 适合大规模、持续更新的知识库场景。
面对 16 种方案，开发者在实际选型时不该追求“最新”或“最复杂”，而应以问题为导向，关注以下维度：
如果知识量小且变化缓慢，基础 RAG 完全够用。当知识规模达到百万级文档、更新频率以小时计，就必须考虑索引维护成本、增量更新策略、多路检索的负载均衡等问题。
如果用户查询大多是简单的事实性提问，重排序和迭代检索带来的收益有限。如果查询包含多跳推理、条件筛选、时间相关约束，Graph RAG、Structured Knowledge Enhanced RAG、Iterative RAG 的价值就会凸显。
不同模型支持的上下文长度差异很大。在长上下文模型出现之前，上下文压缩和 Parent Document Retriever 是为了在有限窗口内塞入更多有效信息。如今不少模型支持超长上下文，但这不意味着可以无脑把所有检索结果都塞进去——过长且包含大量噪声的上下文仍然会稀释模型的注意力，影响生成质量。
每次检索、重排序、迭代都会增加端到端延迟和计算成本。Agentic RAG 虽然能力最强，但单次请求可能触发十几次模型调用。对于高并发、低延迟要求的在线服务，需要谨慎评估智能体的调用链条是否可收敛。
当知识库中同时包含不同密级的信息时，检索层必须与权限系统对接。需要在检索阶段就过滤掉当前用户无权访问的内容，而不是在生成后再做拦截——生成阶段模型可能已经“看到了”不该看到的信息。
RAG 系统的质量取决于检索质量与生成质量两个维度。需要建立包含检索命中率、上下文相关度、回答忠实度、用户满意度等指标的评估体系。没有量化评估的持续优化，RAG 系统很容易在“看起来能用”的状态下持续劣化。
RAG 的本质，是让大模型从“依赖自身记忆”走向“学会利用外部世界”。从 Naive RAG 到 Agentic RAG，16 种方案的演进，本质上是在回答同一个核心问题：如何让模型在正确的时间、以正确的方式、获取正确的信息？
对于 AI 应用开发者而言，理解 RAG 不应该停留在“检索增强生成”这六个字的翻译上，而是要建立一套完整的架构坐标系：知识从哪里来、如何被切分和索引、查询如何被理解和改写、检索结果如何被评估和排序、上下文如何被组装和控制、模型如何被引导去使用这些信息、以及整个系统如何被评估和迭代。
当你能清晰地回答这些问题时，面对任何一个新的 RAG 概念或方案，你都能迅速判断它是在哪个环节、解决了什么问题、是否值得引入。这才是从“背名词”到“懂架构”的关键跨越。