LLM 算術推理：符號表示與外部工具驗證

大型語言模型能把文字題拆成步驟、解釋概念，甚至寫出看似完整的計算過程；但只要數字變長、條件順序改變，或同一題需要多次運算，答案仍可能出錯。這不是單純要求模型「再想一次」就能完全解決的問題，而是要把語言理解、符號表示、實際計算與驗證分開設計。

因此，與其把「符號記憶增強」理解成某個萬用功能，不如把它視為一種系統方法：讓模型把題目中的量、單位、關係與假設整理成可檢查的結構，再把確定性的計算交給適合的工具或求解器。

LLM 為什麼會在算術上失手？

語言模型的主要工作是根據上下文產生下一段文字。它可以從大量範例中學到算式、解題格式與常見模式，但自由文字推導不會自動變成可驗證的算術程序。研究也顯示，模型在某些基礎的複製、反轉、加法與符號操作上仍會受輸入長度、重複符號等因素影響；這代表一個在短題表現不錯的提示，不能直接推論到所有數字與格式。〈Limitations of Language Models in Arithmetic and Symbolic Induction〉

此外，推理題的條件呈現方式本身也會影響結果。Google DeepMind 的研究發現，即使不改變題目本質，調換前提順序也可能讓模型推理表現明顯下降；在其數學文字題的測試中也觀察到類似的脆弱性。這提醒我們：漂亮的單次示範不等於系統已經穩定。Google DeepMind：Premise Order Matters in Reasoning with LLMs

把問題拆成四個可檢查的部分

1. 從文字找出量與關係

模型先負責讀懂題意：哪些是已知量、哪些是未知量、每個數字的單位是什麼、條件之間是相加、相減、比例還是順序關係。這一步最適合使用語言模型，因為它需要處理自然語言中的省略、同義詞與描述順序。

實作時可要求模型把結果輸出成結構化欄位，例如變數名稱、值、單位、來源句子與關係式。這就是一種實用的「符號化記錄」：它不保證理解正確，但能讓後續系統與人員知道模型到底把哪句話當成了哪個數值。

2. 先驗證表達式，再執行運算

在把結果交給計算器、程式執行環境或符號求解器前，系統應檢查變數是否遺漏、單位是否相容、運算式是否引用未定義的量，以及是否踩到業務規則。此處的關鍵不是讓模型自由執行程式，而是使用權限受限、輸入可驗證的工具介面。

3. 將確定性計算交給適合的工具

如果題目已被正確轉成表達式，普通算術可以交給計算器；需要代數化簡或約束求解時，則可交給符號工具。PAL（Program-aided Language Models）的研究採取類似分工：LLM 負責把自然語言問題拆成可執行的程式步驟，實際求值則委交給 Python 執行環境。該研究在特定數學、符號與演算法基準上觀察到此分工的提升，但結果屬於其實驗設定，不能直接當成所有模型與所有題型的保證。PAL：Program-aided Language Models

4. 將答案連回原始條件

工具算出數字後，系統仍應檢查答案是否符合問題所問、單位是否合理、是否有遺漏限制條件，並保留「原文條件 → 結構化表示 → 運算式 → 工具結果」的紀錄。這能把錯誤定位到不同層次：是讀錯題、寫錯式、工具執行失敗，還是回答時把結果講錯。

符號化記錄能帶來什麼？

它最大的好處不是讓模型憑空得到更強的數學能力，而是把原本隱藏在文字推導裡的中間狀態變成可檢查的資料。例如，若題目提到「每月」、「含稅」與「折扣後」，系統可以分別記錄期間、金額基準與運算順序，讓測試者確認是否少讀了一個限制。

這類架構也較容易建立測試案例：同一個關係式可以換名稱、換數字、改變條件順序，再比對解析與結果是否一致。遇到不完整或互相矛盾的題目時，正確行為應是要求補充資訊，而不是把猜測填進公式。

神經模型與符號工具不是誰取代誰

語言模型擅長從非結構化敘述提出候選關係；符號系統擅長依明確規則運算與驗證。兩者結合的價值在於分工：前者協助縮小搜尋與理解範圍，後者提供可重現的推導。AlphaGeometry 的研究就是一個較複雜的例子：系統以語言模型提出可能有用的幾何構造，再由規則式推理引擎完成演繹與驗證。它不能直接證明所有算術應用都適用同一架構，卻清楚說明了「候選生成」與「規則驗證」可以是不同元件。Google DeepMind：AlphaGeometry