评估员吞吐量是评估流水线中隐藏的瓶颈

团队像规划服务一样规划评估集（eval suite）：梳理失败模式、起草评分标准（rubric）、争论样本量大小、安排评判员校准（judge calibration）时间表。然后，他们把评测员产能（rater capacity）当作脚注——“我们会让标注团队每周评测几百条”——然后就发布了剩下的部分。六周后，评测员队列堆积了 4,300 个条目，评估速度坍缩到每月仅一次评判员校准周期，在一次规划评审会上，有人道破了那个大家都心照不宣的事实：没有人对人力进行过产能规划。

在任何严肃对待人工评分的 AI 系统中，评测员吞吐量都是评估速度的约束性瓶颈。将标注视为 SRE 问题而非招聘问题的准则，才是产品发布的关键。一名人类评审员在专家难度下每小时处理 50–100 个样本，而一名专家标注员每周的上限约为 500–1,000 个样本——这些数字不是通过增加人头就能蛮力解决的招聘问题。它们是评估系统的运行属性，必须像建模数据库 IOPS 一样对其进行建模和预算编制。

队列增长速度快于评估集

在你动笔画出来之前，这个问题的形态是不直观的。每个评估集都有两个增长率：工程师添加新案例的速度（来自事故的新失败模式、新产品界面、新评判员校准），以及评测员清空队列的速度。前者是复合增长的，因为每一次发布的模型迁移、Agent 调用的每一个新工具、A/B 测试下的每一个新提示词变体，都会产生新鲜的待评分项。后者的增长至多是线性的，最坏情况下还会退化——评测员流失、校准偏差迫使旧条目重新评分，以及模糊的评分标准案例被退回给工程团队进行澄清。

当你把队列深度对照新提交评估的速度作图时，曲线在运行的第一个季度内就会向上弯曲。没意识到这一点的团队照样发布，然后在下一次由评估驱动的发布决策中发现，他们依赖的数据是六周前根据后来修订过的评分标准评定的。发布决策现在是基于过时的证据做出的，而技术上显示为绿色的评估集，已经不再是发布的关卡（release gate），而成了发布的仪式。

有效的思想模型是：评测员吞吐量就是带宽。处理中的评估案例就是数据包。队列是一个要么排空、要么填满的缓冲区。没有任何“无限劳动力”的假设能在接触生产实际后幸存，假装没这回事在操作上等同于设计一个假设数据库拥有无限写入吞吐量的服务。

校准是持续性的入职引导，而非一次性事件

团队最先低估的是校准。新评测员在第一天是不具备生产力的——只有在他们完成了一套校准集、发现了与共识的分歧，并与内化了政策的人一起理清了评分标准的边界案例后，他们才真正产生价值。将校准视为一次性的入职活动忽略了更昂贵的现实：每一次评分标准的改动对每位评测员来说都是一次重新校准事件；每一次改变输出分布的模型迁移都会产生原始校准未覆盖的新边界案例；每一个新的任务类别都需要自己的校准过程。

有效的规范是将校准视为 SRE 对待运维手册演练（runbook drills）的方式。有一个季度的重新校准周期，每位活跃的评测员都要对同一组预留集（hold-out set）进行评分，衡量评测员间的一致性（Cohen's Kappa、Krippendorff's alpha 或你所在领域实际使用的任何指标），如果一致性降至阈值以下，则触发以下三个动作之一：修改评分标准、添加锚点示例（anchor-example）或针对特定评测员的反馈。预留集本身被视为一种动态产物，与评分标准一起进行版本管理，每当生产环境评分中出现模糊案例时就添加新项。

让团队崩溃的模式是：在没有校准的情况下雇佣更多评测员。在校准不佳的团队中增加标注员，与在存在锁竞争（contended lock）的系统中增加核心是一样的反模式。吞吐量呈次线性增长，分歧率攀升，下游评估信号退化到工程师不再信任它的程度。到那时，你已经花掉了人力预算，却让评估问题变得更糟。

具备队列意识的评估优先级排序

如果评测员吞吐量是带宽，那么具备队列意识的优先级排序就是准入控制（admission control）。并非每个评估案例都同等重要，整个评估集是有预算的——假设如果你有四名处于专家标注员吞吐量上限的专家级评测员，每周预算就是 4,000 个条目。这种规范是将该预算视为值班（oncall）团队对待错误预算（error budget）的方式：它是有限的，消耗它的工作都在竞争同一个池子，必须有人在队列深度替你做决定之前做出优先级决策。

加载中…