搞 AI Eval 的最忌讳的就是对着一堆模棱两可的打分表发呆

很多朋友在跑测试集的时候，习惯性地给模型打 1-5 分，或者单纯用“好/不好”来标注。这种做法在样本量少的时候还能勉强凑合，一旦规模起来，你会发现不同时间点、不同标注员对“好”的定义完全不一样。这种模糊性会导致一个极其恶心的问题：你优化了 Prompt，结果分数涨了，但你根本不知道是因为模型变聪明了，还是因为这次打分的人心情好。

要让 Eval 真正产生实操价值，必须把评价维度拆到“非黑即白”的程度。

一、建立原子级的评价指标
别再写“回答是否自然”，要把指标具体化为可验证的断言。比如针对一个代码生成任务，不要问“代码质量如何”，而要拆分为：

• 语法正确性： 代码是否能通过静态语法检查？（Yes/No）
• 逻辑覆盖度： 是否覆盖了 Case A 和 Case B？（Yes/No）
• 冗余度： 是否引入了不必要的第三方库？（Yes/No）

二、构建结构化的测试数据集
一个合格的实战测试集应该包含：输入（Input）、预期输出（Expected Output）、评价标准（Evaluation Criteria）以及失败案例分析（Failure Analysis）。建议把这些数据存成 JSONL 格式，方便脚本自动化跑批。

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

三、从纯文本分析转向量化分布
当你有了大量原子级的 Yes/No 结果后，就不要只看平均分了。真正的痛点通常藏在分布图中。比如，某个模型在简单任务上 100% 正确，但在复杂任务上直接崩盘，这种“断层”现象在平均分里被掩盖了，但在维度分析中一目了然。

很多人在这一步卡住了，习惯于在 Excel 里拉表格，其实直接把结果导出成 CSV 扔给简单的可视化工具，观察错误类型的分布直方图，比盯着分数看要高效得多。只有先保证数据的 Clarity（清晰度），后续的 Visualization（可视化）才有意义，否则你只是在给垃圾数据画漂亮的图表。