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
2026-08-24 11:15:37 +08:00
parent 63add96a09
commit 0dac58fb6f
29 changed files with 644 additions and 434 deletions
@@ -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 推理流程示意](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/llm_tk_1.png?raw=true)
-
- 基于输入文本，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）做归一化
-```
-
-![log-prob 计算示意](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/llm_logprob.png?raw=true)
-
-基于此可以应用以下指标：
-
- **在多个选项中选出模型最偏好的答案**（如上图）。
-  - ⚠️ 注意：这可能**有利于**那些"若自由生成会输出别的东西"的模型——例如图中模型"被迫"在选项里选 `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 的"回答"
-```
-
-![生成式评测示意](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/llm_gen.png?raw=true)
-
-然后**把生成结果与参考答案（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) 查阅，本页不再重复维护。

 ---