結合 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。一如預期，混合方法的表現優於其他方案：

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

下一步是建立可泛化及重用的介面，把自然語言轉換成結構化語義表示，讓後端將其轉化為可供求解器使用的程式碼。這項實驗集中於線性最佳化問題，並以三個公開數據集（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：

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% 的要求。混合方法正確執行這項硬性限制條件，並傳回有效答案。

例子 2：

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 與求解器混合系統，正朝着以下願景邁進：

• 代理不會虛構規則或限制條件。

• 邏輯推演及最佳化在數學上均嚴謹可靠。

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