語言模型文字處理基石:Tokenizer簡明概述
編者按:近年來,人工智慧技術飛速發展,尤其是大型語言模型的問世,讓 AI 寫作、聊天等能力有了質的飛躍。如何更好地理解和利用這些生成式 AI,成為許多開發者和使用者關心的問題。
今天,我們推出的這篇文章有助於讀者深入瞭解大語言模型的工作原理。作者指出,大語言模型的核心在於將文字轉化為數字表徵,這就需要介紹 tokenizer 的概念。透過 tokenizer ,文字被分詞並對映為 token id,這為模型理解文字提供了堅實的基礎。作者還比較了基於統計學的文字自動補全和大語言模型的不同之處,說明了上下文視窗大小的重要性。最後,作者建議讀者在使用 OpenAI 等平臺時觀察定價規則與 token 數量的關係,並思考為什麼是這種定價規則。
本文通俗易懂地介紹了 tokenizer 在語言模型中的關鍵作用,讓我們更好理解這類模型的工作方式,對使用生成式AI有很好的啟發作用。人工智慧技術的發展日新月異,理解其基礎原理尤為重要。我們將持續關注該領域新進展,為讀者呈現有價值的技術分析。
以下是譯文,enjoy!
作者 | SCORPIL
編譯 | 嶽揚
???歡迎小夥伴們加入 AI技術軟體及技術交流群 ,追蹤前沿熱點,共探技術難題~
最近,生成式人工智慧(Generative AI)領域的最新進展深刻改變了AI輔助應用(AI-assisted applications)中所採用的開發模式。就在五年前,將人工智慧整合到應用程式中,除了需要基礎技術外,很可能還需要一支電腦科學家團隊來設計神經網路架構、訓練和精心微調模型。總的來說,要做很多外行人難以理解的工作。但自從不到一年前 ChatGPT 釋出以來,語言模型已經變得足夠智慧,以至於人們只需透過禮貌地詢問,就能修改它們的行為(也不一定需要禮貌地詢問)。侷限性。其中大部分都或多或少地依賴於應用 LLM 來控制 LLM 的想法(在本系列的後續部分中,我們將更深入地探討這種情況)。這類工作感覺與傳統的軟體工程非常不同,有部分原因是它的 empirical nature (譯者注:empirical nature應當意思為此類工作方式或方法是基於實際經驗和實證資料的,而不是完全基於理論或假設。),部分原因是因為這個領域還十分年輕。
如今,使用人工智慧並不一定要求對神經網路、機器學習和自然語言處理等領域有深入的瞭解,就像從事Web開發並不需要掌握編譯器和組合語言一樣。不過,在這兩種情況下,對於技術底層運作的瞭解對我們大有裨益,並且往往是優秀工程師與卓越工程師之間的區別。
目錄
01 人工智慧模型的本質是一種應用程式
02 文字自動補全系統設計
03 關於單詞的定義和處理方式
01 人工智慧模型的本質是一種應用程式
很多軟體工程師第一次接觸生成式人工智慧時可能會感到困惑。多年的專業經驗使他們對機器的能力有著一定的預期,並且可能會讓他們懷疑其中是否存在一些虛假的表象。不管這種情況是好是壞,事實並非如此:每個人工智慧模型只不過是一個應用程式(或者,如果你更願意嚴格定義的話,是一個應用程式的核心部分)。 模型的訓練方式與大多數應用程式從零開始設計的方式不同,但它們仍然只是具有輸入和輸出的一種應用程式。
該應用程式的設計目標是,在輸入一段文字後,以一種類似於人類編寫的方式擴充套件輸入的文字。這就是目前所有的 LLM 所做的。大模型是否能夠“理解”輸入的內容,這是一個備受爭議的哲學話題。然而,大多數專家都同意,目前的 LLM 在建立文字時,並沒有像人類那樣真正理解輸入文字。當然,沒有人真正知道“像人類那樣理解事物”是什麼意思。誰知道呢,也許我們也只是一種非常先進的資料理解機器呢?
不過,我們還是不要被哲學問題所束縛。那麼,我們要如何設計(哪怕只是在理論上)這種文字補全應用程式呢?
02 文字自動補全系統設計
文字自動補全系統(Autocomplete systems)已經存在幾十年了,但直到手機流行起來後,才出現了對其最有用的應用。在手機上打字確實並不是很方便,因此能夠猜測使用者意圖並給出輸入建議這種能力就成了備受追捧的功能。
如果輸入“New York”,文字自動補全系統很可能會預測下一個詞是“City”。建立這種系統的一種相對直接的方法是使用簡單的統計方法:在一個大型文字資料集中,記錄下“New York”出現的所有文字樣例(以及其他所有詞對的樣例),並記錄在這些詞對(如“New York”)後面出現的是什麼單詞,以此來學習文字的模式。
在設計這樣的系統時,一個明顯的需要權衡的因素是上下文的大小,即文字自動補全系統可以在輸入中一起評估的單詞數量:
-
接受更長的輸入可能助於提升預測的準確度。
-
然而,輸入量越大,統計資料儲存所需的記憶體就會呈指數級增長。由於任何特定語言中可能出現的單片語合數量都是天文數字,因此即使使用最強大的硬體,收集和使用連續幾個以上單詞的精確頻率資料也極其困難。
一個只有很小上下文視窗的文字自動補全系統,很快就會忘了他們剛剛在說什麼。儘管有明顯的侷限性,但這樣的系統與成熟的 LLM 相比還是有優勢的:執行起來更輕便,而且可以說更適合文字資訊輔助(text message assistance)。現代智慧手機上的“預測文字”和“自動更正”功能更接近文字自動補全(autocomplete),而不是LLM(至少在撰寫本文時是如此。它們可能很快就會被成熟的生成式人工智慧所取代)。你可以親自體驗一下——在移動裝置上進入本文的評論區,輸入幾個詞(如果你想不出來,可以用“In future AI will(未來人工智慧將會)”),然後不斷選擇裝置給出的第一個輸入建議。我以“The movie was(這部電影是)”開始,最後得到了下面這句話:
這部電影是一部好電影,但我認為它不足以成為一部好電影,因為它是一部好電影
The movie was a good one, but I don’t think it was good enough for the movie to be a good one because it was a good one
這個句子中的每一個詞都是由前一個詞自然銜接起來的。如果僅從這段文字中抓取一小段,單獨讀起來還可以:“這部電影是一部好電影”、“但我認為它不足以成為一部好電影”、“因為它是一部好電影”。 然而,整段文字卻是毫無意義的。 沒有任何意義的線索將它們聯絡在一起。
為了便於比較,以下是由 GPT-3 根據 “The movie was” 補全的文字。
這部電影於2015年11月18日在美國上映。由布拉德·伯德執導,喬治·克魯尼、休·勞瑞和布里特·羅伯遜主演。該片由迪士尼出品,票房大獲成功,全球總票房超過 2.09 億美元。
The movie was released in the United States on November 18, 2015. It was directed by Brad Bird, and stars George Clooney, Hugh Laurie, and Britt Robertson. It was produced by Disney and was a box office success, grossing over $209 million worldwide.
從這個簡單的線索開始,GPT-3似乎就離題了,開始談論了一部名為《明日世界(Tomorrowland)》的電影。令人印象深刻,但坦率地說,這可能不是我們希望從手機的文字自動補全功能中希望得到的結果。
這個例子表明, LLM可以根據更多的資訊和語境來進行預測和生成文字,而不僅僅是依靠少數詞語。 畢竟,要在第二句中正確說出“Disney”,必須考慮前面的整句文字。
但回到文字自動補全功能。為了讓這種簡單的統計方法發揮作用,我們必須首先獲取統計資料。為此,我們可以編寫一個程式,計算使用者輸入中提供的片語頻率,並將統計資料儲存在某個資料庫中,以便以後在文字自動補全應用程式中使用。最終,輸入的文字資料越多,文字自動補全程式的輸出就應該變得更準確。
這種兩階段的方法反映了人工智慧(以及機器學習一般)的工作方式。(譯者注:此處的兩階段指的應當是首先需要收集並處理資料(訓練模型),然後才能應用這些資料來進行預測或生成結果(執行模型))在這個類比中,這些統計資料是模型,計算這些資料是訓練,文字自動補全是執行模型。開發者沒有直接編寫程式碼來定義應用程式的行為,而是建立了一個類似大型語言模型的中間過程,透過這個過程來指定應用程式的行為方式。
03 關於單詞的定義和處理方式
我們理論上的文字自動補全程式(autocomplete program)隱含地 將單詞作為語言的原子部分進行操作。這是一個顯而易見的選擇,但並非最 佳選擇,原因有以下幾點:
-
單詞並非如其表面看起來那樣被清晰地定義;“I’m”算一個詞還是兩個詞?像“um”這樣的插入語算不算一個詞?像GPT這樣的首字母縮略詞算不算單詞?這是一個單詞嗎:“?”?“bbbbbbbb”呢?
-
“Apple”和“apples”是同一個單詞的兩種形式還是兩個不同的單詞?
-
如果只關注單詞,我們就會忽略標點符號提供的有價值的線索。例如,“Cats like eating…”可能會有“fish”作為有效的補全內容,而“Cats like eating, …”(注意逗號)更可能會補全“sleeping, and playing”之類的內容。
為了解決這些挑戰,LLM的輸入被分割成“token”而不是單詞。 在LLM中,token本質上是“在文字中的常見字元序列”,不受嚴格規則或語言語義的約束。相反,統計分析過程會根據輸入文字確定什麼是token,什麼不是token。因此,這種方法允許對任何語言(不受其語法的限制)自動分詞(automatic tokenization)。此外,token可以包括任何符號,而不僅僅是字母。分詞器會將文字中的每個字元都分配給一個token,包括標點符號、數字、空白字元,甚至是表情符號。
需要注意的是,上述方法是對 LLM 的輸入進行分詞的最常見方式,但並非唯 一的方式。“分詞(tokenization)”這個術語可能在其他語境下指代自然語言處理中使用的其他更高 級程式。
LLM 分詞器需要保持一種微妙的平衡:
-
過於激進地將文字分割成 token 會使平均 token 長度變短,增加給定文字的上下文大小,並使 LLM 的執行成本更高。
-
另一方面,如果分詞過程過於保守,token過長,可能會限制模型捕捉長程依賴關係(long-range dependencies)的能力,導致文字中細微訊號的丟失,並可能導致計算複雜性增加。
找到合適的一個平衡點對於確保分詞器有效地表示文字,並保持計算效率至關重要。 GPT使用的是一種自定義分詞器,你可以嘗試理解它的工作方式[1]。請注意,該分詞器將前導空格作為下一個單詞token的一部分:”GPT“由兩個token組成,與單詞“tokenizer”相同。
由於分詞器定義了一個龐大但也有限的 token 集合,因此可以對其進行列舉,並使用它們的索引作為數字型別的文字表徵(digital text representation)。這種格式就是目前 LLM(大語言模型)所使用的。token 文字,即使是以二進位制形式,長度也是可變的,這使得處理起來很困難,但token ID 只是數字。從 LLM 的角度來看,不存在所謂“文字字元(text character)”這樣的東西。有趣的是,一些研究表明,人類感知文字的方式與此類似[2],更多地是根據單詞塊而不是單個符號。
至此,我相信您已經對建立 LLM 中訓練步驟的重要性,上下文視窗大小的重要性,以及分詞如何在將文字轉換為與神經網路相容的格式時發揮關鍵作用有了紮實的瞭解。是時候將我們新學習的知識應用到現實世界中了。我鼓勵大家在瀏覽 OpenAI 的 LLM 定價頁面[3]時牢記這些關鍵要點:
-
模型使用成本,包括與訓練、輸入和輸出相關的費用 ,是按每 1000 個token 計算的 。 透過 LLM 的 token 數量直接影響了執行它所產生的成本。
-
上下文視窗大小對於 LLM 來說是一個關鍵引數。較大的視窗可以提高效能,但也會增加成本。
透過理解使用基於 token 的定價規則的目的,我們可以在實際場景中更明智地使用 LLM。
END
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70018536/viewspace-2997909/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 自然語言處理(NLP)概述自然語言處理
- 文字相似度 HanPL漢語言處理
- 自然語言處理中的語言模型預訓練方法自然語言處理模型
- Gson簡明處理
- 探索自然語言處理:語言模型的發展與應用自然語言處理模型
- CCAI 2020 | 周明:自然語言處理大有可為AI自然語言處理
- 人工智慧--自然語言處理簡介人工智慧自然語言處理
- 牛津大學xDeepMind自然語言處理 第13講 語言模型(3)自然語言處理模型
- Hanlp自然語言處理中的詞典格式說明HanLP自然語言處理
- 自然語言處理(NLP)簡介 | NLP課程自然語言處理
- 8 語言模型簡介模型
- 牛津大學xDeepMind自然語言處理 第9講(下)語音模型自然語言處理模型
- 使用 Python+spaCy 進行簡易自然語言處理Python自然語言處理
- 自然語言處理NLP(四)自然語言處理
- HanLP 自然語言處理 for nodejsHanLP自然語言處理NodeJS
- Go 語言異常處理Go
- NLP 與 NLU:從語言理解到語言處理
- Java語言概述Java
- 華為雲 API 自然語言處理的魅力—AI 情感分析、文字分析API自然語言處理AI
- 批處理概述
- 05.序列模型 W2.自然語言處理與詞嵌入模型自然語言處理
- 精通Python自然語言處理 2 :統計語言建模Python自然語言處理
- 自然語言處理(NLP)系列(一)——自然語言理解(NLU)自然語言處理
- [譯] 自然語言處理真是有趣!自然語言處理
- 用c語言處理檔案C語言
- Go 語言處理 yaml 檔案GoYAML
- 自然語言處理:分詞方法自然語言處理分詞
- 用於訓練自然語言處理 (NLP) 和文字模型的 7 個頂級開源資料集 - KDnuggets自然語言處理模型
- 大語言模型訓練資料常見的4種處理方法模型
- Pytext 簡介——Facebook 基於 PyTorch 的自然語言處理 (NLP) 框架PyTorch自然語言處理框架
- JSP 日期處理概述JS
- 中國語文(自然語言處理)作業自然語言處理
- 自然語言處理NLP快速入門自然語言處理
- 配置Hanlp自然語言處理進階HanLP自然語言處理
- 自然語言處理的最佳實踐自然語言處理
- Go 語言操作 MySQL 之 預處理GoMySql
- 自然語言處理之jieba分詞自然語言處理Jieba分詞
- 人工智慧 (06) 自然語言處理人工智慧自然語言處理