LLM 在反直覺機率題翻車

這篇研究證明，LLM 在標準離散機率題表現很好，但一碰到反直覺或改寫題型就容易失準。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：標準題平均準確率 0.96；反直覺題降至 0.59
• 突破點：同題型做抗直覺測試

這篇論文在測一件很實際的事：LLM 到底是真的會算機率，還是只是在熟悉題型上看起來很會。作者把標準題和反直覺題分開測，結果顯示，模型在教科書式問題上很強，但只要題目換個說法、塞進誤導線索，表現就會掉下來。

對做助理、教學、風險解釋或決策支援的人來說，這不是小問題。因為真實世界的使用者不會永遠用最乾淨、最標準的方式提問。只要模型對措辭很敏感，它就可能在看似簡單的機率推理上失手。

這篇在解什麼痛點

這篇研究想處理的，是 LLM 在「看起來懂」和「真的懂」之間的落差。作者關心的不是模型能不能解高等數學，而是它在離散機率這種需要正確理解不確定性的題目上，是否真的有穩定推理能力。

摘要裡的核心想法很直接：就算模型在一般數學 benchmark 上成績不錯，也不代表它能在機率題上可靠作答。尤其當題目不是標準模板，而是混入干擾資訊、改寫成不常見形式，模型可能會走捷徑，而不是照機率結構推理。

這個切法很重要，因為真實應用場景通常不是整齊的考卷。使用者會改寫問題、漏掉條件、加上多餘描述，甚至不小心提供錯誤暗示。若系統只在 canonical 題型上穩，實務上就不夠可靠。

方法怎麼做

作者做的是一個受控的離散機率 benchmark。摘要明確提到，他們建立了兩組資料：一組是標準題，另一組是反直覺題。前者比較接近教科書常見形式，後者則刻意設計成容易誘發 heuristic reasoning，也就是讓模型想走表面捷徑。

研究一共評估了八個 state-of-the-art 模型，並且每個模型都測了有沒有 Chain-of-Thought prompting 的版本。這讓研究不只是看模型「能不能答對」，而是看它在被要求逐步推理時，是否真的能更穩定地處理機率問題。

摘要也測了兩個很貼近部署場景的 robustness 問題。第一個是 token bias：同一題如果改成 disguised variant，也就是外觀不同但邏輯相同的版本，模型表現會不會變。第二個是 prompt contamination：在提示詞裡加入誤導建議，答案品質會不會被帶歪。

換句話說，這篇不是單純比誰答對最多題，而是在看模型遇到不同包裝方式時，推理是否還穩定。這種測法比只看單一題型更接近產品環境。

研究實際證明了什麼

最明顯的結果，是標準題和反直覺題之間有很大的落差。摘要給出的平均數字很清楚：標準題平均準確率是 0.96，但反直覺題只有 0.59。也就是說，模型在熟悉題型上幾乎像是做對了，但一旦題目不那麼直觀，表現就明顯崩下來。

摘要還指出，當 canonical formulations 被改成 disguised variants 時，表現會下降超過 20%。這代表影響模型的，不只是數學本身，還包括題目的外觀與措辭。對一個應該理解問題結構的系統來說，這是很值得警惕的訊號。

更糟的是，誤導性的提示會讓表現最多下降 34%，而且沒有任何一個模型能完全免疫。這表示 prompt 裡多加一句看似合理的暗示，都可能改變模型對機率問題的判斷。

不過，摘要也有明確限制：它沒有提供每個模型的細部表格，也沒有公開資料集大小或信賴區間。換句話說，我們知道方向很清楚，但只靠摘要還不能判斷統計強度，也不能精細比較不同模型家族誰最穩。

• 八個 state-of-the-art 模型都被測試
• 每個模型都比較了有無 Chain-of-Thought prompting
• 資料集分成標準題與反直覺題兩類

這對開發者代表什麼

如果你的產品會碰到不確定性，這篇就是一個提醒：不要把 LLM 的機率能力想得太樂觀。它可能在標準題上看起來很準，但遇到稍微變形的題目，就不一定還能維持同樣水準。

這對產品設計很直接。像是解釋機率、處理風險分析、教學輔助，或任何需要比較 odds 的功能，都不能只靠模型原始輸出。你可能需要更強的驗證流程、題目正規化，甚至外掛一層 deterministic 的推理或檢查器。

token bias 的結果也很值得 eval 團隊注意。如果同一個問題換個寫法，分數就變動很大，那單一 benchmark 句型根本不足以證明可靠性。你需要測 canonical 版本，也要測 disguised 版本，才知道模型是不是在理解結構，而不是背表面模式。

prompt contamination 的結果則很像真實使用情境。使用者常常會在 prompt 裡塞入假設、暗示，或半成形的推理。這篇研究顯示，這些內容可能直接把模型帶偏。對開發者來說，prompt hygiene 不是美觀問題，而是正確性問題。

實務上怎麼解讀

這篇論文不是在說 LLM 完全不能做機率題。相反地，摘要顯示它們在標準題上表現非常高。真正的問題是穩定性。當題目變得反直覺、被改寫，或混入誤導線索時，模型就沒有那麼可靠。

所以，這篇研究也在提醒大家：不同類型的 reasoning benchmark 不能互相替代。某個模型在其他數學任務表現好，不代表它在機率推理上也一樣穩，尤其是當答案需要抵抗直覺捷徑時。

如果你是工程端，最保守也最實用的做法很簡單：把 LLM 當成在機率邊界案例上可能脆弱的系統。只要輸出會影響決策，就應該再用計算器、規則引擎，或領域內的檢查邏輯驗證一次，而不是直接相信模型已經掌握了機率規則。

如果你是做評測的人，這篇也提供了一個更好的測法：同時放入標準與改寫版本，再加上誤導提示，觀察性能是否穩定。這種測試方式更接近真實用戶怎麼折磨系統，也更能看出模型到底有沒有真的懂。

總結來看，這篇研究的重點不是「LLM 會不會算機率」，而是「LLM 在什麼條件下還算得穩」。摘要給出的答案很明確：在標準題上可以很強，但在反直覺、改寫、或被誤導的情境下，可靠度還不夠。