更便宜的评审模型所隐藏的成本
评估流水线正面临削减开支的压力。一种常见的做法是用更便宜的模型替换昂贵的评审模型。推理账单下降了，流水线仍然产出分数，仪表盘依旧一片绿色。看不见的是，这些分数已经不在同一量纲上了。评审模型不是中立的测量仪器。它是一个带有自身偏见、解码行为和失效模式的模型。替换它改变的是测量本身，而不仅仅是成本。
本文主张，只有当评审模型被视为一种带版本的依赖——被固定、被记录、被回归测试——替换评审模型才是正当的。没有这套纪律，省下的成本就要以可比性的丧失为代价，而可比性正是评估流水线的全部意义所在。
为什么替换评审模型会破坏历史数据
两个评审模型版本产出的分数无法直接比较，即使评分标准的文本逐字节相同。评审模型会带入自己的先验：它如何严格地解读某条评分标准，如何权衡部分得分，如何处理歧义。一条写着“答案必须引用来源”的评分标准，在一个只对 URL 是否存在做模式匹配的小模型和一个会检查所引来源是否支持该论断的大模型那里，读法是不同的。评分标准相同；测量不同。
这不是理论上的担忧。它是 agent 评估中分数出现无法解释的变动的最常见原因。一个混合了不同评审模型版本的排行榜，测量的是评审模型，而不是被测系统。当新评审模型被悄悄部署时，历史分数就变成了两个分布的混合体。跨时间的趋势变得无法解读。第六周出现的回归，可能是第五周的一次评审模型升级。
实际后果是：任何跨运行的比较都要求评审模型版本保持恒定，或者对量纲偏移进行显式建模。大多数团队两者都没做。他们把评审模型当作可以原地升级的基础设施，就像运行时补丁一样。但运行时补丁不会改变某个指标的含义。评审模型升级会。
把评审模型当作一个组件
解决办法是像严肃系统对待 schema 或模型 checkpoint 那样对待评审模型。这意味着在每一条结果记录中记录产出该分数的评审模型的完整身份：
- 模型标识符和提供方修订版本；
- 解码参数（temperature、top-p、max tokens，以及 seed 如果可用）；
- 评审模型 prompt 和评分标准文本的哈希；
- 评分标准修订号。
缺少这些字段的结果记录不可复现。它只是一则轶事。
一个具体的机制是把评审模型的原始输出与候选输出一起存储。如果评审模型返回结构化裁决，就持久化完整响应，而不只是解析后的分数。这样就能在不重跑被测 agent 的情况下重新评分。当评审模型升级时，旧的候选输出可以在新评审模型下重新评分，两组分数可以直接比较。如果不存储评审模型输出，一次评审模型迁移就会强制进行完整的 agent 重跑，而这通常是流水线中昂贵的那部分。
像给 schema 做版本管理那样给评审模型做版本管理。当量纲发生偏移时，写一份迁移说明：改了什么、为什么改、对分数的预期影响是什么。迁移说明不是官僚主义。它是仪表盘的读者区分真实回归与测量变化的唯一途径。
便宜的评审模型需要自己的评估
更便宜的评审模型是一个新组件，而新组件需要自己的评估。关键问题不是这个便宜评审模型总体上好不好，而是它在流水线实际覆盖的任务族上是否与一个可信的参照一致。参照可以是一个留出的人类样本，或一个被节制地用作 oracle 的更昂贵的评审模型。
按任务族分别测量一致性，而不是看总体。一个评审模型可能在分类上可靠，在多步正确性上却毫无用处。总体一致性会掩盖这一点。如果流水线覆盖十个任务族，便宜评审模型在九个上与 oracle 一致，却在最重要的那个上出现分歧，那么总体数字就是误导性的。
设定一个会阻断流水线、而不是只向仪表盘发警告的分歧阈值。警告是一种在截止日期压力下会被忽略的信号。阻断是一种必须被解决的信号。阈值应按任务族分别定义，并配有文档化的回退方案：当便宜评审模型的分歧率超过阈值时，流水线把该任务族路由给昂贵的评审模型或人工审核。这样就把成本节省保留在安全的地方，并在不安全的地方取消它。
这里有一个诚实的权衡。因分歧而阻断会增加延迟和运维摩擦。它需要维护一个 oracle 样本，并在评分标准变化时重跑一致性检查。跳过这一步的团队并没有省下功夫；他们
etwork-cables-macro-e398d9-23b10f.jpg)
评审模型成本通常只占 agent 运行成本的一小部分。被测 agent 可能发起大量模型调用、使用工具并重试。评审模型对每个候选输出只调用一次。在 agent 之前优化评审模型，往往是错误的操作顺序。更大的杠杆通常是 agent 自身的 token 和工具预算，而不是评审模型的推理开销。
便宜评审模型带来的真正节省是评分标准的迭代速度，而不是推理开销。便宜评审模型让团队可以在打磨评分标准措辞时，对一组已存储的候选输出反复重新评分。这是实实在在的好处：评分标准迭代才是评估质量真正被改进的地方。但它依赖于已存储的评审模型输出和一个被固定的评审模型版本。没有这些，便宜评审模型加速的是一个产出不可比数字的流程。
如果便宜评审模型改变了你发布什么，那么节省就是负的。一个更便宜但更嘈杂的评审模型会以不同方式批准或拒绝候选。如果这种差异改变了一次发布决策，决策错误的代价会让推理节省相形见绌。正确的比较不是评审模型成本对评审模型成本，而是评审模型成本加决策错误对评审模型成本加决策错误。
一套最小纪律
这一切都不需要大型平台。它需要四个习惯：
- 在每条结果记录中固定评审模型身份，包括 prompt 和评分标准的哈希。
- 把评审模型输出与候选输出一起存储，以便在不重跑 agent 的情况下重新评分。
- 维护一个 oracle 样本，按任务族测量一致性，并设置阻断阈值。
- 每当评审模型版本变化时写一份迁移说明，并对一个固定的候选集重新评分以量化量纲偏移。
这与应用于任何影响输出的依赖的纪律相同。数据库驱动升级在进入生产前要经过测试。评审模型升级会改变流水线中每一个分数的含义。把它当作一次随意的替换是一种范畴错误。
削减成本这个问题是正当的。评估预算真实存在。但更便宜的评审模型带来的节省只有在可比性得以保留时才是真实的。否则，流水线产出的数字看起来像测量值，行为却像噪声。
延伸阅读
封面照片：panumas nikhomkhai / Pexels。