reconcile LLM_Evaluation zone: align stage numbering and scopes, standardize full-path wikilinks, slim old guidebook notes, dedupe templates
- fix stage-numbering conflict (README vs 05-Progress) and unify stage-1 reading scope - resolve AWS workshop prerequisite contradiction in 04-Reference/01 - convert medium-path wikilinks to vault-root paths (~30 links), fix .pyy typos, annotate ragas fork, unify archive status, add 01-/02- README hubs - compress old-version guidebook notes (01, 05) into pointers; add 2026 reading guidance to 00-Overview - dedupe project templates and remove embedded template copy in 03-Practice/README
This commit is contained in:
windyboy
+9
@@ -70,6 +70,15 @@ source: https://github.com/huggingface/evaluation-guidebook
|
||||
|
||||
文内标记 ⭐ 的链接是作者特别推荐阅读的资源。
|
||||
|
||||
### 2026 起：主入口与旧版独有内容
|
||||
|
||||
- **主入口是 [[08-2025-Edition]]（新版提炼）**；日常查阅先看它。
|
||||
- 旧版 01–07 只在你需要"旧版独有细节"时查阅：
|
||||
- [[02-Human-Evaluation]]（标注者组织与实操细节）、[[03-LLM-as-a-Judge]]（judge 详述、模板与 FAQ）、[[04-Troubleshooting]]（推理排错 + LaTeX/sympy 解析）、[[07-Resources]]（资源清单）为细节版；
|
||||
- [[01-Automatic-Benchmarks]] 保留 §4 数据集大表与 §5 实战技巧（§1–§3 已被新版覆盖）；[[05-General-Knowledge]] 保留 tokenization 细节（§1 已被新版覆盖）；
|
||||
- [[06-Yearly-Dives]] 保留 2023/2024 年度回顾。
|
||||
- 与新版重叠的旧版正文已压缩为指针，不再重复维护。
|
||||
|
||||
## 与本专区的关系
|
||||
|
||||
- 本专区（LLM_Evaluation）是**面向个人学习与工程能力养成**的中文路线（概念 → 为什么 → 工作表 → 项目 → 完整路线图）。
|
||||
|
||||
+21
-204
@@ -18,13 +18,11 @@ source: https://github.com/huggingface/evaluation-guidebook
|
||||
>
|
||||
> **关联笔记**：[[02-Human-Evaluation]]（人工评测）、[[03-LLM-as-a-Judge]]（模型作评委）、[[04-Troubleshooting]]（排错与可复现性）。
|
||||
>
|
||||
> ⚠️ **旧版内容**（2024 GitHub 仓库）。设计自动评测的新版对应：[[08-2025-Edition]] §5；「常用评测数据集盘点」在新版中不再渲染正文（仅保留仓库资产），本节 §4 作为旧版独有细节保留。
|
||||
> ⚠️ **旧版内容**（2024 GitHub 仓库）。本页 §1–§3（核心概念 / 优缺点 / 设计流程）与新版重叠，已压缩为指针；保留的旧版独有内容为 **§4 常用评测数据集盘点** 与 **§5 实战技巧**（新版 §5 覆盖设计流程，但数据集大表与部分技巧仅旧版有）。
|
||||
|
||||
## 目录
|
||||
|
||||
- [1. 核心概念](#1-核心概念task--capability--dataset--metric--样本--泛化)
|
||||
- [2. 自动化基准的优缺点](#2-自动化基准的优缺点)
|
||||
- [3. 如何设计自己的自动评测](#3-如何设计自己的自动评测)
|
||||
- [1–3. 核心概念 / 优缺点 / 设计流程（已压缩，见新版）](#1-3-核心概念--优缺点--设计流程已压缩见新版)
|
||||
- [4. 常用评测数据集盘点](#4-常用评测数据集盘点)
|
||||
- [5. Tips and Tricks](#5-tips-and-tricks)
|
||||
- [6. 参考资料](#6-参考资料)
|
||||
@@ -33,212 +31,31 @@ source: https://github.com/huggingface/evaluation-guidebook
|
||||
|
||||
## 速览（TL;DR）
|
||||
|
||||
| 问题 | 一句话答案（详见对应章节） |
|
||||
> 下列要点在新版 [[08-2025-Edition]] 中都有对应小节，此处仅保留一句话答案。
|
||||
|
||||
| 问题 | 一句话答案（详见新版对应小节） |
|
||||
|---|---|
|
||||
| 自动基准评测是什么？ | 用「数据集（输入+gold 参考）+ metric」给模型在 task / capability 上打分；LLM 输出分两类：生成文本（generative）与序列 log-probability（MCQA / perplexity）。（[§1](#1-核心概念task--capability--dataset--metric--样本--泛化)） |
|
||||
| 为什么要测模型没见过的数据？ | 测的是泛化（generalization）；在训练数据上评测等于给模型不具备的能力打分（overfitting 的学生类比）。（[§1](#1-核心概念task--capability--dataset--metric--样本--泛化)） |
|
||||
| 自动化基准有什么优势？ | 一致可复现、成本低、指标可理解、可用专家级高质量数据（但 MMLU 也有错 → MMLU-Pro/Redux）。（[§2](#2-自动化基准的优缺点)） |
|
||||
| 有什么短板？ | 复杂能力难分解成精确任务（转向 generalist 评测、性能当 proxy）；公开数据集必有 contamination。（[§2](#2-自动化基准的优缺点)） |
|
||||
| 评测结果好坏取决于什么？ | 取决于评测数据集质量——选数据集要看创建者、标注者一致性、指南、随机抽 50 个样本检查；自建可走聚合/人工标注/合成（LLM 或规则）三条路。（[§3.1](#31-选择数据集)） |
|
||||
| 用 log-prob 还是生成式？ | 多选题/测知识 → log-prob（快、能给置信度，但高估小模型、对选项顺序敏感）；测流利度/推理 → 生成式（更贴近真实关注点，但难打分、更贵）。（[§3.2](#32-选择推理方法inference-method)） |
|
||||
| prompt 要注意什么？ | 语义等价的微小改动会让结果波动；模型会过拟合 prompt 格式（Llama 3.2 / Qwen 2.5 在 few-shot 里不跟格式）；必要时约束输出。（[§3.3](#33-选择提示词prompt)） |
|
||||
| 代码评测的聪明做法？ | 功能测试：用单元测试验证生成程序（降低过拟合、测主动能力）；文本版代表是 IFEval。（[§3.5](#35-智能新任务功能测试functional-testing)） |
|
||||
| 数据污染怎么办？ | 默认「已污染」；用 canary string、加密/门控发布、动态 benchmark、事后检测（无万全之法）。（[§5.1](#51-管理污染managing-contamination)） |
|
||||
| 评测结果意外差？ | 先看生成结果：解析太严、few-shot 不跟格式、模型太啰嗦，逐一排查。（[§5.3](#53-生成式评测结果异常差时的排查)） |
|
||||
| 自动基准评测是什么？ | 用「数据集（输入+gold 参考）+ metric」给模型在 task / capability 上打分；LLM 输出分两类：生成文本（generative）与序列 log-probability（MCQA / perplexity）。（[[08-2025-Edition]] §4） |
|
||||
| 为什么要测模型没见过的数据？ | 测的是泛化（generalization）；在训练数据上评测等于给模型不具备的能力打分（overfitting 的学生类比）。（[[08-2025-Edition]] §4） |
|
||||
| 自动化基准有什么优势？ | 一致可复现、成本低、指标可理解、可用专家级高质量数据（但 MMLU 也有错 → MMLU-Pro/Redux）。（[[08-2025-Edition]] §5.5） |
|
||||
| 有什么短板？ | 复杂能力难分解成精确任务（转向 generalist 评测、性能当 proxy）；公开数据集必有 contamination。（[[08-2025-Edition]] §3） |
|
||||
| 评测结果好坏取决于什么？ | 取决于评测数据集质量——选数据集要看创建者、标注者一致性、指南、随机抽 50 个样本检查；自建可走聚合/人工标注/合成（LLM 或规则）三条路。（[[08-2025-Edition]] §5.1–5.3） |
|
||||
| 用 log-prob 还是生成式？ | 多选题/测知识 → log-prob（快、能给置信度，但高估小模型、对选项顺序敏感）；测流利度/推理 → 生成式（更贴近真实关注点，但难打分、更贵）。（[[08-2025-Edition]] §5.4） |
|
||||
| prompt 要注意什么？ | 语义等价的微小改动会让结果波动；模型会过拟合 prompt 格式（Llama 3.2 / Qwen 2.5 在 few-shot 里不跟格式）；必要时约束输出。（[[08-2025-Edition]] §5.4、§5.11） |
|
||||
| 代码评测的聪明做法？ | 功能测试：用单元测试验证生成程序（降低过拟合、测主动能力）；文本版代表是 IFEval。（[[08-2025-Edition]] §5.8） |
|
||||
| 数据污染怎么办？ | 默认「已污染」；用 canary string、加密/门控发布、动态 benchmark、事后检测（无万全之法）。（本页 §5.1） |
|
||||
| 评测结果意外差？ | 先看生成结果：解析太严、few-shot 不跟格式、模型太啰嗦，逐一排查。（本页 §5.3） |
|
||||
|
||||
---
|
||||
|
||||
## 1. 核心概念：task / capability / dataset / metric / 样本 / 泛化
|
||||
## 1–3. 核心概念 / 优缺点 / 设计流程（已压缩，见新版）
|
||||
|
||||
自动化基准（automated benchmark）通常这样工作：你希望知道模型在某件事上表现如何。这件事可以是：
|
||||
旧版 §1（核心概念）、§2（优缺点）、§3（设计自动评测）的正文与新版大幅重叠，已压缩为指针：
|
||||
|
||||
- 一个定义清晰的**具体任务（task）**，例如「我的模型能不能区分垃圾邮件与非垃圾邮件（spam / non-spam classification）？」；
|
||||
- 一个更抽象、更一般的**能力（capability）**，例如「我的模型数学能力如何（How good is my model at math）？」。
|
||||
|
||||
### 评测的三要素
|
||||
|
||||
1. **数据集（dataset）**，由**样本（samples）**组成：
|
||||
- 每个样本包含给模型的**输入（input）**，有时配一个用来比对输出的**参考答案（reference，也称 gold）**；
|
||||
- 样本通常刻意设计成贴近你要测的东西：例如做邮件分类，就构造一批垃圾/非垃圾邮件数据集，尽量包含一些难的边界案例（edge cases）。
|
||||
2. **度量（metric）**：给模型打分的方式。
|
||||
- 示例：垃圾邮件分类的准确率（正确分类的样本记 1 分，错误记 0 分）；
|
||||
- metric 利用模型输出打分。对 LLM 而言，人们主要考虑两类输出：
|
||||
- 模型根据输入**生成的文本**（*generative evaluation*，生成式评测）；
|
||||
- 提供给模型的**一个或多个序列的 log-probability**（*multiple-choice evaluations*，简称 MCQA；或 *perplexity evaluations*，困惑度评测）。
|
||||
- 更多细节见 [Model inference and evaluation](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) 页面。
|
||||
|
||||
### 泛化（generalization）与过拟合（overfitting）
|
||||
|
||||
- 评测最好在**模型从未见过的数据**（不在其训练集里的数据）上进行，因为你测的是它能否**泛化（generalize）**——例如：模型只见过「假银行」类垃圾邮件后，能否正确分类「保健品」类垃圾邮件。
|
||||
- **overfitting**：模型只能在训练数据上预测得好、没有学到更高级的通用模式，就称其过拟合。这就像学生把考题背下来却没理解知识点——**在训练集中已经出现过的数据上评测 LLM，等于给它不会的能力打分**。
|
||||
|
||||
---
|
||||
|
||||
## 2. 自动化基准的优缺点
|
||||
|
||||
### 优点
|
||||
|
||||
| 优点 | 说明 |
|
||||
|---|---|
|
||||
| **一致性与可复现性（Consistency and reproducibility）** | 同一 benchmark 在同一个模型上跑 10 次结果相同（除硬件差异或模型固有随机性外）。因此可以方便地为给定任务建立公平的模型排名。 |
|
||||
| **低成本规模化（Scale at limited cost）** | 目前最廉价的评测模型方式之一。 |
|
||||
| **可理解性（Understandability）** | 大多数自动化指标非常易懂：exact match 告诉你生成文本是否与参考完全一致；accuracy 告诉你选对选项的次数占比。（相比而言 `BLEU`、`ROUGE` 这类指标就没那么直观。） |
|
||||
| **数据集质量（Dataset quality）** | 不少 benchmark 使用专家生成的数据集或已有的高质量数据（如 MMLU、MATH）。但高质量 ≠ 完美：MMLU 事后被发现样本中有若干错误（从解析问题到实际上无意义的问题），催生了 MMLU-Pro、MMLU-Redux 等后续数据集。 |
|
||||
|
||||
### 局限
|
||||
|
||||
1. **对复杂任务的使用受限**：自动化基准擅长性能容易定义和评估的任务（如分类）。更复杂的能力很难分解成定义清晰、精确的子任务。
|
||||
- 例如「数学好」到底指什么？算术好？逻辑好？能对新数学概念推理？
|
||||
- 这催生了更多**通用型（generalist）评测**：不再把能力拆成子任务，而是假设整体表现是所测目标的**良好代理指标（good proxy）**。
|
||||
2. **污染（Contamination）**：数据集一旦以纯文本形式公开，就会进到模型训练数据里。因此打分时你无法保证模型没解析过评测数据。
|
||||
|
||||
---
|
||||
|
||||
## 3. 如何设计自己的自动评测
|
||||
|
||||
核心原则：**你的评测结果只会和你的评测数据集一样好（your evaluation result will only be as good as your evaluation dataset）**。
|
||||
|
||||
#### 设计自动评测的完整流程（对照清单）
|
||||
|
||||
把原文的设计建议串成一条可执行的流程，每个步骤的细节见对应小节：
|
||||
|
||||
1. **明确要测什么**：具体 task（如垃圾邮件分类）还是抽象 capability（如数学能力）？（[§1](#1-核心概念task--capability--dataset--metric--样本--泛化)）
|
||||
2. **选或建数据集**：优先复用已有高质量数据集；自建可走聚合现有数据 / 人工标注 / 合成数据（LLM 生成或基于规则）。（[§3.1](#31-选择数据集)）
|
||||
3. **检查样本**：已有数据集看创建者与标注流程（专家 > 付费 ≈ 众包 > MTurk）、标注者一致性、创建指南；随机抽 50 个样本查质量与相关性；样本数 ≥ 100 才统计显著。（[§3.1](#31-选择数据集)）
|
||||
4. **选推理方法**：MCQA（log-probabilities）还是生成式（generative）？（[§3.2](#32-选择推理方法inference-method)）
|
||||
5. **设计 prompt**：task prompt / context / question / options / connector words；注意 prompt 敏感性、few-shot、格式过拟合。（[§3.3](#33-选择提示词prompt)）
|
||||
6. **选 metric**：log-prob 侧用按长度归一化的 accuracy / perplexity / recall / f1；生成侧先决定是否归一化、再决定匹配方式（exact match、ROUGE、BLEU…）；想清楚任务到底关心平均还是最差表现。（[§3.4](#34-选择度量metric)）
|
||||
7. **跑评测 + 复盘**：检查生成结果（解析、格式遵循、长度），关注 contamination 与 tokenization 坑。（[§5](#5-tips-and-tricks)）
|
||||
|
||||
### 3.1 选择数据集
|
||||
|
||||
要么选已有数据集（见 [第 4 节](#4-常用评测数据集盘点)），要么自己设计。过程中必须紧盯上面这条原则。
|
||||
|
||||
#### 选用已有数据集：必须检查的组件
|
||||
|
||||
**（1）创建过程（Creation process）**
|
||||
|
||||
- **样本是谁创建的？** 作者给出的质量排序（作者观点）：
|
||||
> 专家创建（expert created）> 付费标注者（paid annotator）≈ 众包（crowdsourced）> MTurk 标注
|
||||
- 找数据卡（data card），看**标注者人口学信息（annotator demographics）**——对理解数据集的语言多样性很重要。
|
||||
- **样本是否被其他标注者或作者复核过？** 要确认：标注者间一致性分数（inter-annotator score）是否高（标注者是否达成共识）、以及/或作者是否审查过整个数据集。
|
||||
- 这对「用低薪标注者（通常不是你目标语言的母语者，如 AWS Mechanical Turk）」的数据集尤其重要，否则你可能发现拼写错误/语法错误/无意义答案。
|
||||
- **标注者是否拿到清晰的数据创建指南（data creation guidelines）？** 换句话说：你的数据集一致吗？
|
||||
|
||||
**（2）样本（Samples）**
|
||||
|
||||
取 50 个随机样本人工检查：
|
||||
|
||||
- *质量（quality）*：
|
||||
- prompt 是否清晰无歧义？
|
||||
- 答案是否正确？（例：TriviaQA 每个问题有多个 gold 答案（aliases 字段），有时互相冲突。）
|
||||
- 信息是否缺失？（例：MMLU 的不少问题缺少参考示意图（reference schematics）。）
|
||||
- *与任务的相关性（relevance）*：
|
||||
- 这些是你想用 LLM 评测的问题类型吗？
|
||||
- 这些例子与你的 use case 相关吗？
|
||||
|
||||
还要知道数据集有多少样本（保证结果统计显著——**自动基准评测通常最少 100 个样本**）。
|
||||
|
||||
#### 设计自己的数据集：三条路线
|
||||
|
||||
| 路线 | 要点 |
|
||||
|---|---|
|
||||
| **聚合现有数据（Aggregating existing data）** | 从不同来源聚合现有数据，评估与任务相关的能力。很多评测数据集就是这样从人工评测数据集聚合而来的（如 MATH、LSAT 等）。走这条路同样要执行上面「检查样本」的步骤。 |
|
||||
| **使用人工标注者（Using human annotators）** | 完整章节见 [Using human annotators](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/human-evaluation/using-human-annotators.md)（人工评测章节）。 |
|
||||
| **使用合成数据（Using synthetic data）** | 分两种： |
|
||||
| ├ **用 LLM 生成** | ⭐ 参考 [Cosmopedia](https://huggingface.co/blog/cosmopedia) 博客（HF 同事写的，很酷）：主要研究如何造合成*训练*集，但类似技术可用于评测。生成后务必按上面的步骤人工检查/过滤/审查。 |
|
||||
| └ **基于规则的技巧（rule-based）** | 如果任务允许，这是获得**几乎无限样本且避免污染**的好办法。示例：[NPHardEval](https://arxiv.org/abs/2312.14890)、[DyVal](https://arxiv.org/abs/2309.17167)、[MuSR](https://arxiv.org/abs/2310.16049)、[BabiQA](https://arxiv.org/abs/1502.05698) 等。 |
|
||||
|
||||
### 3.2 选择推理方法（inference method）
|
||||
|
||||
#### 基于 log-probabilities（MCQA 多选题）
|
||||
|
||||
非常适合选择题（通常测模型知识、或消歧能力）。
|
||||
|
||||
| 优点 | 缺点 |
|
||||
|---|---|
|
||||
| 确保所有模型都能「看到」正确答案 | 轻微高估小模型（若放任自由生成，它们本会生成选项范围之外的内容） |
|
||||
| 提供模型「置信度」（calibration）的代理 | 有些模型会[根据选项的呈现顺序偏好特定选项](https://arxiv.org/abs/2309.03882)，导致评测不具代表性 |
|
||||
| 评估快——尤其只让模型预测一个 token（A/B/C/D 选项序号，或 Yes/No）时 | |
|
||||
| 小模型也能获得任务表现信号 | |
|
||||
|
||||
#### 基于生成（generative / QA 问答）
|
||||
|
||||
适合任何要测流利度（fluency）、推理能力、或模型真正回答问题的能力的任务。
|
||||
|
||||
| 优点 | 缺点 |
|
||||
|---|---|
|
||||
| 应该与 LLM 生成流利文本的能力真实相关，多数时候正是人们真正关心的 | 打分更难（见 3.4 metrics 一节） |
|
||||
| | 通常比 log-likelihood 评测贵一点，尤其包含 sampling 时 |
|
||||
|
||||
### 3.3 选择提示词（prompt）
|
||||
|
||||
prompt 决定：给模型多少任务信息、这些信息如何呈现。
|
||||
|
||||
一个通用 MCQA / QA prompt 通常由以下部分构成：
|
||||
|
||||
- **task prompt**（可选）：介绍你的任务；
|
||||
- **context**：为问题提供额外上下文（例：摘要或信息抽取任务可提供内容来源）；
|
||||
- **question**：prompt 的核心；
|
||||
- **options**（多选题时）：选项；
|
||||
- **连接词（connector words）**：如 `Question`、`Context`、`Choice` 等。
|
||||
|
||||
把这些要素拼成模板（示意，字段顺序与措辞可自行设计）：
|
||||
|
||||
```text
|
||||
Task: {task prompt} # 可选：介绍任务
|
||||
Context: {context} # 可选：为问题提供额外上下文（摘要/信息抽取时可给内容来源）
|
||||
Question: {question} # 核心
|
||||
Choice A: {option_a} # 多选题时提供选项
|
||||
Choice B: {option_b}
|
||||
Choice C: {option_c}
|
||||
Answer: # 用连接词引导模型输出
|
||||
```
|
||||
|
||||
> 注意：上面只是结构示意，原文没有给出固定模板——不同模型对格式的敏感度不同，实际使用时按 3.3 的提示设计并验证。
|
||||
|
||||
设计 prompt 时要注意：
|
||||
|
||||
1. **语义等价的微小改动也可能让结果波动很大**（见 [Troubleshooting reproducibility](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/troubleshooting/troubleshooting-reproducibility.md) 的「Different prompt」一节），且 prompt 格式可能利好或利空特定模型。
|
||||
- 缓解方法：
|
||||
- **昂贵方案**：用多种 prompt 变体把评测多跑几遍；
|
||||
- **省钱方案**：只跑一次，但把一批**难度相当的不同 prompt 格式**分配到不同样本上。
|
||||
2. 可以给模型提供**few-shot 示例**帮它遵守期望格式；加连接词也有帮助。
|
||||
3. 但**模型如今倾向于过拟合特定 prompt 格式**：
|
||||
- ⭐ [这篇论文](https://arxiv.org/abs/2407.07890) 讲得很好：有些模型因为过拟合了测试集的**格式（format）**而被高估。
|
||||
- 在 Open LLM Leaderboard 2 上，作者观察到 Llama 3.2 和 Qwen 2.5 出于这个原因，在 few-shot 设置下不再遵循给定 prompt 的格式。
|
||||
4. 对不少 metric 来说，你需要**高度受约束的生成/输出**（详见 [Model inference and evaluation](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) 的 `Constraining model outputs` 一节）。
|
||||
|
||||
### 3.4 选择度量（metric）
|
||||
|
||||
**基于 log-probabilities** 时，metric 很简单：看 **accuracy**（最可能的选项是最佳选项的频率）。重要：要**按长度归一化**（按字符 character、token、或 pmi）。也可以看 perplexity、recall、f1。
|
||||
|
||||
**生成式评测（generative）** 时可选 metric 范围更广，需要两步决策：
|
||||
|
||||
1. **比较生成结果前是否先归一化（normalize）？**
|
||||
- 归一化设计得不好时[很容易不公平](https://huggingface.co/blog/open-llm-leaderboard-drop)，但总体上在任务层面仍提供信号；
|
||||
- 对特定任务非常重要，如数学评测：你可能要从格式化输出中抽取结果；
|
||||
- 如果要叠加 Chain of Thought 等机制测准确率，也要归一化——你需要把推理痕迹（reasoning trace）从实际结果中剥离。
|
||||
2. **如何把生成与参考做比较？**
|
||||
- 从基于匹配的 metric（exact match、prefix match 等）到摘要/翻译类 metric（ROUGE、BLEU、character n-gram 比较）都可以；
|
||||
- 现有 metric 列表见 ⭐ [lighteval 的 Metric List wiki](https://github.com/huggingface/lighteval/wiki/Metric-List)（作者表示之后会补「何时用哪个 metric」一节）。
|
||||
|
||||
**更一般的原则**：选 metric 时要想清楚任务真正关心什么。有些领域（如医疗、有公共交互的聊天机器人）不该测平均表现，而要能评估**最差表现（worst performance）**——如医疗输出质量、毒性等。（延伸阅读：⭐ [这个博客](https://ehudreiter.com/2024/07/10/challenges-in-evaluating-llms/)）
|
||||
|
||||
### 3.5 智能新任务：功能测试（functional testing）
|
||||
|
||||
代码领域：不仅要按语义评估生成的程序，还要按**实际功能**评估。好办法是检查「为遵循 prompt 而生成的代码」能否通过**一套为该任务设计的单元测试（unit tests）**。
|
||||
|
||||
功能化方法极具前景，因为：
|
||||
|
||||
- 更容易生成测试用例（很多情况下可用基于规则的方法生成 test cases）；
|
||||
- 因此**降低过拟合（overfitting）**；
|
||||
- 测的是模型的具体**主动能力（active capabilities）**。
|
||||
|
||||
不过，要把这种方法**迁移到文本任务需要创造力**！
|
||||
|
||||
- 一个优秀范例是 **IFEval**：测试模型能否遵循指令的评测 benchmark。它创建一批格式化指令（*Add this number of bullet points.*、*Capitalize only one sentence.* 等），严格检查格式是否被遵循。
|
||||
- 作者认为：要把这个思路扩展到文本的其他特性，还需要更多工作。
|
||||
- **核心概念**（task / capability / dataset / metric / 泛化与过拟合）：见 [[08-2025-Edition]] §4。
|
||||
- **自动化基准的优缺点与污染问题**：见 [[08-2025-Edition]] §3（saturation / contamination 定义）与本页 §5。
|
||||
- **设计自动评测的完整流程**（选数据集 / 推理方法 / prompt / metric / 功能测试）：见 [[08-2025-Edition]] §5.1–§5.8。
|
||||
- 旧版更详细的步骤与示例（含 prompt 结构模板、metric 选择细节）：可回原文 [designing-your-automatic-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/automated-benchmarks/designing-your-automatic-evaluation.md) 查阅，本页不再重复维护。
|
||||
|
||||
---
|
||||
|
||||
|
||||
+2
-2
@@ -202,7 +202,7 @@ Score the fluency from 0 to 5, 0 being completely un-understandable, ...
|
||||
|
||||
可以直接借鉴的现成模板：
|
||||
|
||||
- [MixEval judge prompts（lighteval 实现）](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.pyy)
|
||||
- [MixEval judge prompts（lighteval 实现）](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.py)
|
||||
- [MTBench judge prompt templates（lighteval 实现）](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py)
|
||||
|
||||
这四条准则与"一份好 judge prompt 的要素"的对应关系：
|
||||
@@ -668,7 +668,7 @@ LLM 评委的**已知偏见清单**（原文逐条整理，含缓解方法）：
|
||||
### 工具与教程
|
||||
|
||||
- [distilabel](https://distilabel.argilla.io/latest/)（[UltraFeedback tutorial](https://distilabel.argilla.io/latest/sections/pipeline_samples/papers/ultrafeedback/) / [benchmarking with distilabel（Arena Hard）](https://distilabel.argilla.io/latest/sections/pipeline_samples/examples/benchmarking_with_distilabel/)）
|
||||
- [lighteval：MixEval judge prompts](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.pyy) / [MTBench judge prompt templates](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py)
|
||||
- [lighteval：MixEval judge prompts](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.py) / [MTBench judge prompt templates](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mt_bench/judge_prompt_templates.py)
|
||||
- [ArtificialAnalysis LLM Performance Leaderboard（成本对比）](https://huggingface.co/spaces/ArtificialAnalysis/LLM-Performance-Leaderboard)
|
||||
- [LeonEricsson/llmjudge（扰动敏感度扩展实验）](https://github.com/LeonEricsson/llmjudge/blob/main/README.md)
|
||||
|
||||
|
||||
+9
-126
@@ -11,143 +11,26 @@ source: https://github.com/huggingface/evaluation-guidebook
|
||||
|
||||
# LLM 评测指南 · General Knowledge（通用知识）提炼笔记
|
||||
|
||||
> 本页提炼自 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的 **General knowledge** 章节的两页内容：**Model inference and evaluation**（模型推理与评测）与 **Tokenization**（分词）。面向初学者，重点整理与评测直接相关的部分：生成式评测 vs log-probability 评测、log-prob 的计算方式、tokenizer 对评测结果的影响。
|
||||
> 本页提炼自 [HuggingFace Evaluation Guidebook](https://github.com/huggingface/evaluation-guidebook) 的 **General knowledge** 章节的两页内容：**Model inference and evaluation**（模型推理与评测）与 **Tokenization**（分词）。⚠️ §1（模型推理与评测）已被新版覆盖并压缩（见 [[08-2025-Edition]] §4）；本页保留 **tokenizer 对评测结果的影响** 的旧版细节。
|
||||
>
|
||||
> 原文链接：
|
||||
> - [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 的影响）。
|
||||
> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §4。本页 §1（模型推理与评测）已被新版覆盖并压缩；保留 §2（tokenization 细节）与 §3（tokenization 对评测的影响）。
|
||||
|
||||
---
|
||||
|
||||
## 一、模型推理与评测（Model Inference and Evaluation）
|
||||
## 一、模型推理与评测（已被新版覆盖，已压缩）
|
||||
|
||||
### 1.1 什么是推理（inference）
|
||||
> 📌 **术语衔接（来自指南其他章节，非本页原文）**：指南的 *Automatic benchmarks* 章节把"对给定序列求 log-probability"的评测称为 *multiple-choice evaluations*，有时也叫 **MCQA** 或 *perplexity evaluations*；perplexity（困惑度）指标的具体用法，以及评测框架 **lm-evaluation-harness**（EleutherAI）与 **lighteval**（HuggingFace）的讨论，详见指南对应章节与本目录 [[01-Automatic-Benchmarks]]、[[07-Resources]] 笔记。
|
||||
|
||||
大型语言模型的工作方式很简单：**给定一段文本作为输入，它们学会了预测"合理的后续内容"**。整个过程分两步：
|
||||
旧版 §1（模型推理与评测：inference 流程、log-likelihood、生成式评测、约束输出）与新版重叠，已压缩为指针：
|
||||
|
||||
#### 第一步：Tokenization（分词）
|
||||
|
||||
- 输入文本（推理时称为 *prompt*）先被切分成 **tokens**——小的文本单元（可以是一个或几个字符，最多到词级）。
|
||||
- 每个 token 关联一个数字；模型能解析的全部 token 范围称为它的 **vocabulary**（词表）。
|
||||
- 细节见本页第二章（原文 Tokenization 页）。
|
||||
|
||||
#### 第二步：Prediction（预测）
|
||||
|
||||
|
||||
|
||||
- 基于输入文本，LLM 在**整个词表**上生成"最可能的下一个 token"的概率分布。
|
||||
- 要得到连续生成：取概率最高的 token（可加入一点随机性以获得更有趣的输出）作为下一个 token，然后**重复该操作**，把新 token 当作 prompt 的结尾继续下去，如此循环（即自回归生成）。
|
||||
|
||||
### 1.2 你想预测什么？——评测的两大类别
|
||||
|
||||
LLM 评测主要分为两大类：
|
||||
|
||||
1. **给定一个 prompt 和一个（或多个）答案**：我的模型给出这些答案的概率是多少？
|
||||
2. **给定一个 prompt**：我的模型会生成什么文本？
|
||||
|
||||
| 维度 | Log-likelihood 评测（选择题式） | Generative 评测（生成式） |
|
||||
|---|---|---|
|
||||
| 核心问题 | 给定候选答案，答案是"被模型认可"的概率 | 给定 prompt，模型自己生成什么 |
|
||||
| 模型输出 | 候选序列的 log-probability | 自回归生成的 token 序列 |
|
||||
| 典型形态 | 多项选择（multiple-choice / MCQA）、单句概率判断、校准研究 | 开放生成、摘要、翻译、代码生成 |
|
||||
| 打分方式 | 比较各选项 log-prob、与 0.5 阈值比较、看校准 | 与参考文本比对（exact match、BLEU 等）或模型作评委 |
|
||||
| 优点 | 计算确定、可复现，直接反映模型偏好 | 更接近真实使用场景 |
|
||||
| 风险 | 可能偏向"自由生成时会输出别的东西"的模型（见 1.3） | 生成结果多样，打分标准更难定 |
|
||||
|
||||
> 📌 **术语衔接（来自指南其他章节，非本页原文）**：指南的 *Automatic benchmarks* 章节把"对给定序列求 log-probability"的评测称为 *multiple-choice evaluations*，有时也叫 **MCQA** 或 *perplexity evaluations*；perplexity（困惑度）指标的具体用法，以及评测框架 **lm-evaluation-harness**（EleutherAI）与 **lighteval**（HuggingFace）的讨论，不在本页范围内，详见指南对应章节与本目录 [[01-Automatic-Benchmarks]]、[[07-Resources]] 笔记。
|
||||
|
||||
### 1.3 Log-likelihood（log-prob）评测
|
||||
|
||||
目标是：**给定 prompt，求一个或多个候选答案的条件概率**——即"给定输入，得到某个特定续写的可能性有多大"。
|
||||
|
||||
计算过程（对应原文插图 `llm_logprob.png`）：
|
||||
|
||||
```text
|
||||
1. 拼接：把每个选项（choice）与 prompt 拼接，传给 LLM
|
||||
↓
|
||||
2. 取 logits：LLM 输出每个 token 的 logits（每个 token 取决于它之前的 token）
|
||||
↓
|
||||
3. 只保留与选项 token 相关的最后几个 logits，施加 log softmax
|
||||
→ 得到 log-probabilities（值域为 [-inf, 0]，而不是 [0, 1]）
|
||||
↓
|
||||
4. 求和：把所有单个 token 的 log probability 相加
|
||||
→ 得到整个选项的总 log probability
|
||||
↓
|
||||
5. 归一化：最后可按选项长度（choice length）做归一化
|
||||
```
|
||||
|
||||
|
||||
|
||||
基于此可以应用以下指标：
|
||||
|
||||
- **在多个选项中选出模型最偏好的答案**（如上图）。
|
||||
- ⚠️ 注意：这可能**有利于**那些"若自由生成会输出别的东西"的模型——例如图中模型"被迫"在选项里选 `Zygote`，但若让它自由生成可能给出别的答案，从而虚高其得分。
|
||||
- **测试单个选项的概率是否超过 0.5**。
|
||||
- **研究模型校准（calibration）**：一个校准良好的模型，其正确答案应该拥有最高的概率。
|
||||
- 了解校准是什么、如何检测、如何训练出校准良好的模型：Anthropic 论文 [Calibration tutorial](https://arxiv.org/abs/2207.05221)。
|
||||
- 校准的一些可能局限：[Limits of calibration](https://arxiv.org/abs/2311.14648)。
|
||||
|
||||
### 1.4 生成式评测（Generative evaluations）
|
||||
|
||||
目标是：**给定 prompt，得到模型生成的文本**。
|
||||
|
||||
生成过程是自回归的：
|
||||
|
||||
```text
|
||||
1. 把 prompt 传给模型
|
||||
↓
|
||||
2. 看最可能的下一个 token，选中它作为模型的 "choice first token"
|
||||
↓
|
||||
3. 重复，直到满足生成结束条件：
|
||||
- 达到最大长度（maximum length）
|
||||
- 出现特殊终止 token（special token to stop the generation）
|
||||
- 等
|
||||
↓
|
||||
4. 模型生成的所有 token 即它对 prompt 的"回答"
|
||||
```
|
||||
|
||||
|
||||
|
||||
然后**把生成结果与参考答案（references）比较，对两者之间的距离打分**：
|
||||
|
||||
- 简单指标：**exact match**（精确匹配）。
|
||||
- 更复杂的指标：**BLEU** 等。
|
||||
- 或用**模型作评委**（models as judges，即 LLM-as-a-judge，详见指南 Model-as-a-Judge 章节）。
|
||||
|
||||
#### Going further（进阶阅读）
|
||||
|
||||
- ⭐ [Blog on several ways to evaluate MMLU](https://huggingface.co/blog/open-llm-leaderboard-mmlu) —— HuggingFace 团队（原作者所在团队）所写，深入讲解"多项选择 log-likelihood 评测"与"生成式评测"的差异，以及它们对分数变化意味着什么。上文插图即来自该博客（由 Thom Wolf 制作）。
|
||||
- ⭐ [A beautiful mathematical formalization of the above inference methods](https://arxiv.org/abs/2405.14782v2) —— EleutherAI 对上述推理方法的数学形式化，直接看 Appendix。
|
||||
|
||||
### 1.5 约束模型输出（Constraining model outputs）
|
||||
|
||||
在很多情况下，我们希望模型输出遵循特定格式（例如为了与参考答案比较）。原文给出了三种方式：
|
||||
|
||||
| 方式 | 做法 | 优点 | 局限 |
|
||||
|---|---|---|---|
|
||||
| **使用 prompt** | 在任务 prompt 中加入非常具体的指令（如 `Provide numerical answers in digits.`、`Use no abbreviation.`） | 最简单；对高能力模型通常够用 | 不一定总是有效 |
|
||||
| **Few-shot / In-context learning** | 在 prompt 中提供示例（few-shot prompting），让模型隐式偏向遵循示例的 prompt 形状 | 2023 年底之前普遍效果很好 | 见下方说明 |
|
||||
| **结构化文本生成（Structured text generation）** | 用语法（grammar）或正则表达式定义输出路径，约束输出 | 减少评测中的 prompt 方差，结果与排名更稳定 | 可能降低部分任务的性能（见下方说明） |
|
||||
|
||||
#### Few-shot 的说明
|
||||
|
||||
- 工作原理：通过 in-context learning，prompt 里的示例会让模型隐式地偏向"按照重复出现的 prompt 形状"作答。
|
||||
- **时效性**：该方法直到 2023 年底都整体表现良好；但此后 **instruction-tuning** 的广泛采用，以及预训练后期加入指令数据（**continuous pre-training**），似乎让较新的模型偏向特定输出格式——论文称之为 *Training on the test task*（[arxiv 2407.07890](https://arxiv.org/abs/2407.07890)），作者则称之为 *overfitting the prompt format*（对 prompt 格式的过拟合）。
|
||||
- **上下文窗口限制**：对上下文窗口较小的旧模型，few-shot 示例可能**放不进 context window**。
|
||||
|
||||
#### 结构化生成的说明
|
||||
|
||||
- `outlines` 库用**有限状态机（finite state machines, FSM）**实现，作者认为非常 neat；也存在其他方法，例如用于 JSON 生成的 **interleaved generation**（作者本人更偏爱 FSM）。
|
||||
- 收益：结构化生成降低评测中的 prompt 方差，使结果和排名更稳定（见共同撰写的博客 [Evaluation of structured outputs](https://huggingface.co/blog/evaluation-structured-outputs)；也可看 `outlines` 的 [博客](https://blog.dottxt.co/)）。
|
||||
- 风险：近期 [研究](https://arxiv.org/abs/2408.02442) 显示，结构化生成可能通过把先验推离期望概率分布太远，从而**降低模型在部分任务（如推理）上的表现**。
|
||||
|
||||
#### Going further（进阶阅读）
|
||||
|
||||
- ⭐ [Understanding how Finite State Machine works when using structured generation](https://blog.dottxt.co/coalescence.html) —— Outlines 出品，对其方法的清晰讲解。
|
||||
- [The outlines method paper](https://arxiv.org/abs/2307.09702) —— 上述方法的学术版解释。
|
||||
- [Interleaved generation](https://github.com/guidance-ai/guidance?tab=readme-ov-file#guidance-acceleration) —— 另一种约束特定输出格式生成的方法。
|
||||
- **log-likelihood 评测的计算步骤与 MCF / CF / FG 三种任务形式**：见 [[08-2025-Edition]] §4。
|
||||
- **生成式评测与打分**（exact match / BLEU / model judges）：见 [[08-2025-Edition]] §4 与 §5.5。
|
||||
- **约束模型输出**（prompt / few-shot / 结构化生成）：见 [[08-2025-Edition]] §5.11。
|
||||
- 更详细的旧版步骤与插图：可回原文 [model-inference-and-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md) 查阅，本页不再重复维护。
|
||||
|
||||
---
|
||||
|
||||
|
||||
+2
-2
@@ -275,7 +275,7 @@ article.mdx（组装层，含正文过渡小节、saturation/contamination 定
|
||||
|
||||
## §5 设计自动评测（designing-your-automatic-evaluation + article.mdx）
|
||||
|
||||
> 旧版对应：[[01-Automatic-Benchmarks]] §3（设计自动评测）与 §4（常用评测数据集盘点，新版不再渲染正文）。
|
||||
> 旧版对应：[[01-Automatic-Benchmarks]] §4（常用评测数据集盘点）与 §5（实战技巧，均旧版独有）；旧版设计流程部分已被本节省去/覆盖。
|
||||
|
||||
新版把"设计自动评测"重写为完整方法论。**与旧版不同的章节结构**（原文实际顺序）：
|
||||
|
||||
@@ -423,7 +423,7 @@ log-probability 打分容易：accuracy 变体（最可能 choice 是否最佳
|
||||
- 两条路线：**通用高能力模型**（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 竞赛](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；**每个能力一个 prompt**；可用 few-shot / reference / CoT（先输出推理再打分）/ 多轮分析 / **jury（多个 judge 聚合，可用多个小模型降本）** 提升准确率。
|
||||
- **judge prompt 设计**：任务描述 → 评估标准（含详细评分系统）→ 推理步骤 → 指定输出格式（如 JSON `{"Score": ..., "Reasoning": ...}`）。参考 [MixEval](https://github.com/huggingface/lighteval/blob/main/src/lighteval/tasks/extended/mix_eval/judge_prompts.py)/[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；**每个能力一个 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](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)）。
|
||||
|
||||
Reference in New Issue
Block a user