模型迁移的双重账单：被忽视的评测重锚税

我合作过的一个团队为一个受成本目标驱动的 Sonnet 到 Haiku 的迁移预算了两周时间。模型更换和提示词重调按时完成。但评估重锚又花了七周时间。该项目的总成本是发布后首季度每 token 节省预期的 4.5 倍。采购方案中从未提及这七周时间；它们以“工程人力”的形式出现在另一个成本中心，这正是此类超支对 FP&A 隐身并不断重复的原因。

包含“重锚定”阶段的迁移指南​

修复方法是流程性的，而非技术性的。那些能够正确评估迁移成本的团队，会将“重锚定”（re-anchoring）视为一个明确的阶段，拥有独立的预算和退出标准。

提交前的并行运行期。在至少一个完整的评估周期内，旧模型和新模型针对同一评估集进行打分。记录每一个案例的差异。在切换 之前，而非之后，将两个模型意见不一致的情况标记出来供人工审查，因为团队的直觉仍然是基于旧模型校准的，而这种校准正是解决歧义的关键杠杆。如果差异率超过某个阈值（团队根据其能负担的审查量来确定该数值），则暂停切换。

裁判模型校准仪式。在将新模型的裁判分数视为生产信号之前，应针对同样的评分标准（rubric）对新鲜的人工样本（通常几十个案例就足以检测出系统性偏差）进行评分，并将裁判对这些案例的分数与人工分数进行对比。如果相关性与迁移前的基准相比发生了偏移，则更新裁判提示词或评分标准。如果相关性发生了偏移 且团队无法解释原因，则暂停迁移，直到找到原因为止。

快照测试套件分诊，而非批量重写。要抵制在单个 PR 中针对新模型“重新生成所有快照”的诱惑。这种做法会默默地将套件重锚定到新模型上，而没有与旧模型进行任何对比——这正是该套件本应防止的失败。相反，应该逐一检查失败的快照，确定该差异是回归（regression）还是仅仅是措辞变动，并为快照固件（fixture）标注捕获它时所使用的模型版本。测试套件的目的是让模型更换变得 可见，而不是为了让它变绿。

版本化评分标准。评分标准文档——即关于“好”的定义的书面描述——应该是一个被签入的代码资产，与提示词和模型一起进行版本化。每个评估分数都应标注其评分时所依据的标准版本。如果没有这一点，团队最终不得不回答“六个月前我们对质量的定义是什么”，却无法给出答案，因为标注者头脑中的标准已经发生了偏移，且没有留下任何记录。

预算内的人工审查成本。迁移任务单中应包含人工审查工时的分列项目，其估算是根据评估集的大小和团队历史标注速率计算得出的。这是采购部门永远看不到的项目，因为工程团队将其作为“产能”内部消化了；但如果诚实地将其列出，它将改变哪些迁移实际上能通过成本效益评估。

财务计划与分析（FP&A）团队缺失的成本视角​

模型迁移并不是免费的替换。它是一个具有可量化成本的“重锚定”事件。该成本由三部分组成：更换模型的工程工作、针对新模型特性重新调优提示词的工程工作，以及将评估系统重锚定到新模型输出分布上的人工审查工作。前两项通常会被计入迁移计划，而第三项几乎从未被计入，但在大多数迁移中，它却是三者中成本最大的。

让财务部门理解这一点的框架是将评估集视为一种贬值资产，就像训练语料库一样。它有一个锚定模型，当锚点改变时，资产必须重新估值。重新估值会产生劳动力成本。这项劳动力成本是迁移中隐藏的分列项目，如果团队不将其公开，那么每当供应商发布新模型时（在当前的节奏下，至少每季度一次），他们都会被同样的超支问题所困扰。

在采购沟通中一个有用的表达方式是：新模型节省的每 Token 成本，必须能够覆盖摊销后的重锚定成本，加上过渡期间并行运行两个模型的持续成本。对于小型迁移（单一功能、精简的评估集、小团队），这个门槛很低。对于涉及数十个提示词和庞大评估语料库的平台迁移，门槛可能高到节省的成本不足以证明此时迁移的合理性，而正确的答案是推迟迁移，直到可以将两到三个模型版本合并到一次重锚定事件中。

架构启示​

将评估系统视为与模型耦合的配置。这种耦合是隐性的——它存在于人工锚定的参考分数、裁判校准、快照措辞以及团队直觉中——但它是真实存在的，忽略它并不会让劳动力消失。它只是将劳动力转移到了不同的季度和不同的成本中心。

内化了这一点的团队不再将模型更换视为工程计划中的单行任务，而是将其视为一个结构化的重锚定事件，具有明确的阶段、并行运行的准入闸口、裁判校准仪式以及预算内的人工审查成本。迁移在日历时间上变慢了，但在“意外季度”的账目上变便宜了，而这正是大多数团队在经历过上一次迁移后发现自己本该做的权衡。

不这样做的团队则会支付双倍代价。采购方案在每 Token 成本上赢了，但组织在劳动力成本上输了。而且，在团队还没完成上一次迁移的收尾工作之前，下一个供应商关于更快速、更便宜模型的公告就已经发布了。