10.1.1 RAG 效果不好时，应该先查检索还是先查 Prompt？

先给结论：大多数情况下，RAG 效果不好时应该先查检索链路，再查 Prompt。因为 Prompt 只能约束模型如何使用已经拿到的证据，而不能凭空补回没召回到的资料。

这条判断不是说 Prompt 不重要，而是说：

• 排查顺序必须讲先后

如果关键证据根本没进入候选结果或最终上下文，你再怎么改 Prompt，也只能让模型：

• 更会说
• 更会规避
• 更会把现有材料包装得像答案

但它并不能让模型突然知道一段根本没拿到的知识。

为什么很多人会本能地先改 Prompt

因为 Prompt 离最终答案最近，也最容易改。看到回答不理想时，人会自然觉得：

• 是不是我提示词没写清楚

这很正常，但它也容易带来一个误区：

• 把所有问题都当成“模型表达问题”

而真实的 RAG 错误里，很多问题更早就已经发生了：

• query 没理解对
• metadata filter 没生效
• 正确文档没有召回
• 正确 chunk 被 rerank 挤掉
• 关键证据被上下文截断

这类问题如果不先查清楚，Prompt 调得再漂亮，也只是局部遮掩。

一个更稳的排查顺序

遇到失败回答时，推荐先按下面这个顺序看。

第一步，先看正确证据应不应该在库里

先问：

• 这道题的答案是否真的存在于当前知识库
• 是否受时间版本、租户、权限、产品线约束
• 是否本来就应该拒答

如果知识本身不在库里，或者当前边界不允许回答，那就不是 Prompt 的问题。

第二步，看正确证据有没有进入召回结果

重点看：

• 正确文档是否被召回
• 排名大概在什么位置
• 是否被错误过滤掉

如果正确证据没召回，优先方向通常是：

• 检查 query 理解
• 检查检索策略
• 检查 filter
• 检查 chunk 和索引设计

第三步，看正确证据有没有进入最终上下文

有时候召回到了，但最终没给到模型。

这时要看：

• rerank 是否把关键结果压下去了
• 去重和聚合是否误删了关键信息
• top k / top n 截断是否过早
• 长上下文排序是否不利于模型使用关键证据

第四步，最后才看 Prompt 和生成策略

只有当关键证据已经稳定进入最终上下文，但回答仍然不忠实、漏答或外推时，Prompt 才通常是优先排查项。

这时可以重点看：

• 是否明确要求基于给定资料作答
• 是否要求资料不足时说明不确定
• 是否要求保留限制条件、时间条件、例外规则
• 输出格式是否诱导模型过度总结

什么情况下可以优先查 Prompt

不是所有问题都要先查检索。下面这些情况，Prompt 可以更早进入排查优先级：

• 你已经确认关键证据稳定进入最终上下文
• 模型经常忽略明显写在资料里的限定条件
• 模型总在回答里额外脑补超出资料的内容
• 同一批证据换一种 Prompt 就明显更稳

这时问题更可能在：

• 任务指令不清
• 证据使用约束不够
• 输出格式要求引导模型过度归纳

一个简单判断口诀

如果你想先建立一个最低成本的判断直觉，可以先记住：

• 没有证据，先别怪 Prompt
• 有证据但没留下，先查选择和上下文
• 有证据也留下了，还乱答，再重点查 Prompt

一个最小排查示意

def choose_first_debug_target(case):
    if not case["gold_evidence_exists"]:
        return "check_data_or_should_abstain"
    if not case["gold_evidence_in_recall"]:
        return "check_retrieval_first"
    if not case["gold_evidence_in_final_context"]:
        return "check_rerank_and_context_first"
    return "check_prompt_and_generation_first"

这个示意的重点是顺序，而不是规则写死。

两个很常见的低效做法

低效做法一，回答一错就直接改 Prompt

这通常会导致：

• 个别案例改善
• 真正的召回问题被掩盖
• 不同题型之间出现新的副作用

低效做法二，检索和 Prompt 一起乱改

这样最难复盘。因为最后即使结果变好，你也不知道：

• 是检索生效了
• 还是 Prompt 生效了
• 还是两者相互抵消后碰巧看起来更好

一句话总结

RAG 效果不好时，默认应先查检索链路，再查 Prompt。先确认关键证据有没有回来、有没有留下，最后再判断模型有没有把证据用对。