评估总线因子：当定义“正确标准”的人离职时

我最近合作的一个团队失去了一位资深机器学习工程师。两周后，每个 PR 的评估套件（eval suite）依然全绿——847 个案例全部通过，裁判一致性（judge agreement）达到 92%。六周后，一位客户发现了一个回归问题，而这个问题本该被“支持质量”桶里的第一个评估案例捕获。当团队进行调试时，没人能解释为什么要写那个案例，它本该捕获哪种失败模式，或者为什么裁判提示词（judge prompt）是按 1–4 分评分而不是二元评分。那个案例依然通过了，但它并没有测试任何有人能说清楚的东西。

这就是评估的公交车系数（eval bus factor）：一种无声的失败模式。在这里，决定 AI 功能“正确”含义的人，也是策划测试用例、校准裁判模型并吸收了大脑中每一个隐含标注权衡的人。当他们离职时，评估套件虽然依然保持绿灯，但却不再能产生可靠的发布/拒绝信号——因为没有其他人能扩展它、调试不稳定的裁判，或评估新的失败模式是否属于测试集。

这件事之所以容易被忽视，是因为传统的公交车系数指标看的是代码所有权。评估套件也是代码，所以 SourceGraph 查询会显示“两位工程师提交过代码；公交车系数为 2”。但起支撑作用的关键产出（load-bearing artifact）并不是运行评估的代码，而是编码在测试案例和裁判提示词中的判断逻辑。这种判断逻辑存在于某人的头脑中，而提交记录无法捕捉到它。

为什么评估的所有权会向个人集中

评估之所以会集中所有权，是因为对 AI 输出进行评分是极少数“正确性准则本身”就不稳定的工程任务之一。当你为一个两个整数相加的函数编写单元测试时，答案就在规范（spec）里；无论是谁写的规范，谁写的测试，还是谁审查的测试，都会在通过标准上达成一致。但当你为一个“支持代理对计费问题给出了有用的回答”编写评估案例时，并没有现成的规范。只有一个人在查看了 200 次真实互动后，决定了对于这个产品、这个客户群和这个监管背景来说，“有用”应该意味着什么。

这种决定很少被记录下来。它被内化了——同一个人策划了体现该规则的测试用例，选择了将其操作化的裁判提示词，设置了模型“足够好”的阈值，并在每周评估审查期间凭直觉解决了边缘案例。当套件拥有几百个案例时，该规则在组织的其他地方已不复存在。它是某个人评分逻辑的累积残留。

对于“LLM 作为裁判”（LLM-as-a-judge）的设置来说，情况更是如此。裁判提示词看起来像文档，但事实并非如此。它是标注者意图的压缩近似值，而且只有当有人监视其输出并注意到它何时开始发生偏移时，它才能保持校准。研究人员表明，自然的准则微调会随着时间的推移系统性地偏向裁判的偏好——他们称之为“准则诱导的偏好漂移”（rubric-induced preference drift）——这意味着即使是写得很好的裁判提示词，也是一个需要专人负责的动态目标。

负责人离职后的三种失败模式

损害并不会立即显现。评估会以缓慢、难以检测的方式失效：

• 覆盖率冻结。 套件停止增长。新的产品功能发布时没有相应的评估案例，因为团队中没人觉得自己有资格决定什么是代表性案例，或者什么是正确的评分准则。覆盖率占实际发布功能的百分比在一个季度内悄悄从 80% 下降到 30%。
• 裁判腐化（Judge rot）。 “LLM 作为裁判”的提示词是针对原始标注者的直觉进行调整的。随着上游模型的改变、输入分布的转移，或者标注者自身审美的演变，裁判给出的裁决会偏离团队现在认为正确的结果。没人注意到这一点，因为没有人工重新评分的样本来捕获它。
• 能力盲区。 一种新的失败模式出现了——比如，模型开始以六个月前没有的方式幻觉出产品 SKU。评估套件没有针对它的案例，因为“哪些失败模式值得建立案例”的规则属于那个离开的人。在每次客户投诉后，团队会防御性地增加新案例，但此时套件已是响应性的，而非预测性的。

工程师最常描述的模式是第三种：团队意识到（通常是在公开事故之后），他们一直将“评估套件全绿”视为模型可以安全发布的证据，而实际上，该套件仅仅证明了昨天的失败模式没有再次发生。

为什么这比普通的公交车系数问题更难

标准的公交车系数缓解措施——结对编程、文档轮换、代码审查——并不能完全转化。对评估案例 PR 的代码审查可以验证测试是否运行，但无法验证该案例是否代表了一个值得捕获的真实失败模式，因为审查者没有看到标注者所反应的底层生产数据。原始负责人撰写的文档对他们自己来说是显而易见的真理，而对其他人来说则是难以理解的琐碎细节。

这里有一个更深层的问题。评估的所有权是学术界可能称之为“充满主观审美”（taste-laden）的东西。“这个输出对我们的品牌语调来说太简短了”或“这个回答在技术上是正确的但在法律上有风险”这种判断，并不是可以详尽编纂的规则。它是从数百个细微决定中建立起来的校准直觉。关于领域专家的继任计划文献对这一点很坦率：你无法仅通过文档转移隐性知识。你必须让继任者与专家一起工作足够长的时间，做出同样的微观决策并得到纠正，以此来完成转移。

大多数 AI 团队发现这一点时，最初的负责人通常已经离开，而新员工正盯着 847 个评估案例，试图逆向推导产生这些案例的哲学。到那时，代价已经付出了。

在需要之前建立冗余的实践

那些在核心成员离职后仍能生存下来的团队，通常都采用了以下四种实践的一些版本。这些做法并不令人意外；值得注意的是，它们通常只有在经历了第一次惨痛损失之后才会被采用。

带有案例说明的规范化标注准则。 每个标注维度——“有帮助”、“安全”、“合规”、“符合品牌形象”——都有一份书面准则，其中至少包含三个从真实生产数据中提取的正向和负向案例。每当标注员在评估审查中解决了一个棘手的边缘案例时，准则都会更新，而解决后的案例会进入案例列表，并附上一行解释原因的注释。这是唯一能将隐性评分判断转化为继任者可以学习的产物。

评测模型提示词逻辑注释。 LLM-as-a-judge 的提示词会被检入版本控制系统，同时附带一个独立文件，解释提示词中每条指令存在的原因：它防止了哪些过去的失败模式、它使准则中的哪一条款具象化、曾有过哪些替代措辞以及为什么被拒绝。这个文件决定了继任者是能够安全地修改评测模型，还是因为恐惧而不敢触碰它。

评估审查轮换。 每周评估审查——即有人查看最近的失败案例，决定它们代表的是真实的 Bug 还是评测模型的错误，并据此更新案例的会议——由至少三名工程师轮换进行。每次轮换中，原标注员第一个月作为沉默观察者，然后作为标注员可以提问的顾问，最后独立进行。这相当于评估审美（eval taste）的住院医师培训计划，也是最能直接缩短离职后恢复时间的实践。

带有强制人工重新评分的评测模型一致性追踪。 每周有 5% 到 10% 的评测模型判决由人工重新评分。一致率会随时间绘制成图表。如果一致率下降，这是一个领先指标，表明评测模型出故障了、任务发生了偏移，或者准则已经脱离了最初的校准。这起到了报警器的作用：即使原负责人离开了，且没有人注意到评估套件已经过时，一致性偏移图表最终也会发出尖叫。

像对待承重资产一样配置人力

更深层次的变化是组织架构上的。大多数团队将评估集视为工程师在边角料时间维护的东西——占用某人 20% 的时间，通常是那个恰好也在研究模型本身、对 ML 最精通的工程师。这种人员配置模式产生了单点故障。

那些在离职后能迅速恢复的团队，对待评估集的方式就像基础设施团队对待承重服务一样：它有一个明确的主要负责人、一个明确的次要负责人，以及一个明确的继任计划。次要负责人并非碰巧“知情”——他们积极参与编写案例，参加每一次审查，并被要求能在接到通知后的一周内接管工作。当主要负责人休假时，次要负责人主持每周审查。当主要负责人调换团队时，次要负责人变为主要负责人，并在交接完成前任命一名新的次要负责人。

这听起来很繁重，直到你将其与替代方案的成本进行比较。一个看似绿色但毫无意义的评估套件比没有评估套件更糟糕，因为它给了团队发布的虚假信心。评估集的隐性预算应该针对下一次未被检测到的回退（regression）成本来设定，而不是针对维护覆盖范围所需的工程师工时。

如果本季度无法重组团队，该怎么做

大多数读者无法立即任命共同负责人并轮换审查。最小可行干预措施较小，且值得在本周执行：

• 挑选五个引用频率最高的评估案例——那些捕捉到最多回退或在晋级/拒绝决策中最常被引用的案例。为每个案例写一段逻辑说明：它测试了什么失败模式、是什么真实的生产事故触发了它、评分准则为什么要这样设定。将这些逻辑说明检入仓库，放在案例旁边。
• 找到你的评测模型提示词中最具主观见解的部分——通常是区分“好”与“卓越”或“可接受”与“风险”的部分。让原作者用平实的语言口述他们试图捕捉的内容。将其作为注释保存在提示词中。
• 安排一小时，让评估负责人向第二名工程师大声讲解上周的评分决策。录制下来。录音不是为了合规；它是为了给下一个必须学习这种审美的人准备的。

这些做法相当于在度假前写下 Wi-Fi 密码。它们不会在真正的紧急情况下救你，但如果紧急情况真的发生，它们将显著缩短恢复时间。

前瞻性的转变

2026 年 AI 工程组织中发生的有趣结构性变化是，评估所有权终于被视为一门学科，而不是作为团队中最精通 ML 的人的副产品。现在一些团队拥有专门的“评估工程师”，他们的全部工作就是维护准则、培训继任者和审计评测模型校准。这个角色看起来很像测量领域的 SRE：一个负责系统可靠性的专家，而这个系统告诉你其他系统是否可靠。

如果你评估套件的公交系数（bus factor）目前为 1，那么你正面临一场待发的停机事故。解决办法不是编写更多案例，而是确保下次那个知道什么是“正确”的人走出大门时，套件中仍有人能扩展它、调试它，并识别它何时不再说实话。