Tokenization 理论与多语言分析
Tokenization 是 LLM 的”隐形基础设施”——它决定了模型看到什么、能处理什么、以及不同语言用户的体验差异。本文系统梳理 tokenization 的理论基础:词的定义歧义、token 效率对模型性能的影响、词级词表的空间爆炸问题(Zipf 定律)、计算任务中的 tokenization 陷阱,以及多语言 tokenizer 的词表分配问题。
📐 词的定义歧义与 Tokenization 的正式定义
对于字符串 ,tokenization 是一个函数 ,每个 (词表)。
关键约束:(近似可逆性,信息损失极小)
Tokenizer 需要处理的歧义:
- 空格:“don’t” = [“don”, ”’”, “t”] 还是 [“don’t”]?
- 中文:无空格分隔,“我爱中国” 可分为 [“我”, “爱”, “中国”] 或 [“我”, “爱中”, “国”]
- 特殊字符:表情符号 ”😊” = 单 token?多 token?
- 数字:“1234” = 一个 token?还是 [“1”, “2”, “3”, “4”]?
- 大小写:“Apple” 和 “apple” 是同一 token 吗(取决于 tokenizer 是否 case-sensitive)?
📐 Token 效率(Token Efficiency)的影响
对于相同文本 ,定义 Fertility(繁殖率) = 单词平均 token 数:
- 高效 tokenizer(少 token):序列短,注意力计算 代价低,推理快
- 低效 tokenizer(多 token):序列长,二次方注意力成本上升,上下文利用率低
Token 效率直接影响:
- 推理速度:序列越短,每步生成越快
- 上下文容量:同样的 context window 能放入更多语义信息
- 训练成本:同样文本用更少 token 表示,每个 step 覆盖更多语义
📐 词级词表的空间爆炸(Zipf 定律)
词频分布遵循 Zipf 定律:第 高频词的频率正比于 ():
这意味着大量词出现频率极低(长尾),仍然需要存进词表。对于 1 万亿 token 的语料,唯一词数 > 1000 万(因为 “cat”, “cats”, “cat’s”, “Cat”, “CAT”, 各种拼写错误都不同)。
Embedding 层大小:
若 ,:参数量 = (40 billion),已超过整个 7B LLM 的参数量!
📐 计算任务中的 Tokenization 陷阱
数字 tokenization 问题:“9.9 vs 9.11 哪个大?“——GPT-4 早期版本经常答错。原因分析:
- “9.11” 可能被 tokenized 为 [“9”, ”.”, “11”] 或 [“9.11”](单 token)
- 如果是 [“9”, ”.”, “11”],模型在 token 层面看到 “11”,可能把 “.11” 类比为”小数11”
- 而 “9.9” 被分为 [“9”, ”.”, “9”],模型比较 9 vs 11 → 误判 9.11 > 9.9
拼写任务:“strawberry 中有几个 r?“——LLM 容易答错(答2而非3):
tiktoken: "strawberry" → ["str", "aw", "berry"]
str → 含1个r
aw → 不含r
berry → 含1个r(但 "rr" 在 berry 中!)
模型在 token 层面操作,“rr” 被整合进 “berry” token,字符边界模糊,计数困难。
📐 多语言 Tokenizer 的词表分配问题
对于包含 种语言的语料,训练联合 BPE 词表时,高频语言(英文)会”占据”更多词表空间,低频语言被过度分割。
**Fertility(繁殖率)**定义:
英文 fertility ≈ 1.1(几乎每词一 token),低资源语言 fertility 可达 3–5(每词需要多个 token)。
解决方案:上采样(upsampling)低资源语言——在词表训练语料中人为增加低资源语言的比例,迫使 BPE 为这些语言分配更多词表空间。如 Llama 3 的 tokenizer(128K 词表)、XLM-R(250K 词表)都专门扩充了多语言支持。