Back to Index
检索增强 (RAG) /

Self-RAG

让模型自己决定何时检索、如何评估检索质量，突破传统 RAG 的固定检索模式

14 min read Part of RAG · Ch. 6
← 上一层级：学习路径 · Part 02 · RAG 体系化进阶

Self-RAG

flowchart LR
  A["Self-RAG"]
  A --> B["分类：检索增强 (RAG)"]
  A --> C["关键词：RAG"]
  A --> D["关键词：Self-RAG"]
  A --> E["关键词：自适应检索"]
  A --> F["关键词：反思"]

传统 RAG 有一个几乎默认的前提：每次回答都要检索。这个前提在很多入门系统里很好用，因为流程简单、实现直接，但它也带来一个越来越明显的问题：并不是所有问题都值得查，也不是所有查回来的资料都值得信。Self-RAG 这条路线之所以重要，不在于“又发明了一种更强的检索器”，而在于它开始认真处理两个在传统 RAG 里经常被忽略的问题：什么时候应该检索，以及检索回来的内容到底能不能被相信。 Self-RAG 原始论文把这个方向概括为“retrieve, generate, and critique through self-reflection”，也就是让模型在生成过程中同时学习检索和反思。(arxiv.org)

延伸阅读

  • Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection :contentReference[oaicite:0]{index=0}
  • Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity :contentReference[oaicite:1]{index=1}

这篇文章会讲什么

前面几篇 RAG 文章其实都在不断逼近同一个现实：
一个基础 RAG 系统可以工作，但并不天然“聪明”。

它常常会这样做：

  • 不管问题类型，先检索再说
  • 不管检索质量，先把结果塞进上下文再说
  • 不管证据是否充分，先生成答案再说

这套流程的优点是稳定、容易实现，但问题也很明显：

  • 对简单问题来说，它会产生不必要的延迟和成本
  • 对低质量检索来说，它会把噪声直接注入模型
  • 对高风险问答来说，它缺少“我其实不该这么自信”的机制

所以 Self-RAG 真正想解决的，不是“传统 RAG 完全没用”，而是：

传统 RAG 的控制逻辑太外部化、太静态，模型几乎没有判断空间。

Self-RAG 以及后来的 Adaptive-RAG，都在往另一个方向走：让系统学会根据问题复杂度、检索必要性、证据支持度来动态调整行为。Adaptive-RAG 的论文就明确提出，不同复杂度的问题不应该一律走同一种检索策略，而应该在“无检索、单步检索、多步检索”之间自适应选择。(arxiv.org)

传统 RAG 的真正问题，不只是“有时检索不准”

很多文章会把传统 RAG 的问题总结为“检索质量不够好”。这当然没错，但还不够深入。更准确地说，传统 RAG 的问题至少有四类：

问题表现
盲目检索简单问题也触发检索，增加延迟和成本
噪声放大检索到不相关内容，反而干扰生成
缺乏质量控制模型默认“参考资料大概是对的”
无法自纠生成阶段发现证据不足时，通常没有回退逻辑

这里最值得强调的一点是：

RAG 不是自动减少幻觉，而是把“幻觉风险”从模型参数，部分转移到了外部文档和检索链路。

如果检索阶段本身不稳定，RAG 不是不出错，而是换了一种方式出错。Self-RAG 官方页面也直接指出，标准 RAG 的问题之一正是“indiscriminately retrieving and incorporating a fixed number of passages regardless of whether retrieval is necessary, or passages are relevant”。(selfrag.github.io)

Self-RAG 的核心思想

Self-RAG 的本质，不是更强的检索，而是给 RAG 系统增加“判断权”。

Self-RAG 原始论文的关键创新，是让模型不再只是“消费检索结果”，而是参与下面几类判断：

  1. 是否需要检索
  2. 检索到的文档是否相关
  3. 当前生成内容是否被证据支持
  4. 整体回答是否足够有用

论文和项目页都把这种机制称为 self-reflection，并通过一组特殊的 reflection tokens 来显式建模。(arxiv.org) (selfrag.github.io)

如果把它抽象成系统层面的三个问题，其实很容易理解：

层面核心问题
触发层要不要查？
输入层查到的东西靠谱吗？
输出层我说的话有证据吗？

这三层判断，分别对应了传统 RAG 里最容易被忽视的三个薄弱点。

一句话总结：Self-RAG 不是优化某一个检索模块，而是让 RAG 从“静态流水线”变成“带反思的决策系统”。

Self-RAG 的关键机制：Reflection Tokens

Self-RAG 论文和官方项目页都强调，它的一个核心设计，是让模型学习生成一组特殊 token，用这些 token 来显式控制检索和反思过程。官方页面给出的概念非常清楚：模型会生成用于检索控制和批判评估的 reflection tokens，从而在推理阶段实现可控行为。(selfrag.github.io)

在工程理解上，可以把这些 token 看成几类“自我提示信号”：

类型想解决的问题作用
Retrieve 类 token现在要不要查资料？控制是否触发检索
Relevance 类 token这些资料值不值得用？控制文档过滤与保留
Support 类 token我的答案有没有证据？控制生成接受、回退或补充
Utility 类 token当前回答整体是否有帮助？控制最终答案质量偏好

注意，这里最重要的不是具体 token 字面长什么样，而是它们代表的控制逻辑被显式化了。在 Self-RAG 之前，传统 RAG 系统里的这些判断往往全都藏在外部规则里，模型本身不参与；而 Self-RAG 让这些判断成为模型输出的一部分。(arxiv.org) (selfrag.github.io)

一个更真实的例子：Self-RAG 到底在多判断什么

假设用户问：

公司 2025 Q3 的收入是多少？

传统 RAG 的典型流程可能是：

收到问题
→ 直接检索
→ 返回几段财务文档
→ 把它们拼进 prompt
→ 模型生成答案

而 Self-RAG 风格的流程更像：

1. 先判断：这个问题是否需要检索？
2. 如果需要，执行检索
3. 再判断：返回的文档里哪些真的相关？
4. 基于相关文档生成答案
5. 再判断：这个答案是否被证据充分支持？
6. 如果支持不足，决定是否补查、重试或显式表达不确定性

这和传统 RAG 的最大区别是：

它不是默认“检索 → 生成”就结束，而是允许中间出现否决、过滤、回退和再判断。

也正因为如此，Self-RAG 更像“闭环”，而不是“单向流水线”。

工作流程：从线性到闭环

传统 RAG 更接近线性流程：

检索 → 拼接 → 生成 → 输出

而 Self-RAG 更接近决策循环：

1. 用户提问
2. 判断是否需要检索
3. 执行检索（必要时可多轮）
4. 判断文档是否相关
5. 生成答案
6. 判断答案是否被证据支持
7. 不通过时重试、改写、再检索或降级
8. 输出结果

Self-RAG 官方项目页在介绍 inference 阶段时，明确写到模型可以 adaptively retrieve passages on-demand，也就是说它可以完全跳过检索，也可以在生成中多次检索；同时它还能对检索结果和自身生成做 critique。(selfrag.github.io)

所以可以把这类系统的变化概括成先看定义：

RAG 从“固定流程”变成“带回退和判断的控制循环”。

自适应检索（Adaptive Retrieval）的真实价值

很多人第一次听到 Self-RAG，会把它简单理解成：

“不是所有问题都要查资料。”

这当然是它的一个直接收益，但工程上它更深层的价值其实有三点。

1. 降低噪声注入

检索系统天然更偏 recall-first，而不是 precision-first。 这意味着：

  • 查不到，是一种问题
  • 查到了很多不够相关的内容，也是问题

Self-RAG 的价值之一，就是不再默认“只要查到了东西，就应该全部信任并送给模型”。

2. 降低系统成本

RAG 不是免费能力。一次检索往往意味着：

  • query embedding
  • 向量检索或混合检索
  • 可能的 rerank
  • 更长的 prompt
  • 更高的 token 成本

而真实产品里，很多高频问题其实不需要这些步骤。Adaptive-RAG 的论文就明确指出，不同复杂度的 query 如果都走统一的检索路径，会带来不必要的计算开销。(arxiv.org)

3. 降低延迟

在生产系统里，多一次检索、重排和更长上下文，通常就意味着更多延迟。 所以“该查才查”不是玄学，而是一个非常现实的性能优化目标。

但要小心一个误区：Self-RAG 不是“能不查就不查”

这是很容易走偏的一点。

如果你把目标理解成：

“尽量少检索，这样成本更低。”

那么系统很快就会走向另一种失败：under-retrieval，也就是该查的时候没查，模型直接靠参数记忆和语言惯性回答，结果开始自信地胡说。

真正正确的目标应该是：

  • 该检索时一定检索
  • 不该检索时不要乱检索
  • 检索回来后，不要默认无条件信任
  • 生成后，必要时还要再检查自己说的是否站得住

所以 Self-RAG 的关键不在“省掉检索”，而在“检索策略更有判断力”。

从“相信上下文”到“质疑上下文”

传统 RAG 的一个隐含前提是：

只要进 prompt 的资料，大概率就是对的、相关的、值得参考的。

Self-RAG 恰恰是在打破这个前提。

IsRelevant：过滤输入噪声

这一层判断不是为了“排序更漂亮”，而是为了处理这样的问题：

  • 检索到了语义相似但业务不相关的内容
  • 文档局部命中关键词，但整体并不回答问题
  • 某些段落看起来相关，实际上只会误导生成

Self-RAG 官方页明确把 critique on retrieved passages 作为核心能力之一。(selfrag.github.io)

IsSupported：约束输出

这一层更重要，因为它面对的是最终答案。 它要回答的不是“这个答案流不流畅”，而是：

我现在说的这句话，真的能从证据里找到支撑吗？

如果不能，就不应该像传统 LLM 一样自然地“补完”。

这个机制的工程意义很大：

  1. 可解释性增强：系统知道自己在依赖哪类证据
  2. 失败可控：系统知道什么时候应该保守表达或触发 fallback

当然，这里也有个必须讲清楚的边界：

IsSupported 本身也可能判断错。

这意味着，Self-RAG 不是让系统“自动拥有真理”，而是让系统拥有更多显式的自我约束信号。

与标准 RAG 的本质差异

维度标准 RAGSelf-RAG
检索触发系统固定决定模型可参与判断
文档处理查到就用可过滤、可质疑
生成逻辑线性流程带回退的闭环
输出信任默认更信上下文显式检查支持度
错误处理通常较弱理论上可重试、改写、降级

可以用一句更直白的话来概括：

标准 RAG 是“把资料喂给模型”，Self-RAG 是“让模型判断怎么用资料”。

2026 年更现实的实现路径：论文范式 vs 工程近似

这部分非常重要，因为很多人会把 Self-RAG 论文直接等同于今天的工程实现。实际上，两者差距不小。

Self-RAG 原始方法依赖专门训练：官方项目页明确写到其训练涉及 Retriever、Critic、Generator 三个部分，并通过 reflection tokens 让生成模型学会检索和批评。(selfrag.github.io)

但在现实系统里，完全复现这套训练流程并不常见。更常见的是做“近似版 Self-RAG”。

1. Prompt 驱动的 Self-RAG

最常见的做法是通过结构化 prompt，让模型输出类似：

  • 是否需要检索
  • 哪些文档相关
  • 当前答案是否被支持

优点：

  • 实现简单
  • 无需训练
  • 能快速验证价值

缺点：

  • 稳定性依赖底层模型
  • 判断容易漂移
  • 很难达到论文式强控制

2. Retrieval Gating

另一条更工程化的路线，是在检索前先加一个 gating 层。例如：

  • 小模型分类器
  • 基于 query 类型的规则判断
  • 基于复杂度或不确定性的检索触发器

Adaptive-RAG 本质上就是这个方向的一种更系统化实现：它通过一个更小的分类器，根据 query complexity 在 no-retrieval、single-step retrieval、iterative retrieval 之间选择策略。(arxiv.org)

3. Tool Calling + 控制循环

在很多现代 Agent 系统里，工程上最实用的折中方案其实是：

  • 把检索封装成 search() 或 retrieve() 工具
  • 让模型决定是否调用
  • 再让模型决定是否继续调用、是否接受结果

这可以看作是一种“弱化版 Self-RAG + Agent Loop”的结合体。

4. Reranker + Self-critique 组合

另一条常见工程路径是：

  • 先用 retriever / reranker 做第一层过滤
  • 再让 LLM 做 relevance 判断
  • 最后再让 LLM 判断 support

这意味着，不一定非要把所有判断都交给同一个模型层。

关键工程 Trade-off

1. 延迟 vs 准确率

每多一层判断，通常就意味着：

  • 多一次模型调用
  • 或更多生成 token
  • 或更多控制逻辑

这会显著增加系统复杂度和延迟。

2. 灵活性 vs 稳定性

  • 模型自己判断：更灵活，但不稳定
  • 规则或分类器判断：更稳定，但更僵硬

3. 召回 vs 精度

  • 过滤太严：可能漏掉有用信息
  • 过滤太松：噪声仍然污染生成

所以 Self-RAG 从来不是“白嫖提升”，它的每一层智能判断，都会带来额外系统成本。

常见失败模式

1. 过度自信（Under-Retrieval）

模型错误判断“不需要检索”，直接靠记忆或语言惯性回答。

2. 过度检索（Over-Retrieval）

模型过于保守，几乎什么问题都查，系统退化回传统 RAG，甚至更慢。

3. 相关性误判

模型把“语义上有点像”的文档误当作真正 relevant。

4. 支持度幻觉

模型错误判断自己“有证据支持”，但其实只是做了合理推断，并非真正引用证据。

这一类问题很值得重视，因为它说明：

Self-RAG 不是自动可靠，而是把“可靠性判断”本身也变成了一个可被建模、也会出错的环节。

Self-RAG 更适合什么场景

场景建议
混合问答（常识 + 私有知识）很适合
高风险问答（金融、医疗、企业关键数据）推荐，但要配合 fallback
纯 FAQ / 固定知识库收益通常有限
极低延迟场景要谨慎，额外判断链路可能太贵
高 QPS 系统需要做分层设计，不宜全量重型化

一个很现实的判断标准是：

如果你的问题分布里，既有“不需要查的简单问题”，又有“必须依赖外部知识的问题”，那 Self-RAG 思路往往很有价值。 如果你的系统几乎所有问题都必须查固定知识库，那 Self-RAG 的收益可能没那么大。

与 Agentic RAG 的关系

Self-RAG 和 Agentic RAG 很容易被混在一起，但它们的重点不一样。

Self-RAG 更偏局部控制

它主要关心：

  • 要不要查
  • 查来的东西能不能用
  • 我说的话有没有证据

Agentic RAG 更偏全局规划

它更关心：

  • 多步任务怎么拆
  • 什么时候查工具
  • 什么时候改写 query
  • 什么时候切换检索器
  • 什么时候多轮检索

所以可以这样理解：

Self-RAG 管局部判断，Agentic RAG 管全局规划。

但在实际系统里，两者经常会融合：

  • Agent 决定要不要走检索这条路径
  • Self-RAG 风格机制再决定证据能不能被信、答案能不能被接受

一个实用的最小实现：别一上来追论文级复现

如果你想在现有 RAG 系统里引入 Self-RAG 思想，一个更现实的起点通常是下面四步：

  1. 检索前判断 让模型或分类器判断：这个问题需不需要查知识库？

  2. 检索后过滤 让模型或 reranker判断：哪些返回文档真正相关？

  3. 生成后校验 让模型回答：当前答案是否真的有证据支持？支持是否充分？

  4. 失败策略 如果支持不足：

    • 再检索一次
    • 改写 query
    • 返回“不确定”
    • 要求用户补充上下文

这一版并不等于完整 Self-RAG 论文实现，但已经能解决大量真实工程问题，而且复杂度可控。

如果真的要训练 Self-RAG，难点其实在数据

这点经常被忽略。很多人以为 Self-RAG 的关键在模型结构，实际上更大的难点往往在训练数据。

如果要走论文路线，至少要有几类监督信号：

  1. Retrieve：什么时候该检索
  2. Relevant：某个 (query, doc) 是否相关
  3. Supported：某个 (query, evidence, answer) 是否真的被支持
  4. Utility：答案整体有没有帮助

官方项目页也明确说明了训练涉及 Critic 和 Generator，并且 reflection tokens 是在训练中被显式学习的。(selfrag.github.io)

真正困难的地方在于：

  • 这些标签很贵
  • 不同任务标准不一致
  • “支持”本身经常存在模糊地带
  • 长尾场景很难覆盖

所以从现实角度看：

Self-RAG 的上限，很大程度上取决于标注和反馈体系，而不只是模型规模。

小结

Self-RAG 的本质，不是“更聪明的检索器”，而是：

让 RAG 系统具备对检索、证据和输出的判断能力。

它的核心价值不只是“按需检索”，而是把传统 RAG 里原本隐含、静态、外部化的控制逻辑显式化：

  • 要不要查
  • 查来的资料值不值得信
  • 生成的答案有没有被证据支持

Self-RAG 原始论文通过 reflection tokens 和联合训练来实现这一点；Adaptive-RAG 则从 query complexity 的角度，走向“按问题复杂度自适应选择检索策略”的路线。(arxiv.org) (arxiv.org)

在工程里，你不一定需要完整复现论文，但应该认真吸收它背后的三个思想：

  • 检索不是默认动作，而是需要判断的动作
  • 上下文不是默认可信，而是需要审视的输入
  • 答案不是默认可靠，而是需要校验的输出

这正是 RAG 系统从“能用”走向“更可靠”的关键一步。

核心概念速查

概念一句话
Self-RAG让模型参与检索、证据判断和输出校验的 RAG 范式
Adaptive Retrieval按需触发检索，而不是固定每次都查
Reflection Tokens用于显式控制检索与反思行为的特殊 token
Retrieve判断当前问题是否需要检索
IsRelevant / Relevance Critique判断检索结果是否真正相关
IsSupported / Support Critique判断当前答案是否被证据支持
Retrieval Gating在检索前加一层是否触发检索的判断机制
Adaptive-RAG基于 query complexity 在 no-retrieval、single-step、iterative retrieval 之间切换的框架