考察点
Tokenizer 题看似基础，实际考察你是否把模型当黑盒。面试官想听：为什么不能直接按字或按词切、BPE 怎么工作、token 粒度对应用层的成本和效果有什么影响。追问常考中文分词、数字被切碎、token 计费估算。
参考答案
为什么不按字切也不按词切
模型输入必须是离散符号的序列，切分粒度两头都是坑。按词切：英文形态变化（run/runs/running）、中文无空格分词、新词网络词层出不穷，词表要么爆炸要么大量 OOV（词表外）无法表示。按字切：词表小了，但序列变得很长——同样的文本，token 数翻好几倍，注意力的平方复杂度直接吃不消，而且单字几乎不携带语义，模型学习负担重。
答案是在字和词之间找折中：用数据驱动的子词（subword）切分，高频词保留为完整 token，低频词拆成有意义的片段。BPE 就是这条路线最经典的算法。
BPE 的工作原理
BPE（Byte Pair Encoding）训练词表的过程是迭代的贪心合并：
- 初始化：把语料拆成最小单元（现代实现从字节级开始，任何字符都能表示，天然无 OOV）。
- 统计：扫描全部语料，找出出现频率最高的相邻 token 对。
- 合并：把这个对合并成一个新 token，加入词表，语料中所有出现位置替换掉。
- 重复第 2、3 步，直到词表达到预设大小（比如 GPT 系列约 5 万，一些新模型 10 万以上）。
训练完后推理时的切分是确定性查表：按合并规则的优先级，把输入文本贪心地切成词表里最长的匹配。所以「unbelievable」可能切成 un + believe + able 三个 token，而「the」这种高频词就是一个 token。合并顺序完全由训练语料的统计规律决定——词表是数据的镜像。
token 粒度对应用层的实际影响
成本直接挂钩。API 按 token 计费，上下文窗口按 token 计算。经验换算：英文 1 个 token 约对应 0.75 个单词，中文常见汉字约 1 字 1 token，生僻字、特殊符号可能 2~3 个 token。做预算和容量规划时别拿字符数估算，用 tiktoken 这类工具跑真实样本。
模型的怪异短板都长在 token 边界上。经典案例：模型数数、比较 9.11 和 9.9 谁大容易错，因为数字常被切得七零八落，「9.11」可能是「9」「.」「11」三个 token，模型看到的是碎片而不是数值。代码里的缩进、JSON 的括号配对问题，根源也常在切分方式上。做数学、结构化输出场景时，这个认知能帮你解释很多诡异 badcase。
prompt 细节里的坑。token 边界对空格敏感，prompt 末尾留不留空格、换行符怎么处理，切出来的序列不同，模型行为可能有微妙差异。Few-shot 示例的格式严格对齐，本质是让 token 序列模式保持一致。
词表大小的权衡与多语言问题
词表不是越大越好。词表大：压缩率高（同样文本 token 更少，推理便宜），但 embedding 层和输出层的参数量随词表线性涨，低频 token 训练不充分。词表小：参数省，但序列变长。多语言模型里这个矛盾很尖锐——以英文为主训练的词表，切中文、阿拉伯语效率低，同样一句话 token 数可能是英文的两三倍，成本和延迟都吃亏。选模型时如果你的业务是中文为主，值得实测一下候选模型对中文语料的切分效率，这一项在 benchmark 上看不出来。
工程工具上，OpenAI 系用 tiktoken，开源界主流是 HuggingFace 的 tokenizers 库和 SentencePiece（LLaMA 系用的就是这个，语言无关、直接吃原始文本）。
可能的追问
- BPE 和 WordPiece、Unigram 有什么区别？BPE 按频率贪心合并；WordPiece 按似然增益选合并对；Unigram 反过来，从大词表出发逐步剪掉贡献小的 token。效果差异不大，生态差异更大。
- 切 chunk 做 RAG 时按字符还是按 token 切？按 token，因为上下文窗口限制的是 token 数；按字符切会估算失准，中文场景偏差尤其大。
- 词表能自己扩展吗？可以，往词表加领域术语新 token 再扩 embedding 层继续训练是领域适配的手段之一，但要补训，否则新 token 的 embedding 是随机的。