---
type: reference
tags:
  - llm-evaluation
  - evaluation-guidebook
  - general-knowledge
status: active
created: 2026-08-21
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 对评测结果的影响。
>
> 原文链接：
> - [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)

---

## 一、模型推理与评测（Model Inference and Evaluation）

### 1.1 什么是推理（inference）

大型语言模型的工作方式很简单：**给定一段文本作为输入，它们学会了预测"合理的后续内容"**。整个过程分两步：

#### 第一步：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) —— 另一种约束特定输出格式生成的方法。

---

## 二、Tokenization（分词）

### 2.1 为什么以及如何切分文本

**LLM 本质上是大型数学函数，吃的是数字而不是文本。** 要把句子变成数字：先决定如何把句子切成小块，再把每个小块映射成一个数字——这就是 **tokenization**。

历史上两端方案：

| 方案 | 切分方式 | 映射方式 | 例子 |
|---|---|---|---|
| **Character based**（字符级） | 按字符切分 | 每个字符映射为字母表索引 | `a` → 1，`b` → 2 |
| **Word based**（词级） | 按空格切分（若语言有空格；没有的话更难） | 每个词映射为词典索引 | `a` → 1，`aardvark` → 2，`ab` → 3 |

**两者的共同局限：都会丢失输入文本的信息。**

- 抹掉了从**词形**能看出的语义联系，例如：`dis similar`、`similar`、`similar ity`、`similar ly` —— 这些联系正是我们希望模型保留、以便把相关词联系起来的。
- 另外：如果输入中出现一个**全新的词**，它没有对应数字，模型就无法处理 😔

于是有人想到：**把词切成子词（sub-words），再为这些子词分配索引**（如 `dis`、`similar`、`ity`、`ly`）。

- 早期做法：使用**形态句法规则（morpho-syntactic rules）**（"morpho-syntax" 类似于"构词的语法"）。
- 现在大多数使用 **byte pair encoding（BPE）**：一种聪明的统计方法，根据参考文本中的词频**自动**创建子词。

**总结定义**：

> Tokenization 是一种把小的文本单元（可以是一个或几个字符，最多到词级）映射为数字（类似索引）的方式。处理文本时，输入文本（推理时称为 *prompt*）被 **tokenizer** 切分成这些 **tokens**；模型或 tokenizer 能解析的全部 token 范围称为它的 **vocabulary**。

#### Going further：理解 tokenization

- ⭐ [Explanation of different tokenization methods in the 🤗 NLP Course](https://huggingface.co/learn/nlp-course/en/chapter2/4) —— 建议精读。
- ⭐ [Conceptual guide about tokenization in the 🤗 doc](https://huggingface.co/docs/transformers/en/tokenizer_summary) —— 建议精读。
- [Course by Jurafsky on tokenization](https://web.stanford.edu/~jurafsky/slp3/2.pdf) —— 更学术向，直接跳到 2.5 和 2.6 节（其余也有趣但太宽泛）。

#### Going further：Byte Pair Encoding

- ⭐ [Explanation of BPE in the 🤗 NLP Course](https://huggingface.co/learn/nlp-course/en/chapter6/5)
- [Paper introducing BPE to NLP](https://aclanthology.org/P16-1162/)

### 2.2 问题一：如何选择词表大小（vocabulary size）

词表大小 = 模型需要学习的独立 token（例如子词）的数量。

#### 词表太大（too big）的两个问题

1. 可能把**很罕见的词**当作完整 token 收录（例如 `aardvark`）。如果该词在训练数据中几乎不出现，它就**难以与其他概念建立联系**，模型可能无法推断它是什么。
2. 如果该词罕见但只出现在特定上下文，则可能被关联到**非常具体的词**：例如在论坛数据上训练时，tokenizer 把一个用户名映射成单一 token，模型就可能把这个 token 与该用户的内容关联起来。

#### 词表太小（too small）的两个问题

1. **表示能力变差**。
2. **推理成本上升**。

回到 `similar` 词族的例子（原文）：

- 用类 BPE（大词表）切 `similarly` → **2 个 token**：`similar`、`ly`。
- 用字符级切分（词表很小，只有字母表大小）切同一个词 → **9 个 token**：`s` `i` `m` `i` `l` `a` `r` `l` `y`。

对比结论：

- 大词表切出的 token 各自有独立语义；小词表则**丢失了语义表示**。
- 表示长度差异直接变成成本差异：生成同一个词需要 9 个 token 而不是 2 个，**贵了约 5 倍**！

#### 实践建议

目前大多数人用**启发式**选择词表大小，它似乎与**覆盖的语言数量**和**模型规模**相关——因此使用与"规模相近的参考模型"接近的 token 数量，很可能可行。

#### Going further：罕见 token 效应

- ⭐ [SolidGoldMagikarp post on Less Wrong](https://www.lesswrong.com/posts/aPeJE8bSo6rAFoLqg/solidgoldmagikarp-plus-prompt-generation) —— 有趣读物：人们在**不访问模型内部**（例如不知道训练数据内容）的情况下识别出 OpenAI 词表中的极罕见 token。
- [Fishing for Magikarp, paper by Cohere](https://arxiv.org/abs/2405.05417) —— 检测这些 token 的后续工作。

### 2.3 问题二：多语言管理（Managing several languages）

> 建议先读完 BPE 的解释再读本节。

- 构建/选择 tokenizer 时，词表来自**参考文本**——通常意味着**英文、拉丁字母**的数据。
- 如果新语言与原始语言**使用相同脚本且有共同词根**，理论上可以期待部分语义迁移到新语言。
- 但若要 tokenizer 正确切分其他语言（尤其是**不同脚本**的语言），最好在构建 tokenizer 时**纳入这些语言的数据**。
- 然而，这些数据通常**比例失衡**：初始语言（如英文）远多于新语言（如泰语、缅甸语）。由于 BPE 等高效方法基于**最高频的词**创建复杂词表 token：
  - 大多数**长 token 是英文词**；
  - 低频语言的大部分词**只能按字符级切分**。

**结果：多语言 tokenization 的不公平** —— 一些（较不常见的、或 *lower-resourced* 低资源）语言，生成与英文**等长含义的句子需要多出数量级（orders of magnitude）的 token**。

#### Going further：语言与 tokenization

- ⭐ [A beautiful breakdown and demo by Yennie Jun on tokenization issues across languages](https://www.artfish.ai/p/all-languages-are-not-created-tokenized) —— 分析本身非常清晰，值得把玩其 [demo space](https://huggingface.co/spaces/yenniejun/tokenizers-languages)。
- ⭐ [A demo by Aleksandar Petrov on unfairness of tokenization](https://aleksandarpetrov.github.io/tokenization-fairness/) —— 建议看 *Compare tokenization of sentences*，直观感受不同语言在推理成本上的差异。

### 2.4 问题三：数字怎么办？（What about numbers?）

构建 tokenizer 时需要决定如何处理数字：

- 只索引 `0` 到 `9`，假设其他所有数字都是数字位的组合？
- 还是把数字单独存储，直到（比如说）十亿级别？

现状与展望：

- 当前知名模型对此**做法各异**，但尚不清楚哪种方式更有利于**数学推理**。
- 也许需要新的 tokenization 方法（例如 **hierarchical tokenization**，分层分词）来解决。

#### Going further：数字 tokenization

- ⭐ [A nice visual demo by Yennie Jun of how tokenizers split numbers](https://www.artfish.ai/p/how-would-you-tokenize-or-break-down) —— Anthropic、Meta、OpenAI、Mistral 各模型 tokenizer 如何切分数字的可视化演示。
- [Small history by Beren Millidge of number tokenization evolution](https://www.beren.io/2024-05-11-Integer-tokenization-is-now-much-less-insane/) —— 数字 tokenization 多年演变的小史。

---

## 三、Tokenization 如何影响评测（对评测的启示）

把两页内容串到评测视角，可得到如下速查表（均为原文要点，非新增内容）：

| 评测相关维度 | 原文章节要点 | 对评测的含义 |
|---|---|---|
| **生成成本 / 长度** | 同样一个词，字符级切 9 个 token vs BPE 切 2 个 token，贵约 5 倍 | 同一 prompt 在不同 tokenizer 下 token 数不同 → 推理耗时与费用不同；评测大批量样本时成本差异显著 |
| **词表大小** | 太大 → 罕见 token 难以关联或过度关联；太小 → 表示能力差、成本高 | 词表选择影响模型学到的表示质量，进而影响任务表现；词表大小需与模型规模、语言数匹配 |
| **多语言不公平** | 低资源语言生成等长句子需多出数量级的 token | 跨语言评测中，不同语言的"同量内容"成本不同；评测多语言模型时需考虑 token 数差异 |
| **罕见 token** | 罕见 token（如用户名）可能被关联到特定内容 | 可能造成模型在特定输入上的"意外行为"；识别与检测见 SolidGoldMagikarp / Cohere 论文 |
| **数字切分** | 数字 token 化方式尚无定论，可能影响数学推理 | 评测数学/推理基准（如 MATH 类任务）时，数字 token 化方式可能影响分数 |
| **上下文窗口** | few-shot 示例可能放不进 context window（旧模型） | 设计 few-shot 评测时需考虑模型上下文长度，示例数量受限制 |
| **log-prob 归一化** | 选项 log-prob 最后可按选项长度归一化 | 多项选择评测时，不同选项长度不同，归一化避免长选项"天然"得分更高 |

> 一句话总结：**tokenizer 不是评测的"前处理细节"，而是会实际改变评测成本、跨语言公平性和最终分数**的东西。

---

## 四、参考资料

### 原文（GitHub blob）

- [contents/general-knowledge/model-inference-and-evaluation.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/model-inference-and-evaluation.md)
- [contents/general-knowledge/tokenization.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/general-knowledge/tokenization.md)
- 指南仓库主页：[huggingface/evaluation-guidebook](https://github.com/huggingface/evaluation-guidebook)

### 文中提到的外部链接

**评测方法 / 推理**

- ⭐ [Blog on several ways to evaluate MMLU](https://huggingface.co/blog/open-llm-leaderboard-mmlu)（HuggingFace 团队）
- ⭐ [Mathematical formalization of inference methods（EleutherAI）](https://arxiv.org/abs/2405.14782v2)
- [Anthropic：calibration 教程](https://arxiv.org/abs/2207.05221)
- [校准的局限](https://arxiv.org/abs/2311.14648)
- [GAIA 论文](https://huggingface.co/papers/2311.12983) 及其 [leaderboard](https://huggingface.co/spaces/gaia-benchmark/leaderboard)
- [Training on the test task（few-shot 过拟合）](https://arxiv.org/abs/2407.07890)
- [结构化输出评测博客](https://huggingface.co/blog/evaluation-structured-outputs)
- [结构化生成降低推理性能的研究](https://arxiv.org/abs/2408.02442)

**约束输出 / 结构化生成**

- ⭐ [Outlines：FSM 工作原理](https://blog.dottxt.co/coalescence.html)
- [outlines 博客](https://blog.dottxt.co/)
- [outlines 方法论文](https://arxiv.org/abs/2307.09702)
- [Interleaved generation（guidance 库）](https://github.com/guidance-ai/guidance?tab=readme-ov-file#guidance-acceleration)

**Tokenization**

- ⭐ [🤗 NLP Course：tokenization 方法总览](https://huggingface.co/learn/nlp-course/en/chapter2/4)
- ⭐ [🤗 Transformers 文档：tokenizer 概念指南](https://huggingface.co/docs/transformers/en/tokenizer_summary)
- [Jurafsky：tokenization 课程（看 2.5 / 2.6 节）](https://web.stanford.edu/~jurafsky/slp3/2.pdf)
- ⭐ [🤗 NLP Course：BPE 详解](https://huggingface.co/learn/nlp-course/en/chapter6/5)
- [BPE 引入 NLP 的论文](https://aclanthology.org/P16-1162/)

**罕见 token 与多语言**

- ⭐ [SolidGoldMagikarp（Less Wrong）](https://www.lesswrong.com/posts/aPeJE8bSo6rAFoLqg/solidgoldmagikarp-plus-prompt-generation)
- [Fishing for Magikarp（Cohere）](https://arxiv.org/abs/2405.05417)
- ⭐ [Yennie Jun：跨语言 tokenization 分析](https://www.artfish.ai/p/all-languages-are-not-created-tokenized) + [demo](https://huggingface.co/spaces/yenniejun/tokenizers-languages)
- ⭐ [Aleksandar Petrov：tokenization 不公平性 demo](https://aleksandarpetrov.github.io/tokenization-fairness/)
- ⭐ [Yennie Jun：数字切分可视化](https://www.artfish.ai/p/how-would-you-tokenize-or-break-down)
- [Beren Millidge：数字 tokenization 小史](https://www.beren.io/2024-05-11-Integer-tokenization-is-now-much-less-insane/)

---

> 关联笔记：本目录 [[00-Overview]]；指南其余章节提炼笔记（[[01-Automatic-Benchmarks]]、[[02-Human-Evaluation]]、[[03-LLM-as-a-Judge]]、[[04-Troubleshooting]]、[[06-Yearly-Dives]]、[[07-Resources]]）。