LLM 取樣參數到底怎麼調：temperature、top-p、top-k

大多數 API 控制台裡都擺著這三個參數，預設寫著 0.7，很多人用了半年也沒動過。但它們決定一件具體的事：模型一次生成一個 token 時，從候選詞池裡按什麼規則挑詞。這一步直接影響輸出穩定性，甚至影響一批任務的真實成本。這篇把三個參數拆開講，再說清哪些場景該動哪個。

三個參數各自改的是什麼

模型吐字是一個 token 一個 token 進行的。每出一個 token，模型先對詞表（幾萬條）算一遍機率，再按規則把候選池收窄到一小撮，最後按機率抽籤。

- **temperature（溫度）**：在算機率之前把 logits 除以 T。T 越小，高機率的詞越突出；T 趨近 0 就退化成貪婪解碼，永遠只挑最高的那個，輸出完全確定。T 越大，分佈越平，低機率詞的機會越多。

- **top-k**：按機率只保留前 k 個候選，其餘直接丟掉。

- **top-p（核心取樣）**：按機率排序後，取累計機率剛好夠到 p 的最小那一段，其餘丟掉。和 top-k 的區別在於候選池大小隨上下文浮動——模型很自信時，池子自動變小。

三個場景的具體手感

**抽取 JSON、分類標記**：用 temperature 0 或 0.1，top-p 可以壓到 0.1–0.5。這類任務要的是同一份輸入永遠產出同一組欄位，任何詞的穩定度波動都可能讓你多一個逗號、少一個欄位，而壞掉的那幾個只能靠重試兜底，成本翻倍。

**創意文案、腦力激盪初稿**：temperature 0.9–1.2，top-p 0.9–0.95。這類場景的價值恰恰在偶發的意外選詞，重複呼叫要拿到不同的稿子，太穩定反而是在浪費平行處理成本。

**程式碼生成、長文寫作**：temperature 0.2–0.4 是常用平衡點。主體要穩，但保留一點詞面波動，避免同一份程式碼連跑六次六次一模一樣。

兩個工程細節容易踩坑。第一，別把三個參數同時擰到極限。top-k 和 top-p 同時設小，候選池被裁兩次，行為很難推斷。常見做法是 temperature 和 top-p 一起管，top-k 保持預設不動。第二，"不穩定"要先查提示詞再查取樣。答疑答得"虛"，多半是系統提示寫得含糊、few-shot 例子太少，或者一次任務的粒度太大。取樣參數只改變"在模型能力範圍內挑哪個詞"，不擴展能力本身——一個答不好的模型，把溫度調高只是讓它用不同的方式錯了。

生產環境裡怎麼快速試

把兩件事固定下來：輸出格式約束（JSON Schema 或 few-shot 範例）和一份固定的評測樣本（20–30 條代表輸入）。然後一次只動一個參數，用同一批樣本打分，看兩個指標：結構錯誤率（JSON 能否解析、欄位是否齊全）和同輸入多次輸出的一致率。如果 temperature 已經壓到 0.1 結構錯誤率還不降，問題基本不在取樣環節，回去改提示詞或拆任務粒度。

再加一個經常被忽略的參數：**seed**。很多推理服務支援指定隨機種子。temperature 不為 0 時，每次抽到的詞不一樣；seed 固定後，同樣的輸入、同樣的參數會抽到同樣的結果。它的正確用法不是"讓生產輸出固定"，而是做回歸比對：改提示詞前後各跑一遍同一批樣本（seed 相同），diff 一次就能看到改動到底把哪些輸出帶偏了，比憑感覺判斷可靠得多。注意不同服務對 seed 的實作不保證完全一致，換服務後比對結果不能直接沿用。

常用組合可以直接抄：

| 場景 | temperature | top-p | top-k |

|---|---|---|---|

| 抽取 / 分類 | 0–0.1 | 0.1–0.5 | 預設 |

| 執行時代碼生成 | 0.2–0.4 | 0.8–1 | 預設 |

| 創意初稿 | 0.9–1.2 | 0.9–0.95 | 預設 |

總結：三個參數看起來三件套，其實只做一件事——給選詞收窄候選池。要穩定的任務收窄到極限，要新意的任務留間隙。輸出不穩定時，先改提示詞和格式約束，再動取樣；順序反了，就是花幾天調 temperature 然後把答案率調得更看不清。