A Survey on Evaluation of Large Language Models：把"如何评 LLM"做成一个独立学科

  • 关联论文：2307.03109
  • 作者：flyP
  • 更新：2026-07-20

一句话结论

Chang 等人 2023 年 7 月发表、被 ACM TIST 接收的 LLM 评估综述（S2 引用 3500+，影响力引用 130+），提出 "评什么 / 在哪里评 / 怎么评" 三维框架，系统覆盖通用 NLP、推理、医疗、伦理、教育、Agent 等 8 大评估任务族，并维护持续更新的开源材料库，是把"LLM 评估"从附属话题升级为独立学科的奠基性工作。

它在解决什么真问题

2023 年 LLM 圈一个尴尬的现实：模型越来越强，但评测方法越来越乱。

  • benchmark 爆炸：MMLU、HellaSwag、TruthfulQA、HumanEval、GSM8K、BBH、MT-Bench、AlpacaEval、Chatbot Arena、HELM、SuperCLUE、C-Eval、CMMLU……每一个都在测一个切片。
  • 评测方法不一致：同样的 MMLU，有的用 zero-shot，有的用 5-shot，有的用 CoT；同样的代码任务，有的用 pass@1，有的用 pass@10。
  • 评测维度单一：多数 benchmark 只测"答案对不对"，不测"推理过程"、"鲁棒性"、"安全性"、"社会影响"。
  • 缺乏元分析：单点 benchmark 数字互相不可比，没有"哪个 benchmark 测什么能力"的统一坐标。

作者的核心立场是：评测本身应该被当作一门学科来对待，而不是模型论文的附录。

核心方法

1. 三维评估框架

论文提出 What / Where / How 三轴：

  • What to evaluate（评什么）：通用任务、推理、医疗、伦理、教育、Agent、自然科学、社会科学等 8 大领域。
  • Where to evaluate（在哪评）：基准数据集、人类评估、模型自评、对比模型、可解释性工具、嵌入空间分析。
  • How to evaluate（怎么评）：评测指标、prompt 设计、CoT、in-context learning、contamination 检测、稳健性测试。

2. 8 大评估任务族

按"任务族"系统展开：

  • 通用 NLP 任务：文本分类、命名实体识别、情感分析、QA、摘要、翻译。
  • 自然语言推理：NLI、常识推理、物理推理、时间推理。
  • 领域专用：医疗（MedQA、PubMedQA、Med-HALT）、法律（LegalBench）、金融、教育（math、science exam）。
  • 能力维度：知识（MMLU、C-Eval）、推理（GSM8K、MATH、BBH、ARC）、代码（HumanEval、MBPP、APPS）、多模态、Agent（WebShop、AgentBench、SWE-bench）。
  • 社会维度：偏见（BBQ、CrowS-Pairs）、公平性、隐私、有害性。
  • 鲁棒性 / 安全性：对抗 prompt、jailbreak、prompt injection、幻觉、过度自信。
  • 人类对齐：MT-Bench、AlpacaEval、Chatbot Arena、HHH、TruthfulQA。

3. 评测方法学

  • 自动化指标：准确率、F1、BLEU、ROUGE、Pass@k、Log-Likelihood、BertScore、GPT-4-as-judge。
  • 人工评估：单盲 / 双盲对比、Elo 评分、专家标注、众包（MTurk / Prolific）。
  • 模型自评：self-consistency、self-verification、self-critique、LLM-as-judge。
  • 效率维度：latency、cost-per-token、throughput、energy。

4. 失败案例分析

论文专门一节收集"LLM 在 X 任务上失败"的典型案例：

  • 复杂多步推理在 GSM8K 上的早期失败样本；
  • 中文 C-Eval 上 GPT-4 与人类专家的差距；
  • 医疗幻觉案例；
  • 道德两难（trolley problem）回答不稳定。

这部分的价值：让读者建立"benchmark 数字背后的真实表现"的直觉。

5. 评测自身的挑战（meta-evaluation）

  • Benchmark 污染：训练数据与测试集泄漏，导致 SOTA 数字虚高。
  • 数据-能力对应不清：某个 benchmark 涨了，到底是模型真强了，还是 prompt 调过、还是评测脚本优化了？
  • 稳定性：同一模型不同温度 / 不同 prompt 模板，数字差几个百分点。
  • 跨语言公平：中文 / 低资源语言 benchmark 数量与质量显著落后。

关键实验与数据

作为综述，本文不跑统一实验，但给出大量元数据：

  • 整理 200+ benchmark 的任务族 / 题目数 / 评测方式 / 当前 SOTA 四列表。
  • 列出每个任务族上主流模型对比（GPT-4、Claude 2、PaLM 2、LLaMA-2、ChatGLM、Qwen 等）。
  • 维护配套 GitHub 仓库（MLGroupJLU/LLM-eval-survey）和网站 llm-eval.github.io，持续更新新 benchmark、新模型与新方法。

不确定处：具体横评数字随时间漂移，引用本文表格时需配合最新 leaderboard。

亮点与局限

亮点

  • 首次把 LLM 评估当作独立学科：提出"What / Where / How"三维框架，是后续所有 LLM 评估综述 / 工具书的方法论源头。
  • 8 大任务族 + 持续更新：覆盖广、时效长，从 2023 v1 到 v9 持续维护，引用期长达两年以上。
  • 失败案例 + meta-evaluation：不只罗列数字，还讨论"数字背后代表什么"、"评测本身有哪些坑"，对工程团队尤其有价值。
  • 开源材料库：GitHub 仓库与网站持续更新，是事实上的"LLM 评测资源中心"之一。

局限

  • 早期 v1 没覆盖 LLM-as-judge：2023 年 7 月时 GPT-4 做评测还不普及，后续版本有所补充，但仍是其短板。
  • Agent 评测未充分展开：AgentBench、SWE-bench、GAIA 等 2024 年才成熟，本综述早期版本在 Agent 部分覆盖不足。
  • 多模态评测单薄：VLM / Multimodal LLM benchmark 在 2024-2025 才爆发，本综述以文本 LLM 为主。
  • 中文评测章节偏少：C-Eval、CMMLU、SuperCLUE 在表格里出现，但中文能力评估的挑战（语义歧义、古文、时政）未单列讨论。
  • 横评数字非统一复现：表格数字多依赖二手数据，引用时需注明出处与时间。

对工程落地的启发

  1. 先选评测，再选模型：上线一个 LLM 应用，先问"我想评什么能力"，再去对应 benchmark 集合里挑评测方案。不要拿 MT-Bench 数字决定上不上生产。
  2. 评测 pipeline 要包含稳健性 / 安全 / 鲁棒性：单一任务准确率不能上生产，必须加对抗 prompt、jailbreak、幻觉、隐私四类评估。
  3. benchmark 污染是隐形风险：MMLU、HumanEval 已经被训练数据严重污染，新模型数字虚高。优先选择"动态生成 + 时新"的 benchmark（FreshQA、LiveBench、BigCodeBench）。
  4. LLM-as-judge 是性价比神器：MT-Bench、AlpacaEval 的 LLM-as-judge 范式可大幅降低人工评估成本，但要警惕 judge 模型本身的偏见（self-preference bias、position bias）。
  5. 中文场景必须单列评测：C-Eval、CMMLU、SuperCLUE 是入门，但还要补充垂直领域（中文法律、中文医疗、中文代码、中文数学）评测。
  6. 建立持续评测：把评测当 CI 跑，每个新模型、新 prompt、新对齐数据都要回归全套 benchmark，否则容易回归到某一维度的退化自己却不知道。

与同方向工作的关系

  • 直接前驱：Hendrycks et al. 的 Measuring Massive Multitask Language Understanding（MMLU 论文本身）、Wang et al. 的 GLUE / SuperGLUE——这些是单一 benchmark 的奠基，本文把它们上升到"评测学科"层面。
  • 同期综述：
  • Evaluating Large Language Models Trained on Code（HumanEval 论文）；
  • Holistic Evaluation of Language Models (HELM)（Stanford CRFM）；
  • Open LLM Leaderboard（HuggingFace）——这些都是评测体系化的工作，方法论与本综述互补。
  • 下游衍生：
  • AgentBench、SWE-bench、GAIA、MINT、BigCodeBench 等专门评测都引用本综述作为方法学起点；
  • LiveBench、BigBench、Chatbot Arena 等动态 / 人类评估项目在思想上一脉相承。
  • 行业关系：与 Anthropic 的 Constitutional AI 评估、OpenAI 的 Preparedness Framework、Google 的 Responsible AI 评测体系方法论互补。

适合谁读

  • LLM 应用工程师 / 评测工程师：建立评测 pipeline 时的必备工具书。
  • AI 安全 / 对齐研究者：评估"模型是否真对齐"的方法学参考。
  • 产品 / 业务方：理解"模型在生产中可能出问题的地方"以及"如何量化问题"。
  • NLP 研究者：选 baseline、写论文时引用评测方法的标准来源。
  • 学生 / 综述写作者：以本综述为入口，反向检索各任务族原始论文。
  • 监管 / 政策：把"模型能力 vs 风险"框架化的重要参考。

工程落地与核查（Jay）

⚠️ 事实核查存疑处

存疑点 位置 说明
"被 ACM TIST 接收" §一句话结论 arXiv 页面未标注期刊接收状态；建议核查 ACM Digital Library 确认；若仅在审稿中则为未经验证声明
S2 引用 3500+ / 影响力引用 130+ §一句话结论 引用数为实时漂移数据；引用本文前建议以 Semantic Scholar 最新数字为准
GitHub 仓库活跃度 §关键实验 MLGroupJLU/LLM-eval-survey 实际维护状态需独立核验；不可假设"持续更新"即为活跃

实际系统怎么用

评测工具链（2026 年主流）：

# LM Evaluation Harness（EleutherAI）：统一评测框架，支持 200+ benchmarks
pip install lm-eval
lm_eval --model hf \
  --model_args pretrained=meta-llama/Llama-3.1-8B \
  --tasks mmlu,arc_challenge,gsm8k,hendrycks-test* \
  --batch_size 8

# RAGAs（医疗/通用 RAG 评测）
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
results = evaluate(dataset, metrics=[faithfulness, answer_relevancy])

# BigCodeBench（代码评测）
python -m bigcodebench.evaluation.harness \
  --model gpt-4o --temperature 0 --n_samples 1

# Chatbot Arena（人类评估）
# 访问 lmarena.ai 提交对战，不适合自动化 CI

LLM-as-judge 生产落地：

# 警惕 position bias：每轮把 A/B 顺序交换，让 judge 模型评两次取平均
# 警惕 self-preference：用 Claude 评 GPT 模型，反之亦然
# 警惕 length bias：让 judge 同时输出置信度，过短答案自动降权

def judge_with_calibration(answer_a, answer_b, judge_model):
    score_forward = judge(answer_a, answer_b)  # A 优于 B?
    score_reverse = judge(answer_b, answer_a)  # B 优于 A?
    return (score_forward + (1 - score_reverse)) / 2

Benchmark 污染自检：

# 检测 MMLU / HumanEval 是否被污染
# 1. 用 newsela 或动态生成替代数据集
# 2. 用 minhashLSH 查训练数据与测试集重叠率
pip install datasketch
python -c "from datasketch import MinHash; ..."

坑与失败案例

  1. MT-Bench 数字不可直接用于生产决策：MT-Bench 是 8 道题的人类 Elo 评分，样本极小；GPT-4o 和 GPT-4o-mini 在 MT-Bench 可能差 0.5 分，但生产吞吐量 / 成本差 10 倍；以生产 benchmark（实际 query 分布）替代论文 benchmark。
  2. LLM-as-judge 的系统性偏见：judge 模型天然偏好长答案（length bias）、偏好与自己同家族的模型（self-preference）、偏好顺序靠前的答案（position bias）；三重叠加可能导致判断完全反转；每次评测必须做 A/B swap + 长度控制实验。
  3. MMLU / HumanEval 数字严重虚高：GPT-4 Turbo / GPT-4o 的 MMLU 数字在论文里往往用 few-shot，GPT-4o 实际达 ~88%，但这是饱和分数不代表生产质量；不要再把 MMLU 当核心 KPI，改用动态 benchmark（LiveBench、FEC-Bench）。
  4. 中文评测基准缺失：C-Eval / CMMLU 只覆盖通识知识题，垂直领域（中文法律判决书、中文医疗病历）无可靠评测集；建议自建领域评测集并保持定期更新。
  5. Agent 评测严重滞后：SWE-bench 只覆盖 GitHub Issues + PR，实际 Agent 面临的 GUI 操控、多步工具调用、错误恢复等场景无可靠自动评测；Agent 评测仍以人工评估为主，不要被自动化数字误导。
  6. 评测结果发布时滞：论文从提交到发表滞后 6-18 个月，引用本文 benchmark 表格时，数字可能已过时 1-2 代模型；永远查最新 leaderboard 确认当前 SOTA。