金标准集要是定不准，每次对齐数据简直像在吵架，太心累了。
比如，很多团队在搭建模型评测（Eval）体系时，常常陷入依赖模糊打分表的误区。最常见的做法是让标注员给出 1-5 分的评分，或者只是标记“好”或“不好”。面对几十条样本，这种主观评估看起来挺高效；但当数据量激增到数百甚至上千条时，标注一致性就迅速瓦解了。不同时间段、不同人的“好”标准大相径庭。更棘手的是，当 Prompt 优化后分数上升，你也无法确知这是模型能力的真实进步，还是打分者情绪波动或阈值松动造成的。在这种模糊的前提下，任何量化结论都缺乏根基。
赋予 Eval 实际价值的核心，在于将评价维度拆解到“非黑即白”的原子层级。比如，用可验证的断言（Assertions）替代主观打分表。摒弃“回答是否自然”等主观表述，转而采用可验证的断言。以代码生成任务为例，如果指标仅为“代码质量如何”，那毫无操作性。应将其拆分为三个独立的 Yes/No 维度：语法正确性、逻辑覆盖度、冗余度。细化到这个地步，标注员无需“思考”或“权衡”，只需执行“判断”。从“打分”转向“勾选”，就能大幅削减主观偏差。
实战中，测试集的结构也需升级，不能仅有 Prompt 和答案。建议统一使用 JSONL 格式存储评测数据，既便于脚本自动化批处理，又利于版本回溯。标准测试条目应涵盖：输入（Input）、预期行为（Expected Behavior）、具体评价标准（Criteria）以及分类标签（Category）。例如，代码翻译测试用例如下：

{
  "id": "test_001",
  "input": "将这段 Python 代码转换为 Rust",
  "expected_behavior": "实现等效逻辑且无内存泄漏",
  "criteria": "1. 必须使用 ownership 机制; 2. 运行时间偏差在 10% 以内",
  "category": "code_translation"
}

在这样的结构中，评价标准（Criteria）内嵌于数据集，标注员必须严格对照标准操作，而不是依赖直觉。
分析阶段亦应摒弃对“平均分”的迷信。性能瓶颈往往藏身于分布图中，而非平均值。模型可能在简单任务上达到 100% 正确率，却在复杂场景全面崩溃。这种“断层”现象会被平均分抹平，误导你认为模型表现

直接上 checklist 勾选吧，把评价维度拆解至“非黑即白”的原子层级，比打分准太多了！

量化指标没定死简直是灾难，跑出来的曲线全是噪音，心累。许多团队在构建模型评测体系时，常陷入依赖模糊打分表的误区。最常见的方式是让标注员给出 1-5 分的评分，或仅标记“好”与“不好”。面对几十条样本，这种主观评估显得高效；但当数据量激增至数百乃至上千条时，标注一致性便会迅速瓦解。更棘手的是，当 Prompt 优化后分数上升，你无法确知这是模型能力的真实进步，还是打分者情绪波动或阈值松动所致。在如此模糊的前提下，任何量化结论都缺乏根基。赋予 Eval 实际价值的核心，在于将评价维度拆解至“非黑即白”的原子层级。摒弃“回答是否自然”等主观表述，转而采用可验证的断言（Assertions）。以代码生成任务为例，若指标仅为“代码质量如何”，则毫无操作性。应将其拆分为三个独立的 Yes/No 维度：1. 语法正确性：代码能否通过静态语法检查（如 Python 的 pyflakes 或 Rust 的 rustc）？2. 逻辑覆盖度：是否完整覆盖了预设的 Case A 和 Case B？3. 冗余度：是否引入了不必要的第三方库？细化至此，标注员无需“思考”与“权衡”，只需执行“判断”。从“打分”转向“勾选”，可大幅削减主观偏差。