RAG 排查

答错时最省事的反应是改提示词，而多数问题不在那里。按库里有吗、召回到吗、排第几、材料对还错这四步往前查，定位到环，解法自然出来。

知识库上线后一定会收到「它答错了」的反馈。最常见的反应是去改提示词——而大多数时候，问题根本不在那里。检索是一条串行链路，排查要按链路顺序走，而不是从最容易改的地方开始。rag-failure-points

读完你能回答：

为什么调提示词常常是白费力气？
沿着链路往前查，每一步分别排除掉什么？
前三步和第四步的修法有什么根本区别？
怎么把「今天答对了」变成一条可重复的指标？

别从最后一环开始查

提示词处在链路的末端。从这里动手，意味着前面的嫌疑全都还没排除。

拿到一个答错的案例，按顺序问下去，每问完一步就能排除掉一批可能：

一、库里到底有没有这条信息？直接去库里搜相关关键词，把原始片段调出来看。相当一部分「答错」查到最后是文档里压根没写这句，也可能它躺在一份没有收录进来的文件里。走到这一步就能筛掉不少工单。顺便还要确认：那句话是完整落在一个片段里的吗？还是被切分分到了两段，两段各留一半？

二、它有没有被召回？本次检索命中的片段全部打印出来。看看正确的那段在不在其中。

三、它排在第几？如果确实召回了，但位置很靠后，而你只截取前几名，那实际效果和没召回一样。

四、材料给对了，回答还错？把召回到的那几段连同问题一起，手动贴进一次对话，看模型能否答对。只有在这一步答错，改提示词才有意义。

这个顺序的价值在于：如果问题出在前三环，改提示词一点用都没有——模型手里压根没有对的材料，提示词再怎么打磨也答不对。反过来说，前四步全过，说明这条链路本身没毛病，得往别处找。

前三步的病，都不在提示词上

前三步对应三种不同的病，修法也各不相同——但它们有一个共同点：改提示词对它们一律无效。

一、库里没有 → 这是内容上的缺口，不是技术上的故障。三种情形：文档里本来就缺这句话（该去补文档），文件存在但没被收录（该去补数据源），或者资料是图片、扫描件，文字还没被提取出来。这一环的修复往往不在工程侧。不少知识库项目卡住的地方，其实是没人肯花时间先把文档整理干净——这件事应该在项目启动时就讲明白，而不是等上线之后才碰上。

二、召回不到 → 检索策略问题。几个常见原因和对策：用户说的词和文档里的词差得远（加一路关键词检索）；查的是合同编号、设备序列号这种一字不能差的字符串（向量对此无能，必须靠关键词）；切分时丢了标题导致片段没有主题信息（入库时把章节路径拼上）；召回条数设得太少（先往上调，宁可比需要多召一些，让重排来筛）。

三、排名靠后 → 加重排，或者调重排。如果你还没有重排这一步，这通常是投入产出比最高的一次改进。如果已经有了，检查是不是被版权页、修订记录这类高相似度的干扰项挤掉了——它们的措辞往往比真正的答案更接近问题。

只有第四步的错，才轮到你改提示词

走完前三步，材料确认在库里、被召回、排在前面，问题却依然存在——这时候才轮到提示词和模型，常见的失手之处有这么几个：

没交代「回答只能依据这些材料」，于是它把自己记住的东西也掺进来；没给「不知道」留一条路，材料不够时它就开始编；材料给得又多又长，关键那段埋在中间被忽略；也可能是这个问题本身就要跨几段做推理，已经超出模型的能力范围。「中段被忽略」这个效应有专门的论文量化过。lost-in-middle

这一步的诊断之所以要放在最后，是因为它的证据最弱：只有把正确的材料递到它面前、它还是答错了，你才能确认问题出在它这一侧。

两样东西，上线前就得有

上面那套排查要能走得动，前提是链路留下了痕迹。其中两样必须在上线前做好，原因是它们事后补不回来：问题出现的那一刻，那次请求的上下文早就没了。

一、每次检索召回了哪些片段、各自排第几，都要写进日志。没有这份记录，前面那套排查一步都走不了——当时召回了什么，你无从得知。

二、让回答带出处，出处还要能点开看到原文。这样一来，业务方自己就能核对引用准不准。反馈的质量会完全不同：不再是笼统的「它答错了」，而是「它引用的那一段讲的是补充条款，主条款在另一节」——这种说法能直接拿去定位问题。

它们的价值也不止于排查——有了召回日志和可点开的出处，你才有可能分清问题到底是「没找到」还是「没答对」，进而把这两个问题分开优化。

单个案例之外，要有一把可重复的尺子

前面那套排查针对的是一个个案。想系统性改进，得有一把可重复的尺子。

最小可用的做法：准备一批「问题 + 正确片段」的配对，常见问法要覆盖到，再挑几个刁钻的边界情况放进去。

然后分两层看：

检索层——正确的那段进没进召回，名次如何。这一层不用调用模型，跑得快、花费少，可以高频跑。调切分方式、更换向量模型、调整召回条数，都靠它来给结论。

回答层——最终答案对不对。这一层得靠人工判，或者用模型先判再抽检，慢且贵，所以只在改动大的时候跑。

两层分开的意义是：检索层分数上不去，回答层不可能好。先把检索层做到位，这个次序最有效。而评估集本身也会随着产品变化而过时——问题问法会变、文档会变，所以这组配对需要持续维护，评估集本身要养讲的是这件事。

排查到最后，如果每一环都查过了、都修了，还是答不准，那要问的就是另一个问题：这件事真的该靠检索来解决吗？补知识几乎总是检索的活，但有些需求本来就不是知识问题，要补知识几乎总是 RAG讲的是这条分界线。