從2019年到現(xiàn)在，是時(shí)候重新審視Tokenization了

2025-01-06 07:10:00

tokenization 對(duì)語言模型中的算術(shù)性能有顯著影響。通過仔細(xì)選擇，我們可以根據(jù)問題類型優(yōu)化 tokenization 策略，從而提高 LLM 在數(shù)學(xué)任務(wù)上的表現(xiàn)。

2019 年問世的 GPT-2，其 tokenizer 使用了 BPE 算法，這種算法至今仍很常見，但這種方式是最優(yōu)的嗎？來自 HuggingFace 的一篇文章給出了解釋。

「9.9 和 9.11 到底哪個(gè)大？」這個(gè)問題一度難壞了各家大模型。

關(guān)于模型為什么會(huì)答錯(cuò)，研究人員給出了各種猜測(cè)，包括預(yù)訓(xùn)練數(shù)據(jù)的構(gòu)成和模型架構(gòu)本身。

在一篇新博客中，來自 HuggingFace 的研究者討論了可能造成這一問題的原因之一 ——tokenization，并重點(diǎn)分析了它如何影響模型的數(shù)學(xué)能力，尤其是算術(shù)能力。

回顧 Tokenization

早在 2019 年，GPT-2 論文就詳細(xì)介紹了將 BPE（byte-pair encoding）用于語言模型的 tokenization 方法。此方法的工作原理是將頻繁出現(xiàn)的子詞合并為單個(gè)單元，直到詞匯量達(dá)到目標(biāo)大小。

然而，這種做法生成的詞匯表在很大程度上取決于輸入到 tokenizer 中的訓(xùn)練數(shù)據(jù)，從而導(dǎo)致了在數(shù)字編碼方式上的不一致性。例如，在訓(xùn)練數(shù)據(jù)中常見的數(shù)字（例如 1-100、1943 年這樣的表示）很可能被表示為單個(gè) token，而較少見到的數(shù)字則被拆分成多個(gè) token，如下所示：

四年后，Llama 系列來了！Llama 和 Llama 2 使用 SentencePiece （一個(gè)用于基于文本生成的無監(jiān)督文本 tokenizer ）的 BPE 實(shí)現(xiàn)，并對(duì)數(shù)字進(jìn)行了顯著的調(diào)整：它們將所有數(shù)字拆分為單個(gè)數(shù)字。這意味著只有 10 個(gè)唯一 token（0-9）來表示任何數(shù)字，從而簡(jiǎn)化了 LLM 的數(shù)字表示。Deepseek 后來發(fā)布了一個(gè)模型 (DeepSeek-V2)，它有一個(gè)類似的單位數(shù)（single-digit）的 tokenizer 。

后來，Llama 3 采用了不同的方法來處理數(shù)字，將它們 tokenizing 為三位數(shù)。因此，從 1 到 999 的數(shù)字每個(gè)數(shù)都有唯一的 token，而從 1000 開始的數(shù)字由這些 token 組成。

一個(gè)新的范式：從右到左的 Tokenization

到目前為止，我們所看到的 tokenization 方法都是從左到右處理文本的。例如，如果三位數(shù)字的分詞法遇到序列 12345，它將從開頭掃描，將其分解為 123 和 45 這樣的片段。

與從左到右（L2R）的分詞方法不同，從右到左（R2L）的分詞方法以三個(gè)字符為一組，從文本的末尾開始向開頭處理。使用 R2L 分詞，序列 12345 將通過從右側(cè)掃描進(jìn)行分詞，首先分割出 345，然后再處理 12。最近，一些前沿的閉源模型也在探索使用這種 R2L 分詞方法，這已經(jīng)被證明對(duì)某些算術(shù)運(yùn)算有益，因?yàn)?R2L 表示可以防止操作數(shù)的錯(cuò)位。還有傳言稱 Claude 使用了這種 R2L 分詞方法。

為了更好地理解錯(cuò)位是什么樣子的，讓我們以 3789 + 8791 為例：

如上所示，在三位數(shù)從左到右（L2R）的例子中，9 + 1 應(yīng)該映射到數(shù)字 0，但實(shí)際上卻與 8 組合在一起形成了 80，因?yàn)榍懊娴娜齻€(gè) token（125）已經(jīng)被分在一起了。tokenization 邊界的偏移在學(xué)習(xí)過程中引入了額外的復(fù)雜性，已經(jīng)證明準(zhǔn)確性是有害的。

而在從右到左（R2L）的例子中，數(shù)字 580 和對(duì)應(yīng)的子操作數(shù) 789 和 791 很好地對(duì)齊了。

以下是用于處理數(shù)字 tokenization 的技術(shù)概述：

不同方法的比較

該研究旨在比較多個(gè) tokenizer 以及它們處理數(shù)字的不同方式，以盡量減少模型架構(gòu)、訓(xùn)練配置和預(yù)訓(xùn)練數(shù)據(jù)等外部因素在評(píng)估結(jié)果中的影響。因此，每個(gè)模型之間唯一的區(qū)別應(yīng)該是 tokenizer。

實(shí)驗(yàn)選擇了 3 種 tokenizer，分別是 GPT-2 的 BPE tokenizer、Llama 3 的三位數(shù) tokenizer（three-digit tokenizer）和 Deepseek 的單位數(shù) tokenizer（single-digit tokenizer）。

from transformers import AutoTokenizer
from tokenizers import pre_tokenizers, Regex

# Initialize all tokenizers
tokenizer = AutoTokenizer.from_pretrained ("meta-llama/Meta-Llama-3-8B")

# Add an extra step to the existing pre-tokenizer steps
tokenizer._tokenizer.pre_tokenizer = pre_tokenizers.Sequence (
            [
                # Added step: split by R2L digits
                pre_tokenizers.Split (pattern = Regex (r"\d {1,3}(?=(\d {3})*\b)"), 
                  behavior="isolated", invert = False),
                # Below: Existing steps from Llama 3's tokenizer
                pre_tokenizers.Split (pattern=Regex (r"(?i:'s|'t|'re|'ve|'m|'ll|'d)|[^\r\n\p {L}\p {N}]?\p {L}+|\p {N}{1,3}| ?[^\s\p {L}\p {N}]+[\r\n]*|\s*[\r\n]+|\s+(?!\S)|\s+"), 
                  behavior="isolated", invert=False), 
                pre_tokenizers.ByteLevel (add_prefix_space=False, trim_offsets=True, use_regex=False)
            ]
        )

print (tokenizer.tokenize ("42069")) # [42, 069]

訓(xùn)練模型使用了原始的 Llama 架構(gòu)，此外，該研究還調(diào)整了隱藏層的數(shù)量，以確保每個(gè)模型大致具有相同數(shù)量的參數(shù)（約 14.5 億）。

為了保持恒定的計(jì)算預(yù)算，本文減少了具有更大詞匯表模型中的隱藏層數(shù)量。

結(jié)果

算術(shù)問題

如下圖所示，單位數(shù) tokenization 優(yōu)于其他 tokenizer 方法。

結(jié)果顯示，雖然在較簡(jiǎn)單的問題上差異不太明顯，但隨著問題復(fù)雜性的增加，表現(xiàn)最佳的 tokenizer（單位數(shù)分詞）與其他 tokenizer 之間的差距越來越大。這表明單位數(shù)分詞對(duì)于輸入數(shù)據(jù)長(zhǎng)度的變化更為魯棒，并且能夠更好地捕捉復(fù)雜的模式，從而在其他分詞方法難以應(yīng)對(duì)的場(chǎng)景中提升性能。

此外，本文還發(fā)現(xiàn)浮點(diǎn)數(shù)和整數(shù)之間的性能差距在所有 tokenizer 中都是相似的。這表明在這兩個(gè)類別中選擇 tokenizer 時(shí)，并不存在固有的權(quán)衡，即對(duì)于整數(shù)最優(yōu)的 tokenizer 對(duì)于浮點(diǎn)數(shù)也是最優(yōu)的。

如下圖所示，三位數(shù) R2L tokenization 比標(biāo)準(zhǔn)三位數(shù) L2R tokenization 具有更好的性能。

本文發(fā)現(xiàn)，與使用默認(rèn) L2R token 數(shù)據(jù)進(jìn)行訓(xùn)練相比，使用 R2L token 數(shù)據(jù)進(jìn)行訓(xùn)練的模型取得了顯著的改進(jìn)（乘法除外）。這表明，與典型的從左到右編碼相比，它是算術(shù)運(yùn)算的最佳設(shè)置。

當(dāng)數(shù)字被從右向左每 3 位一組進(jìn)行分塊時(shí)，Pure-BPE（Byte Pair Encoding）tokenizer 顯示出不一致的性能。

顯然，沒有任何額外數(shù)字預(yù)處理的純基于 BPE 的 tokenizer 不會(huì)從使用 R2L token 化中受益。一個(gè)可能的解釋是，這些 tokenizer 中數(shù)字分組的方式缺乏結(jié)構(gòu)。

基于單詞的問題

雖然在基于單詞的問題上，不同 tokenizer 之間的性能差距不太明顯，但本文觀察到單位數(shù) tokenizer 和三位數(shù) tokenizer 通常優(yōu)于基于 BPE 的 tokenizer。這表明，無論是單詞問題還是數(shù)字問題，這種趨勢(shì)都是一致的。

Llama 3 R2L 推理

接下來本文進(jìn)行了另一項(xiàng)測(cè)試，即現(xiàn)有的預(yù)訓(xùn)練 / 指令模型在接受與最初訓(xùn)練方案不同的 token 化方案時(shí)表現(xiàn)如何，而無需重新訓(xùn)練或微調(diào)。因此，本文基于 Llama3 8B Instruct 模型，并使用上述相同的代碼修改其 tokenizer，以在推理期間執(zhí)行 R2L tokenization，而無需重新訓(xùn)練新模型。

在三位數(shù) tokenization 方案中進(jìn)行兩個(gè)數(shù)相加需要注意的是：結(jié)果有時(shí)會(huì)產(chǎn)生比輸入數(shù)字更多的 token。例如將 999 和 111 相加時(shí)，它們單獨(dú)只需要一個(gè) token，但是當(dāng)它們相加產(chǎn)生 1110 時(shí)，需要兩個(gè) token（1 和 110）。基于這個(gè)觀察，本文想探索在使用 L2R 和 R2L tokenization 對(duì)不同的 token 長(zhǎng)度執(zhí)行加法時(shí)，會(huì)產(chǎn)生多大的差異。

接下來，本文將把導(dǎo)致額外 token 的加法稱為進(jìn)位（carry）加法，而那些沒有進(jìn)位的加法稱為無進(jìn)位（without carry）加法。

本文用 Llama3 8B Instruct 執(zhí)行了不同數(shù)字長(zhǎng)度和進(jìn)位設(shè)置的算術(shù)任務(wù)。結(jié)果發(fā)現(xiàn)，減法、乘法或除法沒有任何顯著的性能差異，因此結(jié)果只展示了加法。