跳至主要內容
LLM 基礎

語言模型如何生成文字

從 token 到文字預測,理解流暢回答能說明什麼,以及仍需查證什麼。

作者
Huang Tzu LinFounder
發布日期
閱讀時間
約 13 分鐘
更新於
目錄
  1. 01本篇在學習路線中的位置
  2. 02先備知識
  3. 03學習成果
  4. 04完整範例:流暢卻缺乏依據的行程
  5. 05從訓練到生成
  6. 訓練與參數
  7. Token 與推論
  8. 簡單的機率範例
  9. 06助理的五個責任層
  10. 07為什麼流暢的輸出仍會出錯
  11. 08實作產物與實作練習
  12. 09刻意破壞案例
  13. 10完成標準
  14. 11知識檢核
  15. 12解答
  16. 13下一步
  17. 14參考資料與延伸閱讀

語言模型可以把簡短的需求寫成一份看似專業的旅遊規劃。這種組織文字的能力很實用,但語氣再篤定,也無法證明某條火車路線真的存在,或某間餐廳仍在營業。

本篇教學會先拆開「模型本身」與「外圍應用程式」的職責。我們先以虛構的赫爾辛基行程釐清這條界線,後續章節再套用到 OptiVerse Travel 旅行 Copilot。文中的行程只是教學測例,並非實測紀錄或即時旅遊建議。

互動實驗

觀察一句話如何形成

選取一個 token 後,下一步有何改變?

這間

下一個 token 的候選

飯店62%
火車25%
航班13%
前綴已經改變。

下一次分布以擴充後的前綴為條件。選到高機率的 token,不等於驗證了句子。

讀懂目前結果

已選取次數
0
下一次選擇依據
目前顯示的整段前綴

前進一步並比較候選字詞。手寫百分比用來示範條件分布,不是實測信心分數,也不表示解碼一定選最高分。

手寫 token 候選與分數,不是真實 tokenizer 或模型執行。

本篇如何銜接前後內容

本篇在學習路線中的位置

帶入前作:不需要先前產物,直接從下方的虛構旅遊問題開始即可。

本篇新增:五層行為分類表。請將假設、來源 ID 與失敗案例連同成果一併留存。

後續用途:00-2、00-3、00-4 與 I-00 將沿用這些成果。跨主題系列的先備順序請見完整閱讀路線。文章 ID 是固定標籤,編號不代表閱讀順序。

學習目標與實作準備

先備知識

無。本篇是「模型基礎」系列的起點。

學習成果

讀完本篇後,你將能追蹤文字從切分 token 到生成的流程、分辨參數更新與上下文內學習(in-context learning),並判斷一項系統行為屬於基礎模型、後訓練、請求上下文、檢索/工具,還是應用程式政策。

完整範例:流暢卻缺乏依據的行程

假設使用者輸入:

幫我規劃一趟赫爾辛基之旅。

我們刻意設計的錯誤示範回答包含三項主張:

搭定期 VR 客運列車直達波爾沃。六月下旬,在赫爾辛基欣賞整晚不落的太陽。十月造訪時,一定能看到極光。

逐一查核相關來源後,這三句話都站不住腳:

  • 波爾沃交通:Visit Porvoo 介紹了從赫爾辛基出發的密集巴士,另有夏季限定的博物館軌道車。有夏季博物館軌道車,不代表有定期 VR 客運服務;選定班次前,仍須查閱業者適用於出發日期的時刻表。Visit Porvoo

  • 夏季日照:赫爾辛基夏夜雖然明亮,太陽仍會落到地平線以下。「白夜」與北極圈內的「永晝(午夜太陽)」是兩回事。Visit Finland

  • 極光:芬蘭南岸看到極光的機率遠低於北部的拉普蘭。芬蘭氣象研究所在無雲暗夜的觀測指引中,指出南岸的長期平均約為每月一次;這是區域統計,不是特定行程的預報或保證。FMI

上述旅遊資料查核於 2026 年 9 月 10 日,並於 2026 年 11 月 2 日複核;實際班次與觀測條件仍須依出發日期確認。

這組測例能對照外部資料,證實三項主張有誤,卻看不出某個模型實際上如何產生這些錯誤:單憑最終文字,無法認定是哪筆訓練資料或哪個內部成因造成了這種措辭。

從訓練到生成

訓練與參數

神經網路是一種數值函數,其中可調整的數值稱為參數(parameters),包含權重(weights),以及許多架構中的偏差項(bias)。訓練就是根據資料更新參數,讓目標函數的表現更好。

自迴歸(autoregressive)語言模型的一項核心預訓練目標,是根據前文預測下一個 token。最佳化這項目標,能帶出事實記憶、語法結構與解題模式;但說出訓練目標是什麼,並不等於解釋了它帶來的每一種能力。GPT-3 是這類自迴歸模型有文獻記載的實例;本篇聚焦於這個模型家族,而非涵蓋所有語言生成架構。Brown 等人,2020

參數雖然能記住事實關聯,卻不是逐筆附上時間戳記與出處的資料庫。靠權重回憶出的答案不會自帶「目前仍有效」的證明;訓練資料截止日也只是標示資料收錄的上限,不保證模型完整或正確記住截止前的所有事實。

Token 與推論

分詞器(tokenizer)會將文字轉成一串整數 token ID。視 tokenizer 設計而定,一個 token 可能對應完整單字、子詞(subword)、標點、空白或位元組片段。英文單字數無法可靠推估繁體中文的 token 數,實務上請直接用目標模型的 tokenizer 計算,不要憑直覺猜測「Helsinki」這類字詞會切成幾個 token。

推論(inference)是拿訓練完成的模型處理新輸入;一般推論請求不會改動模型參數。即使權重沒有更新,模型仍能依提示詞中的範例或事實調整輸出,這稱為上下文內學習(in-context learning)。GPT-3 研究便在受測任務上展示了這種能力,過程中不做梯度更新。Brown 等人,2020

訓練改變的是數值函數本身,上下文改變的則是送進函數的輸入。產品外圍的程式碼可能另外儲存對話紀錄,或收集資料供日後訓練使用;單次推論呼叫本身不會做這兩件事。

簡單的機率範例

在簡化的自迴歸解碼流程中,模型會讀取目前的上下文,為詞表裡每個候選的下一個 token 算出分數,再由解碼規則挑出一個 token 接回上下文末端,如此反覆,直到觸發停止條件為止。

舉例來說,假設某一步的下一個 token 機率分布如下:

候選 token

假設機率

bus

0.50

train

0.30

ferry

0.20

三項機率合計為 1.00。貪婪解碼(greedy decoding)會直接挑機率最高的 bus;取樣解碼(sampling)則可能選中 train 或 ferry。這組數字只是教學示意,並非模型實測結果。即使 bus 的機率是 0.50,也只表示解碼分布在下一步偏向這個 token,不代表最後的旅遊建議有 50% 的機率正確。

整個概念流程可以寫成 text → token IDs → model scores → decoding choice → output tokens → text。正式環境的推論服務引擎會最佳化這些步驟的執行方式,但「挑出通順的 token」與「查證現實事實」始終是兩件不同的事。

助理的五個責任層

下方的五層架構是本文自訂的教學分類。真實系統可能合併其中幾層,同一個外顯行為也可能有好幾個成因。

層級

本篇定義的職責

範例

基礎模型

學習語言表徵並計算下一個 token 分數

接續寫出通順的旅遊段落

後訓練

透過額外訓練塑造模型行為

從示範與偏好資料學會遵循指令

請求上下文

為當次呼叫提供指令、範例與證據

在提示詞放入旅客的飲食偏好

檢索/工具

取得外部資訊或執行外部操作

查詢交通業者的時刻表

應用程式政策

在生成文字之外強制落實規則

授權未通過時直接攔截訂位

後訓練很重要:在 InstructGPT 研究中,就作者採用的提示詞分布而言,人類評分者偏好參數量小得多的後訓練模型,勝過基礎版 GPT-3。這是該次評估得出的證據,不代表每個後訓練模型在每項任務上都比較強。Ouyang 等人,2022

當工具查回最新時刻表,再由應用程式放進提示詞時,兩層便同時參與:檢索/工具負責向外部取得即時證據,請求上下文則讓模型不必更新任何權重就能讀到最新資訊。

為什麼流暢的輸出仍會出錯

工程上常把錯誤或無依據的生成內容統稱為幻覺(hallucination),但要真正修好系統,必須把失敗拆細:回答可能與現實不符、曲解已提供的證據、把正確事實拼成錯誤推論,或是在缺乏證據時裝作十拿九穩。

「預測下一個 token」不是事實查核機制,但預訓練目標也不是所有錯誤的唯一成因。訓練資料、後訓練的取捨、提問含糊、上下文缺漏、推理失誤與解碼設定都可能造成錯誤;前面的赫爾辛基測例只呈現了錯誤結果,無法單獨鎖定內部成因。

單靠放大模型規模也無法取代查證。TruthfulQA 基準測試發現,在專門設計來誘發常見迷思的題目上,受測的較大模型反而經常給出較不真實的回答。請把這項結果當成特定基準測試的警訊,提醒我們模型規模不等於事實可靠;它並未證明模型越大一定越差,也不代表今日模型的表現。Lin、Hilton 與 Evans,2022

這份行程混了兩種性質不同的查證需求:六月下旬赫爾辛基的太陽會不會下山,屬於相對穩定的地理知識;某班巴士或火車今天開不開,則取決於營運班表。兩者都需要證據支持,但只有後者非查當日即時班表不可。把所有錯誤都籠統說成「知識過時」,就會模糊這項工程上的區別。

實作產物與實作練習

請建立一張包含「項目」、「主要層級」、「理由」、「所需外部證據」四欄的工作表,依五層架構判斷下列十個項目分別由哪一層主責:

  1. 在預訓練階段更新參數,學習文字規律。

  2. 在推論階段計算下一個 token 的分數。

  3. 預訓練後,透過監督式示範學會遵循指令。

  4. 預訓練後,運用偏好回饋調整回答行為。

  5. 在當次請求中附上「我吃素」。

  6. 在當次請求中附上輸出格式範例。

  7. 向交通業者查詢標有日期的時刻表。

  8. 向訂位服務送出已授權的訂位請求。

  9. 因呼叫主體權限不足而拒絕訂位。

  10. 強制規定涉及當日班次的主張必須具備對應日期的交通證據。

示範列:第 7 項屬於「檢索/工具」,因為系統正在向外部來源取回資料;不過取回的結果仍須核對路線、出發日期與業者身分,才能拿來支持最終主張。

刻意破壞案例

假設應用程式把「夏季博物館軌道車」的介紹頁,當成「今天有定期客運列車」的證據。模型雖然逐字忠實引用了網頁內容,卻套錯了服務類型與適用日期。

請在工作表中分開記錄來源原文措辭與主張是否獲得支持。正確的修法是查明該班次與日期的實際營運狀態,或誠實回報尚未確認當日班次;光把回答語氣改得比較保守,並不會補上缺漏的證據。

完成標準

十個項目至少正確歸類 8 項,能清楚說明「下一個 token 機率」與「事實可靠度」的差異,並指出博物館軌道車網頁為何無法支持今天的定期客運班次。完成後請對照解答修正答錯的項目。

知識檢核

  1. 要讓模型根據提示詞裡的新事實調整回答,需要更新模型參數嗎?

  2. 行程內容出錯時,光看最終回答能斷定是哪份訓練文件害的嗎?

  3. 赫爾辛基範例中,哪些項目必須針對實際出發日期查證?

解答

工作表歸類:1–2 為基礎模型;3–4 為後訓練;5–6 為請求上下文;7–8 為檢索/工具;9–10 為應用程式政策。實際執行時可能有多層協作,但本練習聚焦於找出各項職責的主要歸屬。

知識檢核:(1) 不需要,參數固定時,只要改變輸入的上下文就能影響輸出;(2) 不能,單憑表面輸出無法確立訓練資料來源或內部成因;(3) 交通班次與極光觀測條件必須依出發日期查核,至於赫爾辛基夏夜是否日落則需查核可靠的地理資料,不必像查時刻表那樣做即時連線查詢。

下一步

下一篇將實作請求與上下文預算工作表,帶你看指令、範例與檢索證據如何放進有限的上下文視窗,並分辨「上下文缺漏」與「資訊有給卻沒被遵守」。

參考資料與延伸閱讀

閱讀順序

完整閱讀路線

章節 01 / 25

你在這裡4%
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08
  9. 09
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25

查看先備知識、分支路線與共用實作 →

分享這篇文章
XLinkedIn

Huang Tzu Lin

富宇資訊科技創辦人。撰寫 AI 系統設計、證據與工程取捨的文章。

透過 RSS 訂閱

使用慣用的 RSS 閱讀器追蹤最新的 AI 系統實作教學。

開啟 RSS Feed

支援任何 RSS 閱讀器,新文章將自動送達。

回到頂端