windyboy
0dac58fb6f
- 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
14 KiB
type, tags, status, created, source
| type | tags | status | created | source | |||
|---|---|---|---|---|---|---|---|
| reference |
|
active | 2026-08-21 | https://github.com/huggingface/evaluation-guidebook |
LLM 评测指南 · General Knowledge（通用知识）提炼笔记
本页提炼自 HuggingFace Evaluation Guidebook 的 General knowledge 章节的两页内容：Model inference and evaluation（模型推理与评测）与 Tokenization（分词）。⚠️ §1（模型推理与评测）已被新版覆盖并压缩（见 08-2025-Edition §4）；本页保留 tokenizer 对评测结果的影响 的旧版细节。
原文链接：
⚠️ 旧版内容（2024 GitHub 仓库）。新版对应：08-2025-Edition §4。本页 §1（模型推理与评测）已被新版覆盖并压缩；保留 §2（tokenization 细节）与 §3（tokenization 对评测的影响）。
一、模型推理与评测（已被新版覆盖，已压缩）
📌 术语衔接（来自指南其他章节，非本页原文）：指南的 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、生成式评测、约束输出）与新版重叠，已压缩为指针：
- 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 查阅，本页不再重复维护。
二、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
2.2 问题一：如何选择词表大小（vocabulary size）
词表大小 = 模型需要学习的独立 token（例如子词）的数量。
词表太大（too big）的两个问题
- 可能把很罕见的词当作完整 token 收录（例如
aardvark）。如果该词在训练数据中几乎不出现，它就难以与其他概念建立联系，模型可能无法推断它是什么。 - 如果该词罕见但只出现在特定上下文，则可能被关联到非常具体的词：例如在论坛数据上训练时，tokenizer 把一个用户名映射成单一 token，模型就可能把这个 token 与该用户的内容关联起来。
词表太小（too small）的两个问题
- 表示能力变差。
- 推理成本上升。
回到 similar 词族的例子（原文）：
- 用类 BPE（大词表）切
similarly→ 2 个 token：similar、ly。 - 用字符级切分（词表很小，只有字母表大小）切同一个词 → 9 个 token：
similarly。
对比结论：
- 大词表切出的 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 过拟合）
- 结构化输出评测博客
- 结构化生成降低推理性能的研究
约束输出 / 结构化生成
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）。