那些悄然成为你唯一评测集阅读者的提示工程师

评测集（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% 的差异是有效信号而非噪声，以及该类别中的模糊案例是否是由原始标注者以一种不再符合当前产品优先级的方式解决的。

加载中…