my-vault/01_Projects/Personal-Tech/LLM_Evaluation/04-Reference-Archive/evaluation-guidebook/05-General-Knowledge.md

type, tags, status, created, source

type	tags	status	created	source
reference	llm-evaluation evaluation-guidebook general-knowledge	active	2026-08-21	https://github.com/huggingface/evaluation-guidebook

LLM 评测指南 · General Knowledge（通用知识）提炼笔记

本页提炼自 HuggingFace Evaluation Guidebook 的 General knowledge 章节的两页内容：Model inference and evaluation（模型推理与评测）与 Tokenization（分词）。面向初学者，重点整理与评测直接相关的部分：生成式评测 vs log-probability 评测、log-prob 的计算方式、tokenizer 对评测结果的影响。

原文链接：

• model-inference-and-evaluation.md
• tokenization.md

---

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

1.1 什么是推理（inference）

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

第一步：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）：

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。
  • 校准的一些可能局限：Limits of calibration。

1.4 生成式评测（Generative evaluations）

目标是：给定 prompt，得到模型生成的文本。

生成过程是自回归的：

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 —— HuggingFace 团队（原作者所在团队）所写，深入讲解"多项选择 log-likelihood 评测"与"生成式评测"的差异，以及它们对分数变化意味着什么。上文插图即来自该博客（由 Thom Wolf 制作）。
• ⭐ A beautiful mathematical formalization of the above inference methods —— 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），作者则称之为 overfitting the prompt format（对 prompt 格式的过拟合）。
• 上下文窗口限制：对上下文窗口较小的旧模型，few-shot 示例可能放不进 context window。

结构化生成的说明

• outlines 库用**有限状态机（finite state machines, FSM）**实现，作者认为非常 neat；也存在其他方法，例如用于 JSON 生成的 interleaved generation（作者本人更偏爱 FSM）。
• 收益：结构化生成降低评测中的 prompt 方差，使结果和排名更稳定（见共同撰写的博客 Evaluation of structured outputs；也可看 outlines 的 博客）。
• 风险：近期 研究 显示，结构化生成可能通过把先验推离期望概率分布太远，从而降低模型在部分任务（如推理）上的表现。

Going further（进阶阅读）

• ⭐ Understanding how Finite State Machine works when using structured generation —— Outlines 出品，对其方法的清晰讲解。
• The outlines method paper —— 上述方法的学术版解释。
• Interleaved generation —— 另一种约束特定输出格式生成的方法。

---

二、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 —— 建议精读。
• ⭐ Conceptual guide about tokenization in the 🤗 doc —— 建议精读。
• Course by Jurafsky on tokenization —— 更学术向，直接跳到 2.5 和 2.6 节（其余也有趣但太宽泛）。

Going further：Byte Pair Encoding

• ⭐ Explanation of BPE in the 🤗 NLP Course
• Paper introducing BPE to NLP

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 —— 有趣读物：人们在不访问模型内部（例如不知道训练数据内容）的情况下识别出 OpenAI 词表中的极罕见 token。
• Fishing for Magikarp, paper by Cohere —— 检测这些 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 —— 分析本身非常清晰，值得把玩其 demo space。
• ⭐ A demo by Aleksandar Petrov on unfairness of tokenization —— 建议看 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 —— Anthropic、Meta、OpenAI、Mistral 各模型 tokenizer 如何切分数字的可视化演示。
• Small history by Beren Millidge of number tokenization evolution —— 数字 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
• contents/general-knowledge/tokenization.md
• 指南仓库主页：huggingface/evaluation-guidebook

文中提到的外部链接

评测方法 / 推理

• ⭐ Blog on several ways to evaluate MMLU（HuggingFace 团队）
• ⭐ Mathematical formalization of inference methods（EleutherAI）
• Anthropic：calibration 教程
• 校准的局限
• GAIA 论文 及其 leaderboard
• Training on the test task（few-shot 过拟合）
• 结构化输出评测博客
• 结构化生成降低推理性能的研究

约束输出 / 结构化生成

• ⭐ Outlines：FSM 工作原理
• outlines 博客
• outlines 方法论文
• Interleaved generation（guidance 库）

Tokenization

• ⭐ 🤗 NLP Course：tokenization 方法总览
• ⭐ 🤗 Transformers 文档：tokenizer 概念指南
• Jurafsky：tokenization 课程（看 2.5 / 2.6 节）
• ⭐ 🤗 NLP Course：BPE 详解
• BPE 引入 NLP 的论文

罕见 token 与多语言

• ⭐ SolidGoldMagikarp（Less Wrong）
• Fishing for Magikarp（Cohere）
• ⭐ Yennie Jun：跨语言 tokenization 分析 + demo
• ⭐ Aleksandar Petrov：tokenization 不公平性 demo
• ⭐ Yennie Jun：数字切分可视化
• Beren Millidge：数字 tokenization 小史

---

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