2 Token 和字、词、子词有什么关系
P0 · rag
🏷 标签：token, subword, tokenization, chinese-nlp
1️⃣ 考察意图
面试官想看你是否真正理解 Token 不是语言学单位，而是模型为了高效处理文本而设计的“计算单元”。这题看似基础，但刁钻点在于：很多人能背出 BPE、WordPiece 的名字，却说不清为什么中文里“词”的边界模糊，导致子词分词比词分词更优。答好了能展示你对 NLP 底层设计原则的掌握——从“词汇表大小 vs 表示能力”的 trade-off 到“未登录词”的工程解法，这是所有 LLM 应用的基石。
2️⃣ 标准答
Token 是模型视角的“原子单元”，而字、词、子词是语言学或工程视角的文本切分方式。它们的关系是：Token 通常对应子词，但具体取决于分词算法。
1. 定义三个概念
- 字（Character）：书写系统的最小单位。中文里是单个汉字（如“我”），英文里是字母（如“a”）。词汇表固定且小（中文约 6000 常用字），但序列长度极长，语义稀疏。
- 词（Word）：语言学上有意义的最小独立单位。中文里“北京”是一个词，但分词依赖词典和规则（如 jieba），边界模糊（“打球”是词还是“打”+“球”？）。英文里词有空格分隔，但存在形态变化（play/playing/played）。
- 子词（Subword）：介于字和词之间的片段，通过统计频率从语料中学习得到。例如 BPE（Byte Pair Encoding）将“playing”拆成“play”+“ing”，中文里“北京”可能作为一个子词，“天安门”拆成“天”+“安门”。
2. Token 通常是子词现代 LLM（GPT、BERT、LLaMA）都使用子词分词器。原因有三：
- 平衡词汇表大小与表示能力：词分词需要超大词汇表（中文 10 万+），导致 embedding 矩阵巨大、训练慢；字分词词汇表小但序列长（“我爱北京天安门”变成 7 个 token），注意力计算成本高（O(n²)）。子词将词汇表控制在 3-5 万，同时保持合理序列长度。
- 处理未登录词（OOV）：词分词遇到新词会直接报错或映射为 [UNK]，丢失信息。子词可以拆成已知片段（如“DeepSeek”拆成“Deep”+“Seek”），保证模型能处理任意输入。
- 捕捉形态学信息：英文中“running”拆成“run”+“ning”，让模型学到时态变化；中文中“程序员”拆成“程序”+“员”，保留语义组合性。
3. 中文场景的工程取舍中文没有天然分隔符，子词分词面临独特挑战：
- 坑 1：单字词过多。BPE 在中文上容易把高频单字（“的”“了”“我”）作为独立 token，导致序列长度仍偏长。解法：使用 Unigram LM 分词器（如 SentencePiece），通过概率模型合并低频字对，生成更语义完整的子词（如“北京”而非“北”+“京”）。
- 坑 2：领域术语切分错误。医疗文本中“心肌梗死”可能被拆成“心肌”+“梗死”，但模型需要整体理解。解法：在预训练前注入领域词典作为种子词，强制分词器保留这些短语（如 LLaMA 的 BPE 支持自定义 merges）。
- trade-off：子词粒度越粗（接近词），语义保留越好但 OOV 风险高；粒度越细（接近字），泛化性越强但序列长。实践中用 32k-50k 词汇表，配合 512-2048 的 max_length 做折中。
4. 具体例子对比句子“我爱北京天安门”：
- 字分词：
[我, 爱, 北, 京, 天, 安, 门]（7 tokens，词汇表 6000） - 词分词：
[我, 爱, 北京, 天安门]（4 tokens，词汇表 10 万+，但“天安门”可能不在词典中） - 子词（BPE）：
[我, 爱, 北京, 天, 安门]（5 tokens，词汇表 3 万，“安门”是常见子词）
5. 总结Token 是模型的计算单元，字/词/子词是文本的切分策略。子词分词通过统计学习找到最优粒度，是当前 LLM 的标准做法。理解这个关系，才能正确设计 tokenizer 配置（如 max_length、vocab_size）和评估模型输入效率。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，定义层面，字是书写单位，词是语义单位，子词是统计片段；第二，工程层面，Token 通常对应子词，因为子词平衡了词汇表大小和 OOV 处理能力，比如 BPE 把‘playing’拆成‘play’+‘ing’；第三，中文特殊点，用 SentencePiece 的 Unigram 模型比 BPE 更适合中文，因为能减少单字 token 过多的问题。总结一句：Token 是模型视角的原子单元，子词是当前最优的映射策略。”
4️⃣ 高频追问 & 应对
追问 1：为什么 BERT 用 WordPiece 而 GPT 用 BPE？它们在中文上表现有区别吗？
核心区别在合并策略：BPE 基于频率合并最频繁的字节对，WordPiece 基于概率（最大化训练数据似然）合并能提升似然最大的子词对。中文上，WordPiece 倾向于保留更完整的语义单元（如“北京”），BPE 可能拆得更碎（如“北”+“京”）。实际工程中，两者差异不大，但 SentencePiece 的 Unigram 模型在中文上更优，因为它支持多候选合并。如果面试官追问，可以提一下 LLaMA 用 BPE 但加了字节级 fallback 来处理 Unicode 字符。
追问 2：如果词汇表大小从 32k 增加到 128k，模型效果和效率会怎么变化？
效果上，更大词汇表减少序列长度（每个 token 携带更多信息），可能提升长文本理解；但 embedding 矩阵变大，训练参数量增加（词汇表 * hidden_dim），且稀疏性导致优化困难。效率上，推理时 softmax 计算量随词汇表线性增长，128k 的词汇表会让解码速度下降 2-3 倍。实际 trade-off：32k-50k 是黄金区间，超过 100k 通常只用于多语言模型（如 mT5 的 250k 词汇表）。
追问 3：中文里“字”作为 token 有什么实际应用场景？
字分词在字符级任务（如 OCR 纠错、拼音输入法）中仍有优势，因为序列长度虽长但词汇表极小（6000），embedding 矩阵小，训练快。但 LLM 中几乎不用，因为注意力计算 O(n²) 在长序列上不可接受。一个折中方案是混合粒度：用字分词做底层表示，再用 CNN 或 Transformer 层聚合为子词级表示（如 CharBERT 的做法）。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“Token 就是词，比如‘我爱北京’分成 4 个词 token” → ✅ 正确说法：Token 通常是子词，中文里“北京”可能是一个 token，但“天安门”可能被拆成“天”+“安门”，取决于分词器训练数据。
- ❌ 说“子词分词能完美解决所有 OOV 问题” → ✅ 正确说法：子词能处理大部分 OOV，但极端情况（如生僻字“𠀀”）仍需字节级 fallback（如 GPT-4 的 byte-level BPE）。
- ❌ 说“中文分词用 jieba 就行，LLM 里也这么用” → ✅ 正确说法：LLM 不用 jieba 这类词分词，因为词汇表太大且 OOV 问题严重；必须用子词分词器（如 SentencePiece）来保证可控的词汇表大小和泛化能力。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“chunking 粒度与 tokenizer 对齐”切入，说明为什么文档分块时要考虑 tokenizer 的切分边界（如避免在子词中间截断），以及如何用 tiktoken 库预估 token 数来优化分块策略。
- 如果你只做过传统 NLP：用“词性标注 vs 子词 embedding”类比，说明传统方法依赖词典和规则，而 LLM 通过统计学习自动发现子词边界，本质是从“人工特征工程”到“数据驱动表示”的转变。
- 如果你是校招无项目：聚焦“BPE 算法手写实现”的 demo，展示你理解合并频率计算、词汇表构建、以及中文语料预处理（如用 SentencePiece 训练自定义 tokenizer）的完整流程。
- BPE 原始论文：Neural Machine Translation of Rare Words with Subword Units (Sennrich et al., 2016)
- WordPiece 论文：Google's Neural Machine Translation System: Bridging the Gap between Human and Machine Translation (Wu et al., 2016)
- SentencePiece 工具：Google 开源的无监督文本 tokenizer 和 detokenizer，支持 BPE 和 Unigram
- 中文分词对比实验：Character vs. Word vs. Subword in Chinese NLP (Li et al., 2019) —— 验证子词在中文任务上的优势
- tiktoken 库：OpenAI 的快速 BPE tokenizer，用于 GPT 系列模型，支持预估 token 数