第十五章：高级 RAG 范式¶

15.1 三代 RAG 的演进逻辑¶

理解这些范式时，关键是看每一代解决了上一代的什么问题，而不是只列名字。

flowchart LR
    N[Naive RAG<br/>检索一次 直接生成] --> A[Advanced RAG<br/>检索前后加优化环节]
    A --> M[Modular RAG<br/>组件化 可编排 可循环]

代际	结构	解决了什么	遗留问题
Naive RAG	检索 → 拼接 → 生成，一次性、单向	让模型能用外部知识	检索质量差、无质量把关
Advanced RAG	加入 Query 改写、混合召回、Rerank、上下文压缩	大幅提升检索质量	流程仍是固定的一条直线
Modular RAG	组件化，支持路由、循环、条件分支	能按需组合与迭代	复杂度和成本上升

从第二代到第三代的本质变化，是流程从「固定直线」变成了「可以根据中间结果改变走向」。

而当这个「改变走向」的决策权交给 LLM 自己时，就演变成了 Agentic RAG（15.6）。

15.2 Self-RAG：让模型自己决定要不要检索、检索得对不对¶

Self-RAG 的做法是训练模型在生成过程中输出特殊的反思标记，用来自我判断：

判断	含义
需不需要检索	这个问题是否需要外部知识
检索到的内容相关吗	每个片段是否与问题相关
生成的内容被材料支撑吗	输出是否有依据
这个回答有用吗	整体质量评估

它解决的问题：Naive RAG 是「无条件检索、无条件使用」，既浪费（不需要检索时也检索），又危险（检索到不相关内容也硬用）。

这些反思能力是训练出来的，需要专门的训练数据和微调流程。很多工程实现只是借用了它的思路（用提示让模型做类似判断），而不是复现原论文的训练方法，两者不能混为一谈。

15.3 CRAG：检索质量不行时怎么补救¶

这里有一个常见的命名歧义：

Corrective RAG（一种方法）和 CRAG Benchmark（一个评测基准）是完全不同的两个东西，不要混淆。

Corrective RAG 的做法是用一个轻量的评估器给检索结果打分，再按分数分三档处理：

flowchart TB
    R[检索结果] --> E[轻量评估器打分]
    E -->|正确| C[精炼: 去掉无关部分 保留核心]
    E -->|错误| W[丢弃 改用外部搜索]
    E -->|模糊| A[两者结合]
    C --> G[生成]
    W --> G
    A --> G

它的价值在于承认了一个现实：检索是会失败的，系统需要有失败后的补救路径。 这比「检索到什么就用什么」进了一大步。

工程上的简化实现：不一定要训练专门的评估器，用 Rerank 分数做阈值判断 + 触发降级路径（换检索策略、扩大范围、或直接拒答），就能拿到大部分收益。

15.4 RAPTOR：把知识组织成树¶

要解决的问题：普通 RAG 检索的是平铺的片段，无法回答需要综合整篇甚至整个语料的问题（「这份报告的核心结论是什么」）。

RAPTOR 的流程如下：

把所有 chunk 向量化后聚类；
对每个簇用 LLM 生成摘要；
把摘要也向量化，再聚类、再摘要，递归向上，形成一棵树；
检索时同时在所有层级上检索——细节问题命中叶子节点，宏观问题命中高层摘要。

flowchart TB
    ROOT[顶层摘要<br/>全局视角] --> M1[中层摘要 1]
    ROOT --> M2[中层摘要 2]
    M1 --> L1[原始 chunk]
    M1 --> L2[原始 chunk]
    M2 --> L3[原始 chunk]
    M2 --> L4[原始 chunk]

效果：在需要多段落综合的长文档问答任务上，公开评测显示有显著提升。

代价与适用边界：

索引阶段需要大量 LLM 调用（每个簇一次摘要，逐层递归）；
语料更新时树需要局部甚至整体重建；
语料规模小于两百页左右时，收益边际递减——因为整篇本来就装得下。

15.5 各范式对应的痛点¶

范式	治的痛点	成本	成熟度
Self-RAG	无条件检索、无质量把关	需要微调（或用提示近似）	学术为主
Corrective RAG	检索失败无补救路径	中	思路已被工程广泛采纳
RAPTOR	无法回答需要全局综合的问题	索引成本高	学术为主
Adaptive-RAG	简单问题用重策略浪费	低	思路易落地
GraphRAG	无法做多跳和全局主题分析	很高	见第十六章
Agentic RAG	单轮检索无法处理复杂任务	高	快速发展中

15.6 Agentic RAG：把检索变成 Agent 的工具¶

这是 2025–2026 年关注度很高的方向之一。

Agentic RAG 的关键转变是：

从「固定流程中的一个步骤」，变成「Agent 可以自主决定何时调用、调用几次、怎么用结果的一个工具」。

flowchart TB
    Q[用户问题] --> AG[Agent 推理]
    AG --> D{需要更多信息?}
    D -->|是| T[调用检索工具]
    T --> OB[观察结果]
    OB --> AG
    D -->|否| ANS[生成答案]

它带来的能力包括：

能力	说明
多轮检索	第一轮结果不够，基于已知信息发起新一轮检索
多跳推理	先查出 A 的 CEO 是谁，再查这个人的信息
自主分解	复杂问题自己拆成子问题
多源调度	在向量库、SQL、网页搜索、API 之间自主选择
自我纠错	发现检索结果不对，换个查询方式重试

相应的代价也很明确：

延迟不可预测：可能一轮结束，也可能十轮；
成本不可预测：每轮都是完整的 LLM 调用；
可能陷入循环：反复检索却不收敛，必须设最大轮次上限；
调试困难：执行路径每次都不同。

工程上通常会设置硬性的最大迭代次数、总 Token 预算和超时时间。这与 Agent 系统的通用要求一致（参见 Agent 部分的相关章节）。

15.7 什么时候该上高级范式¶

多数情况下，不需要一开始就引入这些高级范式。

第十四章已经说过——先把基础五层做对，通常比盲目叠加高级范式更有效。高级范式应该在满足以下条件时才考虑：

flowchart TB
    S{基础五层<br/>都做扎实了吗?} -->|没有| BASE[回去做基础<br/>第十四章]
    S -->|做了| E{有评测集能<br/>量化收益吗?}
    E -->|没有| EVAL[先建评测集]
    E -->|有| N{失败案例属于<br/>基础方案的结构性缺陷吗?}
    N -->|不是| TUNE[继续调基础参数]
    N -->|是| ADV[评估对应的高级范式]

「结构性缺陷」的判断标准：这个问题不是调参能解决的。例如：

需要多跳推理 → 单轮检索结构上做不到 → 考虑 Agentic RAG；
需要全局主题综合 → 片段检索结构上做不到 → 考虑 RAPTOR 或 GraphRAG；
检索失败率高且无法降低 → 考虑加入补救路径。

反之，如果失败原因是「chunk 切得不好」「没有 BM25 那一路」，那再高级的范式也救不了。

15.8 常见错误¶

15.8.1 罗列范式名字不讲解决什么痛点¶

如果只列出范式名而不说明它们分别在解决什么问题，通常很难支撑选型判断。

15.8.2 混淆 Corrective RAG 和 CRAG Benchmark¶

一个是方法，一个是评测基准，名字撞车但毫不相干。

15.8.3 说 Self-RAG 只是加个提示词¶

原论文是通过训练让模型输出反思标记。工程上的提示词近似实现应该说明是简化版。

15.8.4 忽略 RAPTOR 的索引成本和更新代价¶

大量 LLM 调用 + 更新需重建树，在动态语料上代价很大。

15.8.5 Agentic RAG 不设迭代上限¶

会陷入循环，成本和延迟不可控。

15.8.6 基础没做好就上高级范式¶

这是最常见的错误。基础缺陷不会被高级范式弥补，只会被掩盖并放大成本。

15.8.7 不区分学术方案和生产方案¶

多数高级范式还在学术阶段。讨论它们时应明确成熟度，不宜直接写成“已广泛应用”。

15.9 本章总结¶

三代演进：Naive（固定直线）→ Advanced（前后加优化）→ Modular（可路由可循环）；本质变化是流程能否根据中间结果改变走向；
Self-RAG 用反思标记让模型自判是否检索、内容是否相关、生成是否有依据；原论文靠训练实现；
Corrective RAG 给检索结果分档处理并提供失败补救路径；注意与 CRAG Benchmark 区分；工程上可用 Rerank 阈值简化实现；
RAPTOR 递归聚类摘要成树，多层级检索兼顾细节与全局；索引成本高，小语料收益递减；
Agentic RAG 把检索变成 Agent 的工具，支持多轮、多跳、多源和自我纠错；必须设迭代上限和预算；
上高级范式的前提：基础五层已做扎实 + 有评测集 + 失败原因是结构性缺陷而非调参问题；
要诚实说明各范式的成熟度，多数仍在学术阶段。