10.1 效果不好时先查哪里

先给结论：RAG 效果不好时，最怕的不是一时找不到答案，而是一上来就乱改。更稳的做法是先沿着链路判断问题卡在数据、检索、重排、上下文构造还是生成层，再决定该动哪根杠杆。

很多团队进入调优阶段后，最容易出现一种典型节奏：

• 回答不对，就改 Prompt
• 回答不全，就加 top k
• 看起来不够聪明，就换更大的模型

这些动作并不是永远不该做，但如果没有先做归因，它们很容易变成：

• 局部修一题
• 全局引入新问题
• 做了很多改动，却不知道为什么生效

所以这一节真正要解决的，是调优前最关键的一步：

• 先判断该从哪一层开始查

学这一节时，最值得先建立的判断

• 先查哪里，比怎么调更重要
• 很多表面像“模型问题”的错误，其实发生在更早的链路
• Chunk、Rerank、Prompt 分别解决的是不同阶段的问题
• 如果没有排查顺序，调优很容易沦为随机试参

这一节会回答什么问题

• RAG 效果不好时，应该先查检索还是先查 Prompt？
• 为什么很多问题表面看是模型问题，本质上却是数据或检索问题？
• 什么情况下应该先动 Chunk，什么情况下应该先动 Rerank，什么情况下该动 Prompt？

读完这一节后，你最好能更稳地判断：

• 遇到一个失败回答时，第一步该看召回结果、最终上下文，还是模型输出
• 为什么有些问题改 Prompt 没用，必须回头改数据、过滤或检索
• 当你准备动 Chunk、Rerank 或 Prompt 时，背后到底应该有哪些判断依据