大模型评估体系：基准、指标与方法论

摘要: 从标准化基准测试、核心评估指标与评估方法论三个维度系统梳理了大模型评估体系。基准层面，覆盖了综合知识（MMLU、C-Eval、CMMLU）、推理能力（GSM8K、MATH、AIME）、代码能力（HumanEval、MBPP、SWE-bench）、中文能力（SuperCLUE）和 Agent 能力（WebArena、AgentBench、τ-bench）五大类评测集。指标层面，深入解析了 Perplexity 困惑度的原理与局限、BLEU/ROUGE/BERTScore 三代文本生成指标的演进逻辑，以及 Chatbot Arena Elo 评级的人类偏好机制。方法论层面，对比了 LLM-as-Judge、人工评估和自动化基准评测三种方法的适用场景、成本结构与常见陷阱，并提出了多维度交叉验证的最佳评估实践。

核心问题

一个大模型到底"有多好"？我们用什么标准来衡量它？本文系统梳理大模型评估的标准工具、核心指标与方法论。

1. Benchmarks（基准测试）

Benchmark 是标准化考试卷，一套固定的题目、一套固定的评分规则，所有模型在同一套卷子上答题，分数可以横向对比。

它的价值在于：可复现、可对比、可追踪进展。

1.1 综合知识

综合知识基准衡量模型的"通识"能力 -- 从物理到法律，从历史到计算机，覆盖面越广，越能反映模型的通用智能水平。

MMLU（Massive Multitask Language Understanding）

• 包含 57 个学科（数学、历史、法律、医学、计算机等）约 15,000 道选择题
• 题目来源：各类职业资格考试和学术考试真题
• 格式：四选一选择题
• 意义：当前最主流的"通用知识"标尺，几乎所有模型发布都会报告 MMLU 分数
• 代表性分数（仅供参考，随时间演进）：
  • GPT-4 (2023)：约 86.4%
  • Claude 3 Opus：约 86.8%
  • 人类专家水准：约 89.8%

MMLU 覆盖的学科领域示意：

┌───────────────────────────────────────────────────────┐
│                    MMLU (57 学科)                       │
├─────────────┬─────────────┬──────────────┬────────────┤
│   人文社科    │   STEM     │   社会科学    │   其他      │
├─────────────┼─────────────┼──────────────┼────────────┤
│ 哲学         │ 数学        │ 经济学        │ 法学        │
│ 历史         │ 物理        │ 心理学        │ 医学        │
│ 文学         │ 化学        │ 社会学        │ 商学        │
│ 语言学       │ 生物        │ 政治学        │ 会计        │
│ 艺术         │ 计算机科学   │ 地理          │ 管理学      │
│ └─ 共20+学科  │ └─ 共15+学科 │ └─ 共12+学科  │ └─ 共10+学科│
└─────────────┴─────────────┴──────────────┴────────────┘

C-Eval

• 中文版的 MMLU 等价物，由中国高校和科研机构联合构建
• 覆盖 52 个学科，约 14,000 道题目
• 题目来源：中国各类考试（高考、考研、公务员考试、职业资格考试等）
• 特别价值：考察模型对中文语境下专业知识的掌握程度
• 为何需要 C-Eval 而不仅用 MMLU 的中文翻译？因为中文教育体系的知识重点、题型风格、专业术语与英文体系存在差异

CMMLU

• 同样面向中文的综合知识评测，与 C-Eval 互补
• 覆盖 67 个学科，强调中文文化特有知识（如中国历史、古诗词、中医药等）
• 题目来源更加多样化，包含中国互联网平台上的知识问答数据

对比维度	MMLU	C-Eval	CMMLU
语言	英文	中文	中文
学科数	57	52	67
题目数	~15,000	~14,000	~11,000
侧重点	英文世界通识	中国教育体系知识	中文文化特有知识
出题风格	职业考试/学术考试	高考/考研/公考	多源平台

1.2 推理能力

知识多不等于会推理。推理能力基准衡量模型"多想一步"的能力——数学计算、逻辑推理、多步骤问题求解。

GSM8K（Grade School Math 8K）

• 8,500 道小学数学应用题（加减乘除 + 多步推理）。
• 每道题需要 2-8 步推理才能得出答案。
• 为什么重要：看似简单的"小学数学"，实则测试的是多步逻辑推理链的能力。模型不能靠"记忆"答题——每道题的数字和场景都是新的。
• 典型题目示例：

  Janet 的鸭子每天下 16 个蛋。
  她每天早上吃 3 个蛋，并用 4 个蛋烤松饼给朋友。
  剩下的蛋每天在农贸市场以每个 2 元出售。
  她每天在农贸市场能赚多少钱？
  
  解：16 - 3 - 4 = 9 个剩余 → 9 × 2 = 18 元

MATH

• 包含 12,500 道高中数学竞赛级别的数学题
• 覆盖：代数、几何、数论、概率统计、微积分预科等
• 难度远超 GSM8K——GSM8K 是"小学数学"，MATH 是"高中数学竞赛"
• 输出格式要求严谨的 LaTeX 数学表达式
• 早期模型的 MATH 分数普遍很低（GPT-3 仅约 5%），但推理增强技术（如思维链、self-consistency）显著提升了表现

AIME（American Invitational Mathematics Examination）

• 美国数学邀请赛真题，难度高于 MATH
• 15 道填空题，每题答案是一个 0-999 的整数
• 题目设计精巧，通常需要非常规思路
• 2024-2025 年成为最受关注的"硬核推理"标尺之一，因为主流模型在 MATH 上已经开始趋于饱和

推理基准难度金字塔：

        ▲
       /＼\        AIME         （数学竞赛——需要创造性思维）
      /    \
     / MATH \     MATH          （高中数学——需要多步推导）
    /--------\
   /  GSM8K   \   GSM8K         （小学数学——测试推理链基本能力）
  /────────────\

1.3 代码能力

代码生成是大模型最重要的应用场景之一。代码基准衡量模型从简单函数补全到复杂工程项目的能力。

HumanEval

• 由 OpenAI 提出的 164 道 Python 编程题
• 每道题包含：函数签名 + docstring（描述功能）+ 若干测试用例
• 评估方式：pass@k —— 生成 k 个候选答案，只要有一个通过所有测试用例，即算正确
• 典型题目示例：

  def has_close_elements(numbers: List[float], threshold: float) -> bool:
      """检查给定数字列表中是否存在两个数字，它们的距离小于给定阈值。
      >>> 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
      """

MBPP（Mostly Basic Python Programming）

• 约 1,000 道 Python 编程题
• 相比 HumanEval，题目更偏向基础编程技能（但也因此区分度不如 HumanEval）
• 同样使用 pass@k 评估

SWE-bench

• 不再是"写一个函数"，而是修复真实 GitHub issue
• 从 12 个知名 Python 开源项目（Django、Flask、SymPy 等）中抽取真实的 bug 报告
• 模型需要：理解 issue 描述 → 定位代码中的 bug → 生成 patch → 通过项目的全部测试
• 这是目前最难的代码基准之一，因为它测试的是：
  • 长上下文理解（需要阅读整个代码仓库）
  • 精准定位（在数万行代码中找到问题）
  • 工程素养（patch 需要符合项目规范）

代码能力评估层次：

┌──────────────────────────────────────────────┐
│  Level 3: 真实工程    │  SWE-bench           │  修复真实项目 bug
│                        │  (GitHub issues)      │  需理解整个代码库
├──────────────────────────────────────────────┤
│  Level 2: 函数级编程   │  HumanEval / MBPP    │  根据描述写函数
│                        │  (164 / 1000 题)      │  pass@k 评估
├──────────────────────────────────────────────┤
│  Level 1: 代码补全     │  单行/多行补全        │  按 tab 就能完成
│                        │  (GitHub Copilot 场景) │
└──────────────────────────────────────────────┘

1.4 中文能力

中文用户关心的核心问题：**这些模型说好中文了吗？中文基准用于衡量模型在中文语境下的真实表现。

SuperCLUE

• 中国团队开发的中文综合评测体系
• 覆盖 10+ 大类能力：语义理解、对话、生成、推理、知识、代码、长文本、数学、安全、Agent 等
• 特色：不仅做客观选择题，还包含开放主观题——需要人工或 LLM-as-Judge 评分
• 是国内中文大模型评测引用率较高的榜单

中文基准的设计挑战

英文基准                         中文基准
   │                                │
   ▼                                ▼
MMLU ──── 直接翻译？ ──→ 有问题！
                                │
                  ┌─────────────┼─────────────┐
                  ▼             ▼             ▼
              文化错位      知识体系不同    表达习惯差异
              "棒球规则"    中国高考 vs SAT  成语/古诗
              中国人不熟    数学侧重点不同    英文无对应

C-Eval / CMMLU / SuperCLUE 各自从不同角度解决了这些问题。

1.5 Agent 能力

传统基准测试的是"一步到位"的能力（给输入，看输出），而多步交互能力——模型需要在一个环境中持续行动、观察反馈、做出决策。

SWE-bench（同 1.3 节代码能力部分）

• 也可视为 Agent 基准：模型作为"程序员 Agent"，需要自动修复 bug

WebArena

• 模拟真实网站环境（电商、社交、论坛、地图、GitLab 等）
• 任务示例："在 Reddit 上找到 r/MachineLearning 中关于 Llama3 的讨论最多的帖子，并在其中发表一条评论"
• 模型需要：理解指令 → 导航 → 读取页面内容 → 执行操作 → 验证结果
• 难点：长视野规划、动态环境适应、视觉理解（网站是渲染的页面）

AgentBench

• 由清华大学等机构提出
• 覆盖 8 个环境：操作系统、数据库、知识图谱、棋牌游戏、网页购物、网页浏览、代码、 Household（家庭场景）
• 每个环境有一系列递增难度的任务
• 评估维度全面，是国内 Agent 评测的重要参考

τ-bench（Tau-bench）

• 专注于"工具使用"和"真实世界交互"的基准
• 任务涉及：数据库查询、API 调用、文件操作、命令行交互等
• 特点：强调可靠性和一致性——不是在理想环境中一次成功，而是在有噪声、有失败的真实环境中稳定完成任务

Agent 能力评估全景：

┌──────┬──────────────────┬────────────────────────────────────┐
│ 维度  │ 代表基准          │ 考察内容                            │
├──────┼──────────────────┼────────────────────────────────────┤
│ 代码  │ SWE-bench         │ 修复真实项目 bug（文件编辑、测试运行） │
├──────┼──────────────────┼────────────────────────────────────┤
│ 网页  │ WebArena          │ 在模拟网站中完成多步任务（购物/发帖）  │
├──────┼──────────────────┼────────────────────────────────────┤
│ 综合  │ AgentBench         │ OS、DB、游戏、购物等多环境任务       │
├──────┼──────────────────┼────────────────────────────────────┤
│ 工具  │ τ-bench           │ API 调用、命令行、文件操作可靠性      │
└──────┴──────────────────┴────────────────────────────────────┘

2. 核心评估指标

基准测试给的是"排名和分数"，但这些分数背后的计算方法本身就是一门学问。不同的指标衡量不同维度——你需要知道每个数字代表什么。

2.1 Perplexity（困惑度）

困惑度是语言模型最基础、最内在的评估指标，它衡量的是模型对一段文本的"惊讶程度"。

定义与公式

给定一个 token 序列 $w_1, w_2, ..., w_N$，模型对这段文本的困惑度为：

换个更直观的形式：

直觉理解

困惑度可以理解为：模型在预测每个下一个 token 时，平均有多少个"候选选项"感到纠结。

低 PPL = 模型很"确定"该接什么
高 PPL = 模型很"困惑"，觉得很多词都有可能

举例：
文本："水的化学式是 H₂O"

好的模型：读到"水的化学式是"时，
         → 对"H"给出的概率极高 → PPL 很低
  
差的模型：读到"水的化学式是"时，
         → 对"H"、"C"、"O"、"N"概率差不多 → PPL 很高

PPL 的局限性

1. 只衡量流畅度，不衡量正确性：一段流畅但满嘴胡话的文本，PPL 可以很低
2. 对 tokenizer 敏感：不同 tokenizer 的 PPL 不可直接对比
3. 是内部指标：不需要标注数据，但不能反映人类的真实偏好
4. 不适用于对话评估：PPL 设计用于评估对一段给定文本的拟合程度，而对话的质量评判维度更多

PPL 的典型用途

• 训练过程中监控模型收敛（PPL 持续下降 = 模型在学习）
• 同架构不同版本的横向对比（如 LLaMA-7B vs LLaMA-13B）
• 评估压缩效率（PPL 直接对应无损压缩比）

2.2 生成质量指标：BLEU / ROUGE / BERTScore

当一个任务有"参考答案"时（如翻译、摘要），我们需要衡量模型输出与参考答案的相似程度。

BLEU（Bilingual Evaluation Understudy）

用于机器翻译评估，核心思想：计算模型译文中有多少 n-gram 出现在参考译文中。

其中 $p_n$ 是 n-gram 精度（n=1,2,3,4），$BP$ 是长度惩罚因子。

参考译文："那只猫坐在垫子上"
模型翻译："猫坐在垫子上"

1-gram 精度：{猫, 坐, 在, 垫子, 上} / {猫, 坐, 在, 垫子, 上} = 5/5 = 1.0
2-gram 精度：{猫坐, 坐在, 在垫子, 垫子上} / {猫坐, 坐在, 在垫子, 垫子上} = 4/4 = 1.0
3-gram 及以上的 n-gram 精度依次计算...

（实际计算中还会对上界做剪裁，防止模型重复某个词来刷分）

BLEU 的缺点：只看 n-gram 重叠，完全不懂语义。"我今天很开心"和"我今天快乐极了"在意为上是相同的，但 BLEU 会给出很低的分数。

ROUGE（Recall-Oriented Understudy for Gisting Evaluation）

用于文本摘要评估，关注的是"模型有没有覆盖参考答案的关键信息"。

• ROUGE-N：计算 n-gram 的召回率（参考摘要中的词，有多少出现在模型输出中）
• ROUGE-L：基于最长公共子序列（LCS）的匹配，不要求连续匹配
• 与 BLEU 的差异：BLEU 侧重精度（防注水），ROUGE 侧重召回（防遗漏）

原文（长）：一篇关于气候变化影响的 2000 字文章
参考摘要："气候变化导致海平面上升和极端天气增加"
模型摘要 A："气候变化引起海平面变化和天气极端化"           → ROUGE 较高
模型摘要 B："这是一个值得关注的重要议题"                   → ROUGE 很低（遗漏关键信息）

BERTScore

BLEU 和 ROUGE 只做表面的词匹配。BERTScore 引入了深层次的语义匹配。

• 将模型输出和参考答案分别通过 BERT（或其他预训练模型）编码为向量
• 计算两个文本中每个 token 向量的余弦相似度
• 对每个参考 token 找最大相似度的候选 token（召回），反之亦然（精度）
• 最终结合两者的 F1 分数

BERTScore 与 BLEU/ROUGE 的本质区别：

BLEU/ROUGE：
"good" ≠ "great"  → 完全不同的词，匹配失败

BERTScore：
"good" 的向量 [0.3, 0.5, 0.1, ...]
"great" 的向量 [0.32, 0.48, 0.12, ...]
→ 余弦相似度 0.95 → 高度匹配！

三种指标对比

指标	适用场景	核心思想	优点	缺点
BLEU	机器翻译	n-gram 精度	简单、快速、广泛使用	不懂语义，惩罚意译
ROUGE	文本摘要	n-gram 召回	关注信息覆盖	同样不懂语义
BERTScore	通用生成	语义向量相似	理解同义表达	依赖编码模型质量，计算慢

2.3 Chatbot Arena Elo Rating

前述指标基本都是"有参考答案"的。但对话模型的评估进入了"没有标准答案"的领域——什么才是一段"好"的对话？这时候，人类偏好成为了黄金标准。

Chatbot Arena（LMSYS）的核心设计

1. 用户可以同时向两个匿名模型提问
2. 用户看到两个模型的回答后，投票选择哪个更好（或平局/都不好）
3. 使用 Elo 评分系统（与国际象棋评级相同算法）计算每个模型的分数

用户的视角（匿名对决）：
┌─────────────────────────────────────────┐
│  问题：解释一下量子纠缠                   │
├─────────────────────────────────────────┤
│  模型 A 回答              │  模型 B 回答 │
│  "量子纠缠是指..."        │  "想象你有    │
│  （学术化解释）           │   两只手套..." │
│                           │  （类比解释）  │
├─────────────────────────────────────────┤
│  ○ A 更好   ● B 更好   ○ 平局  ○ 都不好  │
└─────────────────────────────────────────┘

Elo 评分的直观含义

• Elo 分数差 100 分 → 高分模型有约 64% 的胜率
• Elo 分数差 200 分 → 高分模型有约 76% 的胜率
• Elo 分数差 400 分 → 高分模型有约 91% 的胜率

为什么 Arena 评级如此重要？

1. 反映了人类真实偏好：不是某个固定题目上的分数，而是真实用户随机问题的投票
2. 自然对抗：当某个模型在某种类型问题上表现出色，用户自然会更多地用它来挑战其他模型
3. 动态更新：随用户使用持续更新排名，能反映模型迭代后的真实能力变化
4. 补充自动化基准的盲区：有些能力（风格、语气、创意、趣味性）自动化指标完全无法测量

Arena 的局限

• 用户群体偏技术型，不代表所有人群
• 免费模型更容易被测试，可能积累更多"好对付"的问题
• 不评估安全性、事实准确性等非偏好维度
• 存在风格偏好偏差（有的用户喜欢长回答，有的喜欢简洁回答）

3. 评估方法

有了基准和指标之后，问题变成了：谁来评、怎么评？ 这里涉及三种主流方法论。

3.1 LLM-as-Judge（用强模型评估弱模型）

当前最流行的自动化评估方法：用一个强大的模型（如 GPT-4、Claude 3.5 Sonnet）作为"裁判"，评估其他模型的输出质量。

工作原理

输入 ──→ 被评估模型 ──→ 输出
                          │
                          ▼
                    裁判模型（LLM-as-Judge）
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
      打分/排名       指出缺陷       对比偏好
      (1-10分)     (事实错误/逻辑)   (A vs B 更好)

常见评判模式

1. 单点打分：给定一个回答，裁判给出 1-5 或 1-10 的分数，附带理由
2. 成对比较：给定两个模型的回答，裁判判断哪个更好
3. 逐维评估：分别对准确性、完整性、流畅性、安全性等维度打分
4. 参考答案对比：给定一个"标准答案"，裁判判断模型输出与答案的一致性

为什么 LLM-as-Judge 是可行的？

多个研究发现，强模型（GPT-4 级别）的评判结果与人工评估之间的 Spearman 相关系数可以达到 0.8 以上，尤其是在成对比较模式下。这意味着 LLM-as-Judge 可以近似替代昂贵的人工评估。

LLM-as-Judge 的陷阱

• 位置偏见：裁判模型倾向于偏好出现在某个固定位置的答案（通常是第一个）
  • 对策：交换位置再评一次，取平均
• 长度偏见：裁判模型倾向于给更长的回答更高分
  • 对策：控制长度变量，或在 prompt 中明确要求"不要因长度而加分"
• 自我偏好：裁判模型可能对自身风格的回答更有好感
  • 对策：尽量使用与被评估模型不同系列/公司的模型作裁判
• 风格一致性偏见：裁判倾向于偏好与自己风格一致的回答
  • 对策：使用多个不同裁判模型交叉验证

最佳实践

推荐做法：MT-Bench 中的多轮对话评估模式

1. 设计多轮对话场景（含追问）
2. 对每一轮由裁判打分
3. 多个裁判模型（至少 2 个不同系列）
4. 交换位置评估，消除位置偏见
5. 最终分数取多个裁判的平均

3.2 人工评估

当自动化指标不够可靠，或者评估维度过于主观时，人工评估仍然是黄金标准。

人工评估的典型场景

• 安全评估：模型是否输出了危险内容？（LLM-as-Judge 本身可能有盲区）
• 创意写作：诗歌、故事、广告文案 —— 鉴赏需要人类审美
• 偏好测试：A/B 测试哪个回答用户更喜欢
• 红队测试：刻意找漏洞、诱导有害输出（详见第十九章）
• 多模态评估：图片生成质量、视频理解准确性 —— 当前自动化标准不成熟

人工评估的设计要点

关键设计要素	说明
评估者画像	需要什么背景的人？（普通用户/专家/标注员）
评估量	每个样本至少 3-5 人独立评估
评分者间一致性	不同评估者打分的一致性（Krippendorff's α）
盲评设计	评估者不知道哪个是模型输出
对比基线	与参考标准/人类水平/竞争对手对比
评估标准清晰度	明确"好"与"差"的操作性定义

人工评估 vs 自动化评估的成本对比

维度	人工评估	自动化评估
单次评估成本	¥1-10/样本（视复杂度）	¥0.001-0.1/样本（API 调用费）
评估速度	小时到天	分钟到小时
可复现性	低（不同人人不同判）	高（相同输入相同输出）
评估深度	高（理解语境和文化差异）	中（受限于裁判模型能力）
适用规模	百-千级	万-百万级
最佳用途	最终发布前的质检	开发迭代中的快速反馈

3.3 自动化基准评测

自动化基准评测是最传统也是最标准化的方法：固定题目 → 固定答案格式 → 固定评分规则。

标准化评测流程

┌─────────┐    ┌──────────┐    ┌─────────┐    ┌─────────┐    ┌──────────┐
│ 加载基准  │ → │ 构建输入   │ → │ 调用模型  │ → │ 解析输出  │ → │ 比对答案   │
│ 数据集    │   │ prompt    │   │ API推理   │   │ 提取答案  │   │ 计算分数   │
└─────────┘    └──────────┘    └─────────┘    └─────────┘    └──────────┘

评测框架

• OpenCompass：上海 AI Lab 出品，支持 100+ 数据集、50+ 模型的一键评测
• lm-evaluation-harness：EleutherAI 出品，学术界广泛使用的开源评测框架
• HELM（Holistic Evaluation of Language Models）：斯坦福的全面评测体系，覆盖场景评估、安全性、公平性等多维度

自动化评测中的常见陷阱

1. Prompt 敏感性 同一个问题换种问法，分数可能差 10% 以上：

   "请回答以下问题：" vs "你是一位专家，请回答以下问题："
   两句话可能导致完全不同的分数

   对策：Few-shot 评估（给出几个示例）、多 prompt 变体取平均

2. 输出解析失败 模型可能不给直接答案，而是"啰嗦一通"：

   期望：B
   实际：根据我的分析，选项 B 是正确的，因为...
   
   → 解析器需要从这段文字中提取出 B
   → 但解析器可能提取失败，导致正确回答被判错

3. 数据污染 基准题目可能出现在模型的训练数据中：

   模型在 GSM8K 上 100% 正确 ≠ 模型会做数学
                     = 模型可能只是"背过"这些题

   对策：关注新发布的基准、验证模型的泛化能力（相同类型但不同数字的题目）

4. 过度优化风险（Goodhart's Law）

   "当一个指标成为目标时，它就不再是一个好的指标。"

   模型开发者可能针对特定基准进行优化，导致：

   • "高分低能"：基准分数高但实际体验差
   • 基准分数无法反映真实场景中的退化

推荐实践：多维度交叉评估

不要只看一个分数。好的评估策略应该是多维交叉的：

              ┌─────────────────┐
              │   知识基准分数    │
              │  MMLU / C-Eval  │
              └────────┬────────┘
                       │
    ┌──────────────────┼──────────────────┐
    ▼                  ▼                  ▼
┌─────────┐     ┌────────────┐     ┌────────────┐
│ 推理基准  │     │ 人类偏好     │     │ 安全/对齐   │
│ GSM8K   │     │ Arena Elo  │     │ 红队测试    │
│ MATH    │     │ 人工评估    │     │ 偏见评估    │
└─────────┘     └────────────┘     └────────────┘
    │                  │                  │
    └──────────────────┼──────────────────┘
                       ▼
              综合判断模型是否真的好用

4. 总结

模型评估是一个系统工程。没有完美的单一指标——MMLU 高分不代表数学好，Arena 排名高不代表安全。

评估体系需要在标准化 vs 真实感、自动化 vs 深度、单一维度 vs 全面覆盖之间取得平衡。

一个好的评估策略最终服务于一个核心问题：这个模型在真实场景中，到底好不好用？