学习笔记：详述 RAG 系统从 Naive 到 Agentic 的三代演进，Self-RAG、CRAG、GraphRAG、Agentic RAG 四大高级范式，以及幻觉的系统性防控策略
目录
- [三代 RAG 演进](#三代 RAG 演进)
- [Naive RAG](#Naive RAG)
- [Advanced RAG](#Advanced RAG)
- [Modular RAG](#Modular RAG)
- 为什么需要高级范式
- [朴素 RAG 的三大痛点](#朴素 RAG 的三大痛点)
- [Self-RAG：LLM 自主决策检索](#Self-RAG：LLM 自主决策检索)
- CRAG：检索质量差时自动纠错
- GraphRAG：知识图谱增强全局理解
- [Agentic RAG：把 RAG 做成 Agent](#Agentic RAG：把 RAG 做成 Agent)
- 四大范式对比
- [RAG 幻觉防控](#RAG 幻觉防控)
- 幻觉的本质与分类
- [方案一：Prompt 强约束](#方案一：Prompt 强约束)
- 方案二：检索质量门控
- 方案三：生成后引用核查
- 方案四：结构化输出强制溯源
- 四方案组合策略
- 幻觉评估工具
- 参考资料
三代 RAG 演进
Naive RAG
基础的"检索 + 生成"，逻辑直白，什么都没优化。用户提问 → 向量检索 → 拼接 chunk → LLM 生成。存在检索质量参差不齐、流程死板、知识库覆盖盲区等问题。
Advanced RAG
在检索前加 Query 改写和扩展，检索后加 Rerank 精排和内容压缩。工程改动小，效果明显，是当前大多数生产系统的选择。
Modular RAG
把各环节拆成可独立替换的模块，像乐高一样按需组合。LlamaIndex 的 Workflow 和 LangGraph 都是这个设计思路。
为什么需要高级范式
朴素 RAG 的三大痛点
| 痛点 | 描述 | 后果 |
|---|---|---|
| 检索质量参差不齐 | 系统不区分检索结果质量，一律喂给 LLM | 在低质量上下文上产生幻觉 |
| 流程太死板 | 所有问题走同一套流程 | 该省的没省，该深挖的浅尝辄止 |
| 知识库覆盖有盲区 | 找不到相关内容时，LLM 编造答案 | 返回错误或不相关回答 |
Advanced RAG 能缓解这些问题，但它们有个共同假设：流程是固定的，只是每个环节做得更好。真正复杂的场景需要流程本身能根据情况调整。
Self-RAG：LLM 自主决策检索
核心思想
解决「不是所有问题都需要检索」的问题。训练了一个特殊 LLM，使用四种 reflection token 让模型自主决定何时检索、检索结果是否相关、生成内容是否有用。
四种反思 Token
| Token | 含义 | 作用 |
|---|---|---|
| Retrieve | 当前问题需不需要检索？ | 不需要检索的问题直接生成，节省延迟 |
| Relevance | 检索回来的内容和问题相不相关？ | 不相关的 chunk 跳过，避免干扰 |
| Support | 生成的答案有没有文档支撑？ | 防止幻觉，答案必须有据可依 |
| Utility | 最终答案对用户有没有用？ | 保证回答质量 |
执行流程
前提条件
reflection token 需要在专门构造的数据集上对基础 LLM 进行监督微调，作为新词表的一部分训练进去。不能直接拿普通 GPT-4 套用，需要用论文开源的微调版本（基于 Llama2-7B/13B）或自己造数据微调。
CRAG：检索质量差时自动纠错
核心思想
解决「知识库覆盖有盲区」的问题。在检索后增加一个质量评估步骤，检索质量差时自动降级到网络搜索兜底。
三级路由决策
执行流程
- 本地检索：从知识库召回 top-K 个 chunk
- 质量评估：用轻量级评估器判断相关程度
- 三级路由：根据评估结果选择数据来源
- 知识精炼：对检索结果做分解-重组（Decompose → Recompose），提取关键信息
- 生成答案：基于最终上下文生成
核心价值：兜底------知识库覆盖不到的问题不会乱答，自动去网上找答案。判断阈值需根据业务场景调整。
GraphRAG：知识图谱增强全局理解
核心思想
解决「向量检索只能做局部匹配」的瓶颈。微软 2024 年发布的方案，利用知识图谱捕捉实体间的复杂关系，支持全局性问题的回答。
为什么向量检索搞不定全局性问题？ 向量检索本质是「一对一匹配」，擅长找局部片段，但无法理解宏观结构和跨文档关联。GraphRAG 通过预先构建社区摘要，把全局信息提前「蒸馏」好了。
预处理阶段
检索阶段：局部与全局
| 模式 | 适合问题类型 | 检索方式 |
|---|---|---|
| Local Search | 局部问题（如「A 公司的 CEO 是谁」） | 知识图谱中做实体查找和关系遍历 |
| Global Search | 全局问题（如「这些文档的主要主题有哪些」） | Map-Reduce：让 LLM 分别阅读各社区摘要提取信息，再汇总生成 |
适用场景
- 金融企业关系分析
- 医疗药物-疾病-症状关联查询
- 大规模文档集主题归纳
代价：构建知识图谱和社区摘要需大量 LLM 调用，预处理成本较高。
Agentic RAG：把 RAG 做成 Agent
核心思想
解决「复杂问题需要多轮动态检索」的问题。其他范式的流程步骤都是预先定义好的，而 Agentic RAG 由 LLM 根据中间结果动态决定下一步。
执行流程
适用场景
特别适合多步骤推理的复杂问题，如「分析某公司最近三年财报，找出营收增速放缓的根本原因」。
2025 热门框架：LangGraph、CrewAI、AutoGen、LlamaIndex Workflows。
四大范式对比
| 维度 | Naive RAG | Self-RAG | CRAG | GraphRAG | Agentic RAG |
|---|---|---|---|---|---|
| 复杂度 | 低 | 中 | 中 | 高 | 最高 |
| 检索质量控制 | 无 | 反思机制 | 纠正机制 | 结构化 | 自适应 |
| 多跳推理 | 无 | 有限 | 有限 | 强 | 强 |
| 全局理解 | 无 | 无 | 无 | 强 | 可实现 |
| 动态工具调用 | 无 | 无 | Web 搜索 | 无 | 任意工具 |
| 适用场景 | 简单 QA | 需要准确性 | 检索质量不稳定 | 关系复杂 | 复杂多步骤 |
四大范式解决的痛点：
| 范式 | 解决的痛点 | 核心机制 |
|---|---|---|
| Self-RAG | 不是所有问题都需要检索 | LLM 自主决策，四种反思 Token |
| CRAG | 检索质量差时怎么办 | 质量评估 + 三级路由，自动降级网络搜索 |
| GraphRAG | 全局理解和跨文档关联 | 社区发现 + 层次化摘要 |
| Agentic RAG | 复杂问题需要多轮动态检索 | Agent 决策循环，按需检索 |
RAG 幻觉防控
幻觉的本质与分类
LLM 幻觉的本质：模型在没有可靠依据时，会拼凑出"听起来合理"但可能错误的答案。很多人误以为做了 RAG 就不会幻觉，但实际上塞进去不等于 LLM 一定会老老实实照着说。
| 幻觉类型 | 描述 | 示例 |
|---|---|---|
| 检索层幻觉 | 向量检索未找到相关 chunk，LLM 用训练时的知识编造答案 | 知识库记录"7天退款"，检索未召回，LLM 回答"30天退款" |
| 生成层幻觉 | 相关 chunk 被召回，但 LLM 在资料基础上加入自己的推断 | LLM 将两段不相关信息混在一起拼凑"更完整"的答案 |
生成层幻觉更隐蔽也更常见------LLM 将资料内容作为基础，加入推断，读者难以分辨哪些来自文档、哪些是 LLM 添加的。
四个方案从"成本最低"到"机制最严格"依次递进：
方案一：Prompt 强约束
成本最低、最容易上手，效果立竿见影。
很多人搭 RAG 时只将 chunk 塞进 prompt 然后问"请回答这个问题"，未约束 LLM 行为。LLM 会认为资料只是参考，可结合自身知识一起回答，由此产生幻觉。
修复方法：在 system prompt 中明确规则：
回答规则：
1. 只能使用【参考资料】中的信息来回答，不得引入资料之外的知识
2. 如果参考资料中没有足够信息，必须明确回答：
「根据现有资料，无法回答该问题」
3. 回答时标注信息来源（来自哪条参考资料）
4. 不要推断、不要猜测、不要补充资料中没有明确说明的内容各规则的作用：
| 规则 | 意图 |
|---|---|
| 规则 1 | 让 LLM 知道自己"只是个传话人，不是百科全书" |
| 规则 2 | 给 LLM 一个"合法的逃生出口"，资料里没答案时允许优雅地承认不知道 |
| 规则 3 | 让 LLM 主动对照原文，增加自检动作 |
局限性：能压制生成层幻觉，但对检索层幻觉帮助有限。如果 prompt 中根本没相关内容，再强的约束也拦不住 LLM 瞎编。
方案二：检索质量门控
当检索失败、prompt 中全是无关内容时，与其让 LLM 强行生成可能错误的答案，不如直接告知用户知识库中无此信息。
流程 ：
阈值设定 ：没有通用数字，需按业务数据调。一般经验值在 0.3~0.6 之间：
| 场景 | 阈值倾向 | 原因 |
|---|---|---|
| 精度要求高（金融、医疗） | 偏高 | 答错代价大 |
| 召回率宽松（闲聊问答） | 偏低 | 容错空间大 |
| 起步 | 0.4~0.5 | 根据线上误判样例微调 |
核心理念：答错比不答更危险。"拒答"虽然看起来不那么智能，但至少不会给用户错误信息。
方案一 + 方案二的配合 ：方案二负责检索质量差时不让 LLM 胡说；方案一负责检索质量还行但 LLM 超发挥时将其框住。这两个是 RAG 系统上线前的基础配置，成本最低。
方案三：生成后引用核查
前两个方案是"生成之前"做防控，方案三是"生成之后"做校验。
思路：LLM 生成完答案后，再用另一个 LLM（或同一个 LLM）回头检查------答案里的每条关键信息，在 chunk 里有没有对应的依据。没有依据的内容，标注"无法核实"或直接删掉。
类比：方案一是事前约束作者行为，方案三是事后审稿。
代价：多一次 LLM 调用，响应延迟增加，成本翻倍。一般只在对准确性要求极高的场景使用（医疗问诊、法律咨询等答错代价很大的地方）。普通企业知识库问答，方案一+方案二通常够用。
方案四：结构化输出强制溯源
在格式层面做约束，与方案一的 Prompt 约束配合效果更好。让 LLM 输出结构化 JSON，每个结论必须填写来自哪条参考资料的编号。
输出格式示例：
json
{
"answer": "完整回答",
"statements": [
{"claim": "具体结论1", "source_ids": [1, 2]},
{"claim": "具体结论2", "source_ids": [3]}
],
"confidence": "high/medium/low"
}为什么有效：
- LLM 在构建 JSON 时必须主动思考"这条结论从哪条资料里找到的"，该过程本身减少瞎编概率------好比学生写论文必须标注参考文献，自然不敢随便编
- 系统拿到 JSON 后可做程序化验证------如果
source_ids对应的 chunk 与claim明显不相关，可自动过滤该结论
四方案组合策略
| 场景 | 推荐组合 | 说明 |
|---|---|---|
| 普通企业知识库、客服问答 | 方案一 + 方案二 | 基础配置，成本极低，幻觉问题解决大半 |
| 高可信度场景（金融分析、法律文档） | 方案一 + 方案二 + 方案四 | 每条答案带来源编号，用户可自行核实 |
| 高准确性、低容错场景（医疗问诊、合规审核） | 四个方案全上 | 在延迟和成本上付出代价，换取最高级别准确性保证 |
核心结论：规避幻觉没有一劳永逸的银弹。检索质量是幻觉的最大来源------检索到了正确内容，Prompt 再稍加约束，幻觉就已减少很多；如果检索这一步就失败，再多生成层约束也填补不了。
治幻觉，先治检索。
幻觉评估工具
| 工具/框架 | 说明 | 核心指标 |
|---|---|---|
| RAGAS | 专注 RAG 评估的开源框架 | Faithfulness、Answer Relevancy、Context Precision |
| DeepEval | 支持多种幻觉检测指标 | Faithfulness、Hallucination |
| TruLens | 提供 feedback functions 自动评估 | Groundedness、Context Relevance |
| LangSmith | LangChain 官方可观测性平台 | 追踪、评估、调试 |
| Phoenix (Arize) | RAG 检索与生成质量监控 | 检索质量、生成质量 |
| Vectara HHEM | 专门的幻觉检测模型 | 忠实度评分 |
评估指标说明：
| 指标 | 衡量什么 |
|---|---|
| Faithfulness（忠实度） | 生成内容是否忠于检索到的上下文 |
| Answer Relevancy（回答相关性） | 回答是否与问题相关 |
| Context Precision（上下文精度） | 检索到的上下文中有多少是相关的 |
| Context Recall（上下文召回） | 相关内容是否都被检索到了 |
参考资料
-
RAG 高级范式详解
-
RAG 幻觉防控详解
-
Self-RAG 论文：Learning to Retrieve, Generate, and Critique through Self-Reflection
-
CRAG 论文：Corrective Retrieval Augmented Generation
-
GraphRAG（Microsoft Research）
-
RAGAS 评估框架
-
DeepEval 评估框架
-
Vectara HHEM 幻觉检测模型
https://huggingface.co/vectara/hallucination_evaluation_model
-
LangSmith 可观测性平台
-
LangGraph 文档