“换个更大的模型试试”这种直觉反应是一种重构异味

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 Opus，看看能不能解决。”四十分钟后，评估通过率回升了，团队关闭了工单，而该路径上的推理账单悄然翻了三倍。六周后，同样形式的回归出现在另一个路径上，并采用了同样的修复方法。你的团队刚刚训练出了一种巴甫洛夫反射：质量回归 → 增加算力。更大的模型是你的技术栈中最昂贵的调试工具，而你现在却首先想到它。

问题不在于更大的模型没有帮助。它们确实有——有时甚至很大。问题在于，更大的模型是一种绝对占优的“掩盖”策略。当提示词指令冲突、检索返回了过时的块、工具描述被误读，或者评估集没有覆盖失效的分布时，更强大的模型会绕过这些故障而不修复其中的任何一个。下一次回归仍具有相同的根本原因，账单已经复加，而底层系统变得更加脆弱，而非更加稳健，因为升级带来的缓冲空间让所有人都不再去探究底层逻辑。

为什么这种反射如此难以摆脱

这种反射之所以难以摆脱，是因为它在房间里声音最大的指标上奏效了。质量问题的平均修复时间（MTTR）下降了；团队感到富有成效；仪表板变绿了。与此同时，那个本应声音最大的指标——单次正确答案成本——却存在于另一个由 FinOps 掌握的仪表板上，他们每月查看发票，而评估通过率则是每小时更新一次。行动与其真实成本之间的滞后时间刚好足够在账单到达之前形成习惯。

它之所以难以摆脱，还因为替代方案更难。调查上游原因意味着：调取追踪（traces）、运行闭卷测试（模型在没有检索上下文的情况下知道答案吗？）、运行黄金上下文测试（如果你手工构建完美的上下文，它能正确回答吗？）、批判性地阅读工具描述、将系统提示词与上一个已知良好的版本进行比对。其中每一项都需要资深工程师三十分钟的注意力。而更换模型只需切换一个配置标志并重新运行评估。工程精力也是真金白银，而团队隐含地在算力成本与工程师时间成本之间进行了错误方向的套利——因为算力成本会在未来的每一次请求中复加，而调试时间是一次性支出，用于偿还本金。

第三个原因是：更大的模型确实更具包容性。比原模型高出两个层级的模型可以容忍一个顺序混乱的提示词，而较小的模型则无法从中恢复。它会掩盖一个对必需参数界定模糊的工具描述。它会略过包含一个坏块的检索集。团队误以为这种包容是“模型修复了它”，而实际上发生的是模型将 bug 吸收到了自己的冗余度中，且该 bug 仍在那里等待下一次回归——或者更糟，等待你下次尝试回滚模型时爆发。

更大模型隐藏的五个上游 Bug

当团队转向更大的模型时，在生产环境的 AI 工作中，底层的 bug 通常是五种形式之一，而更大的模型只是掩盖而非修复了每一个。

错误的检索。 斯坦福大学的研究和实地报告得出了相同的结论：在大规模应用中，RAG 的质量问题在于检索架构——分块大小、向量空间划分、top-k 调优、嵌入模型不匹配——而不是生成器的智能。更大的模型有时能从三个无关块包围的一个好块中挤出连贯的答案，但检索流水线返回四个无关块才是 bug，一个配备固定检索器的较小模型在质量和成本上都能击败一个配备故障检索器的较大模型。

模型误读的工具描述。 模型在每次调用时都会读取工具模式（schemas）；描述本身就是提示词。一个对 customer_id 是内部 UUID 还是外部计费 ID 模糊不清的描述，在较小模型上会产生 30% 的错误工具调用，而在较大模型上则产生 8%。这两个比例都是 bug。修复方法是重写描述，而不是花费 4 倍的代价将错误率从 30% 降至 8%。

指令冲突的系统提示词。 Datadog 最近的 AI 工程现状分析发现，系统提示词现在占用了客户追踪中约 69% 的输入 Token。随着提示词因三个团队编辑不同部分而超过 2K Token，指令冲突会不断加剧：防御规则说“务必引用来源”，而品牌语调规则说“回答保持在两句话以内”。更大的模型更容易选对冲突中的正确一方，但冲突本身才是 bug。

未覆盖失效分布的评估集。 如果你的评估通过率是 92%，但用户感知的质量是 78%，那么评估集已经偏离了实际分布。更大的模型会将评估通过率提升到 96%，但对评估未衡量的实际分布毫无帮助。团队会庆祝；用户会继续抱怨。

“迷失在中间”的定位问题。 模型对长上下文的头部和尾部的关注度高于中部。在 30K Token 的上下文窗口中，位于中部的检索块对较小模型来说实际上是不可见的，而对较大模型来说也只是断断续续可见。修复方法是重新排序或总结上下文，而不是为了让模型通过糟糕的定位强力运用注意力而付费。

闭卷测试与黄金上下文测试

加载中…