跳到正文

RAG效果差：检索vs生成怎么诊断？

检索、生成、协同环节的诊断方法与关键指标

原题：在使用检索增强生成（Retrieval-Augmented Generation, RAG）系统时，如果整体生成效果不佳，应该如何系统性地定位问题是出在检索模块、生成模块，还是两者之间的协同环节？请说明可能的诊断方法和关键指标。

评估与监控

30 秒回答

  1. 区分检索失败与生成失败的诊断方法
  2. 关键指标设计（召回率、相关性、忠实度、答案相关性）
  3. 消融实验与人工分析的结合
  4. 典型错误模式的识别（检索不准、生成幻觉、协同失效）

回答与解析

答案要点

  • 区分检索失败与生成失败的诊断方法
  • 关键指标设计（召回率、相关性、忠实度、答案相关性）
  • 消融实验与人工分析的结合
  • 典型错误模式的识别（检索不准、生成幻觉、协同失效）

核心诊断思路：分层定位，逐层验证

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工程、文档压缩、动态检索）

一句话总结：先用黄金文档锁定责任方，再用指标细分根因，最后针对性优化，避免盲目调参。

口语版讲法(约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或者换模型。

关键一句:动态检索在复杂推理场景下比一次检索更有效，但会引入延迟代价。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做一个电商客服RAG，用户问‘我的订单怎么还没到’，系统回答了一堆不相干的内容。你觉得问题可能出在检索、生成还是哪里？怎么一步步排查？

  2. 问法 2 · 层层追问

    RAG效果不好，你一般从哪里开始查？……如果检索结果看起来相关但生成还是乱说呢？……那有没有可能检索和生成都没问题，但两者配合出了问题？

  3. 问法 3 · 直球架构

    请系统性地说明RAG效果差时，如何分层定位是检索模块、生成模块还是协同环节的问题，包括关键诊断指标和具体实验方法。

同模块相关题目