1.3.4 为什么 RAG 的问题往往不只出在模型本身？

当一个 RAG 系统回答不好时，最常见的第一反应就是：

“是不是模型不行？”

这个怀疑有时成立，但在很多情况下，问题其实并不在模型本身，而是在模型前面的链路。

因为模型看到的世界，本来就是被前面环节塑造出来的

大模型最终回答什么，取决于它实际收到了什么输入。

而在 RAG 系统里，模型输入不是凭空出现的，它通常要经过前面很多步骤：

• 数据采集
• 数据清洗
• 切块
• 元数据补充
• 建索引
• 查询理解
• 检索
• 排序
• 上下文构造

任何一环出问题，模型拿到的材料就可能已经失真了。

一些常见情况看起来像模型问题，其实不是

1. 回答不准确，可能是没找到关键资料

如果真正相关的内容根本没召回出来，模型再强也只能在不完整信息上作答。

2. 回答偏题，可能是噪声太多

如果输入里混入太多无关内容，模型很可能抓错重点。表面上看像“模型理解差”，本质上可能是上下文构造差。

3. 回答冲突，可能是资料版本不一致

如果知识库里混入旧版本和新版本内容，或者多个来源彼此矛盾，模型就可能把它们混在一起回答。

4. 回答像在编，可能是约束不够

有些时候资料其实够了，但 Prompt 没有明确要求模型基于材料回答，或者没有要求它在证据不足时停止补全，于是模型就开始“合理猜测”。

这些问题表面上都像生成问题，但根源并不一定在模型能力本身。

RAG 更像系统问题，不只是模型问题

RAG 和纯聊天最大的不同之一，就是它把回答质量建立在一整条外部知识链路上。

这意味着最终效果取决于多个层面一起工作：

• 数据层
• 索引层
• 检索层
• 排序层
• 上下文层
• 生成层

所以当你看到结果不好时，更合理的做法通常不是立刻换模型，而是先问：

• 资料是不是对的
• 资料是不是找到了
• 找到的是不是最关键的
• 给模型的组织方式是不是合理
• 模型是不是被清楚约束了

为什么“全怪模型”会让排查效率很低

如果你把所有问题都归结为模型，很容易出现两种低效动作：

• 频繁换模型
• 不断改 Prompt

但如果真正的问题在前面，这样做的收益通常会很有限。

相反，很多系统真正提升明显的地方，反而不是换了更大的模型，而是：

• 把切块做好了
• Metadata 更完整了
• 检索策略更稳了
• 重排加上了
• 上下文更干净了

这也是为什么理解 RAG 时，一定要把它当成链路问题来看，而不是只当成“模型回答问题”来看。

一个更稳妥的看法

模型当然重要，但在 RAG 里，模型更像最后一位“读材料并组织答案的人”。

如果前面递给它的材料本身就不完整、不干净、不相关或者顺序混乱，那么最终回答出问题并不奇怪。

所以更准确的说法应该是：

RAG 的问题有时会出在模型，但很多时候更早就已经在前面的链路里埋下了。