主題: 學習筆記
Temperature 與 Top P：模型如何選擇下一個 token？
Practical Prompt Engineering 第二篇筆記：用五個 token 的機率表理解 temperature 與 nucleus sampling，釐清 Top P 0.5、temperature 0／2，以及穩定與正確的差別。
接著 Prompt Engineering 的入門筆記，這一篇繼續整理 Frontend Masters《Practical Prompt Engineering》的 Temperature 與 Top P。兩個參數都會影響生成時的選擇，但調整的是不同部分：Temperature 改變機率分布的集中程度；Top P 用累積機率決定保留哪些候選 token。
課程問答讓我注意到幾個需要分開理解的地方：機率與候選數量、回覆穩定與內容正確，以及概念上的參數與實際 API 支援。本篇用一組自訂機率示範，數字經過計算核對，沒有呼叫模型比較生成品質。
Temperature 改變機率分布的集中程度
先假設模型正在選下一個 token，只有 A～E 五個候選。這些字母只是標籤；表格描述同一個生成步驟，不代表五種完整回答。
下表的基準是 temperature = 1，暫時不套用 Top P 或其他篩選：
| 候選 token | T = 0.5 | T = 1 | T = 2 |
|---|---|---|---|
| A | 58.18% | 40.00% | 29.84% |
| B | 22.73% | 25.00% | 23.59% |
| C | 14.55% | 20.00% | 21.10% |
| D | 3.64% | 10.00% | 14.92% |
| E | 0.91% | 5.00% | 10.55% |
標準的 temperature scaling 會先把模型的 logits 除以 T，再經過 softmax 轉成機率。若已知 T = 1 時的機率 p_i，同一個轉換也能寫成：
q_i = p_i^(1/T) / sum_j p_j^(1/T), T > 0T 降低時，較高機率的候選更占優勢；T 提高時，機率差距縮小。在這個例子裡，A 仍然排名第一，但被抽中的機率改變了。單純的正溫度縮放會保留排序，不會把 E 直接變成第一名。TemperatureLogitsWarper 說明
表格為四捨五入後的百分比，各欄相加可能略有誤差。模型選出一個 token 後，前文就改變了，下一步會重新計算分布，不能把這張表當成整段回答都固定使用的選項。
Temperature 0 與 2，分別能說明什麼？
課程把 0 作為選擇最高機率 token 的例子。前面的公式只適用於 T 大於 0；API 若支援 temperature = 0，通常會另外處理成選取最高機率 token 的行為。使用 Transformers 時，也可以明確選擇 greedy decoding，而不是直接把 0 代進縮放公式。生成設定
這有助於降低抽樣變化，卻不能直接保證服務每次都回傳逐字相同的結果。Google 的生成參數文件仍保留 temperature 0 可能出現變動的說明。要驗證重現性，還需要保存模型版本、完整輸入、設定與實際結果。
至於 temperature = 2，可以從表格看到分布變平，但五個 token 並沒有各占 20%。因此，「2 就是完全隨機、一定變成亂碼」不能當成通用結論。提高溫度可能降低連貫性，實際程度則和模型、輸入與其他採樣設定有關。
另外，2 並非所有 API 的共同上限。接上服務前，必須先確認所選模型允許的範圍，以及是否支援調整。
Top P 看累積機率，不是候選數量的百分比
Top P 也叫 nucleus sampling。它把候選依機率由高到低排序，保留累積機率達到門檻的最小前綴集合，再從保留集合中抽樣。GenerationConfig 的定義與提出 nucleus sampling 的論文，都以機率質量描述這個篩選方式。
仍使用 T = 1 的五個候選，累積機率如下：
| 候選 token | 原始機率 | 累積機率 |
|---|---|---|
| A | 40% | 40% |
| B | 25% | 65% |
| C | 20% | 85% |
| D | 10% | 95% |
| E | 5% | 100% |
設定 top_p = 0.5 時，A 的 40% 還不夠；加上 B 後達到 65%，因此保留 A、B。這裡留下五個候選中的兩個，並不是「保留排名前 50% 的候選」。門檻也不要求剛好加到 50%，跨過門檻的 B 仍會保留。
接著要重新正規化：A 被抽中的機率是 40 / 65 ≈ 61.54%，B 是 25 / 65 ≈ 38.46%。保留兩個候選，也不表示兩者各占一半。
同一份分布還能得到：
top_p = 0.9：保留 A、B、C、D，累積機率為 95%。top_p = 1：Top P 本身不截掉候選；其他設定仍可能限制它們。
每一步的分布會變，保留的候選數量也可能跟著變。這就是 Top P 與固定保留幾個候選的 Top K 不同的地方。
兩個參數如何分工？
| 參數 | 改變什麼？ | 在本文例子中的效果 |
|---|---|---|
| Temperature | 機率的相對集中程度 | T 從 1 降到 0.5，A 從 40% 提高到約 58.18% |
| Top P | 累積機率門檻內的候選集合 | T = 1、Top P = 0.5，保留 A、B，再重新分配機率 |
若實作先做 temperature scaling，再做 Top P，前者改變分布後，也可能改變後者保留的候選集合。所以，同時改兩個參數時，很難只從最後一段文字判斷是哪個改動造成差異。本文的兩張表刻意分開計算，沒有把 T = 0.5 那欄再套進 Top P 範例。
實際執行順序、其他篩選器與限制，要以使用的 SDK 和模型文件為準。比較設定時，先固定一個參數，比較容易解釋結果。
依任務選擇要觀察的結果
課程用低溫對應事實問答、程式生成與資料擷取，高溫對應創作與腦力激盪。我會把它當成理解取捨的起點，再依任務與模型測試：
| 任務 | 希望觀察的特性 | 還需要檢查什麼？ |
|---|---|---|
| 從文件擷取欄位 | 輸出格式與內容較一致 | 是否忠於原文、缺少資料時如何處理 |
| 生成程式碼 | 減少不必要的寫法變化 | 編譯、測試與執行結果 |
| 回答事實問題 | 回答聚焦且可對照來源 | 主張是否受到可靠來源支持 |
| 發想標題或情節 | 取得不同方向的候選 | 是否切題、差異是否有用 |
較低溫仍然可能穩定地產生錯誤；較高溫也不保證創意有價值。「創作就設 1.3」無法代替對實際任務的評估。
而且，課程的參數操作不能直接套到所有新模型。查閱時的 Claude Messages 文件與 Google 生成參數文件，都已針對部分模型限制自訂採樣參數；設定可能被拒絕或忽略。先確認支援，再進行比較。
把概念變成一個可檢查的小實驗
我會先用一個自編的欄位擷取情境，讓「好不好」有明確依據：
請從以下錯誤回報擷取 browser、route、error，僅輸出 JSON。
沒有出現的欄位請填 null，不要自行補齊。
錯誤回報：
使用 Firefox 開啟 /settings，按下儲存後出現 TypeError: Failed to fetch。事先手寫的預期結果是：
{
"browser": "Firefox",
"route": "/settings",
"error": "TypeError: Failed to fetch"
}這是測試目標，並非模型實際回覆。實驗時先保存模型版本、完整提示、支援的參數與基準設定；每輪只調整 temperature 或 Top P 其中一項。每組先重複五次，記錄 JSON 是否能解析、三個欄位是否符合預期，以及有沒有加入原文不存在的資訊。
接著加入缺少 browser、缺少 error 的案例，檢查 null 的處理。五次結果只適合初步觀察；若要選擇正式應用的設定，還需要更多具代表性的案例。這個流程目前尚未執行模型測試。
這樣比較時，我能分別回答三件事：參數是否真的生效、輸出有多少變化，以及結果是否正確。單看某次回答很流暢，還不足以判斷採樣設定適不適合任務。
參考資料與查核範圍
- Sabrina Goldfarb，《Practical Prompt Engineering》投影片：第 5 頁的 Temperature 與 Top P。
- 課程配套網站，Temperature, Top P, Tokens, and Context Windows：本文只整理 Temperature 與 Top P。
- Hugging Face，TemperatureLogitsWarper、GenerationConfig：分布縮放、採樣與候選篩選。
- Holtzman 等人，The Curious Case of Neural Text Degeneration：nucleus sampling 的原始論文。
- Google，Content generation parameters：參數支援與重現性的限制。
- Anthropic，Create a Message：模型對 temperature 與 Top P 的支援限制。
資料於 2026-10-15 查閱。兩張機率表是自訂分布的計算示例；課程問答中的「前 50% 候選」「0 必定完全一致」「2 必定亂碼」已改用本文的精確說明。沒有模型品質 benchmark 或個人熟練度評量。