CS336 · 第 12 课

语言模型评估

评估看似机械——扔一些 prompt 进去，算个平均分——但实际上是一个深刻而丰富的话题。评估决定了语言模型的未来发展方向，选择错误的指标会引导整个领域走偏。

本讲问题：一个模型在 benchmark 上得分更高，并不自动代表它更有用、更可靠或更安全；评估首先要明确希望测量哪种能力，以及 metric 是否真的对应使用场景。

target behavior
  ↓ operationalize
dataset items + prompt/template + decoding settings
  ↓ model responses
scorer / judge / reference
  ↓ per-item measurements
aggregation + uncertainty + subgroup analysis
  ↓ claim with validity boundary

为什么评估如此困难？

打开任何一个前沿模型的论文（DeepSeek-R1、Llama 4、OLMo 2），你会看到一张 benchmark 分数表。这些数字看起来精确而权威。但这一课要告诉你：每个数字背后都有很多主观选择。

评估的目的决定方法

一个数字不够

单一数字（如"MMLU 86.4%"）隐藏了太多信息：

• 不同科目的表现差异巨大（历史 95% vs 数学 60%）
• few-shot vs zero-shot 差异显著
• prompt 格式影响结果
• 模型可能"记住"了测试集

Perplexity

定义

语言模型是 token 序列上的概率分布 p(x)。Perplexity 衡量模型对测试数据的"惊讶程度"：

为什么用 Perplexity？

• 平滑：是连续值，适合拟合 scaling law
• 通用：任何语言模型都可以计算，不依赖下游任务
• 理论基础：与信息论中的交叉熵直接相关
• 可比：不同模型可以在相同测试集上比较

Perplexity 的局限

• 不代表下游能力：低 perplexity ≠ 好的助手
• 对 tokenization 敏感：BPE vs byte-level 的 perplexity 不可比
• 需要概率输出：闭源模型只给 text output，无法计算
• 不区分错误类型：幻觉和事实错误的代价不同

标准数据集

# GPT-2 的 perplexity 结果（zero-shot 迁移）
# 在 WebText 上训练，在其他数据集上评估

Perplexity on:
- Penn Treeband: 46.5 (LSTM SOTA was 51.3)
- WikiText-103: 17.3
- One Billion Word: 66.3 (在更大的数据集上迁移效果下降)

# 关键洞察: 在相似分布的数据上 perplexity 低
# 在 out-of-distribution 上 perplexity 更高

Perplexity Maximalist 观点

Perplexity 的"精神亲戚"

有些任务本质上就是 perplexity 的变体：

• LAMBADA：预测句子的最后一个词（需要长距离上下文）
• HellaSwag：选择最合理的句子结尾（4 选 1）
• Cloze tasks：完形填空

知识 Benchmark

MMLU (Massive Multitask Language Understanding)

MMLU 是最广泛使用的知识测试之一：

• 57 个学科：数学、美国历史、法律、医学、道德等
• 题型：4 选 1 多选题
• 来源：研究生和本科生从网上收集
• 评估方式：few-shot (5-shot) prompting

MMLU 的问题

• 已饱和：最高分超过 90%，区分度下降
• 噪声/平凡问题：部分题目质量不高
• 记忆 vs 理解：模型可能记住了答案而非理解
• 对 prompt 敏感：system prompt、few-shot 示例影响结果

MMLU-Pro

MMLU 的改进版：

• 移除噪声/平凡问题
• 选项从 4 个扩展到 10 个（更难猜对）
• 使用 chain-of-thought 评估
• 模型分数下降 16-33%（不再饱和）

GPQA (Graduate-Level Google-Proof Q&A)

更难的知识测试：

• 由 61 位 PhD 级别的合同工编写
• PhD 专家能达到 65% 准确率
• 非专家（即使有 Google）只能达到 34%
• GPT-4 只能达到 39%（接近非专家水平）

Humanity's Last Exam (HLE)

最新的"终极测试"：

• 2500 道多模态问题
• 多个学科，多选 + 简答
• 提供 50 万美元奖金池
• 经过前沿 LLM 筛选（过滤掉太简单的）

指令跟随评估

MMLU 等结构化任务之外，更现实的评估是"指令跟随"——像 ChatGPT 那样响应用户请求。问题是：如何自动评估开放式生成？

Chatbot Arena

目前最受信任的评估方式之一：

• 用户提交 prompt，两个匿名模型同时回答
• 用户投票选择哪个更好
• 用 Elo 评分系统计算排名
• 优势：动态的输入（不是静态 benchmark）

IFEval (Instruction-Following Eval)

自动化的指令跟随评估：

• 给指令添加可自动验证的约束
• 例如："用 3 段话回答"、"包含关键词 X"、"用中文回答"
• 约束可以程序化检查，但语义质量仍需要人类判断

AlpacaEval

• 805 个指令（多种来源）
• 用 GPT-4 作为 judge，比较模型回答 vs GPT-4 reference
• 指标：win rate（模型赢过 GPT-4 的比例）
• 局限性：GPT-4 作为 judge 有偏好（偏好长回答、偏好自己）

WildBench

• 从 100 万真实人机对话中采样 1024 个例子
• 用 GPT-4 turbo 作为 judge，使用 checklist（类似 CoT）
• 与 Chatbot Arena 的相关系数 0.95（高度相关）
• 可以作为 Arena 的快速代理

LM-as-a-Judge

用语言模型评估语言模型的输出——这是目前最流行的自动评估方法。

基本框架

# 输入: prompt + model_output
# Judge prompt: "评估以下回答的质量，给出 1-10 分..."

judge_prompt = """
给定问题: {prompt}
模型回答: {response}

请评估回答的质量:
1. 准确性 (1-10):
2. 完整性 (1-10):
3. 清晰度 (1-10):
总分: """

Judge 的偏差

LM judge 有多种系统性偏差：

Pairwise vs Pointwise

• Pointwise：给单个回答打分（绝对质量）
• Pairwise：比较两个回答哪个更好（相对质量）
• Pairwise 通常更可靠（人类也更擅长比较而非绝对评分）

推理 Benchmark

数学推理

代码生成

# HumanEval 示例:
# 写一个函数检查一个数是否为质数

def is_prime(n):
    """Return True if n is a prime number."""
    if n < 2:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True

# 评估: pass@k
# pass@1: 单次采样通过率
# pass@10: 10 次采样至少一次通过的概率

Agent 评估

Agent = 语言模型 + 脚手架逻辑（决定如何使用模型）：

纯推理：ARC-AGI

试图将推理与知识分离：

• 输入：彩色网格图案
• 任务：根据示例推断变换规则，应用到新输入
• 不需要语言或世界知识
• 人类可以轻松解决，但 LLM 表现不佳

Test-Time Compute Scaling

除了增加模型规模，另一种提升性能的方法是在推理时增加计算。

Chain-of-Thought (CoT)

Self-Consistency

# 思路: 多次采样，选出现最一致的答案

# 对同一问题采样 10 次，每次用不同的 temperature
answers = []
for i in range(10):
    response = model.generate(prompt, temperature=0.7, seed=i)
    answer = extract_answer(response)
    answers.append(answer)

# 选出现频率最高的答案
final_answer = max(set(answers), key=answers.count)

# 例: 10 次采样得到 [5, 5, 5, 5, 5, 6, 5, 7, 5, 5]
# 最终答案: 5（出现 8 次）

计算与性能的关系

OpenAI o1/o3 和 DeepSeek-R1 展示了 test-time compute 的 scaling：

• 让模型"思考更久"（生成更长的 CoT）可以提升性能
• 性能与推理时 FLOPs 呈（近似）幂律关系
• 小模型 + 更多推理计算 ≈ 大模型 + 少推理计算（某些任务）

评估的有效性

Train-Test Overlap

现代 LLM 在"整个互联网"上训练。测试集也来自互联网。所以测试集可能已经被模型"看过"：

Dataset Quality

Benchmark 本身可能有质量问题：

• SWE-Bench：部分测试用例不准确 → SWE-Bench Verified（人工审核）
• MMLU：部分题目有错误答案
• Platinum benchmarks：经过专家审核的高质量版本

我们在评估什么？方法还是模型？

真实性与实用性

两种 Prompt

Asking 更现实——用户真正使用 LLM 是为了获取他们不知道的信息。但现有 benchmark 主要是 Quizzing。

Clio (Anthropic)

分析真实用户数据的尝试：

• 用 LLM 分析数百万真实用户-Claude 对话
• 提取一般性模式（不泄露隐私）
• 发现：真实使用模式与 benchmark 测试的分布非常不同

MedHELM

医学领域的现实评估：

• 121 个临床任务，来自 29 位临床医生
• 混合私有和公开数据
• 不是标准化考试，而是真实临床场景

安全评估

什么是安全？

安全不是一个单一维度：

• 拒绝能力：拒绝有害指令
• 幻觉率：不产生虚假信息
• 偏见：不歧视特定群体
• 隐私: 不泄露训练数据中的 PII
• 双重用途：网络安全能力既可用于防御也可用于攻击

HarmBench

• 510 种有害行为（违反法律或规范）
• 评估模型是否会生成有害内容

AIR-Bench

• 基于监管框架和公司政策
• 314 个风险类别，5694 个 prompt

Jailbreaking

自动化的安全绕过：

Capabilities vs Propensity

安全的两个维度：

知识检查

如果只能记住 5 件事

延伸阅读