AI 的 Temperature 是什麼?調成 0 就真的不會亂回答嗎

⚡ 站長快讀:核心重點

• 文章屬性:科技冷知識 / 規格解析
• 核心結論:AI Temperature 取樣參數調的不是「模型有多聰明」,而是挑下一個字時要不要冒險;調成 0 只是叫模型每次都選機率最高的那個字,依 Anthropic 官方 API 文件明載,即使 temperature 設 0.0,結果仍不會完全確定。
• 適用對象:在 OpenAI / Anthropic API 或本地 LLM 介面看到 temperature、top-p 滑桿卻不知道該拉哪裡的人

📌 快速答案

一句話答案:AI Temperature 取樣參數是控制模型挑字隨機程度的縮放值,數值越低越保守、越高越發散;調成 0 會讓它固定挑最高機率的字,但不等於答案正確,也不保證每次輸出一模一樣。

🔍 故事的起點

很多人第一次碰 AI Temperature 取樣參數,是在 API 文件或本地 LLM 工具的側邊欄看到一條從 0 拉到 2 的滑桿,旁邊寫著「越高越有創意」。於是網路上出現了一種很直覺的推論:那把它拉到 0,AI 就不會亂講話了吧?

這個推論錯得很有代表性,因為它把兩件事混為一談——「隨機」跟「錯誤」。模型每產生一個字之前,會先算出一整排候選字的機率分布;temperature 動的是這排機率該被拉平還是拉尖,它從頭到尾沒有碰過「哪個答案是對的」這件事。所以把 temperature 調到 0,你得到的是一個「很穩定地說同一句話」的模型,如果它本來就把錯的答案排在第一名,那你只是讓它很堅定地錯而已。

更違反直覺的是第二層:就算你真的把 temperature 設成 0,你也不一定每次都拿到同一段文字。Anthropic 在 Messages API 官方文件裡把這件事寫得很白:「Note that even with temperature of 0.0, the results will not be fully deterministic.」(官方事實,2026-08-14 查證)這句話背後藏著一個跟 GPU 浮點數運算有關的故事,我們待會拆。

🧪 原理拆解

Temperature 在數學上到底改了什麼

模型輸出的原始分數叫 logits,是一排還沒正規化的數字。要把它變成機率,標準做法是丟進 softmax。而 temperature 的作用非常單純:在進 softmax 之前,先把每個 logit 除以 T。

• T 越小(接近 0):除完之後數字之間的差距被放大,機率分布變得又尖又陡,第一名幾乎吃掉所有機率 → 輸出保守、重複性高。
• T = 1:等於不做縮放,用模型原本的機率分布抽樣。
• T 越大:差距被壓縮,分布被拉平,原本排第八名的冷門字也開始有機會被抽中 → 輸出發散,也更容易離題。

OpenAI 官方對這個參數的敘述是「What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic.」(官方事實,取自 OpenAI 官方 Python SDK 依 OpenAPI spec 生成之參數定義,2026-08-14 查證)注意它用的字是 more deterministic(更趨確定),不是 correct——官方自己就沒有把 temperature 跟正確性綁在一起。

一個好用的生活化比喻:temperature 像餐廳點餐時的「照舊 vs 隨便」。調低=每次都點同一道招牌菜;調高=讓你在整本菜單裡隨機挑,連從沒人點過的菜也算進去。但不管你怎麼調,這家店會不會做菜、菜好不好吃,跟你怎麼點完全無關。

調成 0 = 貪婪解碼,但它治不了幻覺

temperature 趨近 0 時,抽樣實際上退化成貪婪解碼(greedy sampling):每一步都固定選機率最高的那個 token。Thinking Machines Lab 在其技術文章中也是這樣定義的——「the LLM always chooses the highest probability token, which is called greedy sampling」(第三方研究,2025-09-10 發表)。

問題就在這裡。機率最高 ≠ 事實正確。模型的機率分布反映的是「這串文字看起來多像訓練資料裡會出現的句子」,不是「這句話是不是真的」。當模型對某個不存在的函式名稱、某個查無此人的引用來源給出高機率時,把 temperature 壓到 0 只會讓它每一次都非常穩定地生成同一個錯誤,而且因為語氣一致、句子通順,反而更難被察覺。

所以正確的分工是這樣:temperature 管的是輸出的變異度,幻覺要靠別的機制處理——把事實搬進 context(檢索增強)、要求逐句附來源、或是人工查證。想知道幻覺的成因與自保做法,可以看站內這篇AI 幻覺為什麼發生?原理拆解+查證自保 5 招;想理解「先翻資料再回答」那條路線,則可參考 RAG 是什麼的拆解。

為什麼 temperature 0 還是不完全一致:批次不變性

這是本文最反直覺的一段。既然 temperature 0 等於「永遠選第一名」,那應該完全可重現才對,為什麼官方文件還要特別註明不保證?

Thinking Machines Lab 在 2025 年 9 月發表的〈Defeating Nondeterminism in LLM Inference〉裡做了一組實測:用 Qwen/Qwen3-235B-A22B-Instruct-2507,對同一個提示詞在 temperature 0 下取樣 1,000 次、每次生成 1,000 個 token,結果得到 80 種不同的輸出,其中最常出現的那一種只出現了 78 次。更精細的觀察是:這 1,000 份輸出在前 102 個 token 完全相同,第 103 個 token 才開始分岔——有 992 份接著寫「Queens, New York」,另外 8 份寫成「New York City」。(第三方研究,2025-09-10)

真正的元兇不是大家常講的「GPU 平行 + 浮點誤差」這麼籠統。該研究指出,LLM 前向傳播中其實沒有用到會造成 run-to-run 不確定的 atomic add;問題出在批次不變性(batch invariance)——同一筆請求的數值結果,會隨著伺服器當下跟多少其他請求一起被打包成一批而改變。而伺服器的負載,從單一使用者的角度看就是隨機的。研究團隊把 RMSNorm、矩陣乘法、attention 三個含 reduction 的運算改寫成批次不變版本之後,同一組 1,000 次取樣全部輸出一致。代價是效能:在另一組獨立的效能測試中(改用 Qwen-3-8B、單張 GPU、請求 1,000 個序列、輸出長度 90 到 110),vLLM 預設為 26 秒,未優化的確定性版本變成 55 秒,改良 attention kernel 後回到 42 秒。(第三方研究,2025-09-10;請注意這兩組實驗的模型與設定不同,效能數字不能直接套回上面那組 235B 的重現性測試)

底層的源頭是浮點數不滿足結合律:(a + b) + c ≠ a + (b + c)。加總順序一變,末位就可能差一點點;那一點點在某個 token 上剛好把第一名和第二名的排序翻過來,後面整段話就走向另一條路。所以「temperature 0 不完全確定」不是模型在耍你,是數值計算的物理現實。

順帶一提,OpenAI 的 seed 參數也不是萬靈丹:官方對它的定義是「our system will make a best effort to sample deterministically… Determinism is not guaranteed」,並要求你自行比對回應中的 system_fingerprint 來監控後端變動(官方事實,2026-08-14 查證)。OpenAI 官方 Cookbook 也直接寫明「The Chat Completions and Completions APIs are non-deterministic by default」。

top-p、top-k 差在哪?為什麼官方叫你別兩個一起調

temperature 是縮放整個機率分布,而 top-p 與 top-k 是裁切候選名單:

• top-k:只從機率最高的 K 個候選裡挑。Anthropic 官方文件的描述是用來「remove “long tail” low probability responses」。
• top-p(nucleus sampling):把候選字依機率由高到低累加,加到超過 p 就切斷,只在這個「核心」裡抽。OpenAI 的說明給了很好記的例子:「So 0.1 means only the tokens comprising the top 10% probability mass are considered.」(官方事實,2026-08-14 查證)

兩者的關係是:temperature 決定分布多陡,top-p 決定候選圈多大。同時大幅調動兩個,你會很難歸因到底是誰造成輸出變化。這也是為什麼 OpenAI 在 temperature 與 top_p 兩處都放了同一句提醒:「We generally recommend altering this or top_p but not both.」(官方事實,2026-08-14 查證)Anthropic 則更保守,直接把 top_p 與 top_k 標為「Recommended for advanced use cases only.」——先動 temperature,其餘留預設,這就是官方給一般使用者的建議。

各家範圍不一樣,而推理模型乾脆不讓你調

最容易踩雷的地方:temperature 的數值範圍不是跨平台通用的。同樣填 1.0,在一邊是預設值,在另一邊已經是中段偏保守。

(以上為 2026-08-14 查證之官方文件內容)

第三列值得展開。微軟在 Azure OpenAI 的推理模型說明文件裡列出一份「Not Supported」清單,temperature、top_p、presence_penalty、frequency_penalty、logprobs、top_logprobs、logit_bias、max_tokens 全部在內(官方事實,文件標示更新日 2026-08-06)。也就是說,你把 temperature 塞進推理模型的請求裡,拿回來的多半是一個參數不支援的錯誤,而不是更穩定的答案。這類模型改用推理強度(reasoning effort)這種粒度更粗的旋鈕來控制行為——你能調的不再是「挑字要不要冒險」,而是「要花多少心力想」。具體可用等級各家與各代模型不同,以請求當下的官方參數文件為準。

換句話說,「調 temperature」這個習慣本身正在退場中——它是逐 token 抽樣時代的旋鈕,而模型的競爭焦點已經移到推理過程本身。

💡 總結:冷知識延伸

站長我自己在調參數時,實務上只守三條:分析、抽資料、寫程式類任務把 temperature 壓到 0 到 0.3;創意發想拉到 0.8 以上;top-p 除非有明確理由,否則不動。 這不是什麼玄學,而是照官方那句「二擇一」在做——變數少一個,出問題時才歸因得出來。

另一個很少人提的冷知識:很多人以為 ChatGPT、Claude 這種聊天介面有 temperature 可以調,其實沒有。滑桿是 API 層的東西;在聊天介面你能操作的只有提示詞。所以「請你嚴謹一點、不確定就說不知道」這種寫法,才是聊天介面版本的「調低 temperature」——效果不同,但它是你唯一握得到的把手。想把這把手握好,可以看看站內提示詞怎麼寫?10 個技巧讓 AI 聽懂你要什麼。

最後回到那個最一開始的問題:調成 0 就真的不會亂回答嗎?它會少一點「每次講法都不一樣」的困擾,但一個字都不會少講錯。 穩定跟正確,從來就是兩個不同的旋鈕。

❓ 常見問題

Q:temperature 設 0 和設 0.1,差別大嗎?

在多數情況下差別很小,因為 0.1 已經讓機率分布非常陡峭,第一名幾乎穩拿。真正的差別出現在第一名與第二名機率很接近的那些位置——0.1 仍保留一點翻盤空間,0 則完全不留。要復現結果就用 0,要保留一絲彈性就用 0.1 到 0.2。

Q:同一個提示詞、同樣 temperature 0,為什麼今天跟上週結果不同?

除了上面講的批次負載因素,還有一種更常見的原因:後端換了。模型權重、推論基礎設施、數值設定的任何調整都會改變輸出。OpenAI 就是為此提供 system_fingerprint 這個欄位,讓你能察覺後端組合已經變動(官方事實,2026-08-14 查證)。

Q:本地跑模型是不是就能完全復現?

不必然。前述研究明確指出,即使在自己的硬體上用 vLLM 或 SGLang 這類開源推論框架,取樣一樣不是確定性的;要真正做到位元級一致,得把核心運算改成批次不變版本,並付出可觀的效能代價(第三方研究,2025-09-10)。

Q:那 temperature 該設多少才「對」?

沒有全域正解,但有一個穩健起手式:先用官方預設值跑一輪,再往你要的方向單向微調。Anthropic 官方文件給的方向很明確——分析與選擇題類任務用接近 0.0,創意與生成類用接近 1.0(官方事實,2026-08-14 查證)。

🔗 延伸閱讀

• Speculative Decoding 是什麼?用小模型幫大模型「猜下一個字」為什麼會更快
• Claude Opus 5 是什麼?功能、價格與怎麼選
• 2026 本地端 AI(Local LLM)硬體指南
• NotebookLM 完整教學:上傳 PDF、YouTube 打造專屬知識庫

📎 參考資料來源

📖 第一級|廠商官方:

• Anthropic — Messages API Reference(temperature / top_p / top_k 參數定義) — 2026-08-14 查證
• OpenAI — 官方 Python SDK 之 Chat Completions 參數定義(依 OpenAPI spec 生成) — 2026-08-14 查證
• OpenAI Cookbook — How to make your completions outputs consistent with the new seed parameter — 2026-08-14 查證
• Microsoft Learn — Azure OpenAI 推理模型(Not Supported 參數清單) — 2026-08-14 查證

📖 第二級|研究與權威技術分析:

• Thinking Machines Lab — Defeating Nondeterminism in LLM Inference(Horace He 等,2025-09-10) — 2026-08-14 查證