Files

T

windyboy f375cd6134 add evaluation-guidebook notes: HF guidebook knowledge (2024 GitHub + 2025 Space) into LLM_Evaluation

- Add 9 Chinese distilled notes under 04-Reference-Archive/evaluation-guidebook/
  covering automated benchmarks, human evaluation, LLM-as-a-judge,
  troubleshooting, general knowledge, yearly dives, resources, and the
  2025 HF Space edition (FineWeb eval-selection methodology, MCF/CF/FG,
  sampling metrics, Math-Verify, statistical validity & cost)
- Update zone README and Material-List with entry links

2026-08-21 16:19:12 +08:00

67 KiB

Raw Blame History

type, tags, status, created, source

type

HuggingFace LLM Evaluation Guidebook（2025 新版）提炼

本笔记提炼 HuggingFace Evaluation Guidebook 新版（2025-12）独有/更新的内容，与 00-Overview～07-Resources 整理自旧 GitHub 仓库的 8 篇笔记互补。旧版内容（judge 大章节、tokenization、yearly dives、resources 清单等）不在本文重复，重点写新版新增与重构的部分。

开篇：新版是什么

The LLM Evaluation Guidebook（2025 版） 是旧 GitHub 仓库（huggingface/evaluation-guidebook）停更后的全新"科研论文形态"交互式 Space：

地址：https://huggingface.co/spaces/OpenEvals/evaluation-guidebook
作者：Clémentine Fourrier、Thibaud Frere、Guilherme Penedo、Thomas Wolf（均为 Hugging Face）
副标题："All the things you could want to know about LLM evaluation based on our experience scoring 15000 models over 3 years"
发布时间：2025-12-03
许可证：CC BY 4.0
形态：一个 Astro 构建的交互式论文页面（app/src/content/article.mdx 组装各章节 MDX，渲染结构见下），带可交互图表（d3 嵌入）、折叠块（Accordion）、侧注（Sidenote），而非旧版的线性 Git 文档

一句话关系：同一团队对同一知识核心的现代化重组与再创作——保留 tokenization/inference、自动评测设计、人类标注、troubleshooting 的骨架，但删除/压缩了旧版膨胀的部分（judge 独立大章节、troubleshooting 两个专项页、yearly dives、resources），把篇幅让给 2025 评测全景、统计有效性与成本、结构化生成、以及全新加入的 FineWeb 预训练评测选型方法论。

新版实际渲染结构（重要）

新版仓库含 8 个章节 MDX 文件，但页面正文（article.mdx）按以下顺序渲染，与文件布局不完全一一对应：

article.mdx（组装层，含正文过渡小节、saturation/contamination 定义、Conclusion）
├─ Intro                                        ← chapters/intro.mdx
├─ ModelInferenceAndEvaluation                  ← chapters/general-knowledge/model-inference-and-evaluation.mdx
├─ （正文小节 "Evaluating with existing benchmarks"）
│   ├─ EvalsIn2025（2025 评测全景）             ← chapters/general-knowledge/2025-evaluations-for-useful-models.mdx
│   ├─ TroubleshootingReproducibility           ← chapters/troubleshooting/troubleshooting-reproducibility.mdx
│   └─ PickingYourEval（FineWeb 选型）          ← chapters/general-knowledge/picking-your-evaluation.mdx
├─ DesigningAutomaticEvaluation                 ← chapters/automated-benchmarks/designing-your-automatic-evaluation.mdx
│   └─ 其中通过 import 嵌入 UsingHumanAnnotators（在 "Using existing data" 与
│       "Creating a dataset synthetically" 之间）← chapters/human-evaluation/using-human-annotators.mdx
└─ Conclusion（结论）

8 个章节文件一览（app/src/content/chapters/...）：

章节文件	路径	渲染方式	核心内容
intro	`intro.mdx`	article.mdx 直接 import	评测视角（model builder vs model user）、智能定义的困境
model-inference-and-evaluation	`general-knowledge/model-inference-and-evaluation.mdx`	article.mdx 直接 import	tokenization 与 inference 基础、MCF/CF/FG、calibration
2025-evaluations-for-useful-models	`general-knowledge/2025-evaluations-for-useful-models.mdx`	article.mdx 直接 import	2025 分能力评测全景与推荐
troubleshooting-reproducibility	`troubleshooting/troubleshooting-reproducibility.mdx`	article.mdx 直接 import	评测复现排错（与旧版基本一致）
picking-your-evaluation	`general-knowledge/picking-your-evaluation.mdx`	article.mdx 直接 import	FineWeb 预训练评测选型方法论（全新）
designing-your-automatic-evaluation	`automated-benchmarks/designing-your-automatic-evaluation.mdx`	article.mdx 直接 import	设计自动评测：数据、prompt、指标、functional scorers、judge、structured generation
using-human-annotators	`human-evaluation/using-human-annotators.mdx`	通过 `<UsingHumanAnnotators />` 嵌入 designing（位于 "Using existing data" 与 "Creating a dataset synthetically" 之间），是设计流程的一部分	人类标注实践（与旧版基本一致）
some-evaluation-datasets	`automated-benchmarks/some-evaluation-datasets.mdx`	存在于仓库，但页面正文不直接渲染——2025 章节仅以一句 "you'll find a big list of older interesting benchmarks here" 链接到旧 GitHub 仓库的数据集清单	数学类 + 通用类数据集大表（作为仓库资产留存）

要点：新版没有独立的 "Tips and Tricks" 章节、没有 judge 独立大章节（judge 内容压缩进 designing 的 "With judge models" 小节）、没有 yearly dives 2023/2024、没有 resources 清单。

§1 新版与旧版的差异总览

旧版章节（GitHub 仓库）	新版去向 / 变化
00 Overview	无独立 overview 章节；由 `intro.mdx` 承担"为什么要评测"的角色
Automatic benchmarks / Basics（tokenization & inference、评测类型）	精简合并为 `model-inference-and-evaluation.mdx`，新增 MCF/CF/FG 三种任务形式与 log-likelihood 计算细节、calibration 讨论
Automatic benchmarks / Designing your automatic evaluation	重写强化为 `designing-your-automatic-evaluation.mdx`：新增数据创建流程检查清单、样本检查、指标详解（BLEU/ROUGE/TER/BLEURT）、normalization 与 Math-Verify 表格、sampling 指标（pass@k/maj@n/cot@n/avg@n）、functional scorers/IFEval、污染管理、constraining outputs（prompt/few-shot/structured generation）、统计有效性与成本
Automatic benchmarks / Some evaluation datasets	保留为 `some-evaluation-datasets.mdx`（数学大表 + 旧数据集表 + 可复现想法），但仅作为仓库资产，页面正文不再渲染——2025 章节只给出指向旧 GitHub 版清单的链接
Human evaluation / Using human annotators	`using-human-annotators.mdx`（基本一致），通过 import 嵌入 designing 章节内部（"Using existing data" 与 "Creating a dataset synthetically" 之间）；Human evaluation basics 并入 designing 的 "With humans" 小节
LLM-as-a-judge（独立大章节）	删减合并进 designing 的 "With judge models" 小节：judge-LLM 选择、prompt 设计、评估 evaluator、reward models 仍在但大幅压缩
Troubleshooting / Troubleshooting reproducibility	`troubleshooting-reproducibility.mdx`（保留，基本一致）
Troubleshooting / Troubleshooting inference	删除
Troubleshooting / Troubleshooting math parsing	删除独立页；Math-Verify 内容移入 designing 的 Normalization 小节
General knowledge / tokenization 独立页	精简并入 `model-inference-and-evaluation.mdx`
Yearly dives（2023/2024 深度文章）	删除；以 `2025-evaluations-for-useful-models.mdx`（2025 评测全景）取代
Resources 推荐清单	删除独立章节（2025 章节末尾保留了旧数据集清单的链接）
——（新增）	`picking-your-evaluation.mdx`：FineWeb 团队预训练评测选型方法论（全新内容）
——（新增）	`intro.mdx`：model builder vs model user 视角、智能定义的困境

§2 评测视角与目的（来自 intro）

新版开篇不再直接讲技术，而是先回答"为什么评测"——因为你是谁、你在做什么，决定了你需要哪些评测。核心问题：

How can one know if a model is good?（如何知道一个模型是"好"的？）

model builder（模型构建者）：Am I building a strong model?

目标：构建在任务集上表现良好的强模型。基础模型（从零训练）关心通用任务上的多种能力；post-training（针对特定用例微调）更关心该用例上的表现。
通过 ablations（消融实验）检验设计选择（数据混合、架构、超参）是否"搞坏了"预期表现或有所提升——因此 评测任务的选择对 ablation 至关重要，它决定了你在构建模型时优化什么。
除 ablation 外，还要在训练中评测中间 checkpoint（确保在逐步学习、没有因 spike 等回退），最后评测最终 checkpoint 以宣称 SOTA。
需求：快、高信号（strong signal）、便宜，才能快速迭代；也可基于小模型表现用 scaling laws 预测大模型。
重要限定（原文强调）：对于任何复杂能力，目前不能说"这个模型在这项上最好"，而只能说——

"this model is the best on these samples for this specific task that we hope are a good proxy for this capability, without any guarantee"

model user（模型使用者）：Which model is the best for my use case?

目标：直接选用他人训练好的模型，或找最好的基础模型做进一步训练。
常见领域（math/code/knowledge）已有多个 leaderboard 可对比排名；通常只需测试头部候选（如果它们都不行，更差的模型大概率也不行）。
可自己重跑现有 benchmark 获取更细的成功/失败分析。
引用 ImageNet 时代 benchmark 设计教训论文（arxiv 2404.02112）的核心观点：分数容易不稳定，唯一稳健的评测方式是排名（rankings），尤其是找到一批能给出一致且稳定排名的评测组。作者认为这是非常值得采用的思路——LLM 在自动 benchmark 上的分数对 prompt 的微小变化极其敏感（见 evaluation-structured-outputs blog），人类评测也不更一致，而排名在稳健评测方法下更稳定。

智能（intelligence）定义的困境

目前极度缺乏对"什么是模型智能、如何评测智能"的良好定义与框架（有人尝试过：Chollet 2019 arxiv 1911.01547、Hendrycks 等人 agidefinition.ai）。
这不是 ML 独有的难题：人类/动物研究中同样难定义，IQ/EQ 等指标备受争议。
以"智能"为目标是有问题的，三个理由：
1. 移动目标（moving target）：每当我们达到一个曾被当作人类专属的能力，这个词就被重新定义。
2. 框架不迁移：现有框架以人类（或动物）为出发点设计，底层行为与假设与模型不同，很可能不适用于模型。
3. 本质无用：应该瞄准让模型擅长具体、定义良好、有目的、有用的任务（如会计、报告），而不是为了 AGI 而 AGI。

§3 2025 评测全景（2025-evaluations-for-useful-models + article.mdx）

新版先给出两个贯穿全篇的核心概念（来自 article.mdx 的 "Evaluating with existing benchmarks" 引言）：

Saturation（饱和）：模型在 benchmark 上的表现超过人类表现。更广义地指数据集失去模型间区分力、不再有用——"如果所有模型分数都接近最高分，它就不再是 discriminative benchmark，就像拿学前班题目考高中生：成功说明不了什么（虽然失败能说明问题）"。

Contamination（污染）：评测数据集进了模型训练集，导致分数被人为抬高、不反映真实任务表现——"就像考学生他事先知道答案的题目"。

另外注意 2025 章节开头的方法论警告：单独评测具体能力通常很有价值（训练中或比较 base/pretrained 模型时），但如果你用下面的评测去选择和验证训练方法，最终模型上再报告这些评测就是有偏的（你已经把训练方法朝它们调优了）。

推理与常识（Reasoning and commonsense）

多为 BERT/embedding 时代的"历史数据集"，当时有挑战性（常为对抗式构建），现在 1) 太简单 2) 被污染/饱和，只适合 ablation 或预训练评测。大数据集还常含错误/低质量问题（当年靠 Amazon Mechanical Turk 快速低成本扩展，如今由 LLM 生成评测题替代）。
代表数据集：
- ARC（2018，arxiv 1803.05457，注意与 ARC-AGI 区分）：小学科学 MCQA，选项当年对词共现系统对抗式选取；高质量 challenge 子集至今仍用于预训练。
- WinoGrande（2019，arxiv 1907.10641）：众包代词消解/填空，对抗式配对。两者对模型都难到 2022–2023 年。
- HellaSwag（2019，arxiv 1905.07830）：从 ActivityNet 字幕/WikiHow 教程选正确下一句，多需物理常识 grounding。
- CommonsenseQA（2018，arxiv 1811.00937）：基于 ConceptNet 的常识 MCQA。
- PIQA（2019，arxiv 1911.11641）：物理常识，Instructables 例子 + 语义扰动对抗选项。
- OpenBookQA（2018，arxiv 1809.02789）：提供"开卷"事实，仍需潜在常识。
较新的亮点：Zebra Logic（arxiv 2502.01100）用逻辑谜题测推理，方法允许无限生成谜题 → 污染极少。

知识（Knowledge）

MMLU（2020，arxiv 2009.03300）是知识评测主力，已饱和/污染；深查发现多项问题：引用缺失文档的不完整问题、错误 ground truth、歧义问题、主题明显的美国中心主义。
- 后续清理/扩展：MMLU-Redux（2024，arxiv 2406.04127）、MMLU-Pro（2024，arxiv 2406.01574，当前社区主要替代）、Global-MMLU（2024，arxiv 2412.03304，翻译+文化偏差标注）。主要用于预训练评测与 ablation。
Post-training 用更难的：GPQA（2023，arxiv 2311.12022）：生物/化学/物理博士级定制题，本领域 PhD 才能答对；最常用 diamond 子集，但自 2023 发布以来也开始污染。
Humanity's Last Exam / HLE（2024，agi.safe.ai）：2.5K 各领域专家众包题，多为私有，需复杂知识与推理，尚未被攻破。问题：无法快速打分 → 大家用 LLM judge 评估答案而非对照 ground truth → 野外结果不可比。
作者的判断：纯 latent knowledge 评测会逐步退出，两个理由：
1. 对人类不可读：题目越来越复杂，非专家几乎无法理解每题分数的含义（也无法确认数据集本身没错误）。
2. 从 closed book 走向 open book：模型接上工具/联网后，latent knowledge 评测日益变成 web search / retrieval 评测（类比法国教育：高中闭卷，大学默认可查资料，考的是"给你自由获取信息的能力下你怎么推理"）。

数学（Math）

参考基准 GSM8K（2021，arxiv 2110.14168，小学应用题）与 MATH（2021，arxiv 2103.03874，奥赛题聚合）近年已饱和/污染。
- 衍生：GSM1K（2024，arxiv 2405.00332，1K 新题测哪些模型在 GSM8K 上被污染）、GSM-Plus（arxiv 2402.19255，对抗改写：干扰项、数值变体等）、GSM-Symbolic（2024，arxiv 2410.05229，模板化可无限再生成防污染）。
社区当前聚焦：
- MATH-500（MATH 的代表性子集，防过拟合）与 MATH-Hard（最难的 500 题）
- AIME 24/25（美国高中奥赛，逐年换题等难度 → 可对比"发布时分数 vs 前一年分数"来测污染）
- Math-Arena（matharena.ai）：持续更新的竞赛/奥赛聚合（含 AIME25 等）
高端：FrontierMath（2024，arxiv 2411.04872，数学家专写、理论上私有——但 OpenAI 似乎接触过部分数据）；HLE 也含"现做"的复杂数学题（含定理证明）。
作者建议：预训练评测用 AIME25 + MATH-500；post-training 用 Math-Arena。

代码（Code）

历史（2021）：MBPP（1K 众包 Python 入门题）、APPS（10K 面试/分享网站题）、HumanEval（Codex 论文，专门"为发布而写"的题，还带沙箱防恶意代码执行；pass@k 估算器就是它提出的，此前 pass@k 是"n 次中成功次数 ≥ k"的字面检查）。
加强版：EvalPlus（2023）的 HumanEval+/MBPP+（更多测试用例、修 bug、加输入）；EvoEval（2024，arxiv 2403.19114，语义改写 + 难度标注）。
最终模型用更难/未污染的：
- LiveCodeBench（2024，arxiv 2403.07974）：记录题目日期，比较模型在训练截止前后题目上的表现——优秀的污染免疫基准。
- AiderBench（leaderboards，2024 底上线）：来自 Exercism，专门测代码编辑与重构。
Post-training 需要更整体：RepoBench（2023，仓库级自动补全，Python/Java）；SWE-Bench（2024，用 GitHub 真实 issue 测逻辑理解、跨文件编辑、长上下文推理）；CodeClash（2025，代码版 arena，模型代码互相对战迭代）。
作者建议（2025 年 11 月）：关注 LiveCodeBench、AiderBench、SWE-Bench verified，并读 METR 报告了解代码助手的真实效用。

长上下文（Long context）

3 年前模型上下文上限约 2048 tokens，现在普遍 128K+。
NIAH（Needle in a Haystack）（2023）：长无关文本中埋一条事实让其检索。2023 年模型很差，2025 年接近解决。
复杂扩展：RULER（2024，arxiv 2404.06654，多跳追踪、词频变化、NIAH 的 QA 变体，也接近解决）；Michelangelo / MRCR（2024，arxiv 2409.12640，多轮共指，后扩为 OpenAI MRCR 2025）；InfinityBench（2024，arxiv 2402.13718，中英双语 100K token 合成任务，仍有信号）。
HELMET（2024，arxiv 2410.02694）：聚合 RAG/QA（Natural Questions、TriviaQA、PopQA、HotpotQA、NarrativeQA、InfinityBench）、recall（RULER、JSONKV）、带引用生成（ALCE 子集）、摘要、重排（MS MARCO）、ICL（TREC、NLU、Banking77、CLINIC150）等的大数据集。⚠️ 聚合基准有重复计量风险：不要同时对模型跑 HELMET 和 InfinityBench 再聚合结果（等于同一评测跑两遍）。2025 年仍足够区分模型。
作者偏爱：Novel Challenge（2024，arxiv 2406.16264，近一年出版小说的 1K 条真假 claims，须读完整本书）；Kalamang 翻译集（arxiv 2309.16575，读语法书从英语翻到 Kalamang——只有约 200 个使用者的极低资源语言）。

指令遵循（Instruction Following）

IFEval（2023，arxiv 2311.07911）与扩展 IFBench（2025，arxiv 2507.02833）。作者评价 IFEval 是近几年最聪明的评测思路之一：要求模型遵循格式化指令（关键词、标点、字数/句数、markdown/html 文件格式等），每个条件可用一个特定解析测试校验 → 少数无需 model judge 就能拿到严格分数的 free-form generative evaluation。属 functional correctness / unit-test 型评测，且极易再生成/扩展以抗污染。
反向评测：CoCoNot（2024，arxiv 2407.12043）测模型对不完整/不可答/不安全请求的不服从（non-compliance）。

工具调用（Tool-calling）

TauBench（2024，arxiv 2406.12045）：零售/航空域模拟数据库，模型动作正确更新数据库 + 恰当回答用户才算对；用户由 LLM 模拟 → 昂贵且易错，但贴近真实用例。
ToolBench（2023，arxiv 2305.16504）：调用真实/模拟 API 解 100 个测试用例；因 API 不稳定被 StableToolBench（2025，arxiv 2403.07714）用通用 VirtualAPIServer 修复，但改依赖 LLM judge（引入新偏见层）。
BFCL（2025，OpenReview，历史有几年）：当前版本 4 个子集——single turn、众包真实函数调用、多轮对话、agentic（web search/memory/SQL）；用 AST + 执行响应 + 状态匹配（最终状态是否预期）判定正确性；v3 测工具调用、v4 测 web/search。
MCP 时代基准（多依赖 model judge + 真实 API → 网络故障/可复现性问题）：
- MCPBench（2025，arxiv 2508.20453）：连真实 MCP server（Wikipedia、HF、Reddit、Steam、arxiv…），规则检查工具调用有效性 + LLM judge 查回答。
- MCP-Universe（2025，arxiv 2508.14704）：11 个真实主题 MCP server；多个严格 evaluator（格式 1 个 + 回答正确性 2 个），动态任务用基于执行的评估框架自动抓最新正确值对比——作者认为比 LLM judge 干净得多。
- LiveMCPBench（2025，arxiv 2508.01780）：本地可部署的 MCP server 集合，测模型在工具列表中辨别选对工具的能力；最强模型已达 80% → 接近饱和。
附：Anthropic 的 Writing tools for agents 文档。

助手任务（Assistant tasks）

作者认为 assistant tasks 是下一代评测的主要方向之一：解决它们需要多能力组合（长上下文 + 推理 + 工具调用…），又针对具体领域给出真实场景表现；对大众更可理解；若设计得够通用，不检查用了哪个具体工具，只检查最终结果是否正确（复杂任务允许多条成功路径）。

真实信息检索：GAIA（2023，arxiv 2311.12983）开启现代 agentic 评测，3 个难度级别（L1 已饱和，L3 仍难）；因报告口径不一（公开验证集 vs LLM judge 打私有测试集）数值分散。BrowseComp（2025，OpenAI PDF）反向构造题目（从结果反推问题，不保证答案唯一），目前可能更难。GDPval（2025，arxiv 2510.04374）覆盖美国 GDP 前几大行业 44 个职业，用 model judges 对比人机表现。GAIA2（blog）用 mock 手机环境测事件链 + 工具调用；时间敏感与故意噪声子集（模拟失败 API 调用）最难，search/execution 对 SOTA 已极容易。
科学助手：SciCode（2024，arxiv 2407.13168）写科学代码解 STEM 实际问题，发布时模型 <5%；PaperBench（2025，arxiv 2504.01848）给 ICML 论文重建代码库（作者贡献 8K 个独立评分任务，rubric trees 加权），用 LLM judge；DSBench（2025，arxiv 2409.07703）Kaggle/ModelOff 多模态数据分析；DABStep（2025，arxiv 2506.23719）用此前私有的真实运营数据分析工作负载（因此未污染），每道题有 ground truth → 评测无偏且不算太贵，作者很推荐。

游戏化评测（Game-based）

优点：测对变化环境的适应性（多数 assistant tasks 是静态的）、需要长上下文推理、大众能理解；缺点：不 grounded in real life，未必反映真实有用用例。
ARC-AGI（arcprize.org）：2019 版网格谜题（找序列下一项，不给显式规则），类似逻辑 IQ 测试，2024 年几乎被解；ARC-AGI3（2025 进行中）含全新游戏（探索、复杂规划、记忆管理），目前最佳解是暴力搜索。类似规则外推基准：Baba is AI（2024，arxiv 2407.13729）。
单人冒险/RPG：TextQuests（2025，blog）、Pokemon（2024，Claude/Gemini 在 Twitch 直播玩）——需要超长程规划、长上下文记忆管理、推理与回溯；生存游戏 Crafter（2021，arxiv 2109.06780，Minecraft 灵感）同能力；多人游戏环境已集成进 Balrog（2024，arxiv 2411.13543）。
对抗/欺骗类：Poker（2025，arxiv 2501.08328）、Town of Salem（2025）、Werewolf（arxiv 2407.13943）、Among Us——测逻辑、推理与欺骗能力（例：Claude Opus 4 当不了吸血鬼这类欺骗角色，但当农民（非欺骗角色）表现好）；合作游戏 Hanabi（arxiv 2510.04980）测受限环境下的适应与沟通。
妙处：单一无歧义的 pass/fail 指标——LLM 赢没赢。作者建议：能力看 TextQuests，安全看 Town of Salem。

预测未来（Forecasters）

一类无法污染的新任务：预测未发生事件。但不确定是否足够 discriminative，且可能强化 LLM 的"老虎机式成功"感（答对是因为题太简单/公式化，还是真会预测？答错是因为不可预测还是模型差？）。
FutureBench（blog）：浏览 + LLM 按周生成问题 + 博彩市场用户预测；目前模型对人类下注的题仅略好于随机，对模型生成题 3/4 正确（后者更简单）。
FutureX（arxiv 2508.11987）：预测市场/政府网站/排名网站/实时数据平台 + 模板生成（"STOCK 何时到 POINT?"），每天 500 题并过滤无关题。
Arbitrage（arxiv 2412.18544）：类似但事件要 2028 年才揭晓。
金钱交易类 arena（Alpha Arena、Trading Agents）：因成本每个模型只跑一次 → 没有统计显著性。

2025 年 11 月的评测推荐（Recommendations 原文）

核心能力（model builders）：训练用老能力评测；post-training 用 AIME26（等它发布）、GPQA、IFEval、SWE-Bench、选一个长上下文评测（如 HELMET），目标工具使用就加 TauBench 或 BFCL。
核心能力（inference 对比模型）：IFBench、HLE、MathArena、AiderBench、LiveCodeBench、MCP-Universe。
长 horizon 任务（真实世界表现）：GAIA2、DABStep、SciCode，或你用例的领域评测。
游戏（鲁棒性与适应性）：ARC-AGI3（出了再用）、TextQuests、Town of Salem（关注安全）或任何超越 Poker/Chess/Go 的游戏。
趋势总结：评测正从"孤立技能"转向"能力编排（capability orchestration）"——系统能可靠组合核心能力 + 工具使用来真正解决问题。作者希望行业更重视 functional testing 而非 model judges，以及更可理解的数据集与任务。

§4 三种任务形式：MCF / CF / FG（与 log-likelihood 细节）

新版在 inference 基础章节重点讲清了"同一道选择题可以有不同的任务表述（task formulation）"以及 log-likelihood 的计算细节——这是旧版没有展开的部分。

log-likelihood 评测的计算步骤

给定 prompt 与一个（或多个）答案，问"我的模型生成该答案的概率是多少"：

把每个 choice 与 prompt 拼接，传入 LLM，得到每个 token 的 logits；
只保留 choice tokens 对应的 logits，做 log softmax 得到 log-probabilities（范围 [-inf, 0] 而非 [0, 1]）；
对所有 token 的 log 概率求和，得到该 choice 的整体 log probability；
最后按 choice 长度做归一化（防止偏向短答案）。

由此可做：多选中的首选答案；测试某个 choice 概率是否 > 0.5；研究模型 calibration（well calibrated model = 正确答案拥有最高概率）。calibration 参考：Anthropic 论文（是什么、如何检测、如何训练校准良好）+ 校准的局限。

三种常见任务表述（formulation）

表述	含义	示例
MCF（Multiple Choice Format）	选项显式呈现在 prompt 中，前缀 A/B/C/D，比较各选项 index 的 likelihood	MMLU
CF（Cloze Formulation）	不提供选项，直接比较不同 choice 的 likelihood	填空式
FG（Freeform Generation）	对给定 prompt 的 greedy generation 计算 accuracy	自由生成

如何选择（对评测的影响）

FG 需要大量潜在知识（latent knowledge），短预训练 ablation 期间对模型通常太难 → 小规模 ablation 一般用多选表述（MCF 或 CF）。
但研究显示模型在训练早期学不会 MCF（需要大量训练才获得该技能），CF 提供更好的早期信号 → 建议：小 ablation 用 CF；主 run（main run）加入 MCF（模型过了某个阈值、SNR 足够后，MCF 给出更好的中期信号）。
关键数字：MMLU MCF 何时脱离随机表现取决于模型规模与数据量——7B transformer 约 500B tokens（OLMES 论文）；1.7B 模型约 6T tokens（SmolLM2 实验）。
对于 post-trained 模型，FG 是主要表述（要测模型能否真正生成有用回答）。
CF 类 sequence-likelihood 评测算 accuracy 时：正确答案 log probability 最高（按字符/token 数归一化）的题占比——归一化防止偏向短答案。

tokenization 对 log-likelihood 比较的破坏（细节）

一般希望把 context 与 choices 一起 tokenize（产生对模型自然/可能的一串 token）。
但有些 tokenizer（如 Llama 的，lm-eval issue）不满足 tok(context + choice) = tok(context) + tok(choice)（会增删空格）→ context tokens 会"渗入"choice，破坏比较。
具体例子：若 C1C2 恰好是一个 BPE token，context=C1、choices=C2/C3：一起 tokenize 比较的是 C1C2（1 token）vs C1+C3（2 tokens），即使按长度归一化也没可比性；分开 tokenize 比较 C1+C2 vs C1+C3，但 C1+C2 这种组合在编码器数据里罕见，模型的 log-probability 会被压低。
解决方案（两害相权）：分别 tokenize context 与 choice，去掉可能附加的 start/end 特殊 token 后再拼接比较。

generative 评测

自回归生成：传 prompt → 取最可能下一 token → 重复直到结束条件（最大长度/停止 token）→ 全部生成 token 即答案。
与 reference 比较打分：exact match、BLEU 等简单指标，或 model judges。
补充参考：⭐ Open LLM Leaderboard MMLU blog（多选 log-likelihood 与 generative 的差异及分数含义）；⭐ EleutherAI 对上述推理方法的数学形式化（直接看 Appendix）。

§5 设计自动评测（designing-your-automatic-evaluation + article.mdx）

新版把"设计自动评测"重写为完整方法论。与旧版不同的章节结构（原文实际顺序）：

Dataset（使用现有数据/聚合 → [嵌入 UsingHumanAnnotators] → 合成创建 → 污染管理）
→ Choosing a prompt（选 prompt）
→ Choosing an inference method（选推理方法）
→ Scoring（打分：log-prob 简单 / generative 复杂）
→ Evaluation's main challenge: Scoring free form text（自由文本评分）
    ├─ Automatically：Metrics → Normalization → Sampling → Functional scorers
    ├─ With humans
    ├─ With judge models（judge 获取 → prompt 设计 → 评估 evaluator → tips → reward models）
    └─ Constraining model outputs（prompt → few-shot/ICL → structured generation）
→ The forgotten children of evaluation（统计有效性 / 成本效率）

其中 "With judge models" 小节与旧版 03-LLM-as-a-Judge 笔记内容重叠（judge-LLM 获取、prompt 设计、评估 evaluator、偏差缓解、reward models），但新版表述更精炼，本笔记只简要提及差异点，重点写旧版没有的内容（数据检查清单、指标详解、normalization/Math-Verify、sampling、functional scorers、constraining outputs、统计有效性与成本）。

5.1 数据集：使用现有 / 聚合 / 合成

使用现有数据与聚合

可直接用现有数据集改 prompt 或指标；也可聚合多个数据集建针对性评测套件（例："Measuring AGI"论文作者的做法）。
聚合时注意：冗余数据（大多数数学数据集是同一批初始题的改写/聚合）；来源平衡（避免单数据集主导偏斜，这也决定按样本还是按子集聚合分数）；格式与难度兼容（尤其别混用需要 sampling 与不需要的样本）。例子：MMLU、Big-Bench、HELM。
EpochAI 2025 研究：如何在单一框架下最佳聚合 benchmark，让聚合数据集整体更难、更不易饱和。

规则式（rule-based）合成——近乎无限的样本 + 免污染

程序化生成几乎无限的新测试用例，算法可控难度、自动验证。典型任务：数学/逻辑/代码。
例子：NPHardEval（图问题、自动验证、月度刷新防过拟合）、DyVal、MuSR（neuro-symbolic 生成 1000 字谋杀谜题等复杂推理实例）、BabiQA（实体按动作序列模拟）、ZebraLogic（SAT solver 生成解并迭代最小化线索）、IFEval（500+ 条含可程序校验约束的 prompt）、GSM-Symbolic（模板生成多样数学题）。

用模型合成数据

流程：从若干 seed documents（内部文档或 Wikipedia/Stack Overflow 等高质量公开源，作为 ground truth）出发 → chunk 成自包含语义单元 → 用 frontier model + 精心设计的 prompt 从数据出题（最好要求模型给出题目所依据的 source）→ 用另一模型家族的模型当 judge 做自动验证 → 每个步骤都要人工检查数据（"无论多诱人，别全自动"）。
进阶：可用 seed prompts 当示例，让外部模型替你写"出题 prompt"。

5.2 数据创建流程检查清单（来自 article.mdx "Understanding what's in there"）

无论怎么选数据集，最重要的一步永远是看数据（看数据本身、看模型生成、看分数），这是确认评测是否贴合用例的唯一方式。检查三点：

谁创建了样本？ 理想排序：专家 > 付费标注者 > 众包 > 合成 > MTurk。看 data card 的标注者人口统计（理解语言多样性/潜在文化偏差）。
样本是否被其他标注者或作者复核过？ 看 inter-annotator agreement 是否高、数据集是否被作者整体检查过。对低薪标注者（尤其非目标语言母语的 MTurk）尤其重要，否则会有 typo/语法错误/无意义答案。
标注者是否拿到清晰的数据创建指南？ 即数据集是否一致。

5.3 样本检查（Samples inspection）

取 50 个随机样本人工检查——要自己看，不要"让 LLM 帮你找异常"。
内容质量：prompt 是否清晰无歧义？答案是否正确（例：TriviaQA 每个问题有多个 gold answers（aliases 字段），有时互相冲突）？信息是否缺失（例：MMLU 一些题引用不存在的图表）？
与任务的相关性：这些题是不是你想让 LLM 回答的那类题？是否贴合用例？
一致性（尤其要用于 few-shot 或聚合统计时）：多选题各样本选项数是否一致？prompt 前后空格是否一致？带环境的话弄清环境会调用什么。
样本数量：确认足以统计显著——自动 benchmark 通常最少 100 个样本。
指标类型也在此检查：automatic / functional / model judge 三类，成本、可复现性、偏差类型不同；最好（也最稀有）的是 functional 或 rule-based verifier 类指标。⚠️ code eval 里要小心过简单的 pass/fail 单元测试：现在的 LLM 很会"改写全局变量作弊"（尤其 Python 这种作用域可被搞乱的语言）。

5.4 选择 prompt 与推理方法

Prompt 组成：可选 task prompt（介绍任务与输出格式）+ 附加 context（source、image 等）+ problem prompt（你问模型的问题）+ 多选时的选项。注意：

语义等价的 prompt 微小改动可让结果差很多，某些 prompt 格式会偏袒/亏待特定模型。
缓解：多次运行不同 prompt 变体（贵）；或一次运行中把多种 prompt 格式分配给等价难度的不同样本。
用 few-shot 示例帮模型跟格式，加 connector words 有帮助。

推理方法选择：

log-probabilities（适合 MCQA、测知识/消歧）：
- Pros：所有模型都能"看到"正确答案；提供 confidence/calibration 代理；快（尤其只预测一个 token：A/B/C/D 或 Yes/No）；小模型也能拿到任务信号。
- Cons：略微高估小模型（若自由生成它们可能生成选项之外的内容）；部分模型有 choice order bias（arxiv 2309.03882）——除非预算允许打乱样本顺序重跑 n 次取显著性。
- 加速技巧：若选项都是单 token，只跑一次 context 的 forward pass，直接在完整词表概率分布上取各选项的 logprob，省掉 n 次拼接推理。
generative（测流畅度、推理、是否真能作答；评测 reasoning 模型最相关）：
- Pros：与真实兴趣一致；唯一能同时评测开源与闭源模型的方式。
- Cons：更难打分；比 log-likelihood 贵（尤其带 sampling 或 reasoning 模型）。

5.5 指标详解（打分自由文本）

log-probability 打分容易：accuracy 变体（最可能 choice 是否最佳），务必按序列长度归一化（字符/token/PMI），也可看 perplexity/recall/f1。generative 打分是难点：

基于匹配（match-based）的指标：

exact match：最简单最不灵活，无部分 credit（错一个词 = 全错）。注意 "exact match" 是伞形称呼，常包含 fuzzy 变体：带 normalization、只比 token 子集（如 prefix）。
BLEU：与参考译文做 n-gram 重叠；仍广泛使用但有偏向短译文的长度偏差、句级与人类相关性差（语义等价但写法不同就不行）。
ROUGE：类似但更偏向 recall 的 n-gram 重叠。
TER（translation error rate）：从预测到参考所需的编辑次数（类似编辑距离）。
BLEURT：基于 BERT 的学习表示，用 WMT 人类判断训练，语义理解强于 n-gram，但需下载模型 + task-specific fine-tuning 才最优。
变体/扩展：CorpusBLEU、GLEU、MAUVE、METEOR 等。

聚合方式：

binary 分数：precision（FP 代价高时关键）、recall（漏报代价高时关键）、F1（平衡二者，适合不平衡数据）、MCC（Matthews Correlation Coefficient，考虑全部混淆矩阵元素，适合不平衡数据）。
continuous 分数：MSE（重罚大误差、但对 outlier 权重高）、MAE（更均衡）；若假设线性回归（如研究 calibration）：R²、Pearson（线性关系、假设正态）、Spearman（单调关系、无正态假设）。
别只测平均：对某些领域（医疗、面向公众的 chatbot、毒性）需要评估最差表现。

自动评测的优缺点：一致可复现（同一模型跑 10 次同结果，可做公平排名）、规模成本低、可理解；缺点：复杂任务上用途有限——自动指标需要完美、唯一、无歧义的 reference/gold，复杂能力很难分解成单一简单答案。

5.6 Normalization 与 Math-Verify

Normalization = 把字符串改写成适配特定参考格式（不惩罚多余空格/标点/大小写）；对数学评测等需要从长预测中提取方程并对比参考的任务至关重要。
原文件列出了用 SymPy 朴素提取 MATH 数据集答案时的典型问题，以及 Math-Verify（专用数学解析器）如何解决：

示例	问题	✅ Math-Verify	🛑 朴素方法
"Therefore, the perimeter of one of these triangles is `14 + 7\sqrt{2}` inches, expressed in simplest radical form."	提取失败	`7\*sqrt(2) + 14`	None
"Therefore, the sum of the infinite geometric series is (\frac{7}{9})."	提取失败	`7/9`	None
"The final answer is `2x + 4y + z - 19 = 0`. I hope it is correct."	参数方程部分解析	`Eq(2\x + 4\y + z - 19, 0)`	`0`
(23)	latex 边界导致提取失败	`23`	None
((- \infty, -14) \cup (-3, \infty)).	区间提取失败	`Union(Interval.open(-oo, -14), Interval.open(-3, oo))`	None
100%	无效符号提取失败	`1`	None
1/3 == 0.333333	不支持舍入	`True`	`False`
sqrt(1/2)7 == sqrt(0.5)7	不支持数值求值	`True`	`False`

详见 Math-Verify leaderboard blog。⚠️ Normalization 设计不好很容易不公平（open-llm-leaderboard-drop），但总体上在任务层面仍提供信号。
对 CoT / reasoning 生成，需先从输出中移除 reasoning trace（不是最终答案的一部分）再取答案。

5.7 Sampling 指标（pass@k / maj@n / cot@n / avg@n）

多次采样聚合比单次 greedy 更稳健，对复杂推理任务尤其重要：

pass@k over n：n 个生成样本中至少有 k 个通过。两种实现：朴素 pass@k = (c >= k)；无偏估计量 pass@k = 1 - C(n-c,k)/C(n,k)（c = n 个样本中正确的数量）。
maj@n（majority voting）：采 n 次取最频繁答案；能滤掉杂散输出，当模型正确推理路径比错误更一致时效果好；常用于数学与推理。
cot@n：采 n 条推理链评估；可与 majority voting 或 pass@k 组合（采 n 条链、提取最终答案、取多数或设阈值）。
avg@n：n 个样本分数平均；比"取最好"或"取最常见"更稳定的性能估计。

使用要点：

永远报告全部采样参数（temperature、top-p、k），它们显著影响结果。
训练评测/ablations：❌ 一般避免 sampling 指标（贵、加方差），用固定 seed 的 greedy decoding。
post-training 评测：✅ 需要，sampling 能暴露 greedy 看不到的能力（推理/数学/代码类复杂任务）。
推理时：✅ 有用——估计多次采样能提升多少，尤其研究 test-time compute 能把小模型推到多远。
⚠️ 采样 k 次使评测成本 ×k，贵模型/大数据集上累积很快。

5.8 Functional scorers（函数式打分 / 功能测试）

核心思想：不做模糊字符串匹配，而是检查输出是否满足可验证的约束。更灵活、允许通过规则生成"无限"更新测试用例（降低过拟合）。
IFEval / IFBench 是最佳范例：不问"文本是否匹配参考答案"，而问"文本是否满足指令中的格式约束"，例如：
- "Include exactly 3 bullet points" → 校验输出恰好 3 个 bullet
- "Capitalize only the first sentence" → 解析并检查大小写模式
- "Use the word 'algorithm' at least twice" → 数词频
- "Your response must be in JSON format with keys 'answer' and 'reasoning'" → 校验 JSON 结构
每个约束配一个 rule-based verifier → 评测更无歧义、可解释、快、且远便宜于 model judges。
灵感来自代码评测（单元测试是标准做法）。关键挑战：找到能用程序验证的文本属性，对指令遵循效果很好，扩展到其他文本属性需要创造力。

5.9 人类评测（简述，与旧版一致）

Vibe-checks：社区个人在未公开 prompt 上的手动"体感"评测，多为轶事证据、易受确认偏差影响；但是自家用例的好起点。
Arena：社区投票排名（如 LMSYS chatbot arena），Elo 聚合；主观性强、标注者偏好有文化差异（arxiv 2404.16019），靠"群众智慧"规模效应平滑。
Systematic annotations：付费精选标注者 + 极其具体的指南；贵、不自动、仍有人类偏差（不同身份者对毒性打分差异很大，arxiv 2205.00501）。
扩展规模三条路：无数据集（给任务+评分指南+模型）→ 有数据集（preprompt + 输出 + 指南）→ 有数据集和分数（error annotation 复核评测方法）。
人类评测的已知偏差（第一印象、语气、与标注者价值观对齐等）必须考虑：任何要求事实性的任务（代码、知识）都应叠加更稳健的评测方式（专家、自动指标等）。详见 02-Human-Evaluation。

5.10 Judge models（新版压缩版，与 03-LLM-as-a-Judge 重叠）

本节与旧版 03 笔记内容重叠：新版把整个 judge 大章节压缩进 designing 的 "With judge models" 小节，表述更精炼、几乎没有新增论点。以下是压缩后的要点，供快速对照；完整展开见 03-LLM-as-a-Judge。

定义：用神经网络（或其衍生品）评估另一神经网络的输出；多数情况评文本生成。
两条路线：通用高能力模型（LLM + prompt）或小型专用模型（从偏好数据训练判别，如"毒性垃圾邮件过滤器"）。
闭源模型（Claude、GPT-o）：不可复现（API 更新随时变）、黑盒、隐私风险；优点是免本地部署。开源模型正在追平（DeepSeek R1、gpt-oss、最新 Qwen 是竞争性替代）。
小型专用 judge（数 B 参数、可本地跑）：Flow-Judge-v0.1（3.8B，Phi-3.5-mini-instruct 微调）、Prometheus（13B，从零训练）、JudgeLM（7–33B）。自训 judge 除非 niche 领域否则不建议；偏好数据可来自 lmsys 竞赛或 Prometheus collections；从 reward model 起步优于从 instruct model。
judge prompt 设计：任务描述 → 评估标准（含详细评分系统）→ 推理步骤 → 指定输出格式（如 JSON {"Score": ..., "Reasoning": ...}）。参考 MixEval/MTBench 模板。Pairwise 比较比打分与人类偏好相关性更好（arxiv 2403.16950）；整数刻度要给每个分数的详细解释或用 additive prompt；每个能力一个 prompt；可用 few-shot / reference / CoT（先输出推理再打分）/ 多轮分析 / jury（多个 judge 聚合，可用多个小模型降本） 提升准确率。
评估你的 evaluator（上线前必做）：选 baseline（约 50 个示例即可，但必须 representative / discriminative / high quality）→ 选 metric（binary/pairwise 的 accuracy/precision/recall 易解释；score 相关性难）→ 评估并定阈值：pairwise 对比可设 80%–95% accuracy；score 相关性文献常满意于 0.8 Pearson（也有人宣称 0.3 就算与人类标注相关良好——"ymmv"）。
judge 偏差与缓解：internal consistency（self-consistency prompting 取多数）→；self-preference（用 jury）；input perturbation blindness（先给 reasoning 再给分、给连贯评分刻度）；position-bias（随机交换答案位置、用 logprob 归一）；verbosity/length-bias（考虑长度差，arxiv 2404.04475）；format bias（遵守模型训练 prompt 格式）。
LLM evaluators 的已知弱点：整体上不擅长识别幻觉（尤其 partial hallucinations，arxiv 2305.11747、2303.08896）；在摘要/忠实性上与人类标注相关性低到中等，跨任务不持续与人类一致（arxiv 2406.18403）。

Reward Models（奖励模型）

学人类标注预测 prompt/completion 对得分，目标是与人偏对齐；最常用 Bradley-Terry：p(completion b better than a) = sigmoid(score_b - score_a)，只用 pairwise 比较训练（比收集分数容易），但只能比较同一 prompt 内的 completion。
变体：更细粒度概率版（RLHFlow pair-preference）；绝对分数版 SteerLM（arxiv 2311.09528，评测易用但数据难收集——绝对分数比 pairwise 不稳定）；两者皆出的 HelpSteer2-Preference（2410.01257）与 ArmoRM（2406.12845）。
评测用法：绝对分数可平均成汇总；但相对分数不要直接平均 raw reward（outlier 与 prompt 难度不同会偏置）——改用 win rates（对参考 completion 集合，胜率百分比）或 win probabilities（均值概率，更细更平滑）。
特性：非常快（小模型一次 forward pass）、确定性、少 position bias、无需 prompt engineering；缺点：需专用微调、分布外任务表现差、同一 RM 既用于 RL 又用于评测会过拟合（reward hacking）。
资源：RewardBench Leaderboard、Nemotron 论文用法、用 win rate 跟踪训练以检测退化并选最优 checkpoint（arxiv 2410.11677）。

5.11 约束模型输出（Constraining outputs）

三级递进，目的都是让输出格式可预测、简化评测：

用 prompt：task prompt 里给非常具体的指令（Provide numerical answers in digits.、Use no abbreviation.）。不一定总有效，但对高能力模型通常够用——GAIA 论文就是这么做的。
Few-shots / in-context learning：提供示例隐式引导模型跟随重复的 prompt 形状。2023 年底之前整体很好用；此后 instruction tuning 与持续预训练里的指令数据把更新模型偏向特定输出格式（arxiv 2407.07890 称之为 Training on the test task，作者称之为 overfitting the prompt format）；reasoning 模型因 reasoning trace 与 few-shot 配合不好；小上下文旧模型也可能塞不下示例。
Structured text generation（结构化生成）：用 grammar 或正则约束输出路径。outlines 库用有限状态机（FSM）实现（其他方法如 guidance 的 interleaved generation 用于 JSON 等特定格式）。效果：降低评测中的 prompt variance，结果与排名更稳定（evaluation-structured-outputs blog）。⚠️ 但近研究（arxiv 2408.02442）显示结构化生成可能降低某些任务（如推理）的表现——把先验推离了期望的概率分布。入门：⭐ outlines 的 FSM 讲解、方法论文。

§6 FineWeb 预训练评测选型方法论（重点：全新内容）

来自 picking-your-evaluation.mdx（标题 "Picking good automatic evaluations for pretraining"）。场景：训练进行中就想知道模型学得怎么样——这时需要的评测与"最终性能"评测性质不同：即使模型还不好，任务也要给出好信号。FineWeb 团队为此设计了完整方法，覆盖 9 种语言。

6.1 规模与多样性（185 tasks）

对这 9 种语言收集并实现能找到的所有任务，共 185 个。
任务选择两大目标：评测多样性 + 每个任务提供可靠信号（reliable signal）。
多样性覆盖五类能力：
- Reading comprehension (RC)：理解给定上下文并作答
- General knowledge (GK)：无上下文的事实问答
- Natural Language Understanding (NLU)：理解输入语义
- Common-sense reasoning (RES)：需要具身知识（embodied knowledge）的简单推理
- Generative tasks：无多选题"辅助"时用目标语言生成文本

6.2 实验设置（代价与规模）

每种语言训练多个 1.5B 参数模型，用 30B tokens（取自 5 个最大的开放多语言 web 数据集的子集）；同一超参与 tokenizer；0-shot、无 instruction、无 system prompt；按固定 checkpoint 间隔评测。
因任务实现反复迭代，总消耗 73,000 GPU hours 🔥；共训练 49 个模型，由此定义"可靠信号"。

6.3 可靠信号（Reliable Signal）的四个标准

原文定义：任务提供可靠信号 = 分数高于随机基线、随训练推进而上升、跨不同 seed 低方差、每个训练步给出一致的模型排序（对同规模、同超参、同数据量的模型）。

单调性（Monotonicity）：任务必须能从训练数据中学会、且学习过程可随训练逐步观察到（若随时间不提升，未来能否提升都不确定）。
- 度量：Spearman rank correlation（steps ↔ score）——能捕捉非线性的单调提升。
- 阈值：平均相关性 ≥ 0.5（跨所有模型训练 run）。
低噪声（Low noise）：区分"评测噪声"与"真实性能差异"。噪声来源：训练随机性（token 采样、数据打乱、初始化；Madaan et al., 2024）。做法：在自家单语语料（未过滤 CommonCrawl）上用不同 seed 再训 4 个模型，然后：
- 每步（约每 1B tokens）算模型分数的标准差 → per-step-std；
- 对所有 per-step-std 取平均 → avg-std（因用的是更"脏"数据训练的模型、方差偏高，视为全架构/数据集的上界）；
- signal-to-noise ratio (SNR) = 30B tokens 时所有 run 的分数均值 ÷ avg-std，作为任务变异性的主指标。
- 阈值：SNR > 20。唯一例外：generative 任务（SNR 通常偏低，但保留有价值——能看出模型在无选项自由生成时表现如何；多语言场景尤其重要，有些模型任务分数很高但生成任务会突然用错语言回答！）。
- 额外要求：假设模型表现跨 seed 正态分布，benchmark-run 表现至少高于随机基线 3 个 final-stds（形式上 benchmark-run performance - benchmark random baseline > 3 * final-std），即 99.85% 的 seed 分数高于随机。
非随机表现（Non-Random Performance）：很多能力训练后期才习得，许多任务（尤其数学这类较难的）长时间停留在基线水平——有用但不适合早期预训练评测，所以不保留。
- 计算：任务随机基线（多选题 = 所有样本 sum(1/n_choices)；生成式 = 0），任务距基线距离 = 所有模型中的最高分 − 基线。
模型排序一致性（Model Ordering Consistency）：评测的最终目的是比较模型与数据集——我们希望任务在很少 token（30B ablation）时对数据集的排序，与训练更久（300B+）后的排序一致，即任务对预训练未来表现有预测力。严格证明不可能，但有可测的必要条件：大规模一致的前提是小规模一致。
- 度量：相邻两个训练步之间模型排名的平均 Kendall's Tau（只取 15B tokens 之后的步——之前排序噪声太大）。高值 = 排序随训练推进保持一致。
- 无严格最小值，用来在任务之间做比较。

交互式图表：好/坏信号示例（新版 Space 特有的 d3 图，直观展示四标准的判例；图表配置还揭示了实际使用的指标名，如 acc_norm_token、acc_norm_pmi）：

标准	✅ 好例子	❌ 坏例子
Monotonicity（`acc_norm_token`）	`mlmm_hellaswag_fra_cf [fr]`（法语 HellaSwag，随 tokens 平滑上升）	`mlmm_truthfulqa_ara_cf:mc1 [ar]`（阿拉伯语 TruthfulQA，无趋势）
SNR（`acc_norm_token`）	`xstory_cloze_tel_cf [te]`（泰卢固语，各 seed 紧密）	`tydiqa_tel [te]`（`prefix_match`，噪声大）
Non-Randomness	`agieval_zho_cf` 用 `acc_norm_pmi [zh]`（中文 AGIEval，明显高于随机）	同一任务用裸 `acc [zh]`（停留在随机水平）——同一任务换个指标信号天差地别
Kendall's Tau（`acc_norm_token`）	`xcsqa_ara_cf [ar]`（阿拉伯语，排序稳定）	`thai_exams_tha_cf [th]`（泰语考试题，排序漂移）

注意 agieval_zho_cf 一例：同一个任务，用 acc_pmi 就是非随机、用裸 acc 就是随机表现——这正是 §6.4 强调"指标选择决定信号"的直观证据。

6.4 指标选择（Metrics）

多选任务的 CF target 就是选项本身，每个选项的 token 数、字符数、无条件概率（无上下文前缀下生成该选项的概率）都不同——不归一化的话模型会偏好更少 token 的答案。考虑的 accuracy 变体：

指标	公式
`acc`	`\underset{i}{\arg\max}\big(ln(P(a_i \mid q))\big)`
`acc_char`	`\underset{i}{\arg\max}\dfrac{ln(P(a_i \mid q))}{num\_characters(a_i)}`
`acc_token`	`\underset{i}{\arg\max}\dfrac{ln(P(a_i \mid q))}{num\_tokens(a_i)}`
`acc_pmi`	$\underset{i}{\arg\max}ln\dfrac{P(a_i \mid q)}{P(a_i \mid u)}$，其中 `u =` `"Answer:"`

实际落地时，FineWeb 团队在 lighteval 中使用的指标名是 acc_norm_token（= 上面的 acc_token）与 acc_norm_pmi（= 上面的 acc_pmi）——交互图表配置里出现的就是这些名字，"norm" 指长度/概率归一化。

acc_pmi 度量"给了问题上下文相比没有上下文，模型更可能选 a_i 多少"——当正确选项含普遍罕见 token、模型天然不爱选它时有用。详见 Gu et al., 2024（OLMES）与 Biderman et al., 2024。
生成式任务用：prefix_match（只要求答案前缀 exact match）与 f1（用 word tokenizer 在预测/gold 词上算 F1）；两者都做轻预处理：去冠词、去标点、小写化。
选指标本身就是难题：没有单一指标全面胜出，常出现"一个指标单调性更好、另一个 SNR 更高"的两难，团队只能按其他语言的既有实现来定（并承认这种手挑未必可复制）。给出建议：

➡️ 多选任务

base accuracy：适合选项细微变化的任务（如 Yes/No/Also 的 NLI 类），此时选项常各是单 token。
PMI：对"难"推理与知识任务（AGIEVAL、MMLU）极其有效——常是唯一高于随机的指标；但平均而言是全场最弱指标，且计算贵 2 倍 → 只在复杂推理与知识任务用。
长度归一化指标（token 或 character）整体最可靠，但最优选择取决于语言而非任务 → 推荐取 max(acc_char, acc_token) 得到最可靠结果。注意 acc_token 高度依赖 tokenizer（好在 ablation 中所有模型用同一 tokenizer）。

➡️ 生成式任务

选择更清晰：除非必须 exact match（如数学），建议用 F1——F1 噪声更小、对生成的小变化更稳健。

§7 统计有效性与成本效率（"The forgotten children of evaluation"）

新版把这两件事命名为"评测中被遗忘的孩子"，来自 designing 章节结尾——旧版没有的独立主题。

统计有效性（Statistical validity）

报告评测结果时必须在点估计（point estimate）之外附上置信区间（confidence intervals）。
自动指标：从分数的标准差或 bootstrapping 得到（相对简单）。
model judge：近期论文（arxiv 2511.21140）建议用估计器做 bias correction。
人类评测：报告 agreement（一致性）。
也可用 prompt variations 来算：以略微不同的方式问同一问题、或对不同 prompt 格式重跑同一样本。

成本与效率（Cost and efficiency）

作者呼吁集体开始按模型运行成本报告评测结果——一个要思考 10 分钟、花 10K tokens 回答 10 + 1 的 reasoning 模型（还可能在二进制 vs 十进制算术上跑题），比用几十 token 答 30 道题的 smol 模型低效得多。建议报告：

Token 消耗：评测所用的输出 token 总数——估计效率的关键，直接影响 model-as-judge 评测成本；token 数直接影响货币成本并帮他人估算算力需求。货币成本也是效率的良好代理。
- 成本指标在比较评测方法时也很关键：强 LLM judge 信号可能更好，但相对自动指标的 100x 成本未必值当；sampling 类指标（pass@k、maj@n）成本随样本数倍增，要与其信号增益权衡。
时间：模型完成评测的推理时间（含实际推理 + API rate limit 开销）——对时间敏感应用（如 GAIA2 这类 agentic 工具使用）尤其重要。
环境足迹：报告运行模型的碳排放在资源有限的当下越来越重要——含训练碳排放与推理能耗，取决于模型大小、硬件（若已知）与生成的 token 数。一些更小或量化模型达到非常有意思的 performance-to-consumption 比值。（原文在此段结束。）

注：2025-evaluations-for-useful-models.mdx 在 Recommendations 一节自然收尾，无截断；designing-your-automatic-evaluation.mdx 在 environmental footprint 段结束——原文到此。

§8 新版结论要点（来自 article.mdx Conclusion）

"Evaluation is both an art and a science."

作者希望读者记住五点：

Think critically about what you're measuring（批判性看待你在测什么）：评测是能力的代理（proxy），benchmark 高分不保证真实世界表现；自动指标、人类 judge、model judge 各有偏差、局限与权衡。
Match your evaluation to your goal（让评测匹配目标）：训练 ablation → 快、可靠、在小模型上也有强信号的基准；最终模型选型 → 更难、未污染、测整体能力的基准；特定用例 → 建贴合你问题与数据的自定义评测。
Reproducibility requires attention to detail（可复现性需要抠细节）：prompt、tokenization、normalization、模板、随机种子的微小差异就能让分数差几分；报告结果要透明交代方法；复现别人结果时，即使你试图控制每个变量，精确复现也极其困难。
Prefer interpretable evaluation methods（优先可解释的评测方法）：能选时，functional testing 与 rule-based verifiers 优于 model judges；能理解、能 debug 的评测给出更清晰可操作的洞察——评测越可解释，你越能改进模型。
Evaluation is never finished（评测永无止境）：模型变强 → benchmark 饱和；训练数据增长 → 污染更易发生；用例演进 → 新能力需要测量。评测是一场持续的战役。

收尾金句：

"The models we build are only as good as our ability to measure what matters." （我们构建的模型，其好坏只取决于我们测量重要之事的能力。）

致谢名单（Acknowledgments）：Hynek Kydlicek、Loubna Ben Allal、Sander Land、Nathan Habib 等直接或间接贡献者。

参考资料

新版 Space（主入口）

交互式页面：https://huggingface.co/spaces/OpenEvals/evaluation-guidebook

各章节 raw 链接（https://huggingface.co/spaces/OpenEvals/evaluation-guidebook/raw/main/app/src/content/...）

总组装（含结论、saturation/contamination 定义、数据检查清单）：article.mdx
Intro（评测视角、智能定义困境）：chapters/intro.mdx
Model inference and evaluation（MCF/CF/FG、calibration）：chapters/general-knowledge/model-inference-and-evaluation.mdx
2025 evaluations for useful models（2025 评测全景）：chapters/general-knowledge/2025-evaluations-for-useful-models.mdx
Designing your automatic evaluation（设计自动评测）：chapters/automated-benchmarks/designing-your-automatic-evaluation.mdx
Picking good automatic evaluations for pretraining（FineWeb 方法论）：chapters/general-knowledge/picking-your-evaluation.mdx
Some evaluation datasets（数据集大表，存在于仓库但页面正文不渲染，仅被 2025 章节以链接引用）：chapters/automated-benchmarks/some-evaluation-datasets.mdx
Using human annotators（嵌入 designing 章节内部，位于 "Using existing data" 与 "Creating a dataset synthetically" 之间）：chapters/human-evaluation/using-human-annotators.mdx
Troubleshooting reproducibility：chapters/troubleshooting/troubleshooting-reproducibility.mdx

本专区相关笔记

00-Overview（旧版总览，含新版迁移说明）
01-Automatic-Benchmarks（旧版自动评测）
02-Human-Evaluation（旧版人类评测）
03-LLM-as-a-Judge（旧版 judge 大章节——新版压缩版的可对照全文）
05-General-Knowledge（旧版 tokenization/inference）
06-Yearly-Dives（旧版年度深潜）

正文出现的关键论文/资源（按章节）

ImageNet 时代 benchmark 设计教训：arxiv 2404.02112
OLMES（PMI 推荐）：arxiv 2406.08446；推理方法数学形式化：arxiv 2405.14782v2
MMLU 各实现差异（lm_eval/helm/作者原实现）：Open LLM Leaderboard MMLU blog
Training on the test task（prompt 格式过拟合）：arxiv 2407.07890
结构化输出评测（prompt variance）：evaluation-structured-outputs blog；outlines：arxiv 2307.09702
Math-Verify：blog
EpochAI benchmark 聚合（Rosetta Stone）：epoch.ai
旧数据集清单（2025 章节末尾保留链接）：GitHub evaluation-guidebook/automated-benchmarks/some-evaluation-datasets.md

67 KiB Raw Blame History Unescape Escape