完整题目
当RAG系统产生错误输出时，如何系统性地判断问题源于检索模块还是生成模块？请设计可行的归因分析方法或实验方案，说明如何通过结果观察、指标评估或对照实验进行定位，并解释其原理。
本文目录
核心思路：隔离变量 + 对照实验
RAG错误的根因定位本质是解耦检索与生成的影响，通过控制输入变量观察输出变化。
一、黄金文档替换实验（Gold Document Swap）
原理：用已知正确的文档强制替换检索结果，消除检索噪声
| 实验组 | 检索输入 | 预期结果 | 实际结论 |
|---|---|---|---|
| 原系统 | 真实检索Top-K | - | 基线 |
| 黄金组 | 人工标注的相关文档 | 正确输出 | 若仍错误→生成模块问题 |
| 随机组 | 随机不相关文档 | 错误输出 | 若仍正确→生成过度依赖先验 |
关键判定：
- 黄金组正确 + 原系统错误：提示原检索/排序/过滤/上下文组织可能有问题，还要区分漏召回与噪声、位置、截断。
- 黄金组仍错误：先确认黄金证据充分、prompt和输入格式正确，再查生成与证据使用；不能仅凭该实验断言是幻觉。
二、独立指标体系
检索侧指标（无需生成模型）：
Recall@K：Top-K命中的黄金相关文档数 / 全部黄金相关文档数；至少命中一份是Hit@KMRR：每个query首个相关结果排名的倒数，再求均值；无命中记0NDCG：排序质量
生成侧指标（固定检索结果）：
Faithfulness：生成内容是否被检索文档支持（可用NLI模型判断）Answer Relevance：答案与问题的相关性
交叉验证：当检索指标高但Faithfulness低 → 生成模块问题
三、注意力权重分析（辅助手段）
只有具有cross-attention且开放相应内部状态的架构，才可提取该类权重；decoder-only模型或托管API不一定提供。注意力大小不能直接证明因果归因。
- 可用权重定位候选片段，再通过删除/替换证据、调整位置与保持其它变量不变的干预验证。
- 不把“高权重”当作模型确实依赖该资料或模块有错的充分证据。
四、端到端消融实验
实验1: 检索模块消融
→ 固定生成模型，换用不同检索策略（BM25→Dense→混合）
→ 效果变化大 = 检索是瓶颈
实验2: 生成模块消融
→ 固定检索结果，换用不同生成模型（7B→70B）
→ 效果变化大 = 生成是瓶颈快速落地建议
生产环境可用轻量版：对错误case自动注入"已知正确文档"重跑，对比输出变化，实现半自动化归因。
学习建议
掌握RAG流程中检索与生成的接口数据格式，练习构造测试用例，理解常见错误模式及其归因逻辑。
参考资料
换一种问法，检查是否真正理解
场景切入
我看你们客服系统用的RAG，假设用户问订单状态，结果模型瞎编了一个物流编号。你觉得这个问题是检索没找到正确页面，还是生成时捏造了信息？怎么一步步查出来？
层层追问
RAG出错了，一般你会怎么排查？……如果我先给你一段正确文档，模型还是答错，那问题出在哪？……那反过来，用随机文档它反而答对了呢？
直球架构
设计一套实验方案来系统归因RAG错误是检索还是生成问题。要求能用指标或对照实验定位，说明原理和判断依据。
练习口述回答 · 约4分钟
- 一句话定位：本质是隔离变量做归因
- 黄金文档替换实验：核心方法，用已知正确文档替换检索结果
- 结合指标与注意力权重辅助验证
- 落地风险与工程简化方案
- 收尾与可延伸点
面试官你好，这个问题其实问的是，当[[RAG]]系统的输出不对时，我们怎么快速判断是检索没找到好东西，还是生成模型自己编错了。本质就是隔离变量做归因，把检索和生成的影响解耦开。
我最常用的方法是黄金文档替换实验，思路很简单：人工准备一份绝对正确的相关文档，替换掉检索模块的Top-K结果，喂给生成模型。替换后输出改善，提示原检索、排序、过滤或上下文组织可能存在问题；替换后仍错，还要先确认证据充分、prompt和格式正确，再查生成及证据使用，不能唯一归因。你可以这么理解，这就像排查一个流水线，把上游零件换成标准件，看下游还出不出问题。
当然，这个实验有个前提，就是黄金文档要真的准，不然结论会误导。实际业务里，比如客服退款场景，用户问的是'为什么我退款被拒'，黄金文档就是对应退款政策的正确条款。如果替换后系统还是答非所问，那大概率是生成模型对政策理解不到位，或者产生了幻觉。
除了这个实验，我还会配合指标来交叉验证。检索侧我会看 Recall@K 和 MRR，如果这些指标很高但输出还是错，那大概率是生成侧出了问题。生成侧我主要关注 [[Faithfulness]]，用NLI模型判断生成内容是否被检索文档支持。检索指标高但Faithfulness低时，继续查上下文组织、截断与生成证据使用；单个自动分数不足以唯一归因。
只有具有cross-attention且开放内部状态的架构才能查看这类权重，decoder-only或托管API不一定提供。注意力大小不等于因果解释，应通过删除、替换或移动证据的干预继续验证。不过这个比较重，生产环境我一般先用黄金文档实验快速定位，再决定要不要深入看权重。
这里有个坑：黄金文档实验在冷启动或文档质量差时可能不成立，比如企业SOP文档本身就有歧义，那黄金文档本身就不黄金。所以上线前我会特别关注文档质量，先人工抽检一批case，确保黄金文档是可靠的。另外，生产环境里全量跑黄金文档实验成本高，我会用轻量版：只对线上报错的case自动注入已知正确文档重跑，对比输出变化，实现半自动化归因。
还有一个延伸点我提一下：如果检索和生成各自指标都正常但整体效果还是差，那可能问题不在模块本身，而在检索结果和生成模型的交互，比如检索到的文档虽然相关但信息冗余或矛盾，导致生成模型困惑。这个场景下，我会考虑引入 [[Self-RAG]] 让模型自己学会反思和修正，或者用 [[Corrective RAG]] 做检索后纠正。
所以整体上，我更倾向先跑黄金文档实验做快速定位，再结合指标做验证，这样在工程上比较高效。