LLM 评估体系——方法、基准与判断力

传统机器学习的评估有一套成熟的约定：分类看 Accuracy/F1，回归看 MSE，跑个 k-fold 交叉验证，结果就基本可信。但 LLM 的输出是自然语言——「北京的别称」和「中国首都的别称」指向同一个答案，token 序列却完全不同。同一个问题换一种措辞，同一个模型可能给出相反的答案。选择题做对了不一定代表理解，可能只是「蒙对了」。

评估 LLM 不是跑几个 Benchmark 然后看谁分高。选错评估方式、忽略数据污染、把单次 Benchmark 分数当作模型能力的等价指标——任何一个环节出问题，都会造成「评测结果好看，线上效果稀烂」的错位。本文梳理 LLM 评估的核心维度、主流方法和关键陷阱，帮助读者建立对评测数字的批判性判断力。

一、评估维度：模型能力不是单一数字

评估 LLM 首先需要回答「测什么」。不同下游场景对模型的要求完全不同——一个数学竞赛冠军可能完全不会写安全的 API 响应。

1.1 知识与推理

衡量模型「知道什么」和「能从已知推出什么」。MMLU 是当前最通用的「模型能力标尺」，覆盖 57 个学科的选择题。但仅靠选择题分数会高估模型的理解深度——MMLU Chain-of-Thought（让模型先推理再选）比直接选择更能反映真实推理能力，高分模型的排序也可能因此改变。

Benchmark 考察方向 题型 规模
MMLU 57 学科综合知识 选择题 ~14K 题
C-Eval 中文综合知识 选择题 ~14K 题
HellaSwag 常识推理（完形填空） 选择题 ~10K 题
ARC 科学推理（小初高） 选择题 ~7.8K 题
BIG-Bench 200+ 子任务综合 混合 超大

1.2 数学与符号推理

GSM8K 是最常用的数学推理基准——8.5K 道小学数学应用题，需要逐步推理而非直接输出答案。但 GSM8K 有一个被反复验证的陷阱：模型的高分可能来自「背答案」而非推理能力。GSM-Symbolic 将题目中的数字和名称随机化后，多数模型的分数会大幅下滑——暴露出的是记忆而非理解。

Benchmark 考察方向 说明
GSM8K 小学数学应用题 最通用的数学基准，但存在记忆化风险
MATH 竞赛级数学 含代数、几何、微积分，难度远超 GSM8K
GSM-Symbolic 符号随机化的 GSM8K 用于区分「推理」和「记忆」

1.3 代码能力

HumanEval 是代码能力的首选基准，但 pass@k 指标需要仔细解读：k=1 和 k=100 的差距意味着模型可能只有 60% 的概率一次写对，但给 100 次机会总有一次是对的。在生产环境中，pass@1 才是体感指标。

Benchmark 考察方向 评估方式
HumanEval Python 函数补全 pass@k
LiveCodeBench 实时更新的编程题 防数据污染
SWE-bench 真实 GitHub Issue 修复 端到端软件工程

1.4 对话与指令跟随

知识与推理 Benchmark 衡量的是「模型知道什么」，但用户真正感受的是「模型好不好用」——这涉及到流畅度、有用性、安全性和指令跟随的准确性。MT-Bench 用 GPT-4 评分多轮对话质量，Chatbot Arena 用真实用户的盲评投票——后者虽有偏差，但最接近实际体验。

二、评估方法：四种范式及其内置的偏见

确定了评估维度后，下一个问题是「怎么测」。四种方法的差异不仅是工程实现层面的，更是方法论层面的——每种方法自带一套系统性偏见。

2.1 选择题：客观但脆弱

模型输出每个选项的 log-likelihood，选最高的。这是最常用的方法——可复现、自动化、可大规模运行。但选择题对 Prompt 格式极度敏感：选项用 A/B/C/D 还是 ①/②/③/④、Few-shot 示例的顺序和数量、甚至选项之间的长度差异，都会显著影响分数。这种敏感性本身就是一个信号：选择题测的是「模型在特定格式下的表现」，不是泛化的能力。

2.2 开放生成 + 规则匹配：接近真实但提取脆弱

模型自由生成答案，用正则表达式提取最终结果后再比较——常用于 GSM8K 等推理任务。但这引入了新的脆弱性：「答案为 42」「我认为结果是 42」「答案是 42.0」——三句话意思一样，但正则能否正确提取全看规则写得是否鲁棒。

2.3 LLM-as-Judge：能评估质量，也自带偏见

用 GPT-4 等强模型对生成结果打分，解决了规则匹配无法处理的主观评价问题。但裁判模型本身存在系统性偏见：长度偏好（更长的回答倾向打高分）、位置偏好（先出现的回答有优势）、自身增强偏见（裁判模型偏好自己同类模型的输出）。MT-Bench 和 AlpacaEval 的分数需要结合这些偏见来解读。

2.4 人类盲评：金标准，但不可规模化

Chatbot Arena 的 Elo 排名是当前最受关注的「用户体感」指标——真实用户看不到模型名称，只对两段回答投票。但代价也很明显：慢、贵、不可复现，且存在标注员文化背景和偏好的影响。

四种方法的本质权衡：客观的不可感（选择题分数 ≠ 用户体验），可感的不客观（LLM-as-Judge 和人类评估各有偏见）。好的评估策略不是选一种，而是用四种方法交叉验证。

三、陷阱：为什么「SOTA」经常不可信

Benchmark 分数和模型能力之间的差距，往往来自三个系统性陷阱。

3.1 数据污染

训练数据中可能包含 Benchmark 原题或高度相似的题目。模型不是在「推理」——它在「回忆」训练数据。检测手段包括 n-gram 重叠分析、使用模型训练截止日期之后发布的 Benchmark 版本，以及动态更新的基准（如 LiveCodeBench）。

3.2 Prompt 敏感性

同一模型在略微不同的 Prompt 下，同一 Benchmark 的分数可以差 5-10%。这意味着「分高」不等于「模型强」——可能只是「Prompt 写得好」。好的评估应该使用多套 Prompt 模板，报告均值与方差，而非单次最高分。

3.3 维度错配

用 GSM8K 证明「数学好」、用 HumanEval 证明「能用」——这是能力维度的偷换概念。GSM8K 只测小学到初中难度的应用题，HumanEval 只测简短的函数补全。当模型声称在这些基准上超越人类时，需要追问：超越的是哪个维度上的人类？

四、工具与框架

工具 特点 适用场景
HELM (Stanford) 最全面的多维评估框架，覆盖 40+ 场景 学术研究、模型横向对比
lm-evaluation-harness 开源社区标准，支持 200+ benchmark 日常开发、论文复现
OpenCompass 中文 benchmark 覆盖最全 中文模型评估
Chatbot Arena 人类偏好盲评 用户体感参考

五、相关资源