第 5 章 · 高级 RAG 模式：Self-RAG、CRAG、GraphRAG、Agentic RAG

🎯 本章目标：理解学术界和工业界最前沿的 RAG 演进方向，能在面试和技术分享中讲清每种模式的"为什么"、"怎么做"、"什么时候用"。

💡 本章重要性：基础 RAG 大家都会做，高级 RAG 是技术领先和差异化的关键。也是高级岗位面试的高频考点。

---

目录

1. RAG 范式演进路线图
2. Self-RAG：会反思的 RAG
3. CRAG：会自我纠正的 RAG
4. GraphRAG：基于知识图谱的 RAG
5. Agentic RAG：能动的 RAG
6. Modular RAG：模块化架构
7. 对比与选型
8. 思考题

---

1. RAG 范式演进路线图

1.1 三代 RAG 简要对比

代际	时期	特点	代表
第一代 Naive RAG	2020-2022	朴素：检索 → 拼接 → 生成	原始 RAG 论文
第二代 Advanced RAG	2022-2023	优化：查询改写、Rerank、混合检索	LangChain/LlamaIndex 标准模式
第三代 Modular & Agentic	2023-至今	模块化、自反思、动态决策	Self-RAG、CRAG、GraphRAG、Agentic RAG

---

2. Self-RAG：会反思的 RAG

📄 论文：Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection（2023）

2.1 解决的痛点

普通 RAG 的"二傻"行为

用户问：「中国的首都是?」
普通 RAG：去知识库检索 → 找出 "中国位于亚洲" "中国人口很多" → 拼起来回答 "中国是亚洲国家，人口很多..."

问题：根本不需要检索的简单问题，也去检索；检索到的内容不一定相关，但还是硬塞。

Self-RAG 的智能化

模型自己判断：

1. 要不要检索？（简单问题直接答）
2. 检索到的内容相关吗？（不相关就丢掉）
3. 我生成的答案是否得到了检索内容的支持？（没支持就重新生成或检索）

2.2 核心机制：反思 Token

Self-RAG 训练时在生成过程中插入特殊 Token（叫"反思 Token"）：

Token	含义	取值
[Retrieve]	是否需要检索？	Yes / No / Continue
[IsRel]	检索的文档是否相关？	Relevant / Irrelevant
[IsSup]	生成内容是否被文档支持？	Fully / Partially / No
[IsUse]	生成内容是否有用？	1-5 分

2.3 Self-RAG 工作流程

2.4 生活类比

Self-RAG 像一个有自我审视习惯的优秀员工：

1. 接到任务先想：这个问题我直接能答吗？（不能就查资料）
2. 查到资料后审视：这资料和问题真的相关吗？（不相关就丢掉）
3. 写完答案后回看：我写的内容是不是基于资料？有没有瞎编？（瞎编就重写）
4. 提交前自评：我这个答案对用户有用吗？（不够好就再改）

2.5 优缺点

优点	缺点
✅ 大幅降低幻觉	❌ 需要专门训练带反思 Token 的模型（成本高）
✅ 节省调用（简单问题不检索）	❌ 多次反思 = 多次 LLM 调用，延迟增加
✅ 召回质量自动把关	❌ 实现复杂度高
✅ 答案有据可查	❌ 工业界落地少（多用近似版）

2.6 工业界简化版

由于训练 Self-RAG 模型成本高，工业界常用简化版：

用普通 LLM（如 GPT-4），通过 Prompt 让它做以下判断：
  1. "这个问题需要外部知识吗?" (Yes/No)
  2. 检索后追加 Prompt: "以下文档和问题相关吗?" (打分 1-10)
  3. 生成后追加 Prompt: "你的回答是否完全基于上面的文档?"

💡 用 LLM 模拟 Self-RAG 的思路，是当前生产环境的主流落地方式。

---

3. CRAG：会自我纠正的 RAG

📄 论文：Corrective Retrieval Augmented Generation（2024）

3.1 解决的痛点

用户问：「2024 年欧洲杯冠军是?」
检索：知识库里只有 2020 年欧洲杯的数据（信息过时）
普通 RAG：硬答 "意大利" ← 严重错误!

CRAG 的核心：当检索质量差时，主动 fallback 到其他信息源（比如 Web 搜索）。

3.2 CRAG 的核心：检索评估器

CRAG 引入一个轻量级评估模型（Retrieval Evaluator），给检索结果打分：

评分	含义	后续动作
Correct	检索质量高，包含正确信息	直接用，生成回答
Incorrect	检索质量差，信息缺失/过时	Web 搜索 + 用搜索结果回答
Ambiguous	部分相关但不完整	知识精炼 + Web 搜索补充

3.3 CRAG 工作流程

3.4 知识精炼（Knowledge Refinement）

CRAG 的另一个特色：分解 + 过滤

原 Chunk: "猫咪发烧的处理方法包括降温、补水、送医。
          此外，猫咪还需要定期接种疫苗，注意饮食卫生。"

分解为 Strip:
  - "猫咪发烧的处理方法包括降温"
  - "猫咪发烧的处理方法包括补水"
  - "猫咪发烧的处理方法包括送医"
  - "猫咪需要定期接种疫苗"     ← 与查询无关
  - "注意饮食卫生"             ← 与查询无关

打分过滤后保留：
  - "猫咪发烧的处理方法包括降温、补水、送医"

💡 效果：去掉无关内容，提升 Context 信息密度。

3.5 生活类比

CRAG 像一个严谨的研究员：

1. 接到问题先查内部资料库（知识库）
2. 评估："我手头资料够吗?"
   • 够 → 整理内部资料回答
   • 不够 → "我得查查最新论文/Google 一下"
   • 半够 → "内部资料 + 网上搜，综合分析"

3.6 优缺点

优点	缺点
✅ 解决"知识库不完整"问题	❌ 需要 Web 搜索 API（成本）
✅ 减少过时信息导致的幻觉	❌ 评估器质量影响整体效果
✅ 知识精炼降低 Context 噪声	❌ 流程复杂
✅ 工程上比 Self-RAG 简单	❌ 引入外部依赖（网络）

3.7 工业级落地建议

最小实现：
  1. 用一个 Reranker（如 BGE-Reranker）当评估器
  2. 设置阈值（如 score < 0.5 视为 Incorrect）
  3. 接入 Tavily / SerpAPI / Bing API 作为 Web 搜索
  4. Web 搜索结果二次处理后送 LLM

---

4. GraphRAG：基于知识图谱的 RAG

📄 论文：From Local to Global: A Graph RAG Approach to Query-Focused Summarization（微软，2024）

4.1 解决的痛点

普通 RAG 的"局部视野"问题

查询："这本小说中谁影响了主角最大?"

普通 RAG：检索"主角"相关的片段
  → 召回到"主角去了餐厅" "主角和导师吵架" "主角的母亲打电话"
  → LLM 基于零散片段答："母亲" 或 "导师"，但都不全面

问题：普通 RAG 看不到"全局关系"，无法回答需要跨文档汇总的问题。

4.2 GraphRAG 的核心思路

把文档变成知识图谱（实体 + 关系），检索时不只检索文档，还检索图谱结构。

4.3 工作流程

4.4 关键创新点

创新 1：实体抽取 + 关系构建

原文：「鲁迅在 1936 年于上海去世，他的妻子是许广平。」

LLM 抽取实体：
  - 鲁迅 (Person)
  - 上海 (Location)
  - 许广平 (Person)
  - 1936 (Date)

LLM 抽取关系：
  - (鲁迅) --[死亡地点]--> (上海)
  - (鲁迅) --[死亡时间]--> (1936)
  - (鲁迅) --[妻子]--> (许广平)

→ 存入知识图谱

创新 2：社区检测（Community Detection）

把图谱按"高度连接"的部分分组：

社区 1（文学社区）: 鲁迅, 许广平, 周作人, 林语堂...
社区 2（政治社区）: 蒋介石, 宋美龄, 汪精卫...
社区 3（科学社区）: 钱学森, 钱三强, 邓稼先...

创新 3：双层检索

查询类型	检索方式	例子
Local Query（具体）	直接查实体邻居	"鲁迅的妻子是谁?" → 查鲁迅节点的 "妻子" 关系
Global Query（汇总）	查社区摘要	"中国近代文学家有哪些贡献?" → 查文学社区摘要

4.5 生活类比

GraphRAG 像一个有家谱树的家族：

• 普通 RAG：「问鲁迅是谁，翻一本本相册（文档），找鲁迅的照片」
• GraphRAG：「有家谱树（图谱），不仅找到鲁迅，还知道他的兄弟（周作人）、妻子（许广平）、学生（萧军）等。问家族贡献，可以看家谱整体描述。」

4.6 优缺点

优点	缺点
✅ 能回答跨文档的全局问题	❌ 构建成本极高（每个文档都要跑 LLM 抽取）
✅ 支持复杂关系推理	❌ 知识图谱质量受 LLM 抽取能力限制
✅ 适合知识密集型领域	❌ 工程复杂（需要图数据库）
✅ 可解释性强	❌ 增量更新困难

4.7 适用场景

适合	不适合
✅ 历史/小说/复杂关系网	❌ FAQ 类问答
✅ 学术文献综述	❌ 简单事实查询
✅ 企业组织架构、产品关系	❌ 实时性要求高的场景
✅ 客户关系（CRM）	❌ 预算有限的小项目

4.8 相关工具

工具	说明
microsoft/graphrag	微软开源实现
LlamaIndex Knowledge Graph	简化版集成
Neo4j	主流图数据库
NebulaGraph	国产开源图数据库
LightRAG	香港大学，轻量级 GraphRAG

---

5. Agentic RAG：能动的 RAG

5.1 核心思想

把 RAG 变成一个 Agent（智能体），让它能自主决策：

• 要不要检索？
• 检索哪个知识库？
• 检索结果够不够？要不要再检索一次？
• 要不要调用其他工具（计算器、搜索、API）？
• 要不要分解任务？

5.2 Agentic RAG vs 普通 RAG

	普通 RAG	Agentic RAG
流程	固定流水线	动态决策
检索次数	1 次	1-N 次（按需）
数据源	单一向量库	多源（向量库、SQL、API、Web）
任务能力	只能回答	检索 + 计算 + 操作
类比	流水线工人	自主问题解决者

5.3 一个典型 Agentic RAG 工作流

5.4 关键能力

5.4.1 工具选择（Tool Selection）

Agent 决策：
  问题：「2024 年 Q3 利润同比增长多少?」
  → 这是数值查询 → 用 SQL 工具查数据库
  → 不是模糊问题 → 不用向量检索

  问题：「客户对新功能 X 的反馈如何?」
  → 模糊语义 → 用向量检索查客服日志
  → 需要汇总 → 多次检索 + 总结

5.4.2 多步骤推理（ReAct 模式）

Question: 比较产品 A 和产品 B 的退货率

Thought: 我需要分别查产品 A 和产品 B 的退货数据
Action: query_db(product="A", metric="return_rate")
Observation: 产品 A 退货率 5%

Thought: 现在查产品 B
Action: query_db(product="B", metric="return_rate")
Observation: 产品 B 退货率 8%

Thought: 已有数据，可以对比回答
Action: Final Answer
回答: 产品 B 退货率比产品 A 高 3 个百分点...

5.4.3 自我验证（Self-Verification）

Agent 生成答案后追加：
  "我的回答是否完整覆盖了用户问题?"
  "是否有数字/事实需要再次验证?"
  → 不放心就再查一次

5.5 生活类比

Agentic RAG 像一个全能的私人助理：

你说："帮我规划下周去东京旅游"

一个好的助理会：

1. 自己判断需要查哪些信息（机票、酒店、景点、天气、签证）
2. 调用不同工具（携程查机票、Booking 查酒店、Google 查景点）
3. 每查完一项评估："信息够了吗?"
4. 综合所有信息给你一个完整方案
5. 如果你说"预算 1 万"，会回头重新优化

而普通 RAG 只会：你问什么就去翻一次资料，告诉你"东京有很多景点"。

5.6 优缺点

优点	缺点
✅ 处理复杂任务	❌ 多次 LLM 调用，成本和延迟高
✅ 多源数据整合	❌ Agent 可能"绕圈"，不收敛
✅ 灵活适应不同问题	❌ 调试困难（黑盒决策）
✅ 接近"真人助理"体验	❌ 对 LLM 推理能力要求高

5.7 实现框架

框架	特点
LangGraph	LangChain 出品，图式 Agent 编排
LlamaIndex Agent	灵活的工具调用
AutoGen	多 Agent 协作
CrewAI	团队式 Agent 协作
Cursor / Claude Code	编程类 Agent 的事实标准

---

6. Modular RAG：模块化架构

6.1 思想

把 RAG 各个环节做成可插拔的模块，按需组合。

传统 RAG = 固定流水线
Modular RAG = 乐高积木，按场景拼装

6.2 模块清单

模块类别	具体模块
Indexing	加载器、切分器、Embedding
Pre-Retrieval	查询改写、扩展、路由、HyDE
Retrieval	向量、BM25、SQL、API、图谱
Post-Retrieval	Rerank、压缩、去重、过滤
Generation	LLM 选择、Prompt 模板
Post-Generation	引用、验证、格式化
Orchestration	流程编排、循环、分支

6.3 典型组合示例

场景 A：企业 FAQ

查询 → 关键词检索（BM25）→ Rerank → LLM 生成

简单粗暴够用。

场景 B：知识密集型问答

查询 → 查询改写 → 向量检索 + BM25 → RRF 融合 → Rerank → 压缩 → LLM

场景 C：实时数据 + 文档结合

查询 → 路由（实时数据走 SQL，文档走向量）→ 结果合并 → LLM

场景 D：复杂分析任务

查询 → 任务分解 → 多 Agent 并行检索 → 综合分析 → LLM 生成 → 验证

6.4 编排框架

框架	编排方式
LangChain LCEL	链式管道
LangGraph	状态机/图
LlamaIndex Pipeline	配置式
Haystack	YAML 配置
DSPy	声明式优化

---

7. 对比与选型

7.1 五种高级 RAG 对比

模式	核心解决	复杂度	成本	何时用
Self-RAG	幻觉、过度检索	⭐⭐⭐⭐	高（多次反思）	高准确度要求
CRAG	检索不准、信息过时	⭐⭐⭐	中（Web 搜索）	知识库不完整时
GraphRAG	全局/关系问题	⭐⭐⭐⭐⭐	极高（构图）	关系密集型领域
Agentic RAG	复杂多步任务	⭐⭐⭐⭐⭐	高（多次调用）	复杂分析 / 多源整合
Modular RAG	灵活性	⭐⭐⭐	中	几乎所有生产场景的设计原则

7.2 选型决策树

7.3 实战建议：组合使用

真实生产系统通常 组合多种模式：

最强组合 = Modular 架构 +
           查询改写 +
           混合检索 +
           Rerank +
           Self-RAG 风格反思（Prompt 实现）+
           按需 Agentic（复杂任务时启用）

7.4 不要过度设计的警示

⚠️ 常见误区：盲目追求"高级"，忽略基本功。

现实中：

• 80% 的场景：基础 RAG + Rerank 就能解决
• 15% 的场景：需要混合检索 + 查询改写
• 5% 的场景：才真正需要 GraphRAG / Agentic RAG

先把基础做好，再上高级。否则会陷入"为了用 GraphRAG 而用"的坑。

---

8. 思考题

1. Self-RAG 论文里说它能减少幻觉，原理是什么？

   参考答案

   核心机制：

   1. 按需检索：避免"明明不需要检索却检索"导致的噪声
   2. 相关性过滤（[IsRel]）：把不相关的检索结果丢掉，避免误导
   3. 支持性验证（[IsSup]）：生成后检查"我说的话是不是真有文档支撑"，不支持就重生成
   4. 有用性评分（[IsUse]）：低分回答触发重试

   本质：把"一锤子买卖"的 RAG 变成"有审视机制的多轮迭代"。

2. GraphRAG 构建图谱时，LLM 抽取实体/关系会有错误，怎么保证图谱质量？

   参考答案

   实践方法：

   • 多次抽取 + 投票：同一段文本跑 3 次 LLM 抽取，结果合并取众数
   • Schema 约束：预定义实体类型（Person、Location、Organization）和关系类型，让 LLM 按 Schema 抽
   • 置信度评分：每条关系附带置信度，低置信度的过滤
   • 后处理校验：用规则或小模型再校验一遍（比如"X 出生于 Y"中 Y 必须是地点）
   • 人工抽检：抽样审核 + 反馈训练
   • 增量更新：发现错误后手动修正图谱

3. Agentic RAG 一次任务可能调用 LLM 10 次以上，怎么控制成本和延迟?

   参考答案

   优化策略：

   • 小模型做决策：用 GPT-4o-mini 做"规划/判断"，只在最终生成用 GPT-4o
   • 并行执行：能并行的子任务并行（如同时查 3 个数据库）
   • 缓存：相同子查询的结果缓存
   • 早停：设置最大步数（如 5 步），防止无限循环
   • 状态管理：用 LangGraph 等显式状态机，避免 Agent 重复思考
   • 流式输出：边生成边返回，至少视觉上延迟低
   • 按需启用：简单问题走基础 RAG，复杂问题才走 Agentic（路由判断）

4. 如果让你给一个 100 人公司搭企业知识库，你会选哪些模式组合?

   参考答案

   建议组合（MVP → 进阶）：

   MVP 阶段（1-2 周上线）：

   • 模块化架构（LangChain LCEL）
   • 切分：递归字符 + Markdown Splitter
   • Embedding：BGE-M3
   • 向量库：Milvus 或 Qdrant
   • 检索：纯向量
   • LLM：GPT-4o-mini 或 DeepSeek

   进阶阶段（1-2 个月迭代）：

   • 加 BM25 → 混合检索
   • 加 BGE-Reranker
   • 加查询改写（处理多轮对话）
   • 加元数据过滤（部门 / 权限 / 时间）
   • 加引用追溯（让员工能查证）

   不建议：

   • 不建议一上来就 GraphRAG / Agentic RAG（复杂度高，多数 FAQ 用不上）
   • 不建议自己训练 Self-RAG（小公司没这个资源）

---

📌 本章小结

你应该已经知道	✅
RAG 三代演进（Naive → Advanced → Modular/Agentic）	□
Self-RAG 的反思机制和四个反思 Token	□
CRAG 的检索评估器和 Web fallback	□
GraphRAG 的图谱构建和双层检索	□
Agentic RAG 的工具调用和多步推理	□
Modular RAG 的模块化思想	□
各种模式的选型决策框架	□
"先做好基础再用高级"的工程哲学	□

---

🚀 下一步

学了这么多优化技术，怎么衡量"到底好不好"？下一章讲 RAG 评估：

👉 第 6 章 · RAG 评估与优化