评测集（eval set）是一个文件。但它也暗含了对 AI 功能用途的理论定义。这两者并非一回事，混淆它们的团队建立了一个质量网关，而其校准完全依赖于单个人的工作记忆。当那个人离职时，文件留下了，但那套理论也随之而去了。
这是你在组织架构图中看不到的失败模式。你规划了一个提示工程（prompt engineering）角色。你雇佣了一个优秀的人才。他们发布了 v1 版本的提示词，审视了简陋的基准测试，并将其重写为内容丰富的东西——一个失败模式分类法、每个类别的权重，以及一套能够消除边缘情况歧义的标注指南（rubric）。评测集变成了“该模型是否好到足以发布”的契约。六个季度后，你发现这份契约除了编写它的那个人之外，其他人都看不懂。
你规划的角色与实际演变出的角色
2026 年提示工程师的职位描述读起来更像是 AI 系统工程师，而非其头衔所暗示的那样。从业者负责策划数据集、定义指标、构建回归测试，并主导提示词变更的发布审核。评测工作不是一项支线任务。它是将已发布功能与在生产环境中出现偏差的功能区分开来的核心环节。
问题在于，角色的重心在组织不知情的情况下发生了偏移。一个注意到评测集薄弱且脆弱的提示工程师有两个选择：针对一个糟糕的衡量标准发布更多提示词，或者停下来修复这个衡量标准。勤奋的人会选择修复它。他们建立分类法，因为真实的失败并非预先分类好的。他们为类别分配权重，因为某些失败的代价比其他失败更高。他们编写标注指南，因为两个理性的工程师对同一个模糊边界案例的标注可能不同，而评测分数取决于由谁来标注。
孤立来看，这些决定中的每一个都是正确的。但它们共同产生了一个充斥着主观判断的产物。要流畅地解读评测分数，需要脑子里记着这些判断。新读者拿到了文件，却没有拿到那些判断逻辑。
为什么标注指南只存在于某个人的脑子里
标注指南是品味的压缩。所有者花了数周时间才决定某种特定的幻觉属于“编造（fabrication）”而非“格式错误（format error）”，因为下游的影响不同。他们决定在某种语境下的拒绝是正确的行为，而在另一种语境下则是过度拒绝（over-refusal）。他们为一个类别选择了 3.0 的权重，为另一个类别选择了 1.0，因为当时的业务优先级决定了这种等级制度。
每一个决定背后都有长篇累牍的推理。其中一些推理被记录在标注指南文档中。但大部分推理都体现在标注好的示例本身中，原始标注者以某种特定方式解决了一个歧义案例，这种解决方案就成了先例。一个看到已解决示例但不知道背后逻辑的新标注者，有时会从中得出不同的先例。
这就是标注者间一致性（inter-annotator agreement）指标所要揭示的经典问题。Krippendorff's alpha 接近 0.8 表明两个标注者使用相同的指南对相同的数据进行标注时，其结果趋于一致。如果低于这个阈值，说明标注指南不够精确，无法产生可靠的信号。大多数团队只在标注指南刚出炉、标注者之间正在对齐校准时测量一次一致性。当标注指南的所有者更换时，他们并不会重新测量。
角色交替的时刻，正是发现你的 alpha 值在不同标注者之间是否依然成立的时刻。但这也是原始标注者已经离职、你无法再针对他们进行重新测量的时刻。
评测集即规范
评测集是你团队对于 AI 功能用途的规范（specification）。这句话听起来很抽象，直到你目睹一次发布审核失败并试图与其争论。
模型供应商发布了升级版本。你通过评测集运行它。分数在“事实性（factuality）”类别下降了 4%。你应该发布吗？答案取决于这 4% 的下降是否发生在你关心的问项上，类别权重是否恰当，该类别的标注是否足够一致以至于 4% 的差异是有效信号而非噪声，以及该类别中的模糊案例是否是由原始标注者以一种不再符合当前产品优先级的方式解决的。
当标注指南的所有者在场时，他们能在五分钟内回答这些问题。当他们离开后，团队需要花费两周时间来弄清楚该先问哪个问题，团队在模型升级上的效率随之下降，因为每一次网关决策都变成了一次考古挖掘。
生产级 LLM 系统的失败模式分类法始终将“更新引发的回归”和“版本漂移”排在前列。其机制几乎总是相同的——一个质量信号在由一个人负责时有效，但在所有权变更时便失效了，团队只能对着一个他们不再信任的尺度来为部署打分。
在人员离职后依然生效的模式
解决方法不是写更多的文档。文档会陈旧失效。解决方法是将评测集 (eval set) 构建为一个即使原作者不在场，多个人也能阅读的产出物 (artifact)，并定期测试这种阅读能力。
将评分标准 (rubric) 视为需要经过审查的代码。每一个评分标准的变更都应通过一个 PR，并附带说明为什么要进行更改以及它移动了哪一类别的边界。该 PR 至少由一名工程师审查，且该工程师需要根据该标准进行标注。这种审查迫使负责人在判断成为先例之前，先用文字清晰地表达出来。
在团队中轮换标注工作。每周选取固定数量的新样本，让两名工程师独立标注。对比他们的分歧。每一个分歧要么是完善评分标准的机会，要么是评分标准此前未涵盖的先例。如果始终只有一个人在标注，评分标准就只能通过他一个人的判断来完善，而这种完善对其他人来说是不可见的。
测量每一组标注者之间的标注者间一致性 (inter-annotator agreement)，而不仅仅是最初的那一组。当一致性降至阈值以下时，将其视为评分标准的 bug 并进行修复。该阈值使巴士系数 (bus factor) 变得可衡量——如果只有一个标注者能达到一致性指标，那么无论团队有多少人，你的巴士系数都只有 1。
要求记录临界案例的裁定过程。当负责人解决了一个模棱两可的例子时，该决议应附带一份解释理由的备注。备注保存在该例子旁边。新的标注者阅读这两者后，无需负责人在场，就能将同样的逻辑应用到新的模糊案例中。
招聘时的关注点
当你撰写下一个提示词工程 (prompt engineering) 的职位描述时，应将评测理论的可记录迁移视为一项交付成果，而不仅仅是一个愿望。候选人的成功标准应包括：“另一名工程师能够独立阅读此评测集，并对处于边界情况的模型变更做出相同的‘发布/不发布’决策。” 这个标准是可以测试的。在入职六个月内进行这项测试，此时前任评测理论的原作者还在，可以进行对比。
根据产出物 (artifact) 而非活动来界定角色。“负责评测集与团队其他成员的校准”与“编写评测集”是两项不同的工作。前者通过设计构建了冗余。后者则构建了依赖。
抵制将评测工程师视为“守门人”的诱惑。守门人的设定会将权力和信任集中在一个人身上，这在短期内感觉很高效，直到守门人离开，而大门背后却没有共享的解读。如果团队将评测集视为共享的规范——即任何资深工程师都应能流利阅读的规范——虽然在协作开销上付出了实际成本，但却获得了在首位评测负责人离职后依然能够持续交付的能力。
架构层面的认知
每当单个人构建了随后成为关键支撑的东西时，都会积累一种特定的组织债务。工程文化的本能是赞美构建者，并让其周围的系统通过渗透来继承他们的判断力。在评测集方面，这种渗透会失效，因为判断力存在于已解决的标签、类别权重和阈值选择中，即便被问及，构建者也无法完全用语言表达出来。
评测集是 AI 产品团队中杠杆率最高的单一产出物。它决定了你发布哪些模型、接受哪些提示词以及捕捉哪些回归。将其视为一个岗位的产出而非一个职能的责任，就像将生产环境的数据库架构 (schemas) 视为单个 DBA 的产出一样，是同样的错误。架构在 DBA 离职后依然存在，是因为每一次变更都经过了审查，且团队的集体记忆保留了它。评测集值得同样的对待。
一个衡量你的团队是否构建了这种冗余的合理测试是：让另一名工程师在没有原负责人指导的情况下，根据评测集对上季度的模型变更进行评分。如果他们的评分在误差范围内与历史评分一致，说明评分标准发挥了作用。如果不一致，说明评分标准从未真正被记录下来——它只是由一个人在解读。在收到辞职信之前，你已经了解了真实的巴士系数是多少。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
