大語言模型（LLM）透過預測下一個最可能的 token 來生成文字，這個過程稱為自迴歸。模型的運作與 token 密切相關，token 數量影響模型的執行時間、計算成本和上下文視窗大小。不同的文字型別，token 的效率也各不相同，英文自然語言文字的效率最高，而隨機字串或特殊符號的效率則較低。理解 token 的概念對於提示工程至關重要，可以有效控制模型的資源消耗。Transformer 架構是 LLM 的核心，其中的注意力機制允許模型的不同部分互相參考資訊，進而更準確地理解和生成文字。然而，資訊流動的單向性限制也影響了模型的推理能力，使其在某些特定任務上表現不佳。為了提升 LLM 的安全性與對話能力，強化學習與人類反饋（RLHF）扮演著關鍵角色，透過 RLHF 的訓練，基礎模型可以進化成更符合人類期望的對話式 AI。
瞭解大語言模型的運作機制
大語言模型（LLMs）在處理文字時，面臨著諸如大小寫轉換等細節問題。雖然更好的LLMs能夠更有效地處理這些問題，但這仍然是它們需要執行的額外工作，並非直接針對主要問題。明智的提示工程師會試圖避免過度負擔模型，例如頻繁進行大小寫轉換。
計算Token數量
在使用LLMs時，瞭解其分詞器（tokenizer）至關重要。每個模型都使用固定的分詞器，因此瞭解模型的分詞器是非常重要的。在進行提示工程時，您可能會使用Hugging Face或tiktoken等函式庫來執行分詞器。
分詞器的最常見應用是計算token數量，因為token數量決定了文字的長度。模型的執行時間和計算成本都與token數量成正比。因此，大多數模型即服務的供應商都是根據產生的或處理的token數量收費。
為何需要計算Token數量
- 執行時間：模型讀取提示和生成解決方案的時間都與token數量成正比。
- 計算成本：模型的計算成本與輸出的長度成正比。
- 上下文視窗：LLMs的上下文視窗大小限制了它可以處理的文字量。上下文視窗大小通常以千個token為單位。
分詞器的效率
不同文字和分詞器的token數量轉換效率不同。常見的GPT分詞器在處理英文自然語言文字時，平均每個token約有四個字元。然而，對於其他語言或隨機字串，分詞器的效率會降低。
不同文字型別的Token效率
- 英文自然語言文字：約4個字元/token
- 其他語言：效率降低，字元/token比例降低
- 隨機數字字串：約2個字元/token
- 密碼學金鑰等隨機字母數字字串：少於2個字元/token
- 包含罕見字元的字串（如Unicode表情符號）：字元/token比例最低
LLM的運作機制：一次一個Token
LLM並非直接將文字轉換為文字，而是透過多次預測單個token來生成文字。這種過程稱為自迴歸（autoregressive）。
自迴歸模型的運作方式
- 模型預測下一個最可能的token。
- 將預測的token附加到提示中。
- 重複步驟1和2，直到生成完整的文字。
這種機制使得LLM在生成文字時無法停下來思考或回溯。一旦輸出了一個token，模型就無法撤回。因此，應用程式設計師需要在必要時提供錯誤識別和回溯功能。
內容解密：
此程式碼範例展示瞭如何使用tiktoken函式庫來計算給定文字的token數量。首先，我們初始化了一個名為cl100k_base的分詞器。然後，使用encode方法對輸入文字進行分詞，最後傳回token的數量。這個例子可以幫助開發者瞭解如何在實際應用中計算和管理token數量。
自迴歸系統中的模式與重複問題
自迴歸系統的一個常見問題是，它們可能會陷入自身的模式中。大語言模型（LLMs）擅長識別模式，因此有時會（偶然地）建立一個模式，卻找不到一個好的地方來結束它。畢竟，給定這個模式，在任何給定的標記（token）下，它繼續的可能性大於中斷的可能性。這導致了非常重複的解決方案。
重複模式的例子
在圖2-10中，一個LLM生成了一份喜歡某部電視劇的理由列表。在這個列表中，可以發現多種模式：
- 專案是連續編號的陳述句，每個陳述句都適合在一行內呈現。
- 它們都以「The」開頭。
- 它們的形式是「X 是 Y 和 Z」。這種形式可能導致正確性問題，因為模型可能會在沒有合適的Z時發明一個。
- 在連續幾個專案以「The franchise」開頭後，後面的專案都遵循了這一模式。
- 向列表末尾，單詞如「legacy」、「following」、「future」、「foundation」和「fanbase」被重複使用。
這種重複的問題在於，模型在生成每個專案後，更傾向於繼續生成下一個專案，而不是停止。
處理重複解決方案的方法
處理這種重複解決方案的典型方法是簡單地檢測並過濾它們。另一種方法是對輸出進行一些隨機化處理。
溫度（Temperature）與機率
在前面的章節中，我們瞭解到LLM計算最可能的標記（token）。但如果進一步探索LLM的工作原理，會發現它實際上計算了所有可能標記的機率，然後再選擇一個單一的標記。這個過程稱為抽樣（sampling）。
抽樣過程
LLM不僅計算最可能的標記，還計算所有標記的可能性。許多模型會與你分享這些機率，通常以對數機率（logprobs）的形式傳回。對數機率越高，模型認為這個標記的可能性越大。對數機率永遠不大於0，因為對數機率為0意味著模型確定這是下一個標記。通常，最可能的標記的對數機率在-2到0之間。
使用溫度引數控制輸出的隨機性
你可以透過設定溫度（temperature）引數來控制輸出的隨機性。溫度是一個至少為0的數字，用於決定模型的「創造力」。當溫度大於0時，模型會給出一個隨機的完成結果，不僅選擇最可能的標記，也有可能傳回可能性較小但並非完全荒謬的標記。
溫度的選擇
- 0：你想要最可能的標記，沒有替代方案。這是當正確性至關重要時的推薦設定。
- 0.1–0.4：如果你希望有一個稍微不那麼可能的替代標記被選中。這通常用於生成少數不同的解決方案。
- 0.5–0.7：你希望增加輸出的隨機性，並且可以接受不準確的結果。這通常用於生成大量獨立的解決方案。
- 1：你希望輸出的標記分佈反映訓練集的統計分佈。
- > 1：你希望生成的文字比訓練集更隨機，這意味著模型不太可能選擇「標準」的延續。
import numpy as np
def softmax(logprobs, temperature):
# 計算每個標記的機率
probs = np.exp(logprobs / temperature)
# 對機率進行歸一化處理
probs = probs / np.sum(probs)
return probs
# 示例對數機率
logprobs = np.array([-1.2, -2.3, -0.5])
temperature = 0.7
# 計算 softmax 後的機率
probs = softmax(logprobs, temperature)
print(probs)
內容解密：
此程式碼範例展示瞭如何根據給定的對數機率和溫度計算 softmax 後的機率。首先，我們定義了一個名為 softmax 的函式，它接受對數機率和溫度作為輸入。然後，我們使用 numpy 的 exp 函式計算每個標記的機率，並將其除以溫度。接著，我們對這些機率進行歸一化處理，以確保它們的總和為1。最後，我們使用示例對數機率和溫度值呼叫此函式，並列印預出結果。這個過程模擬了LLM在不同溫度下選擇下一個標記的方式。
深入理解大語言模型（LLMs）的運作機制
溫度引數對LLMs輸出的影響
溫度引數是控制LLMs生成文字多樣性的關鍵因素。較高的溫度會使模型更傾向於選擇較不可能的詞彙，從而產生更多樣化的輸出，但同時也增加了錯誤率。這種現象類別似於人類在受到酒精影響時的言語模式，隨著溫度的升高，輸出的錯誤率會逐漸增加。
高溫度的影響
高溫度（大於1）會使LLMs的輸出變得更加隨機和不確定。這種情況下，模型更有可能選擇與訓練資料中典型檔案不同的詞彙或句子結構，導致輸出的多樣性增加，但正確性下降。隨著生成文字的長度增加，錯誤率通常會變得更糟，因為模型會根據之前生成的錯誤內容繼續產生新的錯誤。
取樣方法與溫度引數的權衡
不同的溫度引數對LLMs的輸出有著不同的影響。在溫度為0時，模型總是選擇它認為最可能的詞彙，這通常會導致輸出過於單一和確定。在溫度為1時，模型的輸出更接近於訓練資料的分佈，能夠在保持一定正確性的同時提供多樣化的輸出。
不同溫度機制的優缺點
| 溫度機制 | 優點 | 缺點 |
|---|---|---|
| 高溫度 | 提供更多樣化的輸出，與訓練資料的分佈更接近 | 正確率下降，錯誤率增加 |
| 低溫度 | 輸出更正確，更具確定性 | 多樣性下降，可能過於單一 |
Transformer架構：LLMs的基礎
Transformer架構是現代LLMs的核心。該架構由多個相同的「小腦」組成，每個小腦負責處理輸入序列中的一個詞彙。這些小腦透過多層的計算和資訊分享，共同完成對輸入文字的理解和生成任務。
Transformer的工作原理
每個小腦首先接收其對應的詞彙和位置資訊，然後透過固定層數的計算，不斷更新其對文字的理解。在這個過程中，小腦之間透過分享中間結果來協同工作，最終由最右側的小腦負責預測下一個詞彙。
自迴歸機制與新詞彙的生成
當最右側的小腦完成預測後，自迴歸機制會將新生成的詞彙加入輸入序列，並為其建立一個新的小腦。這個過程不斷重複，從而實作文字的連續生成。
Transformer架構的示例
考慮一個例子，當模型被要求補全「One, Two,」時，Transformer架構會為每個輸入詞彙（[One]、[,]、[Two]、[,]）建立一個小腦。這些小腦透過多層計算，不斷更新其狀態，最終由最右側的小腦預測出下一個詞彙（[Buck]），並繼續生成後續詞彙（[le]）。
內容解密：
本段落詳細闡述了Transformer架構的工作原理，包括小腦的概念、資訊分享機制以及自迴歸機制在文字生成中的作用。同時，也解釋了溫度引數如何影響LLMs的輸出，並分析了不同溫度機制的優缺點。這些內容對於深入理解LLMs的運作機制具有重要意義。
Transformer 架構深入解析
Transformer 架構是大語言模型（LLM）的核心創新，其最重要的組成部分之一就是「注意力機制」（attention mechanism）。這個機制允許模型中的各個「微型腦」（minibrain）之間進行資訊交換。以下將詳細解析這個過程及其運作原理。
注意力機制的運作方式
提出問題：每個微型腦根據其當前的輸入提出問題，試圖從其他微型腦取得有用的資訊。例如，當前微型腦位於標記 [my] 上，它可能會問：「誰正在說話？」
提供資訊：每個微型腦根據其當前的輸入提供資訊，供其他微型腦參考。例如，位於標記 [Susan] 上的微型腦可能會提供資訊：「當前說話的人是 Susan。」
匹配問題與答案：系統會將每個問題與最合適的答案進行匹配。在上述例子中，「誰正在說話？」這個問題與「當前說話的人是 Susan。」這個答案非常匹配。
回饋答案：最合適的答案會被回饋給提出問題的微型腦。因此，位於 [my] 上的微型腦會得知「當前說話的人是 Susan。」
在實際運作中，這些微型腦之間的溝通並不是使用自然語言，而是透過一串長向量數字來進行的。這種「語言」對於每個 LLM 來說都是獨特的，並且是在訓練過程中學習到的。
資訊流動的限制
在現代的 LLM 中，注意力機制受到一個稱為「遮罩」（masking）的約束：只有位於提問微型腦左側的微型腦才能回答問題。這意味著資訊只能從左到右流動，而不能反向。這種設計使得模型在訓練和執行時更加高效，但也對模型的資訊處理方式產生了重大影響。
平行計算與效率
由於資訊流動的方向性，模型的計算可以部分平行進行。每一層的狀態計算只依賴於左側（較早的微型腦）和下方（同一微型腦在前一層）的狀態。這種特性使得模型的計算形成一個三角形結構，如圖 2-15 所示。這種結構使得模型在處理長提示（prompt）時比生成長文字（completion）時更快，因為生成文字需要等待前一個 token 被完全處理後才能開始。
「向後且向下」的視野
LLM 的資訊處理具有「向後且向下」（或稱「向後且笨拙地」）的特性：
- 向後：微型腦只能檢視左側的資訊，不能預覽右側的內容。這使得 LLM 被稱為單向（unidirectional）Transformer。
- 向下：每一層的微型腦只能從同一層左側的微型腦取得資訊。這限制了模型的推理深度。
這種設計使得 LLM 在訓練和執行時更加高效，但也限制了模型的資訊處理能力。不過，透過「出聲思考」（即生成文字並根據生成的文字進行進一步處理），模型可以實作某種程度上的多步推理。
內容解密：
上述段落詳細解釋了 Transformer 架構中的注意力機制及其運作方式。重點包括：
- 微型腦之間的資訊交換是透過注意力機制實作的。
- 資訊只能從左到右流動，這使得模型具有單向性。
- 這種設計使得模型在處理長提示時比生成長文字時更高效。
- LLM 的「向後且向下」的視野限制了其推理能力，但透過「出聲思考」可以部分彌補這一限制。
實際範例與挑戰
讓我們考慮一個例子：計算上一段落包含多少個單詞。大多數人不會實際去數，而是期待作者直接提供答案。事實上，這段落包含 173 個單詞。如果我們詢問 ChatGPT 這個問題，它可能會給出錯誤的答案，例如 348 個單詞，不僅錯誤，而且相差甚遠。
內容解密：
這個例子說明瞭 LLM 在某些任務上的侷限性。ChatGPT 的錯誤回答顯示了其在精確計數或處理某些特定任務時的不足。這種情況凸顯了 LLM 在實際應用中的挑戰和侷限性。
從基礎模型到對話式AI：強化學習與人類反饋的重要性
在前一章中，我們探討了生成式預訓練變壓器（Generative Pre-trained Transformer）架構的基本原理。這些模型的訓練方式對其行為產生了深遠的影響。一個基礎模型，僅僅經過預訓練過程，即使用網際網路上數十億份任意檔案進行訓練。當你給予基礎模型一份檔案的第一部分時，它會產生一個看似合理的後續內容。這種行為本身就相當有用，本文將展示如何「誘導」這樣的模型完成各種任務，而不僅僅是純粹的檔案補全。
然而，在應用場景中，基礎模型可能難以使用。首先，由於它是在網際網路上的任意檔案上進行訓練的，因此它同樣能夠模仿網際網路的正面和負面內容。如果提示它「這是西西里千層麵的配方：」，那麼它會生成一份美味的義大利菜譜。但是，如果提示它「以下是製造甲基苯丙胺的詳細步驟：」，那麼你很快就會得到足夠的資訊去開始一段危險的犯罪生涯。一般來說，我們需要模型是「安全的」，這樣使用者就不會因為涉及暴力、性或不雅內容的對話而感到驚訝。
為何需要強化學習與人類反饋（RLHF）
基礎模型的另一個挑戰是，它們只能完成檔案。我們通常希望LLM能夠扮演助手，執行Python程式碼，搜尋並將事實納入補全內容中，以及執行外部工具。如果你向基礎模型提出一個問題，它更有可能產生一系列類別似的問題，而不是像助手一樣回答問題（見表3-1）。
表3-1：無訓練時的提示與補全內容
提示：雞肉的好菜餚是什麼？ 補全內容： 牛肉的好菜餚是什麼？ 豬肉的好菜餚是什麼？ 羊肉的好菜餚是什麼？ 米飯的好菜餚是什麼？ 蔬菜的好菜餚是什麼？ …
但是，透過適當的訓練，模型可以被教導像助手一樣幫助使用者解決問題（見表3-2）。
表3-2：經過適當訓練後的提示與補全內容
提示：雞肉的好菜餚是什麼？ 補全內容： 雞肉的一個好選擇是雞肉檸檬雞排。這是一道經典的義大利-美國菜，既簡單又美味。以下是一個基本的食譜： …
更重要的是，我們需要的不僅僅是一個普通的助手——我們希望它在對話中禮貌、直接但不唐突、答案詳盡但不冗長、真實且不易產生幻覺。我們希望它能夠自定義——使其像海盜一樣說話的醫生——但很難被破解（即很難去除自定義）。最後，我們希望助手具有執行程式碼和外部API的能力。
RLHF的流程與重要性
RLHF是一種利用人類偏好來修改LLM行為的訓練技術。在本文中，你將瞭解如何從一個相當不穩定的基礎模型開始，透過RLHF的過程，最終得到一個能夠與使用者進行對話的、表現良好的LLM助手模型。幾家公司已經建立了自己的RLHF訓練的聊天模型：Google開發了Gemini，Anthropic開發了Claude，而OpenAI則開發了GPT模型。在本文中，我們將重點關注OpenAI的GPT模型，緊跟2022年3月的論文《透過人類反饋訓練語言模型遵循指令》。
