CS336 · 从零构建语言模型

Lecture 12 · 评估

CS336: Language Modeling from Scratch · Stanford · Spring 2025
📅 May 8 · 💻 可执行讲义 · 讲者 Percy Liang

承上启下

上一讲（Lecture 11 · 缩放定律 II：细节）：学会了用 scaling law 和小规模实验规划大模型训练——但那套方法优化的目标是 loss。训练出一个模型之后，还要回答一个更根本的问题：它到底好不好？「好」由谁定义、怎么测量？

与 Lecture 10 · 推理的关联：评估本身就是一个大规模推理 workload——跑一遍完整 benchmark 是成千上万次模型调用，test-time compute（长思维链）更让单题成本涨一个数量级。推理效率决定了评估的成本预算，而评估的调用方式（是否允许 CoT、采样多少次）反过来是推理成本的主要变量。

本讲（评估，evaluation）：评估不是机械地跑 benchmark，而是把一个抽象目标（「模型好不好」）翻译成一套具体的游戏规则。不同人评估模型的目的不同——用户做购买决策、研究者测原始能力、监管者估安全风险、开发者要训练反馈——目的不同，正确的评估就不同。指标、输入分布、调用方式、成本、真实性、数据污染，每一项都会改变结论。

摘要

没有「唯一正确的评估」。评估必须先问目的，再依次定义输入、调用方式、输出判分和结果解释。Perplexity 平滑通用但不等于有用；benchmark 可比较但容易失真；真实流量有价值但有隐私与混杂因素；安全评估更是能力（capability）与倾向（propensity）的混合体。

1. 如何思考评估

先看动机：为什么不能「一个排行榜打天下」？因为评估至少服务四种不同的目的——

购买决策：某公司想选一个模型做客服，它关心的是自家场景下的表现，不是 MMLU；
测量原始能力：研究者想知道模型「智力」的边界，关心难题上限；
理解收益与危害：监管者/社会关心模型会不会被滥用、幻觉率多高；
开发反馈：训练团队要一个能高频迭代、灵敏反映改动的信号。

无论哪种目的，一次评估都要回答四个问题：

输入是什么？
- 覆盖哪些 use cases？分布是否代表真实用户？
- 有没有长尾困难样本，还是全是「平均难度」？
- 是否适配模型真实的交互形式（多轮对话、工具调用、RAG）？
怎么调用模型？
- zero-shot 还是 few-shot？prompt 模板是什么（模型对格式极其敏感）？
- 是否允许 chain-of-thought？是否允许工具？采样多少次？
- 评估的对象到底是 base model、chat model，还是整个 agent 系统？
怎么评价输出？
- 有无标准答案？标准答案本身可靠吗？
- 指标选什么：accuracy、pass@k、win rate，还是 cost-adjusted score（把推理成本折进去）？
- 错误是否对称？医疗场景里「漏诊」和「误诊」的代价天差地别，一个 accuracy 数字掩盖了这种不对称；
- 开放式回答（写作、对话）没有唯一答案，靠人判还是靠模型判？
怎么解释结果？
- 91% 的 accuracy 是否代表可部署？（取决于剩下 9% 错在哪、错的代价多大）
- 是否存在 train-test overlap，让分数虚高？
- 你在评估的是模型本身，还是训练方法，还是整套系统？（见第 9 节）

提示

把评估想成设计一场比赛：规则（输入 + 调用方式 + 判分）决定了什么策略会赢。规则没写清楚，选手就会针对规则的漏洞优化（刷榜、过拟合 prompt 格式），而不是针对你真正关心的能力。所以「定义游戏规则」不是官僚程序，而是评估的全部内涵——不定义游戏规则的排行榜，只是热闹，不是科学。

注意

讲义反复强调的一条实操建议：永远要亲眼看具体样例和模型的具体输出（look at individual instances and predictions）。聚合分数会掩盖判分脚本的 bug、题目本身的错误和模型「答对但格式不符」被误判的情况。

2. Perplexity：最基础但不万能

语言模型定义序列上的概率分布。对序列 $x_1, \dots, x_T$，按链式法则分解：

$$p(x_1, \dots, x_T) = \prod_{t=1}^{T} p(x_t \mid x_{

困惑度（perplexity, PPL）衡量模型对数据集 $D$（共 $\lvert D\rvert$ 个 token）的「惊讶程度」：

$$\text{PPL}(D) = p(D)^{-1/\lvert D\rvert} = \exp\!\Bigl(-\frac{1}{\lvert D\rvert}\sum_{t=1}^{\lvert D\rvert}\log p(x_t \mid x_{

即 $\text{PPL} = \exp(\text{平均交叉熵})$——它就是训练 loss 的指数，也正是 Lecture 9 · 缩放定律 I：基础中 scaling law 拟合的那个量的另一种写法。

提示

PPL 的直观含义是有效分支因子：PPL = 30 意味着模型每一步的不确定性相当于在 30 个等可能的 token 里瞎选。历史坐标：在 One Billion Word 等经典基准上，2016 年前后的 LSTM/CNN 系模型把 PPL 从 51.3 压到约 30；今天的大模型在同类语料上早已远低于此。「PPL 最大主义」（perplexity maximalist）观点认为把 PPL 压到底最终会通向 AGI——预测下一个 token 足够好就必须理解世界——即便这未必是最高效的路径。

2.1 为什么 perplexity 有用？

平滑：任务准确率是跳变的（对/错），PPL 是连续的，小的模型改进立刻反映出来，因此适合拟合 scaling laws、做训练中的监控；
通用：不依赖任何具体任务的定义，覆盖了任务准确率捕捉不到的细微差别；
与训练目标一致：优化的就是它，信号不失真；
可以测 conditional perplexity：把下游任务写成「给定 prompt 时答案的 PPL」，用它当轻量下游信号。

2.2 为什么 perplexity 不够？

低 PPL 不保证指令跟随好——base model 的 PPL 可以很低，但让它「用 JSON 回答」照样失败；这中间隔着 Lecture 15 · 对齐 I：SFT 与 RLHF 的整个后训练阶段；
不直接衡量推理、工具使用、安全等用户真正关心的能力；
需要评估者信任模型给出的概率分布：历史上有模型对罕见词输出 UNK token 来「作弊」压低 PPL；今天的闭源 API 常常根本不返回 logprobs，PPL 无从算起；
tokenizer 不同则 PPL 不可比（参见 Lecture 1 · 概览与分词）：per-token 的平均 loss 依赖分词粒度，词表大的模型每个 token「更难猜」。跨模型比较应换算成 bits-per-byte 这类与分词无关的单位；
对用户价值不直接：没有用户在乎 PPL 降了 0.1。

提示

Perplexity 是温度计，不是体检报告。它能灵敏地告诉你模型的语言建模能力是否在变好（所以训练时人人盯着它），但不能告诉你这个模型能不能当产品。评估体系需要 PPL 这样的「连续内部信号」和 benchmark 这样的「离散外部信号」互相配合。

3. 知识与考试型基准

3.1 MMLU

MMLU（Massive Multitask Language Understanding）覆盖 57 个学科（数学、美国历史、法律、伦理等），全部是四选一选择题，由研究生/本科生从公开网络资料中收集，GPT-3 时代的标准用法是 few-shot（5-shot）提示。

问题在于：题目既然来自公开资料，就很可能出现在预训练语料里（数据污染，见第 9 节）；且选择题形式更像知识考试——测的是「记没记住」，不一定是「理解」；随着模型变强，头部模型分数逼近上限，基准趋于饱和，失去区分度。

3.2 MMLU-Pro

针对 MMLU 的饱和与噪声做的改进：清洗掉有噪声/过于简单的题目；选项从 4 个扩到 10 个（瞎猜基线从 25% 掉到 10%）；用 chain-of-thought 评测。效果立竿见影——同一批模型的准确率比在原 MMLU 上下降 16~33 个百分点，基准重新获得区分度。

3.3 GPQA

GPQA（Graduate-Level Google-Proof Q&A）：由 61 位从 Upwork 招募的 PhD 级标注者编写研究生水平的科学题，并刻意做到「Google 免疫」——非专家开着 Google 花 30 分钟也只能答对 34%，而领域内 PhD 专家能到 65%，成文时的 GPT-4 是 39%。它测的是深度专业知识与推理，而非可检索的表面知识。

3.4 Humanity’s Last Exam

HLE 的定位是「考试型基准的终点」：2500 道题，多模态、多学科，选择题 + 简答混合；出题有 50 万美元奖金池加合著者署名激励；题目先用 frontier model 过滤（模型能直接答对的题不收），再经多阶段人工审查。

注意

越难的 benchmark 越贵——出题要专家、审题要流程、判分要仔细，且一旦公开就开始被污染、被过拟合。「难」和「可信」是两个独立维度：难题库若审查不严，错误答案率反而更高（专家题的标准答案也会错）。

提示

这条演化线（MMLU → MMLU-Pro → GPQA → HLE）是模型与基准的军备竞赛：模型每逼近天花板一次，社区就造一个更难、更防污染、更贵的考试。但再难的考试仍是考试（quizzing）——它测知识上限，不测真实使用价值，后者要靠第 8 节的「真实性」评估补上。

4. 指令跟随与开放式回答

考试型基准有标准答案；聊天、写作等开放式任务没有。判分只能靠「人类偏好」或「模型偏好」。

4.1 Chatbot Arena

流程：真实用户输入自己的 prompt → 两个匿名模型分别回答 → 用户投票选更好的一个 → 汇总海量 pairwise comparison，用 Bradley-Terry 模型（Elo 风格）估计每个模型的 Arena 分数。

优点：输入是活的（用户真实问题，非静态题库，难以污染）；直接测人类偏好；新模型可以随时加入比较。

缺点：投票用户不是任何特定产品用户群的代表，且分布随时间漂移；偏好受风格混杂因素影响严重——更长、格式更漂亮、更礼貌的回答更容易赢，与内容质量无关（官方后来推出 style-controlled 排名试图剥离）；只给一个总分，不适合细分能力诊断。

4.2 IFEval

IFEval（Instruction-Following Eval）的思路是绕开主观判分：给指令附加可程序化验证的约束，如「必须包含某关键词」「用 JSON 输出」「不少于 N 条」，判分只检查约束是否满足，完全自动。

优点是客观、便宜、可复现；缺点是只测了「守规矩」，回答的语义质量不在测量范围内，且约束是人工构造的，与真实指令分布有距离。

4.3 AlpacaEval / WildBench

AlpacaEval：805 条开放式指令，让被测模型与基线模型（GPT-4 Preview）分别回答，再用 GPT-4 Preview 当裁判（LLM-as-judge）判胜负，指标是 win rate。裁判和基线是同一个模型，存在明显的自我偏爱风险；后续的 length-controlled 版本对「裁判偏爱长回答」做了回归校正。

WildBench：从 100 万条真实人机对话（WildChat）中精选 1024 个任务，用 GPT-4-Turbo 当裁判，但配上逐题 checklist引导裁判先分析再打分。它与 Chatbot Arena 的相关系数高达 0.95——说明设计得当的 LLM-as-judge 可以廉价地逼近昂贵的人类投票。

注意

LLM-as-judge 便宜好用，但会系统性继承裁判模型的偏见：偏长、偏格式化（markdown、列表）、偏某些表达风格、偏自家模型。缓解手段：换多个裁判交叉验证、length-control、checklist 约束裁判的注意力、与人类投票（Arena）对齐校准。永远别忘了裁判本身也是个有偏的模型。

提示

开放式评估的三条路线各有取舍：Arena 用真人投票（最真实、最贵、最慢）、IFEval 用程序验证（最客观、覆盖面最窄）、AlpacaEval/WildBench 用模型裁判（最便宜、有偏见）。实践中三者互为校验：模型裁判的可信度就是用「与 Arena 的相关性」来论证的。

5. Agent Benchmarks

Agent = 语言模型 + 工具/环境/控制逻辑（scaffold）。评估前必须先问清楚：

是在评估模型，还是评估整个 agent scaffold？ 同一个模型换一套 scaffold（更好的检索、重试逻辑、环境提示）分数可以差出几十个点——排行榜上比的经常是 scaffold 工程，不是模型能力。

5.1 SWE-bench

任务：给模型一个真实 GitHub issue 和对应的完整代码库，让它提交一个 patch，用仓库自带的单元测试判断是否真的修好。共 2294 个任务，来自 12 个流行 Python 仓库。

优点：贴近真实软件工程，单元测试提供客观判分。难点：环境复现繁琐；不少 issue 描述本身含糊（人也修不了）；测试可能不充分（patch 错了也能过）或过严（正确的等价修法过不了）；scaffold 差异对分数影响巨大。这些质量问题催生了 SWE-bench Verified——由人工逐题审查筛出的 500 题可信子集（见第 9 节）。

5.2 CyBench

40 个来自真实 CTF（Capture the Flag）竞赛的网络安全任务，要求工具使用与多步探索。难度用首解时间（first-solve time，人类选手第一次解出该题所花的时间）客观标定。它是双重属性的典型：既是能力评估（安全从业者的渗透测试助手），也是风险评估（同样的能力可以用来攻击）——见第 7 节的 capability vs propensity。

5.3 MLE-bench

75 个 Kaggle 竞赛构成的机器学习工程基准：数据处理、模型训练、实验迭代，以竞赛奖牌线为客观标尺。它测的是长周期、多步骤的 agent 能力——一次任务可能要跑几小时的真实计算。

提示

Agent benchmark 的共同设计原则是用环境本身当裁判：单元测试、CTF 的 flag、Kaggle 的排行榜都是现成的、无法争辩的判分器。这与 Lecture 16 · 对齐 II：RLVR 的可验证奖励是同一个思想——凡是能自动验证的任务，既好评估，也好拿来做 RL 训练。

6. 纯推理与抽象任务

ARC-AGI（Abstraction and Reasoning Corpus，Chollet 2019 年随论文 On the Measure of Intelligence 提出）：每道题给几个「输入网格 → 输出网格」的变换示例，要求推断规则并应用到新输入。它刻意最小化语言与世界知识成分，只假设人类共有的核心先验（objectness、对称、计数），试图测量流体智力——从少量例子中习得新规则的效率，而不是复述训练中见过的知识。ARC-AGI-2 是更难的后继版本。

难点与争议：

prompt/scaffold 对分数影响极大——网格如何序列化成文本、允许多少次采样，都能改变结论；
视觉抽象先验对人类几乎免费，转成 token 序列后对模型未必公平；
题目数量少，统计稳定性有限，几道题的波动就能改变排名；
2024 年底 o3 用极高的 test-time compute 大幅突破 ARC-AGI-1，但单题推理成本高达数千美元——这凸显了「成本折算后的分数」（参见 Lecture 10 · 推理）应该成为一等公民指标。

提示

ARC-AGI 想把「智力」从「知识」中剥离出来：考试型基准测的是晶体智力（积累了多少），ARC 测流体智力（学新规则多快）。它未必是完美的测量，但作为「模型是否只是在检索记忆」的反例探针非常有价值。

7. 安全评估

7.1 安全不是单一指标

「安全」在实践中是一大族彼此异质的问题：有害指令的鲁棒拒绝、幻觉率、隐私泄露、网络安全滥用、生物安全滥用、政治/法律/文化敏感内容，以及医疗等高风险领域的准确性。各自的评估方法与阈值完全不同，不存在一个「安全分」。

7.2 HarmBench / AIR-Bench

HarmBench：510 种违反法律或规范的有害行为，配套标准化的自动评估框架，统一衡量各种 red-teaming 攻击方法与模型拒绝能力——在它之前，各攻击论文的评估口径互不可比。

AIR-Bench：自上而下地从 8 部政府法规和 16 家公司政策中提炼出 314 个风险类别，构造 5694 条 prompt——让安全评估对齐监管者与企业实际关心的风险分类学，而不是研究者拍脑袋的类别。

7.3 Jailbreak 与 GCG

GCG（Greedy Coordinate Gradient）展示了对齐的脆弱性：用梯度信息贪心地逐坐标优化一段对抗性后缀（adversarial suffix，通常是乱码样的 token 串），拼在有害请求后面就能让对齐过的模型绕过拒绝。更麻烦的是可迁移性：在开源权重模型（如 Llama）上优化出的后缀，直接拿去攻击 GPT-4 等闭源模型也常常奏效——攻击者不需要你的权重。

7.4 Capability vs Propensity

安全评估必须分清两个概念：

概念	含义
Capability（能力）	模型有没有能力做某件（危险的）事
Propensity（倾向）	模型会不会主动/愿意去做这件事

API 模型可以靠拒绝策略与系统级防护压低 propensity，即使 capability 存在；而开源权重模型的安全微调可以被几步 fine-tuning 轻易剥除，propensity 防线形同虚设——因此对开源权重模型，capability 本身才是需要评估的底线。

注意

CyBench 这类基准既是能力评估也是安全评估（dual-use，两用性）。写评估报告时必须说清楚你在测哪一个：测 capability 时模型拒绝回答会让分数虚低（低估风险），测 propensity 时用越狱手段逼模型回答又会让分数虚高。别装糊涂。

8. 真实性：Benchmark 离真实使用有多远？

很多 benchmark 本质是「quizzing」：出题人知道答案，只是在考模型——像考试。真实使用更像「asking」：用户自己不知道答案（否则不会问），想从系统获得真帮助——像问诊。两者的输入分布、难度构成、错误代价都不同，quizzing 上的高分不能直接外推到 asking 场景。

8.1 Clio

Anthropic 的 Clio 系统：用语言模型对真实用户对话做隐私保护的聚类与摘要（个体对话不暴露，只输出聚合后的主题分布），从而知道用户实际在问什么——结果显示编程、写作等用途占比远超 benchmark 里的题型分布。这是「用真实流量校准评估方向」的代表做法。

8.2 MedHELM

医疗评估的演化：早期医疗 benchmark 基本是执业医师资格考试题（quizzing 的极致），MedHELM 则由 29 位临床医生参与定义了 121 个真实临床任务（病历摘要、临床决策支持等），混合公开与私有数据集，让评估对准医生的真实工作流。

现实难点：真实数据涉及隐私，无法随意公开；专家标注极贵；高风险领域错误代价不对称（漏诊 ≠ 误诊）；benchmark 一旦公开就开始被爬取、被污染——真实性与可复现性存在内在张力。

提示

Benchmark 是真实需求的代理（proxy），而一切代理指标都会被 Goodhart 定律侵蚀：「当指标成为目标，它就不再是好指标」。Clio 和 MedHELM 代表了解药的方向——定期回到真实分布，重新校准代理。

9. 效度：评估是否可信？

效度（validity）：分数真的测量了你以为它在测量的东西吗？三个主要威胁：污染、数据质量、比较对象错位。

9.1 Train-Test Overlap

传统 ML 有干净的 train/test split；现代 LM 在整个互联网上训练且训练数据不公开，你无法证明测试题不在训练集里。后果：benchmark 题目（连同答案）被爬进语料，模型「背过题」，分数虚高，且无法区分泛化与记忆。

应对手段：

n-gram / 近重复检测：模型开发者自查训练集与测试集的字符串重叠（GPT 系列技术报告的做法），但只能抓字面重复，改写过的题抓不到；
黑盒污染检测：利用数据点的可交换性（exchangeability）做统计检验——如果模型对 benchmark 题目的原始排列顺序表现出偏好（logprob 显著高于打乱后的顺序），说明它在训练中见过这份数据集本身；
推动报告规范：要求模型开发者随发布报告 train-test overlap（本讲义作者 Liang 组的主张）；
动态 benchmark：持续更新题目（如 Arena 的活流量、按时间切分的 LiveBench 类基准），让「背题」失效；
private eval：保留不公开的测试集（如 ARC-AGI 的私有集），代价是外界无法审计题目质量。

9.2 Dataset Quality

Benchmark 本身也会错：题目有歧义、标准答案错误、单元测试覆盖不了真实修复、数据过时。当模型的错误率已经低于题库自身的错误率时，排行榜排名比的是「谁更会迎合错误标签」。

修复的实例：

SWE-bench Verified：对原始 SWE-bench 逐题人工审查，剔除 issue 描述不清、测试不公平的题，得到 500 题可信子集；
Platinum benchmark：对趋于饱和的经典基准（GSM8K 等）人工清洗标签错误，制作「白金版」，让顶部模型之间的差异重新可测；
通用做法：人工审查抽样、发布高质量子集、报告题目级别的错误分析。

9.3 评估模型还是方法？

前基础模型时代，研究评估的是方法（method）：固定数据 + 固定训练预算 + 固定规则，谁的算法好谁赢——可复现、可归因。

现在的排行榜大多评估的是模型/系统（model/system）：任何数据 + 任何训练 + 任何后训练 + 任意 scaffold，只看最终输出——对下游用户有用，但「分数高」无法归因于任何单一技术，也无法指导科学结论。

两种范式都合理，但不能混淆。仍在坚持「评估方法」的例子：

nanoGPT speedrun：固定训练数据与目标验证 loss，比谁的训练代码到达目标最快——纯粹比训练方法；
DataComp-LM：反过来固定训练配方，比谁的数据筛选策略在标准 pipeline 下训出的模型最好——纯粹比数据方法（与 Lecture 13 · 数据 I 直接相关）。

提示

「比方法」与「比系统」的区别，类似受控实验与产品评测的区别：前者改变一个变量、回答科学问题（哪个算法/数据更好），后者端到端比较、回答消费决策（该买哪个）。读任何排行榜前先判断它属于哪一种，否则会从产品评测中错误地得出科学结论。

总结

mindmap
  root((评估))
    Framework
      inputs
      model call
      outputs
      interpretation
    Perplexity
      smooth
      universal
      not enough
    Benchmarks
      MMLU
      GPQA
      HLE
      ARC
    Open-ended
      Chatbot Arena
      IFEval
      AlpacaEval
      WildBench
    Agents
      SWE-bench
      CyBench
      MLE-bench
    Safety
      HarmBench
      AIR-Bench
      jailbreak
      capability vs propensity
    Validity
      contamination
      dataset quality
      method vs system

关键要点：

没有唯一评估
- 评估取决于你要回答的问题：购买、测能力、估风险、要反馈，各有正确答案。四个设计维度：输入、调用方式、判分、解释。
Perplexity 重要但远远不够
- 它平滑、通用、与训练目标一致，是 scaling law 与训练监控的支柱；但它不测指令跟随与下游能力，且跨 tokenizer 不可比、依赖模型给出可信概率。
考试型基准在与模型军备竞赛
- MMLU 饱和 → MMLU-Pro 加难 → GPQA 做到 Google 免疫 → HLE 用 frontier model 过滤出题。越难越贵，且「难」不等于「可信」。
开放式评估会引入 judge 偏见
- 人类投票受风格混杂影响，LLM-as-judge 继承裁判模型的偏长/偏格式偏见；checklist、length-control 与跨裁判校验是缓解手段。
Agent benchmark 测的是系统
- scaffold、工具、执行环境都会大幅改变分数；好在环境本身（单元测试、flag、奖牌线）可以充当客观裁判。
安全评估要区分能力与倾向
- API 模型靠拒绝策略压 propensity；开源权重模型的安全微调可被轻易剥除，必须直接评估 capability。GCG 说明越狱可跨模型迁移。
效度是硬问题
- 污染让分数虚高（n-gram 检测、黑盒检测、报告规范、动态/私有题库应对），benchmark 自身的标签错误需要 Verified/Platinum 式清洗，「比方法」与「比系统」不能混为一谈。

下一讲预告（Lecture 13 · 数据 I）：

评估告诉我们模型哪里强弱；下一讲回到源头：预训练数据从哪里来，为什么开源模型最不愿公开的就是数据，Common Crawl、C4、The Pile、Dolma、DCLM 等数据集如何演进。

复习自测

题目

$\text{PPL} = \exp\bigl(-\frac{1}{\lvert D\rvert}\sum_t \log p(x_t \mid x_{

题目

不能。(1) 可能有 train-test overlap，分数含记忆成分；(2) MMLU 是四选一知识考试（quizzing），与产品的真实输入分布（asking）不同；(3) 聚合分数掩盖了错误的位置与代价——剩下 9% 若集中在你的关键场景或高代价错误上则不可接受；(4) 分数依赖 prompt 格式与调用方式，换到产品的调用形态未必复现。

题目

Capability 是「有没有能力做」，propensity 是「会不会去做」。API 模型部署方可以用拒绝策略、系统提示和外围防护把 propensity 压低，即使 capability 存在。开源权重模型则不同：任何人拿到权重后用少量微调就能剥除安全对齐，propensity 防线不可依赖，所以危险能力本身（capability）是否存在成了唯一有意义的安全底线。

题目

偏见：偏爱更长的回答、偏爱 markdown/列表等格式化输出、偏爱特定表达风格、偏爱与裁判同源的模型（AlpacaEval 用 GPT-4 当裁判又当基线即是风险）。WildBench 的手段：任务取自真实对话（分布真实）、逐题 checklist 引导裁判先分析再打分；可信度论证靠外部校准——与 Chatbot Arena 人类投票的相关系数达 0.95。

题目

评估方法 = 控制变量的受控实验：固定数据/预算/规则，比较算法，结论可归因；评估系统 = 端到端比较最终产物，服务购买决策但无法归因。nanoGPT speedrun 固定训练数据与目标验证 loss，比谁的训练方法最快到达；DataComp-LM 固定训练配方与预算，比谁的数据筛选方法训出的模型更好。

参考资料

💻 lecture_12.py（官方可执行讲义）
📄 MMLU
📄 MMLU-Pro
📄 GPQA
📄 Humanity’s Last Exam
📄 Chatbot Arena
📄 IFEval
📄 AlpacaEval（length-controlled）
📄 WildBench
📄 SWE-bench
📄 CyBench
📄 MLE-bench
📄 On the Measure of Intelligence（ARC）
📄 HarmBench
📄 AIR-Bench 2024
📄 Universal and Transferable Adversarial Attacks on Aligned Language Models（GCG）
📄 Clio: Privacy-Preserving Insights into Real-World AI Use
📄 Language Models Should Report Train-Test Overlap
📖 HELM