10.1.2 为什么很多问题表面看是模型问题，本质上却是数据或检索问题？

先给结论：很多问题之所以“看起来像模型问题”，只是因为错误最终体现在答案上。但答案只是链路最后一层。真实根因往往更早，可能在数据缺失、知识过期、过滤错误、召回偏差，或者上下文根本没把关键证据给到模型。

这是 RAG 调优里最常见的一种误判。因为用户真正能看到的只有：

• 回答错了
• 回答漏了
• 回答像在编

于是团队很容易直接得出结论：

• 模型不够强
• Prompt 不够好

但这类判断很多时候只是在描述表象，不是在定位根因。

为什么表面现象容易把人带偏

模型是最后生成答案的环节，所以所有前面环节的问题，最后都会折射到输出里。这意味着：

• 数据问题会变成答非所问
• 检索问题会变成不知道答案
• 过滤问题会变成引用错版本
• 上下文构造问题会变成关键条件遗漏

如果你只看最终回答，不回头看链路，就会很容易误以为：

• 既然答案错了，那一定是模型错了

这和 RAG 的系统特性是矛盾的，因为 RAG 本来就不是单一模型能力，而是一条证据链路。

三种非常常见的“看起来像模型问题”的情况

第一种，模型回答得很笼统，其实是没有拿到关键证据

表面上看，像是模型不会回答；但真实情况可能是：

• 正确文档根本没被召回
• 召回结果只有表面相关段落

这时模型能做的，只是在不完整证据上尽量组织语言。

第二种，模型回答用了错误版本，其实是过滤和更新问题

表面上看，像模型理解错了时间边界；但真实情况可能是：

• 新旧版本知识同时进了候选池
• metadata 字段不完整
• 当前有效版本过滤没进检索阶段

这时你去调 Prompt，很难真正解决版本混用。

第三种，模型漏掉限制条件，其实是上下文构造不利于使用

表面上看，像模型没读懂材料；但真实情况可能是：

• 关键约束被放得太靠后
• 多段证据拼接后结构混乱
• 重复证据过多，稀释了真正关键的信息

这时问题不一定是模型能力，而是证据组织方式。

为什么先怀疑模型，往往会带来低效调优

如果你把大部分问题都归到模型层，通常会进入这些动作：

• 换更大的模型
• 一直改 Prompt
• 加更多格式约束

这些动作的代价往往不低，而且经常只能治表不治里。

更糟的是，它们还可能带来副作用：

• 模型更大，成本更高
• Prompt 更复杂，可维护性更差
• 局部案例更好，但整体稳定性并没有真正提高

一个更现实的根因判断顺序

你可以先按下面这个问题顺序判断：

1. 正确知识在不在库里
2. 正确知识有没有被召回
3. 正确知识有没有进入最终上下文
4. 模型是否忠实使用了这些知识

只有前三步都基本成立，第四步才更像模型或 Prompt 层的问题。

为什么数据和检索问题在 RAG 里占比经常更高

因为 RAG 的核心价值，本来就来自：

• 用外部知识补模型

这意味着一旦外部知识链路出了问题，模型再强也会受限。

例如：

• 知识没接进来
• 数据没清洗好
• 权限和版本没建模
• query 没被正确路由
• 正确结果没被稳定召回

这些问题都会直接决定模型能不能拿到可用证据。

所以很多真实项目里，最先带来明显提升的往往不是：

• 换更强模型

而是：

• 先把数据和检索层修正到位

一个很实用的判断信号

如果你的系统经常出现下面这些现象，优先怀疑数据或检索，而不是直接怀疑模型：

• 不同模型答得都不太行
• 同类问题总是错在同一个知识点上
• 新旧版本内容经常混答
• 一类问题只要换个问法就完全召不回来
• 明明资料里有答案，系统却像完全不知道

这些信号都更像：

• 知识准备或召回链路不稳

一个最小判断示意

def root_cause_hint(case):
    if not case["gold_knowledge_exists"]:
        return "data_gap"
    if not case["gold_evidence_in_recall"]:
        return "retrieval_problem"
    if not case["gold_evidence_in_final_context"]:
        return "selection_or_context_problem"
    return "prompt_or_generation_problem"

这个示意想强调的不是复杂逻辑，而是：

• 先排除前面几层
• 再把问题归到模型层

一句话总结

很多问题表面看是模型问题，只是因为错误最终出现在答案里；但在 RAG 里，答案只是最后一层，根因经常更早就埋在数据、过滤、召回和上下文链路里。