3 篇博文 含有标签「llm-judge」

你的综合评估分数在上个季度上升了两个百分点。没人能告诉你这究竟是系统变好了，是打分的人类群体变得更宽松了，还是你在三月份升级的评判模型开始以不同的权重衡量文本的冗长程度。数字变动了。但该数字旨在衡量的事物并不一定随之变动。

当一个评估准则同时被两个群体——人类和 LLM 评判者——阅读时，就会发生这种情况，而且这两个群体的漂移轴线和原因各不相同。综合分数将两者的运动混合在一起，除非你有一套测量方案能在其中一个变动时保持另一个固定，否则你发布的指标，其变化是无法归因于任何因素的。

你的每周评估（eval）仪表盘变平了。曾经在 0.71 到 0.78 之间波动的曲线，已经在连续三个发布周期中紧缩成 0.84 左右的一根细线。团队将其解读为达到了天花板——模型已经达到了评分准则（rubric）允许的上限，进一步的工作需要更难的评估。有人安排了一场规划会议来“设计 eval v2”。

这种解读看似合理，有时也确实正确。但还有第二种解释，它会产生同样的图景，并悄悄摧毁你的发布准入信号：你的标注员（无论是人类还是 LLM 评判员）已经在意见上趋同，评估不再是在衡量模型，而是在衡量模型产出标注员心目中“正确”输出形态的能力。

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

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