11. 用户反馈"答非所问"，你怎么定位是检索问题还是生成问题？
整理用户反馈"答非所问"，你怎么定位是检索问题还是生成问题？的面试回答思路与拆解方式。
简单回答
"答非所问"的归因方法和前面第 5 题一样——先看上下文。把这次请求的完整 Prompt 打印出来：如果检索到的 Chunk 和用户问题就不相关，那是检索问题；如果 Chunk 相关但模型没有基于 Chunk 正确回答，那是生成问题。具体做法是建一个 bad case 分析表，对每个"答非所问"的 case 标注是"检索不相关"还是"检索相关但生成错误"，统计比例后做针对性优化。
详细解释
快速定位
拿到一个"答非所问"的 case，最快的定位方式就是看检索结果。几乎所有成熟的 RAG 系统都应该有日志记录每次请求的检索结果和最终 Prompt。打开日志，看这次请求检索到的 Top-5 Chunk 和用户的原始提问之间有没有关系。
如果 Top-5 全是不相关的内容——比如用户问"怎么申请年假"，检索到的 Chunk 是关于"出差报销流程"的——毫无疑问是检索问题。
如果 Top-5 中有一个 Chunk 明确包含了正确答案（比如包含了年假申请流程），但模型没有基于这个 Chunk 回答或者回答了别的——那就是生成问题。
如果 Top-5 中有"部分相关"但信息不完整的 Chunk——比如 Chunk 提到了"年假"但没有说"怎么申请"——这是一个检索精度不够的中间地带，需要进一步分析是 Chunk 切分问题还是 Embedding 匹配问题。
批量分析 bad case
单个 case 的分析只能定位具体问题。要做系统性优化，需要批量分析——收集 50~100 个"答非所问"的 bad case，每个都标注根因分类，然后统计各类原因的占比。
如果 70% 是"检索不相关"→ 优化重点在检索（Chunk 策略、Embedding 模型、混合检索）。如果 60% 是"检索相关但生成错误"→ 优化重点在 Prompt 或模型。如果两者各占一半 → 两边都需要优化，但优先做检索（因为检索是上游，检索好了生成端的压力也会减小）。
常见的细分原因
检索端导致"答非所问"的常见原因：query 和文档的语义鸿沟（用户说"退钱"，文档写"退款"）→ 加 Query Rewrite 或 BM25。Chunk 切分导致关键信息被切断。Embedding 模型对领域术语理解不好。知识库没有覆盖这个问题。
生成端导致"答非所问"的常见原因：上下文太长关键信息被淹没（Lost in the Middle）。Prompt 指令不明确模型"跑题"了。模型没有遵循"基于上下文回答"的指令，用了自己的知识。模型对多个 Chunk 中的信息做了错误的综合。
面试时可以这样答
定位的方法很直接——看检索结果。拿到一个答非所问的 case，打开日志看这次请求的 Top-5 Chunk 和用户问题有没有关系。不相关就是检索问题，相关但模型没用好就是生成问题。
单个 case 这样分析就够了。但要做系统性优化得批量分析——收集几十个 bad case，每个标注根因，统计占比。实际中检索问题通常占大头，这也是我一直强调先把检索做好的原因。
要注意还有一种中间情况——检索到了"部分相关"的内容但信息不完整。这可能是 Chunk 切分不好，关键信息被切到了相邻的 Chunk 里。这种情况用 Parent-Child 分层切分或加大 overlap 通常能缓解。
常见追问
- 如果一个 case 检索和生成都有问题怎么办？
- 你们的 bad case 分析频率是多久一次？
- "答非所问"和"回答不完整"的根因通常不同吗？