大型语言模型评估基准手册：2026 年 5 月完整版

Handbook for Large Language Model Evaluation Benchmarks — Full Academic Markdown Edition, May 2026

版本日期： 2026-05-31
文档类型： 研究论文式学术报告 / 技术手册
适用范围： 大型语言模型（LLM）与语言智能体（language agents）的研究评测、产品验收、模型选型、风险审计与基准建设

摘要

大型语言模型（Large Language Models, LLMs）的评估体系在 2023—2026 年间发生了范式性变化：早期以静态题库、单一分数、选择题准确率和学科考试式测量为主的评估方法，正在被动态化、任务化、场景化、可审计、可复现以及元评估（meta-evaluation）导向的体系取代。MMLU、GSM8K、MATH、BBH、HumanEval 等经典基准仍具有纵向比较和历史定位价值，但在前沿模型上已普遍面临区分度下降、数据污染、题目噪声、提示敏感性和饱和效应等问题。与此同时，MMLU-Pro、GPQA、Humanity's Last Exam、BBEH、SimpleQA、LiveCodeBench、SWE-bench、OSWorld、GAIA、BrowseComp、HealthBench、LongBench v2、RULER、InfiniteBench、SEA-HELM、GDPval 等新一代基准将评估焦点扩展到专家级知识、短答案事实性、真实软件工程、长上下文理解、浏览与工具使用、临床对话、跨语言文化适配和真实经济任务。

本文以截至 2026 年 5 月可公开检索的学术论文、官方基准说明、开源工具链和评估框架为基础，构建一套面向 LLM 评估基准的系统性手册。报告首先定义“基准”的构成要件与能力构念，随后梳理 benchmark 的历史演化和分类体系；在此基础上提出一套从效度、信度、区分度、抗饱和性、抗污染性、生态影响、可复现性、成本与风险适配性出发的元评估框架；最后给出实验设计、统计检验、LLM-as-a-Judge 校准、人类在环评估、评估报告模板、基准卡模板和应用场景下的推荐基准组合。本文的核心结论是：2026 年的高质量 LLM 评估不应只问“模型在某个榜单上得了多少分”，还必须同时回答“该基准是否仍然有效、是否测量了目标能力、是否存在污染和饱和、评分过程是否可复现、结论不确定性有多大，以及这些分数能否迁移到目标部署场景”。

关键词： 大型语言模型；评估基准；元评估；LLM-as-a-Judge；数据污染；基准饱和；可复现评估；语言智能体；模型审计；Benchmark Health Index

Abstract

The evaluation of large language models has shifted from static, single-score academic benchmarks toward dynamic, scenario-grounded, reproducible, auditable and meta-evaluation-aware protocols. Classic benchmarks such as MMLU, GSM8K, MATH, BBH and HumanEval remain historically important, but they are increasingly limited by saturation, contamination, label noise and prompt sensitivity. Newer benchmarks such as MMLU-Pro, GPQA, Humanity's Last Exam, BBEH, SimpleQA, LiveCodeBench, SWE-bench, OSWorld, GAIA, BrowseComp, HealthBench, LongBench v2, RULER, InfiniteBench, SEA-HELM and GDPval shift the focus toward expert-level reasoning, short-form factuality, real software engineering, long-context understanding, browsing and tool use, clinical dialogue, multilingual-cultural robustness and economically valuable real-world tasks. This report develops a research-paper-style handbook for LLM benchmark selection, benchmark auditing and evaluation protocol design as of May 2026. The main thesis is that frontier-model evaluation must evaluate both models and benchmarks: a benchmark score is decision-useful only when its construct validity, reliability, discriminability, anti-saturation, contamination resistance, reproducibility and deployment relevance are made explicit.

1. 引言

LLM 基准并不是简单的题库。严格意义上的评估基准至少包含四个组成部分：任务或数据集合、运行协议、评分规则和报告规范。缺少其中任何一个要素，模型分数都难以被解释、比较或复现。HELM（Holistic Evaluation of Language Models）提出的整体评估理念表明，模型评估不应只关注准确率，还应同时覆盖校准、鲁棒性、公平性、偏见、毒性、效率等多维指标，并公开模型输入、输出和评估配置以提升透明度。¹

2023 年之后，LLM 评估面临三个结构性变化。第一，模型能力快速提升导致大量传统基准出现天花板效应。MMLU-Pro 的提出即以 MMLU 的分数平台化为背景，通过更困难的问题、更复杂的推理需求和更多选项提升区分度。² BBEH 则明确指出 BBH 已在许多任务上趋于饱和，因此用更难的任务替代原有 BBH 子任务。³ 第二，公开训练语料、合成数据和后训练数据不断扩大，导致 benchmark contamination 成为系统性威胁。数据污染综述表明，训练集与测试集的重叠会高估模型泛化能力，并使静态公开题库的分数解释变得不稳定。⁴ 第三，LLM 正从文本补全或问答模型演化为具备工具调用、浏览、代码执行、GUI 操作和多轮协作能力的语言智能体，因而静态问答高分已不足以代表真实部署能力。GAIA、OSWorld、BrowseComp 和 GDPval 均是这一转向的代表。⁵⁶⁷⁸

本文的研究目标并不是建立一个新的排行榜，而是回答三个更基础的问题：

1. 基准地图问题： 截至 2026 年 5 月，LLM 评估基准可以如何分类？不同类别分别测量什么能力构念？
2. 基准质量问题： 如何评价一个 benchmark 本身是否仍然可靠、有效、可区分且未过度饱和？
3. 评估协议问题： 在研究、产品、采购、安全审计和高风险领域部署中，如何设计可复现、可审计、统计上稳健的评估流程？

本文的基本立场是：单一 benchmark 分数不构成充分证据。一个评估结论只有在披露模型版本、数据版本、提示词、推理预算、工具权限、随机性设置、评分器、人工复核、置信区间和误差分析后，才具备足够的科学解释力。

2. 概念定义与问题形式化

2.1 Benchmark 的最小构成

本文将 LLM 评估基准定义为：

用于测量模型或模型系统在特定能力构念上的可复现表现的一组任务、数据、执行条件、评分规则和报告约定。

其中，“模型系统”可以只是一个裸模型，也可以是包含检索、工具调用、浏览器、代码解释器、记忆、规划器和代理框架的完整系统。AI system evaluation framework 的相关研究强调，安全和能力评估应超越模型中心主义，因为工具权限、环境约束和系统脚手架都会改变能力与风险表现。⁹

一个完整 benchmark 应至少说明：

• 构念定义（construct）： 测量的是知识、推理、事实性、长上下文、代码、偏好、安全、工具使用还是专业任务？
• 任务分布（task distribution）： 任务从何而来，覆盖哪些域，是否接近目标使用场景？
• 输入输出形式： 选择题、短答案、自由生成、代码补丁、浏览轨迹、GUI 操作、文件产物还是多模态输入？
• 运行协议： 是否允许检索、浏览、代码执行、多次采样、反思、自一致性、工具调用或人工协助？
• 评分规则： exact match、accuracy、F1、pass@k、执行测试、规则检查、LLM judge、人类偏好还是专家 rubric？
• 版本管理： 数据版本、评分脚本版本、leaderboard 时间戳和变更记录是否公开？
• 统计报告： 是否提供置信区间、显著性检验、错误分析和样本级输出？

2.2 能力构念与外部效度

LLM benchmark 的根本难点在于，任务表现并不自动等同于目标能力。例如，数学选择题准确率并不等价于数学研究能力；HumanEval 的函数级代码生成不等价于真实软件维护；多轮对话偏好分数不等价于医疗或法律场景下的可靠性；长上下文“needle-in-a-haystack”检索不等价于深层文档理解。

因此，评估设计必须区分：

• 内部效度： 分数是否确实反映模型在该任务上的表现？
• 构念效度： 该任务是否真的测量了声称的能力？
• 外部效度： 该分数能否迁移到目标应用场景？
• 决策效度： 该分数是否足以支持模型发布、采购、部署或风险分级？

本文后续将用这些维度评估不同 benchmark 的适用边界。

3. 研究方法与资料来源

本文采用“文献综合 + 方法论归纳 + 二级元评估框架构建”的研究设计。资料来源包括：

1. 公开学术论文与预印本，重点覆盖 2021—2026 年间的 LLM 评估、benchmark construction、benchmark contamination、LLM-as-a-Judge 和 agent evaluation 工作；
2. 官方 benchmark 页面、开源评估库和排行榜说明；
3. 代表性基准的任务定义、评分协议和论文摘要；
4. 对 benchmark 质量进行系统评估的元评估工作，如 BetterBench、Benchmark²、Benchmark Health Index、BenchScope 与 How2Bench。^1011121314

本文不直接声称复现实验所有排行榜分数，也不将任何 2026 年 5 月之后可能变化的实时模型排名作为稳定证据。文中的“实验与分析”部分是面向基准选择和报告规范的方法论实验设计与二级分析框架，适用于研究团队或产品团队据此复现实证评估。

4. 相关工作与历史脉络

4.1 从 NLP 任务基准到基础模型整体评估

早期 NLP 评估以 GLUE、SuperGLUE、SQuAD、XNLI、WMT 等任务集合为代表，关注句子理解、推理、问答、翻译和分类等相对明确的任务。LLM 出现后，模型以提示方式直接处理多任务输入，传统“针对任务训练—在测试集评估”的范式逐渐转向“统一模型—多任务提示评估”。MMLU 将跨 57 个学科的多项选择题聚合为综合知识测试，成为 2021—2024 年最常用的通用能力基准之一。¹⁵

HELM 的贡献在于将“多指标、多场景、透明日志”作为基础模型评估的基本原则。它指出，在 HELM 之前，主流模型之间经常缺少共同评估场景，导致分数不可比；HELM 通过标准化场景和指标提高了横向比较能力。¹

4.2 从静态问答到高难度、动态和私有基准

随着模型能力进步，传统基准逐步饱和。MMLU-Pro、GPQA、HLE 和 BBEH 均是在这一背景下提出。GPQA 由生物、物理、化学领域专家编写，强调“Google-proof”属性，即即便允许熟练非专家使用网络搜索，问题仍难以回答。¹⁶ HLE 进一步构建跨学科专家级闭合答案问题，目标是为前沿模型保留足够 headroom。¹⁷

动态基准和私有 holdout 的重要性同时上升。LiveCodeBench 持续从竞赛平台收集新代码题，以降低训练污染风险。¹⁸ SimpleQA、BrowseComp 等则通过答案短、可验证的设计降低开放式评分的复杂性。¹⁹⁷

4.3 从模型评估到系统评估与代理评估

GAIA、OSWorld、τ-bench 和 BrowseComp 推动了从静态 benchmark 到语言智能体评估的转向。GAIA 任务需要推理、多模态处理、网页浏览和工具使用；OSWorld 将模型置于真实操作系统与桌面应用中；τ-bench 关注工具、用户模拟器与规则遵循；BrowseComp 则测试 browsing agent 在困难可验证问题上的持续搜索和信息整合能力。⁵⁶²⁰⁷

GDPval 将评估进一步转向真实经济任务，覆盖 44 个职业和美国 GDP 贡献较大的行业中的知识工作产物。该类基准的意义在于：它不再只问模型是否能答对题，而是问模型产物是否接近专业人员交付质量。⁸

4.4 从评模型到审基准

BetterBench、Benchmark²、BHI、BenchScope 和 How2Bench 共同表明，benchmark 本身也需要系统审计。BetterBench 以 46 项最佳实践评估 24 个 AI benchmark，指出常用基准在统计显著性报告和复现性方面存在明显不足。¹⁰ Benchmark² 提出 cross-benchmark ranking consistency、discriminability score 和 capability alignment deviation 等指标，用于衡量 benchmark 是否能稳定区分模型并与同类能力测量一致。¹¹ BHI 从 capability discrimination、anti-saturation 和 impact 三个维度衡量 benchmark 健康度。¹² BenchScope 使用 effective dimensionality 分析 benchmark suite 中实际独立信号数量，提示多分项排行榜可能存在高度冗余。¹³

5. LLM 评估基准分类体系

5.1 分类原则

本文按“能力构念 + 任务形态 + 评分方式 + 部署相关性”四个维度对基准分类。一个 benchmark 可以属于多个类别，例如 BrowseComp 同时属于事实性、浏览代理和真实世界检索；HealthBench 同时属于医疗、高风险、安全和 rubric-based 评估；OSWorld 同时属于多模态、GUI、代理和真实环境评估。

5.2 主类别总览

6. 代表性基准详解

6.1 综合知识与专家级问答

MMLU 与 MMLU-Redux

MMLU 包含跨 57 个学科的多项选择题，是 LLM 综合知识评估的历史锚点。其优势是覆盖广、易运行、易报告，缺点是选择题形式容易受选项偏置、提示模板和污染影响。MMLU-Redux 研究通过人工重标注 5,700 个问题估计原始 MMLU 中存在非忽略的题目错误，并指出这些错误会扰动模型性能解释。²¹

适用建议： MMLU 可用于历史对齐和粗粒度基线，但不宜单独用于 2026 年前沿模型排序；若使用，应优先报告 MMLU-Pro、MMLU-Redux 或其他清洗版本。

MMLU-Pro

MMLU-Pro 扩展了选择项数量，并移除部分琐碎或噪声问题。论文报告显示，模型在 MMLU-Pro 上相较 MMLU 出现明显准确率下降，且 prompt sensitivity 降低，说明其在 2024 年后更适合区分较强模型。²

适用建议： 用作综合知识与推理能力的默认新基线之一，但仍需配合 GPQA、HLE 或专业域基准避免单一分数幻觉。

GPQA

GPQA 包含 448 道由生物、物理、化学领域专家编写的研究生级多选题。其设计强调高质量、专家难度和“Google-proof”。¹⁶

适用建议： 适合衡量科学领域专家级知识和可监督困难问题，但样本量有限，使用时应报告子集、prompt、是否启用工具和置信区间。

Humanity's Last Exam

HLE 由跨领域专家构造，目标是保留前沿模型的测量 headroom。其题目覆盖数学、自然科学、人文社会科学、工程等领域，形式包括多选和短答案。¹⁷

适用建议： 适合评估前沿模型的专家级闭合问题能力。由于高难基准更容易出现答案争议和专家验证成本，应关注版本更新、bug bounty、公开/私有 split 和题目复核。

6.2 数学与形式推理

GSM8K 与 MATH

GSM8K 由 8.5K 小学数学文字题构成，推动了 chain-of-thought 和 verifier-based reasoning 研究。²² MATH 则包含 12,500 道竞赛数学问题和步骤解答，难度更高。²³

主要问题： 到 2026 年，GSM8K 已明显不适合作为前沿模型数学能力的单独度量；MATH 仍有价值，但也受到训练污染、提示策略和 test-time compute 影响。

AIME、FrontierMath 与形式证明

最新数学评估更倾向使用当年竞赛题、私有题库、形式化证明和可验证答案。FrontierMath 等高难数学基准通过专家构建和部分私有化设计降低污染风险；PutnamBench 等形式化基准则将自然语言问题转化为 Lean、Isabelle 或 Coq/Rocq 等证明环境，以获得严格可验证性。

适用建议： 数学评估必须报告推理预算，包括采样次数、自一致性、工具、搜索、证明器、代码执行和时间限制。对 reasoning model 尤其不能只报告 best-of-n 结果而不报告 n 和成本。

6.3 指令遵循、对话与偏好

IFEval

IFEval 通过可程序化验证的约束检查指令遵循能力，例如要求输出包含特定关键词、格式或长度。²⁴

优势： 比开放式偏好评估更可复现。
局限： 更擅长测量形式约束，不足以覆盖帮助性、深层理解和复杂意图。

MT-Bench 与 Chatbot Arena

MT-Bench 与 Chatbot Arena 使 LLM-as-a-Judge 和人类 pairwise preference 成为主流。相关论文指出，强 LLM judge 可在一定程度上接近人类偏好，但存在位置偏置、冗长偏置、自我增强偏置和有限推理能力。²⁵

适用建议： 对话偏好类基准适合作为用户体验代理指标，但必须报告 judge 设置，并对长度、位置和模型家族偏置做控制。

Arena-Hard-Auto 与 WildBench

Arena-Hard-Auto 和 WildBench 试图将真实用户或困难提示纳入自动偏好评估，使其更适合追踪前沿聊天模型的相对表现。²⁶²⁷

适用建议： 可作为开放式生成质量的筛选器，但不应代替目标场景人工评审。

6.4 事实性、幻觉与 grounding

TruthfulQA

TruthfulQA 通过诱导常见误信问题衡量模型是否会模仿训练数据中的虚假陈述。它是早期 truthfulness 评估的重要基准，但题量较小，且强模型可针对其模式优化。

SimpleQA

SimpleQA 评估短答案事实性，设计目标是问题具有唯一、无争议、易评分答案；评分分为 correct、incorrect 和 not attempted。该设计强调模型不仅要答对，还要在不确定时选择不答。¹⁹

适用建议： 适合度量短事实与拒答校准，但需要区分 closed-book 与 open-book 设置。

FACTS Grounding

FACTS Grounding 关注模型是否能严格基于给定长文档回答问题，而不引入外部或幻觉信息。该方向尤其适合 RAG、文档问答和企业知识库场景。

BrowseComp

BrowseComp 包含 1,266 个需要持续网页浏览、搜索策略和信息综合的困难问题，答案短且可验证。⁷

适用建议： 适合浏览代理和深度研究代理评估。必须报告搜索权限、浏览器实现、最大步数、工具调用次数和时间预算。

6.5 长上下文评估

LongBench 与 LongBench v2

LongBench 以双语、多任务方式测试长上下文理解；LongBench v2 更强调真实长文档和深层推理。²⁸²⁹

RULER 与 InfiniteBench

RULER 用可控合成任务测量长上下文模型在不同长度下的实际上下文利用能力。³⁰ InfiniteBench 将上下文扩展到 100K tokens 以上，用于极长文本能力评估。³¹

核心结论： 上下文窗口长度不是有效上下文能力。有效长上下文能力包括信息定位、跨段整合、冲突消解、全局推理、答案压缩和抗位置偏置。

6.6 代码与软件工程

HumanEval 与 MBPP

HumanEval 以函数级 Python 生成和 pass@k 指标成为代码基准经典。³² MBPP 则补充基础编程问题。二者优势是简单、可执行、历史比较清晰；缺点是函数级任务与真实软件工程存在距离。

LiveCodeBench

LiveCodeBench 持续收集 LeetCode、AtCoder、Codeforces 的新题，强调 contamination-free，并覆盖生成、修复、执行和输出预测等多种代码能力。¹⁸

SWE-bench 与 SWE-bench Verified

SWE-bench 由真实 GitHub issue 与 PR 构成，要求模型修改完整代码库以通过测试。³³ SWE-bench Verified 对任务进行人工验证，以降低噪声并提升可用性。

适用建议： 软件工程评估要报告仓库版本、依赖环境、测试命令、失败日志、超时策略、是否允许检索和是否允许多轮 patch。对 agent 型 coding system，还要报告 scaffold 和工具权限。

6.7 安全、高风险与医疗评估

HarmBench、SafetyBench 与 JailbreakBench

HarmBench 提供自动化红队和拒绝鲁棒性框架，SafetyBench 关注模型安全知识与风险判断，JailbreakBench 关注越狱攻击与防御鲁棒性。³⁴³⁵

HealthBench 与 HealthBench Professional

HealthBench 包含 5,000 个健康对话，由 262 名医生构造 rubric，覆盖准确性、指令遵循、沟通、安全等多个行为维度。³⁶ HealthBench Professional 则进一步聚焦真实临床工作中医生与模型的对话任务，并采用多医生 rubric 与专家响应作为对照。³⁷

适用建议： 医疗、法律、金融等高风险领域不应仅依赖自动 judge。应引入专家 rubric、错误严重度分级、区域指南差异说明和人工复核。

6.8 多语言、跨文化与区域性评估

英语中心 benchmark 无法代表全球部署场景。SEA-HELM 面向东南亚语言与文化提出整体评估框架，覆盖 NLP classics、LLM-specifics、SEA linguistics、SEA culture 和 safety 五大维度。³⁸ BrowseComp-ZH 则将浏览代理评估扩展到中文网络环境，并指出中文 web 生态中的语言、基础设施和信息检索复杂性会显著影响模型表现。³⁹

适用建议： 多语言评估不能简单翻译英文题库。应优先使用本地语料、本地专家、本地文化知识和本地 judge 校准。

6.9 真实经济任务与专业产物评估

GDPval 使用专业人士构造的真实工作任务和交付物来评估模型产出质量，覆盖 44 个职业与九个主要行业。⁸ 这类基准对企业部署和经济影响研究更有外部效度，但评分成本也更高，且往往包含部分私有任务。

适用建议： 专业工作评估应区分 one-shot 产物、迭代协作产物和人机协同产物；同时报告速度、成本、复核负担、专家偏好和错误严重度。

7. 元评估框架：如何评估 benchmark 本身

7.1 元评估维度

本文建议从九个维度审计一个 benchmark：

7.2 Benchmark²

Benchmark² 的核心思想是：benchmark 之间可以相互校验。若一个 benchmark 与同类 benchmark 的模型排序高度不一致，且无法用构念差异解释，则可能存在噪声、偏置或不稳定性。其三个指标分别关注跨基准排序一致性、区分能力和能力对齐偏差。¹¹

实践启示： 选择 benchmark bundle 时，不应只选热门基准，而应选构念互补、冗余较低、排序稳定且具备足够区分度的组合。

7.3 Benchmark Health Index

BHI 将 benchmark 健康度分解为 capability discrimination、anti-saturation 和 impact。¹² 这一定义强调 benchmark 的生命周期属性：一个基准可能曾经有效，但随着模型能力提升、训练数据泄露或研究社区过度优化，其健康度会下降。

实践启示： 组织应定期对内部 benchmark 做 health check，并设置退役、刷新或迁移机制。

7.4 BenchScope 与有效维度

BenchScope 使用 Effective Dimensionality 估计 benchmark suite 中实际独立测量信号数量。其结果提示，多个分项分数并不必然代表多个独立能力；某些排行榜的多个指标可能高度相关。¹³

实践启示： “更多基准”不等于“更全面评估”。若新增基准与已有基准高度冗余，评估成本上升但信息增量有限。

7.5 BetterBench 与 How2Bench

BetterBench 从 benchmark 生命周期出发，总结数据质量、统计显著性、透明性、复现性和可用性方面的常见缺陷。¹⁰ How2Bench 对代码相关 benchmark 提出 55 项 checklist，强调数据质量保证、开源、敏感信息处理、任务正确性和复现性。¹⁴

实践启示： benchmark construction 应具备类似软件工程的质量管理，包括 issue tracker、版本号、单元测试、数据审核、变更日志和弃用策略。

8. 评估方法论

8.1 自动硬指标

自动硬指标适合答案唯一或可程序化验证的任务。常见指标包括：

• Accuracy / Exact Match： 多选、短答案、分类任务；
• F1 / ROUGE / BLEU： 抽取式问答、摘要、翻译；
• Pass@k： 代码生成或数学多次采样；
• Execution success rate： 代码、GUI、工具调用任务；
• Rule-check score： IFEval 等约束遵循任务；
• Grounding score： 文档问答和 RAG 事实性任务；
• Task success rate： 代理任务最终状态是否达成。

自动指标的优势是成本低、复现性强、统计处理清晰。局限是难以衡量开放式生成中的帮助性、解释质量、微妙错误和用户满意度。

8.2 Pass@k 的解释

在代码和数学场景中，pass@k 常被用于衡量多次采样中至少一次成功的概率。若每题生成 n 个候选，其中 c 个正确，估计器常写为：

pass@k = 1 - C(n - c, k) / C(n, k)

该指标必须报告 n、k、温度、采样策略、去重策略和总计算成本。否则，高 pass@k 可能只是 test-time compute 增加的结果。

8.3 LLM-as-a-Judge

LLM-as-a-Judge 是开放式生成评估的重要方法。MT-Bench 论文显示，强 LLM judge 在一些对话偏好任务上可接近人类一致性水平，但同时存在位置、冗长和自我增强偏置。²⁵ 后续研究进一步系统分析 position bias，并指出不同 judge 和任务之间偏置差异显著。⁴⁰ PoLL 提出用多个较小且异构的模型组成 judge panel，以降低单一大模型 judge 的家族偏置和成本。⁴¹

稳健的 LLM-as-a-Judge 实践应包括：

1. 使用结构化 rubric，而不是模糊的“哪个更好”；
2. 对候选答案随机交换位置，测量 position consistency；
3. 控制长度，或使用 length-controlled 评估；
4. 使用多个异构 judge，并报告 judge 间一致性；
5. 对高分歧样本进行人工复核；
6. 报告 judge prompt、judge 模型版本、temperature 和采样次数；
7. 避免让模型直接优化固定 judge 而不做人类校准。

8.4 人类在环与专家评估

高风险领域和专业产物评估应使用人类在环（human-in-the-loop, HITL）。人类评估的关键不是简单投票，而是设计清晰的 rubric、训练标注者、测量一致性、处理争议并分层报告错误严重度。

推荐流程：

1. 由领域专家定义 rubric；
2. 抽样双标或三标；
3. 计算 Cohen's kappa、Krippendorff's alpha 或一致率；
4. 对严重错误、模型间差异边界样本和 judge 分歧样本复核；
5. 将人类标注结果用于校准自动 judge，而不是完全替代。

8.5 统计显著性与不确定性

LLM 评估报告应默认包含不确定性。至少应报告：

• 样本量 N；
• 均值、标准误和 95% 置信区间；
• 配对 bootstrap 或置换检验；
• effect size，而不只是 p 值；
• 多重比较校正；
• 模型输出随机性与 judge 随机性的分离；
• 错误类型分布与代表性案例。

小幅分数差异若没有置信区间和显著性检验，不应被解释为能力差异。

8.6 数据污染检测

数据污染检测可分为三类：

缓解策略包括：时间切分、动态采样、私有 holdout、canary string、题目重写、程序化生成、专家新题和输出日志审计。⁴⁴²

9. 实验与分析：面向 benchmark bundle 的元评估设计

9.1 实验目标

本节提出一个可复现的元评估设计，用于比较候选 benchmark bundle 的质量。目标不是给出某一组模型的固定排行榜，而是回答：

1. 哪些基准仍能区分强模型？
2. 哪些基准之间高度冗余？
3. 哪些基准对 prompt、judge 或工具设置最敏感？
4. 哪些基准对目标应用场景最有预测价值？

9.2 实验对象

建议选择三类模型系统：

• 基础聊天模型： 不启用工具；
• 推理增强模型： 启用高 reasoning effort 或多次采样；
• 代理系统： 启用浏览、代码执行、文件读写或 GUI 操作。

每类至少选 3—5 个模型或系统，以便评估 benchmark 的区分度和排序稳定性。

9.3 基准组合示例

9.4 分析指标

9.4.1 区分度

可用模型间方差与总方差之比衡量 benchmark 是否能区分模型：

Discriminability = Var_model(score) / Var_total(score)

更严谨的做法是使用混合效应模型，将模型、题目、采样和 judge 分别作为随机效应，估计模型效应占比。

9.4.2 饱和度

可定义 top-score headroom：

Headroom = 1 - max_model_score

对于非 0—1 量表，应先归一化。若 top-score headroom 过小且多数强模型置信区间重叠，则 benchmark 对前沿模型的排序价值有限。

9.4.3 排名稳定性

使用 Kendall τ 或 Spearman ρ 衡量不同 prompt、不同 judge 或不同随机种子下的模型排序一致性。

9.4.4 冗余度

计算 benchmark 分项之间的相关矩阵，并使用 effective dimensionality 或主成分分析估计独立测量信号数量。BenchScope 提供了该方向的参考思路。¹³

9.4.5 部署相关性

将 benchmark 任务与目标用例映射到同一任务属性空间，包括输入长度、工具权限、领域、输出形式、风险类型和质量标准。相似度越高，外部效度越强。

9.5 结果报告格式

推荐使用如下表格报告模型结果：

9.6 误差分析模板

错误分析应至少包括：

• 知识缺失： 不知道事实或概念；
• 推理错误： 中间推导错误、跳步、类比错误；
• 检索失败： 未找到证据、证据过时、检索策略失败；
• grounding 失败： 引入文档外信息或错引证据；
• 格式失败： 输出不符合约束或解析失败；
• 工具失败： API 参数错误、代码运行失败、GUI 操作错误；
• 安全失败： 有害输出、过度拒答、不当建议；
• 校准失败： 高置信错误或低置信正确；
• judge 失败： 评分器误判或与人类严重不一致。

10. 可复现评估协议

10.1 最低披露清单

10.2 评估 manifest 示例

run_id: llm-eval-2026-05-full-bundle-v1
model:
  name: example-model
  provider: example-provider
  version: 2026-05-01
  access: api
benchmark:
  name: SimpleQA
  version: 2024-11
  source_commit: abc123
  split: public
prompting:
  system_prompt_file: prompts/simpleqa/system.txt
  template_file: prompts/simpleqa/template.jinja
  few_shot: 0
sampling:
  temperature: 0.0
  top_p: 1.0
  max_tokens: 256
  seed: 42
tools:
  web_browsing: false
  code_execution: false
scoring:
  scorer: reference_exact_match_plus_judge
  judge_model: example-judge-2026-05
  judge_prompt_file: graders/simpleqa/rubric.txt
statistics:
  bootstrap_samples: 10000
  confidence_interval: 0.95
outputs:
  raw_generations: logs/raw.jsonl
  scored_outputs: logs/scored.jsonl
  summary: results/summary.csv

10.3 版本管理与数据治理

建议 benchmark 维护方提供：

• 语义化版本号，如 v1.2.0；
• 数据变更日志；
• 样本级 issue tracker；
• 被修复题目的 deprecated 标记；
• public/private/held-out split 说明；
• 数据许可与敏感信息审查；
• 可复现评分容器；
• leaderboard 提交规则；
• 反污染策略。

11. 不同应用场景的推荐评估组合

11.1 学术论文中的通用 LLM 比较

推荐组合：

• MMLU-Pro 或 GPQA：综合知识与科学推理；
• BBEH 或 HLE：高难推理与专家级问题；
• SimpleQA：事实性与校准；
• IFEval：指令遵循；
• LiveCodeBench：代码能力；
• LongBench v2 或 RULER：长上下文；
• HarmBench/SafetyBench：基础安全；
• 至少一个目标语言或目标领域基准。

不建议只报告 MMLU、GSM8K、HumanEval 和 MT-Bench 四项均分。

11.2 企业模型选型

推荐组合：

• 公开通用基准作为 sanity check；
• 企业内部真实任务集；
• RAG grounding 测试；
• 数据隐私和拒答测试；
• 长上下文与文件处理测试；
• 成本、延迟、吞吐量和失败恢复测试；
• 人类专家偏好和错误严重度评级。

企业评估的关键不是追求榜单分数，而是测量目标工作流中的端到端任务成功率。

11.3 编程与软件工程代理

推荐组合：

• LiveCodeBench：动态代码能力；
• SWE-bench 或其人工验证版本：真实 repo 修复；
• 内部代码库任务：目标域迁移；
• 安全测试：依赖漏洞、secret 泄露、恶意代码拒绝；
• 工具轨迹分析：patch 次数、测试次数、回滚次数、失败恢复。

11.4 医疗与健康场景

推荐组合：

• HealthBench / HealthBench Professional；
• 本地医学指南对齐测试；
• 专家人工复核；
• 不确定性与转诊建议评估；
• 危急情况识别；
• 低资源地区和跨文化场景测试。

医疗评估中，单纯“回答看起来专业”不是可靠证据。需要错误严重度和临床安全性审查。

11.5 浏览、研究与信息检索代理

推荐组合：

• BrowseComp；
• GAIA；
• FACTS Grounding；
• 内部 research task benchmark；
• 引用正确性、来源质量、时间敏感性和证据链完整性评估。

浏览代理评估必须记录网页访问轨迹、查询、来源、时间戳和最终答案证据。

11.6 多语言部署

推荐组合：

• 目标语言本地基准，如 C-Eval、CMMLU、SEA-HELM 或 BrowseComp-ZH；
• 多语言事实性与安全测试；
• 本地文化知识；
• 本地专家标注；
• judge 跨语言一致性校准。

翻译英文 benchmark 只能作为补充，不能替代本地化评估。

12. 常见失败模式与防控策略

12.1 分数幻觉

现象： 报告单一综合均分，但隐藏了 benchmark 差异、prompt 设置、样本量和置信区间。
防控： 分构念报告，提供 confidence interval、错误分析和原始配置。

12.2 榜单过拟合

现象： 模型或产品被持续调参以最大化某公开排行榜分数，但真实任务表现不提升。
防控： 使用私有 holdout、动态任务、内部真实任务和定期 benchmark refresh。

12.3 Judge 过拟合

现象： 生成器学会迎合固定 LLM judge，例如输出更长、更华丽或更符合 judge 偏好的文本。
防控： 多 judge、长度控制、人工复核和 judge drift 监控。

12.4 工具权限混淆

现象： 将启用浏览、代码执行或多次采样的系统结果与裸模型结果直接比较。
防控： 明确模型、系统、工具和推理预算边界。

12.5 题库污染

现象： 模型训练数据包含 benchmark 题目或答案，导致分数虚高。
防控： 时间切分、动态新题、私有集、近似重复检测和黑盒污染测试。

12.6 高风险场景的自动评估误用

现象： 医疗、法律、金融或安全场景只使用自动 judge，忽略专家审查。
防控： 专家 rubric、严重度分级、人工复核和本地法规/指南对齐。

13. 基准卡模板

建议每个 benchmark 发布时附带如下 benchmark card：

# Benchmark Card: <Name>

## 1. 基本信息
- 名称：
- 版本：
- 发布日期：
- 维护者：
- 许可证：
- 官方链接：

## 2. 构念说明
- 目标能力：
- 非目标能力：
- 适用模型类型：
- 不适用场景：

## 3. 数据说明
- 样本数量：
- 语言：
- 领域：
- 难度分布：
- 数据来源：
- 标注者资质：
- 质量控制：
- 已知偏差：

## 4. 运行协议
- 是否允许工具：
- 是否允许检索/浏览：
- prompt 模板：
- 采样参数：
- 最大推理时间：

## 5. 评分协议
- 指标：
- 自动评分脚本：
- judge 模型与 prompt：
- 人工评审流程：
- 置信区间计算：

## 6. 污染与版本管理
- 发布时间切分：
- 私有 split：
- canary 或污染检测：
- 版本变更记录：

## 7. 限制与风险
- 已知错误：
- 不能支持的结论：
- 高风险使用说明：

14. 工具链与工程实践

工程实践建议：

1. 评估即代码。 所有评估配置、prompt、脚本、依赖和日志进入版本控制。
2. 分离生成与评分。 先冻结模型输出，再运行评分器，避免重试选择性报告。
3. 保留样本级结果。 只保留 aggregate score 无法支持误差分析。
4. 持续评估。 新模型、新 prompt、新工具、新数据更新均触发 regression eval。
5. 红队和蓝队并行。 能力评估和风险评估同时运行，避免只优化帮助性。

15. 讨论

15.1 为什么“更难”不总是“更好”

高难 benchmark 可以延长生命周期，但若题目远离真实应用，或题目答案本身争议较大，则外部效度可能下降。HLE、FrontierMath 等高难基准适合测量专家级上限能力，但企业部署仍需要内部真实任务和端到端工作流评估。

15.2 为什么“真实任务”不总是“可复现”

OSWorld、BrowseComp、GDPval 等更接近现实，但环境复杂、时间敏感、成本高。真实网页会变化，GUI 环境会漂移，专业产物评分需要专家。解决方向不是退回静态选择题，而是更严格地记录环境、轨迹、时间戳、版本和评分过程。

15.3 为什么“自动评估”不能完全替代人类

自动评估在规模和速度上不可替代，尤其适合 regression testing。但 LLM judge 的偏置、黑箱性和可被优化性决定了其必须接受人类校准。越是高风险、开放式、价值判断密集的任务，越需要专家参与。

15.4 为什么多语言评估是核心问题而非附加项

LLM 部署是全球性的。英语 benchmark 的高分不能推出模型在中文、阿拉伯语、印地语、东南亚语言或非洲语境中同样可靠。语言差异不仅是翻译差异，还包括事实来源、文化规范、法律制度、礼貌策略、风险表达和 judge 偏好差异。

15.5 评估与治理的关系

Benchmark 不只是研究工具，也会影响商业发布、政策监管、采购决策和公众信任。如果 benchmark 质量低、不可复现或被选择性报告，可能导致错误部署。反之，高质量评估协议能为模型卡、系统卡、风险分级和外部审计提供可验证证据。

16. 结论

截至 2026 年 5 月，LLM 评估已进入“评模型”与“审基准”并重的新阶段。经典静态基准仍有历史价值，但不足以单独支撑前沿模型比较。高质量评估体系必须具备以下特征：

1. 多构念覆盖： 同时评估知识、推理、事实性、长上下文、代码、工具、偏好、安全和目标领域；
2. 动态与抗污染： 采用时间切分、私有 holdout、动态新题和污染检测；
3. 可审计与可复现： 公开 prompt、模型版本、数据版本、评分脚本和日志；
4. 统计稳健： 报告置信区间、显著性检验和错误分析；
5. 自动与人工结合： 使用 LLM judge 作为高吞吐工具，但以人类和专家校准；
6. 场景相关： 将 benchmark 与实际部署任务、风险和成本联系起来；
7. 生命周期管理： 定期评估 benchmark 健康度，退役饱和或污染基准。

本文的最终建议可以概括为：不要只报告分数；要报告分数如何产生、它测量什么、不测量什么、误差有多大、是否可复现，以及它为何能支持当前决策。

附录 A：推荐基准选择矩阵

附录 B：评估报告结构模板

# Evaluation Report: <Model/System> on <Benchmark Bundle>

## 1. Executive Summary
- 主要结论：
- 适用范围：
- 不支持的结论：

## 2. Model/System Description
- 模型版本：
- 工具与 scaffold：
- 训练截止/知识截止声明：

## 3. Benchmark Bundle
- 基准选择理由：
- 构念覆盖：
- 已知局限：

## 4. Protocol
- Prompt：
- Sampling：
- Tools：
- Runtime：
- Scoring：

## 5. Results
- 分项结果：
- 置信区间：
- 显著性：
- 成本与延迟：

## 6. Error Analysis
- 错误 taxonomy：
- 典型案例：
- 严重度：

## 7. Robustness and Sensitivity
- Prompt sensitivity：
- Judge sensitivity：
- Tool sensitivity：
- Random seed sensitivity：

## 8. Risk Assessment
- 安全失败：
- 过度拒答：
- 高风险领域问题：

## 9. Reproducibility Package
- 数据版本：
- 代码版本：
- 日志位置：
- 不公开原因：

## 10. Conclusion
- 可部署建议：
- 需要补充评估：

附录 C：术语表

参考文献