L14: Tokenization and Multilinguality

Week 7 · Thu Feb 19 2026 08:00:00 GMT+0800 (中国标准时间)

进度: 0/22 (0%)
下载 PDF
/ 0
100%
正在加载 PDF...

L14: Tokenization and Multilinguality

  • Guest Lecture: Julie Kallini
  • A4 due

Slides

中英交替版(推荐)

L14 双语 (PDF)

英文原版

L14 EN (PDF)

中文翻译版

L14 ZH (PDF)

核心知识点

1. 什么是词?什么是 Token?

Slide 1 Slide 2 Slide 3 Slide 4 Slide 5 Slide 6 Slide 7 Slide 8 Slide 9
  • 回顾 word2vec(skip-gram)和语言建模中的”词”概念
  • 词(word) vs 语素(morpheme) vs 字符(character) vs 短语(phrase)
    • 语素是最小有意义单位(如 “looked” = “look” + “-ed”)
    • 词边界本身就模糊(如 “We’d” = 1 词 or 2 词?)
  • Token:LM 的基本语言单位
  • Tokenization:将文本分割为 token 的过程(预处理步骤,非模型本身)
  • Vocabulary:所有已知 token 的集合

📐 词的定义歧义与 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)?

📚 已收录至 拓展阅读知识库

🔢 数值计算示例

同一段文字用不同 tokenizer 的结果:“Hello, World! 你好世界”

Tokenizer分词结果Token 数
GPT-4o (tiktoken cl100k_base)[“Hello”, ”,”, ” World”, ”!”, ” 你好”, “世界”]6
BERT (WordPiece)[“Hello”, ”,”, “World”, ”!”, “你”, “好”, “世”, “界”]8
字符级每个字符独立21

⚠️ 常见误区

  1. 误区:“一个词 = 一个 token” → 正确:现代 LLM 的 token 是子词(subword)级别。“tokenization” 可能是 [“token”, “ization”] 或 [“token”, “iz”, “ation”],取决于训练语料。
  2. 误区:Tokenization 只是”切词”的预处理步骤,不影响模型能力 → 正确:Tokenization 深刻影响模型的计算能力(字符计数、拼写、数字运算),因为模型在 token 层面操作,而非字符层面。

2. Tokenization 如何影响 LM

Slide 10 Slide 11 Slide 12 Slide 13 Slide 14 Slide 15 Slide 16 Slide 17
  • Token ID -> Embedding Matrix 查找 -> 模型处理
  • 影响序列长度(计算量)和参数量(embedding matrix 大小 Rdmodel×V\mathbb{R}^{d_{model} \times |V|}
  • 同一文本在不同 tokenizer 下可能产生差异巨大的 token 序列

📐 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 覆盖更多语义

📚 已收录至 拓展阅读知识库

🔢 数值计算示例

英文 vs 中文的 token 效率对比(tiktoken cl100k_base,GPT-4 tokenizer):

文本Token 序列Token 数备注
”The quick brown fox”[“The”, ” quick”, ” brown”, ” fox”]4每词约 1 token
”敏捷的棕色狐狸”[“敏”, “捷”, “的”, “棕”, “色”, “狐”, “狸”]7每字约 1 token
”1234567890”[“123”, “456”, “789”, “0”]4数字切分碎
”Hello” / “hello”[“Hello”] / [“hello”]1 / 1大小写各占不同 ID

⚠️ 常见误区

  1. 误区:中文用字符级 tokenizer 效率最高 → 正确:中文在现代 BPE tokenizer 中通常一字一 token(汉字信息密度高),已经相当高效。真正低效的是早期以英文为主的 tokenizer(如 LLaMA-1),把一个汉字拆成 2-3 个 token。
  2. 误区:词表越大越好(覆盖更多词)→ 正确:词表大小影响 embedding 矩阵参数量(V×dmodel|V| \times d_{\text{model}}),词表过大会占用大量参数预算,需要权衡。

3. 词级 Tokenization

Slide 18 Slide 19 Slide 20
  • 优点:语义清晰,一个 embedding 约等于一个含义
  • 缺点:
    • 词汇量爆炸(Zipf’s Law:词频与排名成反比)
    • OOV 问题(Out-of-Vocabulary)
    • 语言持续演变(新词不断产生)
  • 应对:规则预处理、UNK token(信息大量丢失)

📐 词级词表的空间爆炸(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 的参数量!

📚 已收录至 拓展阅读知识库

🔢 数值计算示例

词级词表的 OOV 问题:

  • 训练时词表包含 “cat”,推理时遇到 “ChatGPT”(2022年后才出现)→ UNK token(信息完全丢失)
  • 若用 BPE:ChatGPT\text{ChatGPT} \rightarrow [“Chat”, “G”, “PT”](或类似,取决于训练语料)→ 不完美但可理解
  • 词级词表若包含 “COVID-19”、“自拍”、“AIGC” 等新词,需要重新训练整个模型(词表变化 = embedding 矩阵变化)

⚠️ 常见误区

  1. 误区:词级分词语义最清晰,每词一个含义 → 正确:词级分词不处理词形变化(morphology)。“run”、“ran”、“running” 是三个独立 token,不共享参数,但语义相近。BPE 通过共享子词解决了这个问题(“run” 的表示影响 “running”)。
  2. 误区:增大词表能解决 OOV 问题 → 正确:词表永远无法覆盖所有词(新词、拼写错误、专有名词无限),OOV 只能通过子词或字节级方案从根本上解决。

4. 字符/字节级 Tokenization

Slide 21
Slide 21
  • 优点:词表小(~256 字节)、无 OOV、对拼写错误鲁棒
  • 缺点:序列极长 -> 计算开销大、难学到长距离语义

🔢 数值计算示例

字节级 tokenization 示例:“你好” 的 UTF-8 编码:

你 → 0xE4 0xBD 0xA0  (3 bytes)
好 → 0xE5 0xA5 0xBD  (3 bytes)
  • 字节级 tokenizer:[0xE4, 0xBD, 0xA0, 0xE5, 0xA5, 0xBD] → 6 tokens

  • BPE tokenizer(语料足够):[“你好”] → 1 token

  • BPE tokenizer(语料少):[“你”, “好”] → 2 tokens

推理开销对比:6 tokens 的注意力计算代价是 1 token 的 36 倍(O(n2)O(n^2))。

⚠️ 常见误区

  1. 误区:字节级 tokenizer 无法理解字符 → 正确:即使用字节级 tokenizer,LLM 仍可通过学习字节序列的组合隐式学习字符和词级模式。字节级的优势是零 OOV + 极小词表,劣势是序列长。
  2. 误区:字符级 = 字节级 → 正确:字符级词表大小 = Unicode 字符数(~140,000 个),字节级词表仅 256 个。对于多语言文本,字节级更简洁;字符级词表很大但每 token 仍有语义。

5. 子词 Tokenization(Subword)— 主流方法

  • 核心思想:常见词保持完整,罕见词拆为子词

BPE(Byte-Pair Encoding)

Slide 22 Slide 23 Slide 24 Slide 25 Slide 26 Slide 27 Slide 28 Slide 29 Slide 30 Slide 31 Slide 32 Slide 33 Slide 34 Slide 35 Slide 36 Slide 37 Slide 38 Slide 39 Slide 40 Slide 41 Slide 42 Slide 43 Slide 44 Slide 45 Slide 46 Slide 47 Slide 48 Slide 49 Slide 50 Slide 51 Slide 52 Slide 53 Slide 54 Slide 55
  • 训练算法: 1. 初始词表 = 所有字符 + end-of-word 符号 2. 统计最频繁的相邻 pair,合并为新 subword 3. 重复直到达到目标词表大小
  • 推理时用学到的 merge rules 贪心分词
  • 所有主流 LLM 使用 BPE 或其变体

WordPiece

  • 类似 BPE,但按似然增益而非频率选择 merge
  • BERT 使用 WordPiece

Unigram Model(SentencePiece)

Slide 56
Slide 56 — Beyond Subwords: SentencePiece & Superword Tokenization
  • 从大词表开始,迭代移除对似然影响最小的 token

🔢 数值计算示例

BPE 合并过程(玩具语料):

语料:low </w> ×5,lower </w> ×2,newest </w> ×6,widest </w> ×3

初始词表:{l, o, w, e, r, n, s, t, i, d, </w>}

Step 1:统计 pair 频率:

  • (e, s):“newest” ×6 + “widest” ×3 = 9(最高)
  • 合并 (e, s) → “es”

Step 2:统计 pair 频率:

  • (es, t):“n-e-w-es-t” ×6 + “w-i-d-es-t” ×3 = 9(最高)
  • 合并 (es, t) → “est”

Step 3:(est, </w>):6+3=9,合并为 “est</w>”

以此类推,直到词表达到目标大小。最终 “newest” = [“new”, “est</w>”],“widest” = [“w”, “id”, “est</w>”]。

⚠️ 常见误区

  1. 误区:BPE 的分词结果是唯一确定的 → 正确:BPE 分词结果依赖合并规则的顺序,不同训练语料、不同库实现可能给同一文本不同结果。模型 A 的 tokenizer 不能直接用于模型 B(词 ID 完全不同!)。
  2. 误区:BPE 词表越大越好 → 正确:词表大意味着更多完整词作为单 token(推理快),但 embedding 矩阵变大(训练慢、内存多)。主流模型词表大小 32K–200K,是在两个方向上权衡的结果。

6. Case Studies:Tokenization 失败案例

Slide 57 Slide 58 Slide 59 Slide 60 Slide 61
  • 拼写任务:LLM 难以计算 “strawberry” 有几个 r(因 tokenize 后 r 被合并进子词)
  • Glitch tokens:词表中存在的但训练中极少见的 token,导致异常行为
  • Token 边界与语义边界不对齐导致的各种问题

📐 计算任务中的 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,字符边界模糊,计数困难。

📚 已收录至 拓展阅读知识库

🔢 数值计算示例

Token 边界导致的失败(可验证实验):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")

# 大小写转换
enc.encode("token")   # [4,5] → 某个 ID
enc.encode("TOKEN")   # [35,36] → 完全不同的 ID
# 对模型来说,"token" → "TOKEN" 是映射到不同 embedding 空间的操作

# 字符计数难题
enc.encode("strawberry")  # ["str", "aw", "berry"] 或 ["straw", "berry"]
# 字母 "r" 分散在不同 token 中,模型需要"打破 token 边界"来计数

结论:任何涉及字符操作(计数、拼写、大小写转换)的任务,难度取决于 tokenization 是否把相关字符放在同一 token 里。

⚠️ 常见误区

  1. 误区:LLM 在”字符级别”操作,所以字符任务应该很简单 → 正确:LLM 在 token 级别操作。字符任务(计数 r 的个数、拼写检查)对 LLM 来说并非”简单”,而是需要隐式分解 token 边界的困难任务。
  2. 误区:GPT-4 答不出”strawberry 有几个 r”是智能问题 → 正确:这是 tokenization 问题,而非推理能力问题。给模型提供”请先把每个字符写出来”的提示(强制字符化),正确率大幅提升。

7. Multilinguality(多语言性)

Slide 62 Slide 63 Slide 64 Slide 65 Slide 66
  • 世界上有 ~7000 种语言,但 NLP 研究集中在少数几种
  • 跨语言迁移(Cross-lingual Transfer)
    • 在高资源语言上训练,迁移到低资源语言
    • 共享词表 + 共享 Transformer 参数实现跨语言理解
  • 语言公平性问题:不同语言的 LLM 性能差距悬殊

📐 多语言 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 词表)都专门扩充了多语言支持。

📚 已收录至 拓展阅读知识库

🔢 数值计算示例

词表分配对比(近似,mBERT vs XLM-R):

模型词表大小语言数英文 fertility中文 fertility阿拉伯文 fertility
mBERT110K104~1.3~1.5~3.0
XLM-R250K100~1.2~1.3~1.8

XLM-R 通过更大词表 + 上采样低资源语言,使各语言 fertility 更平衡(1.5–2.0),阿拉伯文不再被严重碎分。

💡 为什么这样做?

多语言 NLP 的核心挑战是”资源不平等”——英文数据是阿拉伯文数据的几百倍。BPE 按频率合并,自然偏向英文。对低资源语言而言,每个词被拆得很碎,每个子词 token 携带更少语义信息,模型难以学习跨语言语义对齐。上采样低资源语言是一种”积极行动”,强制让 tokenizer 为弱势语言提供更公平的表示能力。

⚠️ 常见误区

  1. 误区:“多语言模型 = 多种语言都好” → 正确:多语言能力存在容量稀释(capacity dilution)——同等参数量下,多语言模型在任意单一语言上都弱于专门针对该语言的单语言模型。这是”兼顾所有语言”必须付出的代价。
  2. 误区:扩大词表能完全解决多语言不公平问题 → 正确:词表是必要条件,但训练数据的语言比例、模型参数对每种语言的分配同样重要。即使词表完美,如果训练数据 99% 是英文,模型对其他语言的理解仍然有限。

8. 多语言 Tokenization 的挑战

Slide 67 Slide 68 Slide 69 Slide 70 Slide 71 Slide 72 Slide 73 Slide 74 Slide 75 Slide 76
  • 英语主导的 tokenizer 对其他语言不公平:
    • 同一含义的文本,非英语语言可能需要 2-10x 更多 token
    • 导致更高的 API 成本、更短的有效上下文窗口
  • 词表分配不均:大部分 token 分配给英语
  • 解决方向:多语言平衡的 BPE 训练、language-specific adapter

推荐阅读

  • Jurafsky & Martin, Ch2 — 正则表达式、文本归一化、编辑距离
  • BPE — Sennrich et al., 2016
  • XLM-R — Conneau et al., 2020(跨语言预训练)
  • Tokenization cost paper — 多语言 tokenization 公平性分析

关联概念

个人笔记