14.1.6 RAG 效果差时，为什么不能第一反应就怪模型？

先给结论：RAG 的质量瓶颈，很多时候不在模型，而在“数据质量 + 检索链路 + 评估与观测”。

一旦系统回答不好，最容易被怀疑的就是模型。
原因也很简单：模型输出是用户直接看到的最后结果。
但这恰恰也是最容易造成误判的地方。

因为在 RAG 里，模型是链路最后一环。
前面任何一步出问题，最后都会集中体现在答案上。

为什么模型最容易“背锅”

1. 它是最后一环

用户看到的是答案，不是检索日志，不是上下文快照，也不是切块结果。
所以所有前序错误，最后都会表现成“模型回答不对”。

2. 很多系统没有可观测性

如果你没有下面这些能力：

• 检索结果日志
• 重排结果记录
• 生成前上下文快照
• 评测集与回归对比

那你几乎不可能准确判断问题到底在哪一层。
在这种情况下，模型自然就成了最容易被怀疑的对象。

3. 模型问题最显眼，链路问题最隐蔽

“答案不准”很容易感知，
但“文档过旧”“切块破坏语义”“metadata 不完整”“检索范围错了”这些问题，如果没有专门观察，很容易被忽略。

真实项目里，更常见的根因是什么

很多所谓“模型不行”的案例，最后查出来其实是下面这些问题：

• 文档噪声太多，清洗没做好
• 新旧版本文档混在一起
• chunk 切得太碎或太厚
• metadata 缺失，导致范围过滤做不了
• 召回不稳定，换个问法就漂
• 没有评测，导致问题只能靠印象判断

这些问题如果不先解决，换更强模型通常也只是“更流畅地说错话”。

一个更可靠的排查顺序

当 RAG 效果不好时，更稳妥的顺序通常是：

第一步：查数据

• 文档内容本身是否正确
• 是否混入旧版本、重复内容、目录噪声、OCR 错误
• 文档更新时间和生效范围是否清楚

第二步：查索引前处理

• 切块是否把关键条件切断
• 标题、章节、版本、时间等 metadata 是否保留
• 是否对不同类型文档采用了合理的切分策略

第三步：查检索

• 候选里有没有真正正确的证据
• 同一个问题重复查询时结果是否稳定
• 是否需要加过滤、重排或混合检索

第四步：查生成

• 提示词是否要求基于证据回答
• 上下文是否太长、太乱、冲突过多
• 证据不足时是否允许模型直接说明不足

只有前面这些都基本正常，才值得认真考虑是不是模型本身限制了效果上限。

一个非常常见的错误动作

很多人看到答案不准，马上就做下面这些事：

• 换更大的模型
• 改提示词
• 多写几句“请准确回答”

这些动作不是一定没用，但如果问题根本出在检索和证据上，它们往往只是治标不治本。

你需要警惕一种错觉：
模型越强，系统就越好。
现实里，模型越强，只能让它在已有证据条件下表现得更好；
如果证据本身错了、旧了、碎了，模型再强也不会自动把链路修好。

真正该优先补的是什么

成熟系统真正优先补的，通常不是模型能力，而是下面这些基础设施：

• 问题复现能力
• 检索与生成日志
• 最小评测集
• 改动前后对比能力
• 失败案例归档

有了这些，你才知道自己到底是在优化系统，还是在凭感觉碰运气。

一句话总结

RAG 效果差时，先查数据和检索链路，再查模型。没有观测与评估，模型只会成为最容易被误判的那一层。