大模型能寫出工業級優化算法嗎？MIT提出FrontierOR給AI設下考場

新智元報道

【新智元導讀】過去的大模型優化基準，更多是在考「會不會建模、會不會調求解器」；FrontierOR直接把模型推向真實OR論文里的工業級問題，考的是它能不能像算法工程師一樣發現結構、設計算法，并在大實例上與Gurobi baseline進行比較。

過去兩年，LLM在「自然語言到數學模型」「自然語言到求解器代碼」上進步迅速。模型能讀懂題目，寫出MIP公式，調用Gurobi或其他求解器，看起來已經具備了初步的優化建模能力。但在真正的工業規模問題上，這還遠遠不夠。

真正的難題并不是把約束一條條翻譯成數學表達式，而是設計一套能在大實例上跑得動、跑得準、跑得快的算法。即便一個MIP模型完全正確，交給通用求解器后，也可能在一小時內連可證明的高質量解都拿不到。這也是為什么現實中的OR工程師依然需要寫分解算法、列生成、Benders、局部搜索、元啟發式和數學規劃—啟發式混合算法。

近日，來自麻省理工學院等機構的研究者提出了FrontierOR：一個面向大規模優化算法設計能力的LLM評測基準。

不同于只考察「能否建模」或「能否調用求解器」的傳統benchmark，FrontierOR關注的是LLM能否像真正的OR研究者和工程師一樣，針對復雜問題結構設計出可擴展、高質量且高效率的算法。

論文鏈接：arxiv.org/abs/2605.25246

項目主頁：frontieror.vercel.app

代碼鏈接：github.com/Minw913/FrontierOR

數據集鏈接：SmartOR/FrontierOR

FrontierOR的核心問題正是：今天最強的大模型，究竟能不能從真實問題出發，自主設計有競爭力的高效算法？它能否不再只是「調用求解器」，而是像OR專家一樣，根據問題結構選擇分解、啟發式、搜索與混合策略？

這項工作的意義在于，它把LLM-for-OR的評估重心從「會不會寫模型」推進到「會不會設計算法」。這也是大模型走向真實工業決策系統必須跨過的一道門檻。

研究背景

已有不少基準關注LLM在優化問題中的建模能力，例如讓模型根據自然語言問題生成數學規劃、調用求解器，或者在小規模實例上驗證答案。這類任務非常重要，但它們往往難以回答一個更貼近工業部署的問題：模型能否在求解器性能已經飽和的大規模實例上，主動創造更有效的算法路徑？

在運籌優化實踐中，通用求解器只是起點，不是終點。真實問題常常具有特殊結構：網絡流結構、時間分解結構、車輛路徑結構、庫存與路徑耦合、調度中的機器與工序耦合、選址中的容量與覆蓋耦合等。優秀的算法工程師會利用這些結構，把原問題拆開、近似、松弛、重組，再通過啟發式或精確方法混合求解。

因此，一個真正面向OR的大模型基準，需要同時滿足三個條件：題源足夠真實、實例足夠大、評測足夠嚴格。FrontierOR正是在這個背景下提出：它不是給大模型出一套「優化練習題」，而是把過去三十多年OR文獻中經過同行評審的復雜問題，轉化為可自動評測的算法設計任務。

表1 FrontierOR與代表性OR/LLM-for-optimization基準的多維度比較

研究方法

FrontierOR的構造流程可以概括為四步：從文獻中選題、將論文問題轉化為標準化任務組件、經過自動與專家雙重質檢，再篩選出更具挑戰性的Hard子集。

• 第一步，真實文獻選題。數據源覆蓋1992–2025年間20余家OR期刊，共180篇論文。入選任務需問題定義清晰，且原文獻已經體現出專用算法相對通用求解器的工程價值。

• 第二步，標準化任務組件。每篇論文被轉化為自然語言問題描述、數學模型、Gurobi參考實現、參考解和獨立可行性檢查器。

• 第三步，兩層質量驗證。首先通過自動交叉驗證檢查Gurobi參考解與可行性檢查器是否一致；隨后由15名OR專家進行多輪審核，核查模型、描述、代碼與檢查器的一致性。

• 第四步，Hard子集篩選。從180個任務中選出50個更難任務，聚焦組合爆炸、規模更大、約束更耦合且Gurobi在1小時預算內無法證明最優的場景。

圖1 FrontierOR基準全貌：問題類別、應用領域、實例規模與構造流程

評測協議

評測流程同樣強調端到端能力。模型首先根據自然語言任務生成完整算法程序。程序先在小實例上進行可執行性、可行性和質量預篩：若超時、不可行，或與Gurobi的小實例gap超過10%，就不進入大實例評測。

通過預篩后，程序將在每個任務的多個大規模實例上運行，并與專家審核過的Gurobi參考解進行對照。Frontier OR使用四項指標：Execution rate（可執行率）、Feasibility（可行性）、Solution quality（解質量）和Quality-Time Efficiency（QTE，質效綜合）。其中QTE最嚴格：只有目標值與Gurobi參考解相對差距不超過1%或者超過Gurobi的解，才算成功。

圖2 Frontier OR的兩段式評測流程：小實例預篩，大實例評估質量與速度

實驗結果

One-shot：可執行性接近上限

在one-shot設置中，模型需要從零生成完整算法程序，可以進行有限的基于執行錯誤的自調試，但不能根據評測反饋反復改寫算法。這一設置考察的是模型單次讀題、建模、設計算法與編碼的綜合能力。

結果顯示，最強模型的可執行性已經非常高。例如GPT-5.3-Codex在Full全集上的Execution rate達到0.98，Gemini 3.1 Pro與Claude Opus 4.6也都達到0.93。這說明對前沿模型而言，「代碼能否跑起來」已經不再是最主要瓶頸。

但可執行不等于會解。Feasibility、Solution quality和QTE仍然顯著低于Execution rate。換句話說，大模型已經能寫出形式上完整的優化程序，但要讓這段程序在工業級規模上保持可行、接近最優，并且比Gurobi更快，仍然困難。

從整體分層看，前沿模型在Full全集與Hard子集上都顯著優于其他主流模型。FrontierOR全集上，前沿模型的Feasibility集中在0.60–0.62，而其他主流模型約為0.18–0.42。Hard子集上差距依然存在：前沿模型為0.49–0.64，其他主流模型下降到0.13–0.37。

Hard子集進一步拉開了前沿模型之間的算法能力差距。全集上三個前沿模型的QTE落在0.25–0.31的窄幅區間，看似接近；但在Hard子集上，Claude Opus 4.6的QTE仍達到0.32，GPT-5.3-Codex則降至0.18，二者相差接近2倍。Hard子集因此成為真正的「算法工程能力分水嶺」。

表2 FrontierOR one-shot評測結果：Full全集與Hard子集上的可執行率、可行性、解質量和QTE

算法選擇出現分化

研究團隊進一步分析了模型生成程序所采用的求解方法，將其分為五類：純求解器調用、分解、構造性啟發式、局部搜索/元啟發式，以及數學規劃-啟發式混合方法。這個分析非常關鍵，因為它直接揭示模型是否真正具備算法設計意識。

結果顯示，較弱模型高度依賴純求解器調用。例如LLaMA-4-Maverick約99%的程序都是monolithic solvercall，本質上是把問題丟給通用求解器。相比之下，Claude Opus 4.6的方法分布最均衡：約37%為純求解器，27%為局部搜索/元啟發式，27%為數學規劃-啟發式混合。

更重要的是，非純求解器方法在QTE指標上整體更有優勢。這意味著「方法多樣性」本身就是競爭力：模型越能根據問題結構選擇分解、啟發式和混合算法，就越有可能在大實例上同時贏得質量與速度。

圖3 不同模型生成程序的求解方法分布與失敗模式分析

失敗模式遷移：從「建模不會」到「搜索不夠深」

失敗模式分析顯示，隨著模型能力提升，錯誤發生的位置正在系統性后移。較弱模型主要在數學模型設計、約束規范、I/O schema等前期環節出錯；較強模型在這些基礎環節的錯誤明顯減少，新的瓶頸轉向啟發式搜索的深度與質量。

這和人類算法工程師的成長路徑非常相似。初學者首先會犯建模錯誤：變量定義不清、約束漏寫、輸入輸出不匹配；更成熟的工程師不容易犯這些低級錯誤，但會面臨更難的問題：搜索策略是否足夠強、鄰域設計是否有效、松弛與修復是否能兼顧速度和質量。

因此，FrontierOR不僅告訴我們「誰得分更高」，也告訴我們「能力瓶頸在哪里」。這對下一代LLM-for-OR系統的設計尤其重要：未來的突破不一定來自更會寫公式的模型，而可能來自更會搜索、更會組合算法技能、更會利用反饋自我改進的系統。

自演化

單次生成只是第一步。現實中的算法設計從來不是一稿定終身，而是不斷運行、分析失敗、修改策略、再運行的迭代過程。FrontierOR因此進一步評估了三種測試時自演化框架：OpenEvolve、EoH和CORAL。

實驗選取Hard子集中最難的40%任務作為self-evolve測試集，以GPT-5.3-Codex單次生成的程序作為初始種子。每個框架統一限制30次候選程序，以最終最佳結果作為終態。這樣可以確保差異主要來自搜索機制，而不是初始程序不同。

結果非常亮眼：在三種自演化框架下，最優候選程序在各項指標上均顯著超越單次生成。QTE從one-shot的0.15提升至最高0.50，意味著在最難任務上，約半數大實例已可被LLM生成的算法同時滿足「質量接近Gurobi」和「速度不慢于Gurobi」兩個條件。

其中，CORAL憑借多智能體共享記憶機制取得最穩定提升，QTE達到0.50；OpenEvolve緊隨其后，QTE為0.49；EoH也帶來明顯改進，但性能波動更大，QTE為0.33。

表3 三種測試時自演化框架在最難任務上的表現：QTE最高由0.15提升至0.50

進一步觀察演化軌跡，可以看到一個很有啟發的現象：速度維度往往在前5次嘗試內就能突破Gurobi基線，而解質量維度要困難得多。原因并不難理解：想讓算法跑得更快，采用輕量構造性啟發式就可能做到；但想在「更快」的同時接近全局最優，就需要更精細的鄰域、修復策略、松弛策略與搜索控制。

這說明，LLM的自演化并不是簡單地「多試幾次代碼」。真正有效的自演化，需要能記住歷史失敗、識別性能瓶頸、動態調整搜索方向，并在速度與質量之間做結構化權衡。

圖4 三種自演化框架的質量—速度二維演化軌跡：速度容易先突破，質量提升更難

未來應用

FrontierOR的價值不止在于給模型排榜，更在于為下一代智能優化系統提供了明確的研發方向。若大模型能夠穩定地讀懂真實業務需求、識別優化結構、調用或組合合適的算法技能，并通過執行反饋自我改進，那么它有機會成為工業決策系統中的「AI算法工程師」。

在供應鏈場景中，這類系統可以根據訂單、倉庫、庫存、運輸網絡和時效要求，自動生成面向特定規模的調度與路徑算法；在能源系統中，它可以為電網調度、儲能管理、負荷平衡設計快速近似求解策略；在交通與城市系統中，它可以面向動態需求、擁堵傳播和資源約束，生成可實時部署的優化算法。

更進一步，FrontierOR也暗示了agentic optimization的未來形態：LLM不再只是一個代碼生成器，而是一個會使用技能庫、會調用驗證器、會運行實驗、會做錯誤歸因、會在有限預算下主動探索的算法設計智能體。

展望

• 構建OR算法設計技能庫。將分解、松弛、列生成、局部搜索、修復、重啟、混合求解等常見策略沉淀成可檢索、可組合、可執行的技能模塊，讓agent能根據問題結構自動選擇算法模板。

• 發展更可靠的verifier/evaluator。評測器不僅要檢查可行性，還要識別是哪類約束導致失敗、是哪類局部搜索停滯，從而把執行反饋轉化為下一輪設計方向。

• 提升自演化的預算調度能力。在大規模實例上，每次評測都很昂貴。未來系統需要學會何時探索新結構、何時微調參數、何時終止無效方向。

• 推動LLM與傳統優化器深度融合。最有前景的方向可能不是「LLM替代求解器」，而是LLM負責發現結構與設計算法，傳統求解器負責局部精確優化與可信驗證。

總結來看，FrontierOR為大模型的OR算法工程能力畫出了第一張系統化地圖：大模型已經能夠寫出部分有競爭力的優化算法，但真正決定上限的，不再是代碼語法或公式翻譯，而是結構發現、搜索設計和自我進化能力。

如果說前一階段的LLM-for-OR研究回答的是「大模型會不會建模」，那么FrontierOR開始追問一個更難也更現實的問題：大模型能不能成為真正的算法設計者？

參考資料：

arxiv.org/abs/2605.25246

編輯：LRST