一文詳解GPT tokenizer 的工作原理

來源?| OSCHINA 社區(qū)

在 GPT 模型中，tokenization（詞元化）指的是將用戶輸入的文本分割成 token（詞元）的過程，以讓 GPT 能更好地理解輸入文本的詞義、句法和語義，以及生成更連貫的輸出內(nèi)容。這是非常重要的預(yù)處理操作，對(duì)模型的最終效果有重大影響。

而 tokenizer（詞元生成器）是將文本切分成 token 的工具或組件。它將原始文本轉(zhuǎn)換成模型可處理的數(shù)字形式，為 GPT 的生成與推理提供基礎(chǔ)能力。

本文詳細(xì)介紹了 GPT?tokenizer?的工作原理。作者 Simon Willison 是開源 Web 應(yīng)用框架 Django 的共同發(fā)起人，他也開源了用于探索和發(fā)布數(shù)據(jù)的工具 Datasette。

作者｜Simon Willison

OneFlow?編譯

翻譯｜賈川語言大模型（如 GPT-3/4、LLaMA 和 PaLM）使用 token 作為基本單位進(jìn)行工作。它們接受文本作為輸入，將其轉(zhuǎn)換為 token（整數(shù)），然后預(yù)測(cè)接下來應(yīng)該出現(xiàn)哪些 token。通過操作這些 token，可以更好地了解它們?cè)谡Z言模型內(nèi)部的工作原理。 OpenAI 提供了一個(gè) tokenizer，用以探索 token 的工作方式。我自己構(gòu)建了一個(gè)更有意思的工具，是一個(gè) Observable notebook（?https://observablehq.com/@simonw/gpt-tokenizer?）。在這個(gè) Observable notebook 中，你可以將文本轉(zhuǎn)換為 token，將 token 轉(zhuǎn)換為文本，還可以搜索整個(gè) token 表。這個(gè) Observable notebook 看起來是這樣的：

我在這里切分的文本是：

The dog eats the apples El perro come las manzanas 片仮名

在給定示例中，總共生成了 21 個(gè)整數(shù) token。5 個(gè)對(duì)應(yīng)英文文本，8 個(gè)對(duì)應(yīng)西班牙文本，6 個(gè)（每個(gè)字符兩個(gè)）對(duì)應(yīng)三個(gè)日文字符。兩個(gè)換行符也分別被表示為整數(shù) token。 ? Observable notebook 使用了 GPT-2 的?tokenizer（基于 EJ Fox 和 Ian Johnson 所創(chuàng)建的?優(yōu)秀 notebook?），主要作為教育工具使用，不過 GPT-3 及更高版本的最新?tokenizer?與 GPT-2 的?tokenizer?存在些許差異。 ?

1
探索一些有趣的 token

通過與?tokenizer?進(jìn)行交互可以發(fā)現(xiàn)各種有趣的模式。?大?多數(shù)常見的英語單詞都分配一個(gè) token，如上所示：

“The”: 464

“ dog”: 3290

“ eats”: 25365

“ the”: 262

“ apples”: 22514

需要注意的是：字母的大小寫很重要。以單詞 “the” 為例，大寫字母 T 的 “The” 對(duì)應(yīng)的 token 是 464，而以小寫字母 t 開頭且有一個(gè)前導(dǎo)空格的單詞 “the” 對(duì)應(yīng)的 token 卻是 262。許多單詞的 token 里都包含了一個(gè)前導(dǎo)空格，這樣就不再需要為每個(gè)空格字符使用一個(gè)額外的 token，從而能更有效地對(duì)整個(gè)句子進(jìn)行編碼，相比英語，在對(duì)其他語言進(jìn)行切分時(shí)，效率可能要低點(diǎn)。?西班牙語 “El perro come las manzanas” 這句話的編碼如下：

“El”: 9527

“ per”: 583

“ro”: 305

“ come”: 1282

“ las”: 39990

“ man”: 582

“zan”: 15201

“as”: 292

此處就顯示出了對(duì)英語的偏向。因?yàn)?“man” 是一個(gè)英語單詞，所以它的 token ID 較低，為 582。而 “zan” 不是一個(gè)在英語中獨(dú)立存在的單詞，但也是一個(gè)常見的字符序列，因此仍然值得擁有自己的 token，所以它的 token ID 為 15201。有些語言甚至?xí)霈F(xiàn)單個(gè)字符編碼為多個(gè) token 的情況，比如以下這些日語：

片: 31965 229

仮: 20015 106

名: 28938 235

2
故障 token

“故障 token”（glitch tokens）是一類令人著迷的 token 子集。其中一個(gè)有趣的例子是 token 23282，即 “davidjl”。可以通過在 notebook 的搜索框中搜索 “david” 來找到該 token。

Scale AI 的 prompt 工程師 Riley Goodside 指出了與該 token 相關(guān)的一些奇怪行為。

為什么會(huì)發(fā)生這種情況？這是一個(gè)有趣的謎題。 token 23282 可能與 Reddit 上的用戶 “davidjl123” 有關(guān)。該用戶是 /r/counting 子論壇的一位熱情用戶，他經(jīng)常在該論壇上發(fā)布遞增數(shù)，并且已經(jīng)發(fā)布了超過 163,000 次這樣的帖子。據(jù)推測(cè)，/r/counting 子論壇中的數(shù)據(jù)最終被用于訓(xùn)練 GPT-2 的 tokenizer。由于用戶 davidjl123 在該子論壇中出現(xiàn)了數(shù)十萬次，所以最終分配到了屬于自己的 token。為什么這種情況會(huì)導(dǎo)致類似問題呢？到目前為止，我看到最好的解釋來自 Hacker News 上的用戶 @londons_explore

這些故障 token 都位于 token 嵌入空間的中心附近。這意味著，模型在區(qū)分這些 token 和其他位于嵌入空間中心附近的 token 時(shí)存在困難，因此當(dāng)被要求 “重復(fù)” 這些 token 時(shí)，模型會(huì)選擇錯(cuò)誤的 token。 ? 這種情況發(fā)生的原因是，這些 token 在互聯(lián)網(wǎng)上出現(xiàn)了很多次（例如，davidjl 用戶在 Reddit 上有 163000 個(gè)帖子，僅僅是計(jì)算遞增的數(shù)字），但是這些 token 本身并不難以預(yù)測(cè)（因此，在訓(xùn)練過程中，梯度變得幾乎為零，并且嵌入向量會(huì)衰減到零，這是某些優(yōu)化器在歸一化權(quán)重時(shí)會(huì)進(jìn)行的操作）。

在 “?SolidGoldMagikarp (plus, prompt generation)?” 這篇帖子下，LessWrong 對(duì)這種現(xiàn)象進(jìn)行了詳細(xì)說明。

3
用 tiktoken 進(jìn)行 token 計(jì)數(shù)

OpenAI 的模型都有 token 限制。有時(shí)在將文本傳遞給 API 之前，需要計(jì)算字符串中的 token 數(shù)量，以確保不超過該限制。其中，一個(gè)需要計(jì)算 token 數(shù)量的技術(shù)是 “檢索增強(qiáng)生成（Retrieval Augmented Generation）”，通過對(duì)文檔語料庫運(yùn)行搜索（或嵌入搜索）來回答用戶的問題，提取最有可能的內(nèi)容，并將其作為上下文涵蓋在 prompt 中。成功實(shí)現(xiàn)這種模式的關(guān)鍵是，在 token 限制內(nèi)包含盡可能多的相關(guān)上下文，因此需要能夠計(jì)算 token 數(shù)量。 OpenAI 提供了一個(gè)名為 tiktoken（?https://github.com/openai/tiktoken?）的 Python 庫來實(shí)現(xiàn)這一功能。如果你深入研究這個(gè)庫，就會(huì)發(fā)現(xiàn)它目前包括五種不同的切分方案：r50k_base、p50k_base、p50k_edit、cl100k_base 和 gpt2。其中，cl100k_base 是最相關(guān)的，它是 GPT-4 和當(dāng)前 ChatGPT 使用的經(jīng)濟(jì)型 gpt-3.5-turbo 模型的 tokenizer。 text-davinci-003 使用的是 p50k_base 。在 tiktoken/model.py 的 MODEL_TO_ENCODING 詞典中可以找到模型與 tokenizer 的完整映射。以下是如何使用 tiktoken 的代碼示例：

import tiktoken

encoding = tiktoken.encoding_for_model("gpt-4")
# or "gpt-3.5-turbo" or "text-davinci-003"
tokens = encoding.encode("Here is some text")
token_count?=?len(tokens)

現(xiàn)在token將是一個(gè)包含四個(gè)整數(shù)token?ID的數(shù)組——在該例中是[8586,?374,?1063,?1495]。

使用.decode()方法將一個(gè)token?ID數(shù)組轉(zhuǎn)換回文本：

text?=?encoding.decode(tokens)
#?'Here?is?some?text'

第一次調(diào)用 encoding_for_model () 時(shí)，編碼數(shù)據(jù)將通過 HTTP 從 openaipublic.blob.core.windows.net Azure Blob 存儲(chǔ)桶（storage bucket）獲?。ùa：?https://github.com/openai/tiktoken/blob/0.4.0/tiktoken_ext/openai_public.py?）。這些數(shù)據(jù)會(huì)被緩存在臨時(shí)目錄中，但如果機(jī)器重新啟動(dòng)，該目錄將被清除。你可通過設(shè)置 TIKTOKEN_CACHE_DIR 環(huán)境變量來強(qiáng)制使用更持久的緩存目錄。

4
ttok

幾周前，我介紹了?tto?k（https://github.com/simonw/ttok）?，這是 tiktoken 的一個(gè)命令行封裝工具，具有兩個(gè)關(guān)鍵功能：一是可以計(jì)算輸入給它的文本中的 token 數(shù)量，二是可以將該文本截?cái)酁橹付〝?shù)量的 token。它可以計(jì)算輸入到其中的文本中的 token 數(shù)：

# Count tokens
echo -n "Count these tokens" | ttok
# Outputs: 3 (the newline is skipped thanks to echo -n)


# Truncation
curl 'https://simonwillison.net/' | strip-tags -m | ttok -t 6
# Outputs: Simon Willison’s Weblog


# View integer token IDs
echo"Show these tokens" | ttok --tokens
#?Outputs:?7968?1521?11460?198

? 使用 - m gpt2 或類似選項(xiàng)可選擇使用適用于不同模型的編碼。

5
token 生成過程

一旦你理解了 token，那么 GPT 工具生成文本的方式就會(huì)變得更加明了。特別有趣的是，觀察到 GPT-4 將其輸出流式化為獨(dú)立的 token（GPT-4 的速度略慢于 3.5 版本，可以更容易觀察到其生成過程）。以下是使用我的 llm CLI（?https://github.com/simonw/llm?）工具從 GPT-4 生成文本的結(jié)果，命令是 llm -s 'Five names for a pet pelican' -4：