大模型能寫出工業(yè)級優(yōu)化算法嗎？MIT提出FrontierOR給AI設(shè)下考場

新智元報道

【新智元導(dǎo)讀】過去的大模型優(yōu)化基準，更多是在考「會不會建模、會不會調(diào)求解器」；FrontierOR直接把模型推向真實OR論文里的工業(yè)級問題，考的是它能不能像算法工程師一樣發(fā)現(xiàn)結(jié)構(gòu)、設(shè)計算法，并在大實例上與Gurobi baseline進行比較。

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

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

近日，來自麻省理工學(xué)院等機構(gòu)的研究者提出了FrontierOR：一個面向大規(guī)模優(yōu)化算法設(shè)計能力的LLM評測基準。

不同于只考察「能否建模」或「能否調(diào)用求解器」的傳統(tǒng)benchmark，F(xiàn)rontierOR關(guān)注的是LLM能否像真正的OR研究者和工程師一樣，針對復(fù)雜問題結(jié)構(gòu)設(shè)計出可擴展、高質(zhì)量且高效率的算法。

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

項目主頁：frontieror.vercel.app

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

數(shù)據(jù)集鏈接：SmartOR/FrontierOR

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

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

研究背景

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

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

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

表1 FrontierOR與代表性O(shè)R/LLM-for-optimization基準的多維度比較

研究方法

FrontierOR的構(gòu)造流程可以概括為四步：從文獻中選題、將論文問題轉(zhuǎn)化為標準化任務(wù)組件、經(jīng)過自動與專家雙重質(zhì)檢，再篩選出更具挑戰(zhàn)性的Hard子集。

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

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

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

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

圖1 FrontierOR基準全貌：問題類別、應(yīng)用領(lǐng)域、實例規(guī)模與構(gòu)造流程

評測協(xié)議

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

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

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

實驗結(jié)果

One-shot：可執(zhí)行性接近上限

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

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

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

從整體分層看，前沿模型在Full全集與Hard子集上都顯著優(yōu)于其他主流模型。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的窄幅區(qū)間，看似接近；但在Hard子集上，Claude Opus 4.6的QTE仍達到0.32，GPT-5.3-Codex則降至0.18，二者相差接近2倍。Hard子集因此成為真正的「算法工程能力分水嶺」。

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

算法選擇出現(xiàn)分化

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

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

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

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

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

失敗模式分析顯示，隨著模型能力提升，錯誤發(fā)生的位置正在系統(tǒng)性后移。較弱模型主要在數(shù)學(xué)模型設(shè)計、約束規(guī)范、I/O schema等前期環(huán)節(jié)出錯；較強模型在這些基礎(chǔ)環(huán)節(jié)的錯誤明顯減少，新的瓶頸轉(zhuǎn)向啟發(fā)式搜索的深度與質(zhì)量。

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

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

自演化

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

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

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

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

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

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

這說明，LLM的自演化并不是簡單地「多試幾次代碼」。真正有效的自演化，需要能記住歷史失敗、識別性能瓶頸、動態(tài)調(diào)整搜索方向，并在速度與質(zhì)量之間做結(jié)構(gòu)化權(quán)衡。

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

未來應(yīng)用

FrontierOR的價值不止在于給模型排榜，更在于為下一代智能優(yōu)化系統(tǒng)提供了明確的研發(fā)方向。若大模型能夠穩(wěn)定地讀懂真實業(yè)務(wù)需求、識別優(yōu)化結(jié)構(gòu)、調(diào)用或組合合適的算法技能，并通過執(zhí)行反饋自我改進，那么它有機會成為工業(yè)決策系統(tǒng)中的「AI算法工程師」。

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

更進一步，F(xiàn)rontierOR也暗示了agentic optimization的未來形態(tài)：LLM不再只是一個代碼生成器，而是一個會使用技能庫、會調(diào)用驗證器、會運行實驗、會做錯誤歸因、會在有限預(yù)算下主動探索的算法設(shè)計智能體。

展望

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

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

• 提升自演化的預(yù)算調(diào)度能力。在大規(guī)模實例上，每次評測都很昂貴。未來系統(tǒng)需要學(xué)會何時探索新結(jié)構(gòu)、何時微調(diào)參數(shù)、何時終止無效方向。

• 推動LLM與傳統(tǒng)優(yōu)化器深度融合。最有前景的方向可能不是「LLM替代求解器」，而是LLM負責(zé)發(fā)現(xiàn)結(jié)構(gòu)與設(shè)計算法，傳統(tǒng)求解器負責(zé)局部精確優(yōu)化與可信驗證。

總結(jié)來看，F(xiàn)rontierOR為大模型的OR算法工程能力畫出了第一張系統(tǒng)化地圖：大模型已經(jīng)能夠?qū)懗霾糠钟懈偁幜Φ膬?yōu)化算法，但真正決定上限的，不再是代碼語法或公式翻譯，而是結(jié)構(gòu)發(fā)現(xiàn)、搜索設(shè)計和自我進化能力。

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

參考資料：

arxiv.org/abs/2605.25246

編輯：LRST