RAG 坏例分析怎么讲：回答错了到底是哪一层的问题

RAG，也就是检索增强生成，项目面试里一个很常见的追问是：用户问了一个问题，系统回答错了，你怎么排查？很多候选人会直接说“优化提示词”或“换更强模型”，但这往往不是第一步。RAG 是多层链路，任何一层出错都会导致最终答案不好。

先判断资料库有没有答案

第一步不是看模型，而是看资料库本身有没有正确答案。如果资料库缺失、过期或冲突，再强的模型也只能猜。面试里可以说：我会先人工确认标准答案是否存在，以及权威资料是哪一份。

如果资料不存在，应该补资料或拒答，而不是让模型自由发挥。

再看切分和召回

资料存在，但召回不到，可能是切分不合理。比如一个制度条款被切得太碎，模型只看到半句话；或者一个接口说明和错误码说明被切开，导致上下文不完整。

召回失败也可能是因为只用了向量相似，专有名词、编号、字段名没有匹配上。这时可以加入关键词召回，或者对重要标题、编号做额外索引。

重排和生成也要分开看

召回到了正确资料，但排在后面，可能进入不了模型上下文，这就是重排问题。资料排在前面，但模型仍然答错，才更多是生成约束问题，比如没有要求基于证据回答，或者资料冲突时没有拒答。

项目回答可以这样说：我会把坏例按资料缺失、切分错误、召回失败、重排错误和生成错误归类。每次修改检索策略或提示词，都用坏例集回归。线上看用户追问率、拒答率、人工纠错和工具失败率。这样回答能体现你不是只会调模型，而是能维护一条完整的问答链路。

面试里还要强调一个边界：RAG 不是为了让模型回答所有问题。资料不足、资料冲突、用户问题超出权限时，拒答比编造更可靠。一个成熟系统应该能解释为什么拒答，并把这类问题沉淀成资料补充或权限规则优化，而不是只追求回答率。

坏例归因不要混在一起

RAG 坏例最忌讳一句“优化提示词”。提示词只是最后一层，前面还有资料、切分、召回、重排和权限。面试时可以把一个错误答案拆成可验证的链路问题，这样修复动作才不会乱。

这篇文章后续还可以继续扩成一个 RAG 排查清单：每次线上回答错，不要只保存用户问题和最终答案，还要保存召回片段、排序分数、提示词版本和模型版本。没有这些中间证据，坏例复盘会很难落地。