5.6 模型评估

核心问题： 如何判断一个 LLM 是否"好"？评估为什么比想象中难？

在线 Notebook

对应的交互式版本可在 Google Colab 打开，统一使用方式见第0章说明。

为什么评估 LLM 很难

传统机器学习的评估很简单：分类准确率、回归 MSE，有标准答案，一个数字说明一切。

LLM 的评估难在：

问题：写一首关于秋天的诗
回答A：秋风萧瑟，落叶纷飞，天高云淡，雁南飞。
回答B：秋天来了，树叶变黄了，天气变冷了。

哪个更好？为什么？怎么量化？

核心困难：

开放式生成没有唯一正确答案
质量是多维度的（准确、有用、安全、流畅）
人类评估成本高且主观
自动指标和人类判断经常不一致

自动评估指标

Perplexity（困惑度）

定义： 模型对测试文本的"惊讶程度"，越低越好。

PPL = \exp (- \frac{1}{N} \sum_{i = 1}^{N} \log P (w_{i} | w_{1}, \dots, w_{i - 1}))

直觉： PPL=10 意味着模型平均在 10 个候选词中选择下一个词；PPL=100 意味着模型很"困惑"。

局限： 只衡量语言建模能力，不衡量有用性、准确性或安全性。PPL 低的模型不一定是好助手。

主流 Benchmark

知识与推理

Benchmark	内容	题型	说明
MMLU	57 个学科（数学、历史、法律...）	4 选 1	最广泛使用的知识评估
HellaSwag	常识推理，补全句子	4 选 1	测试日常常识
ARC	小学/初中科学题	4 选 1	分 Easy/Challenge 两档
TruthfulQA	容易产生幻觉的问题	判断/生成	测试模型是否会"一本正经地胡说"

数学与代码

Benchmark	内容	题型	说明
GSM8K	小学数学应用题（8500 题）	生成答案	测试多步数学推理
MATH	竞赛数学（12500 题）	生成答案	难度高，顶级模型也只有 50-80%
HumanEval	164 个 Python 编程题	生成代码	OpenAI 发布，测试代码生成
MBPP	500 个 Python 编程题	生成代码	比 HumanEval 更多样

对话与指令遵循

Benchmark	内容	题型	说明
MT-Bench	80 个多轮对话问题	GPT-4 打分	测试对话质量，LLM-as-Judge
AlpacaEval	805 个指令	GPT-4 对比	与 GPT-4 输出对比胜率
IFEval	541 个带格式要求的指令	规则检查	测试指令遵循的精确度

中文评估

Benchmark	内容	说明
C-Eval	52 个中文学科	中文版 MMLU
CMMLU	67 个中文主题	更多中国特色题目
GAOKAO-Bench	高考真题	贴近中国教育场景

人工评估

自动 Benchmark 有局限，人工评估更接近真实使用体验。

偏好标注

给标注者两个模型的回答，让他们选择更好的那个：

问题：如何学习编程？

模型A的回答：建议从 Python 开始，先学基础语法...
模型B的回答：编程学习需要循序渐进，首先...

标注者选择：□ A 更好  □ B 更好  □ 差不多

优点： 直接反映人类偏好，不受 Benchmark 格式限制。
缺点： 成本高，标注者之间一致性差，难以规模化。

Chatbot Arena（LMSYS）

机制： 用户匿名对比两个模型的回答，投票选择更好的，用 ELO 排名系统计算分数。

用户提问 → 两个匿名模型各自回答 → 用户投票 → ELO 更新

优点： 真实用户、真实问题、大规模（数百万次对比）。
缺点： 用户偏好可能偏向某些风格（冗长、自信），不一定等于"正确"。

LLM-as-Judge

用强模型（GPT-4、Claude）评估弱模型的输出，替代人工评估。

评估 prompt：
  问题：{question}
  模型回答：{answer}
  请从准确性、有用性、安全性三个维度打分（1-10），并说明理由。

MT-Bench 就是用 GPT-4 作为评判者，对 80 个多轮对话打分。

优点： 比人工评估便宜 100 倍，可以规模化。
缺点： 评判者模型本身有偏见（倾向于自己风格的回答），存在"自我偏好"问题。

评估的局限：Goodhart's Law

"当一个指标变成目标，它就不再是好指标了。"

Benchmark 刷分问题：

现象：
  模型在 MMLU 上得分 90%
  但实际使用中表现平平

原因：
  训练数据中包含了 MMLU 的题目（数据污染）
  或者针对 MMLU 格式专门优化（过拟合）

已知的刷分案例：

部分模型在 GSM8K 上表现异常好，但换一种表述方式就失败
Benchmark 题目被包含在训练数据中（数据污染）
针对特定 Benchmark 格式的专项训练

应对方法：

使用多个 Benchmark，避免单一指标
定期更新 Benchmark，减少数据污染
结合人工评估和 Chatbot Arena
关注模型在新问题上的表现，而非已知题目

评估维度总结

一个完整的 LLM 评估应该覆盖多个维度：

维度	评估方法	代表 Benchmark
知识广度	多选题	MMLU、C-Eval
数学推理	解题	GSM8K、MATH
代码能力	生成+执行	HumanEval、MBPP
指令遵循	规则检查	IFEval
对话质量	LLM 打分	MT-Bench
真实偏好	人工投票	Chatbot Arena
安全性	红队测试	TruthfulQA、专项测试

代码实验

Benchmark Comparison

图5.6a：LLM 评估基准对比——MMLU、HumanEval、MT-Bench 等主流基准的覆盖维度与适用场景。

代码文件： code/ch05_llm_basics/benchmark_comparison.py
运行方式： python code/ch05_llm_basics/benchmark_comparison.py

本节小结

LLM 评估比传统 ML 难，因为开放式生成没有唯一答案，质量是多维度的
自动 Benchmark（MMLU、HumanEval、GSM8K）高效但有局限，容易被刷分
人工评估（偏好标注、Chatbot Arena）更接近真实体验，但成本高
LLM-as-Judge 是折中方案，用强模型评估弱模型
Goodhart's Law：当 Benchmark 变成优化目标，它就失去了评估价值——需要多维度、持续更新的评估体系

扩展阅读： E5.x 评估方法调研

下一章： 第6章：LLM应用

5.6 模型评估 ​

为什么评估 LLM 很难 ​

自动评估指标 ​

Perplexity（困惑度） ​

主流 Benchmark ​

知识与推理 ​

数学与代码 ​

对话与指令遵循 ​

中文评估 ​

人工评估 ​

偏好标注 ​

Chatbot Arena（LMSYS） ​

LLM-as-Judge ​

评估的局限：Goodhart's Law ​

评估维度总结 ​

代码实验 ​

本节小结 ​