大语言模型评测指南

模型评测是什么？

在探索大语言模型（LLM）的世界时——无论你是在训练或微调自己的模型、为应用程序选型，还是试图了解该领域的现状——你很可能都曾遇到过这样一个问题：

如何判断一个模型是否足够好？

答案是（对于这个博客主题来说，出乎意料地简单）——评测！它无处不在：对模型进行排名的排行榜、声称能衡量推理能力、知识储备、编程能力或数学性能的 benchmark（基准测试）、宣布最新最优结果的论文……

但评测究竟是什么？它能真正告诉我们什么？

本指南旨在帮助你全面理解这一切：评测能做什么、不能做什么，何时信任不同的评测方法（以及它们各自的局限性和偏差），如何在评测模型时选择 benchmark（2025 年哪些 benchmark 仍然相关），以及如果你有意愿，如何设计自己的评测体系。

在整个指南中，我们还将重点介绍常见的陷阱、来自 Open Evals 团队的技巧与经验，并帮助你学会如何批判性地看待评测结果所做出的各种声明。

在深入细节之前，让我们先快速了解一下人们进行评测的原因——因为你的身份和工作内容，将决定你需要使用哪种评测方式。

模型构建者视角：我正在构建一个强大的模型吗？

如果你是一名正在创建新模型的研究员或工程师，你的目标很可能是构建一个在一系列任务上表现出色的强大模型。对于基础模型（从头开始训练），你希望模型在各种通用任务上表现良好，涵盖多样化的能力。如果你是在对某个基础模型进行后训练以适配特定用例，你可能更关注该特定任务上的性能。无论哪种情况，衡量性能的方式都是通过评测。

在尝试不同架构、数据配比和训练方案的过程中，你需要确保你的改动（选择不同的训练数据、架构、参数等）没有”破坏”该规模模型应有的预期性能，甚至能有所提升。测试不同设计选择影响的方式是通过消融实验（ablations）：消融实验是指在特定配置下训练模型、在所选任务集上进行评测，并将结果与基线模型进行比较的实验。 因此，评测任务的选择对消融实验至关重要，因为它们决定了你在构建模型过程中将优化的方向。

对于基础模型，通常会选用其他模型构建者使用的标准 benchmark 任务（想想那些每次新模型发布时都会报告的经典 benchmark 列表——我们稍后会介绍）。对于特定用例，如果已有现成的评测任务，可以直接使用——但如果它们不够”标准”，你可能需要仔细审查；或者你也可以自己设计（下文将详细讨论）。由于你可能需要运行大量消融实验，你希望评测任务能提供足够强的信号（而不只是无意义的噪声结果），同时运行成本低、速度快，以便快速迭代。 通过消融实验，我们还可以利用 scaling laws（规模定律）根据小模型的性能来预测大模型的性能。

除了用于实验的消融实验，你可能还需要在模型训练过程中对中间 checkpoint（检查点）进行评测，以确保模型在各项任务上正常学习并持续提升，不会因为训练抖动或其他问题而出现性能回退。最后，你需要对最终 checkpoint 进行评测，以便在发布时宣布你的模型是 SOTA（state-of-the-art，当前最优）。

（你仍然可以声称自己是 SOTA，只是请记住这个注意事项。）

模型使用者视角：哪个模型在<任务>上最好？

你想将别人训练好的模型用于你的特定用例，无需额外训练；或者你计划进行额外训练，并希望找到最好的现有模型作为基础。

对于数学、代码或知识等常见领域，很可能已经有多个排行榜使用不同数据集对模型进行比较和排名，你通常只需测试排名靠前的几个候选模型，找到最适合你的那个（如果排名最高的模型都不能满足你的需求，下一名的模型也不太可能奏效）。

你可能希望自己运行评测和比较（通过复用现有 benchmark），以获取关于模型成功与失败的更多细节分析，这将在下文介绍。

与模型构建者在特定能力上不断迭代类似，对于较为小众的主题，你可能需要考虑设计自己的评测体系，这将在我们的最后一节中详细介绍。

理解评测所需的LLM基础知识

既然你已经了解了评测对不同人群为何如此重要，接下来让我们看看如何对模型进行提示（prompt）以获取答案，进而对其进行评测。如果你已经有过评测经验，可以略读本节，重点关注注释和旁注部分。

在本节中，我们将了解模型处理的两个步骤：如何对输入进行预处理后送入模型（tokenization，分词），以及模型如何据此生成预测（inference，推理）。

分词（Tokenization）

输入文本（在推理时称为 prompt，即提示词）首先被切分为 tokens（词元），即文本的最小单元（可以是一个或多个字符，最大到词级别），每个词元对应一个编号。一个模型能够解析的全部词元集合称为其 vocabulary（词汇表）。

分词基础：为何以及如何对文本进行分词？

由于大语言模型本质上是一个大型数学函数，它处理的是数字，而非文本。

假设你想把一个句子转换成数字，首先需要决定如何将句子切割成小片段，再将每个小片段映射到一个数字，这就是 tokenization（分词）。

过去，人们会尝试将文本中的每个字符映射为其在字母表中的索引（a -> 1，b -> 2，以此类推），这被称为 character based tokenization（基于字符的分词，即按字符切分）。另一个极端是将每个单词映射为其在词典中的索引（a -> 1，aardvark -> 2，ab -> 3，以此类推），这被称为 word based tokenization（基于词的分词，即按空格切分——如果该语言没有空格，则会更复杂一些）。

这两种方法都有一个共同的局限：会丢失输入文本中的信息。它们会抹去从词形中可以看出的语义关联（例如：dis similar、similar、similar ity、similar ly），而这些正是我们希望模型保留的信息，以便它能将相关词语联系起来。（此外，如果突然出现一个全新的词语，它将没有对应的编号，模型就无法处理 😔）

因此，一些人产生了将词切分为子词（sub-words）并为这些子词分配索引的想法（如 dis、similar、ity、ly）！

这最初是通过形态句法规则（morpho-syntax，即词语构成的语法）来实现的。现在大多数人使用 byte pair encoding（BPE，字节对编码），这是一种根据参考文本中的频率自动创建子词的智能统计方法。

综上所述：分词是一种将文本最小单元（可以是一个或多个字符，最大到词级别）映射为数字（类似于索引）的方式。处理文本时，输入文本（在推理时称为 prompt）由分词器（tokenizer）切分为这些 tokens（词元）。一个模型或分词器能够解析的全部词元集合称为其 vocabulary（词汇表）。

构建一个分词器需要做出的选择比人们预期的要多。例如，对于数字的分词，不能直接使用基本的 BPE，但你是只索引 0 到 9 并假设所有其他数字都是数字的组合，还是要单独存储直到十亿的数字？

目前已知的模型在这方面展示了一系列不同方法，但尚不清楚哪种方法更有利于数学推理。这会影响某些数学评测（这也是为何几乎没有评测是纯算术的原因）。

分词如何干扰你的评测

管理微调模型、系统提示词和对话模板（chat templates）

2022 年以前，模型通常只是预训练模型：文本输入，文本输出，仅此而已。此后，2023 年出现了指令微调（instruction tuning）和对话模型，2025 年又出现了推理模型。这意味着我们从使用纯文本逐渐转向使用越来越多的格式化内容。

这意味着，如果你不注意以下几点，许多模型的表现将会很差：

1. 遵守模型期望的格式
2. 如果模型需要，在推理开始时添加系统提示词（system prompt）
3. 在处理推理模型的答案之前，去除其中的思考过程（通常可以用正则表达式去除 <think> 标签之间的内容）

⚡

关键：对话模板与分词

不同的分词器在处理空格和特殊词元时行为不同。请参阅这个可视化示例，了解空格、分词和模板如何相互影响。切勿假设所有分词器的行为完全一致！

注意句首和句尾词元

某些预训练模型，如 Gemma 系列，对推理时是否包含句首词元（start of sentence tokens）非常敏感。你可能需要做一些实验来检验这一情况，并在评测时手动添加这些词元（如果数据集中没有的话）。

你也可能遇到这样的问题：模型不会像预期那样在句尾词元处停止生成。代码模型通常将 \n\t 作为单个词元进行训练。这意味着在生成文本时，它们往往会一步生成 \n\t。如果某个任务将 \n 定义为句尾词元（即停止生成的信号），那么当模型预测出 \n\t 作为一个词元时，生成不会停止，因为它与单独的 \n 并不相同。但实际上你仍然希望模型停止。在这种情况下，你需要更新句尾词元，或者定义一种机制，回溯最新词元的字符表示，以便事后停止（并截断）生成。

多语言与分词

在研究多语言评测时，你会遇到两个问题。

首先，由于某些语言并不总是用空格作为词的分隔符（如韩语、泰语、日语、中文等），它们需要特定语言的分词器才能被正确切分，否则会影响其在 BLEU、F1 分数等指标上的得分。

其次，分词器通常对非英语语言不够公平。在训练 BPE 分词器时，你会使用来自不同语言的数据，但大多数情况下，这些数据在语言间是不平衡的（例如，英语数据量比泰语或缅甸语多一个数量级甚至更多）。由于 BPE 分词器根据出现最频繁的词来创建词汇表词元，大多数长词元都会是英语单词，而来自频率较低的语言的词语大多只能在字符级别进行切分。这种效应导致了多语言分词的不公平：某些（频率较低或”低资源”的）语言需要比英语多出数个数量级的词元，才能生成等长的句子。

如果你遇到这种情况，模型在评测中允许生成的词元数量也应该因语言而异，因为不同语言分词所需的词元数量并不相同。

推理（Inference）

了解了如何将输入文本转换为 LLM 能够解析的形式之后，让我们来看看模型如何处理这些文本。

从输入文本出发，LLM 会在整个词汇表上生成下一个最可能词元的概率分布。为了获得连续的生成结果，我们可以选取概率最高的词元（再加上一些随机性以获得更有趣的输出）作为下一个词元，然后重复这一过程，将新词元追加到提示词末尾，如此循环往复。

对数似然评测（Log-likelihood evaluations）

对数似然评测的目标是获取给定提示词时，一个或多个选项的条件概率——换句话说，给定输入后得到特定续写内容的可能性是多少？

具体步骤如下：

• 将每个选项与提示词拼接，传入 LLM，模型会根据前面的词元输出每个词元的 logits（未归一化概率）
• 只保留最后的 logits（对应选项词元），并应用 log softmax，得到对数概率（范围为 [-inf, 0]，而非 [0-1]）
• 将所有单个词元的对数概率求和，得到整体选项的对数概率
• 最终可以根据选项长度进行归一化

这使我们可以应用以下指标之一：

• 在多个选项中获取模型的偏好答案，如上图所示。（但这可能会使某些模型的得分虚高，因为这些模型在自由生成时可能会生成其他内容，例如上图中的 Zygote。）
• 测试单个选项的概率是否高于 0.5
• 研究模型校准（calibration）。一个良好校准的模型，其正确答案具有最高的概率。

生成式评测（Generative evaluations）

在生成式评测中，我们希望获取模型根据输入提示词生成的文本。

生成过程以自回归（auto-regressive）方式进行：将提示词传入模型，查看最可能的下一个词元，将其选定为模型”第一个生成词元”，然后重复这一过程，直到满足生成结束条件（最大长度、触发停止生成的特殊词元等）。模型生成的所有词元共同构成其对提示词的回答。

随后，我们可以将生成内容与参考答案进行比较，评分两者之间的差距（可以使用简单指标如精确匹配（exact match），更复杂的指标如 BLEU，或以模型作为评判者（models as judges））。

使用现有 benchmark（基准测试）进行评测

现在你已经（重新）熟悉了 tokenization（分词）和推理（inference）工作原理的必备基础，以及评测过程中的注意事项，让我们来看看实际的 benchmark（基准测试）！我们将首先简要介绍2025年的评测现状，然后讨论在 benchmark 中应重点关注的内容，以及为什么你可能无法复现公告中的分数。最后，我们将结合 FineWeb 团队的经验，介绍如何在模型训练中选择合适的 benchmark。

2025年值得关注的 benchmark

你可以单独评测特定能力——这在训练阶段或比较基础/预训练模型时通常非常有价值。（但是，如果你用以下评测来选择并验证训练方法，再在最终模型上汇报这些指标，结果会略有偏差，因为你的训练方法已经面向这些评测进行过优化。）

推理与常识

推理与常识数据集通常是”历史遗留”数据集，诞生于 BERT 和 embedding 模型时代，早于 LLM 的兴起。这些数据集在当时颇具挑战性（尤其是因为它们往往针对当时的模型进行了对抗性构建），但如今 1) 已过于简单 2) 已被污染/饱和，仅适合用于消融实验或预训练评测。大型数据集有时也包含错误或低质量问题，因为它们往往通过 Amazon Mechanical Turk 大规模快速构建以控制成本（而现在通常用 LLM 生成评测问题）。

ARC（2018）（注意与 ARC-AGI 区分）是一个基于人类测试题构建的小学科学多选题（MCQA）数据集，选项经过对抗性筛选以规避当时的词共现系统。它有多个子集，较高质量的 challenge 子集至今仍用于预训练评测。WinoGrande（2019）是一个众包（机械土耳其 + 验证）的代词消解/填空数据集，利用对抗性问题对来迷惑模型。这两个数据集在 2022 至 2023 年之前对模型都颇具挑战。

许多历史数据集专门考察需要某种常识理解与接地（grounding）的推理能力。HellaSwag（2019）要求 LLM 从一组对抗性选项中选出正确的下一句话，文本来源于 ActivityNet 的字幕和 Wikihow 的教程。（它是 Swag 数据集的续作。）由于大多数句子来自教程或活动描述，解题往往需要物理常识接地能力。同样地，CommonsenseQA（2018）是基于 ConceptNet 构建的常识多选题数据集——标注者提问，并用概念上相近的干扰项作为选项。PIQA（2019）专门考察物理常识问题（样本来自 Instructables.com，干扰项通过语义扰动或改写生成）。OpenBookQA（2018）提供开放书籍事实来辅助回答多选题——但这些问题同样需要隐含的常识知识。

一个较新颖的推理数据集是 Zebra Logic，它使用逻辑谜题来测试模型的推理能力。其方法支持无限生成谜题，因此污染程度极低。

知识

知识评测的主要数据集一直是 MMLU（2020）。它已达到饱和/污染状态，经过深入审查后发现了若干问题：涉及缺失文档的不完整问题、错误的标准答案、模糊的问题，以及话题选择上明显的美国中心主义倾向。因此，它在 MMLU-Redux（2024）中被清洗，在 MMLU-Pro（2024，目前社区使用的主要替代版本）中被扩展为更复杂的问题和更多答案，并在 Global-MMLU（2024）中被翻译并标注了文化偏见。这些数据集主要用于预训练评测和消融实验。

对于后训练评测，人们关注更难的高质量知识数据集。GPQA（2023）包含生物/化学/物理领域的定制博士级问题，设计目标是让相关领域的博士生能够解答，而其他人则难以作答。最常用的子集是 diamond，但自 2023 年发布以来，它也开始出现污染迹象。

最后，名称宏大但质量极高的 Humanity’s Last Exam（2024）包含 2500 道由各领域专家众包提交的跨领域问题。该数据集大部分为私有内容，问题既需要复杂知识也需要推理能力。目前尚未被攻克，我个人认为这是一个很酷的数据集。唯一的问题是，由于无法快速获得模型评分，人们现在通过 LLM 评判来评估模型答案，而非与标准答案对比，因此在实践中你会得到难以比较的结果。

然而，尽管几年前测试模型原始潜在知识质量是非常有意义的（在训练时用于检验模型质量仍然有价值，例如预训练阶段用 MMLU-Pro，后训练阶段用 GPQA/HLE），我认为未来几年我们将逐渐淡出此类 benchmark（基准测试），原因有二。

1. 它们对人类而言越来越难以理解：问题变得如此复杂，非专家几乎无法理解每道题的表现意味着什么（也无法确保数据集本身不含错误）
2. 如今模型已连接工具（如互联网访问），潜在知识评测越来越变成了网络搜索与检索评测，其意义因此打了折扣。简而言之，我们正从闭卷考试转向开卷考试。类比法国学校体系：高中阶段是闭卷考试，但进入大学后，通常假定你可以访问数据库、互联网，评分更多关注给定信息下的推理能力，而非死记硬背。我相信随着模型能力的提升，LLM 评测也会经历同样的转变。

数学

数学评测数据集除了显然用于检验模型是否能解决数学问题之外，也被用作推理和逻辑能力的代理指标。

两个参考数学评测数据集是 GSM8K（2021）（包含小学数学题）和 MATH（2021）（汇编自网络上的奥数题），两者在近年来均已达到饱和/污染状态。前者被 GSM1K（2024）扩展，后者提供 1000 道新题以检验哪些模型在原版上存在污染；GSM-Plus 对题目进行了对抗性改写（添加干扰项、数值变换等）；GSM-Symbolic（2024）较少使用，但将 GSM8K 改写为问题模板，从而防止污染：问题可以无限再生。

社区目前主要关注：

• MATH 的后续版本，包括 MATH-500（从 500 道有代表性的问题中采样以避免过拟合）和 MATH-Hard（仅保留最难的 500 题）
• AIME（24、25），美国高中数学奥林匹克竞赛数据集，发布时直接使用。这些数据集的有趣之处在于，由于每年题目难度相当但内容不同，可通过比较发布时与前一年数据集上的成绩来检验污染情况
• Math-Arena，汇编自各类竞赛和奥数，定期更新（包含 AIME25 及其他众多竞赛！）

这些数据集实际上大多已不再”那么难”，因为它们止步于小学水平（即便 GSM-Symbolic 允许生成递归层级更多的问题，使其合成难度更高）。在难度谱的另一端，FrontierMath（2024）尝试提供难度大幅提升的数学题，由数学家专门为此撰写。该数据集理论上是私有的（但 OpenAI 似乎已获取了部分数据——实属遗憾）。Humanity’s Last Exam（2025）（在知识部分已介绍）也包含需要复杂推理的”专为评测而设”数学题（尤其是一些定理证明类题目）。

我个人会在预训练评测中使用 AIME25 和 MATH-500，在后训练评测中使用 Math-Arena。

代码

由于 agent（智能体）需要与工具交互，它们需要编程能力——无论是直接调用工具（代码 agent），还是在出现问题时理解如何调试工具输出（代码 agent 和 json agent 均需，两者区别见此处）。代码评测集也是推理能力的良好代理指标。

2021 年的历史编程评测集包括：MBPP（1000 道众包 Python 入门编程题）、APPS（10000 道来自编程面试和分享网站的代码生成题），以及随 Codex 模型一同发布的 HumanEval——与前两者不同，它是”专为发布而设计”的题目，当时非常创新！它还附带了沙箱环境以避免在评测机器上执行危险代码。（该论文还引入了 pass@k 的估算方法，此前是通过字面检查某次评测是否在 n 次中成功超过 k 次来计算的。）

EvalPlus（2023）团队制作了 HumanEval+ 和 MBPP+，通过增加更多测试用例、修复原始数据集中的 bug 并添加更多输入来扩展前述数据集。EvoEval（2024）也通过语义改写问题并添加难度标签，对 HumanEval 进行了变体扩展。

对于最终模型，你可能需要更难或未被污染的题目。

LiveCodeBench（2024）采用类似的”从 LeetCode 类网站抓取”方法，但非常有价值，因为它存储了问题创建日期，可以比较模型在训练结束前后所创建问题上的表现。这是一个出色的无污染 benchmark（基准测试），期待其更新！

AiderBench（大约 2024 年底上线）同样使用现有编程网站的数据（具体来自 Exercism），但超越了单纯的问题求解，专门测试代码编辑和重构能力。

对于后训练，需要更全面的评测，部分 benchmark（基准测试）已超越单独问题评测——因为单独问题并不能评估复杂编程能力。RepoBench（2023）测试 Python 或 Java 的仓库级自动补全系统，以 GitHub 代码为数据来源。它通过随机遮蔽代码库中的行并要求补全（跨文件或文件内函数）来构建，并定义了多个测试层级（检索、补全、组合）。

SweBench（2024）是该方向更为知名和完整的版本，同样使用 GitHub，但这次测试模型能否解决现有 issue，涉及逻辑理解、跨文件编辑与执行、长上下文推理等能力。

CodeClash（2025）是竞技场形式的代码评测，模型编写相互竞争的代码，并进行编辑和迭代。

目前，我推荐关注 LiveCodeBench、AiderBench 和 SWE-Bench 的高质量子集（SWE-Bench verified），并阅读 METR 报告以了解代码助手的实际使用价值。

长上下文

要在长时间对话中正确与用户互动而不丢失上下文，需要良好的长上下文管理能力。（想想三年前模型的最大上下文长度还是 2048 个 token（分词单元），而现在已普遍达到 128K 甚至更长，颇为有趣。）

2023 年开始测试这一能力的评测可能是 NIAH（Needle in a Haystack，大海捞针），即在一段长篇无关文本中嵌入一个随机事实，要求模型将其检索出来。它提供了一个整洁的框架，用于评估模型最容易在上下文中的哪个位置、从哪个上下文长度开始遗忘信息。2023 年模型在该测试上表现很差，2025 年已接近解决。

此后出现了更复杂的长上下文扩展评测。RULER（2024）增加了多跳追踪（要求模型跟随变量链条以获取正确值）、词频变化，并增加了 NIAH 的问答变体。目前也接近解决。Michelangelo（2024，有时也称为 MRCR，即多轮共指消解）同样使用合成长上下文数据：任务（长度各异）测试模型能否精确复现上下文中的唯一片段（以及识别相关信息是否存在），并理解对文本的一系列修改操作。后续在 OpenAI MRCR（2025）中进行了扩展。InfinityBench（2024）是多语言版本（英文和中文），提供 10 万 token 的合成数据任务，涵盖多种目标（问答、NIAH 式检索、超长上下文计算……）。InfinityBench 目前仍具有一定区分度。

HELMET（2024）整合了任务和现有 benchmark（基准测试），构建成一个更大的单一数据集以提供更多信号：包括 RAG 和问答数据集（Natural Questions、TriviaQA、PopQA、HotpotQA、Narrative QA 和 InfinityBench）、召回（RULER 和 JSONKV）、带引用的生成（ALCE 子集）、摘要、段落重排（MS MARCO）、上下文学习（TREC、NLU、Banking77、CLINIC150）。Benchmark 聚合虽然全面，但存在重复测量的风险：例如，不要同时针对 HELMET 和 InfinityBench 进行测试后聚合结果，因为这样会重复运行相同的评测！在 2025 年，HELMET 仍具有足够的区分力来比较模型。

我个人最喜欢的长上下文评测创意是 Novel Challenge（2024）——1000 道关于近一年出版的虚构书籍的判断题（由书的读者提交！），需要阅读并理解完整文本才能正确作答；以及 Kalamang 翻译数据集（2024）——模型需要通过阅读一本语法书，正确地将英语翻译成卡拉芒语（Kalamang 是资源极度匮乏的语言，几乎没有任何网络存在，仅有约 200 名母语者）。Kalamang 翻译集还可以扩展到其他低资源语言（如果能引入基于规则的语法检查器来测试生成有效性，从而获得严格的准确率而非依赖 BLEU，那就更棒了……）。

指令遵循

两个主要的指令遵循数据集是 IFEval（2023）及其扩展版 IFBench（2025）。IFEval 在我看来是近年来最聪明的评测创意之一：模型被要求遵循格式化指令（关于关键词、标点、词数/句数、文件类型格式如 markdown 或 html 等）。每项条件都可以通过特定解析测试来验证：这意味着该评测是少数几个无需依赖模型评判即可获得严格分数的自由生成评测之一。

更广泛地说，它属于功能正确性/单元测试评测类型，这是我个人最喜欢的模型评测方式。它也非常容易重新生成或扩展以防止污染。

顺便一提，一些 benchmark（基准测试）还测试”不遵循指令”（不合规）：CoCoNot（2024）专门测试模型对不完整（规格不明确/不清晰）、无法回答（因信息缺失或 AI 拟人化，通常会触发幻觉）或不安全请求的响应方式。它通过人工撰写查询、模型生成不合规请求，再经过过滤，构建成一个分类问题形式的评测集。

工具调用

工具的出现是 LLM 开始迈入 agentic（智能体化）领域的重要特征之一。

TauBench（2024）评测模型在零售和航空领域（订单/预订/查找产品等）回答用户查询的能力。数据库通过合成样本模拟真实领域数据，当 1) 模型的操作正确更新了数据库且 2) 模型给出了适当的用户回复时，认为模型回答正确。为使该 benchmark（基准测试）自动化运行，用户由 LLM 模拟，这使得评测成本较高且容易出错。尽管如此，它仍被广泛使用，尤其因为它很好地反映了真实使用场景。

ToolBench（2023）要求调用 API（OpenWeather、Cat、HomeSearch、TripBooking、GoogleSheets、WebShop、Tabletop 等）来解决 100 个测试案例，每个案例需要 1 到 10 次工具调用。部分 API 是模拟的，部分是真实的，使得数据集容易出现意外失败。因此在 StableToolBench（2025）中进行了修复和扩展，引入了通用 VirtualAPIServer 对所有 API 进行模拟以确保评测稳定性，但评测依赖 LLM 评判，引入了额外的偏差层。

BFCL（2025，但实际上这个 benchmark（基准测试）已有数年历史）在过去一年间发展显著，当前版本包含 4 个子集：单轮（简单工具调用）、来自用户的众包真实函数调用、多轮对话（测试长上下文和带工具调用的查询回答中的准确率）以及 agentic（网络搜索、记忆、SQL 数据交互）。它综合使用抽象语法树（Abstract Syntax Trees）、执行响应和状态匹配（最终状态是否符合预期）来评估调用是否正确。人们主要关注 v3 来专门测试工具调用，v4 测试网络和搜索工具使用。

最后，随着 MCP（模型上下文协议）的出现，一些 benchmark（基准测试）应运而生以测试面向 MCP 的工具调用——但大多依赖模型评判，且使用真实 API，这可能因网络问题引入潜在失败案例/缺乏可重复性（由于大多数 MCP 涵盖的用户群足够大，对网站造成的额外负载似乎不是太大问题）。

MCPBench（2025）将 LLM 连接到实时的真实 MCP 服务器（Wikipedia、HF、Reddit、Steam、arxiv 等），任务需要多轮交互才能解决（通过合成方式创建）。评测结合了基于规则的工具调用有效性和成功率检查，以及 LLM 评判来评估查询是否被适当回答。

MCP-Universe（2025）使用 11 个涵盖各类真实世界主题的 MCP 服务器（现实导航、3D 设计、网络搜索等）。该评测的亮点在于评估依赖多个严格评测器：一个用于格式正确性，两个用于答案正确性。由于任务可以是静态的（询问不会变化的事物）或动态的（GitHub 仓库星数、天气等），对于后者，答案正确性采用依赖任务的基于执行的评测框架，自动从相关来源获取最新正确答案并与模型输出进行比较。这比依赖 LLM 评判要精准得多！

LiveMCPBench（2025）提供了一个大型可本地部署的 MCP 服务器集合，测试模型在完成任务时区分工具的能力。最佳模型已达到 80% 左右——接近饱和。不过，测试模型能否在超长列表中选择合适工具是一个很好的用例，随着网络向 MCP 迁移，这一能力将越来越重要。

（顺带一提，这里有一篇关于如何为 agent 编写优质工具的酷炫文档。）

虽然测试单项能力提供了有价值的信号，但现实世界中助手的表现取决于这些能力如何协同发挥。一个模型可能在推理上表现出色，但当推理必须同时与工具调用和长上下文管理整合时可能会失败，因此我们需要能够测试多种能力协同编排的评测。

助手任务

我相信助手任务将成为下一级评测的主要方式之一：解决这些任务需要综合多种能力（长上下文、推理、工具调用……），同时 benchmark（基准测试）本身在有用的真实场景中提供了特定领域表现的洞察。这类评测对大众而言也往往比单项能力 benchmark（基准测试）更易理解。如果 benchmark（基准测试）足够通用，它们不会检查使用了哪些具体工具，而是检查最终结果是否正确，因为复杂任务通常有多种解决路径。

真实信息检索

GAIA（2023）通过要求模型综合运用工具、推理和检索来解决真实查询（有时包括文档），开创了现代 agentic 评测先河。问题分为 3 个难度级别，第一级现已饱和，第三级对模型而言仍然困难。这也是一个你会发现数字分散的 benchmark（基准测试），因为人们要么在公开验证集上报告成绩，要么使用 LLM 评判来评估私有测试集（有公开排行榜在此）。

后来，BrowseComp（2025）对此进行了复制，测试相同内容（模型能否使用工具和在线信息找到特定查询的适当答案），但不保证结果唯一性，因为问题是从结果出发构建的，难度不一：例如，针对一篇需要检索的特定论文，通过组合元数据信息来构造问题，如”哪篇关于某主题的论文在某会议发表，作者包含一名某国籍人员和两名来自某机构的人员？“不过，该 benchmark（基准测试）目前难度可能也较高。

GDPval（2025）在”对美国 GDP 贡献最大的行业”中 44 种职业上评测模型，使用模型评判将模型表现与人类表现进行比较。

最后，GAIA2 超越了简单的信息检索，使用模拟移动环境来测试助手能否正确回答依赖一系列事件和工具调用的查询。目前，时间敏感型和刻意引入噪声的子集（模拟 API 调用失败）对模型最具挑战性，而搜索和执行对于 SOTA（当前最优）模型而言已极为简单。

科学助手

SciCode（2024）测试模型能否通过编写适当的科学代码来解决真实科学问题，涵盖 STEM 各领域（从生物学到数学/化学……）。问题来源于真实工作流程，每个核心问题被分解为更简单的子问题。第一个版本由科学家和模型评判共同评测——发布时模型表现相当差（得分不足 5%），但我不确定最新结果在哪里可以找到。

PaperBench（2025）同样测试模型能否复现 ML 研究，但设置更难：给定高质量的 ICML 论文，模型必须重建对应的代码库（由论文作者贡献的 8000 个单独评分任务，组织为带权重的评分树以计算最终成绩）。Benchmark（基准测试）使用 LLM 评判进行评测（尽管我怀疑通过限制所要求代码的形态，部分工作可以自动化完成）。

DSBench（2025）是一个多模态数据分析 benchmark（基准测试），使用 Kaggle 和 ModelOff（金融数据）样本。从附录中的示例来看，ModelOff 的问题以多选题形式呈现，这可能使任务更容易，而 Kaggle 任务各自有其评估指标。

DABStep（2025）使用真实的、此前私有（因此未被污染）的运营数据分析工作负载，基于真实问题和数据来评测模型。所有问题都需要多步推理和多样化的文档解析，当然也需要特定的数据操作技能。这是一个简洁的评测，因为它难度适中且能复现实际有用的真实场景，并且每个问题都有标准答案，所以评测无偏且成本不高。

助手任务在现实场景中测试综合能力，但它们要么是动态只读的，要么处于不会改变的静态环境中。为了评测适应性和动态决策能力，我们需要能够”出奇”制胜模型的环境。

游戏类评测

游戏类 benchmark（基准测试）因多种原因而非常有趣：它们通常评测对变化环境的适应能力（与大多数静态助手任务相反），需要长上下文推理，最重要的是，对大多数人而言都易于理解。然而，它们与真实生活不够贴近，未必能反映在实际有用场景中的良好表现。

这类评测中最著名的正式评测可能是 ARC-AGI。第一个版本（2019）由序列中的谜题网格组成，模型需要在没有明确规则提供的情况下找出序列的最后一项。在我看来，这个 benchmark（基准测试）非常类似于面向逻辑的智商测试，并于 2024 年接近被解决。一个类似的 benchmark（基准测试）（规则推断）是 Baba is AI（2024）。该 benchmark（基准测试）的最新版本 ARC-AGI3（2025，进行中）仍在开发中，包含专为 benchmark（基准测试）设计的全新游戏（需要探索、复杂规划、记忆管理……）。目前仍在进行中，现有问题上的最佳解法是暴力破解游戏。

社区和模型提供商已探索了许多现有游戏与 LLM 的结合。单人冒险游戏/RPG 如 TextQuests（2025）或 Pokemon（2024）（Twitch 上有 Claude 和 Gemini 的直播）需要综合极长程规划来达成目标，这要求适当的长上下文记忆管理、推理和回溯能力。单人生存游戏如 Crafter（2021，Minecraft 风格）也需要相同能力。许多单人游戏环境已被整合到 Balrog（2024）benchmark（基准测试）中。

竞争性虚张声势游戏如 Poker（2025）、Mafia 变体如 Town of Salem（2025）和 Werewolf（2025，这里/那里），或 Among us 非常适合测试逻辑、推理以及欺骗能力。例如，Claude Opus 4 在 Town of Salem 中作为吸血鬼（欺骗性角色）无法获胜，但作为村民（非欺骗性角色）表现良好。合作类游戏如 Hanabi 也可用于在受限环境中测试适应性和沟通能力。

这类游戏的另一大优点是具有单一且明确的通过/失败指标：LLM 是否赢得了游戏？如果我现在要用这些来评测模型，我可能会关注 TextQuests 来测试能力，以及 Town of Salem 来测试安全性。

除了在受控环境中测试能力，人们还探索了终极难以作弊的任务：预测未来。

预测类

过去一年，出现了一类全新的、几乎无法被污染的任务：预测（forecasting）。（从技术上说，股市预测可以通过某些操纵手段作弊，但希望目前还没有到为扰乱评测而产生财务激励的地步。）这类任务理应需要跨来源推理来尝试解答尚未发生的事件，但尚不确定这些 benchmark（基准测试）是否具有足够的区分度，且它们可能强化了 LLM 的”老虎机式成功”感（某些事件上的表现接近随机，是因为它们本来就无法预测，还是因为模型不擅长？反过来，如果模型能正确预测某个事件，是问题太简单还是太有规律可循？）

FutureBench 测试模型是否能预测未来的新闻值得关注的事件。它使用两个来源：浏览和 LLM 生成的具有每周时间跨度的问题，以及来自博彩市场的用户预测。所有数据在使用前都经过严格过滤和清洗。目前，模型在人类创建的赌注上仅略好于随机，在模型生成的问题上成功率约为 3/4（后者可能更容易）。

FutureX 与之类似，但使用一系列特定网站（预测市场、政府网站、综合排名网站和实时数据平台），然后使用模板来生成关于潜在未来事件的问题（STOCK 何时达到 POINT？）。每天生成 500 道问题，并过滤掉意外不相关的问题。

Arbitrage 采用类似方法生成问题，核心区别在于时间跨度：其中的事件应在 2028 年解决。

同样地，你还会发现一些竞技场，LLM 在其中获得资金在金融市场上主动交易（如 Alpha Arena 或 Trading Agents）——这些实验不太可能得出有意义的结果，因为受成本限制，每个模型通常只运行一次，无法获得统计显著性。

推荐

深入理解 benchmark 的内容

无论你最初是如何选择数据集的，最重要的步骤始终是——亲自查看数据，包括你拥有的数据、模型生成的内容以及对应的分数。归根结底，这是唯一能让你确认评测是否真正适用于你特定场景的方法。

你需要研究以下几个方面。

数据创建过程

• 实际样本是由谁创建的？ 理想情况下，你希望数据集由专家创建；其次是付费标注员，再次是众包，然后是合成数据，最后是 MTurk（机械土耳其）。你还需要查阅数据卡片（data card），其中包含标注员的人口统计信息——这对于理解数据集的语言多样性或潜在的文化偏见非常重要。

• 所有样本是否经过其他标注员或作者的审核？ 你需要了解样本的标注员间一致性分数是否较高（即标注员之间的意见是否一致？），以及整个数据集是否经过作者的审查。 对于借助报酬较低的标注员（如 AWS Mechanical Turk 上的标注员，通常不是目标语言的母语者）所创建的数据集，这一点尤为重要——否则你可能会发现其中存在拼写错误、语法错误或答案不合逻辑的情况。

• 标注员是否获得了明确的数据创建规范？ 换句话说，你的数据集是否一致？

样本检查

随机抽取50个样本并亲自检查；我说的是你自己来做，而不是”让LLM替你找数据中的异常”。

首先，检查内容质量：

• 提示（prompt）是否清晰无歧义？
• 答案是否正确？（例如：TriviaQA每道题包含多个标准答案（aliases字段），有时存在相互矛盾的情况。）
• 是否缺少信息？（例如：MMLU的部分题目引用了文中未附的示意图。）

请务必记住，数据集是标准并不等于它是高质量的——而大多数人跳过了这一步，这种情况才会发生。

其次，检查与你任务的相关性。这些问题是你希望用来评测LLM的那类问题吗？这些示例与你的使用场景相关吗？

你可能还需要检查样本的一致性（尤其是当你计划使用 few-shot 或计算聚合统计数据时）：如果是多选题评测，所有样本的选项数量是否相同？提示前后的空格是否一致？如果你的评测附带了额外的运行环境，最好也通过它来了解实际调用的是什么。

最后，还需要快速检查样本数量（以确保结果具有统计显著性——对于自动 benchmark，通常至少需要100个样本）。

在下面的查看器中，你可以查看由 Lewis 收集的知名 post-training（后训练）benchmark 的前几个样本。

任务与指标

你需要检查使用了哪些指标（metrics）：它们是自动化的、功能性的，还是基于模型裁判（model judge）的？答案将影响你运行评测的成本，以及可复现性和偏差类型。最佳（但也最罕见）的指标是功能性测试或基于规则的验证器

所以，你无法复现模型公告中的分数？

假设你读了一篇关于某个酷炫新模型的技术报告，想在自己的机器上复现其结果……但就是复现不了？ 让我们来探讨一下原因。

代码库不同

要将评测分数精确复现到小数点，首先需要确保使用与目标论文完全相同的代码库。

通常来说，这意味着要么使用作者提供的官方评测代码，要么使用 Eleuther’s AI lm_eval 或 HuggingFace 的 lighteval 等参考库中的标准实现。然而，如果论文没有提供评测代码来源，那么很遗憾，你很可能无法精确复现其结果。

如果你想直观了解不同实现之间会产生哪些差异，可以参考这篇博客（⭐），这是我们与 HuggingFace 评测团队共同撰写的。它研究了 MMLU 评测在 3 种常见实现（lm_eval、helm 和原始作者实现）之间的差异，以及这些差异如何影响模型得分。

细微的实现或加载差异

我们发现，即使使用相同的代码库，以下几点也很容易出错：

• 不同的随机种子（random seed）。
  • 通常情况下，推理受随机种子的影响比训练小。但随机种子仍可能影响某些 CUDA 操作（参见 PyTorch 关于可复现性的文档），并在使用非贪心（non greedy）生成策略时改变预测结果。它还会影响使用 few-shot（少样本）时的 prompt（提示词），以及部分预处理和后处理函数。 -> 微小的改动可能导致几个点的差异。
• 实际上不同的指标（metrics）。 即使名称相同，指标在实际使用中也可能不同。举例如下：
  • 如果原始实现是 对数似然（log likelihood） 版的 exact match（计算不同可能答案的对数概率），而你使用的是生成式（generative） 版的 exact match（仅将主要的贪心生成结果与参考答案比较），那么得分就不会相同。
  • 我们还在评测代码库中发现，有些任务定义为 exact match，但实际上是 prefix exact match（仅比较生成结果的开头与参考答案）、suffix exact match（相反，比较结尾）或 quasi exact match（带归一化的精确匹配）。 -> 因此不能仅凭指标名称来判断实际发生了什么，需要查阅代码。
• 不同的归一化（normalization）方式。
  • 回到上面的 exact match 对比示例，在 lm_eval v1 中，许多任务只是被命名为生成式 exact match：你可能会据此认为预测结果是直接与参考答案比较的。 但查看代码后会发现，预测结果在与参考答案比较之前会经过一个归一化步骤（去除标点、统一数字格式等）。这显然会对结果产生较大影响。 （lm_eval v2 现在已在大多数指标名称中包含归一化方式的说明。） -> 这是最容易出错的地方之一，尤其是对于需要大量归一化/答案后处理的任务，例如数学评测（需要从生成的解题过程中提取答案）。

不同的 prompt（提示词）

prompt 变化主要涉及 3 个方面。

prompt 本身

你使用的 prompt 格式会对分数产生巨大影响。

例如，对于多选题，常见格式包含一些非常细微的变体（如用 A、A. 或 A) 来引出选项），这些格式在语义上等价（因为内容完全相同），但对同一模型的得分影响却可能达到几个点。

某些任务还会在开头加上任务提示（如：The following questions are about <topic>），其存在与否同样会影响得分。

系统提示（system prompt）与对话模板（chat template）

聊天（chat）模型通常经过了指令微调（instruction fine-tuning）或偏好训练（preference training）。在这一阶段，它们学会了在推理时遵循特定的对话模板（chat template）。例如，模板可能要求在每轮对话开头加上一个通用提示（称为 system prompt，系统提示词），并以特定 token 作为前缀（通常是 System: ）。该提示用于向模型提供高层次指令，例如角色人格的内容或通用回答风格的说明。每轮对话还可能要求在文本前添加关键词前缀，如用 User 标识提问，用 Assistant 标识回答。

使用 few-shot 时，还需要选择是以多轮对话形式（模拟 user/assistant 轮流）提供示例，还是一次性全部放在单个 user 提示中。

推理时若不遵循模型所期望的对话模板，会严重损害其性能，因为这会将模型的输出引向它训练时收敛的概率空间之外。

类似地，如果使用推理模型（reasoning model），还需要确认对比时是否启用了思考（thinking）模式。

Few-shot 样本

在 few-shot 样本方面，有两点很容易出错：few-shot 示例的数量、所使用的具体示例，以及它们的排列顺序。

这也是需要特别关注随机种子的地方。

参数（Parameters）

对于生成式评测（generative evaluations），需要注意的参数包括：1) 使用相同的句子结束 token（end of sentence token，对于聊天模型和推理模型，不应使用默认值）；2) 允许模型为评测生成相同数量的 token（这对推理模型尤为重要，因为它们在思考模式下需要大量 token）；3) 如果使用采样（sampling），确保使用相同的种子/温度（seed/temperature）参数。

为模型训练自动筛选合适的 benchmark

在某些情况下，你并不只是想”事后”复现已有的分数，而是需要在模型训练过程中实时了解其训练效果。此时所需的评测具有与最终性能评测不同的特性：你需要的任务即使在模型尚未很强时，也能提供有效的信号。

因此，FineWeb 团队设计了一套方法，用于在 9 种语言的预训练消融实验（ablation）中筛选出最佳评测任务——让我们来听听他们的宝贵经验。

针对这些语言，我们收集并实现了所有能找到的可用任务，共计 185 个任务。随后，我们以两个核心目标开始进行任务筛选：确保评测多样性，以及确保每个任务在预训练过程中能提供可靠的信号。

在评测多样性方面，我们旨在覆盖广泛的模型能力，包括：

• 阅读理解（RC，Reading Comprehension）：理解所提供的上下文并基于此回答问题。
• 通用知识（GK，General Knowledge）：无需额外上下文，回答来自各领域的事实性问题。
• 自然语言理解（NLU，Natural Language Understanding）：理解所提供输入的语义。
• 常识推理（RES，Common-sense Reasoning）：展示运用具身知识（embodied knowledge）进行简单推理的能力。
• 生成式任务（Generative Tasks）：在无多选项”辅助”的情况下，以目标语言生成文本的能力。

我们认为，若任务能提供可依赖的分数，则视为可靠信号。这意味着分数应高于随机基线（random baseline），随着训练推进而上升，在不同随机种子下变化幅度小，并在每个训练步骤中对模型排名保持一致针对使用相同超参数在相同数据量上训练的同等规模模型。。

为深入考察各任务所提供的信号质量，我们针对每种语言训练了多个 1.5B 参数模型，使用了来自五个最大的公开多语言网络数据集的目标语言子集中的 300 亿 token。这些模型使用相同的超参数和 tokenizer（分词器）进行训练，随后在固定检查点间隔上以零样本（0-shot）、无指令、无系统提示的方式对所有收集的任务进行评测。

由于每个任务的实现需要多轮迭代和多次评测运行，整个过程共消耗了 73,000 GPU 小时 🔥！

训练了 49 个模型之后，我们终于可以给出我们对可靠信号的定义！

单调性（Monotonicity）

我们对任务的核心要求之一，是该任务能够从训练数据中被习得，且这种学习过程可以随着训练的推进被逐步观察到。如果性能没有随时间提升，就无法判断未来是否会出现改善。

为此，我们使用 Spearman 秩相关系数来量化训练步骤与分数之间的相关性。Spearman 秩相关即使在分数与步骤数不呈线性关系时也能捕捉到单调性。我们要求每个任务在所有模型训练运行中的平均相关系数至少为 0.5。

低噪声（Low Noise）

在比较模型在任务上的表现时，我们需要考虑差异是源于评测噪声还是真实的性能差异。

噪声可能来自模型训练中涉及的随机过程，例如 token 随机采样、数据打乱或模型初始化（Madaan et al., 2024）。为衡量每个任务对噪声的敏感程度，我们使用不同随机种子，在自建的单语语料库（各语言的未过滤 CommonCrawl 数据）上额外训练了四个模型。

对于每个任务，我们计算了：

1. 首先，计算每个步骤（约每 10 亿 token）的模型分数标准差，称为逐步标准差（per-step-std）。
2. 然后，将所有逐步标准差取平均，得到整个训练过程的平均标准差（avg-std），作为全局变异性度量。我们假设此值是跨模型架构和训练数据集的上界（因为它是用在”较脏”数据集上训练的模型估算的，因此变异性更高）。
3. 最后，我们以**信噪比（SNR，Signal-to-Noise Ratio）**作为任务变异性的主要指标。SNR 的计算方式为：所有运行在 300 亿 token 时的平均分数除以 avg-std。该指标衡量的是整体分数相对于分数波动（噪声）的显著程度。

我们要求每个任务的 SNR > 20。唯一的例外是生成式任务，它们通常 SNR 相对较低，但仍值得纳入，因为它们能揭示模型在无答案选项约束下自由生成时的行为特征。在多语言场景下，这一点尤为重要——某些在多语言数据上训练的模型可能在任务分数上表现很高，但在生成式任务中却突然以错误的语言作答！

非随机性能（Non-Random Performance）

许多模型能力在训练后期才会习得，因此许多任务（尤其是较难的任务，如与数学相关的任务）会在较长时间内保持基线水平的性能。虽然这些任务有其价值，但并不适合用于早期预训练评测，我们不希望在此设定中保留它们。

我们首先计算任务的基线随机性能（对于多选题，为所有样本的 1/n_choices 之和；对于生成式评测，为零）。然后，将任务与基线的距离计算为所有模型的最高分减去基线分。

模型排序一致性（Model Ordering Consistency）

别忘了，这些评测的主要目标是比较模型和数据集！

未来，我们希望利用这些评测来选择用于全量模型预训练的最佳数据集。这意味着我们的任务应该能够在训练 token 数极少时（我们通常在 300 亿 token 上运行数据消融实验），就以与训练更长时间后相同的顺序对数据集进行排名。

换言之，我们希望任务具有对预训练过程中未来性能的预测能力：如果预训练数据集 A 在 300 亿 token 时优于预训练数据集 B，我们希望这一趋势在 3000 亿 token 时依然持续。

证明这一点本质上是不可能的，但我们可以验证一个必要的前提条件：若要在大规模训练时结果保持一致，首先必须在小规模训练时也表现出一致性！

为衡量任务排序的一致性，我们计算了每两个相邻步骤之间模型排名的平均 Kendall’s Tau。我们只考虑预训练超过 150 亿 token 之后的步骤，因为我们发现此范围之前的排序噪声极大。该指标值越高，说明随着训练推进，排序保持越稳定。

评测指标（Metrics）

由于 CF（Cloze Format，完形填空格式）多选任务的目标本身是选项，每个目标的 token 数、字符数以及无条件概率（在无上下文前缀时生成该选项的概率）可能各不相同。

为此，我们考虑以下几种准确率变体：

• 准确率（Accuracy）： acc = $\underset{i}{\arg\max}(ln(P (a_i|q)))$
• 按字符长度归一化的准确率（Accuracy normalized over character length）： acc_char = $\underset{i}{\arg\max}\frac{ln(P (a_i|q))}{num\_characters(a_i)}$
• 按 token 长度归一化的准确率（Accuracy normalized over token length）： acc_token = $\underset{i}{\arg\max}\frac{ln(P (a_i|q))}{num\_tokens(a_i)}$
• PMI 准确率（PMI Accuracy）： acc_pmi = $\underset{i}{\arg\max}ln\frac{P (a_i|q)}{P (a_i|u)}$，其中 $u =$ ”Answer:”

其中 $a_i$ 为第 $i$ 个答案选项，$q$ 为问题提示，$P (a_i|q)$ 为在给定 $q$ 的条件下生成 $a_i$ 的概率。更多细节请参阅 Gu et al., 2024 和 Biderman et al., 2024。

对于我们的生成式任务，我们则使用以下指标：

• prefix_match：前缀精确匹配，即答案仅需前缀部分匹配
• f1：使用词语 tokenizer（分词器）提取预测词和标准答案词后计算的 F1 分数

对于两种生成式指标，均会进行简单的预处理：去除冠词和标点符号，并将文本转为小写。

选择最佳评测指标是一项颇具挑战性的工作。不仅没有哪个单一指标能始终优于其他指标，我们还经常遇到一个指标单调性更好、而另一个指标信噪比更高的情况。在这种情况下，我们通常参考同一任务在其他语言实现中所选用的指标来做决策。我们深知这种人工选取的方式并不总是可行，因此提供以下建议：

➡️ 多选任务（Multichoice Tasks）

• 对于答案选项细微差异的任务（例如 是/否/也），我们发现**基础准确率（base accuracy）**表现良好，这在 NLI 任务中尤为常见。此类情况下，答案选项通常各只有一个 token，建议使用基础准确率。
• 虽然 OLMES 的作者（Gu et al., 2024）建议对含有不常见词的任务使用 PMI，但我们发现 PMI 对于 AGIEVAL 或 MMLU 等”较难”的推理和知识任务非常有效。在这些情况下，PMI 提供了最佳结果，往往是唯一能使性能超出随机水平的指标。然而，PMI 在所有其他任务的平均表现上是最弱的，且计算成本是其他指标的两倍。因此，我们仅建议将其用于复杂的推理和知识任务。
• 我们发现整体最可靠的指标是长度归一化指标（基于 token 或字符）。然而，哪种最优取决于语言，而非对给定任务保持一致。因此，我们建议取 acc_char 和 acc_token 的最大值以获得最可靠的结果。注意，acc_token 对 tokenizer（分词器）高度依赖。在我们的消融实验中，所有模型均使用相同的 tokenizer 训练。

➡️ 生成式任务（Generative Tasks）

对于生成式指标，选择相对明确：我们建议使用 F1 分数，除非需要精确匹配（如数学相关任务）。F1 通常噪声更低，对生成结果的细微变化更具鲁棒性。

创建你自己的评测

到了这个阶段，你可能已经对人们为何进行评测有了清晰的认识，也了解了哪些 benchmark 适用于模型的不同阶段（训练、base 模型和 fine-tuned 模型的推理），但如果针对你特定场景的评测根本不存在呢？

这正是你可能需要创建自己的评测的时候。

数据集

使用现有数据

你可以直接使用现有数据集，并修改其关联的提示词（prompting）或评估指标（metrics）（就像对旧版评测进行改造以适配新提示方法那样），也可以对多个数据集进行聚合。

当你想评测某项能力，但单一 benchmark（基准测试）覆盖不够全面时，数据集聚合是一个很好的思路。与其从头开始，不如从多个现有数据集中抽取样本，组合成一套有针对性的评测套件。例如，“Measuring AGI”论文的作者最近就采用了这种方法，试图构建一个新的”AGI 评测”数据集。

在聚合数据集时，需要注意以下几点：

• 是否存在冗余数据（大多数数学数据集都是对同一批初始题目的改写或聚合）
• 是否需要各来源数据的均衡表示（你可能不希望某个数据集过于主导并扭曲评测结果）——这也将决定你是在所有样本上聚合分数，还是按子集分别聚合
• 格式与难度等级是否兼容（通常，如果要创建统一数据集，要注意不要将需要采样和不需要采样的样本混在一起）

EpochAI（2025 年）的最新研究展示了如何在统一框架下最优地聚合多个 benchmark，使聚合后的数据集整体难度更高，同时降低饱和（saturation）风险。

使用人工标注员

建议阅读这篇关于数据标注质量良好实践的综述的第 3 节。如果你需要达到生产级质量，并且有能力实施所有这些方法，尽管去做！

但无论项目规模大小，在确定任务和评分指南之后，以下重要准则都必须遵守。

• 人员筛选，如有条件请给予金钱激励 你希望参与任务的人员能够：

1. 满足一定的人口特征要求。 示例：是目标语言的母语者、拥有较高学历、是某一特定领域的专家、地域来源多样，等等。 你的需求会因任务不同而有所差异。
2. 产出高质量的工作成果。 现在尤其重要的是，要增加检测答案是否由 LLM（大型语言模型）生成的手段，并从标注员池中过滤掉部分人员。 在我看来，除非你依赖高度积极的众包标注员，否则给标注员合理的薪酬总是更好的选择。

• 指南设计 务必花大量时间认真构思你的标注指南！这是我们在 GAIA 数据集上花费时间最多的环节之一。

• 迭代标注 做好进行多轮标注的准备，因为标注员会误解你的指南（它们比你想象的更有歧义）！多次生成样本将帮助标注员真正聚焦于你的需求。

  • 质量估计与人工筛选 你需要对答案进行审核（尤其是在可行的情况下通过标注员间一致性来核查），并进行最终筛选，只保留质量最高/最相关的答案。

像 Argilla 这样专门用于构建高质量标注数据集的工具也能为你提供帮助。

合成数据集

使用基于规则的技术

如果你的任务允许，使用程序化生成的 benchmark 是一种非常好的方式，可以获得近乎无限的样本供给，同时避免数据污染（contamination）！这类方法可以通过算法生成无限的全新测试用例，同时控制难度并支持自动验证，确保模型在训练阶段未曾见过这些样本。

具体示例可参考 NPHardEval、DyVal、MuSR、BabiQA、ZebraLogic、IFEval 以及 GSMTemplate 等。NPHardEval 会生成基于复杂度分级的任务（如图问题），支持自动验证并每月刷新，以减少过拟合。MuSR 使用神经符号（neurosymbolic）生成方法创建复杂推理实例，例如长达 1000 词的谋杀推理故事。ZebraLogic 通过算法生成逻辑网格谜题，先生成答案，再使用 SAT 求解器迭代精简线索。BabiQA 模拟实体按照一系列动作顺序执行的过程。IFEval 使用 500 余条包含可验证约束（如字数限制）的提示词来测试指令遵循（instruction-following）能力，这些约束可通过编程方式进行检验。GSM-Symbolic 使用模板生成多样化数学题目。

通常适合这种范式的任务主要测试数学、逻辑或代码能力。

使用模型生成合成数据

如果你想创建合成数据，通常需要从一批种子文档（seed documents）出发，将其作为你的真实标签（ground truth）。这些文档可以是针对你的使用场景的内部数据，也可以是网络上质量较高的公开资源（如 Wikipedia、Stack Overflow 等）。接下来，你可能需要将数据切分为具有独立语义的片段。

然后，你可能需要让一个模型根据你的数据设计问题。为此，你需要选择一个前沿模型（frontier model），并精心设计提示词，让模型从提供的数据中生成与使用场景相关的问题。最好能要求模型注明其问题所依据的来源。

如果你想完全走合成路线，也可以使用种子提示词作为示例，提供给外部模型，让它为你的模型编写提示词，再由你的模型生成新问题。^^

完成上述步骤后，你可以使用另一家模型系列的模型，以”真实标签 + 问题 + 答案”作为输入，将其作为模型裁判（model judge）进行自动化验证。

管理数据污染

一般来说，你应当假定公开发布在互联网上的数据集已经或将会被污染。

应对措施包括：

• 在评测集中加入金丝雀字符串（canary string）（如 BigBench 所做的那样）：这是一种特定的字符组合，模型训练方可以在训练集中搜索该字符串，以判断训练数据中是否包含该评测集
• 以**加密或访问受限（gated）**的形式提供评测集，使其难以被网络爬虫解析，从而避免意外进入训练集
• 运行动态 benchmark：定期更新的 benchmark，使模型无法”死记答案”（但这会增加数据集维护成本）
• 如果你正在运行某个 benchmark，可以尝试事后检测污染（例如，通过观察生成困惑度（perplexity）或设计对抗性提示词版本——但目前没有任何方法能够万无一失地检测污染）

然而，数据集被污染并不意味着它在训练过程中就不再有用或失去信号，正如我们在消融实验（ablations）部分所看到的那样。

选择提示词

提示词（prompt）将决定向模型提供多少关于任务的信息，以及这些信息如何呈现给模型。它通常包含以下几个部分：一个可选的任务提示（task prompt），用于介绍任务及输出应遵循的格式；可选的附加上下文（attached context）（例如来源文档、图片）；问题提示（problem prompt），即你向模型提出的具体问题；以及多选评测的可选选项。

在定义提示词时，你需要注意：即使是语义等价的提示词之间的细微差异，也可能导致结果相差悬殊，而且不同的提示词格式可能会对特定模型产生有利或不利的影响（参见此章节）。

➡️ 这一问题可以通过对提示词进行多次变体并重复运行评测来缓解（但代价较高），或者直接运行一次评测，对相同难度的不同样本使用多种提示词格式。

➡️ 你也可以向模型提供示例（即小样本学习，few-shot examples），帮助其遵循预期格式，添加连接词也有助于整体效果。

为模型选择推理方法

你需要选择所需的推理方式。

评分

如果你使用的是对数概率，指标会相对简单：你可能需要关注准确率的某个变体（即最可能的选项是否为最优答案）。需要注意的是，应按序列长度进行归一化（字符级、token 级或 PMI 归一化）。你也可以关注困惑度（perplexity）、召回率（recall）或 F1 分数。

如果你使用的是生成式评测，这部分就会变得比较复杂，因此下一章将专门讨论这一话题！

评测的核心挑战：对自由形式文本进行评分

对自由形式文本进行评分非常棘手，原因在于：表达同一正确答案通常有很多不同方式，这使得通过简单的字符串匹配来判断语义等价变得困难；输出形式的差异可能使两个语义完全相同的答案看起来截然不同。回答可能部分正确，或同时包含准确和不准确的信息。对于某些问题，甚至不存在唯一的标准答案，例如需要判断连贯性（coherence）、有用性（helpfulness）和风格（style）的任务——这些本质上是主观的，且依赖于具体情境。

自动化评分

然而，当存在标准答案（ground truth）时，你可以使用自动化指标，下面来看具体方法。

指标

自动比较文本字符串与参考答案的大多数方法都基于匹配（match based）。

最简单但灵活性最低的匹配指标是 token 序列的精确匹配（exact match）。虽然简单且无歧义，但它不提供部分得分——一个只有一个词错误的预测和一个完全错误的预测会得到相同的分数。

翻译和摘要领域引入了通过 n-gram 序列重叠度来比较相似性的自动化指标。BLEU（Bilingual Evaluation Understudy，双语评估替代）衡量与参考译文的 n-gram 重叠度，尽管存在偏向较短译文的长度偏差（length bias），且在句子级别与人类判断相关性较差，但仍被广泛使用（值得注意的是，它对于语义等价但表达方式与参考答案不同的预测效果不佳）。ROUGE 做的事情类似，但更侧重于召回导向（recall-oriented）的 n-gram 重叠度。这些指标中更简单的版本是 TER（翻译错误率，translation error rate），即将预测结果修改为正确参考答案所需的编辑次数（类似于编辑距离）。 最后，你还会发现基于模型的指标，它使用嵌入距离（embedding distances）来衡量相似性，例如 BLEURT（使用基于 BERT 的学习表示，在 WMT 的人类判断数据上训练，与 n-gram 方法相比具有更好的语义理解能力，但需要下载模型，且需针对特定任务进行微调才能达到最优性能）。 这里介绍的是最广为人知的指标，但这些指标都有各自的变体和扩展版本，其中包括 CorpusBLEU、GLEU、MAUVE、METEOR 等，不一而足。

一旦获得每个样本的准确率分数，你可以通过多种方式在整个数据集上进行聚合。通常情况下，人们会对结果取平均值，但你也可以根据需求进行更复杂的处理。（某些指标已自带聚合方式，如 CorpusBLEU。）

如果你的分数是二元（binary）的，可以关注精确率（precision）（当假阳性代价较高时至关重要）、召回率（recall）（当漏掉正例代价较高时至关重要）、F1 分数（平衡精确率和召回率，适用于不平衡数据）或 MCC（Matthews 相关系数，通过考虑所有混淆矩阵元素来有效处理不平衡数据集）。 如果你的分数是连续（continuous）的（概率较低），可以使用均方误差（mean squared error，MSE）（对大误差惩罚较重，但对异常值权重过大）或平均绝对误差（mean absolute error，MAE）（比 MSE 更均衡）。

更广泛地说，在选择指标及其聚合方式时，你需要时刻牢记任务的真正目标。对于某些领域（如医疗、面向公众的聊天机器人），你不应关注平均性能，而需要一种能够评估最差表现的方法（针对医疗输出质量、毒性等方面）。

归一化

归一化（normalization）是指将一段字符串转换为符合特定参考格式的过程。例如，在将模型预测与参考答案进行比较时，你通常不希望因预测中多余的空格、标点符号或大小写而受到惩罚。这就是为什么你需要对预测结果进行归一化。

归一化对于某些特定任务至关重要，例如数学评测——你需要从较长的预测文本中提取方程式，并与参考答案进行比较。 下表列出了我们在使用 SymPy 朴素地提取 MATH 数据集模型输出时遇到的一些问题，以及专用数学解析器 Math-Verify 是如何解决这些问题的。

归一化如果设计不当，可能会产生不公平的结果，但总体上它仍有助于在任务层面提供有效信号。

归一化在评测思维链（chain of thought）或推理模型生成的预测时同样重要，因为你需要从输出中去除推理轨迹（reasoning trace）——它不属于最终答案的一部分——才能得到实际答案。

采样

当模型生成输出时，多次采样并聚合结果通常比单次贪婪解码（greedy generation）能提供更稳健的信号。 这对于复杂推理任务尤为重要，因为模型可能通过不同路径得出正确答案。

常见的基于采样的指标有：

• pass@k over n：给定 n 个生成样本，衡量其中至少 k 个通过测试的比例。

• maj@n（多数投票，majority voting）：采样 n 个生成结果，取出现频率最高的答案。这有助于过滤掉偶发性错误输出，在模型正确推理路径比错误路径更稳定的情况下效果尤为突出。常用于数学和推理任务。

• cot@n（思维链采样，chain-of-thought sampling）：采样 n 条推理轨迹并进行评测。可与多数投票或 pass@k 结合使用（采样 n 条推理链，提取最终答案，取多数或设定阈值）。

• avg@n（稳定平均分，stable average score）：对 n 个样本的分数取平均。比使用”最佳”或”最常见”情况更稳定地估计模型性能。

使用采样评测时，务必始终报告所有采样参数（温度、top-p、k 值），因为这些参数会显著影响结果。

功能性评分器

与通过模糊字符串匹配将生成文本与参考答案进行比较不同，功能性测试（functional testing）评估输出是否满足特定的可验证约束。这种方法极具前景，因为它更灵活，并且通过基于规则的生成允许对测试用例进行”无限”更新（从而减少过拟合）。

IFEval 和 IFBench 是这种方法在指令遵循（instruction following）评测领域的典型示例。它们不问”这段文本是否与参考答案匹配？“，而是问”这段文本是否满足指令中给出的格式约束？”

例如，指令可能包含以下要求：

• “恰好包含 3 个要点” → 验证输出是否恰好包含 3 个要点
• “只大写第一句话” → 解析并检查大写规律
• “至少使用两次 ‘algorithm’ 一词” → 统计词语出现次数
• “你的回答必须是 JSON 格式，包含 ‘answer’ 和 ‘reasoning’ 两个键” → 验证 JSON 结构

每个约束都可以通过特定的基于规则的验证器进行检查，使这类评测更加明确、可解释、高效，且比使用模型作为裁判（model as judge）的成本低得多。

这种功能性方法非常适用于指令遵循任务，但将其扩展到其他文本属性需要一定的创造力。关键在于识别那些可以通过编程方式验证的文本特征，而不是依赖语义比较。

使用人工评测

人工评测就是让人类对模型预测进行打分。

人工评测非常有价值，原因在于其灵活性（只要你对评测内容定义得足够清晰，几乎可以对任何事物进行打分！）、天然的非污染性（如果由人类编写新问题来测试你的系统，希望这些问题不会出现在你的训练数据中）以及与人类偏好的良好相关性（这是显而易见的）。

使用人工参与评测模型的方式有多种。

**Vibe-check（感知评测）**是指由社区个别成员在未公开的提示词上进行的手动评测，旨在对模型在其偏好使用场景下的表现获得整体”感觉”。（我也见过将此称为”canary 测试”，对应矿井中金丝雀（canary in a coalmine）的高信号比喻）。这些使用场景五花八门，从最令人兴奋的到最平凡的都有——我在 Reddit 上见过的一些例子包括：德语法律问题、编程、工具使用、所写色情小说的质量，等等。这类评测通常分享在论坛或社交媒体上，大多只是个案证据（anecdotal evidence），且往往高度容易受到确认偏误（confirmation bias）的影响（换句话说，人们倾向于找到他们预期会找到的东西）。

利用社区反馈建立大规模模型排名，就是我们所说的竞技场（arena）。一个知名示例是 LMSYS chatbot arena，社区用户在其中与模型对话，直到认为某个模型比另一个更好为止。投票结果随后以 Elo 排名（一种比赛排名方式）进行聚合，以选出”最佳”模型。这种方法存在明显的主观性问题——由于许多社区成员使用宽泛的评分标准，很难确保评分的一致性，尤其是标注人员的偏好往往具有文化绑定性（不同人倾向于偏好不同的讨论话题，等等）。我们寄希望于这种效应能够通过海量投票的规模效应被平滑掉——通过所谓的”群体智慧（wisdom of the crowd）“效应（这一效应由统计学家 Galton 发现，他观察到个人对某一数值（如猪的重量）的估计可以被建模为以真实答案为中心的概率分布）。

最后一种方法是系统化标注（systematic annotations），即向经过筛选的付费标注人员提供极其具体的标注指南，以尽可能消除主观性偏差（这是大多数数据标注公司所采用的方法）。然而，这种方法成本极高，因为对于每个需要评测的新模型，你都必须持续进行非自动化的评测工作；而且它仍然可能受到人类偏见的影响（这项研究表明，拥有不同身份的人对模型答案毒性的评分差异很大）。

Vibe-check 是针对自身使用场景的绝佳起点，因为你在测试对自己而言真正重要的内容。非正式人工评测的优点在于成本低廉，且因为充分利用了用户的创造力（几乎不受约束），可以发现有趣的边缘案例。但它们可能存在盲点。

当你想扩展到使用付费标注人员进行更系统化的评测时，你会发现主要有 3 种方式。如果你没有数据集，但想探索一组能力，可以向人类提供任务和评分指南（例如：尝试让这两个模型输出都输出有毒语言；如果模型输出了有毒内容，得 0 分，否则得 1 分），以及可以与之交互的一个（或多个）模型，然后要求他们提供分数和理由。如果你已经有了数据集（例如：一组你不希望模型回答的提示词，比如出于安全目的），你可以用这些提示词预填充你的模型，然后向人类提供提示词、模型输出和评分指南。如果你已经有了数据集和分数，你可以通过让人类进行错误标注（error annotation）来审查你的评测方法（它也可以作为上述类别中的一种评分系统）。这是测试新评测系统的重要步骤，但从技术上讲，它属于对评测进行评测，因此略超出本章讨论范围。

系统化人工评测（尤其是使用付费标注人员时）的优点在于：你获得的是高质量的私有数据，专门针对你的使用场景（特别是依赖内部标注人员时），且大多是可解释的（模型获得的分数可由给出分数的人类进行解释）。 然而，这种方法成本更高（尤其是你很可能需要经过多轮标注来调整指南），且扩展性较差。

总体而言，人工评测存在若干已知偏差，包括基于第一印象、语气、与标注人员价值观的契合程度等，详见下图。

这些偏差并不出乎意料，但必须将其纳入考量：并非所有使用场景都应依赖廉价的人工标注人员——任何需要事实准确性的任务（如代码编写、模型知识评测等）都应包含另一种更稳健的评测类型作为补充（专家评测、自动化指标（如适用）等）。

使用裁判模型

为了降低人工标注人员的成本，一些研究人员开始探索使用模型或其衍生产物（最好是与人类偏好对齐的）来评测模型的输出。

裁判模型（judge models）简而言之就是用于评测其他神经网络输出的神经网络。在大多数情况下，它们评测的是文本生成结果。

评分方式有两种：使用通用高能力模型，或使用专门在偏好数据（preference data）上训练以进行判别的小型专用模型（类似于”垃圾邮件过滤器”，但针对的是毒性检测等场景）。在前一种情况下，当使用 LLM 作为裁判时，你需要提供一个提示词来解释如何评分（例如：将流畅度从 0 到 5 进行评分，0 表示完全无法理解……）。

模型裁判（model as judges）可以对文本的复杂且细致的属性进行评分。 例如，预测与参考之间的精确匹配可以让你测试模型是否预测了正确的事实或数字，但评估更开放性的经验能力（如流畅度、诗歌质量或对输入的忠实程度）则需要更复杂的评估器。

它们主要用于以下 3 类任务：

• 对模型生成结果进行评分：在给定的量表上评估文本的某个属性（流畅度、毒性、连贯性、说服力等）。
• 成对评分（pairwise scoring）：比较一对模型输出，就某个给定属性挑选最优文本。
• 计算相似度：计算模型输出与参考答案之间的相似程度。

使用裁判 LLM 的优缺点

支持裁判 LLM 的人声称它们能提供：

• 与人类相比更强的客观性：它们以客观且可重复的方式自动化经验性判断（理论上如此——在我看来，它们引入的细微偏差比它们所消除的要多）
• 规模化与可重复性：比人工标注人员更易规模化，允许在大量数据上重复评分（如果控制了温度参数）
• 成本：实例化成本低廉，因为无需训练新模型，只需良好的提示词工程和现有的高质量 LLM 即可。同时比聘请真实的人工标注人员更便宜（资本主义的产物……）

在我看来，正确使用 LLM 裁判极具挑战性，对于关键使用场景而言极易产生误导：

• LLM 裁判看似客观，但它们有许多隐性偏差，可能比人类的偏差更难被发现，因为我们并未主动寻找它们（见下文）。此外，通过特定统计稳健的方式设计调查问题，已有可以减少人类偏差的方法（这在社会学领域已被研究了约一个世纪），而 LLM 的提示词工程在这方面还不够成熟。使用 LLM 来评测 LLM 被比喻为制造回音室效应，通过微妙地强化偏差。
• 它们确实可以规模化，但会产生大量数据，而这些数据本身需要被检查以确保质量（例如，你可以通过要求 LLM 裁判生成思维轨迹或推理过程来提高其质量，但这会生成更多的人工数据需要分析）
• 它们确实实例化成本低廉，但不如为你的特定使用场景聘请真正的专业人工标注人员效果好。

这一节因此篇幅较长，因为你需要充分了解使用模型作为裁判的局限性：很多人因为它看起来比真正与人类合作或设计新指标更容易而盲目跳进去使用，但最终却得到了充满难以提取的棘手偏差的难以解读的数据。

我个人对使用模型作为裁判的最大疑虑在于，它们在答案选择中引入了非常细微且难以解释的偏差。我觉得，就像遗传学研究中过度近亲繁殖最终会产生功能失调的动物或植物一样，通过使用 LLM 来选择和训练 LLM，我们同样可能引入微小的变化，这些变化会在几代之后产生更大的影响。我认为这种偏差在作为裁判的较小专用模型（如毒性分类器）中不太可能出现，但这仍有待严格测试和证明。

获取裁判模型

在使用现有 LLM 时，你可以选择通用高能力模型、专门在偏好数据上训练以进行判别的小型专用模型，或自己训练一个。

使用通用 LLM

随着更强大的 LLM（如 ChatGPT）的出现，一些研究人员开始探索将大型模型用作裁判。

如果需要选择模型提供商，你可以在这里找到一份很好的成本分析。

使用超小型专用 LLM 裁判模型

你也可以选择使用超小型专用 LLM 裁判。这类模型通常只有几十亿参数，可以在大多数近期消费级硬件上本地运行，同时可以从头训练或使用指令数据进行微调。通常需要遵循其特定的提示词格式。

2024 年的一些现有模型包括：Flow-Judge-v0.1（权重），3.8B 参数，基于 Phi-3.5-mini-instruct 在合成偏好数据集上微调；Prometheus（权重，论文），13B 参数，在合成偏好数据集上从头训练的模型；以及 JudgeLM（论文），7B 至 33B 参数，在多种模型生成的合成偏好数据集上从头训练的模型。当然，更新的替代方案肯定已经出现！

自己训练 你也可以选择训练或微调自己的 LLM 裁判。（除非你处于非常小众的领域，否则我建议避免这样做。）

如果你决定走这条路，首先需要为你感兴趣的任务收集偏好数据，这些数据可以来自：

• 现有的人类偏好数据集
• 模型生成的偏好数据（你可以参照上述小型模型裁判论文的数据部分来生成，或者直接获取，例如来自 Prometheus 的偏好和反馈数据集）

然后你需要决定是从小模型从头训练，还是基于现有模型——你可以将其蒸馏成新的更小模型，或进行量化，然后使用上述数据进行微调（如果模型较大且训练算力有限，可以使用 peft 或适配器权重）。

设计你的评测提示词

选定模型之后，你需要为你的任务确定最佳提示词。

你可以并且应该从 MixEval 或 MTBench 的提示词模板中获取灵感。

你还可以使用以下技术（可能成本更高）来提升准确性：

• 少样本示例（Few shot examples）：与许多其他任务一样，提供示例可以帮助其推理。但这会增加上下文长度。
• 参考答案：如果存在参考答案，你也可以用它来增强提示词，这会提高准确性
• CoT（思维链）：对于旧一代模型，可以提高准确性——如果你要求模型在给出分数之前输出其思维链（这里也有相关观察）
• 多轮分析（Multiturn analysis）：可以提升事实错误检测能力
• 使用评审团（jury）（多个裁判，取答案的聚合结果）：比使用单一模型效果更好。利用多个小型模型而不是一个大型昂贵模型，可以大幅降低成本。你也可以通过在不同温度下使用同一个模型进行实验
• 令人惊讶的是，社区发现在提示词中增加利害关系（正确回答就能得到一只小猫）可以提高正确性。这个效果因人而异，请根据需求自行评估。

如果你处理的是关键任务（例如医疗领域），请务必借鉴人文学科的方法论：1）计算标注者间一致性（inter-annotator agreement）指标，确保评估者尽可能无偏；2）在创建评分标准时使用规范的调查设计方法论以减少偏差。然而，大多数人并不真正需要可重现的高质量无偏评测，用凑合的提示词进行粗糙评测就够了。（这种情况完全可以接受！只是取决于相应的后果。）

评测你的评测器

在将裁判 LLM 用于生产环境或大规模使用之前，你需要评测其对你的任务的质量，以确保其分数对你真正有用。

因此，一旦你选定了裁判模型及其提示词，你需要进行以下步骤。

1. 选定基线 你需要将你的评估器判断与某个基线进行比较：可以是人工标注、你已知在该任务上质量较高的另一个裁判模型的输出、黄金真实标签（gold truth），也可以是用另一个提示词对其自身的评估，等等。

2. 选定指标 你的指标将用于将裁判的评估结果与参考答案进行比较。

总体而言，如果你的模型预测的是二元类别或进行成对比较，这种比较会容易得多——你可以计算准确率（用于成对比较）或精确率和召回率（用于二元类别），这些都是非常容易解释的指标。

将分数与人工或模型评分的相关性进行比较会更加困难。要更深入地了解原因，我建议阅读这篇精彩博客中关于该主题的相关部分。

总体而言，如果你对何时选择哪种指标（模型、指标等方面）感到困惑，你也可以参考同一博客中的这张有趣的图表 ⭐。

3. 评测你的评测器 在这一步中，你只需使用你的模型及其提示词来评测测试样本！然后，一旦获得评估结果，使用上述指标和参考答案来计算你的评测分数。

你需要决定你的接受阈值是什么。根据任务的难度，如果你进行成对比较，可以以 80% 到 95% 的准确率为目标。关于相关性（如果你使用分数），文献中的人们似乎对与参考答案达到 0.8 Pearson 相关系数感到满意。然而，我见过一些论文声称 0.3 表示与人工标注者有良好相关性（^^”），所以结果因情况而异。

技巧与诀窍

为 LLM 裁判选择正确的任务

LLM 评估器：

• 不擅长识别幻觉（hallucinations），尤其是所谓的部分幻觉（partial hallucinations，看起来与真实情况接近但实际上略有不同）（参见这篇和这篇）
• 与人工标注者在摘要（这里也是）、忠实度（faithfulness）方面的相关性较低到一般，且与一系列任务的人类判断并无一致性相关

关于奖励模型（Reward Models）

奖励模型学习从人类标注中预测给定提示词/补全对的分数。最终目标是使其预测与人类偏好保持一致。 训练完成后，这些模型可以用于改进其他模型，充当作为人类判断代理的奖励函数。

最常见的奖励模型类型是 Bradley-Terry 模型，它输出一个单一的成对分数（pairwise score），遵循以下公式：

$p(\text{completion b is better than completion a}) = \text{sigmoid}(\text{score}_b - \text{score}_a)$

该模型仅使用补全结果的成对比较进行训练，这比收集分数更容易，但只能比较同一提示词下的多个补全结果，而无法跨提示词比较补全结果。

其他模型在此基础上进行了扩展，以预测一个补全比另一个更好的更细致概率（示例）。

这理论上允许它们判断补全结果之间的细微差异，但代价是无法轻松地为同一测试集跨不同提示词保存和比较多个分数。此外，当比较过长的补全结果时，上下文长度和内存限制可能成为问题。

一些奖励模型（如 SteerLM）输出绝对分数（absolute scores），可以直接用于评估补全结果，无需成对比较。这类模型更易于用于评测，但收集训练数据也更困难，因为绝对分数在人类偏好中往往不如成对分数稳定。

最近，有模型被提出可以同时输出绝对和相对分数，如 HelpSteer2-Preference 和 ArmoRM。

约束模型输出

在很多情况下，我们可能希望模型输出遵循非常特定格式的预测，以简化评测。

使用提示词

最简单的方法是添加一个包含非常具体指令的任务提示词（以数字形式提供数值答案。、不要使用缩写。等）。

这种方法不一定每次都有效，但对于高能力模型应该足够了。例如，这就是我们在 GAIA 论文中采用的方法。

少样本学习与上下文学习

下一种方法是通过”上下文学习（in context learning）“来约束模型。通过在提示词中提供示例（即所谓的”少样本提示，few-shot prompting”），模型会被隐式地偏向于在实际样本中遵循重复的提示词格式。

结构化文本生成

结构化文本生成（Structured text generation）约束输出遵循由语法（grammar）或正则表达式等定义的特定路径。outlines 库使用有限状态机（finite state machines，FSM）来实现这一点，非常巧妙。（其他方法也存在，例如对 JSON 生成使用交错生成（interleaved generation），但 FSM 方法是我最喜欢的。）

要更深入地了解使用结构化生成时发生了什么，你可以查看我们合作撰写的博客：结构化生成减少了评测中的提示词方差，使结果和排名更加稳定。你也可以查看 outlines 的整体博客，了解与结构化生成相关的有趣实现和观察。

然而，最近的一些研究似乎表明，结构化生成可能会在某些任务（如推理）上降低模型性能，因为它将先验分布推得离预期概率分布太远。

评测中被遗忘的方面

统计有效性

在报告评测结果时，除了点估计之外，还必须包含置信区间（confidence intervals）。

这些来自原始分数的置信区间可以通过标准差或自助法（bootstrapping）获得——对于自动化指标，这相对简单；对于模型裁判，最近的一篇论文建议使用估计器进行偏差校正。对于基于人工的评测，你应该报告一致性（agreement）。

你也可以通过提示词变体来计算这些区间——以稍微不同的方式提问相同的问题，或在相同样本上使用不同的提示词格式重新运行。

成本与效率

在设计和报告评测结果时，我们需要开始共同报告模型运行成本的相关结果！一个需要 10 分钟思考和 1 万个 token 才能回答 10 + 1（因为它决定对二进制与十进制算术进行长篇大论）的推理模型，比一个用寥寥数个 token 直接回答 30 的小模型效率低得多。

我们建议报告以下内容：

• Token 消耗量：报告评测期间使用的输出 token 总数。这对于估计效率尤为重要，并会影响模型裁判评测的成本。Token 数量直接影响货币成本，并帮助其他人估算计算需求。货币成本也可以作为效率的一个良好代理指标。

• 时间：记录模型完成评测所需的推理时间。这包括实际推理时间和 API 速率限制产生的额外开销。这对于任何时间敏感的应用尤为重要（例如某些 Agent 工具使用场景，如 GAIA2）。

最后同样重要的是，随着地球上可用资源的整体状况日益严峻，报告你所运行模型的环境足迹变得越来越重要。这包括训练产生的碳排放和推理时的能耗，这些指标将取决于模型大小、硬件（如果已知）和生成的 token 数量。一些更小或量化后的模型在性能与能耗比方面达到了非常有趣的水平。

结语

评测既是一门艺术，也是一门科学。我们探索了2025年LLM评测的全貌——从理解为什么要评测模型、tokenization（分词）和推理的基本原理，到如何在不断演进的 benchmark 生态系统中找到方向，最终到为你自己的使用场景创建评测。

希望你能记住以下几点核心内容：

批判性地思考你在衡量什么。 评测是对能力的近似度量，因此在某个 benchmark 上获得高分并不能保证现实世界中的性能。不同的评测方式（自动指标、人工裁判或模型裁判）各有其固有的偏差、局限性和权衡取舍。

让你的评测与你的目标相匹配。 你是在训练过程中进行消融实验（ablation）吗？请使用快速、可靠、即便在小模型上也有强信号的 benchmark。在对最终模型进行比较和筛选吗？重点关注更难、未被污染的数据集，以测试整体能力。为特定场景构建产品吗？创建能反映你的实际问题和数据的自定义评测。

可复现性需要对细节保持高度关注。 提示（prompt）、tokenization（分词）、归一化（normalization）、模板（template）或随机种子（random seed）的细微差异，都可能导致分数相差几个百分点。在报告结果时，请对你的方法论保持透明。在尝试复现结果时，要预期即使你试图控制每一个变量，精确复现也会极为困难。

优先选择可解释的评测方法。 在可能的情况下，应优先选择功能性测试（functional testing）和基于规则的验证器（rule-based verifiers），而非模型裁判（model judge）。可以被理解和调试的评测能提供更清晰、更具可操作性的洞见……而且你的评测越可解释，你就越能改进你的模型！

评测永无止境。 随着模型的进步，benchmark 会趋于饱和（saturate）。随着训练数据的增长，数据污染（contamination）变得更加可能。随着使用场景的演变，新的能力需要被衡量。评测是一场持续的攻防战！

最后：我们构建的模型，其好坏取决于我们衡量重要事项的能力。感谢阅读！

致谢

衷心感谢所有直接或间接为本文做出贡献的人，特别是 Hynek Kydlicek、Loubna Ben Allal、Sander Land 和 Nathan Habib。