检索答错了，先检查哪一层？

给模型接上资料，并不意味着模型就会使用对的资料。一次看似流畅的错误回答，可能来自资料、召回、排序，也可能来自最后的生成。

先确认答案确实存在

排查前，我会先做一次不依赖模型的人工检索：答案是否在当前资料中？它是否仍然有效？同名文档是否有多个版本？如果资料没有答案，系统就不应该被要求输出一个确定结论。否则，后续优化很可能只是让猜测变得更自然。

这一步还需要确定评价对象。对于“旧版与新版的参数有什么差别”，只找到其中一个版本并不够。对于“某项配置是否已经生效”，说明文档也不能替代实际运行状态。证据必须能够回答当前问题，而不只是与它主题相近。

把候选结果单独拿出来看

在生成回答之前，先检查被召回的片段。记录它们来自哪一份文档、对应哪一节，以及为什么可能相关。片段太短会丢失条件，太长会混入无关内容；把表格标题与数据拆开，也可能让原本正确的资料失去意义。文本切分不是单纯按字数截断。

向量检索通常适合找到语义相近的候选，但相近不等于足以支持结论。型号、错误码或版本号有时需要精确匹配。这也是为什么检索方式应依据资料特征选择，而不是认为一种搜索形式可以覆盖全部问题。

重排不是另一个资料库

重排的作用，是进一步比较已经找到的候选与当前问题。它不能补回从未进入候选集的关键文档。因此，先保证召回覆盖，再讨论排序质量。把候选数量一味调大，也会增加处理量，并不自动提高最终答案质量。

我会分别记录“正确资料有没有出现”“出现后排在哪里”“最终回答有没有依据这份资料”。三个问题对应三个改进位置，不能只用一个最终分数把它们混在一起。

检查结论是否越过证据

即使正确片段已经进入上下文，模型仍可能补充资料没有支持的细节。一个实用检查是：把回答拆成具体主张，再逐条寻找依据。不能找到依据的内容，要么标为推断，要么删除或改为说明信息不足。

RAG 的价值是给生成增加可利用的外部依据，而不是把系统变成不会出错的事实机器。排查时保留各层的中间结果，比只比较最后一段文字更有帮助。