大模型能写出工业级优化算法吗？MIT提出FrontierOR给AI设下考场

过去两年，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