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

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 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 的上下文窗口中，位于中部的检索块对较小模型来说实际上是不可见的，而对较大模型来说也只是断断续续可见。修复方法是重新排序或总结上下文，而不是为了让模型通过糟糕的定位强力运用注意力而付费。

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

在做出任何层级升级决策之前，团队都应该能够回答两个问题，而答案将决定该决策是否通过。

闭卷测试（Closed-book test）： 当你完全移除检索到的上下文时，当前模型能否正确回答？如果可以，那么你的检索往好里说是多余的，往坏里说则是模型在处理大量信息时所面临的噪音来源。更换更大的模型也无法改变这一点。

黄金上下文测试（Gold-context test）： 当你手工编写完美的上下文——包含精确的文本块、正确的顺序、且没有干扰项时，当前模型能否正确回答？如果可以，那么问题出在检索环节。修复方案应该在模型的上游。如果不行，那么问题出在提示词或模型本身的真实能力上——只有到这时，“层级升级”才是一个候选假设，而且即使如此，它也只是“重写提示词”、“分解任务”或“更换一个指令遵循能力更强但层级相同的模型”等众多假设之一。

那些将这两项测试制度化的团队发现，70–80% 的退化问题都可以在提示词或检索层得到解决。剩下的层级升级案例现在则是站得住脚的：存在一个书面假设（“黄金上下文测试在多跳推理中失败，较小的模型无法维持思维链”），而层级升级是对特定上游发现的慎重回应，而不是巴甫洛夫式的本能反应。

层级升级门槛

必须落实的规范是设立一个层级升级门槛——这是一个轻量级的流程，它将模型层级的更改从一个配置开关转变为一个留有记录的决策。这个门槛并不是官僚主义；它的形式与工程师在生产代码中已经接受的部署门槛完全相同。

该门槛由四个部分组成。书面假设：说明为什么更大的模型会有所帮助，指明失败模式以及闭卷/黄金上下文测试的结果。“用户报告显示产品推荐错误；黄金上下文测试通过率为 95%；检索测试通过率为 60%；层级升级并非正确的干预手段”应该和“层级升级是合理的”一样经常成为结论。成本预测：将层级升级转化为当前 QPS 下的单次请求和每月成本增量，并计入功能团队的预算，以便在决策时而非在收到账单时就能看到权衡。资深工程师评审：针对每次层级升级进行评审——这并非形式化的审批，而是因为层级升级决策具有复利效应，同行评审员能发现“上个季度为了同类问题我们已经升级过这个路由了”这类模式，而原始工程师在自己的工单历史中可能无法察觉。退化复盘：在变更三十天后回过头来问同样的问题：事后看来，上游问题是否是可以发现的？如果是，什么方法能让它更早暴露出来？

如果没有这个门槛，层级升级就是阻力最小的路径，并会成为默认选择。有了门槛，它依然可选——有时它确实是正确的——但团队已经先付出了诊断代价，上游的 bug 得到了修复而不是被掩埋。

FinOps 的逆向反射

这方面的财务层面不仅仅是阅读账单；它还关乎建立一种足够强大的逆向反射（counter-reflex），以平衡工程上的本能。有三种模式行之有效。

在同一个仪表盘上显示“每个正确答案的成本”和“评估通过率”。 当仪表盘显示“92% 通过率，每个正确答案 0.04 美元”而不是仅仅显示“92% 通过率”时，如果一次层级升级将通过率提高到 94%，但每个正确答案的成本却增加到 0.16 美元，这显然是在成本维度上出现了 4 倍的退化，只为换取 2 个百分点的质量增益。对于高风险功能，这种权衡可能仍然值得；但对于高流量功能，这几乎从来都不值得。

将层级升级预算作为功能团队的项目支出。 当负责路由的团队将层级升级成本作为其季度预算的一部分时，权衡发生在规划阶段，而不是账单阶段。那些在成本抽象化时会条件反射式升级模型的工程师，在成本具体化且归属于自己时，会条件反射式地去查看上游。

层级下调审查。 每年两次，梳理那些已经升级层级的路由并询问：随着此后上游提示词和检索能力的改进，这个路由现在能否重新降低层级？大多数团队从未问过这个问题，而按流量计算，至少有 20–30% 的路由在其当前层级上是过度服务的。这种练习让人感到不适，因为它承认了最初的层级升级可能只是一种权宜之计，但成本的回收是实实在在的，而且这种必须证明每个层级选择合理性的过程对规范的建立也有积极影响。

架构层面的认知

模型层级是你的技术栈中最昂贵的调试工具——按单次请求、按天和按季度衡量都是如此。一个首选此工具的团队正在做出一个他们没有定价的杠杆选择：用一次性修复上游问题的工程投入，换取该路由未来每一次请求中永久的计算倍率增加。在一年流量增长的过程中，这种计算结果很少是划算的。

解决办法不是禁止层级升级；有时更大的模型确实是正确答案，而那些拒绝升级层级的团队会使一类确实困难的任务得不到充分处理。解决办法是让层级升级成为对经过调查的失败的深思熟虑的回应，而不是对未经调查的失败的本能反应。闭卷测试、黄金上下文测试、层级升级门槛、每个正确答案成本的仪表盘以及层级下调审查都是支撑结构。每一个的成本都低于单个路由一个月不必要的层级升级。

一旦规范落地，架构层面的认知就是团队的调试词汇量扩大了。对话不再是“模型很差，试试更大的模型”，而是变成了“检索针对这种形状的查询返回了过时的文本块”，或者“自从 v2 变更以来，这个工具描述一直很模糊”，或者“自客户群转移以来，评估集一直没有更新”。这些对话会产生代码变更、提示词变更和基础设施变更，并随着时间的推移产生复利效应。而“升级到更高层级”则是一场产生账单的对话。