大型語言模型如何運作

您送出請求，大約一秒後，終端機裡的回答就開始冒出來。不是一次整段出現，而是真的一點一點打出來：一段接一段，好像有人正在即時敲鍵盤。有時在這之前，螢幕上會先停著 Thinking，這時回答會明顯晚一點到，但也更有條理。

這一切都來自同一個機制。下面就來拆解大型語言模型是怎麼運作的：它怎麼處理您的文字、用什麼衡量文字的長度、知識從哪裡來，以及它在思考的那幾秒裡發生了什麼。按下 Enter 並不需要知道其中任何一點。但把它們放在一起，您對回答的期待會明顯不同。

漫畫：一個人在漆籬笆，示範給機器人看該怎麼做，機器人卻照抄了筆刷的紋路，而不是把每一塊木板都漆好

這裡簡化了多少

這份材料是刻意簡化的。這樣讀起來快，也能回答您螢幕上到底發生了什麼。精確的拆解這裡沒有，也不可能有 - 光是一個 Transformer 區塊就得另寫一整篇。

語言模型估計的是接續

先從對象本身說起。大型語言模型，也就是 LLM（large language model），不是有視窗和按鈕的程式，也不是聊天工具。它是一個被呼叫的機制：把對話的文字交給它，它就回傳接下來的內容。Claude Code、網頁版聊天、編輯器裡的建議 - 這些全都是包在這種呼叫外面的外殼，而且每一種的外殼都不一樣。

而模型本身只會一件事：根據文字的開頭，估計哪種接續最有可能。不是找出正確答案，而是估計機率，而且不只針對一個選項，是針對它詞彙表裡的每一個選項。

用一句短短的話最容易體會。請您出聲接下去："我喝咖啡不加..." 最先冒出來的是"糖"，接著是"牛奶"，但"網路"就完全接不上，雖然文法上沒有問題。您在不到一秒內、想都沒想就做完了這個判斷。模型做的是同一件事，只是更形式化，也做得更徹底：它把整個詞彙表走一遍，替每個候選打一個分數。

每個選項都有自己的分數。沒有任何一個被標上"正確"

請注意圖上少了什麼。沒有任何選項被標為正確：只有比較可能和比較不可能的接續。這些數字也不是靠統計某個詞組在文本裡出現過幾次得來的 - 那是另一種簡單得多的技術，早在現在這些模型出現之前就被淘汰了。機率是根據模型在訓練期間內部固定下來的規律算出來的。所以就算是在您之前從來沒人寫過的句子，它也算得出來。

LLM 和聊天、代理有什麼不同

這三個詞常被當成同義詞，但它們描述的是系統裡不同的層。

LLM - 語言模型本身。接收上下文，生成下一則訊息。
聊天 - 包在 LLM 外面的介面和程式。它保存歷史紀錄、組出請求、送給模型，再把回答顯示出來。
代理 - 帶有目標、工作迴圈和工具的 LLM。它可以請應用程式讀取檔案、進行搜尋或執行測試，看過結果之後再決定下一步。

LLM 是核心；聊天和代理各自在模型外面加上自己的能力

簡單說：LLM 提出決定，聊天安排對話，代理把模型的決定和外部世界的動作接在一起。

是 token，不是單字

上面那張圖要補一句：詞在圖上是完整的，只是為了好懂。實際上，模型會把文字切成 token - 也就是它自己詞彙表裡的片段。一個 token 可能是整個單字、單字的一部分或一個標點符號，而空格通常會併進後面那個 token 裡，不算成獨立的單位。

詞彙表是事先在大量文本上建立的，而且是一步一步建立：演算法找出經常一起出現的字元序列，把它們黏成更大的片段。常出現的組合，就會拿到自己的 token。所以在建好的詞彙表裡，完整的單字和單字的碎片混在一起。

詞彙表裡每個 token 都有自己的編號，文字進到模型裡時已經是數字了：先把字串切成片段，再把每個片段換成它的編號。回答則是用同一份詞彙表，反過來還原成看得懂的文字。

灰色小方塊是空格：它不會消失，而是併進下一個 token 裡。切法只是示意，每個模型都有自己的詞彙表

由此有兩件事值得記在心裡。第一：每個模型家族的詞彙表都不一樣，同一個字串的切法也不盡相同，而像"一個 token 大約是四分之三個單字"這種估算，只是針對英文的粗略參考，僅此而已。第二：在訓練文本裡出現得比較少的語言，會被切得比較碎。中文的一個詞常常會被拆成兩三個 token，而對應的英文單字一個就夠了。

這種事親眼看一次，比讀描述直觀得多。打開 The Tokenizer Playground，貼上幾句您平常會下的請求，再貼上同樣內容的英文 - 馬上就能看到字串被切成了哪些片段、一共幾個。只有一點要說明：那裡的分詞器屬於某個特定模型，您實際在用的模型會有自己的切法。去那裡是為了看這個現象，不是為了拿到精確的數字。

這帶來一個意想不到的實際影響。模型看到的不是字母，而是片段，所以關於字母的問題，對它來說明顯比關於意思的問題難。請它數一個長單字裡有幾個字母"o"，答案很可能會錯。不是因為這題很難，而是因為這個字是切成兩個片段送進模型的，對模型來說，片段裡面並沒有一個個獨立的字母。

回答是怎麼由 token 組成的

現在把整個機制兜起來，它會比您想的更簡單。模型估計各個選項，從中選出一個，接到文字的最後面。然後一切重新開始 - 用的是同一段文字，只是多了一個 token。

回答不是現成拿來的：它一次長出一個 token，每個新的 token 都會影響下一個

完成的回答原本不存在於任何地方，也不是從哪裡取出來的 - 它裡面有多少個 token，就是經過多少步組出來的。結束也不是靠計時器：到了某個時候，最可能的接續剛好是一個代表"到此結束"的特殊 token，生成就停下來了。

從同一張圖還能看出另一個細節。模型沒辦法擦掉已經寫出來的東西：進到文字裡的 token 會一直留在那裡，成為之後每一步的條件。它要修正自己，方法就跟人在對話中一樣 - 靠下一句話。

而下面這個推論讓很多人意外：同一個問題問兩次，可能會得到兩個不同的回答。每一步選中的不一定是最可能的選項，而只要有一個 token 走岔，後面的一切都會跟著被帶走。多半只是措辭不同，但有時連提出的解法都不一樣。

終端機裡發生了什麼

回答在 Claude Code 視窗裡一點一點浮現，那不是載入動畫，而是生成的步驟本身：模型每選出一個 token 就交出去，程式立刻把它顯示到螢幕上。所以長回答才會逐漸出現，而不是停頓一陣之後一次整段跳出來。

為什麼模型被稱為"大型"

"大型"這個詞說的不是某個地方那個檔案有多大。它背後是兩種完全不同的規模，兩種都值得老老實實想像一下。

第一種是模型在訓練時讀過的文字量：書籍、文章、文件、論壇、程式碼，份量多到一個人讀好幾輩子都讀不完。第二種是參數的數量。參數就是模型裡的一個數字，是訓練過程中被一點一點調整的設定之一。這樣的數字有好幾十億個。開源模型會直接把這個數字寫進名字裡：7B、14B、70B，其中 B 是 billion，也就是十億。

接下來是很容易誤會的地方。參數數量不是品質排名。結果還取決於模型用什麼資料訓練、它的架構、它針對哪些任務調校過，以及為了塞進某個地方把它壓縮成什麼樣子。小一點的模型，在特定工作上完全可能勝過大一點的。名字裡的數字大，本身並不保證什麼。

還有一件事，在這樣的規模上好像是自然而然就出現了。要把一句關於測試失敗的話順順地接下去，光知道哪些詞通常擺在一起是不夠的。還得抓到測試本身是怎麼運作的。模型學的是猜詞，但順帶地，這些詞所描述的東西也固定到了它的參數裡。那種"它好像很懂"的感覺就是這麼來的，雖然機制一步都沒變。

模型的知識從哪裡來

來源剛好兩個，把它們搞混的代價很高。

第一個是參數。裡面固定著訓練時學到的規律。這不是每張卡片都註明出處的資料卡櫃：知識散布在大量數字裡，沒辦法從中取出一段精確的引文。所以模型有可能給出一個幾乎正確的東西：形式對、名字眼熟，偏偏某個具體細節是錯的。

第二個是此刻就放在對話裡的東西：您的請求、之前說過的一切、開啟的檔案內容、執行過的指令輸出。這個來源很精確，但壽命很短。它不會搬進參數裡，下一段對話對它一無所知。

其他所有想被當成獨立來源的東西 - 記憶檔案、找到的文件、外部服務的回應 - 走的都是同一條路：先進到對話裡，然後才會影響回答。模型沒有自己通往專案或網路的門。

第一個來源有個日期，這個日期也有名字 - knowledge cutoff。它是一個參考點，告訴您模型內建的知識大致更新到什麼時候。對於在這個日期之後才發布的函式庫，模型知道的就只有目前對話裡放進去的那些。

這裡的但書比日期本身更重要。cutoff 並不代表在這天之前模型什麼都知道、之後什麼都不知道。就算在這段期間之內也會有空白：有些主題的文字本來就少，有些地方彼此矛盾，還有些東西根本沒進到訓練資料裡。日期給的是上限，並不保證它之下的內容是完整的。

再補一個小但實用的點。直接問模型它的 cutoff 是什麼，不是什麼好主意：它會用生成來回答這個問題，也就是挑一個聽起來合理的答案。精確的日期寫在特定版本的文件裡，而且同一家族裡相鄰的模型，日期很可能不一樣。

Thinking 是什麼意思

螢幕上出現 Thinking 時，模型並沒有切換到什麼另一種意識模式。只是在開始回答之前，它被給了一段可以思考的空間。技術上這完全是同一種生成：模型先替自己寫一份草稿 - 拆解任務、盤算各種做法、跟自己辯論 - 然後才輸出最後的文字。要想多久，現在的模型在很大程度上會自己決定：簡單的問題草稿很短，甚至沒有；複雜的問題就長一些。

同一個請求，可以直接得到快速回答，也可以多拿一點時間來分析和檢查

為什麼需要這個，看個例子就懂。代理在找一個測試失敗的原因。第一個看似合理的解釋指向外部服務的用戶端，但旁邊的測試和錯誤訊息說的是另一回事：問題出在資料解析。有了多出來的空間，模型來得及發現這個矛盾，在提出修改之前就換了方向。這裡的好處不在推理有多長，而在於檢查改變了下一步。

第一個解釋本來就常常不是對的那個。它看起來合理，但"看起來合理"正是機制挑中它的標準。

接著來看，什麼時候多花力氣推理才划得來。它要花時間，沒必要每件小事都打開。

通常快速回答就夠了	值得給推理一些空間
解釋螢幕上那段程式碼在做什麼	找出測試失敗的原因，而且牽涉好幾個檔案
修正錯字或格式	比較兩種解法，連同它們的限制一起比
重述您剛剛給的文字	規劃一次步驟彼此相依的改寫

判斷方式很簡單：任務裡的岔路和相依關係越多，讓模型好好展開就越有用。只是重新命名一個變數的話，您直接看結果，會比讀它的推理還快。

還有一條要老實說的界線。顯示出來的推理，並不是內部過程的精確紀錄；很多時候那是為了讀者整理出來的轉述。一條又長又工整的推理鏈，完全可能建立在錯誤的前提上，而且正因為工整，看起來比實際更可靠。反過來的情況也有：答案已經找到了，模型卻還在懷疑、繞圈子，把自己搞糊塗。這種情況甚至有名字 - overthinking。

比"好好想一想"更有效的做法

要求它想久一點，是個使不上力的槓桿：草稿的長度本身不會讓任何東西變好。清楚的目標、講明的限制，以及一個看得出任務已經完成的明確標準，效果要強得多。這樣模型才有東西可以拿來檢查自己的推理。