CS336 2026 Lecture 12：Evaluation

LaTeX 源码 · 备用 PDF · 观看视频

字段	内容
作者/整理	基于 Stanford CS336 Spring 2026 官方可执行讲义重新整理
来源	Stanford CS336
日期	2026 年春季

Lecture 12: evaluation 的核心问题

前面课程已经讲了如何训练语言模型：架构、训练、系统、scaling、推理。Lecture 12 转向一个更基础也更容易被低估的问题：给定一个模型，如何判断它“好不好”？这个问题必须先于数据选择，因为数据会塑造模型行为；如果我们不知道目标行为是什么，就不知道该训练什么数据。

Evaluation 的核心挑战

Evaluation 不是机械地“给 prompts、拿 responses、算 accuracy”。它是在把一个抽象 construct，例如“能力”“有用性”“安全性”“推理能力”“真实世界表现”，压缩成 concrete metric。这个压缩过程会反过来塑造研究方向、产品选择和社会判断。

课堂提示：评价先问目的，再选指标

老师在本讲开头的主线不是“介绍一串 benchmark 名字”，而是提醒我们：there is no one true evaluation。评价要服务具体问题。用户或公司想做购买决策，研究者想测 raw capability，政策制定者想理解风险和收益，模型开发者想拿反馈改模型；这四种目的需要不同 eval，混用会导致错误结论。

术语消化：评价设计的三条轴

轴	问题	例子
Difficulty	任务是否仍能区分 frontier models？	MMLU 被 MMLU-Pro/HLE 替代。
Realism	是否像真实用户或真实工作？	Chatbot Arena、GDPVal、MedHELM。
Validity	指标是否真的测到想测的 construct？	contamination、dataset quality、judge bias。

本章小结

本讲的入口问题不是“哪个榜单最权威”，而是“你想用这个榜单回答什么问题”。后面所有指标都要回到这个入口：它测什么、漏什么、被什么污染、会怎样塑造模型开发。

What is good：模型好坏有多个定义

这一节把“模型好”拆成几种互相竞争的定义。一个模型可以 benchmark 强但贵，一个模型可以便宜但不被用户喜欢，一个模型可以在 Arena 上受欢迎但在专业任务上错误很多。老师用这组例子说明：评价本身就是价值选择。

接下来四张图不是并列展示四个网站，而是在构造一条论证链：先看“标准化能力”，再看“成本约束”，再看“用户偏好”，最后看“市场选择”。如果这四个排序一致，评价会很简单；现实中它们经常不一致，所以我们才需要明确评价目的。

读图：benchmark leaderboard 测的是“标准化能力”

这类 leaderboard 让模型在同一批标准任务上比较，优点是清晰、可复现、便于购买决策；缺点是指标集合会选择性代表“好”，且容易被过拟合、污染或专门优化。读这类图时要先问：它覆盖了哪些任务，没覆盖哪些真实场景。图中的排序不是模型的绝对价值，而是某组 benchmark 权重下的投影。

这个图回答的是“如果我只关心一组标准能力，谁强？”但真实部署还会问另一个问题：强多少，贵多少，慢多少？因此老师接着把 cost 引入评价。

读图：性能-成本 Pareto frontier

如果两个模型能力相近，成本更低的模型可能更“好”。如果一个模型略强但贵很多，具体是否值得取决于用户任务价值。读这张图时应该找 Pareto frontier：有没有模型在更便宜的同时不牺牲太多能力？有没有模型虽然榜单高，但价格或 latency 让它不适合实际产品？

第三种定义来自用户偏好。标准 benchmark 假定题目和答案都由评测方定义；Arena 则让真实用户决定两个回答哪个更好。这更接近开放式 assistant 使用，但也更混乱。

读图：preference leaderboard 测的是“人更喜欢哪个回答”

人类偏好能捕捉开放式回答的风格、完整性和实用性，但也混合了正确性、语气、长度、迎合性和用户群体偏见。它不是纯粹能力测量，而是特定交互分布上的偏好测量。老师在这里的提醒是：真实用户信号很宝贵，但它不是干净标签。

最后一种定义更商业：用户是否真的选择并付费使用。OpenRouter 这类 ranking 把模型放进市场选择中，但市场选择也受价格、可得性、默认选项和生态影响。

读图：使用量不是能力本身

用户选择受到价格、品牌、可用性、上下文长度、API 兼容性、区域访问、产品默认值等影响。商业使用量能说明真实 adoption，但不能直接等同于模型能力。一个模型可能因为便宜、稳定或集成方便而使用量高，不一定因为它在所有任务上最强。

本章小结

模型“好”可以指 benchmark 强、单位成本低、用户偏好高、市场使用多。这些定义都合理，但回答的问题不同。下一节转向最传统的 LM 指标 perplexity，它曾经是语言模型评价的中心，但会暴露“指标平滑”和“真实使用”之间的张力。

Perplexity：最传统也最容易误读的指标

语言模型定义了 token 序列 \(x\) 的概率 \(p(x)\)。给定数据集 \(D\)，perplexity 可写为：

\[ \mathrm{PPL}(D) = \left(\frac{1}{p(D)}\right)^{1/|D|} = \exp\left(-\frac{1}{|D|}\sum_{x_i\in D}\log p(x_i)\right). \]

直觉上，PPL 约等于模型在每个 token 位置“等效面对多少个选项”。PPL 越低，模型越不惊讶。但它只测概率分配，不直接测“回答是否有用”。

术语消化：perplexity 的边界

Perplexity 适合做平滑 scaling-law 指标，因为它连续、低噪声、可在预训练数据上自然计算。它不适合单独代表真实产品质量，因为它会惩罚所有 token，包括与任务无关的表达形式；也不能直接评价工具使用、开放式帮助、安全性和 agent 行为。

术语澄清：zero-shot 不是 ZeRO

本节的 zero-shot 指“不针对目标数据集微调，直接评测”。它不是 ZeRO（Zero Redundancy Optimizer）：ZeRO 是训练系统里的优化器状态、梯度和参数分片方法，用于减少 data-parallel ranks 上的重复显存。

读图：GPT-2 perplexity 说明 transfer 不是均匀发生

GPT-2 在小数据集上可能因为预训练 transfer 表现更好，但在更大或分布更不同的数据集上不一定占优。这说明 in-distribution perplexity 和 out-of-distribution perplexity 是不同问题。读这张图时，不要把“某个数据集上 PPL 下降”泛化成“所有语言任务都更好”。它更像在问：WebText 训练出的概率分布，能否迁移到这些标准数据集？

老师随后提醒，许多看起来像 task benchmark 的东西，其实仍然是概率比较。LAMBADA 和 HellaSwag 把 perplexity 包装成填空或多选题，让评价更接近任务，但底层仍在比较候选 continuation 的 likelihood。

课堂提示：为什么说它们是 perplexity in disguise

LAMBADA 和 HellaSwag 都可以通过给候选 continuation 打 log probability 来选择答案。它们比纯 PPL 更接近任务，但仍依赖模型概率是否校准、tokenization 是否公平、候选长度如何归一化。老师在这里的隐含提醒是：任务形式变了，不代表评价对象完全变了。

perplexity leaderboard 的信任问题

如果参赛者提交的是 black-box LM，评测方计算 \(\log p(\text{test data})\) 时必须相信模型返回的是合法概率分布并且归一化。下游任务只需 response，而 perplexity leaderboard 需要概率接口，安全边界不同。

本章小结

Perplexity 仍是语言模型开发中最常用的内部指标，因为它平滑、便宜、适合 scaling。可是它离真实使用很远。接下来考试类 benchmark 试图补足“能否答题”的维度，但又会牺牲开放性和真实感。

Exam benchmarks：难度可控但不一定真实

考试类 benchmark 的吸引力很明显：题目边界清楚、答案通常唯一、评分便宜、难度可设计。老师把它类比成人类考试：考试可以控制学科和难度，但考试不等于真实工作。这个张力贯穿 MMLU、MMLU-Pro、GPQA 和 HLE。

本节的四组 benchmark 是一个递进序列：MMLU 建立了多学科知识考试范式；MMLU-Pro 解决饱和和噪声问题；GPQA 把题目推向专家级；HLE 则试图构造 frontier models 仍然很难的综合考试。读这些图时，要同时看两个维度：它们是否更难，以及它们是否更接近真实使用。后一维度并不会自动随难度增加。

读图：MMLU 测的是知识，不是所有 language understanding

MMLU 名字里有 language understanding，但其核心是跨学科知识问答。它的优点是题目清楚、容易评分、覆盖广；缺点是容易饱和、可能污染、且不代表真实助理交互。读这张图时，应把它理解为“知识考试面板”，而不是“通用智能温度计”。

随着模型变强，旧考试会饱和。MMLU-Pro 的设计思路不是换一个名字，而是删掉噪声/简单题、增加选项数量、给模型 chain-of-thought 空间，让强模型仍有区分度。

读图：MMLU-Pro 为什么更难

更多选项降低猜中概率，去掉 trivial questions 后减少饱和。模型准确率下降 16%-33% 说明旧 benchmark 的区分度已经不足。Benchmark 难度必须随模型进步而升级，否则 leaderboard 会变成“谁都差不多”的噪声表。

GPQA 和 HLE 进一步把难度推高。GPQA 试图让非专家即使用 Google 也难以答对；HLE 则通过奖金、共同作者身份和多轮过滤构造极难题。它们的共同目标是恢复区分度，但代价是离普通用户使用越来越远。

读图：GPQA 的设计目标

GPQA 试图让非专家即使用 Google 也难以答对，从而减少简单检索和记忆。它更接近专业知识推理，但题目来源、专家定义和评测格式仍会影响 validity。它测的是某种“专家题目上的知识和推理”，不是所有实际专业工作。

读图：HLE 的意义和限制

HLE 代表 benchmark 随模型变强而不断加难的趋势。它能延缓饱和，但仍然是考试式任务：答案通常预先存在，交互性弱，不一定覆盖真实世界开放式协作。老师的核心提醒是：更难不等于更真实；difficulty 和 realism 是两条不同轴。

本章小结

Exam benchmarks 的优势是难度可控、答案明确、易评分；缺点是生态真实性弱，且容易被 saturation 和 contamination 追上。下一节转向 chat benchmarks：它们更真实，但评价更主观、更容易受偏好和 judge 影响。

Chat benchmarks：开放式回答如何评价

真实用户不会总问多选题。用户会问“甜菜和山羊奶酪做沙拉配什么香草”，这种问题没有唯一答案，甚至好答案依赖口味、上下文和表达风格。因此开放式评价要从 accuracy 转向 preference、rubric 和 judge reliability。

读图：开放式评价为什么难

同一个 prompt 可能有多个好答案。回答可以在正确性、风格、详细程度、简洁性、礼貌性上不同。单一 accuracy 无法覆盖这些维度，因此 pairwise preference 成为高信号替代。图中例子看似日常，却正好暴露“好回答”不是一个标量事实。

\[ P(A \text{ beats } B) = \frac{1}{1+10^{(ELO_B-ELO_A)/400}}. \]

这里 \(ELO_A,ELO_B\) 是两个模型的评分。Arena 用大量 pairwise comparisons 拟合 ELO，从而得到动态 leaderboard。

老师强调：Arena 真实但不干净

Arena 的 prompts 来自真实用户，这是它的价值；但用户是谁、是否懂任务、是否偏好长回答、是否被 sycophancy 影响，都会改变结果。Arena 很真实，但真实不等于无偏。它适合回答“真实用户更喜欢哪个系统”，不适合单独回答“哪个模型更正确”。

LLM judge 的出现，是因为人类偏好昂贵且慢。AlpacaEval 和 WildBench 试图用模型裁判和 rubric/checklist 降低成本，同时用 Chatbot Arena 相关性校准它们是否接近人类偏好。

读图：LLM judge 的优势和危险

LLM judge 便宜、可扩展、可复现，但会偏好长回答、特定风格或自己熟悉的模型。AlpacaEval 2.0 用 regression debias，是因为指标本身也需要被评价。读相关性图时要注意：高相关不等于无偏，只说明在某个分布上它能近似 Arena。

开放式评价的经验规则

Pairwise comparison 通常比单独打分更稳定；checklist/rubric 能提高人类或 LLM judge 的一致性；必须监控 judge bias、长度偏好、style preference 和 correctness/style conflation。老师在这里给出的实践判断是：开放式评价不是不能做，而是必须显式管理偏差。

本章小结

Chat benchmarks 更接近真实助理使用，但牺牲了可控性。它们测的是用户或 judge 在特定分布上的偏好，不是纯粹能力。下一节继续从“说得好”推进到“做得成”：agentic benchmarks。

Agentic benchmarks：评价模型说什么到做什么

Agent = language model + agent scaffold。Scaffold 包括如何调用工具、如何计划、是否维护 todo、是否写文件、是否调用子代理、如何管理长上下文。Agent benchmarks 评价的是模型和 scaffold 的组合系统。

课堂提示：agent benchmark 的归因问题

老师在这里把评价对象从 LM 扩展成系统：同一个模型配不同 scaffold，成绩可能差很多。因此 agent benchmark 的结果不能简单归因给 base model。它测的是 model + tools + memory + planning + execution loop 的整体。

读图：SWE-Bench 为什么是 agent benchmark

模型必须读代码、定位 bug、修改文件、运行测试并迭代。最终 metric 是 unit tests，而不是文本回答质量。它评价的是工程行动能力。图中任务结构提醒我们：评测不再是一次 forward pass，而是一个多步闭环。

TerminalBench 把环境进一步抽象成通用终端。CyBench 加入安全/CTF 问题。MLE-Bench 则把数据处理、训练模型和提交结果纳入任务。这三类 benchmark 都在扩大“能力表面”：模型不只是回答，还要操作环境。

为了避免把这组图读成“又三个榜单”，可以把它们看成三种行动环境：TerminalBench 测通用终端工作流，CyBench 测安全挑战和探索，MLE-Bench 测机器学习工程项目。它们共同的问题是：模型必须在多步过程中观察、行动、失败、修正，而不是一次性输出一句答案。

读图：TerminalBench 的通用性

终端环境简单、通用、可脚本化，能覆盖安装、调试、运行、文件处理等真实工作流。但它也强依赖 scaffold：同一模型配不同工具循环，成绩可能显著不同。human time 图还告诉我们，难度不是抽象标签，而可以用人类完成时间校准。

TerminalBench 的三张图分别承担不同角色：环境图说明任务长什么样，人类时间图给出难度标尺，结果图展示模型系统当前能做到什么。只有三者一起看，才不会把低分误解为“模型完全不会”，也不会把高分误解为“模型已经能独立工作”。评测中间还隔着 scaffold、工具权限、时间预算和错误恢复策略。

读图：CyBench 的 dual-use 含义

CTF 能测试安全推理和工具使用，也具有 dual-use 性质。模型越会做 cyber tasks，越需要同时评估防御和滥用风险。这里的“能力提升”本身不是单向好事。

CyBench 和 MLE-Bench 进一步说明 agentic evaluation 必须报告过程，而不是只报告最终分数。CTF 任务里，模型可能靠枚举、工具调用或漏洞知识推进；Kaggle 任务里，模型可能输在环境配置、数据处理或提交策略。若没有轨迹分析，benchmark 分数很难告诉我们应该改模型、改 scaffold，还是改工具。

读图：MLE-Bench 为什么难

这类任务跨越数据清洗、建模、调参、提交格式、错误分析和计算预算。它更像真实 ML 工程，而不是单步问答。成绩低不一定说明模型不会 ML 知识，也可能说明 scaffold、计算预算、调试循环和提交策略不足。

Agentic evaluation 的关键

评估 agents = 评估 language model + scaffold。若不固定 scaffold，就不能把结果归因到模型本身；若固定 scaffold，又可能低估真实产品系统的能力。一个严谨 agent benchmark 应报告模型、工具、prompt、记忆、规划策略、时间预算和失败恢复规则。

本章小结

Agentic benchmarks 从“说得好”转向“做得成”。它们更真实，也更难设计 valid metrics，因为 scaffold、工具、时间、环境和测试质量都会影响结果。

Pure reasoning benchmarks：尽量剥离知识

前面的任务大量依赖语言知识和世界知识。ARC-AGI 试图问一个更纯的问题：能否把 reasoning 从 memorized facts 中分离出来？它用网格变换任务让每题都相对独特，减少直接记忆帮助。

读图：ARC-AGI 想测什么

ARC-AGI 试图把推理从语言知识中剥离出来。输入输出是小网格转换，要求从少量 examples 推断规则。它的目标不是百科知识，而是抽象模式发现。读这些网格时，真正要看的是“从几个例子归纳规则，再应用到 test grid”的能力。

老师强调：reasoning benchmark 也有边界

纯预训练语言模型不一定擅长搜索和多步假设检验。o1/o3 类 reasoning models 开始在 ARC 上提升，说明训练范式会改变曲线。但 ARC 仍是人类设计的抽象任务，它测的是某种受控 reasoning，不是所有现实推理。

纯 reasoning 也不是纯粹无争议

ARC 试图减少知识记忆，但任务设计仍包含人类先验、视觉模式偏好和搜索空间选择。它测的是一种人类可理解的抽象推理，不代表所有 intelligence。

Safety benchmarks：安全是什么也要定义

安全评价尤其能说明本讲主旨：如果 construct 不清楚，metric 就会误导。AI safety 不是一个单指标，它包含违法伤害、隐私、偏见、幻觉、sycophancy、jailbreak、dual-use 等维度。

这一节从 crash test 类比开始，是为了强调“安全”必须场景化。汽车安全不会只给一个总分，而会区分正面碰撞、侧面碰撞、儿童乘员、行人保护。AI safety 同理：harmful request refusal、policy compliance、jailbreak robustness、dual-use capability、truthfulness 和 privacy 都是不同维度。

读图：为什么用 crash test 类比 AI safety

汽车安全不是一句“安全/不安全”，而是不同碰撞场景、速度、假人伤害指标。AI safety 也类似：harmful instructions、隐私、偏见、幻觉、jailbreak、dual-use 都是不同风险维度。一个模型在某类安全测试上好，不代表全局安全。

读图：AIR-Bench 的 taxonomized risks

安全评价需要 taxonomy，否则不同评测只是在测不同风险。AIR-Bench 把风险类别显式化，能帮助比较模型在不同政策维度上的拒答和合规表现。读图时要看风险分类如何组织，而不是只看总分。

读图：jailbreak 评价是对齐系统的压力测试

GCG 说明安全不是只看普通 harmful prompt 是否拒答，还要看 adversarial prompts 是否能绕过。迁移性意味着 open-weight model 上找到的攻击可能影响 closed models。老师在这里的提醒是：安全 eval 必须包含对抗性，而不只是正常用户输入。

Safety 的上下文依赖

很多安全问题强烈依赖政治、法律、社会规范和地区差异。比如医疗建议、网络安全、政治内容、犯罪协助在不同上下文中的边界不同。安全 benchmark 必须明确政策背景，而不是假装存在唯一全局答案。

Realism 与 Validity：真实、有用、可信是三件事

Realism，也叫 ecological validity，问 evaluation 是否捕捉真实使用。GPQA 这类考试远离真实工作；Chatbot Arena prompt 来自真实用户但分布不可控；GDPVal 和 MedHELM 试图从专业工作场景中构造任务，但隐私和可复现性会变难。

读图：GDPVal 的 ecological validity

GDPVal 更接近“模型能否替代或辅助真实工作”，但也更难标准化。真实职业任务通常没有简单唯一答案，评分 rubrics 更复杂，数据也更可能私有。这里的 tradeoff 是 realism 换来了复现难度。

读图：医学评价为什么要离开标准考试

标准医学考试测知识，但临床工作还包括文档、诊断上下文、沟通、风险权衡和机构流程。MedHELM 用 clinicians 提供的任务提高 realism，但也引入隐私和数据访问限制。

realism 和 privacy 的张力

越真实的 eval 越可能含有私有数据、商业流程或用户隐私；越公开可复现的 eval 越容易变得不真实或被污染。高质量评测常需要在公开性、隐私、可重复性和现实性之间折中。

课堂提示：真实 eval 往往不可完全公开

老师在这一段的隐含判断是：公开 leaderboard 和真实产品评估之间天然有缝。公开 eval 需要可复现、可比较、可审计；真实 eval 需要贴近用户、业务和私有数据。越靠近真实使用，越可能受隐私、商业机密和数据授权限制。一个成熟团队通常会同时维护公开 benchmark、fresh eval、private eval 和线上反馈，而不是押注单一榜单。

Validity 则问：我们如何知道 eval 真的有效？最常见威胁是 train-test overlap。传统 ML 时代 train/test split 清楚；foundation model 时代训练数据常来自互联网，评测集可能已经出现过。

读图：foundation model 时代的污染问题

模型在互联网大规模训练，提供商通常不公开数据。评测集可能被训练过，导致 benchmark 高估能力。污染检测可以从模型行为推断，也可以靠报告规范、新鲜 eval 或私有 eval 降低风险。

这里的 Train-test overlap 不是一个小洁癖问题，而是 foundation model 评测的基本信任危机。预训练语料覆盖互联网，benchmark 题目也在互联网传播；模型供应商又不公开完整训练集。于是我们很难证明“模型会做这个题”是泛化能力，还是见过原题或近似答案。课程列出的四条路线各有代价：从模型行为推断 overlap 依赖统计假设；报告规范依赖供应商诚实；fresh eval 会被时间戳和复制传播破坏；private eval 更真实但难以公开复现。

Dataset quality 是另一个 validity 威胁。测试用例不足、答案错误、任务太 trivial，都会让 benchmark 产生假信号。SWE-Bench Verified、Platinum benchmarks 和 Docent 都在修复“评测本身不可靠”的问题。

读图：benchmark bugs 会变成模型能力幻觉

如果测试用例不足、答案错误、任务太 trivial，agent 可能用投机策略通过，而不是具备真实能力。评价质量本身需要评价；否则模型开发会追逐坏指标。

实践经验：如何审计一个 benchmark

一份 benchmark 至少要问六个问题：样本是否代表目标任务？答案是否可靠？是否存在训练污染？题目是否已经被 frontier models 饱和？评分器是否有偏？失败样例能否指导模型改进？如果这些问题没有答案，benchmark 分数就只能作为粗略信号，而不能作为发布、采购或研究结论的唯一依据。

How to think about evaluation

老师最后回到本讲开头：评价没有唯一真理，关键是定义规则。Pre-foundation model 时代我们经常评价 methods：固定数据、固定 split、比较算法。今天我们更多评价 models/systems：任何训练数据、prompting、tool scaffold 都可能进入系统，规则必须明说。

读图：method eval 和 system eval 的区别

nanoGPT speedrun 固定数据和目标 validation loss，比较达到目标所需时间，因此鼓励算法和工程优化。Arena 或 SWE-Bench 则更像 system eval：用户关心哪个系统好用，不一定关心改进来自模型、数据、prompt 还是 scaffold。

这一区分解释了许多论文和产品报告为什么看起来互相矛盾。研究论文想证明一个方法更好，就应该固定数据、计算预算、评测规则，尽量隔离变量；产品评测想告诉用户哪个系统好用，就可以允许工具、检索、prompting、post-training 和产品策略一起发挥作用。二者都合理，但不能混在同一张表里解释。

术语消化：methods vs models vs agents

对象	评价什么	例子
Methods	算法或训练方法，在固定数据和规则下比较。	nanoGPT speedrun。
Models	训练好的模型能力和偏好表现。	MMLU、Arena、HLE。
Agents/systems	模型加 scaffold、工具、记忆和执行循环。	SWE-Bench、TerminalBench、CyBench。

讲义提醒：评价规则本身就是研究对象

当模型越来越强，旧 benchmark 会饱和，评测者会加难；当模型会调用工具，评测者要决定是否允许工具；当模型会长链推理，评测者要决定是否限制时间和 token；当模型会影响真实用户，评测者要考虑隐私和生态有效性。Evaluation 不是训练结束后的打分脚本，而是 AI 系统发展的一部分。

总结与延伸

Lecture 12 的核心不是列举 benchmarks，而是建立评价思维：评价会把抽象目标压成具体指标，指标会改变模型开发方向。Perplexity 平滑但不真实；考试清晰但不开放；聊天偏好真实但有偏；agent benchmarks 有行动性但混入 scaffold；reasoning benchmarks 试图剥离知识但仍有先验；safety、realism、validity 则提醒我们，评价本身也是需要被评价的对象。

注意：本讲讨论的 zero-shot、zero contamination、one true evaluation 中的 zero 只是普通英文含义，不是 ZeRO（Zero Redundancy Optimizer）；ZeRO 是训练并行中的优化器状态、梯度和参数分片方法，Lecture 12 不以它为主题。

把本讲压缩成一个实践流程：先写下评价目的，再决定评价对象是 method、model 还是 agent；然后选择指标类型，是 probability、exam accuracy、human preference、tool-task success、safety refusal，还是 real-world workflow；接着检查 validity，包括污染、题目质量、judge bias、privacy 和 representativeness；最后才看 leaderboard 分数。这个顺序很重要，因为分数只有在规则清楚时才有含义。

因此，一份好的 evaluation report 不应该只列出模型名和分数，还应该说明数据来源、prompt 形式、是否允许工具、judge 是谁、失败样例长什么样、置信区间有多宽，以及这个评测不覆盖哪些真实场景。只有这些上下文齐全，读者才能判断一个分数是否值得信任。

最终 takeaways

1. 没有 one true evaluation；先说明评价目的和 rules of the game。
2. Perplexity 仍有用，但不能代表真实 assistant quality。
3. Exam benchmarks 易评分但会饱和，且不等同于真实使用。
4. Open-ended chat 需要 preference、rubric 和 judge-bias 控制。
5. Agent benchmarks 评价的是 model + scaffold + tools 的系统。
6. Safety 和 realism 都高度上下文相关，隐私和公开复现之间有张力。
7. Validity 包括 contamination、dataset quality、fresh/private evals 和 benchmark auditing。

拓展阅读

• HELM, MMLU, MMLU-Pro, GPQA, Humanity's Last Exam.
• Chatbot Arena, AlpacaEval, WildBench.
• SWE-Bench Verified, TerminalBench, CyBench, MLE-Bench.
• ARC-AGI, HarmBench, AIR-Bench, GDPVal, MedHELM.
• Train-test contamination and benchmark quality auditing papers.