RAG 答不准的三个环节 | 上下文与 RAG | 做产品

RAG 答不准的三个环节

知识库上线后，一定会收到「它答错了」的反馈。这时候最常见的反应是去改提示词——而大多数时候，问题根本不在那里。

你会遇到的现象

• 反复调提示词，效果就是上不去

• 同一个问题，有时答对有时答错，说不清规律

• 业务方说「这个文档里明明写了」，但它就是答不出来

按顺序往前查

RAG 是一条串行链路，任何一环断了，最终输出都是错的。所以排查要从前往后，而不是从最容易改的地方开始。

拿到一个答错的案例，按这四个问题依次问下去：

**① 库里到底有没有这条信息？**去向量库里直接搜一下相关关键词，把原始片段调出来看。你会惊讶于有多少「答错」其实是文档里压根没写，或者写在了一份没被收录的文件里。这一步能筛掉相当一部分工单。

顺带确认：那句话是完整存在于某一段里的吗？还是被切分拆到了两段？

**② 它有没有被召回？**把这次检索召回的全部片段打印出来（这需要你事先做了日志，见下文）。正确那段在不在里面？

**③ 它排在第几？**如果召回了但排在第 18 名，而你只取前 5，那它等于没召回。这是重排的问题。

**④ 材料给对了，回答还错？**把召回的那几段手动贴进一个对话框，把问题也贴上，看模型答得对不对。只有这一步答错了，才轮到改提示词。

这个顺序很重要。前三环出问题时改提示词，纯属白费力气——模型手上根本没有正确材料，你把提示词写出花来它也答不对。

每一环怎么修

① 库里没有 → 这是内容问题，不是技术问题。

要么文档确实没写（该去补文档），要么这份文档没被收录（该去补数据源），要么它以图片、扫描件形式存在而没被提取出文字。

这一环的修复往往不在工程侧。很多知识库项目的真正瓶颈，是没人愿意先把文档整理干净——这件事该在项目启动时就说清楚，而不是上线后才发现。

② 召回不到 → 检索策略问题。

几个常见原因和对策：用户用的词和文档用的词差太远（加关键词检索这一路）；问的是订单号型号这类精确串（向量对此无能，必须靠关键词）；切分时丢了标题导致片段没有主题信息（入库时拼上章节路径）；召回数量太少（先调大，宁可多召再靠重排筛）。

③ 排名靠后 → 加重排，或者调重排。

如果你还没有重排这一步，这通常是投入产出比最高的一次改进。如果已经有了，检查是不是被目录页、反向条款这类高相似度的干扰项挤掉了。

④ 材料对但答错 → 这才是提示词和模型的事。

常见情况：没说清「只能基于材料回答」，它掺了自己的知识；没给「不知道」的出路，材料不足时它编了；材料太多太长，关键那段埋在中间被忽略；或者问题确实需要跨段推理，超出了模型能力。

建一套评测

上面那套排查是针对单个案例的。要系统性改进，得有可重复的度量。

最小可用的做法：准备一组「问题 + 正确文档段」的配对，30 到 50 组，覆盖常见问法和几个刁钻的边界情况。

然后分两层看指标：

检索层——正确那段有没有进召回？排第几？这一层不需要调用模型，跑起来又快又便宜，可以高频跑。调切分、换向量模型、改召回数量，都用它来判断。

回答层——最终答案对不对。这一层要人工判或者用模型辅助判，慢且贵，改动大的时候跑。

分开看的价值在于：**检索层的分数上不去，回答层怎么都好不了。**先把检索层做到位，是最有效的顺序。

最后，两件必须在上线前做好的工程准备：

**一、把每次检索的召回结果和排名记进日志。**没有这个，上面那套排查一步都走不了——你连当时召回了什么都不知道。

**二、让回答带出处，并且出处能点开看原文。**这样业务方自己就能判断引用对不对，问题反馈会从「它答错了」变成「它引用了第 3 段，但应该看第 5 段」——后者是可以直接行动的信息。

要系统性改进，指标得分成两层看

检索层 正确那段有没有进召回？排第几？ 不用调用模型，又快又便宜 调切分、换向量模型、改召回数量都用它判断

可以高频跑

回答层 最终答案对不对？ 人工判，或用模型辅助判再抽检 慢且贵，改动大的时候才跑 低频

检索层的分数上不去，回答层怎么都好不了——先把检索层做到位，是最有效的顺序。

上线前必须做好的两件工程准备 ① 把每次检索的召回结果和排名记进日志——没有它，排查一步都走不了

② 让回答带出处且能点开原文：反馈会从「它答错了」变成「它引用了第 3 段，但应该看第 5 段」

后一句才是这张图真正的收益：**「它答错了」没法行动，「它引用了第 3 段但应该看第 5 段」可以直接行动。**业务方自己就能判断引用对不对，你也省掉了大半排查时间。

切分：RAG 成败的第一步 第一环出问题的概率最高，也最容易被忽略。

相似不等于相关 召回和重排这两环的根本难点。

RAG：知识库的三步 回到整条链路，看每一环各自的位置。