读了 GPT-4 分词器源码才明白：为什么 tiktoken 宁可丢掉合并树，也要采用“只读字典”的扁平设计？

tiktoken 的源码里藏着一个让人困惑的事实：当你调用tiktoken.get_encoding("cl100k_base")拿到 GPT-4 的分词器时，你拿到的不是一张合并规则表，而是一个{bytes: int}的字典——每个 key 是一段字节序列，每个 value 是一个整数 rank。没有任何地方告诉你"字节序列 A 和字节序列 B 合并成了字节序列 C"。

打开 minbpe 的gpt4.py，第 29 行有一个函数叫recover_merges()——函数名本身就透着一股不寻常的味道：为什么需要"恢复"合并规则？按理说，一个训练好的 BPE 分词器应该直接存储它的合并规则表才对，就像 minbpe 自己的BasicTokenizer.save()存的那样。但 tiktoken 偏偏不这么做。它只存了合并的结果（parent token 的字节和 rank），却丢掉了合并的过程（哪两个 children 合并成了这个 parent）。

这就像一个编译器只给你.o目标文件，不给你.cpp源文件——你能从目标文件里反推出源文件吗？在一般情况下不能，但在 BPE 合并树这个特定问题上，可以。而gpt4.py的前 46 行代码，就是这个逆向工程的完整实现。

更有意思的是，这段逆向工程代码还揭露了 GPT-4 分词器的一个怪癖——它对最基础的 256 个字节 token 做了一次排列