Self-RAG：让模型反思检索与生成质量

让模型对是否需要检索、证据是否相关、答案是否充分进行自检。

01. 开卷考试与 Self-RAG

这里我们从一个常见的生活场景入手——参加开卷考试，一般来说我们通常会采用以下两种作答策略：

• 方法一：对于熟悉的题目，直接快速作答；对于不熟悉的题目，快速翻阅参考书，找到相关部分，在脑海中整理分类和总结后，再在试卷上作答。
• 方法二：每一个题目都需要参考书本进行解答。先找到相关部分，在脑海中进行整合和总结后，再到试卷上书写答案。

显然，方法一 大家用的更多一些，是首选方法。方法二不仅耗时，还有可能引入无关的或错误的信息，导致出现混淆和错误，甚至在考生原本擅长的领域也不例外。

映射到 RAG 应用开发中，很容易可以发现，方法二 是典型的 RAG，即（检索->整合->生成）流程，而方法一就是 Self-RAG 的流程。

Self-RAG 全称为自我反思 RAG，见名知其意，即对原始查询、检索的内容、生成的内容进行自我反思，根据反思的结果执行不同的操作，例如：直接输出答案、重新检索、剔除不相关的内容、检测生成内容是否存在幻觉、检测生成内容是否有帮助等，可以把 Self-RAG 看成是一个拥有自我反思能力的智能体，这个智能体主要用来依据相关知识库回复用户问题，自我迭代，直到输出满意的结果。

一个 Self-RAG 应用主要有三大步骤组成：

1. 按需检索（Retrieval as Needed）：使用需要检索时，例如查询“慕小课是谁时？”，模型会输出一个 检索query，表示需要检索与 query 相关的内容；相反，当模型被要求写“写一篇关于Python依赖注入的文章”时，大模型会直接生成答案，无需进行检索。
2. 以并行方式生成内容（Parallel Generation）：模型会同时使用 prompt 和检索到的内容来生成模型输出，在整个过程中，会触发多种类型的反思（Reflection），涵盖了：反思文档是否有关联、反思生成内容是否存在幻觉，如果不关联则重新检索，如果存在幻觉/支持度不够，则重新生成。
3. 内容的评估和选择：对步骤 2 中生成的内容进行评估，并选择最佳文档段落作为输出。

拆分成流程图后，Self-RAG 的运行流程如下：

在 Self-RAG 架构中，用到了 3 处循环结构，对于该架构的 AI 应用，单纯使用 LCEL 表达式构建的链应用也没法或者很难实现整个过程，同样必须使用到 LangGraph 来构建 循环图，所以关于 Self-RAG 整个流程的构建，依旧会等到我们掌握完 LangGraph 再来尝试。

02. LangSmith 下的 Self-RAG

在 LangChain 官网的示例中，提供了一个 Self-RAG 的 LangSmith 日志运行流程，我们可以通过这个日志的运行流程来深入理解。

链接：https://smith.langchain.com/public/55d6180f-aab8-42bc-8799-dadce6247d9b/r

最新版 LangChain 用法提示

新项目要优先确认组件所在包名。核心抽象通常在 langchain_core，文档分割在 langchain_text_splitters，OpenAI 相关集成在 langchain_openai，大量社区组件在 langchain_community 或独立集成包中。

涉及 Retriever、Runnable、LCEL、LangGraph 的链路，建议用 invoke() / ainvoke() 作为统一调用入口，并把检索参数、路由条件、重排参数和降级策略显式配置出来。不要只照搬旧导入路径。

拓展

Self-RAG：让模型反思检索与生成质量 不应该孤立使用。RAG 优化通常要和评测集、召回日志、答案引用、用户反馈、成本统计一起看。只优化某一个环节，可能会让另一个环节退化。

工程上建议把 query、改写后的 query、召回文档、metadata filter、重排得分、最终 Prompt 和模型输出都记录下来。否则问题出现时，很难判断是加载、切分、Embedding、检索、重排、Prompt 还是生成阶段出了问题。

常见问题

什么时候需要使用这个策略？

当普通向量检索已经不能稳定命中关键证据，或者复杂问题经常漏召回、召回重复、上下文不完整时，就需要引入该类优化。

它能替代基础 RAG 链路吗？

不能。优化策略依赖基础链路。文档质量、chunk 设计、Embedding 模型、metadata 规范和 Retriever 配置没有打好，后续策略只能缓解，不能根治。

如何判断优化是否有效？

用固定评测集对比优化前后：召回命中率、答案正确率、引用正确率、拒答准确率、延迟和成本。只看单个 demo 很容易误判。

面试题

RAG 优化应该从哪里开始？

先定位问题阶段：文档是否解析正确、chunk 是否完整、Embedding 是否适合、检索是否命中、上下文是否可用、模型是否按证据回答。定位后再选择对应策略。

为什么复杂 RAG 系统需要可观测性？

因为答案错误可能来自任意环节。没有检索日志、重排分数、Prompt 和输出记录，就只能靠猜。

如何避免优化策略越加越乱？

每个策略都要有触发条件、输入输出、评测指标和降级方案。能用简单策略解决的问题，不要过早引入复杂链路。

生产问题排查

问题	常见原因	处理方式
优化后更慢	多路检索、重排或图分支增加调用次数	增加超时、缓存、并行和候选裁剪
召回更多但更乱	多查询或混合检索没有去重和重排	使用 RRF、rerank、source_id 去重
答案仍然无依据	上下文质量低或 Prompt 没有约束证据	增加引用要求、拒答策略和证据检查
成本上涨明显	过多 LLM 改写、摘要或评估调用	缓存中间结果，限制触发条件
线上效果不稳定	缺少评测集和回归流程	固化 golden set，发布前跑回归