看似一体的两项工作
执行动作的 agent 与对动作打分的 agent，往往基于同一个 checkpoint、同一套 prompt 脚手架和同一套 serving 栈构建。这很方便，但它是错误的默认做法。决策模型与证据模型有着不同的需求集合，把它们当作同一个产物，会以悄然使评估失效的方式将二者的失效模式耦合在一起。
决策模型在策略下优化动作质量：给定一个状态，在延迟与成本预算内产出下一个能推进目标的 tool call、消息或计划步骤。证据模型则优化校准度、稳定性以及对表述框架的抵抗力。它必须产出在行动者措辞变化时保持不变的判断，并在不确定时诚实地降级。
这不是同一件事的两种规模，而是两份不同的规格。
决策模型与证据模型有着不同的需求集合
决策模型由下游发生的结果来评判：工单是否关闭、测试是否通过、retrieval 是否返回了正确的文档。它的有用属性是吞吐量、tool-use 可靠性，以及从糟糕的中间步骤中恢复的能力。延迟很重要，因为模型处在循环之中。一个慢的决策模型就是更差的决策模型，即便它的推理更好，因为循环是有预算的。
证据模型由其对参照的评分质量来评判。它的有用属性是校准度（0.7 的分数大致意味着 0.7）、稳定性（同一输入在不同运行和排序下得分相同），以及独立于行动者的表述框架。它应当慢到足够谨慎，又便宜到足以在整套测试规模上运行。
这些需求指向相反的方向。决策模型受益于激进的上下文压缩以及自信、果断的输出。证据模型受益于保守的输出和明确的不确定性。一个被训练或被 prompt 成果断的模型，从构造上就不适合承担说出“我不确定这是否正确”的工作。
为什么共享权重会破坏评估
当评判者源自行动者时，它会继承行动者的盲区。如果行动者系统性地误读某种日期格式，一个拥有相同权重和相同训练分布的评判者往往会接受这种误读。这种失效不会表现为错误答案，而会表现为通过的分数。评估在系统已经损坏时报告健康。
这不是假设。这是自我评分循环的常态：同一个模型被要求检查自己的输出。检查与错误相关，因此检查几乎不增加信息。在最坏的情况下，它增加的是负信息：分数之所以高，恰恰是因为行动者和评判者共享同一个错误的先验。
自我改进循环会放大这个问题。如果行动者针对评判者的分数进行微调或 prompt 优化，它学到的是评判者的偏好，而不是任务本身。梯度指向评判者恰好奖励的任何东西，包括它的怪癖。经过多次迭代，系统变得更擅长满足评判者，而在工作上毫无进步。评估指标上升了，产品没有。
独立评判者每次运行的成本更高。在大多数情况下，它们是唯一能检测系统性错误的机制，因为它们不共享该错误。这正是分离的全部意义。
一种分离模式
把评判者当作一个拥有自身生命周期的依赖项。
独立地对评判者进行版本管理，并按套件固定
评判者不是一个配置开关。它是一个带有版本、prompt、模型和解码配置的产物。按评估套件固定这四项，就像你在 lockfile 中固定库版本一样。当评判者变化时，该套件的分数就不再与上一次运行可比，系统应当明说这一点，而不是跨版本静默地做 diff。
一个具体的机制：在每个套件旁存储一份评判者清单。
suite: checkout-agent-v4
judge:
model: evidence-judge-2024-11
prompt_hash: 9f2c1a
decoding: {temperature: 0.0, top_p: 1.0}
rubric_version: 3
actor:
model: checkout-actor-2024-11
prompt_hash: 4b7jpg)移
行动者漂移是常见的嫌疑对象，但评判者漂移才是污染测量的那一个。留出一个小的、人工标注的集合，行动者从不在其上训练，评判者也从不在其上调优。按计划在其上运行评判者。如果评判者与人工标注的一致率超出其历史区间，评判者就发生了漂移，自上次干净运行以来它产出的每一个分数都可疑。
留出集不需要很大。它需要稳定，由独立于评判者的流程标注，并且检查得足够频繁，以便在漂移影响部署决策之前被发现。
### 为每个分数记录评判者身份
历史比较只有在测量工具相同的情况下才有效。存储分数时，一并存储评判者清单的哈希。仪表盘应当拒绝跨评判者版本边界绘制趋势线，或者显式地渲染出该边界。这是不起眼的管道工作，而它正是指标与断言之间的区别。
## 需要接受的权衡
独立评判会给每次评估运行增加延迟和成本。独立的评判者意味着每个条目多一次模型调用，或者对套件做一次批处理作业，再加上对其进行版本管理和 serving 的基础设施。对于大型套件，这是一笔实实在在的开支，而它是能够检测行动者系统性错误的测量所付出的代价。
评判者版本管理会带来迁移工作。当评判者升级时，升级前后的分数不能直接比较。要么让旧评判者继续存活以对历史套件重新评分，要么对套件重新建立基线并记录这一不连续性。两者都是工作。如果评估意在为部署决策提供依据，两者都无法避免，因为基于不可比数字做出的决策，是披着仪表盘外衣的猜测。
替代方案更便宜也更糟糕：一个与行动者共享权重、从构造上就与之一致、并报告成功的评判者。那个系统没有被评估，它被奉承了。
## 边界是一种设计选择
做决策的模型与做评判的模型之间的界线，是设计边界，不是规模边界。它不在于用更大的模型去给更小的模型打分，或者反过来。它关乎两个目标不同、失效模式不同、生命周期不同的产物。刻意划出这条边界的团队，得到的是可以据以行动的评估。把它合并掉的团队，得到的是一个上升的数字，以及一个没有上升的系统。
_封面照片：Jakub Pabis / Pexels。_