MMLU、HumanEval、GSM8K 这套组合在 2025 年前后已经被沿用多年，主流的大模型评测体系也已形成两条线：通用知识与推理（以 MMLU、HellaSwag、ARC 为代表），以及垂直能力（代码 HumanEval/MBPP、数学 GSM8K/MATH、长上下文 RULER、对齐 MT-Bench、人类偏好 LMSYS Chatbot Arena）。单纯刷榜意义有限，真正可用的评估需要避开”基准饱和”、”训练集泄露”、”指标片面”三大坑，并按业务场景把多个 Benchmark 组合起来看。
一、评测体系的两条主线
| 评测线 | 关注能力 | 代表 Benchmark | 典型指标 |
|---|---|---|---|
| 通用知识与推理 | 跨学科广度、常识、阅读理解 | MMLU、HellaSwag、ARC-Challenge、WinoGrande | 准确率 |
| 垂直能力 | 代码、数学、指令跟随、长上下文、对齐 | HumanEval、GSM8K、MATH、MT-Bench、IFEval、RULER | pass@k、准确率、Elo |
通用线的好处是”覆盖广、能跨模型横比”，坏处是高分模型之间的差异越来越小。垂直线的好处是”贴近业务”，坏处是不同 Benchmark 测的不是同一类能力，组合看才稳。
二、五类核心 Benchmark 对照
下面这张表是 2025 年最常被引用的五类评测基线：
| Benchmark | 任务类型 | 规模 | 典型饱和点 | 主要风险 |
|---|---|---|---|---|
| MMLU | 57 学科多选题 | 万级 | 接近饱和，前沿模型冲高 90%+ | 训练集泄露、选择题随机猜 |
| GSM8K | 小学数学应用题 | 8500 题 | 高分段接近上限 | 死记硬背，迁移性弱 |
| HumanEval | Python 函数级代码补全 | 164 题 | 头部模型 pass@1 达到高水平 | 题目过少、覆盖窄 |
| MT-Bench | 多轮对话质量 | 80 题 | 用 LLM-as-Judge | 裁判偏差 |
| LMSYS Chatbot Arena | 人类偏好盲测 ELO | 持续累积 | 持续刷新 | 提交成本高 |
注意表里”典型饱和点”是经验范围（”接近饱和”），具体到某个模型版次的数字会随评测协议和测试集更新而变化，应以最新发布为准。
2.1 MMLU 与”基准饱和”问题
MMLU 涵盖 57 个学科的多选题，长期是大模型”通用知识”的代理指标。但前沿模型已经在多个学科接近人类水平，整体均值被推到很高的位置，单看 MMLU 数字很难再区分模型差异。社区的应对是 MMLU-Pro：把选项从 4 个扩到 10 个以上，并扩充到上万题，迫使模型真正做推理而不是猜答案。
2.2 HumanEval 与”题目太少”问题
HumanEval 只有 164 题，覆盖面窄，且全部是函数级 Python 题。对生产代码场景（多文件、跨语言、需要测试与维护）远远不够。LiveCodeBench、SWE-Bench、BigCodeBench 等持续更新的基准正在补这块——SWE-Bench 直接拿真实开源仓库的工单端到端评估智能体，看模型能不能定位、修改、跑通测试。
三、评估框架的差异：HELM vs. lm-eval-harness
| 框架 | 出品方 | 评测维度 | 适用场景 | 成本 |
|---|---|---|---|---|
| HELM | Stanford CRFM | 准确性、校准、鲁棒性、公平性、偏见、毒性、效率（7 类 × 42 场景） | 学术级多维评估 | 高（百万级 API 调用） |
| lm-eval-harness | EleutherAI | 数百个 Benchmark 标准化复现 | 通用开源评测 | 中等 |
| OpenCompass | 社区 | 中文场景 + 多模态扩展 | 中文模型评估 | 中等 |
| RAGAS | 社区 | RAG 场景的忠实度、相关性、上下文指标 | RAG 应用 | 低 |
HELM 适合”我想全面了解一个模型的画像”，lm-eval-harness 适合”我要快速对一堆模型跑标准 Benchmark”，OpenCompass 适合中文场景，RAGAS 适合 RAG 应用。生产里通常组合使用：先用 lm-eval-harness 跑基线，再用 HELM 做选型对照，最后用业务私域数据集校准。
四、选 Benchmark 的工程步骤
按下面 5 步把评测做成可重复的工程动作：
- 明确业务目标：选”通用能力”还是”代码/数学/对话”哪一类；
- 选 3-5 个互补 Benchmark：每类至少 1 个，避免单点看花眼；
- 统一 Prompt 协议：zero-shot 还是 few-shot、是否要求 CoT，必须在每次评估中固定；
- 跑对照：在同一硬件/同一 Prompt 协议下，测新模型与基线模型，差值才是有效信号；
- 加业务私域评估：用真实业务样本 + 专家标注做最后一公里校准。
第 4 步的”差值”是关键。单看一个模型的绝对分数没意义，因为 Benchmark 之间的 prompt、温度、采样数都不同；只有在同一条件下做对照，才能归因差异来自模型本身还是配置。
下面是一段最小可运行的评估脚本（Python + lm-eval-harness）：
import lm_eval
from lm_eval.models.huggingface import HFLM
# 1. 加载待评估模型
model = HFLM(pretrained="my-llm-7b", dtype="bfloat16")
# 2. 选定基准（多选互补）
tasks = ["mmlu", "gsm8k", "humaneval"]
# 3. 统一评测参数
results = lm_eval.simple_evaluate(
model=model,
tasks=tasks,
num_fewshot=0, # 统一 zero-shot
batch_size=8,
temperature=0.0, # 确定性采样
)
# 4. 打印关键指标
for task, metrics in results["results"].items():
print(f"{task}: {metrics}")温度置零、shot 数固定、batch 一致——这三个参数不固定，跨模型对比就是噪声。
五、几类常见误用
把”刷榜”当成”能力”是第一个误用。基准饱和之后，0.5 个百分点的提升可能只是评测协议差异，不代表真实能力跃迁。第二个误用是忽略训练集泄露——MMLU、GSM8K 的题面在网上随处可见，未经污染检测就报数字会严重虚高。第三个是只看准确率不看其他维度——模型可以”答得对但答得不诚实”或”答得快但答得贵”，单维指标会鼓励模型做有偏优化。
六、几个补足工具
- lm-eval-harness：开源评测标准框架，覆盖数百个 Benchmark；
- HELM：学术多维评估，画像式打分；
- OpenCompass：中文场景与多模态扩展；
- RAGAS：RAG 应用专项，含忠实度、相关性等指标；
- LiveCodeBench：月度更新的代码基准，抗污染；
- LMSYS Chatbot Arena：真实人类偏好 ELO。
这六个工具组合起来基本能覆盖从学术研究到生产选型的需求。具体选哪个，取决于团队是在做”研究复现”还是”业务选型”。
常见问题（FAQ）
Q1：MMLU 已经饱和了，还有必要看吗？
可以看，但要和 MMLU-Pro、GPQA 等新基准一起看，避免被饱和度误导。
Q2：HumanEval 高分代表代码能力强吗？
不完全。HumanEval 只测单函数补全，真实工程能力要看 SWE-Bench、LiveCodeBench。
Q3：业务落地该怎么选评测组合？
先 1-2 个公开 Benchmark 做横比，再用 200-500 条业务私域样本做最后一公里校准。
