词表与 Trie：Tokenizer 的切词秘密
大模型原理篇见过分词，这次看底层：一棵前缀树怎么把「五花肉」整块认出来。亲手沿着 Trie 走一次分词
本页解决的问题
先给结论「词表与 Trie：Tokenizer 的切词秘密」要解决的关键问题是什么？
大模型原理篇见过分词，这次看底层：一棵前缀树怎么把「五花肉」整块认出来。亲手沿着 Trie 走一次分词
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
假设词表里有这些词：五、五月、五花肉、今天、天、天气、吃、花、好。按第一个字、第二个字……一层层挂起来，共享开头的词就共享树枝——「五月」和「五花肉」挤同一根「五」枝。带绿色 ✓ 的节点表示「走到这里是一个完整的词」；注意「五→花」那个节点没有 ✓：它只是路过的中转站（「五花」不是词）。
🧩 BPE：把「最常一起出现的字符对」反复合并成块
真实的 Tokenizer（GPT、DeepSeek 都在用的 BPE）建词表的方式更野：先把所有文字拆成最小碎片，然后数一数哪两个碎片最常挨在一起，把它们粘成一块收进词表；再数、再粘，重复几万次。常见组合就这样一层层「长」成了大块词元——和 Trie「常见的词整块收纳」是同一个思想。
所以你见过的现象都有了解释：「的」「，」永远只占一个 token；生僻字反而被拆成好几块。这也是中文普遍比英文费 token 的原因——大多数词表以英文语料为主训练，英文常见词都攒出了整块词元，中文攒得少，只好多切几刀。同一句话，中文版账单往往更贵，根子就在词表这本「字典」收纳了谁。
「先看收纳 · 词表怎么挂成一棵树」如何改变一次回答
「假设词表里有这些词： 五 、 五月 、 五花肉 、 今天 、 天 、 天气 、 吃 、 花 、 好 。按第一个字、第二个字……一层层挂起来，共享开头的词就共享树枝——「五月」和「五花肉」挤同一根「五」枝。」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「真实的 Tokenizer（GPT、DeepSeek 都在用的 BPE ）建词表的方式更野：先把所有文字拆成最小碎片，然后数一数 哪两个碎片最常挨在一起 ，把它们粘成一块收进词表；再数、再粘，重复几万次。常见组合就这样一层层「长」成了大块词元——和 Trie「常见的词整块收纳」是同一个思想」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- 词表是一本字典 ：收纳所有词元；分词就是「查着字典把句子切成块」
- Trie 按共享开头收纳 ：让「最长匹配」一步一查、不用回头路
- 贪婪最长匹配 ：能走多深走多深，走不通回退到最近的词尾切刀
先保留会改变判断的内容
可以用「所以你见过的现象都有了解释：「的」「，」永远只占一个 token；生僻字反而被拆成好几块。这也是 中文普遍比英文费 token 的原因——大多数词表以英文语料为主训练，英文常见词都攒出了整块词元，中文攒得少，只好多切几刀。同一句话，中文版账单往往更贵，根子就在词表这本「字典」收纳了谁」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「先看收纳 · 词表怎么挂成一棵树」走到「揭底 · 真实大模型用的是 BPE，思想同源」
「先看收纳 · 词表怎么挂成一棵树」先把问题落在「假设词表里有这些词： 五 、 五月 、 五花肉 、 今天 、 天 、 天气 、 吃 、 花 、 好 。按第一个字、第二个字……一层层挂起来，共享开头的词就共享树枝——「五月」和「五花肉」挤同一根「五」枝。 带绿色 ✓ 的节点表示「走到这里是一个完整的词」 ；注意「五→花」那个节点没有 ✓：它只是路过的中转站（「五花」不是词）」上；到了「揭底 · 真实大模型用的是 BPE，思想同源」，讨论继续推进到「真实的 Tokenizer（GPT、DeepSeek 都在用的 BPE ）建词表的方式更野：先把所有文字拆成最小碎片，然后数一数 哪两个碎片最常挨在一起 ，把它们粘成一块收进词表；再数、再粘，重复几万次。常见组合就这样一层层「长」成了大块词元——和 Trie「常见的词整块收纳」是同一个思想」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「先看收纳 · 词表怎么挂成一棵树」：假设词表里有这些词： 五 、 五月 、 五花肉 、 今天 、 天 、 天气 、 吃 、 花 、 好 。按第一个字、第二个字……一层层挂起来，共享开头的词就共享树枝——「五月」和「五花肉」挤同一根「五」枝。 带绿色 ✓ 的节点表示「走到这里是一个完整的词」 ；注意「五→花」那个节点没有 ✓：它只是路过的中转站（「五花」不是词）
- 「揭底 · 真实大模型用的是 BPE，思想同源」：真实的 Tokenizer（GPT、DeepSeek 都在用的 BPE ）建词表的方式更野：先把所有文字拆成最小碎片，然后数一数 哪两个碎片最常挨在一起 ，把它们粘成一块收进词表；再数、再粘，重复几万次。常见组合就这样一层层「长」成了大块词元——和 Trie「常见的词整块收纳」是同一个思想
- 「最后的要点」：中文费 token 的根子 ：词表偏英文，中文整块词元少，只好多切几刀
最后的「最后的要点」把讨论落到「中文费 token 的根子 ：词表偏英文，中文整块词元少，只好多切几刀」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这一课想和你分享的
- 词表是一本字典：收纳所有词元；分词就是「查着字典把句子切成块」
- Trie 按共享开头收纳：让「最长匹配」一步一查、不用回头路
- 贪婪最长匹配：能走多深走多深，走不通回退到最近的词尾切刀
- BPE 思想同源：最常一起出现的组合反复合并成整块——常见的省，生僻的碎
- 中文费 token 的根子：词表偏英文，中文整块词元少，只好多切几刀
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。