RAG / 高级与多模态 / 高级 RAG 范式
本文转载自 Awesome AI Roadmap，原作者 Polo Li，依 CC BY 4.0 协议共享。

第十五章：高级 RAG 范式

15.1 三代 RAG 的演进逻辑

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

flowchart LR
    N[Naive RAG
检索一次 直接生成] --> A[Advanced RAG
检索前后加优化环节]
    A --> M[Modular RAG
组件化 可编排 可循环]
代际 结构 解决了什么 遗留问题
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 的流程如下：

  1. 把所有 chunk 向量化后聚类；
  2. 对每个簇用 LLM 生成摘要；
  3. 把摘要也向量化，再聚类、再摘要，递归向上，形成一棵树；
  4. 检索时同时在所有层级上检索——细节问题命中叶子节点，宏观问题命中高层摘要。
flowchart TB
    ROOT[顶层摘要
全局视角] --> 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{基础五层
都做扎实了吗?} -->|没有| BASE[回去做基础
第十四章]
    S -->|做了| E{有评测集能
量化收益吗?}
    E -->|没有| EVAL[先建评测集]
    E -->|有| N{失败案例属于
基础方案的结构性缺陷吗?}
    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 本章总结

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

参考资料