Lecture 12：评估

“好”的多种定义#

一个模型”好不好”并没有唯一正确的答案，不同视角给出截然不同的判断标准：

• Benchmark 得分：Artificial Analysis 网站已成为衡量模型”智能程度”的事实标准。它汇聚了多个数据集的综合评分，形成从 GPT-5.5 到各类小模型的排名。
• 得分 + 成本效率：Intelligence index 与推理成本（inference cost）之间存在正相关关系——花得越多，智能指数越高——但并非完全对齐。在推理成本的约束下评估模型，是一种更实用的视角。
• 用户偏好：Arena AI（前身为 Chatbot Arena）通过让用户直接比较两个匿名模型的输出来形成排名。这代表了一种”人们更喜欢哪个模型”的评估路径。
• 市场使用量：OpenRouter 作为多模型的统一调用入口，公开发布各模型的使用统计数据。“我不知道什么是好，但如果人们愿意为它付费，那它大概就是好的”——这是一种经济学视角。

这些定义彼此并不矛盾，但也不完全一致。评估方法的选择，本质上反映了”你认为什么才是好模型”的价值判断。

Perplexity Is All You Need?#

这个观点听起来有些激进，但它确实驱动了大量语言建模研究。论证逻辑如下：假设存在某个真实分布 $T$，模型 $P$ 所能获得的最优 perplexity 等于 $T$ 的熵（entropy），且唯一极小值点正是 $P = T$。换言之，持续降低 perplexity 等价于逼近真实分布。一旦获得真实分布，便可以对任意问题做条件生成：condition on a problem, generate a solution; condition on a question, generate the answer。按照这套逻辑，perplexity 下降到极致就是 AGI——这正是过去许多年里驱动研究者不断 scaling 语言模型的信念基础，尤其在 GPT-3 出现之前，语言模型的潜力尚不明朗的时期。

范式转换：从 In-Distribution 到 Out-of-Distribution#

在 2010 年代的经典范式中，语言建模研究采用 in-distribution 评估：在 Penn Treebank、WikiText-103、One Billion Word Benchmark 等标准数据集上，训练集和测试集来自同一分布。2016 年 Jozefowicz et al. 的工作展示了 CNN+LSTM 在 One Billion Word Benchmark 上的巨大 perplexity 降幅，是首个确凿证明纯神经网络方法远超 n-gram 和混合模型的结果。

GPT-2（2019）改变了这一范式。 OpenAI 在 WebText（40 GB 来自 Reddit 链接的网页文本）上训练，但评估方式与众不同：零样本地在标准数据集上测试。这是 out-of-distribution evaluation——模型并未在 Penn Treebank 或 WikiText 上训练，却在这些数据集上展现了竞争力。例如，1.5B 参数的 GPT-2 在 PTB 上达到 35 的 perplexity，优于当时 in-distribution SOTA 的 46。但值得注意的是，在拥有充足 in-distribution 训练数据的大规模数据集（如 One Billion Word Benchmark）上，零样本的 GPT-2 并未超过 SOTA——当 in-distribution 数据量足够时，out-of-distribution 迁移的优势并不明显。此外，是否存在训练集泄漏也值得怀疑，因为不确定 OpenAI 是否做了严格的 train-test decontamination。这一评估范式在当时被视为新颖的尝试，而今天已成为常规操作。

Perplexity 的局限：不是所有 Token 同等重要#

考虑句子 “Stanford was founded in 1885”——perplexity 对所有 token 一视同仁地计算预测损失。预测 “1885” 的能力确实有意义（这本质上是一个 Q&A 问题，以句子补全的形式呈现，考察世界知识），但预测句首词或 “founded” 这类高可预测性 token 的意义就小得多。Perplexity 不做区分，对偏离真实分布的每一个 bit 都计入惩罚。

条件 perplexity 是一种部分缓解方案：给定一段 prompt，只度量后续 response 部分的 perplexity，从而将注意力聚焦在你认为有意义的 token 上。

Perplexity 的伪装#

许多 benchmark 表面上以 accuracy 衡量，实质上是 perplexity 的变体：

• LAMBADA（2016）：fill-in-the-blank 任务。给定一段长上下文和一个句子如 “Do you honestly think I will want you to have a ___“，模型需要预测缺失的词。虽然以 accuracy 度量，但本质上是 next-token prediction。关键在于，这些空白位置被精心挑选为必须依赖长距离上下文才能解析的 token——这正是早期 GPT 系列论文关注的焦点，他们认为长上下文建模是通向推理能力的关键。
• HellaSwag：给定一段场景描述（“A woman is outside with a bucket and a dog. The dog is running around. She ___”），从多个候选中选出最佳续写。形式上是多选题，本质上仍是 perplexity——哪个续写被模型赋予最高概率。

Perplexity Leaderboard 的信任问题#

如果要建立一个 perplexity 排行榜，参赛者提交模型，你计算其在测试集上的 log probability。这里存在信任问题：你需要信任对方返回的 logprob 确实来自一个合法的归一化分布（概率之和为 1）。否则，一个恒定返回 $\log P = 0$（即概率 = 1）的”模型”将获得完美的 perplexity 分数，但显然这不是有效的分布。对于自回归模型，这尚可检验；但对于 VAE 等只能计算 bound 的模型，你还需要信任其数学推导是正确的。相比之下，下游任务的评估要简单得多：给 prompt、取 response、算 accuracy，无需触及内部分布。

小结#

Perplexity 至今在语言模型开发中被大量使用。它作为 scaling laws 的度量尤其合适，因为它随规模平滑变化。但如果你不是 perplexity 的信徒，那就需要更具体的 benchmark 来说服别人你的模型是好的。

MMLU：大规模多任务语言理解#

MMLU（Massive Multitask Language Understanding, Hendrycks et al., 2020）是考试型 benchmark 的奠基之作。尽管名称中包含 “Language Understanding”，它实际测试的是知识和推理而非纯语言理解。设计团队组织学生从互联网各种来源搜集题目，覆盖 57 个学科领域。

评估方式采用 few-shot prompting：构造一个 prompt，包含学科说明（“The following are questions about high school mathematics”）、若干 in-context 示例（问题-答案对），然后模型预测最终问题的答案。在 2020 年（GPT-3 时代），这种做法相当激进——构造如此复杂的 prompt 并期望语言模型给出合理回答，在当时并非常识。

最初，小模型的表现仅略高于随机水平（四选一，chance = 25%），而 GPT-3 则明显超越 chance。此后数年，MMLU 经历了完全饱和：从 GPT-3.5 Turbo 到 GPT-4，再到如今 90+ 的准确率，这个 benchmark 已无法区分前沿模型。

MMLU-Pro：修补与加难#

2024 年前后，MMLU 进入”太简单”的阶段。MMLU-Pro 做了几项改进：清理噪声和无意义的题目，将选项从 4 个扩展到 10 个，并适配了 chain-of-thought 推理（GPT-3 时代 CoT 尚未成为标准做法）。效果立竿见影：模型准确率从 90+ 回落到 33%。但截至目前，MMLU-Pro 又攀升至近 90%。

GPQA：Google-Proof QA#

GPQA（Google-Proof QA）的设计理念是：如果一个问题能通过 Google 搜索解决，那它对语言模型来说可能太简单了——因为语言模型本身就是在互联网上训练的。因此，他们专门收集了 PhD 级别的高难度问题。

质量控制流程非常严格：61 位 PhD 合同工（来自 Upwork）撰写问题 → 专家验证并反馈 → 出题者修改 → 另一位专家审核。之后，问题被交给非专家（配备 Google 搜索权限） 尝试作答。子集 DIAMOND set 的筛选标准更严格：两位领域专家必须同时达成一致答案，且至少一位非专家（带 Google 搜索权限）也能正确作答——只有同时满足这两个条件的题目才进入 DIAMOND 集。

这套流程的结果：PhD 专家的正确率仅 65%（四选一），非专家（带 Google）也仅略高于 chance。GPT-4 初始表现为 39%。截至 2026 年，GPQA 准确率已达 94%。

Humanity’s Last Exam：终极难度尝试#

Humanity’s Last Exam（2025）的态度很明确：既然模型越来越强，就要倾尽全力制造足够难的考试。它是多模态的、多学科的、兼具多选和简答题型。

征集方式采用众包：用金钱激励出题（吸引看重报酬的人）和论文署名激励（吸引看重学术声誉的人），经过多轮筛选并用前沿模型过滤。为应对 data contamination，他们保留了一个未公开发布的私有测试集——但这也意味着需要信任 API 提供者不会将评估 prompt 纳入训练数据。

初始发布时，前沿模型的准确率均在个位数。截至 2026 年，最强模型（Mythos）也仅达到 64.7%——确实是一个持久的高难度 benchmark。

Data Contamination：一个挥之不去的问题#

一个始终存在的疑问：这些测试题是否出现在了模型的训练集中？短答案是”我们不知道，因为我们不知道训练集里有什么”。Contamination 的形式往往比”直接在测试集上训练”更微妙：题目可能源自其他来源，而这些来源可能被训练集覆盖了。因此，所有 benchmark 数字都应保持一定的审慎。

考试型 Benchmark 的反复循环与核心局限#

回顾整条线索，可以看到一个清晰的模式：benchmark 饱和 → 制造更难的 benchmark → 再次饱和 → 再次加难。多选题格式之所以长盛不衰，并不是因为”简单”——多选题可以做得任意难——而是因为它限制了可以提问的问题类型。

考试型 benchmark 的根本局限在于：它不反映真实使用场景。没有人在日常使用中向语言模型提出 HLE 式的问题。人们的实际查询是开放式的、不一定有标准答案的、甚至可能表述不清的——这些特征都无法被考试型 benchmark 捕获。

Chatbot Arena / Arena AI：众包 pairwise comparison + ELO 排名#

Chatbot Arena（现更名为 Arena AI）的设计相当巧妙。它搭建了一个公开网站，任何人都可以免费使用语言模型进行对话。与普通 chat 不同的是，用户同时收到来自两个匿名模型的回复，然后选择：A 更好 / 两者都好 / 两者都差 / B 更好。

这些 pairwise comparison 数据被用来拟合 ELO 排名模型。具体来说，定义模型 A 胜过模型 B 的概率为 ELO 分差的 sigmoid 函数：

$P(A > B) = \sigma(R_A - R_B)$

其中 $R_A, R_B$ 是各模型的 ELO 评分。通过最大化所有 pairwise comparison 的似然来拟合这些评分，最终得到每个模型的全局排名。

优势：

• 真实世界 prompt：用户来网站是为了免费使用语言模型解决实际问题，因此 prompt 具有一定的真实性。
• 稀疏采样仍有效：ELO 系统的优美之处在于，不需要每对模型都直接比较——只要比较图是连通的，就能推导出全局排名。这对于人工评估至关重要，因为不可能让每个用户评价所有模型。
• 增量更新：新 prompt 和新模型可以自然地加入系统，排名随时间持续更新。

问题与偏差：

• 用户群体偏差：“网上随机一个人”的分布是未知的，“网上随机一个愿意来 Arena 的人”的分布更加未知。人口统计数据无法完全解释行为差异。可能存在 spammer、试图为自家模型刷分的人等。
• Style vs Correctness 混淆：二元偏好（“哪个更好”）将风格和正确性混为一谈。ELO 用于国际象棋天经地义——胜负分明；但”哪个回答更好”远没有那么清晰。
• 评判能力限制：用户通常因为不知道答案才去提问，如果收到两个不同的回答，他们如何判断哪个正确？
• Sycophancy 风险：讨好式回答（更令人愉悦但不一定正确）可能在评分中被系统性地高估。

AlpacaEval：LLM-as-Judge 范式#

AlpacaEval（2023）采用了不同的路线：从多个来源收集指令（instruction），用一个基准模型（如 GPT-4 Preview）生成参考回答，再用另一个 LLM（同样是 GPT-4 Preview）作为 judge，判断待评模型的回答是否优于参考——这就是 LLM-as-judge。

这立即引出潜在偏差的问题：judge 模型可能偏好特定风格。更严重的问题在早期版本中暴露：LLM judge 系统性偏好更长的回答。这导致了排行榜被 gaming——大量经过 fine-tuning 的模型仅凭更长的输出就获得了高分。后续版本用一个简单的回归方法对 length bias 做了 de-biasing 修正。

AlpacaEval 与 Chatbot Arena 的相关系数达到 0.98，意味着如果你不想等待人工评估或不想公开模型，可以用 AlpacaEval 作为代理。但需注意，这个高相关是基于特定模型集合计算的，对于显著强于 GPT-4 Preview 的模型未必成立。

WildBench：Checklist 驱动的评估#

WildBench 结合了 Chatbot Arena 的”真实 prompt”（从人类-chatbot 对话中收集查询）和 AlpacaEval 的”LLM-as-judge”。其核心创新在于引入了 checklist / rubric：针对每个具体 prompt 或任务生成一份评估清单。

这样做的动机是：如果只笼统地问 LLM “这个回答好不好”，这个判断任务本身就定义不清（good according to what?）。通过 checklist 将评估任务具体化和限定化，可以显著提升评估的可靠性和一致性。

如何评估一个”度量指标”本身？#

这是一个递归问题：我们一直在讨论如何用指标评估模型，但如果要提出一个新指标，如何知道这个指标本身是好的？

没有终极答案。一种 sanity check 的做法是计算新指标与已有指标（如 Chatbot Arena）的相关性。相关性高意味着新指标能近似替代旧指标——但这本身也有循环性：“Chatbot Arena 真的是 ground truth 吗？“至少，如果多个独立指标指向一致的结论，我们对结论的可信度会提升。

开放式评估的核心原则#

• Pairwise comparison 优于绝对评分：对于相似的回答，“A 比 B 好一点”这种方向性信号比”A 是 7 分还是 8 分”要可靠得多。
• 始终警惕偏差：无论是人类还是 LLM judge，都有各自的偏差模式。使用多个不同的 judge 并 ensemble 是缓解手段。
• Rubric / Checklist 提升 well-definedness：众包标注的经验告诉我们，如果不给标注者提供评分标准，结果会非常混乱。这对 LLM judge 同样适用。
• 开放式评估本质上 ill-defined：目前没有完美解决方案，只有在各个维度上做权衡的不同策略。

SWE-bench：代码修复的标准测试场#

SWE-bench 是 agentic benchmark 中最具代表性的一个。任务定义极其清晰：给定一个代码库和一段 GitHub issue 描述，提交一个 PR（patch）。评估标准同样清晰：patch 是否通过单元测试——在提交前某些测试失败，提交后这些测试通过，且不破坏其他测试。

这种”通过/不通过”的评估方式直截了当，是 agentic benchmark 的优势所在。原始 SWE-bench 因部分任务和测试不够严格而推出了 SWE-bench Verified（经过人工审核的子集）。2024 年初 SWE-bench Verified 上的最佳成绩约 16%，截至 2026 年已攀升至 93%（Mythos）。

Terminal-Bench：通用终端任务#

Terminal-Bench 将评估环境设定为计算机终端——一个简单且通用的交互接口。93 位贡献者众包了 89 个任务（Terminal-Bench 2.0），任务难度跨度很大：专家约需 1 小时，初级人员可能超过一周。这些任务不限于代码编写，涵盖终端中可完成的各类操作。

排行榜显示一个重要现象：使用同一底层模型但不同 agent scaffold 的系统，准确率存在显著差异。这说明 scaffold 的设计质量对最终性能影响巨大。

CyBench：网络安全 CTF#

CyBench 包含 40 个 Capture The Flag 任务。Agent 被放入一个包含 web 服务器的环境中，可以查看源代码、访问服务器、执行各种命令，目标是找到隐藏的 flag 字符串以证明成功入侵。

早期版本使用一个极简的 agent scaffold：单一连续记忆缓冲区，产生 action → 获取环境反馈 → 将结果拼接到 buffer → 循环。这个 buffer 会不断增长，需要更好的上下文管理策略。CyBench 发布时最佳模型约 10%，目前已完全被解决。

MLE-bench：Kaggle 竞赛#

MLE-bench 汇集了一批 Kaggle 竞赛任务，涉及数据处理、模型训练等完整 ML 工程流程。Agent 可以查看数据集、阅读描述、编写代码、训练模型并最终提交。排行榜同样显示 LLM 层面是”常见嫌疑人”（前沿模型），但 agent scaffold 间的变异非常大。

Agent Scaffold 的关键设计要素#

解决复杂任务的 agent 需要远超”流式意识 + chain of thought”的架构。几个被证明有效的设计模式：

1. 显式规划（Explicit Planning）：维护一个 to-do list，逐项检查完成，而非让模型在连续上下文中自由漫游。没有显式规划的 agent 很容易在长任务中迷失方向。
2. 层级委派（Hierarchical Delegation）：主 agent 将子任务分发给 sub-agent，sub-agent 在清洁的上下文中执行，仅返回结果。主 agent 不需要看到所有细节，这提供了一种封装机制。
3. 显式记忆（Memory）：当上下文窗口不够用时，通过显式地读写文件来管理持久信息。
4. 上下文工程（Context Engineering）：管理整个交互流程的元策略——何时委派 sub-agent、何时切换策略、何时写入持久记忆。这些通常需要针对特定语言模型做优化。

评估的是什么？#

Agent 评估与纯语言模型评估有本质区别：你评估的是模型 + scaffold 的整体系统，而非单独的语言模型能力。同一个模型在不同 scaffold 下可以表现出截然不同的性能。这使得 agent benchmark 的结果解读更加复杂——好成绩是因为模型强，还是因为 scaffold 设计精妙？

ARC-AGI：专为挑战 AI 而设计#

ARC-AGI 项目始于 2019 年（GPT-2 时代，pre-LLM），其设计哲学极具前瞻性：

• 100% 人类可解：每个任务对人类来说应该在合理时间内可解
• 每个任务都是独特的：记忆大量事实或解过的题不应该有帮助
• 不依赖语言或世界知识：纯粹基于视觉模式识别和推理

ARC-AGI-1 的任务形式是：给定若干输入-输出图案对作为示例，推断规则并生成新的输出。例如，给定几组带有黄色缺口的矩形及其完整版本，推断规则是”填充黄色以形成完整矩形”。对人类来说，10 秒内就能看出规律。

ARC-AGI-2（2025 年 3 月）提升了复杂度，引入了更多多步推理要求（见图1）。

从”完全不行”到”接近解决”：Reasoning Model 的突破#

ARC-AGI 的历史轨迹堪称戏剧性。当 ARC-AGI-1 发布时，GPT-3 等预训练模型完全无法推动指针——正如设计者所预期的，预训练模型只是学到了互联网上的事实和语言模式，这些对 ARC-AGI 任务并无直接帮助。

转折发生在 2024 年。OpenAI 发布 o1 和 o3 系列 reasoning model 后，分数骤然飙升。ARC-AGI-1 很快被基本解决。即便 ARC-AGI-2 也在发布后不久就显示出即将被攻克的趋势。

这个结果说明：真正解锁 ARC-AGI 的是推理能力（reasoning capabilities），而非知识量。当然，如果没有大规模预训练作为基础，reasoning model 也不会出现——所以预训练的贡献虽然不直接体现在 ARC-AGI 分数上，但在整个技术栈中不可或缺。

ARC-AGI-3：交互式环境#

2026 年 3 月，ARC-AGI-3 面世——又一轮”旧 benchmark 饱和，制造新 benchmark”的循环。这次的创新是转为交互式环境：用户（或 agent）可以在线玩一个游戏，通过操作来探索规律，而非仅仅静态地观察输入输出对。任务依然不涉及语言，纯粹基于空间模式推理。

当前分数极低——最强模型 Opus 4.6 (Max) 仅 0.50%，GPT-5.4 (High) 仅 0.20%（见图2）。

纯推理评估的固有张力#

ARC-AGI 系列在”分离推理与知识”这一目标上可能是最好的尝试，但存在几个固有局限：

• 是否真正解耦？ 任务虽然不依赖语言知识，但仍源自某种先验分布。如果研究者真的重视这个 benchmark，他们大概率能专门优化它——正如对其他 benchmark 所做的那样。
• 人类推理天花板：设计目标要求 100% 人类可解（在合理时间内），这意味着它不涵盖超人类推理——例如 IMO 金牌级别的数学问题或开放性数学难题，而这些能力同样重要。
• 输入表示的挑战：ARC-AGI-3 的网格（约 64×64）可以作为图像输入，也可以用 ASCII art 或文本表示。无论哪种方式，模型都需要处理空间关系——这与自然语言处理有根本区别。

HarmBench：拒绝有害指令#

HarmBench 代表了最直觉的安全测试路径：用有害 prompt 探测模型，期望模型拒绝回应。这是多数人想到”AI 安全”时的第一反应——阻止恶意用户利用语言模型做坏事。

AIR-Bench：跨监管框架的安全分类法#

AIR-Bench 试图更系统地思考安全问题。它综合了欧盟、中国、美国的监管框架以及各公司的使用政策，构建了一个关于”什么可能出错”的分类体系（taxonomy），然后基于此设计 prompt 和评估流程。这是一种自上而下的方法——先定义安全的范畴，再构建评估。

Jailbreaking：自动化的安全绕过#

语言模型通常被训练为拒绝有害指令，但这种防线可以被巧妙绕过。GCG（Greedy Coordinate Gradient）是早期的自动化攻击方法，通过坐标级优化来搜索能绕过安全限制的 prompt 后缀。一个关键发现是：在开源模型上优化得到的攻击 prompt 能够迁移到闭源模型。例如，生成的基本上是无意义的文本附加在 “step by step plan to destroy humanity” 之后，竟能让 OpenAI 的模型配合执行。

当然可以争辩：模型输出的”毁灭人类计划”真的有害吗？但至少，模型在这种情况下的预期行为应该是拒绝。

安全是一个多维问题#

安全远不止”阻止坏人”这一个维度。其复杂性体现在多个层面：

上下文依赖性：安全涉及政治、法律、社会规范，这些在不同国家之间存在巨大差异。一个在美国合规的回答在中国可能违规，反之亦然。

风险的多样性：

• 幻觉（Hallucination）：在医疗、法律、金融场景中，事实性错误可能造成实际伤害。但幻觉与能力相关——模型越准确，幻觉越少，因此提升能力本身就在缓解这个风险。
• 谄媚（Sycophancy）：模型倾向于讨好用户而非给出诚实的回答。
• 犯罪协助（Abetting Crimes）：这个风险可能与能力提升呈反方向——模型越强，潜在的协助能力也越强。
• 批判性思维丧失（Losing Critical Thinking）：过度依赖 AI 可能削弱人类自身的判断能力。这同样与能力正相关。

Dual-use 问题：网络安全 agent 可以用来入侵系统，也可以用来做渗透测试以增强系统安全。这使得同一能力既是风险也是收益——一把双刃剑，使得”这是否属于安全风险”的判断变得模糊。

生态效度：评估是否反映真实使用？#

Ecological validity（生态效度）问的是：评估在多大程度上捕获了现实世界的使用模式？考试型 benchmark 离真实使用很远；Chatbot Arena 来自真实用户，但用户群体分布是否有代表性值得怀疑。

GDPVal（OpenAI）试图从行业覆盖度切入：按美国 GDP 排名前 9 的行业、44 个职业，由平均 14 年经验的专业人员创建任务。覆盖了护士、酒店前台、房产经纪、影视编辑等多种角色——这些职业代表了 AI 的真实潜在用户群。

医疗领域此前的 benchmark 多基于标准化考试。但通过考试不等于能行医（即便人类也需要漫长的实习期）。一个包含 121 个任务、来自 29 位临床医生的项目专门收集了临床医生实际会向语言模型提出的问题，这些问题与多选考试有根本差异。

真实查询分析：谁拥有最真实的使用数据？模型开发者。Anthropic 的一个项目用语言模型自身来分析真实用户查询（出于隐私，人类不能直接查看用户数据，但可以让语言模型做聚合分析），从而了解人们实际用 Claude 做什么。这种方法的局限是真实性与隐私之间的矛盾——理想情况下你想直接分析真实查询流，但隐私保护限制了这一点。

Data Contamination：四条应对路径#

Train-test contamination 在基础模型时代变得格外棘手。传统 ML 有清晰的 train/test split；现在模型在整个互联网上训练，你甚至不知道训练集里有什么。

路径 1：推断检测。一种巧妙的方法利用了这样的事实：benchmark 中题目的排列顺序本应是随机的。如果模型对某个特定顺序表现出偏好（且该顺序与 benchmark 一致），则强烈暗示模型在该 benchmark 上训练过。

路径 2：规范倡导。借鉴统计学的传统——你有一个估计值，就应该报告其可靠性（置信区间）。类似地，如果模型开发者宣称某个 GPQA 分数，就应该提供他们没有在测试集上训练过的证据。这是一种社区规范层面的解决方案。

路径 3：Fresh Evals。LiveCodeBench、UncheatableEval 等项目持续从新的网页、arXiv 论文、GitHub 仓库中采集数据，定义发布时间晚于模型训练截止日期的评估集。这在概念上很稳健，但也有隐患：一个新发布到 GitHub 的项目可能是从旧仓库 fork 或衍生的，时间戳并不能完全保证内容的”新鲜度”。

路径 4：私有评估。模型开发公司（Google、OpenAI 等）使用内部代码库作为评估集——这些数据显然不在互联网上，也不会被有意纳入训练。对于非企业用户，可以使用个人未发表的写作（“我读研时被拒的论文，从未放到网上”）。这条路径对 perplexity 评估尤其友好——只需要一个好的数据集就能计算 log probability。

Dataset Quality：不可忽视的基础问题#

SWE-bench 推出 Verified 版本是因为原始版本中的部分任务和单元测试不够严格。这不是个例：

• GSM8K 和 MMLU 都经历了人工审核后的修正——原始数据集中有损坏的题目，例如”引用了一条曲线但文本中没有提供该曲线”、“问婴儿是否穿了袜子但图中无法判断”。
• Agent benchmark 的双重问题：一方面，测试用例可能不完整——通过全部测试用例并不等于有一个正确的解决方案（这与多选题的质量问题性质不同，因为 agent 任务的正确性验证本身就更复杂）。另一方面，存在 trivial baseline 问题：TorchBench 中，一个空输出（什么都不做）就能获得 38% 的分数，这意味着 benchmark 中大量任务可以被 trivially 通过，严重扭曲了分数的含义。
• Docent 工具：使用语言模型检查 agent 的执行轨迹（traces），从定性角度检测问题——这是对高度定量化的 benchmark 文化的有益补充。

一个普适的建议：无论是开发 benchmark 还是在 benchmark 上评测模型，都应该看模型的实际输出并人工审核，确认你度量的确实是你以为在度量的东西。

评估的目的：不同角色，不同需求#

不存在”一个评估统治所有”的方案。设计或选择评估时，必须明确目的：

• 用户/企业：做采购决策——在特定用例下，模型 A 和模型 B 哪个更好？需要高 ecological validity。
• 研究者：度量某种直觉性的”智能”概念。可以接受较低的生态效度，但需要高难度和区分度。
• 政策制定者：理解 AI 的收益和风险。需要安全和社会影响维度的评估。
• 模型开发者：获取改进模型的反馈信号。需要细粒度、可解释的评估指标。

我们在评估什么？方法 vs 模型#

基础模型出现之前，研究者评估的是方法（method）——因为 train/test split 是标准化的，唯一变化的是算法。今天，我们主要评估模型和系统（model + system）——训练数据、模型架构、后训练、scaffold 全部打包在一起，“anything goes”。少数例外如 NanoGPT speedrun 是在刻意评估训练算法本身。

评估模型/系统是有价值的——这是最终被部署和使用的东西。但这也意味着 benchmark 分数的归因变得困难：分数提升是因为模型更好、数据更好、还是 scaffold 更好？

全局回顾#

Perplexity、考试、对话、Agent、推理、安全——这些评估维度在难度、生态效度、科学有效性之间各有取舍。很难同时获得高度真实、足够困难、无 contamination 的评估。取决于你的目标，你必须选择在哪个维度上做出妥协。在做评估之前，先想清楚你的目的。