dedupe LLM_Evaluation zone: single-source tables, fix nav orphans, compress guidebook 2025

- Why Guide: remove duplicated 20-case/rubric/test-definition tables, link to authoritative Roadmap/Worksheet instead; 10-min action points to entries - Concept Map / What-Is: cross-link narrative vs quick-reference roles - Worksheet: annotate sections with authoritative sources - 04-Reference 01-04 <-> archive/01: bidirectional resource links - archive/00-Material-List: shrink guidebook listing, now reachable from READMEs - guidebook: compress 06-Yearly-Dives 2025 section (-> 08-2025-Edition §3), add old/new version nav banners to 01-05, reverse links in 08 - README/Start-Here: link Learning Board (was orphaned)
2026-08-21 17:25:12 +08:00
parent 451cd42b7a
commit 63add96a09
20 changed files with 75 additions and 245 deletions
@@ -218,26 +218,14 @@ Regression Suite

 ## 程序员应该如何理解 Evaluation

-最实用的映射是：
+最实用的映射是一条测试链：

 ```text
-Requirement
-   ↓
-Acceptance Criteria
-   ↓
-Eval Case
-   ↓
-Assertion / Rubric
-   ↓
-Run
-   ↓
-Failure
-   ↓
-Root Cause
-   ↓
-Regression
+Requirement → Acceptance Criteria → Eval Case → Assertion / Rubric → Run → Failure → Root Cause → Regression
 ```

+（完整版"最重要的概念关系"图见 [[03-Core-Concept-Map]] 第 10 节。）
+
 因此 LLM Evaluation 的核心不是“评分技术”，而是：

 1. 定义正确；
@@ -62,6 +62,8 @@ Anthropic 使用 evaluation suite 表示围绕共同目标组织的一组 tasks

 ## 2. 判定相关概念

+> 可填写的 rubric 模板与通过/失败定义见 [[01-LLM-Evaluation-Roadmap]] 第六节；"为什么 rubric 比参考答案重要"见 [[02-Why-Guide]] 第 3 步。
+
 ### Rubric

 **给人或模型执行的判断标准。**
@@ -199,6 +201,8 @@ load cases

 ## 4. 数据集生命周期概念

+> split 划分、冻结与版本化的实操表（dev / eval / regression / holdout）见 [[01-LLM-Evaluation-Roadmap]] 第五节。
+
 ### Dev Set

 用于频繁开发和调试。
@@ -394,6 +398,8 @@ Level 4 — Outcome

 ## 9. Benchmark、Eval、Monitoring 的关系

+> 展开叙述见 [[01-What-Is-LLM-Evaluation]]（"Evaluation 与 Benchmark 的区别"一节）。
+
 ### Benchmark

 回答：
@@ -464,6 +470,12 @@ Regression

 如果只记住一张图，记住这张。

+## 展开阅读
+
+- 概念讲解：[[01-What-Is-LLM-Evaluation]]
+- 每一步背后的道理：[[02-Why-Guide]]
+- 操作路线与 schema：[[01-LLM-Evaluation-Roadmap]]
+
 ## 参考资料

 [1] Anthropic, Demystifying evals for AI agents  
@@ -43,6 +43,7 @@ created: 2026-08-21
 | 知道原理，但不知道今天怎么开始 | [[02-First-Week-Worksheet]] | 不要把项目放大到 100 个 case。 |
 | 已有 10 个 case，想系统推进 | [[01-LLM-Evaluation-Roadmap]] | 不要急着微调模型。 |
 | 已有具体项目，想记录实验 | [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README]] | 不要把 run、case 和个人笔记混在一起。 |
+| 想知道自己学到哪了 | [[01-Learning-Board\|学习看板]] | 不要用“看过多少篇文章”代替闭环进度。 |
 | 想理解这条职业方向的全貌 | [[02_Areas/Job/llm_data_annotation_programmer_roadmap\|大模型数据标注与程序员入门]]（存于 02_Areas/Job） | 不要把岗位名当成能力边界。 |

 ## 本专区的学习原则
@@ -140,21 +140,11 @@ OpenAI 将 eval 描述为对模型输出进行结构化测试，并强调先定

 先写 10—20 个 case，是为了迫使你回答一个更难的问题：用户会以哪些不同方式使用系统？哪些情况最容易诱发错误？你写不出来，恰恰说明你还没有足够理解任务，而不是说明你需要更多数据。

-建议先用如下小分布，而不是随机列 20 个问题：
-
-| 样本类型 | 初始数量 | 为什么要有 |
-|---|---:|---|
-| 文档可完整回答 | 8 | 验证核心功能是否成立。 |
-| 文档完全没有答案 | 4 | 观察系统是否乱猜。 |
-| 文档只支持部分答案 | 2 | 观察系统能否承认边界，而非二元化地答或不答。 |
-| 多片段才能回答 | 2 | 暴露遗漏证据、拼接错误或片面回答。 |
-| 容易诱发常识补全 | 2 | 检测看似合理但无证据的内容。 |
-| 格式或引用约束 | 1 | 检查输出结构与引用格式是否被遵守。 |
-| 边界或对抗输入 | 1 | 检查系统是否错误执行不可信指令。 |
+建议先用如下小分布，而不是随机列 20 个问题：7 个类别（文档可完整回答、完全没有答案、只支持部分、多片段、容易诱发常识补全、格式/引用约束、边界/对抗输入）按 `8 / 4 / 2 / 2 / 2 / 1 / 1` 配比，每类的意图与权威表格见 [[01-LLM-Evaluation-Roadmap]] 的 Day 1 小节。

 这 20 个 case 不是“训练数据”，而是**你写给系统的 20 个问题**。每个问题都在问：“当我换一种真实但容易出错的条件时，你还能遵守同一个行为标准吗？”

-如果时间只够做 **10 个 case**，不要把所有类别机械地等比例砍半。优先保留：3 个正常路径、2 个资料不足、1 个部分支持、1 个多证据、1 个幻觉诱发、1 个格式约束、1 个边界条件（与《首周工作表》第 2 节的结构一致）。第一版必须先学会测试“能答”与“不能答时不乱猜”这两个核心行为。
+如果时间只够做 **10 个 case**，不要把所有类别机械地等比例砍半。优先保留：3 个正常路径、2 个资料不足、1 个部分支持、1 个多证据、1 个幻觉诱发、1 个格式约束、1 个边界条件（与 [[02-First-Week-Worksheet]] 第 2 节的结构一致）。第一版必须先学会测试“能答”与“不能答时不乱猜”这两个核心行为。

 ### 为什么负例和资料不足特别重要

@@ -178,13 +168,7 @@ OpenAI 将 eval 描述为对模型输出进行结构化测试，并强调先定

 同一个正确答案可以有不同措辞；同一个看起来像参考答案的输出，也可能漏掉了最关键的安全限制。参考答案只是一个例子，rubric 才是**判定逻辑**。

-以“根据文档回答问题”为例，第一版 rubric 可以只有三项：
-
-| 维度 | 通过意味着什么 | 失败意味着什么 | 为什么这样设计 |
-|---|---|---|---|
-| 有据性 | 每个关键事实能在上下文找到支持 | 出现至少一条无依据事实 | 直接约束幻觉风险。 |
-| 资料不足处理 | 资料不足时明确说明 | 把未知内容说成确定结论 | 让“拒答”成为正确行为。 |
-| 核心任务完成度 | 覆盖问题中的必要部分 | 漏掉核心限制或答偏 | 防止系统只写安全套话却不解决问题。 |
+以“根据文档回答问题”为例，第一版 rubric 只保留三个维度：**有据性**（约束幻觉风险）、**资料不足处理**（让“拒答”成为正确行为）、**核心任务完成度**（防止只写安全套话却不解决问题）。三个维度的通过/失败定义与判定方式以 [[01-LLM-Evaluation-Roadmap]] 第六节为权威版本；可填写的空白模板见 [[02-First-Week-Worksheet]] 第 1 节。

 第一版优先使用 `pass/fail` 或 `0/1/2`，不要上来就给“专业度、清晰度、帮助性”各打 1—5 分。原因不是细粒度评分不好，而是你还没有建立足够的锚点：3 分与 4 分差在哪里？如果人自己答不清，模型评分器更不可能稳定答清。

@@ -250,13 +234,7 @@ Case 定义：我想测试什么、成功条件是什么。
 Run 记录：这个版本的系统在某个时间、某个配置下实际输出了什么。
 ```

-这个区分就是 `Test Definition ≠ Test Execution`。它的意义与传统测试完全一样：测试用例不应随一次执行结果被改写；否则你无法比较不同版本，更无法追溯错误。
-
-| 应该稳定保存的定义 | 每次运行才生成的记录 |
-|---|---|
-| 问题、上下文、预期行为、类别、rubric 版本 | 模型名、提示词/系统版本、温度、trial、输出、延迟、评分结果 |
-| 为什么测这个 case | 这次系统到底做了什么 |
-| `datasets/` | `runs/` |
+这个区分就是 `Test Definition ≠ Test Execution`。它的意义与传统测试完全一样：测试用例不应随一次执行结果被改写；否则你无法比较不同版本，更无法追溯错误。两类内容各自应保存的字段与 JSONL 示例见 [[01-LLM-Evaluation-Roadmap]] 第五节（该 schema 为权威版本）。

 保存 run 不是“为了看起来工程化”，而是为了保留实验条件。没有条件记录的结论无法重现；无法重现的结论，就不能指导后续修改。

@@ -290,7 +268,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出
 比较 Judge 与人工不一致的 case
 ```

-这不是反对自动化，而是在建立自动化的基准。自动 Judge 的真正用途是把已被校准的判断放大，而不是代替你决定什么叫好。
+这不是反对自动化，而是在建立自动化的基准。自动 Judge 的真正用途是把已被校准的判断放大，而不是代替你决定什么叫好。校准实验的具体做法（混淆矩阵、failure precision / recall、接受阈值）见 [[01-LLM-Evaluation-Roadmap]] 第七节。

 ### 你此时真正学到什么

@@ -398,7 +376,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出
 | 引用是否正确 | 参数、权限和状态是否正确 | 输出或动作能否被核对？ |
 | 最终回答 | 环境 outcome | 文字承诺是否与真实结果一致？ |

-所以，等你准备做 Agent 项目时，不要先追求复杂的多工具流程。先实现三个无副作用的模拟工具，例如 `search_issue()`、`get_issue()`、`update_issue_draft()`，再构造“参数缺失、同名实体、权限不足、用户改意”这些 case。你会发现仍然是在重复同一条主线：**定义成功 → 构造边界 → 执行 → 评分 → 归因 → 回归。**
+所以，等你准备做 Agent 项目时，不要先追求复杂的多工具流程。先实现三个无副作用的模拟工具，例如 `search_issue()`、`get_issue()`、`update_issue_draft()`，再构造“参数缺失、同名实体、权限不足、用户改意”这些 case。你会发现仍然是在重复同一条主线：**定义成功 → 构造边界 → 执行 → 评分 → 归因 → 回归。**（Agent 评测的根因分类、trace 与 outcome 断言等实操见 [[01-LLM-Evaluation-Roadmap]] 第八节。）

 ---

@@ -414,11 +392,7 @@ Run 记录：这个版本的系统在某个时间、某个配置下实际输出

 ## 最后：现在第一步到底做什么

-不要再打开新的课程或框架文档。任选一个动作，十分钟内完成：
-
- [ ] 从一份公开技术文档中复制一段 200—500 字的内容，并写出一个“文档能回答的问题”和一个“文档不能回答的问题”。
- [ ] 在空白文档写下：“我的系统什么时候应该说‘我无法确认’？”
- [ ] 写一条 rubric：`若答案包含上下文未支持的事实，则 groundedness = fail`。
+不要再打开新的课程或框架文档。任选 [[00-Start-Here|开始这里]] 或 [[02-First-Week-Worksheet|首周工作表]] 中的“十分钟动作”，十分钟内完成一个（例如：从公开文档复制一段 200—500 字并写一个“能回答/不能回答”的问题，或写一条 `若答案包含上下文未支持的事实，则 groundedness = fail` 规则）。

 这个动作很小，但它会迫使你从“学习 AI 概念”切换到“定义 AI 的可验证行为”。后面的 case、盲评、脚本和回归，都是从这一步自然长出来的。

@@ -38,6 +38,8 @@ created: 2026-08-21
 ## 1. 写 rubric v0.1：先让“怎么判”有答案

 > **为什么这一步比写参考答案更早：** 参考答案只是一个可能的表述；rubric 才说明你要保护的行为边界。
+>
+> 三个维度的完整定义与判定方式见 [[01-LLM-Evaluation-Roadmap]] 第六节；为什么这样设计见 [[02-Why-Guide]] 第 3 步。

 | 维度 | 通过条件 | 失败条件 | 正例 | 反例 |
 |---|---|---|---|---|
@@ -56,6 +58,8 @@ created: 2026-08-21
 ## 2. 写 10 个 case：让不同类型的失败有机会出现

 > **为什么不是“随便写 10 个问题”：** 评测数据集的价值来自覆盖不同风险，而不是来自问题数量。
+>
+> 20-case 的权威分布表（含每类意图）见 [[01-LLM-Evaluation-Roadmap]] Day 1。

 | 编号 | 类别 | 问题 | 文档能否完整回答 | 你预期系统应该怎样做 |
 |---:|---|---|---|---|
@@ -130,6 +134,8 @@ created: 2026-08-21
 ## 5. 写最小失败分类：不要把所有错误叫“幻觉”

 > **为什么分类：** 错误类型决定修复路径。检索错、规则错、提示词错和评分错，不应使用同一修复手段。
+>
+> 每类的定义、示例与扩展分类见 [[02-Why-Guide]] 第 7 步与 [[01-LLM-Evaluation-Roadmap]] 第八节。

 | Case | 失败类型 | 证据 | 你准备先检查什么 |
 |---|---|---|---|
@@ -53,3 +53,5 @@ created: 2026-08-21
 ## 次级参考
 - Hugging Face evaluation-guidebook（已在本目录下：[[04-Reference/evaluation-guidebook/00-Overview|evaluation-guidebook]]）
 - DeepEval（应用级单元测试框架，上手快但抽象层较浅）
+
+> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"与"云厂商生产环境"两节）。
@@ -45,3 +45,5 @@ created: 2026-08-21

 ## 关键认知
 Benchmark 工程的本质是把「测试定义」做成可版本化的资产。
+
+> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"一节）。
@@ -33,3 +33,5 @@ created: 2026-08-21
  runs/、runs-v2/、runs-final/、runs-final-new/
  说明该学 experiment tracking 了
 - 不建议：一开始就为了"专业"搭 W&B
+
+> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"云厂商生产环境"与"名校/大牛的工业级课程"两节）。
@@ -29,3 +29,5 @@ created: 2026-08-21
 ### 3. AWS Workshop 中的相关模块
 - Tool Calling 的 5 种渐进式评测
 - Red Teaming 示例
+
+> 🔗 本页资源的完整链接、来源背景与上手建议见 [[04-Reference/archive/01-Curated-External-Resources|archive/01-Curated-External-Resources]]（"国家级与顶级学术机构"的 AISI 一节与"解决环境即数据的下一代框架"一节）。
@@ -65,6 +65,7 @@ created: 2026-08-21
 | [[04-Agent-Safety-and-Environments\|04-Agent-Safety-and-Environments]] | Tool Use / Sandbox / Trajectory | Inspect Sandbox, BenchFlow |
 | [[05-Source-Reading-Checklist\|05-Source-Reading-Checklist]] | 统一阅读方法论 | 固定的 8 个问题 |
 | [[04-Reference/evaluation-guidebook/00-Overview\|evaluation-guidebook]] | 方法论补充 | Hugging Face 官方 Guidebook |
+| [[04-Reference/archive/00-Material-List\|archive/]] | 早期草案与外部资源归档 | 索引见 00-Material-List |

 ## 原则

@@ -23,16 +23,7 @@ created: 2026-08-21

 ## 外部知识参考（evaluation-guidebook 子目录）

-对 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的中文提炼笔记：
-
- [[evaluation-guidebook/00-Overview|总览：这是什么、怎么读]]
- [[evaluation-guidebook/01-Automatic-Benchmarks|自动基准评测]]
- [[evaluation-guidebook/02-Human-Evaluation|人工评测]]
- [[evaluation-guidebook/03-LLM-as-a-Judge|LLM-as-a-Judge（模型作评委）]]
- [[evaluation-guidebook/04-Troubleshooting|排错（推理 / LaTeX / 可复现性）]]
- [[evaluation-guidebook/05-General-Knowledge|通用知识（推理与评测 / Tokenization）]]
- [[evaluation-guidebook/06-Yearly-Dives|年度深度文章（2023–2025）]]
- [[evaluation-guidebook/07-Resources|资源链接清单]]
+对 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的中文提炼笔记，共 9 篇（00-Overview 总览 + 01–07 旧版分篇 + 08 新版提炼）。各篇清单与阅读方式见 [[evaluation-guidebook/00-Overview|总览：这是什么、怎么读]]，此处不重复罗列。

 ## 正式学习材料不在本目录

@@ -14,6 +14,8 @@ created: 2026-08-21
 # 精选外部评测资源（真材实料级）

 > 目的：不是收藏大量 AI 资料，而是锁定顶级大厂、顶尖开源组织在生产环境中沉淀出的核心方案、底层评测基建与硬核课程源码。按需查阅，不按顺序通读。
+>
+> 能力地图（每个资源对应哪层能力、何时看、重点看什么）见 [[04-Reference/README|04-Reference 资源地图]]；本页只负责完整链接、来源背景与上手建议。

 ## 1. 国家级与顶级学术机构的"硬核基建"

@@ -17,6 +17,8 @@ source: https://github.com/huggingface/evaluation-guidebook
 > **性质**：中文提炼式笔记，非逐字翻译；关键英文术语保留原文。文内 ⭐ 标记的链接是作者特别推荐阅读的资源（同 [[00-Overview]] 的约定）。
 >
 > **关联笔记**：[[02-Human-Evaluation]]（人工评测）、[[03-LLM-as-a-Judge]]（模型作评委）、[[04-Troubleshooting]]（排错与可复现性）。
+>
+> ⚠️ **旧版内容**（2024 GitHub 仓库）。设计自动评测的新版对应：[[08-2025-Edition]] §5；「常用评测数据集盘点」在新版中不再渲染正文（仅保留仓库资产），本节 §4 作为旧版独有细节保留。

 ## 目录

@@ -22,6 +22,8 @@ source: https://github.com/huggingface/evaluation-guidebook
 3. `tips-and-tricks.md` —— 实操层：任务设计、标注过程中的注意事项、人机混合标注与端到端教程。

 > 原文建议的阅读顺序：先读 `using-human-annotators`，再读 `tips-and-tricks`。
+>
+> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §5.9（人类评测，简述且与旧版一致）；本页保留标注者组织与实操细节。

 ## 什么是人工评测

@@ -14,6 +14,8 @@ source: https://github.com/huggingface/evaluation-guidebook
 > 本笔记是 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 中 **Model-as-a-Judge** 章节（共 6 页）的中文提炼。核心问题：**如何用一个模型来评价另一个模型的输出？** 适合在设计评测、选择评委模型、写 judge prompt、或搭建基于 reward model 的评测管线时查阅。
 >
 > 相关笔记：[[00-Overview]]（总览与阅读顺序）
+>
+> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §5.10（Judge models 压缩版）；本页为详述版，校准、偏见与 reward model 细节以此为准。

 ---

@@ -12,6 +12,8 @@ source: https://github.com/huggingface/evaluation-guidebook
 # Troubleshooting（排错）

 > 本页提炼自 [HuggingFace LLM Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的 **Troubleshooting** 章节（共三小节：推理排错、LaTeX 数学解析、可复现性排错）。这是整本指南中最实操的部分——当评测跑不起来、跑得慢、分数对不上时，先查这里。文内 ⭐ 标记为作者特别推荐的资源。
+>
+> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版仅保留「可复现性排错」章节（与旧版基本一致，见 [[08-2025-Edition]] §7 的复现提示与 §5.6 Normalization / Math-Verify）；推理排错与 LaTeX 解析独立页已从新版删除，本节作为旧版独有实操细节保留。

 ## 本节速览（TL;DR）

@@ -16,6 +16,8 @@ source: https://github.com/huggingface/evaluation-guidebook
 > 原文链接：
 > - [model-inference-and-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md)
 > - [tokenization.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/tokenization.md)
+>
+> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §4（三种任务形式 MCF / CF / FG 与 log-likelihood 细节、tokenization 的影响）。

 ---

@@ -339,194 +339,25 @@ source: https://github.com/huggingface/evaluation-guidebook
 ## 2025：评测要超越简单基准，构建真正可用的模型

 > 原文：`yearly_dives/2025-evaluations-for-useful-models.md`（原文标题：Evals in 2025: going beyond simple benchmarks to build models people can actually use）。
+>
+> ⚠️ 本节为旧版详细版的**压缩版**。各能力类别、数据集链接与最新推荐（2025 年 11 月版）见新版 [[08-2025-Edition]] §3（2025 评测全景），以新版为准；本节只保留旧版独有的"核心论点"与各小节一句话摘要，不再重复维护表格。

-### 核心论点
+### 核心论点（旧版独有，简要保留）

- 目标应是构建"**工作得好（work well）**"的模型而非"智能"的模型——对人们有用且高效的工具体现为更好的成功度量，而非追求"通用智能"替人解决问题（顺带制造一串新问题）。
- 现实依据：Anthropic [经济指数报告](https://www.anthropic.com/research/anthropic-economic-index-september-2025-report)与 OpenAI [ChatGPT 使用研究](https://cdn.openai.com/pdf/a253471f-8260-40c6-a2cc-aa93fe9f142e/economic-research-chatgpt-usage-paper.pdf)显示 LLM 当前最常见的用途是**助手**：写代码、行政支持等；模型今年在通用 agent 用例上取得进展。
- 好助手应做到：面对 query 处理指令**歧义**、构建**逐步计划**、正确识别所需**资源**、不跑偏地执行计划、按需**调用工具**、执行中适应**意外事件**与新信息、且全程**不胡编（without bullshitting）**。
- 所需能力组合：逐步"推理"、长上下文记忆管理、适应性、低幻觉率，外加数学/代码/工具调用能力。
- 规模观察：**7B 的模型就能当好 agent 助手**（但再小到 3B 以下会碰到能力壁垒）。
- 评测方法需**分层**：开发期测**单一能力**、在现实任务上测**集成表现**、在动态环境中探**适应性**。
+- 目标应是构建"**工作得好（work well）**"的模型而非"智能"的模型——对人们有用且高效的工具体现为更好的成功度量。
+- 现实依据：Anthropic 经济指数报告与 OpenAI ChatGPT 使用研究显示，LLM 当前最常见的用途是**助手**（写代码、行政支持等）。
+- 好助手应做到：处理指令**歧义**、构建**逐步计划**、识别所需**资源**、按需**调用工具**、适应**意外事件**、全程**不胡编**。
+- 规模观察：**7B 的模型就能当好 agent 助手**（再小到 3B 以下会碰到能力壁垒）。
+- 评测方法需**分层**：开发期测单一能力、现实任务上测集成表现、动态环境中探适应性。

-### 单一能力评测（Testing specific capabilities）
+### 各小节摘要（详细内容见 [[08-2025-Edition]] §3）

-> 注意：若用下列评测来挑选/验证训练方法，最终报告这些指标会略有偏置（训练方法已被导向这些结果）。适合训练中取信号与对比 base/预训练模型。
-
-#### 推理与常识（Reasoning and commonsense）
-
- 背景：这类数据集多为 BERT/嵌入模型时代建的"历史"数据集——当年有挑战性（常针对当时模型对抗式构造），现在 1) 太简单 2) 污染/饱和。
- 定位：只适合**消融或预训练评测**。
- 质量问题：大型数据集常经 MTurk 快速低成本构建，含错误或低质量问题（现在改用 LLM 生成评测题）。
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| ARC | 2018 | 小学科学 MCQA，选择对当时的词共现系统对抗式构造；高质量的 `challenge` 子集今天仍用于预训练（[1803.05457](https://arxiv.org/abs/1803.05457)；勿与 ARC-AGI 混淆） |
-| WinoGrande | 2019 | 众包（MTurk + 校验）代词消解/填空，对抗式配对；2022–2023 前对模型一直很难（[1907.10641](https://arxiv.org/pdf/1907.10641)） |
-| HellaSwag | 2019 | 从对抗候选中选正确下一句；文本来自 ActivityNet 字幕与 Wikihow 教程，常需物理常识 grounding；Swag 的后继（[1905.07830](https://arxiv.org/abs/1905.07830)） |
-| CommonsenseQA | 2018 | 基于 ConceptNet 的常识 MCQA，干扰项用概念相近选项（[1811.00937](https://arxiv.org/abs/1811.00937)） |
-| PIQA | 2019 | 物理常识题，源自 Instructables.com，对抗选项来自语义扰动/改写（[1911.11641](https://arxiv.org/abs/1911.11641)） |
-| OpenBookQA | 2018 | 提供 open book 事实辅助答题，但题目仍需潜在常识知识（[1809.02789](https://arxiv.org/abs/1809.02789)） |
-
-#### 知识（Knowledge）
-
- **MMLU**（2020，[2009.03300](https://arxiv.org/abs/2009.03300)）：主要知识评测集，已饱和/污染；深入检查发现多种问题——残缺问题（引用不存在的文档）、错误 ground truth、歧义问题、明显的美国中心主义选题。
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| MMLU-Redux | 2024 | MMLU 的清洗版（[2406.04127](https://arxiv.org/abs/2406.04127)） |
-| MMLU-Pro | 2024 | 更多复杂题与答案，社区当前主要替代品（[2406.01574](https://arxiv.org/abs/2406.01574)） |
-| Global-MMLU | 2024 | MMLU 翻译 + 文化偏差标注（[2412.03304](https://arxiv.org/abs/2412.03304)） |
-| GPQA | 2023 | 生物/化学/物理博士级定制题，只有对应领域博士生能答；最常用 `diamond` 子集，2023 发布以来也开始污染（[2311.12022](https://arxiv.org/abs/2311.12022)） |
-| Humanity's Last Exam（HLE） | 2024 | 2.5K 专家众包跨领域题，需复杂知识与推理；基本私密、尚未被"打穿"（[agi.safe.ai](https://agi.safe.ai/)） |
-
- HLE 的问题：无法快速按 ground truth 打分，大家改用 **LLM judge** 评估答案 → 野外结果不可比。
- 用途：MMLU 系列多用于**预训练评测与消融**；后训练用更硬的 GPQA/HLE。
- 作者预测"潜在知识"评测将逐步淡出（训练期仍可用 MMLU-Pro、后训练用 GPQA/HLE），两个原因：
-  1. 对人类越来越**不可读**：题太难，非专家无法理解每题的意义（也无法核查数据集本身有没有错）。
-  2. 模型连上工具（如联网）后，潜在知识评测逐渐变成**搜索与检索评测**——从闭卷考试走向开卷考试（类比法国教育：高中闭卷，大学假设可查数据库/网络，评分更多看"给自由信息后的推理"）。
-
-#### 数学（Math）
-
- 数学评测长期被当作推理与逻辑的代理。
- 参考集：**GSM8K**（2021，[2110.14168](https://arxiv.org/abs/2110.14168)，小学应用题）与 **MATH**（2021，[2103.03874](https://arxiv.org/abs/2103.03874)，网上奥林匹克题聚合），近年已饱和/污染。
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| GSM1K | 2024 | GSM8K 重做 1K 新题，测哪些模型在 GSM8K 上污染（[2405.00332](https://arxiv.org/abs/2405.00332)） |
-| GSM-Plus | — | GSM8K 对抗式改写：干扰项、数值变化等（[2402.19255](https://arxiv.org/pdf/2402.19255)） |
-| GSM-Symbolic | 2024 | 把 GSM8K 改写成问题模板、可无限再生成防污染；用得少但很有意思（[2410.05229](https://arxiv.org/abs/2410.05229)） |
-| MATH-500 | — | 500 题代表性子集，避免过拟合（[HF 数据集](https://huggingface.co/datasets/HuggingFaceH4/MATH-500)）；另有 MATH-Hard（最难的 500 题） |
-| AIME 24/25 | 2024/2025 | 美国高中生奥赛，按发布年原样使用；每年题目难度相当，可用"发布年成绩 vs 上一年度题成绩"测污染（[24](https://huggingface.co/datasets/HuggingFaceH4/aime_2024)、[25](https://huggingface.co/datasets/math-ai/aime25)） |
-| Math-Arena | — | 持续更新的竞赛/奥赛汇总，含 AIME25 及大量其他竞赛（[matharena.ai](https://matharena.ai/)） |
-| FrontierMath | 2024 | 数学家为评测专门撰写的显著更难的题，理论私密（但 OpenAI 疑似接触过部分数据）（[2411.04872](https://arxiv.org/abs/2411.04872)） |
-
- 观察：大多数上述数据集已"没那么难"（止步小学水平，GSM-Symbolic 可生成更多递归层级的题使其合成地变难）；HLE 里也有需复杂推理（含定理证明）的数学题。
- 作者建议：预训练评测用 **AIME25 与 MATH-500**，后训练用 **Math-Arena**。
-
-#### 代码（Code）
-
- 理由：agent 要与工具交互就需要编码能力（代码 agent 直接调工具；code/json agent 都要能调试工具输出，区别见 [agents course](https://huggingface.co/learn/agents-course/en/unit2/smolagents/tool_calling_agents)）；代码评测也是推理的好代理。
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| MBPP | 2021 | 1K 众包 Python 入门题（[2108.07732](https://arxiv.org/abs/2108.07732)） |
-| APPS | 2021 | 10K 来自面试与分享网站的代码生成题（[2105.09938](https://arxiv.org/abs/2105.09938)） |
-| HumanEval | 2021 | 随 Codex 发布、专为发布构造的题 + 防危险代码执行的沙箱 + `pass@k` 估计器（[2107.03374](https://arxiv.org/abs/2107.03374)） |
-| EvalPlus（HumanEval+/MBPP+） | 2023 | 补测试用例、修 bug、加输入（[OpenReview](https://openreview.net/pdf?id=1qvx610Cu7)） |
-| EvoEval | 2024 | HumanEval 语义改写 + 难度标注（[2403.19114](https://arxiv.org/abs/2403.19114)） |
-| LiveCodeBench | 2024 | 记录题目日期，比较训练前后题目的表现——优秀的防污染基准（[2403.07974](https://arxiv.org/abs/2403.07974)） |
-| AiderBench | 2024 底上线 | 用 Exercism 数据，专门测**代码编辑与重构**（[leaderboard](https://aider.chat/docs/leaderboards/)） |
-| RepoBench | 2023 | 仓库级自动补全（Python/Java），跨文件/文件内函数，retrieval/completion/组合多层测试（[2306.03091](https://arxiv.org/abs/2306.03091)） |
-| SWE-Bench | 2024 | GitHub 真实 issue 求解：逻辑理解、跨文件编辑与执行、长上下文推理；推荐高质量子集 **SWE-Bench verified**（[OpenReview](https://openreview.net/pdf?id=VTF8yNQM66)） |
-
- 作者建议关注 LiveCodeBench、AiderBench、SWE-Bench verified，并读 [METR 报告](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) 了解真实代码助手有用性。
-
-#### 长上下文（Long context）
-
- 背景：3 年前最大上下文还是 2048 token，现在普遍 128K 以上。
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| NIAH（Needle in a Haystack） | 2023 | 把随机事实放进长无关文本再检索；可评估模型在上下文何处、多长之后最易遗忘；2023 年表现很差，2025 年接近解决（[gkamradt 仓库](https://github.com/gkamradt/LLMTest_NeedleInAHaystack)） |
-| RULER | 2024 | 多跳追踪（追踪变量链求值）、词频变化、NIAH 的 QA 变体；也接近解决（[2404.06654](https://arxiv.org/pdf/2404.06654)） |
-| Michelangelo / MRCR | 2024 | 多轮共指：精确复现上下文唯一片段、识别相关信息是否存在、理解文本修改序列；OpenAI 2025 扩展为 [OpenAI MRCR](https://huggingface.co/datasets/openai/mrcr)（[2409.12640](https://arxiv.org/pdf/2409.12640v2)） |
-| InfinityBench | 2024 | 中英多语言，100K token 合成数据，覆盖 QA、NIAH 式检索、超长上下文计算等；仍有信号（[2402.13718](https://arxiv.org/abs/2402.13718)） |
-| HELMET | 2024 | 任务与现有基准的大聚合：RAG/QA（Natural Questions、TriviaQA、PopQA、HotpotQA、NarrativeQA、InfinityBench）、recall（RULER、JSONKV）、带引用的生成（ALCE 子集）、摘要、重排（MS MARCO）、ICL（TREC、NLU、Banking77、CLINIC150）；2025 年仍有足够区分度（[2410.02694](https://arxiv.org/abs/2410.02694)） |
-| Novel Challenge | 2024 | 关于近一年出版虚构小说的 1K 真/假判断题，由读者出题，须读完并理解全书（[2406.16264](https://arxiv.org/abs/2406.16264)） |
-| Kalamang 翻译集 | 2024 | 模型须读语法书后把英语译成 Kalamang——仅约 200 使用者的极低资源语言、无网络存在；可扩展到其他低资源语言，并可用规则语法检查器做严格准确率而非 BLEU（[2309.16575](https://arxiv.org/abs/2309.16575)） |
-
- 提醒：聚合基准有**重复测量**风险——别同时测 HELMET 和 InfinityBench 再合并结果（等于同一评测跑两遍）。
-
-#### 指令遵循（Instruction Following）
-
- 两大数据集：**IFEval**（2023，[2311.07911](https://arxiv.org/abs/2311.07911)）与扩展 **IFBench**（2025，[2507.02833](https://arxiv.org/abs/2507.02833)）。
- 作者评价：IFEval 是近几年最聪明的评测思路之一——要求模型遵循**格式指令**（关键词、标点、字数/句数、markdown/html 等文件类型格式），每个条件可用特定解析测试检查。
- 意义：少数**不依赖模型评委也能得到严格分数**的自由生成评测，属功能性正确/单元测试类评测（作者最偏爱的评测方式），也易再生成/扩展防污染。
- 反方向（non-compliance）：**CoCoNot**（2024，[2407.12043](https://www.arxiv.org/pdf/2407.12043)）测模型对不完整（未说明/不清晰）、不可回答（缺信息、AI 化、常触发幻觉）、不安全请求是否会拒绝遵循；人工写 query + 模型写违规请求再过滤，作为分类问题评测。
-
-#### 工具调用（Tool-calling）
-
- 背景：工具的出现是把 LLM 推向 agentic 的关键之一。
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| TauBench | 2024 | 零售与航空领域查询求解（下单/预订/查产品等），合成样本模拟真实领域数据；判对标准：1) 动作正确更新数据库 2) 恰当回答用户；用户由 LLM 模拟（成本高、易错），但贴合真实用例、用得很多（[2406.12045](https://arxiv.org/pdf/2406.12045)） |
-| ToolBench | 2023 | 调 API（OpenWeather、Cat、HomeSearch、TripBooking、GoogleSheets、WebShop、Tabletop 等）解 100 个测试用例，每例需 1–10 次工具调用；部分 API 是 mock、部分真实 → 易意外失败（[2305.16504](https://arxiv.org/pdf/2305.16504)） |
-| StableToolBench | 2025 | 用通用 VirtualAPIServer 全部 mock 保证稳定，但引入 LLM judge 评分（又多一层偏差）（[2403.07714](https://arxiv.org/pdf/2403.07714)） |
-| BFCL | 2025 版 | 4 个子集：单轮简单调用、众包真实用户函数调用、多轮对话、agentic（web 搜索、记忆、SQL 数据交互）；用 AST、执行响应与状态匹配判对；v3 测工具调用、v4 测 web/search 工具（[OpenReview](https://openreview.net/pdf?id=2GmDdhBdDk)） |
-| MCPBench | 2025 | 接真实 MCP 服务器（Wikipedia、HF、Reddit、Steam、arxiv 等），多轮合成任务；规则检查工具调用有效性 + LLM judge 评回答（[2508.20453](https://arxiv.org/abs/2508.20453)） |
-| MCP-Universe | 2025 | 11 个真实主题 MCP 服务器（IRL 导航、3D 设计、web 搜索等）；多个严格评估器（格式 + 两个答案正确性）；动态任务用**基于任务执行的框架**自动抓最新正确答案对比——比 LLM judge 干净得多（[2508.14704](https://arxiv.org/abs/2508.14704)） |
-| LiveMCPBench | 2025 | 大规模本地可部署 MCP 服务器集合，测模型在工具间分辨挑选的能力；最强模型已到 80%，接近饱和；"超长工具列表中选对工具"会随 web mcp 化越来越重要（[2508.01780](https://arxiv.org/abs/2508.01780)） |
-
- 附：[Anthropic 的"为 agent 写工具"文档](https://www.anthropic.com/engineering/writing-tools-for-agents)。
- 过渡语：单项能力评测有价值，但真实助手表现来自能力组合——推理必须与工具调用、长上下文管理同时进行，所以需要"多能力编排"的评测。
-
-### 助手任务（Assistant tasks）
-
- 作者认为这是下一代评测的主流方向：解一个助手任务需组合大量能力（长上下文、推理、工具调用…），同时具体领域表现被放进真实有用场景；比单项能力基准**更易懂**。
- 足够通用时，不检查用了什么具体工具，只看**最终结果对不对**（复杂任务有多条成功路径）。
-
-#### 真实信息检索（Real life information retrieval）
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| GAIA | 2023 | 开创现代 agentic 评测——组合工具、推理、检索解真实查询（有时含文档）；3 个难度级别，第一级已饱和、第三级仍难；公开榜见 [leaderboard](https://huggingface.co/spaces/gaia-benchmark/leaderboard)；分数因评测方式（公开验证集 vs LLM judge 评私有测试集）差异很大（[2311.12983](https://arxiv.org/abs/2311.12983)） |
-| BrowseComp | 2025 | 测同样的事（用工具与在线信息找到具体查询的答案），但**结果不保证唯一**——从结果反推构造问题（如"哪篇关于 Topic 的论文发表在 Conference，作者含一位 Nationality 与两位 Entity 的人？"），多难度；目前可能更难（[OpenAI PDF](https://cdn.openai.com/pdf/5e10f4ab-d6f7-442e-9508-59515c65e35d/browsecomp.pdf)） |
-| GAIA2 | — | 用模拟移动环境，测助手靠事件链与工具调用正确回答查询；对 SOTA 模型，搜索与执行已极容易，**时间敏感与刻意加噪（模拟 API 失败）子集**最难（[HF 博客](https://huggingface.co/blog/gaia2)） |
-
-#### 科学助手（Science assistants）
-
-| 数据集 | 年份 | 说明（链接） |
-|---|---|---|
-| SciCode | 2024 | 跨 STEM 领域用写科学代码解真实科研问题；核心问题分解为子问题；初版由科学家 + 模型评委评分，发布时模型表现很差（<5%）（[2407.13168](https://arxiv.org/abs/2407.13168)） |
-| PaperBench | 2025 | 复现 ML 研究——给定 ICML 高质量论文重建对应代码库（论文作者贡献 8K 个分级任务，rubric 树加权计总分）；LLM judge 评分（作者怀疑部分可约束代码形态来自动化）（[2504.01848](https://arxiv.org/abs/2504.01848)） |
-| DSBench | 2025 | Kaggle + ModelOff（金融数据）的多模态数据分析；ModelOff 题以多选题形式给出（可能变简单），Kaggle 每题有自己的指标（[2409.07703](https://arxiv.org/pdf/2409.07703)） |
-| DABStep | 2025 | 用此前私密（未污染）的真实运营数据分析工作负载 + 真实问题与数据；全部需多步推理、多样文档解析、特定数据操作；难、贴近真实、每题有 ground truth → 评测无偏且不算贵（[2506.23719](https://arxiv.org/abs/2506.23719)） |
-
-### 游戏化评测（Game-based evaluations）
-
- 价值：测对**变化环境的适应**（多数助手任务是静态的）、需长上下文推理、**人人都能看懂**。
- 缺点：不扎根真实生活、未必反映真实有用场景的表现。
- **ARC-AGI**（[arcprize.org](https://arcprize.org/arc-agi)）：2019 初版是网格拼图序列，无显式规则，找序列最后一项；非常像逻辑导向的 IQ 测试；2024 年几乎被解决。
- **Baba is AI**（2024，[2407.13729](https://arxiv.org/abs/2407.13729)）：同类规则外推基准。
- **ARC-AGI3**（2025，进行中）：整批新游戏（探索、复杂规划、记忆管理等），当前最佳解还在暴力破解。
- 单机冒险/RPG：**TextQuests**（2025，[HF 博客](https://huggingface.co/blog/textquests)）、**Pokemon**（2024，[benchflow 仓库](https://github.com/benchflow-ai/benchflow/tree/main/libs/pokemon-gym)；Claude 与 Gemini 都有 Twitch 直播：[Claude plays Pokemon](https://www.twitch.tv/claudeplayspokemon)、[Gemini plays Pokemon](https://www.twitch.tv/gemini_plays_pokemon)）——需超长规划、长上下文记忆管理、推理、回溯。
- 生存游戏：**Crafter**（2021，[2109.06780](https://arxiv.org/abs/2109.06780)，Minecraft 启发）。
- 环境整合：**Balrog**（2024，[2411.13543](https://arxiv.org/pdf/2411.13543)）整合了多个单人游戏环境。
- 竞争性虚张声势游戏（测逻辑、推理与**欺骗**）：
-  - **Poker**（2025，[2501.08328](https://arxiv.org/html/2501.08328v1)）。
-  - **Town of Salem**（2025，[仓库](https://github.com/summersonnn/Town-Of-Salem-with-LLMs)）。
-  - **Werewolf 狼人杀**（2025，[2407.13943](https://arxiv.org/abs/2407.13943) / [网站](https://werewolf.foaster.ai/)）。
-  - 例：Claude Opus 4 当狼人杀里的吸血鬼（欺骗角色）赢不了，但当农民（非欺骗角色）表现好。
- 合作游戏 **Hanabi**：测受限环境下的适应与沟通。
- 优势：单一明确的 **pass/fail 指标**（赢没赢）。
- 作者当前建议：能力看 TextQuests，安全看 Town of Salem。
-
-### 预测类评测（Forecasters）
-
- 背景：去年新出现的、**本质上无法污染**的任务类别（股票市场预测理论上可被操纵，但希望还没到为搞坏评测而作弊的激励程度）。
- 定位：需跨来源推理回答尚未发生事件的问题；但不确定区分度是否够强，且可能强化 LLM 的"老虎机式成功"观感——事件上接近随机：因为不可预测还是模型差？反过来，预测对了：题太简单还是太模板化？
-
-| 数据集 | 说明（链接） |
-|---|---|
-| FutureBench | 预测未来有新闻价值的事件；两个来源——浏览 + LLM 每周时间窗生成问题，以及博彩市场的用户预测；数据重度过滤清洗；模型在人类博彩题上勉强优于随机，在模型生成题上 3/4 成功（后者更简单）（[HF 博客](https://huggingface.co/blog/futurebench)） |
-| FutureX | 用一系列特定网站（预测市场、政府网站、通用排名网站、实时数据平台），模板生成未来事件问题（"STOCK 何时到达 POINT？"）；每日生成 500 题并过滤意外无关题（[2508.11987](https://arxiv.org/abs/2508.11987)） |
-| Arbitrage | 类似生成方式，核心差异是时间窗——事件须在 2028 年前解决（[2412.18544](https://arxiv.org/pdf/2412.18544)） |
-
-### 2025 年 9 月的推荐评测组合
-
-| 用途 | 推荐评测 |
-|---|---|
-| 核心能力（模型构建者） | 训练期用旧能力评测；后训练用 MATH500/AIME24、GPQA、IFEval、SWE-Bench；长程评测选一个如 HELMET；面向工具用 TauBench 或 BFCL |
-| 核心能力（推理期对比模型） | IFBench、HLE、MathArena、AiderBench 与 LiveCodeBench、MCP-Universe |
-| 长时程任务（真实世界表现） | GAIA、DABStep、SciCode 或针对自己用例的领域评测 |
-| 游戏（测鲁棒性与适应性的趣味补充） | ARC-AGI3（发布后）、TextQuests；安全相关看 Town of Salem；或任何超越 Poker/Chess/Go 的游戏 |
-
-### 结语
-
- 领域正从"测孤立技能"走向"测能力编排"以服务真实使用，契合"构建 work well 的模型"的目标。
- 作者希望未来评测更重视**功能性测试**而非模型评委，并保持数据集与任务的可理解性。
+- **单一能力评测**：推理与常识（ARC/WinoGrande 等历史数据集，只适合消融与预训练）；知识（MMLU 已饱和，改用 GPQA/HLE）；数学（GSM8K/MATH 饱和，预训练用 AIME25+MATH-500、后训练用 Math-Arena）；代码（关注 LiveCodeBench、AiderBench、SWE-Bench verified）；长上下文（NIAH 接近解决，HELMET 有重复计量风险）；指令遵循（IFEval/IFBench，少数不依赖模型评委的严格评测）；工具调用（TauBench/BFCL/MCP 系基准）。
+- **助手任务**（下一代评测主流方向）：GAIA/BrowseComp 真实信息检索、SciCode/PaperBench/DABStep 科学助手——设计得够通用时只看最终结果对不对。
+- **游戏化评测**：ARC-AGI/TextQuests/Pokemon/Town of Salem，单一 pass/fail 指标；作者建议能力看 TextQuests、安全看 Town of Salem。
+- **预测类评测**（本质上无法污染）：FutureBench/FutureX/Arbitrage，但区分度存疑。
+- **推荐评测组合**：旧版"2025 年 9 月"版已被新版 §3 的"2025 年 11 月"版取代，直接看 [[08-2025-Edition]] §3 末尾。
+- **结语**：领域正从"测孤立技能"走向"测能力编排"，更重视功能性测试而非模型评委。

 ---

@@ -539,4 +370,4 @@ source: https://github.com/huggingface/evaluation-guidebook
 - 2025 原文（GitHub）：[yearly_dives/2025-evaluations-for-useful-models.md](https://github.com/huggingface/evaluation-guidebook/blob/main/yearly_dives/2025-evaluations-for-useful-models.md)
 - 指南仓库：[huggingface/evaluation-guidebook](https://github.com/huggingface/evaluation-guidebook)

-相关：[[00-Overview]] · [[07-Resources]]
+相关：[[00-Overview]] · [[07-Resources]] · 新版对应：[[08-2025-Edition]]
@@ -118,6 +118,8 @@ article.mdx（组装层，含正文过渡小节、saturation/contamination 定

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

+> 旧版对应：[[06-Yearly-Dives]] 的 2025 节（旧版压缩摘要，含旧版独有的"核心论点"）。
+
 > 新版先给出两个贯穿全篇的核心概念（来自 article.mdx 的 "Evaluating with existing benchmarks" 引言）：
 >
 > - **Saturation（饱和）**：模型在 benchmark 上的表现超过人类表现。更广义地指数据集失去模型间区分力、不再有用——"如果所有模型分数都接近最高分，它就不再是 discriminative benchmark，就像拿学前班题目考高中生：成功说明不了什么（虽然失败能说明问题）"。
@@ -273,6 +275,8 @@ article.mdx（组装层，含正文过渡小节、saturation/contamination 定

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

+> 旧版对应：[[01-Automatic-Benchmarks]] §3（设计自动评测）与 §4（常用评测数据集盘点，新版不再渲染正文）。
+
 新版把"设计自动评测"重写为完整方法论。**与旧版不同的章节结构**（原文实际顺序）：

 ```
@@ -32,6 +32,7 @@ created: 2026-08-21
 | 4 | [[02-First-Week-Worksheet\|首周工作表]] | 今天应该写什么，卡住时怎样缩小范围？ | 完成任务边界、10 个 case 与 rubric v0.1。 |
 | 5 | [[01_Projects/Personal-Tech/LLM_Evaluation/03-Practice/README\|项目实践入口]] | 如何把工作表变成自己的项目仓库？ | 开始一个最小项目并保存第一个 run。 |
 | 6 | [[01-LLM-Evaluation-Roadmap\|LLM 评测工程实战路线图]] | 怎样逐步走向 Judge、Agent、安全、数据资产与 CI？ | 为自己选择一个 12 周内的下一阶段。 |
+| 7 | [[01-Learning-Board\|学习看板]] | 我学到哪了？还差哪个闭环？ | 能勾选当前 Level 的全部条目。 |

 > **数量口径：** 首周最低完成 10 个 case；若时间充裕，按路线图 Day 1 扩展至 20 个（结构见《首周工作表》第 2 节）。

@@ -56,7 +57,7 @@ created: 2026-08-21

 ## 你的当前入口

-打开 [[00-Start-Here|开始这里]]，完成其中的十分钟动作；完成后再填写 [[02-First-Week-Worksheet|首周工作表]]。
+打开 [[00-Start-Here|开始这里]]，完成其中的十分钟动作；完成后再填写 [[02-First-Week-Worksheet|首周工作表]]。想追踪进度时，对照 [[01-Learning-Board|学习看板]] 勾选闭环条目。

 ## 关联材料

@@ -66,3 +67,4 @@ created: 2026-08-21
 - 评测工程资源地图：[[04-Reference/README|04-Reference 资源地图]]（五层能力框架与推荐精读顺序）
 - 外部权威知识参考：[[04-Reference/evaluation-guidebook/00-Overview|HuggingFace Evaluation Guidebook 中文提炼]]（自动基准 / 人工评测 / LLM-as-judge / 排错，按主题查阅）
 - 外部精选资源（已归档）：[[04-Reference/archive/01-Curated-External-Resources|精选外部评测资源]]（顶级大厂与开源组织的生产级方案、评测基建与硬核课程源码）
+- 归档总索引：[[04-Reference/archive/00-Material-List|材料清单与归档说明]]（早期草案与外部参考的定位总览）