LLM 评测数据集的标注规则先写清楚

评测标注规则 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 不同人按不同理解给样本打分，最后得出的结论只会越来越混乱，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。

我现在更倾向的做法，是先把这类能力当成正式工程问题来看，而不是把它当成一个临时技巧。对我来说，最关键的一步通常是 先把正确、可接受、不可接受的判定样式写清楚，再开始大规模标注，因为只有边界先明确，后面的优化、扩展和排查才不会一直漂。

真正容易被忽略的，往往不是功能能不能做出来，而是以下这些细节：

• 边界样本要重点讨论并记录共识
• 规则一旦调整，要保留版本而不是静默覆盖
• 评测样本要能回溯到来源场景，否则很难解释为什么入选

这些细节看起来都不大，但它们决定了系统是在 demo 阶段“能跑”，还是进入业务以后依然稳定。越是和 AI、工作流、构建链路这类复杂能力相关，越不能靠感觉把事情糊过去。

评测体系真正解决的是团队判断不一致

围绕「LLM 评测数据集的标注规则先写清楚」这类主题，最常见的问题不是没人关心质量，而是每个人都在用不同标准判断质量。没有样本版本、标注口径和评测节奏时，团队会把一次效果波动误认成模型能力变化，或者把个别成功案例误当成整体可用。评测的真正价值，是把“感觉不错”改造成“知道为什么通过、为什么失败”。

我会先锁住的评测约束

• 先定义样本集版本和 rubric，确保今天的好坏标准下周还能复现。
• 离线评测先于在线放量，避免把本来能在实验阶段挡住的问题直接推给真实用户。
• 每次改 prompt、模型或检索策略时，都保留失败样本和变化记录，这样复盘才会越来越快。

小结

评测数据集不是凑样本，而是沉淀判断标准。规则先稳住，后面的模型比较才有意义。