RAG 进入 2.0 时代：从传统 RAG 到 Agentic RAG——检索增强生成的新范式

从传统 RAG 到 Agentic RAG：检索增强生成的新范式

大语言模型擅长组织语言，却无法天然掌握企业私有数据，也无法保证参数中的知识始终准确、及时。RAG（Retrieval-Augmented Generation，检索增强生成）的核心价值，就是在生成答案之前引入外部知识，让模型尽可能"有据可依"。

传统 RAG 通常被概括为：

用户问题 → 向量化 → 检索 Top-K 文本块 → 拼接上下文 → LLM 生成答案

这条链路简单、实用，但它只回答了一个问题：如何找到与问题相似的文本？

当任务变成跨文档归纳、关系分析、检索纠错、多步研究或图表理解时，仅靠一次向量检索就不够了。GraphRAG、RAPTOR、Self-RAG、CRAG、Adaptive RAG、Agentic RAG 和 Multimodal RAG，正是在索引结构、检索策略、结果校验和流程控制等不同位置上扩展了传统 RAG。

这些名称并不是互斥的"产品型号"，而是不同层面的能力。一个生产系统完全可以同时使用混合检索、重排、GraphRAG、纠错分支和 Agent 调度。

1. 先重新认识传统 RAG

严格来说，RAG 最初的论文描述的是把参数化语言模型与可检索的非参数记忆结合起来；今天工程语境中的 RAG 已经更加宽泛，通常包含离线索引和在线问答两条链路。

1.1 离线索引

原始文档
  → 解析与清洗
  → 分块（Chunking）
  → 补充标题、时间、权限等元数据
  → 生成向量 / 建立关键词索引
  → 写入检索系统

1.2 在线问答

用户问题
  → 查询改写
  → 召回候选内容
  → 重排与过滤
  → 组装上下文
  → LLM 生成答案与引用

很多所谓的 RAG 问题，其实并不出在模型，而是出在更前面的环节：

• 文档解析丢失了表格、标题层级或页面关系；
• Chunk 太小导致语义不完整，太大又引入过多噪声；
• 向量检索擅长语义相似，却可能漏掉产品编号、报错码和人名；
• Top-K 只返回几个局部片段，无法覆盖整个数据集；
• 检索到了内容，但内容与问题无关、已经过期，甚至彼此冲突；
• 系统把检索结果直接交给 LLM，没有引用、拒答或质量评估机制。

因此，"升级 RAG"通常不是先换一个更大的模型，而是先定位失败发生在解析、召回、排序、上下文还是生成阶段。

2. 新型 RAG 到底"新"在哪里

技术路线	主要改变	适合解决的问题	主要代价
Advanced / Hybrid RAG	查询改写、关键词与向量混合召回、重排	通用企业知识库、客服问答	链路和调参更复杂
RAPTOR / Hierarchical RAG	对文档递归聚类并生成多层摘要	长文档、多层级语义问题	建索引成本、摘要误差
GraphRAG	抽取实体与关系，构建图和社区摘要	跨文档关系、全局主题分析	索引成本高，图质量难评估
Self-RAG	让经过训练的模型按需检索并自我批判	需要动态检索与证据判断的生成	通常需要专门训练或适配
CRAG	评估召回质量，并在失败时纠正或回退	检索结果不稳定的问答	增加评估、外部检索成本
Adaptive RAG	按问题复杂度选择不检索、单次或迭代检索	查询难度差异大、成本敏感	路由错误会放大下游问题
Agentic RAG	Agent 规划、拆解任务并多轮调用数据源	多来源、开放式复杂任务	延迟、成本和安全风险更高
Multimodal RAG	联合检索文本、图片、表格、版面等信息	PDF、图表、扫描件、工业文档	模型与存储开销更大

其中，Advanced / Hybrid RAG 往往是最值得先做的基础升级；其余方案应针对已经被评测集证明的具体瓶颈，而不是全部堆进系统。

3. Advanced / Hybrid RAG：先把"检索"做好

只使用向量召回时，系统容易找到语义接近的内容，却可能漏掉精确标识符。例如，用户查询 ERR_CONN_RESET、SKU-4821-A 或某个姓名时，关键词检索通常比纯向量检索更可靠。

混合检索会并行执行两类搜索：

• 稀疏检索：例如 BM25，擅长关键词、专有名词和精确匹配；
• 稠密检索：基于 Embedding，擅长同义表达和语义相似。

两路结果可以通过 RRF（Reciprocal Rank Fusion）等方法合并，再由 Reranker 对候选内容做第二次精排。Azure AI Search 的混合检索说明也采用了"全文检索 + 向量检索 + RRF 融合"的思路。

                     ┌→ BM25 关键词召回 ─┐
用户问题 → 查询改写 ─┤                   ├→ 结果融合 → Rerank → 生成
                     └→ 向量语义召回 ───┘

在生产环境中，这一层还常常包括：

1. 为模糊问题补全上下文，或把一个复杂问题拆成多个子查询；
2. 使用标题、时间、租户和访问权限做元数据过滤；
3. 对候选 Chunk 去重、扩展相邻段落，再进行重排；
4. 要求答案提供引用；证据不足时明确拒答。

这类改造没有 Graph 或 Agent 那么醒目，却通常能以更低的成本解决大部分知识库问答问题。

4. GraphRAG：从相似文本走向实体、关系与全局结构

考虑这样一个问题：

分析过去一年的所有项目会议记录，总结延期的主要原因，并说明涉及哪些团队及其相互依赖。

答案可能散落在几百份文档中。一次 Top-K 检索只能拿回少量与"项目延期"相似的片段，很难覆盖整个语料库，更难还原团队、项目、事件和原因之间的关系。

以微软开源的 GraphRAG 为例，索引阶段大致会执行：

文档 → TextUnit
     → 抽取实体、关系和关键声明
     → 构建知识图谱
     → 对图进行层次化社区聚类
     → 为每个社区生成摘要报告

查询时则可以按问题类型选择不同策略：

• Local Search：围绕具体实体及其邻居搜索，同时结合原始文本块；
• Global Search：对社区报告执行 Map-Reduce，回答"整个数据集的主要主题是什么"一类全局问题；
• DRIFT Search：用社区信息拓宽局部搜索，并生成更具体的后续问题；
• Basic Search：对适合普通 Top-K 的问题继续使用基础向量 RAG。

这也说明 GraphRAG 并不是"用知识图谱完全替代文本检索"，而是为不同问题增加结构化的检索路径。具体查询方式可参考微软的 GraphRAG Query Engine 文档。

GraphRAG 的代价同样明显：实体和关系抽取需要额外模型调用，社区摘要必须随数据更新，错误关系还可能沿图传播。微软在 Dynamic Community Selection 的实验中报告：在 AP News 数据集的 50 个全局问题上，限定相同搜索深度时，平均 Token 成本相对静态 Global Search 下降约 77%，回答质量相近；但搜索到更深层级时，总成本也可能反而上升。因此，这个数字应理解为特定实验条件下的结果，而不是通用承诺。详见微软研究博客。

5. RAPTOR：给长文档建立"语义目录树"

GraphRAG 强调实体和关系，RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）则强调不同抽象层级的语义。

它会对原始 Chunk 递归执行嵌入、聚类和摘要，最终形成一棵树：

                   全局摘要
                 /          \
            主题摘要 A      主题摘要 B
             /     \         /     \
          章节块   章节块   章节块   章节块

查询时，系统既能检索底层原文，也能命中高层摘要，因此更适合长报告、书籍、论文集等需要跨章节理解的内容。RAPTOR 论文在 ICLR 2024 发表，方法细节见论文页面。

可以这样区分两者：

• 关心"谁与谁有什么关系"，优先考虑 GraphRAG；
• 关心"长文档在不同粒度上讲了什么"，优先考虑 RAPTOR；
• 两者都依赖生成式摘要，因此最终答案仍应回溯到原始证据，而不是只引用摘要。

6. Self-RAG 与 CRAG：不要盲目信任检索结果

传统流水线通常默认"检索到的内容可以直接使用"。现实中，Top-K 结果可能无关、过期或相互矛盾；如果模型仍然被要求回答，就会基于错误上下文生成一个看似可信的结论。

Self-RAG 和 CRAG 都试图处理这个问题，但它们不是同一种方案。

6.1 Self-RAG：把检索与反思教给模型

Self-RAG训练模型生成特殊的 Reflection Tokens，使其能够学习：

• 当前步骤是否需要检索；
• 检索到的段落是否相关；
• 生成内容是否得到证据支持；
• 当前回答整体上是否有用。

它的关键点是经过训练的模型使用反思标记控制检索和生成。在普通工作流中增加一句"请检查答案"可以实现类似的产品行为，但严格来说并不等同于 Self-RAG 原论文的方法。

6.2 CRAG：在流水线中加入纠错分支

CRAG（Corrective Retrieval-Augmented Generation）更像一个可插入现有 RAG 的工程模块：

Query → Retrieve → Retrieval Evaluator
                         │
             ┌───────────┼───────────┐
             ↓           ↓           ↓
          Correct     Ambiguous    Incorrect
             │           │           │
          精炼内容    组合或补充     改写查询 /
             │        检索结果       Web Search
             └───────────┴───────────┘
                         ↓
                      Generate

CRAG 论文使用轻量级检索评估器判断文档质量，并在本地语料不足时引入 Web Search；同时通过"分解---重组"过滤文档中的无关片段。

两者的差异可以简化为：

• Self-RAG：重点在模型如何学习"按需检索和自我批判"；
• CRAG：重点在系统如何评估检索质量，并触发纠正动作。

它们能提高系统的鲁棒性，但不能自动保证事实正确。尤其在医疗、金融和法律等高风险场景中，仍需要可靠数据源、引用核验、权限控制和人工复核。

7. Adaptive RAG：不是每个问题都值得走最重的流程

"公司的报销截止日是哪天？"可能只需要一次检索；"比较三份合同的责任条款并指出冲突"则可能需要拆解问题和多轮搜索。

Adaptive RAG 会先判断问题复杂度，再选择不同策略：

简单问题 → 不检索，或直接回答
事实问题 → 单次检索
复杂问题 → 多步 / 迭代检索

Adaptive-RAG使用分类器在不检索、单步检索和迭代检索之间动态路由。实际系统不一定需要训练专门分类器，也可以从规则或小模型路由器开始。

它的价值在于控制平均延迟和成本；风险则是路由器一旦把复杂问题误判为简单问题，后续流程可能连检索机会都没有。因此路由本身也需要独立评测，并为低置信度结果设置回退策略。

8. Agentic RAG：把 RAG 变成 Agent 的一项能力

传统 RAG 的流程主要由开发者预先固定；Agentic RAG 则让 Agent 根据目标决定去哪里查、查几次，以及下一步做什么。

用户目标
  → 任务拆解
  → 选择数据源或工具
  → 检索并评估证据
  → 信息不足？改写问题并继续检索
  → 汇总证据、生成结论与引用

例如，用户提出"分析最近一个月 iOS 用户流失率上升的原因"，Agent 可能执行：

1. 查询指标数据库，定位异常开始的时间；
2. 检索 Release Notes，寻找同期功能变更；
3. 查询客服工单，统计登录失败相关投诉；
4. 检索 Jira，寻找对应缺陷和修复进度；
5. 交叉验证时间线，输出结论、证据和不确定项。

此时，知识库检索只是 Agent 可以反复调用的工具之一。2025 年的 Agentic RAG 综述将常见能力概括为反思、规划、工具使用和多 Agent 协作。不过，多 Agent 并不是 Agentic RAG 的必要条件；如果单个 Agent 加确定性的工作流已经够用，引入更多 Agent 只会增加协调成本。

Agentic RAG 的主要风险包括：

• 多轮搜索带来的延迟和 Token 成本；
• 循环调用、错误规划和不可预测的停止条件；
• 外部网页或文档中的提示注入；
• Agent 越权访问数据或执行工具；
• 中间证据链缺乏可观测性，导致问题难以复现。

因此，生产系统需要限制工具权限、迭代次数和预算，并完整记录查询、召回结果、工具调用与引用来源。

9. Multimodal RAG：文档不只有文字

真实企业文档中，大量信息存在于表格、流程图、截图、页面布局和扫描件中。只做 OCR 再切文本，可能会破坏行列关系、图文对应关系和视觉层级。

多模态 RAG 常见有两条路线：

1. 解析后检索：分别抽取正文、表格、图片描述和元数据，再建立多个索引；
2. 视觉检索：直接对页面图像生成多向量表示，召回页面后交给视觉语言模型理解。

ColPali是第二条路线的代表工作之一，它使用视觉语言模型为文档页面生成多向量表示。对于年报、幻灯片、技术手册和扫描 PDF，这类方法能够保留比纯文本管线更多的版面信息，但也会增加索引体积、推理成本和权限审查难度。

10. 如何选择：从问题类型，而不是技术热度出发

主要问题	建议先尝试
通用知识库问答召回不准	优化解析与 Chunk，再做 Hybrid Search + Rerank
产品编号、错误码、人名经常漏召回	BM25 + 向量混合检索
需要跨章节理解一份或少量长文档	RAPTOR / Hierarchical RAG
需要分析大量文档的主题、实体和关系	GraphRAG
检索结果质量波动大，需要失败回退	CRAG 或确定性的检索评估工作流
查询难度差异大，简单问题不想付出高成本	Adaptive RAG
任务要跨知识库、数据库、Web 和 API	Agentic RAG
答案依赖表格、图片和页面布局	Multimodal RAG

一条更稳妥的演进路线通常是：

可靠的文档解析
  → 混合召回
  → Rerank
  → 引用与拒答
  → 离线评测集
  → 根据失败案例引入 Graph / Corrective / Adaptive / Agentic 能力

11. 上线前应该评估什么

只看"最终回答像不像人话"远远不够。RAG 至少要分层评估：

• 检索层：Recall@K、MRR、nDCG，以及关键证据是否被召回；
• 生成层：答案是否正确、是否忠于上下文、引用能否支持对应结论；
• 系统层：P95 延迟、Token 成本、索引成本、数据新鲜度、拒答率；
• 业务层：任务完成率、人工接管率、用户反馈和高风险错误率。

RAGAS等框架可以帮助自动化评估上下文相关性、忠实度和回答质量，但 LLM 评审本身也会产生偏差。关键场景仍应维护一套由人工审核、覆盖真实问题分布的测试集。

结语

传统 RAG 解决的是"给 LLM 找几段相关资料"；新一代 RAG 进一步回答：

• 什么时候需要检索？
• 应该去哪里检索？
• 应该使用文本、图、表格，还是外部工具？
• 检索结果是否相关、可信和完整？
• 不同证据之间有什么关系？
• 信息不足时，下一步应该查什么？

RAG 正逐渐从"向量数据库前面的一个问答流程"，演变为 AI 系统中的 Knowledge / Retrieval Layer。真正成熟的方案并不是组件最多的方案，而是能够用最简单、可评估、可追溯的架构稳定解决目标问题。

参考资料

1. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.
2. Gao et al., Retrieval-Augmented Generation for Large Language Models: A Survey.
3. Microsoft, GraphRAG Documentation.
4. Sarthi et al., RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, ICLR 2024.
5. Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, ICLR 2024.
6. Yan et al., Corrective Retrieval Augmented Generation, 2024.
7. Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity, NAACL 2024.
8. Faysse et al., ColPali: Efficient Document Retrieval with Vision Language Models, ICLR 2025.
9. Singh et al., Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG, 2025.
10. Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL 2024.