大模型能写出工业级优化算法吗？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 solverc