完整题目
在使用检索增强生成（Retrieval-Augmented Generation, RAG）系统时，如果整体生成效果不佳，应该如何系统性地定位问题是出在检索模块、生成模块，还是两者之间的协同环节？请说明可能的诊断方法和关键指标。
本文目录
答案要点
- 区分检索失败与生成失败的诊断方法
- 关键指标设计（召回率、相关性、忠实度、答案相关性）
- 消融实验与人工分析的结合
- 典型错误模式的识别（检索不准、生成幻觉、协同失效）
核心诊断思路：分层定位，逐层验证
RAG故障排查的关键是隔离变量，把端到端问题拆解到具体模块。
第一层：判断检索模块是否合格
关键指标
- Recall@K：正确答案是否在Top-K检索结果中（K通常取5或10）
- MRR/NDCG：排序质量，相关文档是否排在前面
诊断方法
- 人工抽检：随机采样bad case，人工判断"给定这个问题，理想文档应该是什么"，对比实际检索结果
- 查询改写分析：检查原始query与改写后query的检索效果差异
- 向量相似度分布：观察query与top1结果的相似度分数，过低（如<0.6）说明语义空间对齐有问题
判定标准：Recall@K < 70% 或人工判断检索结果明显偏离，则问题在检索侧。
第二层：判断生成模块是否合格
关键指标
- Faithfulness（忠实度）：生成内容是否基于检索文档，可用NLI模型或人工标注
- Answer Relevance：答案是否直接回应问题，而非答非所问
诊断方法
- 黄金文档实验：把人工标注的理想文档强制喂给生成模型，看输出是否变好
- 变好 → 检索问题
- 仍差 → 生成问题（指令遵循不足、长上下文理解差、或SFT数据有偏）
- 上下文长度消融：逐步截断输入文档，观察性能衰减曲线，判断模型长文本能力瓶颈
第三层：协同环节问题（最易被忽视）
典型症状
- 检索文档相关但生成忽略（选择性失明）
- 多文档信息冲突时生成混乱（矛盾融合失败）
- 检索文档冗余导致关键信息被淹没（信噪比问题）
诊断方法
- 注意力可视化：分析生成时对不同文档片段的注意力权重
- 文档去重/压缩实验：测试去除冗余后的效果变化
- 多文档排序敏感性：打乱文档顺序，观察输出稳定性（位置偏见检测）
快速决策流程
端到端效果差
│
├── 黄金文档测试 ──→ 仍差 ──→ 优化生成模型（SFT数据、上下文长度）
│ │
│ 变好 ──→ 检索问题
│ │
│ 查询理解差？→ 优化query改写/embedding
│ 文档切分碎？→ 调整chunk策略
│ 排序不合理？→ 加精排模型
│
└── 检索和生成单独都好 ──→ 协同优化（prompt工程、文档压缩、动态检索）一句话总结：先用黄金文档锁定责任方，再用指标细分根因，最后针对性优化，避免盲目调参。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服RAG，用户问‘我的订单怎么还没到’，系统回答了一堆不相干的内容。你觉得问题可能出在检索、生成还是哪里？怎么一步步排查？
层层追问
RAG效果不好，你一般从哪里开始查？……如果检索结果看起来相关但生成还是乱说呢？……那有没有可能检索和生成都没问题，但两者配合出了问题？
直球架构
请系统性地说明RAG效果差时，如何分层定位是检索模块、生成模块还是协同环节的问题，包括关键诊断指标和具体实验方法。
练习口述回答 · 约4分钟
- RAG效果差，本质是定位哪个环节掉链子
- 黄金文档实验锁定责任方
- 检索侧问题诊断与指标
- 生成侧问题诊断与指标
- 协同环节的隐蔽问题
面试官你好，这道题问的是[[RAG]]效果不好怎么排查，我觉得它本质上是在问：你怎么把一个端到端的黑盒问题拆成模块级问题，然后找到那个最薄弱的环节。我的思路是分层定位、逐层验证，核心就一句话，先隔离变量，再对症下药。
具体来说，我会先问一个问题：如果我把一个完美文档直接塞给生成模型，它能不能给出好答案？这就是所谓的黄金文档实验。我找几个bad case，人工写一份理想文档，然后强制让生成模型基于它输出。如果结果明显变好，那问题大概率在检索侧；如果还是不行，那生成模型本身就有问题。这一步能快速划分责任边界，避免盲目调参。
假设黄金文档实验告诉我们检索有问题，那我会看几个关键指标。首先是 Recall@K，比如K取5或10，看正确答案是不是在前几个结果里。如果召回率低于70%，那检索模块基本要重做。另一个是排序质量，可以用MRR或者NDCG，但说实话，线上我更多依赖人工抽检，拿一批真实用户query，自己判断理想文档应该是什么，再对比实际检索结果，这样最直观。常见失败场景比如用户问“退款多久到账”，结果检索出来一堆退货政策，那肯定是[[embedding]]和query理解之间的对齐出了问题。我还会看query和top1结果的向量相似度，如果低于0.6，说明语义空间没对齐，可能需要优化query改写或者换embedding模型。
如果检索没问题，那就看生成侧。核心指标是 [[Faithfulness]]，也就是生成内容是否忠实于检索文档。我会用NLI模型或者人工标注，看有没有胡编乱造的内容。另一个是答案相关性，就是答没答到点子上。比如用户问“这个订单为什么异常”，模型却开始解释异常订单的定义，那就是相关性差。这里有个坑：生成模型在长上下文场景下容易丢失信息，特别是文档中间部分。我会做个消融实验，逐步截断输入文档，看性能怎么变化，如果截到一半效果反而变好，说明模型对长上下文理解有瓶颈，那可能需要改进prompt或者用 [[Sliding Window]] 策略。
最容易被忽视的是协同环节的问题。有时候检索结果明明很相关，生成模型却选择性失明，或者多份文档信息冲突时生成混乱。比如客服场景，用户问“这两个优惠能同时用吗”，检索出来两份政策文档，一份说满减可用，一份说不可用，模型可能就胡编一个答案。这种问题我会看注意力可视化，或者做个文档去重实验，把冗余信息去掉看效果是否提升。还有一个常见问题是位置偏见，把相关文档放在第一位和不放在第一位，输出可能完全不同。
说到这，我顺便提一个我比较关注的方向：动态检索。就是生成过程中根据已生成的token实时调整检索策略，而不是一次检索完。这在多跳推理场景下特别有用，比如用户问“张三在A公司的职位是什么，他后来跳槽去了哪”，一次检索很难覆盖完整信息链。当然这也有代价，就是延迟会明显增加。
所以整体上，我会把RAG问题排查看成三步：先用黄金文档锁定责任方，再用指标和人工分析细化根因，最后针对性优化。如果检索和生成单独测都好但合起来差，那就去优化协同，比如改进prompt让模型更关注文档、加文档压缩、或者用动态检索。最怕的就是不看数据，上来就调embedding或者换模型。