2 篇博文 含有标签「annotation」

构建 LLM 应用的团队总会犯同一个错误：他们等待积累足够的标注数据之后，才肯投入评估基础设施建设。他们告诉自己需要 5000 个样本，或者 10000 个。评估系统始终停留在待办事项清单上，而"感觉不错"的主观判断代替了真正的指标度量。ZenML 对 1200 个生产部署的分析发现，即便是成熟的部署，非正式的直觉判断依然普遍存在——许多团队从未真正建立起系统性的评估机制。

数据量直觉是从经典机器学习时代借来的——在那个时代，更多的标注样本确实能稳定提升模型性能。但对于 LLM 评估，这个直觉基本上是错的。对稀疏基准测试的研究表明，20–40 个精心挑选的样本就能可靠地估算完整基准的排名，而 100 个样本产生的平均绝对误差低于 1%，与使用数千个样本相比相差无几。问题不在于数据量，而在于大多数团队跳过了使小规模评估集值得信赖的结构化流程。

本文介绍这个流程的实际操作方式：如何通过主动学习选取合适的样本，如何用弱监督大规模生成噪声标签，如何借助 LLM 评判者进行冷启动，以及如何判断你的小型评估集何时可以正式使用。

大多数团队对待标注流水线的方式，就像对待他们 2019 年的 CI 脚本一样：它能运行，大部分时候如此，而且没人想去碰它。一个带有颜色标记行的共享电子表格。一个将任务路由到 Slack 频道的 Google 表单。三名承包商异步工作，在一个讨论串中对比笔记。

接着，一个模型发布后质量下降，评估（eval）以一种令人困惑的方向退化，事后分析（post-mortem）最终揭示了显而易见的事实：标签错了，而且没人构建任何东西来检测它。

标注不是一个数据问题。它是一个软件工程问题。那些以此方式对待它的团队——使用队列、模式（schemas）、监控和结构化的分歧处理——构建的 AI 产品会随着时间的推移而改进。而那些不这么做的团队则陷入了无法解释的重新标注循环。