2026-08-21 16:19:12 +08:00
---
type : reference
tags :
- llm-evaluation
- evaluation-guidebook
- 2025 -edition
status : active
created : 2026-08-21
source : https://huggingface.co/spaces/OpenEvals/evaluation-guidebook
---
# HuggingFace LLM Evaluation Guidebook（
> 本笔记提炼 **HuggingFace Evaluation Guidebook 新版（2025-12）独有/更新的内容**，与 [[00-Overview]]～
## 开篇：新版是什么
**The LLM Evaluation Guidebook（ 是旧 GitHub 仓库（huggingface/evaluation-guidebook）停更后的**全新"科研论文形态"交互式 Space**：
- **地址**：
- **作者**： ）
- **副标题**：
- **发布时间**：
- **许可证**：
- **形态**：一个 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（
│ ├─ TroubleshootingReproducibility ← chapters/troubleshooting/troubleshooting-reproducibility.mdx
│ └─ PickingYourEval（
├─ 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（ `model-inference-and-evaluation.mdx` ，
| 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（
| Automatic benchmarks / Some evaluation datasets | 保留为 `some-evaluation-datasets.mdx` （数学大表 + 旧数据集表 + 可复现想法），**但仅作为仓库资产，页面正文不再渲染**——2025 章节只给出指向旧 GitHub 版清单的链接 |
| Human evaluation / Using human annotators | `using-human-annotators.mdx` （基本一致），**通过 import 嵌入 designing 章节内部**（
| **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 | **删除独立页** ；
| General knowledge / tokenization 独立页 | **精简**并入 `model-inference-and-evaluation.mdx` |
| Yearly dives（ **删除** ；以 `2025-evaluations-for-useful-models.mdx` （
| Resources 推荐清单 | **删除**独立章节（2025 章节末尾保留了旧数据集清单的链接） |
| ——（新增） | `picking-your-evaluation.mdx` ：**FineWeb 团队预训练评测选型方法论（全新内容）** |
| ——（新增） | `intro.mdx` ：
---
## §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 ](https://huggingface.co/blog/evaluation-structured-outputs )），人类评测也不更一致，而**排名**在稳健评测方法下更稳定。
### 智能（intelligence）定义的困境
- 目前**极度缺乏**对"什么是模型智能、如何评测智能"的良好定义与框架（有人尝试过：Chollet 2019 [arxiv 1911.01547 ](https://arxiv.org/abs/1911.01547 )、Hendrycks 等人 [agidefinition.ai ](https://www.agidefinition.ai/paper.pdf )）。
- 这不是 ML 独有的难题：人类/动物研究中同样难定义，IQ/EQ 等指标备受争议。
- 以"智能"为目标是**有问题的**，三个理由：
1. **移动目标（moving target） ：每当我们达到一个曾被当作人类专属的能力，这个词就被重新定义。
2. **框架不迁移** ：现有框架以人类（或动物）为出发点设计，底层行为与假设与模型不同，很可能不适用于模型。
3. **本质无用** ：应该瞄准让模型擅长**具体、定义良好、有目的、有用**的任务（如会计、报告），而不是为了 AGI 而 AGI。
---
## §3 2025 评测全景（2025-evaluations-for-useful-models + article.mdx）
2026-08-21 17:25:12 +08:00
> 旧版对应：[[06-Yearly-Dives]] 的 2025 节（旧版压缩摘要，含旧版独有的"核心论点"）。
2026-08-21 16:19:12 +08:00
> 新版先给出两个贯穿全篇的核心概念（来自 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**（ ， arxiv 1803.05457 ](https://arxiv.org/abs/1803.05457 )，注意与 ARC-AGI 区分）：小学科学 MCQA，选项当年对词共现系统对抗式选取；高质量 `challenge` 子集至今仍用于预训练。
- **WinoGrande**（ ， arxiv 1907.10641 ](https://arxiv.org/abs/1907.10641 )）：众包代词消解/填空，对抗式配对。两者对模型都难到 2022–2023 年。
- **HellaSwag**（ ， arxiv 1905.07830 ](https://arxiv.org/abs/1905.07830 )）：从 ActivityNet 字幕/WikiHow 教程选正确下一句，多需物理常识 grounding。
- **CommonsenseQA**（ ， arxiv 1811.00937 ](https://arxiv.org/abs/1811.00937 )）：基于 ConceptNet 的常识 MCQA。
- **PIQA**（ ， arxiv 1911.11641 ](https://arxiv.org/abs/1911.11641 )）：物理常识，Instructables 例子 + 语义扰动对抗选项。
- **OpenBookQA**（ ， arxiv 1809.02789 ](https://arxiv.org/abs/1809.02789 )）：提供"开卷"事实，仍需潜在常识。
- 较新的亮点：**Zebra Logic**（ arxiv 2502.01100 ](https://arxiv.org/abs/2502.01100 )）用逻辑谜题测推理，方法允许**无限生成谜题 → 污染极少**。
### 知识（Knowledge）
- **MMLU**（ ， arxiv 2009.03300 ](https://arxiv.org/abs/2009.03300 )）是知识评测主力，已饱和/污染；深查发现多项问题：**引用缺失文档的不完整问题、错误 ground truth、歧义问题、主题明显的美国中心主义**。
- 后续清理/扩展：**MMLU-Redux**（ ， arxiv 2406.04127 ](https://arxiv.org/abs/2406.04127 )）、**MMLU-Pro**（ ， arxiv 2406.01574 ](https://arxiv.org/abs/2406.01574 )，**当前社区主要替代**）、**Global-MMLU**（ ， arxiv 2412.03304 ](https://arxiv.org/abs/2412.03304 )，翻译+文化偏差标注）。主要用于预训练评测与 ablation。
- Post-training 用更难的：**GPQA**（ ， arxiv 2311.12022 ](https://arxiv.org/abs/2311.12022 )）：生物/化学/物理博士级定制题，本领域 PhD 才能答对；最常用 `diamond` 子集，但自 2023 发布以来也开始污染。
- **Humanity's Last Exam / HLE**（ ， agi.safe.ai ](https://agi.safe.ai/ )）：2.5K 各领域专家众包题，多为私有，需复杂知识与推理，尚未被攻破。问题：**无法快速打分 → 大家用 LLM judge 评估答案而非对照 ground truth → 野外结果不可比**。
- 作者的判断：纯 latent knowledge 评测会逐步退出，两个理由：
1. **对人类不可读** ：题目越来越复杂，非专家几乎无法理解每题分数的含义（也无法确认数据集本身没错误）。
2. **从 closed book 走向 open book** ：模型接上工具/联网后，latent knowledge 评测日益变成 web search / retrieval 评测（类比法国教育：高中闭卷，大学默认可查资料，考的是"给你自由获取信息的能力下你怎么推理"）。
### 数学（Math）
- 参考基准 **GSM8K** （ ， arxiv 2110.14168 ](https://arxiv.org/abs/2110.14168 )，小学应用题）与 **MATH** （ ， arxiv 2103.03874 ](https://arxiv.org/abs/2103.03874 )，奥赛题聚合）近年已饱和/污染。
- 衍生：**GSM1K**（ ， arxiv 2405.00332 ](https://arxiv.org/abs/2405.00332 )，1K 新题测哪些模型在 GSM8K 上被污染）、**GSM-Plus**（ arxiv 2402.19255 ](https://arxiv.org/pdf/2402.19255 )，对抗改写：干扰项、数值变体等）、**GSM-Symbolic**（ ， arxiv 2410.05229 ](https://arxiv.org/abs/2410.05229 )，模板化可无限再生成防污染）。
- 社区当前聚焦：
- **MATH-500**（
- **AIME 24/25**（美国高中奥赛，逐年换题等难度 → 可对比"发布时分数 vs 前一年分数"来测污染）
- **Math-Arena**（ matharena.ai ](https://matharena.ai/ )）：持续更新的竞赛/奥赛聚合（含 AIME25 等）
- 高端：**FrontierMath**（ ， arxiv 2411.04872 ](https://arxiv.org/abs/2411.04872 )，数学家专写、理论上私有——但 OpenAI 似乎接触过部分数据）；HLE 也含"现做"的复杂数学题（含定理证明）。
- 作者建议：**预训练评测用 AIME25 + MATH-500；
### 代码（Code）
- 历史（2021）：**MBPP**（ （ （ @k 估算器就是它提出的**，此前 pass@k 是"n 次中成功次数 ≥ k"的字面检查）。
- 加强版：**EvalPlus**（ （ ， arxiv 2403.19114 ](https://arxiv.org/abs/2403.19114 )，语义改写 + 难度标注）。
- 最终模型用更难/未污染的：
- **LiveCodeBench**（ ， arxiv 2403.07974 ](https://arxiv.org/abs/2403.07974 )）：记录题目日期，比较模型在**训练截止前后**题目上的表现——优秀的污染免疫基准。
- **AiderBench**（ leaderboards ](https://aider.chat/docs/leaderboards/ )，
- Post-training 需要更整体：**RepoBench**（ （ （
- 作者建议（2025 年 11 月）：关注 **LiveCodeBench、AiderBench、SWE-Bench verified** ，并读 [METR 报告 ](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ) 了解代码助手的真实效用。
### 长上下文（Long context）
- 3 年前模型上下文上限约 2048 tokens，现在普遍 128K+。
- **NIAH（ ） （
- 复杂扩展：**RULER**（ ， arxiv 2404.06654 ](https://arxiv.org/abs/2404.06654 )，多跳追踪、词频变化、NIAH 的 QA 变体，也接近解决）；**Michelangelo / MRCR**（ ， arxiv 2409.12640 ](https://arxiv.org/pdf/2409.12640v2 )，多轮共指，后扩为 [OpenAI MRCR ](https://huggingface.co/datasets/openai/mrcr ) 2025）；**InfinityBench**（ ， arxiv 2402.13718 ](https://arxiv.org/abs/2402.13718 )，中英双语 100K token 合成任务，仍有信号）。
- **HELMET**（ ， arxiv 2410.02694 ](https://arxiv.org/abs/2410.02694 )）：聚合 RAG/QA（ （ （ **聚合基准有重复计量风险** ：不要同时对模型跑 HELMET 和 InfinityBench 再聚合结果（等于同一评测跑两遍）。2025 年仍足够区分模型。
- 作者偏爱：**Novel Challenge**（ ， arxiv 2406.16264 ](https://arxiv.org/abs/2406.16264 )，近一年出版小说的 1K 条真假 claims，须读完整本书）；**Kalamang 翻译集**（ arxiv 2309.16575 ](https://arxiv.org/abs/2309.16575 )，读语法书从英语翻到 Kalamang——只有约 200 个使用者的极低资源语言）。
### 指令遵循（Instruction Following）
- **IFEval**（ ， arxiv 2311.07911 ](https://arxiv.org/abs/2311.07911 )）与扩展 **IFBench** （ ， arxiv 2507.02833 ](https://arxiv.org/abs/2507.02833 )）。作者评价 IFEval 是近几年**最聪明的评测思路之一**：要求模型遵循格式化指令（关键词、标点、字数/句数、markdown/html 文件格式等），每个条件可用一个特定解析测试校验 → **少数无需 model judge 就能拿到严格分数的 free-form generative evaluation** 。属 functional correctness / unit-test 型评测，且**极易再生成/扩展以抗污染**。
- 反向评测：**CoCoNot**（ ， arxiv 2407.12043 ](https://www.arxiv.org/pdf/2407.12043 )）测模型对不完整/不可答/不安全请求的**不服从**（
### 工具调用（Tool-calling）
- **TauBench**（ ， arxiv 2406.12045 ](https://arxiv.org/pdf/2406.12045 )）：零售/航空域模拟数据库，模型动作正确更新数据库 + 恰当回答用户才算对；用户由 **LLM 模拟** → 昂贵且易错，但贴近真实用例。
- **ToolBench**（ ， arxiv 2305.16504 ](https://arxiv.org/pdf/2305.16504 )）：调用真实/模拟 API 解 100 个测试用例；因 API 不稳定被 **StableToolBench** （ ， arxiv 2403.07714 ](https://arxiv.org/pdf/2403.07714 )）用通用 VirtualAPIServer 修复，但改依赖 LLM judge（引入新偏见层）。
- **BFCL**（ ， OpenReview ](https://openreview.net/pdf?id=2GmDdhBdDk )，历史有几年）：当前版本 4 个子集——single turn、众包真实函数调用、多轮对话、agentic（ **AST + 执行响应 + 状态匹配** （最终状态是否预期）判定正确性；v3 测工具调用、v4 测 web/search。
- MCP 时代基准（多依赖 model judge + 真实 API → 网络故障/可复现性问题）：
- **MCPBench**（ ， arxiv 2508.20453 ](https://arxiv.org/abs/2508.20453 )）：连真实 MCP server（
- **MCP-Universe**（ ， arxiv 2508.14704 ](https://arxiv.org/abs/2508.14704 )）：11 个真实主题 MCP server；
- **LiveMCPBench**（ ， arxiv 2508.01780 ](https://arxiv.org/abs/2508.01780 )）：本地可部署的 MCP server 集合，测模型在工具列表中**辨别选对工具**的能力；最强模型已达 80% → **接近饱和** 。
- 附：Anthropic 的 [Writing tools for agents ](https://www.anthropic.com/engineering/writing-tools-for-agents ) 文档。
### 助手任务（Assistant tasks）
> 作者认为 **assistant tasks 是下一代评测的主要方向之一**：解决它们需要多能力组合（长上下文 + 推理 + 工具调用…），又针对具体领域给出真实场景表现；对大众更可理解；若设计得够通用，不检查用了哪个具体工具，只检查最终结果是否正确（复杂任务允许多条成功路径）。
- **真实信息检索**： （ ， arxiv 2311.12983 ](https://arxiv.org/abs/2311.12983 )）开启现代 agentic 评测，3 个难度级别（L1 已饱和，L3 仍难）；因报告口径不一（公开验证集 vs LLM judge 打私有测试集）数值分散。**BrowseComp**（ ， OpenAI PDF ](https://cdn.openai.com/pdf/5e10f4ab-d6f7-442e-9508-59515c65e35d/browsecomp.pdf )）反向构造题目（从结果反推问题，不保证答案唯一），目前可能更难。**GDPval**（ ， arxiv 2510.04374 ](https://arxiv.org/abs/2510.04374 )）覆盖美国 GDP 前几大行业 44 个职业，用 model judges 对比人机表现。**GAIA2**（ blog ](https://huggingface.co/blog/gaia2 )）用 mock 手机环境测事件链 + 工具调用；**时间敏感与故意噪声子集（模拟失败 API 调用）最难**，
- **科学助手**： （ ， arxiv 2407.13168 ](https://arxiv.org/abs/2407.13168 )）写科学代码解 STEM 实际问题，发布时模型 <5%； （ ， arxiv 2504.01848 ](https://arxiv.org/abs/2504.01848 )）给 ICML 论文重建代码库（作者贡献 8K 个独立评分任务，rubric trees 加权），用 LLM judge； （ ， arxiv 2409.07703 ](https://arxiv.org/pdf/2409.07703 )） （ ， arxiv 2506.23719 ](https://arxiv.org/abs/2506.23719 )）用**此前私有的真实运营数据分析工作负载**（因此未污染），每道题有 ground truth → 评测无偏且不算太贵，作者很推荐。
### 游戏化评测（Game-based）
- 优点：测**对变化环境的适应性**（多数 assistant tasks 是静态的）、需要长上下文推理、**大众能理解**；缺点：不 grounded in real life，未必反映真实有用用例。
- **ARC-AGI**（ arcprize.org ](https://arcprize.org/arc-agi )）：2019 版网格谜题（找序列下一项，不给显式规则），类似逻辑 IQ 测试，2024 年几乎被解；**ARC-AGI3**（2025 进行中）含全新游戏（探索、复杂规划、记忆管理），目前最佳解是暴力搜索。类似规则外推基准：**Baba is AI**（ ， arxiv 2407.13729 ](https://arxiv.org/abs/2407.13729 )）。
- 单人冒险/RPG： （ ， blog ](https://huggingface.co/blog/textquests )）、**Pokemon**（ ， **Crafter** （ ， arxiv 2109.06780 ](https://arxiv.org/abs/2109.06780 )，Minecraft 灵感）同能力；多人游戏环境已集成进 **Balrog** （ ， arxiv 2411.13543 ](https://arxiv.org/pdf/2411.13543 )）。
- 对抗/欺骗类：**Poker**（ ， arxiv 2501.08328 ](https://arxiv.org/html/2501.08328v1 )）、**Town of Salem**（ （ arxiv 2407.13943 ](https://arxiv.org/abs/2407.13943 )）、**Among Us**——测逻辑、推理与**欺骗能力**（例：Claude Opus 4 当不了吸血鬼这类欺骗角色，但当农民（非欺骗角色）表现好）；合作游戏 **Hanabi** （ arxiv 2510.04980 ](https://arxiv.org/abs/2510.04980 )）测受限环境下的适应与沟通。
- 妙处：**单一无歧义的 pass/fail 指标——LLM 赢没赢**。作者建议：能力看 TextQuests，安全看 Town of Salem。
### 预测未来（Forecasters）
- 一类**无法污染**的新任务：预测未发生事件。但不确定是否足够 discriminative，且可能强化 LLM 的"老虎机式成功"感（答对是因为题太简单/公式化，还是真会预测？答错是因为不可预测还是模型差？）。
- **FutureBench**（ blog ](https://huggingface.co/blog/futurebench )）：浏览 + LLM 按周生成问题 + 博彩市场用户预测；目前模型对人类下注的题仅略好于随机，对模型生成题 3/4 正确（后者更简单）。
- **FutureX**（ arxiv 2508.11987 ](https://arxiv.org/abs/2508.11987 )）：预测市场/政府网站/排名网站/实时数据平台 + 模板生成（"STOCK 何时到 POINT?"），每天 500 题并过滤无关题。
- **Arbitrage**（ arxiv 2412.18544 ](https://arxiv.org/pdf/2412.18544 )）：类似但事件要 2028 年才揭晓。
- 金钱交易类 arena（ **没有统计显著性** 。
### 2025 年 11 月的评测推荐（Recommendations 原文）
- **核心能力（model builders） **TauBench 或 BFCL** 。
- **核心能力（inference 对比模型）**：
- **长 horizon 任务（真实世界表现）**：
- **游戏（鲁棒性与适应性）**：ARC-AGI3（出了再用）、TextQuests、Town of Salem（关注安全）或任何超越 Poker/Chess/Go 的游戏。
- 趋势总结：评测正从"孤立技能"转向"**能力编排（capability orchestration）
---
## §4 三种任务形式：MCF / CF / FG（与 log-likelihood 细节）
新版在 inference 基础章节重点讲清了"同一道选择题可以有不同的**任务表述（task formulation）
### log-likelihood 评测的计算步骤
给定 prompt 与一个（或多个）答案，问"我的模型生成该答案的概率是多少"：
1. 把**每个 choice 与 prompt 拼接**，传入 LLM，得到每个 token 的 logits；
2. **只保留 choice tokens 对应的 logits** ，做 log softmax 得到 log-probabilities（范围 `[-inf, 0]` 而非 `[0, 1]` ）；
3. **对所有 token 的 log 概率求和** ，得到该 choice 的整体 log probability；
4. 最后按 **choice 长度做归一化** （防止偏向短答案）。
由此可做：多选中的首选答案；测试某个 choice 概率是否 > 0.5； （ Anthropic 论文 ](https://arxiv.org/abs/2207.05221 )（是什么、如何检测、如何训练校准良好）+ [校准的局限 ](https://arxiv.org/abs/2311.14648 )。
### 三种常见任务表述（formulation）
| 表述 | 含义 | 示例 |
|---|---|---|
| **MCF** （ ）
| **CF** （ ） **不提供选项** ，直接比较不同 choice 的 likelihood | 填空式 |
| **FG** （ ） **greedy generation** 计算 accuracy | 自由生成 |
### 如何选择（对评测的影响）
- **FG 需要大量潜在知识（latent knowledge），短预训练 ablation 期间对模型通常太难** → 小规模 ablation 一般用多选表述（MCF 或 CF）。
- 但研究显示**模型在训练早期学不会 MCF**（需要大量训练才获得该技能），CF 提供更好的早期信号 → **建议：小 ablation 用 CF；主 run（ （模型过了某个阈值、SNR 足够后，MCF 给出更好的中期信号）。
- 关键数字：**MMLU MCF 何时脱离随机表现取决于模型规模与数据量**——7B transformer 约 **500B tokens** （ **6T tokens** （
- 对于 post-trained 模型，**FG 是主要表述**（要测模型能否真正生成有用回答）。
- CF 类 sequence-likelihood 评测算 accuracy 时：**正确答案 log probability 最高（按字符/token 数归一化）的题占比**——归一化防止偏向短答案。
### tokenization 对 log-likelihood 比较的破坏（细节）
- 一般希望**把 context 与 choices 一起 tokenize**（产生对模型自然/可能的一串 token）。
- 但有些 tokenizer（如 Llama 的，[lm-eval issue ](https://github.com/EleutherAI/lm-evaluation-harness/pull/531#issuecomment-1595586257 )）不满足 `tok(context + choice) = tok(context) + tok(choice)` （会增删空格）→ context tokens 会"渗入"choice，破坏比较。
- 具体例子：若 `C1C2` 恰好是一个 BPE token， `C1` 、choices=`C2` /`C3` ：一起 tokenize 比较的是 `C1C2` （ ） `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 ](https://huggingface.co/blog/open-llm-leaderboard-mmlu )（多选 log-likelihood 与 generative 的差异及分数含义）；⭐ [EleutherAI 对上述推理方法的数学形式化 ](https://arxiv.org/abs/2405.14782v2 )（直接看 Appendix）。
---
## §5 设计自动评测（designing-your-automatic-evaluation + article.mdx）
2026-08-21 17:25:12 +08:00
> 旧版对应：[[01-Automatic-Benchmarks]] §3（设计自动评测）与 §4（常用评测数据集盘点，新版不再渲染正文）。
2026-08-21 16:19:12 +08:00
新版把"设计自动评测"重写为完整方法论。**与旧版不同的章节结构**（原文实际顺序）：
```
Dataset（使用现有数据/聚合 → [嵌入 UsingHumanAnnotators] → 合成创建 → 污染管理）
→ Choosing a prompt（选 prompt）
→ Choosing an inference method（选推理方法）
→ Scoring（打分：log-prob 简单 / generative 复杂）
→ Evaluation's main challenge: Scoring free form text（自由文本评分）
├─ Automatically：
├─ With humans
├─ With judge models（ ）
└─ Constraining model outputs（ ）
→ The forgotten children of evaluation（统计有效性 / 成本效率）
```
其中 ** "With judge models" 小节与旧版 03-LLM-as-a-Judge 笔记内容重叠**（
### 5.1 数据集：使用现有 / 聚合 / 合成
**使用现有数据与聚合**
- 可直接用现有数据集改 prompt 或指标；也可**聚合多个数据集**建针对性评测套件（例："Measuring AGI"论文作者的做法）。
- 聚合时注意：**冗余数据**（大多数数学数据集是同一批初始题的改写/聚合）；**来源平衡**（避免单数据集主导偏斜，这也决定按样本还是按子集聚合分数）；**格式与难度兼容**（尤其别混用需要 sampling 与不需要的样本）。例子：MMLU、Big-Bench、HELM。
- EpochAI 2025 研究：如何在单一框架下[最佳聚合 benchmark ](https://epoch.ai/blog/a-rosetta-stone-for-ai-benchmarks )，让聚合数据集整体更难、更不易饱和。
**规则式（rule-based）合成——近乎无限的样本 + 免污染**
- 程序化生成几乎无限的新测试用例，算法可控难度、自动验证。典型任务：数学/逻辑/代码。
- 例子：**NPHardEval**（图问题、自动验证、月度刷新防过拟合）、**DyVal**、**MuSR**（ （
**用模型合成数据**
- 流程：从若干 **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"）
无论怎么选数据集，**最重要的一步永远是看数据**（看数据本身、看模型生成、看分数），这是确认评测是否贴合用例的唯一方式。检查三点：
1. **谁创建了样本？** 理想排序：专家 > 付费标注者 > 众包 > 合成 > MTurk。看 data card 的标注者人口统计（理解语言多样性/潜在文化偏差）。
2. **样本是否被其他标注者或作者复核过？** 看 inter-annotator agreement 是否高、数据集是否被作者整体检查过。对低薪标注者（尤其非目标语言母语的 MTurk）尤其重要，否则会有 typo/语法错误/无意义答案。
3. **标注者是否拿到清晰的数据创建指南？** 即数据集是否一致。
### 5.3 样本检查（Samples inspection）
- **取 50 个随机样本人工检查——要自己看，不要"让 LLM 帮你找异常"**。
- 内容质量：prompt 是否清晰无歧义？答案是否正确（例：**TriviaQA 每个问题有多个 gold answers（
- 与任务的相关性：这些题是不是你想让 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（
- **语义等价的 prompt 微小改动可让结果差很多**，某些 prompt 格式会偏袒/亏待特定模型。
- 缓解：多次运行不同 prompt 变体（贵）；或**一次运行中把多种 prompt 格式分配给等价难度的不同样本**。
- 用 few-shot 示例帮模型跟格式，加 connector words 有帮助。
**推理方法选择** ：
- **log-probabilities**（适合 MCQA、测知识/消歧）：
- Pros：所有模型都能"看到"正确答案；提供 confidence/calibration 代理；快（尤其只预测一个 token：
- Cons：**略微高估小模型**（若自由生成它们可能生成选项之外的内容）；部分模型有 **choice order bias** （ arxiv 2309.03882 ](https://arxiv.org/abs/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**（
- **BLEURT**：基于 BERT 的学习表示，用 WMT 人类判断训练，语义理解强于 n-gram，但需下载模型 + task-specific fine-tuning 才最优。
- 变体/扩展：CorpusBLEU、GLEU、MAUVE、METEOR 等。
**聚合方式** ：
- binary 分数：**precision**（ （
- 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 ](https://huggingface.co/blog/math_verify_leaderboard )。⚠️ Normalization 设计不好**很容易不公平**（[open-llm-leaderboard-drop ](https://huggingface.co/blog/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)` （
- **maj@n （ ）
- **cot@n **：采 n 条推理链评估；可与 majority voting 或 pass@k 组合（采 n 条链、提取最终答案、取多数或设阈值）。
- **avg@n **：n 个样本分数平均；比"取最好"或"取最常见"更稳定的性能估计。
使用要点：
- **永远报告全部采样参数**（
- **训练评测/ablations：❌ 一般避免 sampling 指标**（贵、加方差），用固定 seed 的 greedy decoding。
- **post-training 评测：✅ 需要**，
- **推理时：✅ 有用**——估计多次采样能提升多少，尤其研究 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 上的手动"体感"评测，多为轶事证据、易受确认偏差影响；但[是自家用例的好起点 ](https://olshansky.substack.com/p/vibe-checks-are-all-you-need )。
- **Arena**：社区投票排名（如 LMSYS chatbot arena），Elo 聚合；主观性强、标注者偏好有文化差异（[arxiv 2404.16019 ](https://arxiv.org/abs/2404.16019v1 )），靠"群众智慧"规模效应平滑。
- **Systematic annotations**：付费精选标注者 + 极其具体的指南；贵、不自动、仍有人类偏差（不同身份者对毒性打分差异很大，[arxiv 2205.00501 ](https://arxiv.org/abs/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 更新随时变）、黑盒、隐私风险；优点是免本地部署。**开源模型正在追平**（
- **小型专用 judge**（数 B 参数、可本地跑）：Flow-Judge-v0.1（ ， （ （ – lmsys 竞赛 ](https://www.kaggle.com/competitions/lmsys-chatbot-arena ) 或 Prometheus collections； 从 reward model 起步优于从 instruct model ](https://x.com/dk21/status/1826292289930674590 )。
- **judge prompt 设计**：任务描述 → 评估标准（含详细评分系统）→ 推理步骤 → 指定输出格式（如 JSON `{"Score": ..., "Reasoning": ...}` ）。参考 [MixEval ](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.pyy )/[MTBench ](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py ) 模板。**Pairwise 比较比打分与人类偏好相关性更好**（[arxiv 2403.16950 ](https://arxiv.org/abs/2403.16950 )）；整数刻度要给每个分数的详细解释或用 additive prompt； **jury（多个 judge 聚合，可用多个小模型降本）** 提升准确率。
- **评估你的 evaluator**（上线前必做）：选 baseline（**约 50 个示例即可**，但必须 representative / discriminative / high quality）→ 选 metric（ – ；
- **judge 偏差与缓解**： （ （ arxiv 2404.04475 ](https://arxiv.org/abs/2404.04475 )）；format bias（遵守模型训练 prompt 格式）。
- **LLM evaluators 的已知弱点**：整体上**不擅长识别幻觉**（尤其 partial hallucinations， arxiv 2305.11747 ](https://arxiv.org/abs/2305.11747 )、[2303.08896 ](https://arxiv.org/abs/2303.08896 )）；在摘要/忠实性上与人类标注相关性低到中等，跨任务不持续与人类一致（[arxiv 2406.18403 ](https://arxiv.org/abs/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 ](https://huggingface.co/RLHFlow/pair-preference-model-LLaMA3-8B )）；**绝对分数**版 **SteerLM** （ arxiv 2311.09528 ](https://arxiv.org/abs/2311.09528 )，评测易用但数据难收集——绝对分数比 pairwise 不稳定）；两者皆出的 **HelpSteer2-Preference** （ 2410.01257 ](https://arxiv.org/abs/2410.01257 )）与 **ArmoRM** （ 2406.12845 ](https://arxiv.org/abs/2406.12845 )）。
- **评测用法**：绝对分数可平均成汇总；但**相对分数不要直接平均 raw reward**（ **win rates** （对参考 completion 集合，胜率百分比）或 **win probabilities** （均值概率，更细更平滑）。
- 特性：**非常快**（小模型一次 forward pass）、**确定性**、**少 position bias**、**无需 prompt engineering**；缺点：需专用微调、分布外任务表现差、**同一 RM 既用于 RL 又用于评测会过拟合**（
- 资源：RewardBench Leaderboard、Nemotron 论文用法、用 win rate 跟踪训练以**检测退化并选最优 checkpoint**（ arxiv 2410.11677 ](https://arxiv.org/abs/2410.11677v1 )）。
### 5.11 约束模型输出（Constraining outputs）
三级递进，目的都是让输出格式可预测、简化评测：
1. **用 prompt** ： `Provide numerical answers in digits.` 、`Use no abbreviation.` ）。不一定总有效，但对高能力模型通常够用——**GAIA 论文就是这么做的**。
2. **Few-shots / in-context learning** ：提供示例隐式引导模型跟随重复的 prompt 形状。**2023 年底之前整体很好用**；此后 instruction tuning 与持续预训练里的指令数据把更新模型**偏向特定输出格式**（[arxiv 2407.07890 ](https://arxiv.org/abs/2407.07890 ) 称之为 *Training on the test task* ，作者称之为 *overfitting the prompt format* ）；**reasoning 模型因 reasoning trace 与 few-shot 配合不好**；小上下文旧模型也可能塞不下示例。
3. **Structured text generation（结构化生成）** ：用 grammar 或正则约束输出路径。**`outlines` 库用有限状态机（FSM）实现**（其他方法如 guidance 的 interleaved generation 用于 JSON 等特定格式）。效果：**降低评测中的 prompt variance，结果与排名更稳定**（ evaluation-structured-outputs blog ](https://huggingface.co/blog/evaluation-structured-outputs )）。⚠️ 但近研究（[arxiv 2408.02442 ](https://arxiv.org/abs/2408.02442 )）显示**结构化生成可能降低某些任务（如推理）的表现**——把先验推离了期望的概率分布。入门：⭐ [outlines 的 FSM 讲解 ](https://blog.dottxt.co/coalescence.html )、[方法论文 ](https://arxiv.org/abs/2307.09702 )。
---
## §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；
- 因任务实现反复迭代，总消耗 **73,000 GPU hours** 🔥；共训练 **49 个模型** ，由此定义"可靠信号"。
### 6.3 可靠信号（Reliable Signal）的四个标准
原文定义：任务提供可靠信号 = 分数**高于随机基线**、**随训练推进而上升**、**跨不同 seed 低方差**、**每个训练步给出一致的模型排序**（对同规模、同超参、同数据量的模型）。
1. **单调性（Monotonicity） ：任务必须能从训练数据中学会、且学习过程可随训练逐步观察到（若随时间不提升，未来能否提升都不确定）。
- 度量：**Spearman rank correlation**（
- 阈值：**平均相关性 ≥ 0.5**（跨所有模型训练 run）。
2. **低噪声（Low noise） ：区分"评测噪声"与"真实性能差异"。噪声来源：训练随机性（token 采样、数据打乱、初始化；[Madaan et al., 2024 ](https://arxiv.org/abs/2406.10229 )）。做法：在自家单语语料（未过滤 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 分数高于随机。
3. **非随机表现（Non-Random Performance） ：很多能力训练后期才习得，**许多任务（尤其数学这类较难的）长时间停留在基线水平**——有用但不适合早期预训练评测，所以**不保留**。
- 计算：任务随机基线（多选题 = 所有样本 `sum(1/n_choices)` ；生成式 = 0），任务距基线距离 = 所有模型中的最高分 − 基线。
4. **模型排序一致性（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_pmi` 度量"给了问题上下文相比没有上下文，模型更可能选 $a_i$ 多少"——当正确选项含普遍罕见 token、模型天然不爱选它时有用。详见 [Gu et al., 2024 ](https://arxiv.org/abs/2406.08446 )（ Biderman et al., 2024 ](https://arxiv.org/abs/2405.14782 )。
- 生成式任务用：**`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 ](https://arxiv.org/pdf/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."
作者希望读者记住五点：
1. **Think critically about what you're measuring（批判性看待你在测什么）** ：评测是能力的**代理（proxy）**，benchmark 高分不保证真实世界表现；自动指标、人类 judge、model judge 各有偏差、局限与权衡。
2. **Match your evaluation to your goal（让评测匹配目标）** ：训练 ablation → 快、可靠、在小模型上也有强信号的基准；最终模型选型 → 更难、未污染、测整体能力的基准；特定用例 → 建贴合你问题与数据的自定义评测。
3. **Reproducibility requires attention to detail（可复现性需要抠细节）** ：
4. **Prefer interpretable evaluation methods（优先可解释的评测方法）** ：能选时，functional testing 与 rule-based verifiers 优于 model judges；能理解、能 debug 的评测给出更清晰可操作的洞察——**评测越可解释，你越能改进模型**。
5. **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（ `chapters/general-knowledge/model-inference-and-evaluation.mdx`
- 2025 evaluations for useful models（ `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（ `chapters/general-knowledge/picking-your-evaluation.mdx`
- Some evaluation datasets（数据集大表，**存在于仓库但页面正文不渲染**，仅被 2025 章节以链接引用）：`chapters/automated-benchmarks/some-evaluation-datasets.mdx`
- Using human annotators（ `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 ](https://arxiv.org/pdf/2404.02112 )
- OLMES（ arxiv 2406.08446 ](https://arxiv.org/abs/2406.08446 )；推理方法数学形式化：[arxiv 2405.14782v2 ](https://arxiv.org/abs/2405.14782v2 )
- MMLU 各实现差异（lm_eval/helm/作者原实现）：[Open LLM Leaderboard MMLU blog ](https://huggingface.co/blog/open-llm-leaderboard-mmlu )
- Training on the test task（ arxiv 2407.07890 ](https://arxiv.org/abs/2407.07890 )
- 结构化输出评测（prompt variance）：[evaluation-structured-outputs blog ](https://huggingface.co/blog/evaluation-structured-outputs )； ： arxiv 2307.09702 ](https://arxiv.org/abs/2307.09702 )
- Math-Verify： blog ](https://huggingface.co/blog/math_verify_leaderboard )
- EpochAI benchmark 聚合（Rosetta Stone）：[epoch.ai ](https://epoch.ai/blog/a-rosetta-stone-for-ai-benchmarks )
- 旧数据集清单（2025 章节末尾保留链接）：[GitHub evaluation-guidebook/automated-benchmarks/some-evaluation-datasets.md ](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/automated-benchmarks/some-evaluation-datasets.md )
