大模型能写出工业级优化算法吗？MIT的FrontierOR给出了残酷答案

大模型能写出工业级优化算法吗？MIT的FrontierOR给出了残酷答案

大模型能写代码了，能调求解器了，能建模了。

但在真正的工业规模问题上，这些远远不够。

MIT等机构最近提出了FrontierOR：一个面向大规模优化算法设计能力的LLM评测基准。它不是给大模型出一套”优化练习题”，而是把过去三十多年OR（运筹优化）文献中经过同行评审的复杂问题，转化为可自动评测的算法设计任务。

结果很残酷：最强模型的可执行率高达98%，但质效综合（QTE）只有0.18-0.31。

换句话说，大模型已经能写出形式上完整的优化程序，但要让这段程序在工业级规模上保持可行、接近最优，并且比Gurobi更快，仍然困难。

为什么需要FrontierOR？

过去两年，LLM在”自然语言到数学模型””自然语言到求解器代码”上进步迅速。模型能读懂题目，写出MIP公式，调用Gurobi或其他求解器，看起来已经具备了初步的优化建模能力。

但真正的难题并不是把约束一条条翻译成数学表达式，而是设计一套能在大实例上跑得动、跑得准、跑得快的算法。

即便一个MIP模型完全正确，交给通用求解器后，也可能在一小时内连可证明的高质量解都拿不到。这也是为什么现实中的OR工程师依然需要写分解算法、列生成、Benders、局部搜索、元启发式和数学规划-启发式混合算法。

FrontierOR的核心问题正是：今天最强的大模型，究竟能不能从真实问题出发，自主设计有竞争力的高效算法？它能否不再只是”调用求解器”，而是像OR专家一样，根据问题结构选择分解、启发式、搜索与混合策略？

FrontierOR的设计：四个关键步骤

FrontierOR的构造流程可以概括为四步：

第一步，真实文献选题。 数据源覆盖1992-2025年间20余家OR期刊，共180篇论文。入选任务需问题定义清晰，且原文献已经体现出专用算法相对通用求解器的工程价值。

第二步，标准化任务组件。 每篇论文被转化为自然语言问题描述、数学模型、Gurobi参考实现、参考解和独立可行性检查器。

第三步，两层质量验证。 首先通过自动交叉验证检查Gurobi参考解与可行性检查器是否一致；随后由15名OR专家进行多轮审核，核查模型、描述、代码与检查器的一致性。

第四步，Hard子集筛选。 从180个任务中选出50个更难任务，聚焦组合爆炸、规模更大、约束更耦合且Gurobi在1小时预算内无法证明最优的场景。

这个设计的精妙之处在于：它不是考”会不会建模”，而是考”会不会设计算法”。

评测结果：可执行率高，但质效综合低

在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。

从整体分层看，前沿模型在Full全集与Hard子集上都显著优于其他主流模型。FrontierOR全集上，前沿模型的Feasibility集中在0.60-0.62，而其他主流模型约为0.18-0.42。

Hard子集进一步拉开了前沿模型之间的算法能力差距。全集上三个前沿模型的QTE落在0.25-0.31的窄幅区间，看似接近；但在Hard子集上，Claude Opus 4.6的QTE仍达到0.32，GPT-5.3-Codex则降至0.18，二者相差接近2倍。

Hard子集因此成为真正的”算法工程能力分水岭”。

算法选择出现分化：弱模型只会调求解器

研究团队进一步分析了模型生成程序所采用的求解方法，将其分为五类：纯求解器调用、分解、构造性启发式、局部搜索/元启发式，以及数学规划-启发式混合方法。

这个分析非常关键，因为它直接揭示模型是否真正具备算法设计意识。

结果显示，较弱模型高度依赖纯求解器调用。例如LLaMA-4-Maverick约99%的程序都是monolithic solver call，本质上是把问题丢给通用求解器。

相比之下，Claude Opus 4.6的方法分布最均衡：约37%为纯求解器，27%为局部搜索/元启发式，27%为数学规划-启发式混合。

更重要的是，非纯求解器方法在QTE指标上整体更有优势。这意味着”方法多样性”本身就是竞争力：模型越能根据问题结构选择分解、启发式和混合算法，就越有可能在大实例上同时赢得质量与速度。

失败模式迁移：从”建模不会”到”搜索不够深”

失败模式分析显示，随着模型能力提升，错误发生的位置正在系统性后移。

较弱模型主要在数学模型设计、约束规范、I/O schema等前期环节出错；较强模型在这些基础环节的错误明显减少，新的瓶颈转向启发式搜索的深度与质量。

这和人类算法工程师的成长路径非常相似。初学者首先会犯建模错误：变量定义不清、约束漏写、输入输出不匹配；更成熟的工程师不容易犯这些低级错误，但会面临更难的问题：搜索策略是否足够强、邻域设计是否有效、松弛与修复是否能兼顾速度和质量。

因此，FrontierOR不仅告诉我们”谁得分更高”，也告诉我们”能力瓶颈在哪里”。这对下一代LLM-for-OR系统的设计尤其重要：未来的突破不一定来自更会写公式的模型，而可能来自更会搜索、更会组合算法技能、更会利用反馈自我改进的系统。

自演化：从0.15到0.50的飞跃

单次生成只是第一步。现实中的算法设计从来不是一稿定终身，而是不断运行、分析失败、修改策略、再运行的迭代过程。

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。

进一步观察演化轨迹，可以看到一个很有启发的现象：速度维度往往在前5次尝试内就能突破Gurobi基线，而解质量维度要困难得多。

原因并不难理解：想让算法跑得更快，采用轻量构造性启发式就可能做到；但想在”更快”的同时接近全局最优，就需要更精细的邻域、修复策略、松弛策略与搜索控制。

这说明，LLM的自演化并不是简单地”多试几次代码”。真正有效的自演化，需要能记住历史失败、识别性能瓶颈、动态调整搜索方向，并在速度与质量之间做结构化权衡。

我的判断：这是起点，不是终点

1. 从”会不会建模”到”会不会设计算法”

过去，LLM-for-OR的评估重心是”会不会写模型”。

但从FrontierOR可以看出，评估重心正在转向”会不会设计算法”。

这意味着什么？

意味着我们开始能够用更贴近工业部署的标准，衡量大模型的真实能力。

这需要两个能力：一是对优化问题结构的深入理解，二是对算法设计意识的培养。

2. “方法多样性”本身就是竞争力

FrontierOR的发现说明了一个问题：弱模型高度依赖纯求解器调用，强模型方法分布更均衡。

这意味着”方法多样性”本身就是竞争力。

模型越能根据问题结构选择分解、启发式和混合算法，就越有可能在大实例上同时赢得质量与速度。

未来的LLM-for-OR系统，将是谁能更好地培养这种”方法多样性”，谁就能赢得市场。

3. 自演化不是”多试几次”，而是”结构化权衡”

CORAL的0.50 QTE说明了一个问题：真正有效的自演化，需要能记住历史失败、识别性能瓶颈、动态调整搜索方向，并在速度与质量之间做结构化权衡。

速度容易先突破，质量提升更难。

这意味着，未来的突破不一定来自更会写公式的模型，而可能来自更会搜索、更会组合算法技能、更会利用反馈自我改进的系统。

写在最后

大模型能写出工业级优化算法吗？

MIT的FrontierOR给出了残酷答案：可执行率高，但质效综合低。

但这不只是一次评测结果的公布。

它标志着LLM-for-OR的评估重心从”会不会建模”转向”会不会设计算法”，从”代码能否跑起来”转向”代码能否在工业级规模上保持可行、接近最优，并且比Gurobi更快”。

从”方法单一”转向”方法多样”，从”单次生成”转向”自演化”。

未来的LLM-for-OR系统，将是谁能更好地培养”方法多样性”，谁能更准确地进行”结构化权衡”，谁就能赢得市场。

这是起点，不是终点。