結合 LLM 與形式求解器，實現可靠的 AI 決策

大型語言模型（LLM）在理解自然語言、生成流暢回應，以及打造全新的客戶與員工體驗方面，已取得非凡進展。然而，LLM 本質上具有隨機性，因此運用它們進行複雜的數值或邏輯推理時，很難保證輸出符合規範或達到最佳結果。例如：

• 經理指示 AI 規劃助理：「下週盡可能多出貨，同時壓低成本。」系統於是提出一套看似高效的積極計畫，卻在未示警的情況下超出倉庫容量，無法履行交付保證。

• 協調員指示 AI 助理：「重新指派工作人員，減少過夜住宿並盡量降低干擾。」模型於是產生一份成本較低、看似最佳的排程，卻違反強制工時或休息限制。

• 金融營運 AI 助理必須依照嚴格的區域與風險限制核准交易，卻捏造了一套聽起來合規、實際上違反內部政策的理由，放行可疑交易。

在營運要求嚴格的環境中，結合 LLM 與形式求解器，有助於確保以自然語言驅動的決策維持在既定界線內，避免產生不可行、非最佳或不合規的結果。

我們的研發團隊正在研究一種混合方法，結合 LLM 的創造力與靈活性，以及 Z3、Pyomo 和 OR-Tools 等形式數學求解器的嚴謹性、可保證性與透明度。我們也正在打造可重複使用的形式 AI 引擎，讓這項能力成為企業技術堆疊的標準元件。此平台將讓組織能直接從既有系統匯入業務規則、持續依據這些規則驗證決策，並在明確界定的範圍內安全部署 AI 代理。

我們的願景是在加速大規模決策的同時，降低營運風險。領導者可透過自然語言輸入，更快做出符合政策的決策；組織則能自動處理排程、供應鏈資源分配、金融營運、政策驗證，甚至影片或 3D 設計中的臨時變更。內建防護機制可防止不可行、不合規或不安全的結果進入正式環境。

在涵蓋物流型最佳化問題與三項公開基準的控制實驗中，我們的混合方法持續展現：

• 更高的準確度

• 更高的可解釋性與可稽核性

我們的方法翻轉了常見的「一切都由 LLM 完成」模式，改採以下設計：

此方法明確劃分職責：LLM 從自然語言擷取規則與限制條件，而 OR-Tools、Z3 和 Pyomo 等確定性求解器則負責最佳化與驗證。最終成果結合了兩種方法的優勢：

我們首先處理部分客戶面臨的一項挑戰：

將自然語言要求轉化為最佳的即時資源決策，同時嚴格落實營運、政策與成本限制。

這項挑戰正是現代物流與供應鏈的核心，涵蓋人力排程、資產分配、路線規劃、履約規劃及容量管理。這也是 LLM 與形式求解器必須攜手合作，才能打造可信賴系統的領域。為進行評估，我們建立了受控測試情境、資料來源與限制條件，另加上 240 項合成查詢。範例包括：

• 請在取消作業後修改現有排程。目標設施必須在 2025 年 12 月 24 日前獲得完整供應。若情況允許，請從鄰近倉庫調度庫存，並經由指定集運點運送。最早可開始日期為 2025 年 12 月 14 日。

• 臨時要求：一位貴賓將於三小時後抵達 A 地點。我們需要相關人員在兩小時內抵達現場。請調整人力配置，同時盡量減少對現有排程的變更。

從這些查詢可看出，系統必須可靠地直接從自然語言要求中擷取並落實硬性與軟性限制條件：

• 硬性限制條件沒有妥協空間（例如最早開始日期、合約條款及容量上限）。只要違反其中任何一項，解決方案便屬無效。

• 軟性限制條件代表偏好，例如盡量減少延誤、降低成本及限制變更幅度。目標是在不逾越硬性界線的前提下進行最佳化。

這些最佳化問題的某些面向無法完全預先定義。系統必須根據結構化業務邏輯、內部文件與營運資料中的預先定義限制條件和目標，再納入使用者要求，進行動態組合。

為了解不同技術在此情境下的表現，我們實作並比較了三種方法。

1. 純 LLM：最簡單的方法是將所有相關資料及使用者的自然語言要求傳給單一 LLM 提示詞，要求它產生最佳計畫或配置。這種方法雖可處理小型或限制較寬鬆的問題，但複雜度提高後便難以應付。模型可能忽略限制條件、優先處理錯誤目標，或產生聽起來合理但其實不可行的計畫，而且沒有可靠方法可偵測或防止失敗。

2. LLM + 程式碼解譯器：在此方法中，LLM 會解讀要求，並使用工具存取資料來源及產生可執行的最佳化程式碼。這能提升靈活性與可觀測性，但可靠性仍是一項問題。LLM 仍須將限制條件轉譯為正確程式碼，而細微的推理或編碼錯誤可能造成無效或非最佳結果，限制條件增加時尤其如此。

3. 混合式：LLM → 結構化限制條件 → 確定性求解器：第三種方法會劃分職責。LLM 絕不會「決定」結果，而是協助將變數、限制條件與目標形式化。經過驗證的最佳化求解器會落實限制條件、保證可行性，並產生可驗證及稽核的結果。LLM 的角色僅限於使用預先定義的結構描述，將自然語言要求轉譯為明確的結構化限制條件。這些限制條件會自動編譯成 OR-Tools 等求解器的程式碼，以確定性方式算出可行的最佳解決方案。

我們使用多種 LLM 測試這些方法，包括 GPT-5、GPT-5.1 和 GPT-5.2。不出所料，混合方法的表現優於其他方法：

我們的混合方法展現了大幅提升的準確度、超過 4 倍的 Token 效率，以及延遲降低一個數量級的成果。

下一步是建立可泛化、可重複使用的介面，將自然語言轉換為結構化語意表示，再由後端轉譯成可供求解器使用的程式碼。在這項實驗中，我們聚焦於線性最佳化問題，並使用三個公開資料集（NLP4LP、NL4OPT 和 IndustryOR）評估此方法。

1. 獨立 LLM

2. 混合方法（LLM → 結構化規則 → 求解器 → 驗證輸出）

• 使用 LLM 從輸入中擷取變數、限制條件與目標，並建構結構化最佳化問題。

• 將結構化問題與原始要求傳給 LLM 進行自我驗證。

• 將結構化問題轉譯成 OR-Tools 程式碼，以計算最佳配置。

我們使用專有前沿模型評估此方法，包括 GPT-5.1、GPT-5 mini、GPT-5.1-Codex-Max 和 GPT-5.2，以及 Kimi K2、GPT-OSS 模型和 MiniMax M2 等開放原始碼模型。箱形圖彙整了各種方法的結果。

在幾乎所有受評估的底層語言模型中，混合方法都比獨立 LLM 基準持續產生更準確、穩定且可驗證的結果。雖然各模型的絕對表現不同，混合方法帶來的相對提升仍維持一致。這表示改善來自將自然語言理解與形式最佳化分開處理，而非仰賴任何單一模型的推理能力。

準確度

NLP4LP 與 NL4OPT 主要由線性規劃問題組成；混合方法在這兩者上皆達到接近上限的準確度，並優於獨立 LLM 提示方法。混合系統不只是產生「大致正確」的推理，而是更穩定地生成有效且格式完善的數學表述。在難度較高的 IndustryOR 資料集上，兩種方法的準確度都會下降，但原因不同。許多 IndustryOR 問題涉及車輛路線規劃、工作排序及人力配置等組合結構，超出求解器後端目前支援的線性最佳化能力。

失敗模式分析顯示，獨立 LLM 經常違反必要的限制條件，如下所示：

範例一：

1"A bodybuilder buys prepared meals: a turkey dinner and a tuna salad sandwich. The turkey dinner contains 20 grams of protein, 30 grams of carbohydrates, and 12 grams of fat. The tuna salad sandwich contains 18 grams of protein, 25 grams of carbohydrates, and 8 grams of fat. The bodybuilder needs at least 150 grams of protein and 200 grams of carbohydrates. Because turkey dinners are expensive, no more than 40% of the meals should be turkey dinners. How many of each meal should the bodybuilder eat to minimize total fat intake?"

獨立 LLM 產生的解決方案雖然總脂肪量較低，卻違反火雞餐不得超過餐點總數 40% 的要求。混合方法會正確落實這項硬性限制條件，並傳回有效答案。

範例二：

1"A hospitalized patient can take two pills: Pill 1 and Pill 2. Each Pill 1 provides 0.2 units of pain medication and 0.3 units of anxiety medication. Each Pill 2 provides 0.6 units of pain medication and 0.2 units of anxiety medication. Pill 1 causes 0.3 units of discharge, while Pill 2 causes 0.1 units. At most 6 units of pain medication may be provided, and at least 3 units of anxiety medication must be provided. How many of each pill should the patient receive to minimize total discharge?"

獨立 LLM 再次產生排放量較低的解決方案，卻超過允許的止痛藥用量上限。混合方法會正確落實該項硬性限制條件，並傳回有效答案。

延遲與 Token 使用量

延遲與 Token 使用量資料揭示了一項重要差異。混合方法的平均延遲與 Token 使用量高於單次 LLM 提示詞，但這反映的是架構選擇，而非效率不彰。

混合管線包括：

1. 呼叫 LLM 一次或多次，以擷取結構化變數、限制條件與目標。

2. 執行自我驗證步驟，以找出內部不一致之處。

雖然這些步驟比單一提示詞增加了額外負擔，但延遲仍有明確上限且可預測；問題一旦妥善建構，求解器通常能快速執行。這些額外作業會產生明確、可重複使用且可稽核的中介表示。相較之下，獨立 LLM 方法將推理壓縮成一次不透明的生成過程，把成本轉嫁到重試、人工檢查及下游失敗。未來版本可透過以下方式降低額外負擔：

• 快取擷取出的結構描述。

• 以增量方式更新限制條件。

• 改善提示詞與呼叫的協調流程。

透明度與可稽核性

最後，即使兩種方法都失敗，失敗模式本身也有根本差異。

• 使用獨立 LLM 時，失敗往往不易察覺：模型可能傳回只有細微錯誤的結果。

• 使用混合方法時，明確的問題表述可讓失敗清楚可見，並協助團隊找出是哪個表述環節導致錯誤。

未來版本可在介面中呈現這些表述，讓使用者在求解器執行前加以稽核或驗證。這種透明度不僅能提高實測準確度，也讓系統更容易偵錯與改善，對實際部署至關重要。

重點結論

在所有基準及大多數受測的底層模型中，結果都進一步印證了我們工作的核心結論：

LLM 擅長理解與轉譯意圖，但要確保正確性，確定性求解器不可或缺。

混合方法將自然語言從歧義來源轉化為可靠介面，支援具備嚴謹數學基礎的決策，使企業 AI 朝兼具智慧與可信度的系統更進一步。

企業限制條件很少以整齊的結構描述或措辭完美的提示詞存在。這些條件散布於資料庫、試算表、內部政策與合約中。使用者要求可能不完整、語意模糊，或與業務規則不一致。為了讓這套方法能大規模運作，我們正在打造可重複使用的後端引擎，將這些複雜因素轉化為可靠的企業能力。

此引擎的核心是作為 AI 驅動決策系統的形式化骨幹，提供：

• 具備配接器的符號知識庫，可匯入業務規則、限制條件、變數與目標。

• 將結構描述編譯成求解器程式碼的轉譯層。

• 讓團隊能檢視、稽核及修改限制條件的介面。

目前這些實驗雖聚焦於最佳化，但同一方法也可延伸至邏輯驗證。潛在商業應用包括：

• 在落實所有營運限制條件的同時，執行臨時動態排程、路線規劃與資源分配。

• 產生始終符合業務規則的答案與建議。

• 設計及驗證複雜的 3D 物件、影片與架構，並在製作前找出不可行的設計。

現今的 AI 功能強大，但企業需要的不只是能力，還需要正確性、一致性與控制力。我們的 LLM 與求解器混合系統，正帶領我們邁向以下願景：

• 代理不會憑空捏造規則或限制條件。

• 邏輯推導與最佳化具備嚴謹的數學基礎。

• 自然語言成為確定性系統的通用介面。