Tokenization 理论与多语言分析

分类: 预训练与微调 · 难度: 中级 · 关联讲座: L14

Tokenization 是 LLM 的”隐形基础设施”——它决定了模型看到什么、能处理什么、以及不同语言用户的体验差异。本文系统梳理 tokenization 的理论基础:词的定义歧义、token 效率对模型性能的影响、词级词表的空间爆炸问题(Zipf 定律)、计算任务中的 tokenization 陷阱,以及多语言 tokenizer 的词表分配问题。

📐 词的定义歧义与 Tokenization 的正式定义

对于字符串 ss,tokenization 是一个函数 τ:s[t1,t2,,tn]\tau: s \mapsto [t_1, t_2, \ldots, t_n],每个 tiVt_i \in V(词表)。

关键约束:detokenize(τ(s))s\text{detokenize}(\tau(s)) \approx s(近似可逆性,信息损失极小)

Tokenizer 需要处理的歧义:

  • 空格:“don’t” = [“don”, ”’”, “t”] 还是 [“don’t”]?
  • 中文:无空格分隔,“我爱中国” 可分为 [“我”, “爱”, “中国”] 或 [“我”, “爱中”, “国”]
  • 特殊字符:表情符号 ”😊” = 单 token?多 token?
  • 数字:“1234” = 一个 token?还是 [“1”, “2”, “3”, “4”]?
  • 大小写:“Apple” 和 “apple” 是同一 token 吗(取决于 tokenizer 是否 case-sensitive)?

📐 Token 效率(Token Efficiency)的影响

对于相同文本 ss,定义 Fertility(繁殖率) = 单词平均 token 数:

fertility(l)=language l tokenized token countlanguage l word count\text{fertility}(l) = \frac{\text{language } l \text{ tokenized token count}}{\text{language } l \text{ word count}}

  • 高效 tokenizer(少 token):序列短,注意力计算 O(n2)O(n^2) 代价低,推理快
  • 低效 tokenizer(多 token):序列长,二次方注意力成本上升,上下文利用率低

Token 效率直接影响:

  1. 推理速度:序列越短,每步生成越快
  2. 上下文容量:同样的 context window 能放入更多语义信息
  3. 训练成本:同样文本用更少 token 表示,每个 step 覆盖更多语义

📐 词级词表的空间爆炸(Zipf 定律)

词频分布遵循 Zipf 定律:第 kk 高频词的频率正比于 1/kα1/k^\alphaα1\alpha \approx 1):

P(wordk)kαP(\text{word}_k) \propto k^{-\alpha}

这意味着大量词出现频率极低(长尾),仍然需要存进词表。对于 1 万亿 token 的语料,唯一词数 > 1000 万(因为 “cat”, “cats”, “cat’s”, “Cat”, “CAT”, 各种拼写错误都不同)。

Embedding 层大小:V×dmodel|V| \times d_{\text{model}}

V=107|V| = 10^7d=4096d = 4096:参数量 = 4×10104 \times 10^{10}(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 的词表分配问题

对于包含 LL 种语言的语料,训练联合 BPE 词表时,高频语言(英文)会”占据”更多词表空间,低频语言被过度分割。

**Fertility(繁殖率)**定义:

fertility(l)=language l tokenized token countlanguage l word/character count before tokenization\text{fertility}(l) = \frac{\text{language } l \text{ tokenized token count}}{\text{language } l \text{ word/character count before tokenization}}

英文 fertility ≈ 1.1(几乎每词一 token),低资源语言 fertility 可达 3–5(每词需要多个 token)。

解决方案:上采样(upsampling)低资源语言——在词表训练语料中人为增加低资源语言的比例,迫使 BPE 为这些语言分配更多词表空间。如 Llama 3 的 tokenizer(128K 词表)、XLM-R(250K 词表)都专门扩充了多语言支持。