[CS336-12] 评测

这篇是 Stanford CS336 Spring 2025 第 12 讲 Course Materials 的学习笔记。主题是 evaluation：如何把抽象目标变成可执行评测。

1. Evaluation 的第一性问题#

评测不是简单跑一个 benchmark。真正的问题是：你想优化什么目标？这个目标如何被可重复、可比较、难被投机的测试表示出来？

例如“模型有帮助”可以对应很多指标：答题正确率、指令遵循、用户偏好、工具调用成功率、安全性、事实性、端到端任务完成率。不同指标之间可能冲突。

因此 evaluation 本质上是目标建模。

2. Benchmark scores 和 vibes#

课程区分 benchmark scores 和 vibes。Benchmark 提供可量化、可复现的数字，但可能覆盖面有限，也可能被污染或过拟合。Vibes 更接近真实用户体验，但主观、难复现、难比较。

健康的评测体系通常需要两者结合：用 benchmark 做回归测试和定量比较，用人工体验和真实流量发现 benchmark 没覆盖的问题。

3. 经典能力评测#

Lecture 12 讨论了 MMLU、MMLU-Pro、GPQA、Humanity's Last Exam 等知识和推理类 benchmark。

这些评测的难点在于：

• 数据是否足够高质量；
• 是否真的需要推理，而不是记忆；
• 是否存在 train-test overlap；
• 选择题是否能代表开放生成能力；
• 模型是否通过 prompt tricks 提升但没有本质能力变化。

越强的模型越容易把旧 benchmark 打满，因此 benchmark 需要不断升级。

4. 开放式回答怎么评#

开放生成没有唯一标准答案，因此需要偏好评测、LM-as-a-judge 或人类评估。

Chatbot Arena 用成对比较和用户投票构建相对排名。AlpacaEval、WildBench 等尝试用自动 judge 评估开放回答。IFEval 则专门检查指令遵循中的可验证约束。

这类评测的关键风险是 judge bias。例如模型可能因为回答更长、更自信、更像 judge 偏好的格式而得分更高。

5. Agent、安全和系统评测#

课程还讨论了 SWE-bench、CyBench、MLE-Bench 等更接近真实任务的评测。这些不只测语言模型本身，还测系统是否能读文件、改代码、运行工具、迭代修复。

安全评测则包括 HarmBench、jailbreak、pre-deployment testing 等。安全不是单一数字，因为不同场景下 hallucination、拒答、越权、隐私、偏见、滥用能力的风险都不同。

6. 数据污染和评测质量#

Train-test overlap 是评测中的核心问题。如果 benchmark 题目出现在训练集中，分数就可能不再代表泛化能力。

同时，评测集自身质量也很重要：题目是否清晰、答案是否唯一、标注是否正确、是否能区分模型能力。一个低质量 benchmark 会鼓励错误优化。

7. takeaway#

第 12 讲的核心是：evaluation 是把目标函数具体化。

• benchmark 分数有用，但不是全部；
• 开放回答需要处理 judge bias 和偏好偏差；
• agent 评测更接近真实系统，但更难复现；
• 安全评测必须结合具体部署场景；
• 数据污染和评测集质量决定分数可信度。

做模型系统时，评测不是最后一步，而是决定训练和产品方向的控制面。

参考#

• Stanford CS336 Spring 2025 Course Materials: lecture_12.py