第十五章：高级 RAG 范式¶

15.1 三代 RAG 的演进逻辑¶

Naive、Advanced、Modular 是综述中的组织方式，不是严格的版本标准或必经代际。理解时应看控制流、训练要求和适用问题，而不是只列名字。

%%{init: {"flowchart": {"nodeSpacing": 16, "rankSpacing": 22, "padding": 8, "wrappingWidth": 160}}}%%
flowchart TB
    N[Naive RAG<br/>检索一次 直接生成] --> A[Advanced RAG<br/>检索前后加优化环节]
    A --> M[Modular RAG<br/>组件化 可编排 可循环]

组织方式	关注点与边界
Naive RAG	用检索、拼接、生成建立基本链路；若缺少质量控制，容易使用无关或不充分证据
Advanced RAG	优化检索前后环节，如改写、混合召回、重排和压缩；是否有循环由实现决定
Modular RAG	强调组件替换、路由、分支与循环的可组合性；灵活性增加，也增加调试与成本管理负担

比“属于第几代”更有用的问题是：谁决定下一步，依据什么中间结果，何时停止。

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

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

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

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

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

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

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

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

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

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

%%{init: {"flowchart": {"nodeSpacing": 12, "rankSpacing": 16, "padding": 8, "wrappingWidth": 110}}}%%
flowchart TB
    R[检索结果] --> E[轻量评估器]
    E -->|正确| C[精炼]
    E -->|错误| W[外部搜索]
    E -->|模糊| A[结合两者]
    C --> G[生成]
    W --> G
    A --> G

评为“正确”时，精炼会去掉无关部分，保留核心证据；评为“错误”时，丢弃原结果，改用外部搜索；评为“模糊”时，结合精炼与外部搜索。各分支随后向生成阶段提供证据。

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

工程上可以借用“质量判断 + 补救”的控制流，但不能声称提示词或 Rerank 阈值复现了原论文、或保证获得大部分收益。拒答规则需校准；私有知识检索失败时，外部网页通常无法补全，还可能带来泄密和来源风险，必须受数据与工具授权约束。

15.4 RAPTOR：把知识组织成树¶

要解决的问题：只从平铺片段中取少量 Top-K，可能覆盖不了整篇报告的主要结论。RAPTOR 提前构建多层摘要，让检索既能取细节，也能取较高层的概括；这不是说普通 RAG 配合全文读取或分组汇总就不能回答综合题。

RAPTOR 的流程如下：

把所有 chunk 向量化后聚类；
对每个簇用 LLM 生成摘要；
把摘要也向量化，再聚类、再摘要，递归向上，形成一棵树；
原论文比较了 tree traversal 与 collapsed tree 两种检索方式，后者把多层节点放在一起检索；不能把“每次遍历所有层”视为唯一实现。

%%{init: {"flowchart": {"nodeSpacing": 12, "rankSpacing": 16, "padding": 8, "wrappingWidth": 110}}}%%
flowchart LR
    ROOT[全局摘要] --> M1[摘要 1]
    ROOT --> M2[摘要 2]
    M1 --> L1[块 1]
    M1 --> L2[块 2]
    M2 --> L3[块 3]
    M2 --> L4[块 4]
    M2 -.-> L2

顶层摘要从全局视角概括两个中层摘要，叶节点是原始块。额外的虚线表示块 2 同时属于两个摘要，成员关系不必互斥。

图中虚线表示一个片段也可能参与另一个簇的摘要。原论文采用软聚类，节点可属于多个簇；“树”是分层组织的直观称呼，不能据此假定每个片段只有唯一父节点。去重和来源回链需处理这种重叠。

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

代价与适用边界：

索引阶段需要大量 LLM 调用（每个簇一次摘要，逐层递归）；
语料更新时树需要局部甚至整体重建；
摘要可能省略细节或传播错误，必须保留到叶子原文的来源映射；判断是否值得建树应看 Token 量、跨文档证据需求和缓存成本，没有“两百页”通用阈值。

15.5 各范式对应的痛点¶

其中 Adaptive-RAG 训练一个较小的语言模型分类器，根据问题复杂度在不检索、单轮检索与迭代检索之间选择。训练标签来自候选流程的实际表现等信号；规则路由可以借鉴这种分工，但不是原论文分类器的复现。

范式	针对的问题与新增负担
Self-RAG	学习何时检索和如何评价证据；需要反思标记训练与推理控制
Corrective RAG	为低质量检索提供补救；需要评估器校准、知识精炼与受控外部搜索
RAPTOR	扩大综合题的证据层次；付出聚类摘要、来源维护与更新成本
Adaptive-RAG	避免简单题过度计算、复杂题检索不足；付出分类训练和错路由代价
GraphRAG	用关系和社区报告支持实体或全局问题；需构图、证据校验与派生更新
Agentic RAG	按中间结果自主多轮检索；需控制预算、停止条件与工具权限

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

这里讨论一种控制方式，不把年份或关注度作为采用依据。

Agentic RAG 的关键转变是：

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

%%{init: {"flowchart": {"nodeSpacing": 16, "rankSpacing": 22, "padding": 8, "wrappingWidth": 160}}}%%
flowchart TB
    Q[用户问题] --> AG[Agent 推理]
    AG --> D{需要更多信息?}
    D -->|是| T[调用检索工具]
    T --> OB[观察结果]
    OB --> AG
    D -->|否| ANS[生成答案]

它带来的能力包括：

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

相应的代价也很明确：

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

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

每轮工具调用还要由执行层检查身份、资源与可发送数据；检索片段不能替用户授予新的权限，也不能指使 Agent 把内部查询转发到未批准的外部搜索。

停止条件还应包括“新一轮未增加有效证据”和“目标证据已覆盖”。记录每轮查询、证据、重复命中与停止原因，并与固定两轮查询分解基线比较任务成功率、平均轮次、P95 和每个成功任务的成本；否则更多轮次可能只是更贵地重复错误。

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

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

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

%%{init: {"flowchart": {"nodeSpacing": 16, "rankSpacing": 22, "padding": 8, "wrappingWidth": 160}}}%%
flowchart TB
    S[验证基础] --> E[建立可量化收益]
    E --> N[诊断结构性限制]
    N --> ADV[评估对应高级范式]

这些是门槛，不是要求一律采用高级设计。基础五层中有任何一层薄弱，就回到第十四章；没有能量化收益的评测集，就先构造评测集；失败并未暴露基础方案的结构性限制，就继续调整基础方案。通过这些检查后，才评估相应的高级范式。

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

多跳证据在单轮候选中覆盖不足 → 比较查询分解、多轮检索与图扩展；
全局主题需要更广覆盖 → 比较全量分组汇总、长上下文、RAPTOR 或 GraphRAG；
检索失败率高且无法降低 → 考虑加入补救路径。

如果失败来自解析损坏、切分遗漏或词项匹配不足，应先修对应环节；不能仅因没有 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 的工具，支持多轮、多跳、多源和自我纠错；必须设迭代上限和预算；
上高级范式的前提：基础五层已做扎实 + 有评测集 + 失败原因是结构性缺陷而非调参问题；
区分论文机制、具体实现和业务验证，不要以方法名字或年份替代采用依据。

参考资料¶

本章的参考资料、阅读建议与来源说明见集中参考资料章节。