语言模型评估
对应课程 Lecture 12:Evaluation(Percy)
训练花了几百万美元，然后呢？评估（evaluation） 决定你知不知道模型好不好、差在哪、该不该上线。这一讲的中心问题：语言模型的能力，到底能不能被“分数”诚实地衡量？
两类评估：困惑度与下游任务
困惑度（perplexity）
困惑度就是“下一个 token 的平均分支数”，由交叉熵损失导出：
- 优点：全自动、可大规模计算、与训练目标一致、平滑可微调缩放定律；
- 局限：它是分布层面的度量—— perplexity 下降不一定意味着“会做题了”；不同分词器之间没有可比性（token 数不同）。
困惑度适合内部追踪训练健康度，不适合对外报告能力。
下游任务基准
真正关心的能力（问答、数学、代码）用基准（benchmark） 评估：固定一批题目 + 标准答案，让模型作答后打分。经典例子：
| 基准 | 测什么 |
|---|---|
| MMLU / MMLU-Pro | 多学科知识（选择题） |
| GSM8K / MATH | 数学推理 |
| HumanEval / SWE-bench | 代码生成与工程 |
| HellaSwag / ARC | 常识与科学推理 |
任务框架：同一个基准，多种问法
让语言模型答题，需要先决定怎么把题目变成提示。同一道题：
- 生成式：把题目和选项写出来，让模型生成答案，再解析匹配；
- 打分式：对每个选项分别计算
，取概率最大者。
两种框架的分数可以相差好几个点，而且排名都可能变化。所以评估的第一课：报告基准时必须说明评估协议，协议本身就是结果的一部分。
评估的四大陷阱
陷阱一：数据污染（contamination）
基准题目很可能出现在训练数据里（它们都来自互联网）。模型“背过答案”，分数虚高但不代表能力。检测与缓解：
- 训练时做与基准的 n-gram 重叠筛查并剔除；
- 用“从未见过的、动态生成的”私有测试集；
- 报告污染审计结果，像报告实验设置一样常规化。
陷阱二：基准饱和与 Goodhart 定律
当一个基准被大家优化得太久，它就不再是能力的代理，而变成优化目标本身（Goodhart 定律：指标一旦成为目标，就不再是好指标）。MMLU 已接近饱和、区分度下降——评估体系需要持续换血。
陷阱三：过拟合评估集（哪怕不训练）
在开发中反复看同一测试集做决策，本身就是一种隐性过拟合。自适应评估（adaptive evaluation）：动态组合新题（如 HELM-lite 的做法）、隐藏测试集（LMArena 式盲测）是对策。
陷阱四：表面形式敏感
答案顺序、措辞、few-shot 例子选取都会显著影响分数。稳健的做法：多种 prompt 变体取平均/中位数，报告方差而不是单点。
主观评估与人类偏好
很多重要维度（有用、无害、写作风格）难以客观打分，主流方法：
人类相对排名
Chatbot Arena / LMArena 模式：两个模型匿名对战，人类盲选谁更好；用 Elo / Bradley-Terry 模型把海量两两比较聚合成排名。优点是贴近真实偏好、难被直接污染；缺点是偏好可能偏向“讨喜”风格而非正确性。
LLM 评审（LLM-as-a-judge）
用一个强模型给回答打分/排序：可扩展、便宜、一致性好。已知偏差：位置偏差（偏先出现的答案）、自我偏好（偏自己的风格）、长度偏好（偏长回答）。缓解：交换位置双向评审、去偏校准。
风格与能力的解耦
一个重要的近期发现：许多榜单分数里混着“写作风格”的信号。控制风格（或先做风格对齐）之后，不同模型的能力差距会变得不同——评估时要问：我测的是能力，还是文风？
安全评估
对齐后的模型还要评估安全性：
- 拒绝合规：对有害请求应拒绝，对良性请求不应过度拒绝（过度拒答是常见副作用）；
- 越狱（jailbreak）鲁棒性：角色扮演、编码、多轮诱导等攻击下的行为；
- 红队测试（red-teaming）：人或模型系统性地尝试让模型出格；
- 安全评估的难点同样存在：攻击面是开放集合，通过的测试不代表安全，只代表“还没被打穿”。
组织评估的工程视角
把评估当作软件工程来做：
- 评估套件分层：快速冒烟集（每次训练都要跑）→ 核心能力集（每周）→ 全量基准（里程碑）；
- 版本化一切：评估代码、prompt 模板、解析逻辑都要进版本控制，否则分数不可比；
- 自动解析与人工抽查结合：生成式答案的解析（正则/模型抽取）是常见误差源；
- 记录原始输出：只存分数会让你将来无法重新分析。
小结
- 困惑度管训练健康，下游基准管能力，人类/LLM 评审管偏好——三层缺一不可。
- 评估协议（框架、few-shot、解析）是一等公民；污染、饱和、表面形式敏感是三大陷阱。
- 基准会失效，评估体系需要持续演化；把评估当工程做，可复现、可审计。