简介：本文系统梳理 RAG（检索增强生成）的定义、产生背景、核心组成与工作流程，并扩展讲解从基础 RAG 到模块化、图结构、Agentic RAG 等 16 种主流演进方案。通过对比不同方案的特点、适用场景与选型注意事项，帮助开发者建立完整的技术判断框架，避免在 AI 应用开发中只停留在“检索增强生成”六个字的表面理解。
在近两年的 AI 应用开发中，RAG（Retrieval-Augmented Generation，检索增强生成）已经成为高频出现的技术名词。然而，不少开发者对它的理解仍然停留在“检索 + 生成”的粗略印象上，一旦被追问“检索阶段怎么设计”“如何降低幻觉”“与传统问答系统有什么区别”，往往难以给出系统回答。
本文尝试对 RAG 做一个全景式梳理：先给出它作为技术概念的准确定义，再说明它出现的原因与价值，进而拆解其核心组成和运行机制。之后，文章会对目前行业中常见的 16 种 RAG 方案进行分类讲解，其中既包括最基础的 Naive RAG，也包括当前更受关注的模块化 RAG、图 RAG 与 Agentic RAG。最后，本文会讨论在系统选型、性能优化和工程落地时需要关注的关键问题。
RAG，即检索增强生成，是一种将“信息检索”与“大语言模型生成”结合起来的技术架构。它的核心思想是：在大语言模型生成答案之前，先从外部知识库或文档集合中检索与用户问题相关的信息片段，再把这些片段作为上下文提供给模型，让模型基于这些相对可信的材料进行回答。
这个定义可以从三个视角进一步理解。
从技术流程视角看，RAG 是在模型输入层面增加了一个“证据提供”环节。它不是让模型只依赖参数中记忆的知识，而是允许模型在推理时访问外部信息。
从应用目的视角看，RAG 主要用于提升生成内容的可信度、时效性和可追溯性。当企业希望模型回答来自内部文档、最新政策、产品手册或特定领域资料时，仅靠模型预训练阶段学到的东西往往不够，RAG 提供了一种动态补充知识的机制。
从系统架构视角看，RAG 并不是一个单一算法，而是一套由索引构建、查询编码、相似度检索、上下文拼接和生成控制等多个环节组成的工程系统。不同实现方案之间的差异，也主要集中在这几个环节的设计选择上。
因此，RAG 的核心定义可以概括为：通过外部知识检索来增强语言模型生成能力的一种架构模式。它解决的不是“模型会不会说话”的问题，而是“模型是否能基于给定材料说对、说准、说新”的问题。
在 RAG 广泛流行之前，大语言模型本身的局限已经逐渐显现，突出的问题包括：
RAG 的出现提供了一条更轻量的路径：不修改模型权重，而是通过外部检索动态提供相关信息。与传统的关键词搜索不同，RAG 使用语义检索，可以在用户问题与文档片段之间建立更灵活的匹配关系；与纯生成式问答不同，RAG 的答案基于实际检索到的材料，天然具备一定的可追溯性。
更重要的是，RAG 将“知识更新”从“重新训练模型”转变为“更新知识库和索引”，这大幅降低了企业接入私有知识的门槛。对于大多数希望快速搭建知识问答、文档助手、客服辅助等应用的团队来说，RAG 是一种工程上更务实的选择。
一个典型的 RAG 系统由以下几个模块组成：
数据源可以包括 PDF、Word、Markdown、网页、数据库记录或工单内容。文档加载模块负责读取这些不同格式的数据，并将其规范化成后续可处理的纯文本或结构化文本。
由于检索通常以片段为单位，而长文档很难被一次性精确匹配，因此需要对文本进行切分。分块大小、是否保留标题层级、是否按语义边界切分，都会显著影响后续检索质量。
文本块需要转换为向量表示才能进行语义相似度计算。嵌入模型将每个文本块映射为高维空间中的向量，使得语义相近的内容在向量空间中距离更近。
大量文本块向量需要被高效组织和检索。向量数据库或支持向量检索的存储系统负责建立索引，并在查询阶段返回最相似的候选片段。
用户问题同样需要经过嵌入模型转换为查询向量。系统利用该向量在索引中执行相似度搜索，返回 top-k 个相关文本块。此阶段还会涉及召回策略、重排序、相似度阈值过滤等细节。
检索到的文本块会被拼接到提示词中，并与用户原始问题一起传递给大语言模型。模型基于这些上下文生成最终回答。提示词中通常还会要求模型在无法依据材料回答时明确说明，以降低幻觉。
一个简化的示意性流程可以用伪代码表示：
question = 用户输入query_vector = embed(question)candidates = vector_index.search(query_vector, top_k=8)reranked = reranker.rerank(question, candidates)context = concat(reranked)answer = llm.generate(prompt(question, context))
这个流程虽然简单，但它已经涵盖了 RAG 系统中最基本的“索引—检索—生成”三阶段结构。
RAG 的有效性并非仅仅因为“给模型多塞了几段文字”，而是因为它从三个层面改变了生成行为。
当模型接收到明确的上下文材料时，生成过程会更倾向于使用这些材料中的事实和表述。这相当于在解码阶段施加了隐式约束，减少了模型自由发挥造成的事实漂移。
向量检索将用户问题与知识库内容映射到同一语义空间。即使问题措辞与原文差异较大，只要语义接近，相关片段也可能被找到。这一能力是传统关键词匹配难以提供的。
工程上可以在提示词中要求模型只根据给定材料回答，并在必要时标注来源。虽然模型并不总是严格遵循，但合理的提示设计可以显著提高回答的忠实度和可验证性。
值得注意的是，RAG 并不会“消除”幻觉，而是通过引入外部证据来降低幻觉概率。在某些情况下，如果检索结果本身质量差，或者模型过度信任错误材料，反而可能产生新的错误。因此，检索质量是 RAG 系统性能的决定性因素之一。
行业中对 RAG 方案的划分并没有绝对统一的标准，但可以根据架构复杂度和智能程度，将其归纳为以下几个阶段和类型。以下方案并非互斥，而是常常组合使用。
最直接的实现：文档分块 → 嵌入 → 向量检索 → 拼接上下文 → 生成。优点是实现简单、容易上手；缺点是检索结果噪声大、上下文长度控制差，建议仅用于原型验证。
在语义检索基础上加入关键词检索作为补充。对于包含专有名词、编号、产品型号的问题，关键词匹配往往比纯向量相似度更可靠。两者结果可以通过融合策略合并。
系统同时执行向量检索和全文检索，再使用融合排序算法综合两者结果。这种方案在大多数企业知识库场景中都能获得更稳定的召回表现。
将文档以较小粒度分块用于检索，但在生成阶段返回其所属的更大段落作为上下文。这样既能提高检索精度，又能保留更多上下文信息。
以句子为基本检索单元，命中后向外扩展一定窗口的文本作为上下文。适合需要精确定位信息、同时要求阅读流畅性的场景。
为同一文本块生成多个表示形式，例如摘要、标题、关键词或问题式表示，并在检索时同时匹配。这种做法可以显著提升用户自然语言问题与文档内容之间的匹配度。
先对文档进行上下文感知的嵌入计算，再进行分块与索引。相比先分块再嵌入，这种方法能让每个片段在嵌入时携带更多文档级语义。
将文档中的实体、关系和事件抽取出来构建知识图谱，在检索阶段不仅返回文本片段，还返回与问题相关的结构化关系路径。适合处理多跳推理和复杂关联问题。
在向量检索返回候选集之后，引入重排序模型对候选片段进行精排。该模型通常更善于判断问题与片段之间的语义相关性，是当前提升检索质量最常用的手段之一。
在检索之前对用户问题进行改写、扩展或拆解。例如将口语化问题改写成更适合检索的短句，或将复杂问题拆分为多个子问题分别检索后合并。
模型在生成答案后，对答案是否得到材料支撑进行自我评估。如果发现证据不足，可以触发补充检索或重新生成。适合对答案可靠性要求较高的场景。
在生成过程中，如果发现检索结果质量不满足预设标准，系统主动进行二次检索、改写查询或调整检索策略，然后再继续生成。它与 Self-Reflective RAG 的区别在于，纠正行为发生在生成前或生成中，而非仅在生成后检查。
将 RAG 系统拆分为独立模块，例如索引模块、检索模块、重排模块、记忆模块、路由模块等。各模块可以独立替换和升级，便于在复杂业务中灵活编排。
系统在入口处根据问题类型选择不同的检索路径。例如，事实型问题走向量检索，统计型问题走结构化查询，实时问题走新闻或动态数据源。路由质量直接影响整体效果。
在多轮对话场景中维护用户记忆和任务状态，让检索过程能够利用历史上下文。它能避免每轮对话都从零开始检索，并支持更自然的延续性问答。
这是当前演进的前沿方向。系统不再按固定流程执行“检索—生成”，而是由智能体动态规划路径：先判断是否需要检索，再决定检索什么、如何检索、是否需要多步推理、是否调用外部工具、是否对结果进行验证。Agentic RAG 可以组合上述多种方案，依据任务复杂度自适应调整策略。
从 Naive RAG 到 Agentic RAG，整体趋势是从静态流水线走向动态决策系统。但复杂度提升也意味着开发成本、调试难度和不可控性的增加。
RAG 的适用场景非常广泛，核心特征是“外部知识相对明确、用户需要基于这些知识获得准确回答”。常见场景包括：
在这些场景中，RAG 的价值不仅体现在回答生成上，更体现在“让模型有据可依”。
微调通过修改模型权重让模型掌握新知识，通常需要较多数据和计算资源，且更新周期长。RAG 不修改模型权重，只增加外部检索环节，更适合知识高频变化、数据规模大但标注成本高的场景。两者并不互斥，实践中可以结合使用。
搜索引擎返回的是文档列表，用户需要自行阅读和判断；RAG 返回的是基于文档生成的完整回答。搜索引擎的检索单元通常是整篇文档，RAG 的检索单元往往是更细粒度的文本片段。
知识图谱问答依赖结构化三元组进行推理，准确性高但构建成本高。RAG 可以直接使用非结构化文本，适用范围更广。Graph RAG 则可以看作两者的融合，既保留文本覆盖度，又引入结构化关系推理能力。
长上下文模型可以直接把大量文档放入上下文窗口，而 RAG 则先检索出最相关片段。前者在上下文窗口极大且文档总量不大时使用方便，后者在文档量巨大、动态更新频繁时更具工程优势。
在落地 RAG 系统时，以下问题需要特别关注：
分块不是简单按字符数切割。块太大可能降低检索精度，块太小可能丢失必要上下文。需要结合文档结构、问题类型和目标生成长度综合设计。
如果检索阶段无法返回有效片段，再强大的生成模型也无法给出正确回答。应重点关注嵌入模型选择、索引参数、召回数量、重排序策略和相似度阈值。
向模型传递过多检索结果会带来更高延迟和更多消耗。应根据任务复杂度控制上下文长度，避免冗余信息稀释关键内容。
知识库更新后，索引必须同步更新。对于实时性要求高的场景，需要设计增量索引、失效检测和重新嵌入机制。
不同用户可能拥有不同文档访问权限。RAG 系统在索引和检索阶段都需要考虑权限过滤，避免越权访问。
需要建立检索命中率、答案忠实度、用户满意度等指标，并对每次问答过程中的检索来源进行记录，便于问题回溯和持续优化。
Agentic RAG、Graph RAG 等高级方案在特定任务中表现突出，但工程复杂度显著增加。对于数据规模较小、问题类型集中的场景，基础或混合方案往往更具性价比。
RAG 是一种通过引入外部知识检索来增强语言模型生成能力的架构模式。它的核心价值不在于替代模型推理，而在于为生成过程提供动态、可更新、可追溯的证据支撑。
从 Naive RAG 到 Agentic RAG，这一技术体系经历了从简单静态流水线到智能动态决策的演进。不同方案分别针对检索精度、语义匹配、上下文构建、多轮记忆和自主规划等问题提出优化思路。对于开发者而言，更重要的是根据实际业务的数据规模、问题复杂度、延迟要求和运维能力，选择适合的工程组合，而不是盲目追求方案数量或架构复杂度。
理解 RAG 的本质，是理解“外部知识如何被有效组织、定位并注入生成过程”。只有把这个核心问题想清楚，才能在 AI 应用开发中做出真正可靠的系统设计。