LLM實踐系列-詳談Tokenizer訓練細節
經過了數據收集、篩選、去重，馬上就可以開始訓練實驗了。但是在實驗之前，我們還需要先獲取一個語言模型的基石：分詞器（Tokenizer）。Tokenizer 的作用是對一條文本數據進行切分、詞表映射，得到這條文本的token序列。
用開源 Tokenizer 還是自己訓練
Tokenizer可以自己訓練，也可以從目前開源的模型中扒一個來用，用開源Tokenizer有幾個點需要著重關注：
- 壓縮率：壓縮率決定了文本向量化后的長度，壓縮率越高，向量后數據越短，訓練和推理效率越高，但是對訓練數據的數量要求也越大，主流的tokenizer對漢字的壓縮率都在1.5-1.6之間，也就是1.5-1.6個漢字劃分為一個token。
- token覆蓋率：token覆蓋率不用糾結細節，只需要關注是否有你的目標語種的token，比如llama的tokenizer中文就很少，相應地中文上壓縮率就比較低，token向字節流的退化率比較高，也一定程度的反應了中文訓練數據不多。
- 預留token數量：預留token也叫特殊token，一般寫作reserved_token、unused_token，paded_token，都是一個意思。這些token是指不會出現在自然語料中，僅保留為后續post train階段的一些特殊用途使用。比如任務隔離、角色隔離、function call的特殊指令、agent特殊指令等等。預留token最好足夠，100-1000為佳。如果下載的tokenizer預留token不夠，可以手動添加。
- 詞表大小：目前開源的tokenizer詞表大小一般在8萬或15萬左右。詞表越大，壓縮率一般也越高，同時模型的embedding層和logits層也會更大，對顯存資源敏感的需要注意一下。
有開源tokenizer，訓練自己的tokenizer意義何在？用自己的數據訓練的 tokenizer，在同詞表大小的情況下，會比開源tokenizer有更高的壓縮率（也不會高太多），可以一定程度降低訓練和推理成本。另外更主觀一點的原因是，訓tokenizer是個很基礎的工作，訓不訓一定程度上反映了團隊的技術棧是否全面。還有一點需要注意的是，不同壓縮率的tokenizer訓練的模型loss可能有差別，但是性能不會有太大差別。
經典的分詞器有WordPiece 、subword-nmt、Unigram等等，但是這些并不是本文的重點，本文主要說目前最流行的兩種tokenizer：BPE和BBPE。
BPE（Byte Pair Encoding）
BPE是目前大模型主流的兩種分詞法之一，訓練過程總結成一句話就是：迭代合并當前最高頻的token對，直到到達預設詞表大小上限。舉個具體的例子來說，假設我要訓練一個詞表大小是12的tokenizer，訓練語料就是下面這句話：
“海水潮潮潮潮潮潮落,浮云長長長長長長長消”
1、 這句話首先會按字拆分成：海 水 潮 潮 潮 潮 潮 潮 落 , 浮 云 長 長 長 長 長 長 長 消。
我沒數錯的話算上逗號應該是總共有9個不重復的字。這些字會被當作初始token，加入詞表。現在我們離目標詞表大小還差12-9=3個token，下面開始迭代合并。
2、 統計當前已經加入詞表的所有token兩兩組合在訓練語料中出現的次數。
這里有兩點注意，首先是“當前”，也就是說每次迭代加入新token后，下一次統計兩兩組合要算上這個新token。其次是“所有token兩兩組合”，也就是既要統計A token與B token的組合，也要統計A token與自身的組合。比如上面這個句子，我們要統計“海水”、“水潮”、“潮潮”、”潮落“....這些所有兩兩組合出現的次數。
3、 取兩兩組合中出現次數最高的那一個，作為新token加入詞表，同時記錄下這個token的合成路徑。
比如上面“潮潮”和“長長”是出現次數最高的組合，都出現了5次，那么我們取更早出現的“潮潮”作為本次要加入詞表的新token，同時記錄下”潮“+”潮“=”潮潮“。現在詞表大小為10。
4、 如果詞表沒有達到設定的上限12，那么就迭代執行2-3步。
再一次統計兩兩組合出現次數，這一次最多的就是剛才并列第一的“長長”。當然也不要忘記上一步剛加入的“潮潮”這個token，他可以和前面的token組成“水潮潮”，也可以和后面的token組成“潮潮潮”，不過次數都不如“長長”。所以這一次加入詞表的是“長長”。
再迭代一次，再統計組合，此時次數最多的是“潮潮”+“潮” 組成的“潮潮潮”，以及“長長”+“長”組成的“長長長”，分別出現4次。按照之前的原則，取次數最多且更靠前的“潮潮潮”加入詞表，此時詞表大小為12，訓練停止，我們已經得到了大小為12，在“海水潮潮潮潮潮潮落,浮云長長長長長長長消”上訓練的分詞器。
BPE的訓練過程還是很簡單很好理解的，但是還是有一些需要注意的地方。上面的解釋中有兩個我刻意嚴謹表達的點，一個是「取次數最多且更靠前的“潮潮潮”加入詞表」，另一個是「“潮潮”+“潮” 組成的“潮潮潮”，以及“長長”+“長”組成的“長長長”」。前者想說明token加入詞表的順序是有先后的，是有優先級的，后者說明token的合成路徑方式需要嚴格遵循，改變詞表可能導致錯誤的合成路徑。
特意強調這個是因為我看到一些改詞表的開源工作其實是有問題的。舉個我看到的實際的例子，有一個地名”烏魯木齊“，假設詞表中包含”烏魯“和”魯木“兩個token。首先說可不可能出現這倆token？完全可能，如果我的訓練語料是下面這樣的就會出現這兩個token：
烏魯
烏魯
魯木
魯木
齊這個語料訓出來的tokenizer詞表大概率是這樣的：「烏」「魯」「木」「齊」「烏魯」「魯木」
如果詞表里烏魯這個token在前，分詞結果就是 「烏魯」「 木」「 齊」，如果是魯木這個token在前，分詞結果就是「烏」「魯木」「齊」。分詞結果是不一樣的。如果拿到一個訓練過的模型，改一改詞表順序，肯能會導致分詞結果的不一致，模型可能完全沒有見過這樣的token，導致一些無法理解的怪異生成結果。
再說合成路徑，如果我的詞表是 「烏」「魯」「木」「齊」「烏魯」「木齊」，后來擴增了詞表，增加了「烏魯」+「木」=「烏魯木」，和「烏魯木」+「齊」=「烏魯木齊」兩個token，「烏魯木齊」這個token是合成不出來的，因為「木齊」在「烏魯木」之前，所以優先合成「木齊」，而不是「烏魯木」，那么沒有「烏魯木」，自然無法合成「烏魯木齊」。如果要進行詞表刪減、擴增，或者兩個tokenizer進行合并，尤其要注意這個問題。
BBPE（Byte-Level Byte Pair Encoding）
BBPE和BPE大體上是一樣的，區別在于BPE把文本看作字符集合，第一步是按照字符切分獲得初始token，BBPE把文本看作是二進制編碼，按照8bit切分獲得原始token。比如還是上面那句話，會先轉成utf8編碼：
“海水潮潮潮潮潮潮落,浮云長長長長長長長消” =>
"\xe6\xb5\xb7\xe6\xb0\xb4\xe6\xbd\xae\xe6\xbd\xae\xe6\xbd\xae\xe6\xbd\xae\xe6\xbd\xae\xe6\xbd\xae\xe8\x90\xbd\x2c..."
然后取每一個2位16進制數作為初始token，也就是「\xe6」「\xb5」「\xb7」...這些。剩下的統計兩兩組合、合成路徑都和BPE是一樣的，不過都是在二進制層面去合并。我們知道utf8是變長編碼，ascii字符在utf8中的編碼長度是1，也就是剛好一個2位16進制數。比如我上面句子里的逗號對應的utf8編碼是“\x2c”。所以ascii字符一定會作為一個基礎字符加入詞表，而且也不會被拆分，所以英文單詞、數字這種ascii字符組成的詞，一定是整數個token表示的。但是漢字的編碼長度大部分是3，比如“海”的編碼是“\xe6\xb5\xb7”，這就導致漢字在bbpe的詞表中并不一定是1個、2個字這種整數個token組成。可能是3/2個token表示一個漢字。
BBPE與BPE的對比
從流行度來說，BPE是去年、前年大家普遍使用的方法，而BBPE是去年底到今年的模型主要使用的方法。GPT2使用的tokenizer也是BBPE。
從編碼的角度，有一些文章說BBPE對比BPE的優勢是不存在OOV問題，字符只要能轉utf8，就一定能被BBPE表示，但是實際執行起來并不是，因為大部分BPE的庫也支持bytes退化，遇到超出詞表范圍的字符，也會退化到二進制表示。這么看下來BBPE剩下的優點就是多語種下、token切分更均勻。畢竟一個中文能占3/2個token了。
從實現的角度，BPE的tokenizer用sentencepice庫的居多，BBPE用huggingface的tokenizers庫的居多，但是sentencepice庫產出的tokenizer.model本質是一個protobuf文件，可以用protobuf庫讀出這個tokenizer原始的訓練參數，甚至帶著訓練語料的磁盤路徑，不太安全。
訓練參數
除了最基本的詞表大小外，實際訓練的tokenizer還有一些可配置關鍵參數。我比較喜歡讀google的文檔，就拿sentencepice的訓練參數來介紹了，兩個庫的可配置參數其實差不多，可以類比。
--vocab_size
tokenizer預設的詞表大小。最終模型訓練的時候，我們一般會確保embedding層的shape可以被128整除，這個一方面是為了量化考慮，一方面是為了序列并行考慮。所以可以在這一步直接設置一個能被128整除的詞表大小，也可以這里不設置，等tokenizer訓練完了加一些特殊token，補到128的倍數。另外詞表大小也決定了壓縮率。
--character_coverage
字符覆蓋率。這個表示在最一開始，初始單字token要覆蓋訓練語料中全部token的百分之多少。如果是1，表示所有token只要出現就加入初始詞表，這會導致詞表的單字token過多。一般可以設置0.9998、0.9999，表示初始單字token要覆蓋訓練集字符的99.99%
--max_sentencepiece_length
單一token最多多少個字符組成，一般設為2、4、6，8或以上就比較大了，不太推薦，可能會出現低頻超長token。
--split_digits
是否做數字的一致性切分，說白了就是數字和其他token是否可以組合成新token，還是數字必須一個字符一個token不做合并。早期一些工作認為開了對數學任務有好處，但是從我的實驗上來看，是可以打開，但不是必須。數字在自然界是均勻分布的，也就是說1、2、3還是111、222、132、863數量其實是差不多的，所以就算不開一致性切分，這些token也都應該在詞表里。只要模型訓練充分，模型是能分辨111和1 1 1是一個東西的。我一直認為不應該對語言模型的泛化抱有太樂觀的態度，它就只能說出見過的話。所以我不指望在欠訓練的模型上，依賴一致性切分提高數學能力。當然這是理想情況，如果數據集準備的不充分，不能保證所有這些數字都出現在詞表里，可以手動把0-9999添加到詞表里，這樣既保持一致性，又能提高壓縮率。說個題外話，前段時間知乎上流行討論為什么9.11>9.8，我認為就是token欠訓練，又剛好沒有泛化過來。為什么沒有泛化過來呢？因為真的有9.11大于9.8的時候。python3.11就大于python3.8
--allow_whitespace_only_pieces
允許多個空格作為一個token，一般是允許，主要是為了排版，比如python的代碼排版。當然也可以不開，手動把1-20個空格組成的token添加到詞表里。
-user_defined_symbols
這個主要就是為了配置之前說的特殊token，可以預留幾百比如<reserved_0> <reserved_1> ...，如果要手動添加數字的一致切分和連續空格token，也可以在這里加
--byte_fallback
之前說的二進制退化，讓BPE當半個BBPE用
--remove_extra_whitespaces
是否刪除多余空格，這個一般改為False，不要讓tokenizer隨便動我們的空格。
--unk_id 、--bos_id、--eos_id、--pad_id 、 --unk_piece、--bos_piece、--eos_piece、--pad_piece
指定控制字符和ID，這里面現在我們一般只用pad和eos。在訓練的時候文檔或者一個turn的末尾增加一個eos token。需要做padding補齊的時候拼pad token，也可以直接用eos token當補齊token。不過建議四個都設置上，也算是致敬一下之前的NLPer
番外篇1:tokenizer與loss
不同tokenizer的壓縮率，每個token的信息量是不同的，這就導致不同tokenizer在同一份數據下訓練出來的模型loss不一樣。假設不考慮訓練tokenizer的語料質量差異，那么tokenizer的壓縮率越高，同一個文本分詞后產生的token越少，整句話的平均loss就越高。相反壓縮率越低，一句話的loss通常也越低。但是實際推理起來，兩種tokenizer訓出來的模型效果差異不大，所以更多的還是從效率和成本的角度考慮壓縮率的取舍吧。
再引申一下，從這一點上不禁讓我們升起一個疑惑，loss能代表模型性能嗎？答案是不行。其實同loss不同tokenizer、同loss不同參數量的模型性能都不一樣。這個具體可以等寫到scaling law擬合、模型性能預測或者continue pretraining的時候再討論。
番外篇2：看一看真實的tokenizer
再拿qwen2的tokenizer舉例，qwen2的tokenizer時BBPE，重要文件有這么幾個：
圖片
merges.txt就是保存合成路徑的文件，里面看上去會有一些像亂碼的東西：
圖片
這些其實是轉義后的控制字符。前面也說了BBPE的初始token是2位16進制數。如果直接存這些二進制字符，可能被翻譯成ascii碼中的控制字符，比如換行制表符之類的，所以這里坐了下轉義。
vocab.json是每次token的映射id，tokenizer_config.json里面可以配置一下控制字符。tokenizer訓練完之后如果想加特殊字符，也可以在這里配置。
番外篇3:詞表增減問題
詞表的修改最好發生在模型訓練之前，包括tokenizer合并、添加特殊token、自定義token等等，這其中還尤其要注意增加詞表。語言模型訓練的時候，計算logits時是hidden_states和所有token的logits_weight的乘積，softmax也是所有token的歸一，刪除詞表相當于減小歸一化的分母，會導致最后sample時的概率發生變化。添加token則跟要小心，如果添加的token未經訓練，可能導致歸一化后亂掉。如果添加的token初始化的不好，比如正常token是1e-2，新增加的token是1e-23量級，rms norm會回傳給embedding層一個大概在1e21量級的梯度。這個時候如果你開了梯度裁切，在求梯度的模長的時候1e21求平方直接變成inf，再歸一化其他token，所有token梯度都會變成0，這樣你不太看得出來報錯，但是embedding實際一點沒訓。
再有就是前文強調過的，注意處理合成路徑和token順序的沖突問題。
