评估与基准：如何判断模型好坏
直觉版：没有单一分数能概括模型
Section titled “直觉版：没有单一分数能概括模型”评估 LLM 就像评估一个人：你不会只看数学成绩就判断他是否优秀。模型可能在知识问答上得分高，但在代码生成、逻辑推理或多轮对话上表现平平。好的评估需要多维度、多场景、多难度的综合测试。
工程版：选择适合任务的评估策略
Section titled “工程版：选择适合任务的评估策略”工程上，评估分为几个层次：
- 自动指标：困惑度（perplexity）、BLEU、ROUGE 适用于有标准答案的任务；代码用 pass@k；推理用准确率。但自动指标往往与真实用户体验不完全一致。
- 模型作为评判（LLM-as-a-judge）：用更强的模型评估较弱模型的输出，MT-Bench 等基准采用此法。成本低但存在位置偏差、长度偏差和自身偏好问题。
- 人类评估：金标准，但昂贵且慢。常用于对齐评估、创意写作和开放式对话。
- 红队测试（Red Teaming）：主动寻找模型的失败模式，包括 jailbreak、提示注入、偏见和危险内容生成。
常见陷阱包括：训练数据污染（测试集已出现在预训练数据中）、提示敏感性（换种问法分数大变）、以及过度优化单一基准导致的能力扭曲。
研究版：评估即科学
Section titled “研究版：评估即科学”研究层面，评估本身就是科学问题。HELM 提出了 holistic 评估框架，强调场景、指标和目标的全面覆盖。但评估与现实部署之间仍有鸿沟：基准上的领先不等于产品中的好用。
开放问题包括：如何评估涌现能力？如何量化解码策略对评估结果的影响？如何设计不易被”刷分”的基准？以及，当模型能力接近或超过人类时，谁来担任评判者？
🔬 开放研究问题
该领域的关键问题与研究方向：
- LLM-as-a-Judge 的偏差来源有哪些？如何设计更公正的评估协议？
- 数据污染（data contamination）问题在静态 benchmarks 中如何系统性地检测和缓解？
- Holistic 评估（如 HELM）与任务特定评估之间的张力如何调和？
本文引用论文
- Measuring Massive Multitask Language Understanding
57 学科 1.4 万道考题，从此"刷 MMLU"成为衡量 LLM 通用能力的事实标准。即使在 2025 年仍是模型卡里第一行的指标；另见后续 MMLU-Pro。
- Holistic Evaluation of Language Models
Stanford CRFM 系统化评测 30+ LLM × 多维度指标（准确性、鲁棒性、公平性、效率…），把"评测科学"立起来。是反"只看平均分"的代表性工作。
- Evaluating Large Language Models Trained on Code
提出 Codex 模型 + HumanEval 基准（164 道编程题）。HumanEval 至今是 coding 模型的"心电图指标"；这篇论文也是 GitHub Copilot 的根。
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
提出 GPT-4-as-judge + 人类偏好众包 (Chatbot Arena) 评测对话能力。MT-Bench 和 Arena ELO 至今是社区比较模型"对话能力"的事实双标准。
- Stop Uploading Test Data in Plain Text: New Protocols for Dataset Release
提出检测和预防基准数据污染的系统方法。通过分析模型在污染数据上的异常表现模式（如逐字记忆测试集），可以可靠地检测预训练数据是否包含公开测试集。呼吁发布加密或延迟公开的测试集。
- Large Language Models are not Fair Evaluators
系统评估了 LLM-as-a-Judge 方法的偏见问题：位置偏见（偏好第一个回答）、长度偏见（偏好更长的回答）和自增强偏见（偏好自己生成的内容）。提出了缓解这些偏见的方法，如交换位置评分和引入参考答案。