大模型评测体系：从传统指标失效到 LLM-as-Judge
传统软件测试是确定性的（输入 A 必须输出 B）；大模型输出是开放且随机的。没有科学的评测体系，迭代就是盲人摸象。
传统 NLP 指标的全面失效
BLEU / ROUGE 为什么死
它们依赖 n-gram 重叠率。看看这个对比：
【标准答案】过拟合就像学生死记硬背练习题，遇到新考题就不会做。
【模型 A】过拟合是指模型在训练集上表现优异，但在测试集上泛化能力差。
（重叠词极少，但 100% 正确）
【模型 B】过拟合就像学生死记硬背练习题，因为他就是死记硬背练习题。
（重叠词极高，但完全是车轱辘废话）
BLEU 会给毫无价值的模型 B 打出高分，却给真正专业的模型 A 打出低分。
更致命的是：大模型最危险的缺陷——幻觉——传统重叠指标完全无法感知。
LLM-as-Judge：用 AI 当裁判
用能力更强的大模型作为裁判，依据显式定义的评分 Rubrics 对候选回答打分。
┌──► [待评估模型 A] ──► [回答 A] ──┐
[用户问题 Input] ─┤ ├──► [Judge 大模型] ──► [评分 + 归因报告]
└──► [基准参照模型 B] ──► [回答 B] ──┘
为什么它有效（以及什么时候有效）
一个强裁判模型经过 RLHF 训练，内化了"人类喜欢什么"。当裁判比被测模型更强时，裁判偏好与人类偏好的相关系数在聚合层面约为 r ≈ 0.7–0.85，但单样本层面很低。
四种必须处理的偏差
偏差 | 表现 | 缓解方法 |
|---|
长度偏差 | 更长 = 更好，即便控制内容 | 交换后取平均；用长度受控的胜率 | 位置偏差 | 成对比较中 A 倾向赢 | 交换顺序跑两次，只在两次一致时计票 | 自我偏好 | GPT-4 偏好 GPT 系输出 | 用多个裁判，或用不同家族的裁判 | 格式偏差 | 要点、加粗、标题看起来更好 | 判断前剥离格式，只评实质 |
位置偏差的缓解是必做项。这是最容易被忽略、也最容易把评测结论带偏的地方。 长度受控胜率AlpacaEval 2 引入的指标，把长度因素回归掉。不这么做的话，"请回更多文字"看起来就能打败推理能力的改进。 永远报告长度受控的指标。 裁判校准用 50-100 个输出比较裁判评分与人工评分，相关系数 r > 0.8 才认为裁判可靠。 并且始终使用同一个裁判——不同裁判有不同的偏差。 Agent 评测：四维能力雷达评估单轮对话只需看"语言流畅度"，但评估自主 Agent 必须考察任务完成闭环能力： 任务规划 (Planning)
/ \
/ \
工具调用 ◄──┼──► 逻辑推理 (Reasoning)
(Tool Use) │ (Reasoning)
\ /
\ /
状态记忆 (Memory)
维度 | 考察什么 |
|---|
任务规划 | 能否把复杂目标拆成可执行步骤 | 工具调用 | 能否选对工具、传对参数 | 逻辑推理 | 多步推理是否正确 | 状态记忆 | 跨步骤能否保持上下文 |
主流 Agent 基准基准 | 考察 |
|---|
SWE-bench | 自动修复真实 GitHub 仓库的 Issue（代码阅读、Bug 定位、测试通过率） | GAIA | 需要网络搜索 + 文件解析 + 多步逻辑推导的综合难题 | WebArena | 在真实 Web 界面自动完成购物、订票等 UI 操作 | OSWorld | 桌面 computer-use Agent | TAU-bench | 真实客服场景 + 模拟用户，多轮工具使用 | MLE-Bench | 完整的机器学习工程任务（Kaggle 式竞赛） |
SWE-bench Verified 当前前沿约 70% 解决率——这是 Agent 编码能力的金标准。 可验证指令遵循：IFEvalIFEval 是指令遵循评测的金标准，因为它完全去掉了裁判环节。 指令是可程序化检查的： 按指令和按提示词报告通过率。 产品项目里一定要加可验证指令的评测。 它们能抓到裁判抓不到的回归——因为裁判本身也在漂移。 公开基准的四个陷阱陷阱 | 说明 |
|---|
污染 | 测试题泄漏进预训练数据，虚高分数。HumanEval 约 40% 被污染；GSM8K 去污染后掉 13 分 | 饱和 | 最强模型达到 ~95% 后就没有提升空间 | 窄化 | 优化 MMLU 不保证真实世界有用 | 误导 Agent | 静态 QA 基准无法刻画多步工具循环中的表现——而那才是用户实际体验 |
公开基准只应作为方向性信号。 2026 年前沿模型的参考成绩以下是 SWE-bench Verified 和 GPQA Diamond 的公开数值，供建立量级感（不是绝对对比，版本和设置会影响结果）： 模型 | SWE-bench Verified | GPQA Diamond |
|---|
Claude Opus 4.5 | ~78% | ~84% | GPT-5 | ~74% | ~85% | Gemini 2.5 Pro | ~63% | ~84% | Llama 4 405B | ~55% | — | DeepSeek-R1 | ~50% | — |
注意一个有意思的现象：Chatbot Arena 的前沿分差在约 40 Elo 以内，说明主观质量差异比数值基准显示的更小。 一份可辩护的最小评测套件对于 2026 年的前沿模型评测： 通用能力
├─ MMLU-Pro
├─ GPQA-Diamond
└─ IFEval
数学与代码
├─ MATH-500
├─ AIME
├─ LiveCodeBench
└─ SWE-Bench-Verified
对话质量
├─ MT-Bench / Arena-Hard
└─ 多轮场景测试
长上下文
└─ RULER
安全
├─ TruthfulQA
├─ SimpleQA
└─ XSTest（过度拒答）
多模态（如需要）
└─ MMMU
+ 产品特定任务
XSTest 值得单独说：它测过度拒答——那些本该回答但模型错误地拒绝了的问题。这是生产环境里非常常见但很少被主动评测的失败模式。 Sycophancy 探测也值得做：先问一个问题，然后说"我觉得答案是 X（错的）"——看模型会不会跟着翻转。 评测工具工具 | 出处 | 适合 |
|---|
Inspect AI | UK AISI | 学术与评测研究 | Promptfoo | 开源 | 快速对比多个模型/提示词 | Braintrust | 商业 | 评测 + CI 门禁 | LangSmith | LangChain | 轨迹追踪 + 评估 | lm-evaluation-harness | EleutherAI | 复现公开基准 | Anthropic evals library | Anthropic | Agent 轨迹评估 |
一条根本原则对于创业产品，能力基准远不如你自己的任务评测重要。 构建一个你自己的评测集： 50-200 条真实用例
人工标注期望输出
每次改动都跑
作为 CI 门禁
这是你唯一可靠的评测工具。 一个常见的误用是：拿公开基准做路由决策。路由决策应该基于你的流量模式——如果你的真实流量是"连接器驱动的多工具链"和"短语音轮次"的混合，MMLU 和 SWE-bench 都刻画不了。 分阶段评测策略阶段 | 做什么 | 关注指标 |
|---|
训练中 | 跟踪困惑度和验证损失 | val loss ↑ 而 train loss ↓ = 过拟合 | 训练后 | 跑基准套件 | 任务指标 + 与基座对比检测遗忘 | 上线前 | LLM-as-judge + 人工评估 | 与人工校准 r > 0.8 | | | |
| 生产中 | 监控质量与忠实度 | 用户反馈、错误率，设置告警 |
|---|
参考资料
RAGAS 论文 — https://arxiv.org/abs/2309.15217
Zheng et al., *Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena* — https://arxiv.org/abs/2306.05685
GSM8K / HumanEval 污染研究 — https://arxiv.org/abs/2407.19863
SWE-bench — https://www.swebench.com/
Inspect AI — https://inspect.aisi.org.uk/
SuperCLUE 中文大模型测评 — https://www.superclueai.com/
