跳到主要内容

第23章：主流 Benchmark

一个模型说自己"很强"，凭什么？训练损失下降了？生成的文字流畅？这些都不够。我们需要可重复、可比较、有明确评分标准的测试集——这就是 Benchmark（基准测试）存在的意义。

本章带你走遍目前最常被引用的几类 Benchmark：知识推理、代码能力、数学，以及最难量化的对话质量。每一类都有它独特的设计哲学，也都有各自的局限。

23.1 知识与推理：MMLU / GPQA / ARC​

问题：如何测试"知识广度"？​

最直观的想法是出选择题——覆盖尽可能多的领域，看模型能答对多少。这个想法催生了三个经典 Benchmark。

MMLU（Massive Multitask Language Understanding）​

由来：Hendrycks 等人于 2020 年发布，目标是测试模型在大学水平知识上的广度。

结构：

  • 57 个学科：从高中数学、历史、法律、医学，到计算机科学、道德哲学
  • 约 14,000 道四选一选择题
  • 题目来源于真实的大学考试题

示例题目（医学伦理学）：

A patient refuses a blood transfusion on religious grounds, but is unconscious and will die without it. The physician should: (A) Respect the patient's prior wishes and withhold treatment (B) Administer the transfusion to save the patient's life (C) Consult with the hospital ethics committee before deciding (D) Ask the patient's family to make the decision

评分：直接准确率（Accuracy），随机猜测基线为 25%。

当前 SOTA 水平：

模型MMLU 准确率
GPT-4o~88%
Claude 3.5 Sonnet~88%
Gemini Ultra~90%
人类专家平均~89%
随机基线25%

:::warning 局限性 MMLU 的题目已被广泛用于训练数据，存在"数据污染"（data contamination）风险。高分不一定意味着真正的理解，可能只是记忆了答案。此外，选择题无法测试开放性推理。 :::

GPQA（Graduate-Level Google-Proof Q&A）​

由来：2023 年发布，专门针对 MMLU"太容易被搜索引擎解决"的问题。

设计哲学：题目难到即使你能上网查，也很难在短时间内找到答案——因为答案本身就需要深度专业推理，而不是事实检索。

结构：

  • 约 448 道题，涵盖生物、化学、物理
  • 由领域博士生/博士后撰写并验证
  • 人类领域专家准确率约 65%，非专家约 34%

一个化学例子（简化版）：

某有机反应在特定立体化学条件下产生两种对映体，其比例受溶剂极性影响。根据以下实验数据，推断控制步骤的过渡态构型……

这类题目需要多步推理，而不是"背答案"。

当前情况：顶级模型（如 Claude 3 Opus、GPT-4）在 GPQA 上约达到 50-60%，刚刚接近人类专家水平。

ARC（AI2 Reasoning Challenge）​

由来：Allen AI 于 2018 年发布，测试小学科学推理能力。

两个难度集：

  • ARC-Easy：标准科学事实题，大多数模型可轻松超过 90%
  • ARC-Challenge：精心筛选的"困难题"——专门挑选那些基于词频统计的模型会答错的题

示例（ARC-Challenge）：

George wants to warm his hands quickly by rubbing them together. Why does this make his hands warm? (A) The rubbing generates electric energy (B) The friction converts kinetic energy to thermal energy (C) His hands absorb heat from the air (D) The pressure increases the temperature of his skin

答案是 (B)，需要理解能量转换的概念，而不只是关联词。

:::info ARC-Challenge 的价值 ARC-Challenge 的筛选方法很有启发性：先用简单的 IR（信息检索）模型和词频模型测试，只保留它们答错的题。这保证了 Benchmark 不能被"捷径"方法解决。 :::

23.2 代码能力：HumanEval / SWE-bench​

问题：代码生成怎么评分？​

文字生成可以主观评分，但代码有天然的客观标准——能不能运行，通不通过测试用例。

HumanEval​

由来：OpenAI 于 2021 年发布，随 Codex 论文一起推出。

结构：

  • 164 个 Python 函数补全任务
  • 每道题给定函数签名 + 文档字符串，模型生成函数体
  • 用隐藏的单元测试验证

示例：

def has_close_elements(numbers: List[float], threshold: float) -> bool:
    """Check if in given list of numbers, are any two numbers closer to each
    other than given threshold.
    >>> has_close_elements([1.0, 2.0, 3.0], 0.5)
    False
    >>> has_close_elements([1.0, 2.8, 3.0, 4.0, 5.0, 2.0], 0.3)
    True
    """
    # 模型需要生成这里的代码

评分指标：pass@k

pass@k=1−(n−ck)(nk)\text{pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}

其中 nn 是每道题生成的样本数，cc 是通过测试的样本数，kk 是最终提交的次数。

直觉：pass@1 表示一次就答对的概率；pass@10 表示 10 次里至少有一次正确的概率。

模型pass@1
GPT-4o~90%
Claude 3.5 Sonnet~92%
早期 Codex (2021)~28%

HumanEval 已接近饱和，顶级模型都在 90% 以上，区分度降低。

MBPP（Mostly Basic Python Programming）​

Google 发布，974 道入门级 Python 题，难度比 HumanEval 低，但覆盖更广的日常编程场景（字符串处理、列表操作等）。主要用于评估基础代码能力。

SWE-bench​

由来：2024 年发布，解决"HumanEval 太简单、脱离真实工程"的问题。

设计：从真实的 GitHub 开源项目中提取 Issue，要求模型：

  1. 理解 Issue 描述（通常包含 bug 报告或功能请求）
  2. 阅读相关代码库（可能有数万行代码）
  3. 生成能通过原始 PR 测试用例的 patch

为什么难？

真实 Issue 示例：
"AttributeError: 'DataFrame' object has no attribute 'swaplevel' 
 when using MultiIndex with certain dtypes"

模型需要：
1. 定位问题在 pandas 代码库的哪个文件
2. 理解 MultiIndex 的实现逻辑
3. 写出正确的修复，不破坏其他功能

SWE-bench Verified（人工验证的子集，500 个高质量样本）当前最好结果约 50%（Claude 3.5 Sonnet，2024 年底）。

:::tip 为什么 SWE-bench 更有意义？ HumanEval 测的是"写一个独立函数"，而 SWE-bench 测的是"在真实代码库中定位并修复问题"。后者更接近工程师的日常工作，也更难作弊。 :::

23.3 数学：GSM8K / MATH​

问题：数学推理有多特殊？​

数学题有精确答案，但"答对"的方式可以是死记硬背公式，也可以是真正的推理。好的数学 Benchmark 必须迫使模型展示推理过程，而不只是输出最终数字。

GSM8K（Grade School Math）​

由来：OpenAI 2021 年发布，8500 道小学数学应用题。

特点：每道题需要 2-8 步推理，数字关系清晰，但需要正确理解题意。

示例：

Janet's ducks lay 16 eggs per day. She eats 3 for breakfast and bakes 4 into muffins. She sells the rest at $2 per egg. How much does she make per day?

推理步骤：

  1. 每天总蛋数：16
  2. 吃掉 + 用掉：3 + 4 = 7
  3. 剩余：16 - 7 = 9
  4. 收入：9 × 2=∗∗2 = **18**

进展：GPT-3 约 35%，GPT-4 约 92%，推理模型（o1）接近 97%。GSM8K 已接近饱和。

MATH​

由来：Hendrycks 等人 2021 年发布，12,500 道竞赛级数学题。

五个难度级别，五个领域：代数、数论、几何、概率、组合数学。最难的是 AMC/AIME 竞赛题。

示例（Level 5，数论）：

Find the number of positive integers n≤1000n \leq 1000 such that nn is divisible by ⌊n⌋\lfloor \sqrt{n} \rfloor.

解题需要分情况讨论：对每个整数 kk，当 k2≤n<(k+1)2k^2 \leq n < (k+1)^2 时，⌊n⌋=k\lfloor\sqrt{n}\rfloor = k，需要 k∣nk \mid n。

推理模型的革命：

模型MATH 准确率
GPT-4（2023）~52%
Claude 3 Opus~60%
o1-preview（2024）~85%
o1（2024）~90%
人类 AMC 竞赛选手~90%

这个跳跃不是靠更大的模型，而是靠Chain-of-Thought + 强化学习的推理训练（详见第19章）。o1 相当于让模型在答题前"思考"更长时间，类似人类做难题时的草稿纸。

:::info 数学 Benchmark 的价值 数学题的特殊性在于：答案唯一，可自动验证，但解题路径需要真实推理。这使得数学成为测试"深度推理"能力最干净的场景之一。 :::

23.4 对话与指令：MT-Bench / AlpacaEval / Arena​

问题：如何评价"好的对话"？​

前三类 Benchmark 都有客观答案，但对话质量是主观的。有用性、流畅性、安全性、遵循指令的准确度——这些很难用单一指标衡量。

MT-Bench​

由来：LMSYS 团队 2023 年发布，专为多轮对话评测设计。

结构：80 道多轮对话题，分 8 个类别：写作、角色扮演、推理、数学、编码、提取、STEM、人文。

关键创新：LLM-as-Judge

不用人工打分，而是用 GPT-4 作为评判员，对模型回答打 1-10 分，并给出理由。

评判 Prompt 示例：
[系统]请作为公正的评判者，评估以下 AI 助手对用户问题的回答质量...
[用户问题] 写一首关于秋天的俳句
[AI 回答] ...
[评分] 请给出 1-10 的评分和理由

局限：GPT-4 可能偏向自己风格的回答（position bias，倾向于选择第一个选项）。

AlpacaEval​

由来：斯坦福 2023 年发布，基于 Alpaca 数据集的 805 道指令。

评分方式：用 GPT-4 比较被测模型与参考模型（通常是 text-davinci-003）的回答，计算胜率（win rate）：

Win Rate=被测模型胜出次数总对比次数×100%\text{Win Rate} = \frac{\text{被测模型胜出次数}}{总对比次数} \times 100\%

AlpacaEval 2.0 引入长度控制，防止模型通过"写更长的回答"来刷胜率（length-controlled win rate）。

Chatbot Arena（LMSYS）​

由来：2023 年由 UC Berkeley LMSYS 团队发布，目前最接近真实使用体验的评测平台。

机制：

  1. 用户输入任意问题
  2. 平台随机选两个模型生成回答（模型名称隐藏）
  3. 用户选择哪个更好，或平局
  4. 用 ELO 评分系统聚合所有对战结果

ELO 评分（来自国际象棋）：

EA=11+10(RB−RA)/400E_A = \frac{1}{1 + 10^{(R_B - R_A)/400}}

其中 EAE_A 是 A 预期胜率，RA,RBR_A, R_B 是当前评分。每次对战后更新：

RA′=RA+K(SA−EA)R_A' = R_A + K(S_A - E_A)

SA∈{0,0.5,1}S_A \in \{0, 0.5, 1\} 是实际结果，KK 是更新系数（通常 32）。

优势：

  • 真实用户，真实问题，覆盖长尾场景
  • 无法针对性刷分（题目不固定）
  • 大量样本使评分统计显著

当前排行榜（2024 年底）：Claude 3.5 Sonnet、GPT-4o、Gemini 1.5 Pro 在 Arena ELO 上互相竞争，差距通常在 20-30 分以内。

:::warning LLM-as-Judge 的偏见 使用 LLM 评判 LLM 存在系统性问题：

  • 自我偏好：GPT-4 倾向于偏爱 GPT-4 风格的回答
  • 长度偏见：更长的回答往往得分更高，即使信息量相同
  • 位置偏见：评判者倾向于偏爱第一个呈现的回答

这些偏见需要通过双盲设计、位置互换、长度控制等手段缓解。 :::

本章小结​

Benchmark领域评分方式难度主要局限
MMLU知识广度（57 学科）选择题准确率大学水平数据污染风险
GPQA专业推理选择题准确率博士水平样本量小（448 题）
ARC-Challenge科学推理选择题准确率小学科学已接近饱和
HumanEval代码生成pass@k入门函数题太简单，接近饱和
SWE-bench软件工程patch 通过率真实工程评测成本高
GSM8K数学推理准确率小学数学顶级模型已接近饱和
MATH数学推理准确率竞赛级推理模型后仍有空间
MT-Bench对话质量LLM 打分通用LLM Judge 有偏见
AlpacaEval指令遵循胜率通用长度偏见
Chatbot Arena真实对话ELO 评分通用数据分布随用户变化

理解 Benchmark 的局限与模型的得分同样重要——每个 Benchmark 都是对"智能"的一次近似，而非完整定义。一个在所有 Benchmark 上都得高分的模型，在真实任务中未必是最佳选择。

当我们知道如何评测，下一个问题自然是：如何让模型生成的内容更可信、更可控？这正是下一章《对齐与安全》要探讨的核心挑战。