团队像规划服务一样规划评估集（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）的方式：它是有限的，消耗它的工作都在竞争同一个池子，必须有人在队列深度替你做决定之前做出优先级决策。
一个可行的分流策略从三个维度对待处理的评估项进行排名。影响范围（Blast radius） ：这个评估关卡影响多少下游变更？一个发布拦截的回归测试集优先级高于探索性探测。信息价值（Information value） ：考虑到已知情况，我们期望从评测该项中学习到多少？与最近评测过的案例近乎重复的项目价值较低；新颖的失败模式价值较高。失效风险（Decay risk） ：该信号多快会过时？与活跃的 A/B 测试或进行中的模型迁移相关的项目只有数小时的有效生命周期；稳定监控套件中的项目可以等待数天。
许多团队发现，每周一早晨进行这种分流，可以在不增加评测员产能的情况下，将队列深度中位数降低 40–60%，因为队列中相当大一部分内容要么是重复的，要么是低价值的，或者在排到最前面时已经过时了。另一半规范则相反：当队列深度超过某个阈值时，必须暂停或缩减会增加新条目的工程工作，就像在值班负载激增时执行功能冻结（feature freeze）一样。
评估员反馈循环是功能而非噪声 将评估员的问题视为干扰的团队是在优化错误的目标。每当评估员停下来询问“在这种情况下评分标准（rubric）是什么意思？”时，他们其实是在揭露评估系统的一个缺陷——评分标准含糊不清，缺少锚点案例（anchor example），或者未说明边缘情况的策略。将这些问题埋在 Slack 频道中，由当时在线的人随意回答，意味着评分标准永远无法得到修正，每一位后续的评估员都会遇到同样的歧义，从而一遍又一遍地支付吞吐量成本。
这种运营模式是机械化的。评估员的问题应该像服务中的错误报告（bug report）一样针对评分标准进行归档。每个问题都应包含评分标准版本、触发该问题的样本项、评估员的解读、共识答案以及状态。重复出现的问题应被提升为对评分标准的修订或新的锚点案例。真正重要的仪表盘是“每千条评分项目的提问数”——随着评分标准的成熟，这一指标应呈下降趋势；而峰值则是一个信号，表明输入分布发生了变化（这通常意味着模型迁移或提示词更改引入了新的失效模式）。
二阶效应是，成熟的评分标准会成为 LLM-as-judge 校准的输入。评分标准越清晰——每个评分等级都有明确的锚点案例，规定了边缘情况策略，并且解决了历史上导致分歧的项目——前沿模型评判员与评估员共识之间的一致性就越高。将评分标准视为动态文档的团队，其评判员校准结果在模型迁移后依然有效，因为策略是被编码在评分标准本身，而不是硬编码在特定评判员版本的提示词中。
SRE 框架：将标注视为基础设施 解决这一问题的框架是：将评估员产能视为基础设施，具有与计算或存储相同的运营属性。它有利用率（评估员花在评分与校准、评分标准疑问上的时间比例）、饱和度（什么样的队列深度标志着过载状态）、错误（由于分歧或评分标准修订而需要重新评分的项目比例）以及延迟（从提交评估项目到获得评分结果的时间）。这是 SRE 长期以来称为“黄金信号”的四个指标，而在仪表盘上每周监控这些指标的纪律，可以在队列深度螺旋式上升演变成计划紧急情况前几个月就发现问题。
产能模型简单到可以在餐巾纸上推算。每位评估员的吞吐量乘以评估员人数即可得出每周产能。减去校准开销（在健康的团队中通常占评估员时间的 10-15%），减去重新校准的拖累（评分标准更改后重新评分项目的成本，随评分标准的波动性而变化），减去病假和新员工的入职磨合期。剩下的数字就是你的每周评估产能，它应该像 QPS 限制作为服务工作的规划输入一样，成为你的规划输入。
让团队惊醒的预测是：当评估套件的增长速度快于评估员产能时，队列深度最终会超过陈旧阈值——即由于评分标准已更新或模型已发布，评分数据不再有用的时间点。那个日期是可以计算的。那也是评估套件作为发布门控失效的日期。将其与下一次模型迁移绘制在同一张路线图上，才能将对话从“我们需要更多标注员”转变为“在增加标注员人数之前，我们需要建立这样的运营纪律”。
成熟的评估运营是什么样的 成熟的形式是：评估员产能与计算支出出现在同一个规划幻灯片上。校准偏移（Calibration drift）是一项周度指标，而不是季度性的惊喜。评分标准的问题被视为缺陷进行跟踪，并形成进入评分标准文档的闭环反馈。队列深度设有告警阈值。评估项目在提交前就确定优先级，而不是在队列满了之后。重新校准是计划内的工作，而不是紧急救火。LLM-as-judge 的校准建立在成熟的评分标准之上，这意味着它们在评判员模型迁移后依然可用，因为策略在评分标准中，而不是在评判员提示词中。
这一切都不光鲜。它是任何生产级 AI 系统在跨越一个工程师无法再亲眼查看每个评分项目的规模后，必须支付的运营税。按时支付这一成本的团队能让其评估套件在多年内保持可信。推迟支付的团队会发现，当第一次因为评估数据陈旧而导致发布决策错误时，事后补救的代价是你之前发布的每一项评估结果的公信力。评估员吞吐量不是招聘问题。它是任何评估驱动的发布流程的运营骨干，将其视为运营骨干，是将“能够工作的评估套件”与“在团队凭直觉做发布决策时仅用于点缀规划文档的评估套件”区分开来的关键。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
