论文标题FrontierOR: Benchmarking LLMs’ Capacity for Efficient Algorithm Design in Large-Scale Optimization论文作者Minwei Kong, Chonghe Jiang, Ao Qu, Wenbin Ouyang 等 28 位作者论文链接https://arxiv.org/abs/2605.25246Github链接https://github.com/Minw913/FrontierOR数据集连接https://huggingface.co/datasets/SmartOR/FrontierOR网站链接https://frontieror.vercel.app编者按在交通调度、电网平衡、芯片布线、航班排班、供应链调配等真实工业场景中每天都有大量关键决策依赖运筹优化算法支撑。以双十一前夜的仓配调度为例物流公司的运营团队需要在 6 小时内把 50 万订单重新分配到 200 个仓库使总配送成本最低同时保证 90% 的包裹次日送达。短短一句需求背后是数百万决策变量与多重业务约束共同织出的高维优化问题。近年来已有大量工作致力于提升 LLM 把自然语言翻译成可执行的数学模型与求解器代码 的能力。然而面对真正的工业级优化问题真正难的从来不是列出一个数学模型而是设计一套能在工业规模上跑得动、跑得准、跑得快的算法。即便是数学上完全正确的 MIP 公式化在工业规模实例上交由商用求解器求解时也往往无法在一小时预算内返回任何可行解。这也是为什么运筹优化专家们至今仍在写列生成、Benders 分解、分支定界、邻域搜索和混合算法等以突破求解器的规模瓶颈在可接受时限内得到高质量解。那么今天最强的大模型到底能不能像一名真正的运筹优化工程师那样面向真实工业级的优化问题设计出有竞争力的算法为系统回答这个问题研究团队推出了FrontierOR——首个基于学术文献中真实复杂场景问题构建的大规模运筹优化基准。它收录了 180 个来自顶级 OR 期刊的真实问题每个问题都配有自然语言描述、可扩展的大规模实例、专家验证过的 Gurobi 参考解和独立的可行性检查器。图1 FrontierOR 基准全貌问题类别、应用领域、实例规模与 Gurobi 基线性能从期刊文献到可评测任务FrontierOR 的数据构造流程1. 数据源FrontierOR 的所有任务均源自运筹学领域的同行评审期刊论文。源期刊涵盖 Operations Research、Management Science、Transportation Science、INFORMS Journal on Computing、European Journal of Operational Research 等 20 余家 OR 期刊时间跨度 1992–2025共 180 篇论文。每篇论文需同时满足两项条件(1) 所研究的优化问题定义清晰、信息足以从原文重建(2) 在原文献中已展示出专用算法相对通用求解器具有显著效率优势的算法工程价值。2. 任务组件生成每篇论文沿一条标准化流水线被转化为一个评测任务其产出包括(1)自然语言问题描述基于原论文的应用语境和原始数学模型生成自然语言段落形式的问题描述避开公式与决策变量 / 约束 / 目标函数等建模术语。(2)数学模型从原论文中识别原始优化问题的完整的集合、参数、决策变量、目标函数与约束。(3)数据实例包含两类——小实例Gurobi 秒级可解用作 LLM 生成程序的正确性预筛大实例作为主评分目标基于论文计算实验配置生成并在同一规模参数下多样化结构特征如空间布局、容量-负载比等。(4)Gurobi 求解程序和参考解Gurobi 程序基于原文中提供的便于求解器直接求解的等价公式化实现并将解统一投影回原决策变量空间。参考解为在1小时单线程预算内运行该程序得到最优解或最好可行解。(5)可行性检查器一份独立运行的 Python 校验器核查原始优化问题中的所有硬约束、变量定义域与界限。3. 两层质量验证(1)自动交叉验证。将每个任务的 Gurobi 参考解送入对应的可行性检查器复核若判定参考解不可行即触发修复回路依次排查并修复所有关联的构建环节直至两端结果一致。(2)多轮专家审核。15 名 OR 专家针对每个任务进行了为期三周的多轮迭代审核重点核查数学模型与源论文的一致性、问题描述的完备性、Gurobi 实现与数学模型的对应关系以及可行性检查器是否逐一校验原始问题约束。4. Hard 子集为聚焦商用求解器性能饱和的难题研究团队基于以下三项准则从 180 个任务中遴选出 50 个组成 Hard 子集(i) 任务隶属于具有组合爆炸性质的经典 NP-hard 问题族如 lot-sizing、图优化、调度等(ii) 实例规模显著大于整体中位水平且约束之间高度耦合(iii) Gurobi 在 1 小时单线程预算内未能证明最优。任务须在 (i) 或 (ii) 上提供充分的结构性证据并经 (iii) 验证其在求解器层面确已饱和方纳入 Hard 子集。经上述流程后保留的 180 个任务其 Gurobi 参考解均能通过对应的可行性检查器优化问题描述也足以让模型独立推断潜在的优化结构并生成可执行算法。FrontierOR 的关键贡献维度表 1 对 FrontierOR 与近期 LLM-for-optimization 的基准集进行了在端到端生成End-to-End、问题数量#Problems、文献溯源性Lit.-Grounded、自然语言输入NL input、大规模问题实例Large Instance、求解器基线Solver Baseline、评测协议Eval.Protocal上的多维度比较。FrontierOR 的关键贡献维度可总结为以下 3 点1.首个以 OR 文献为题源的基准。任务全部源自高质量的运筹学期刊论文并经研究团队多轮专家审核提取的任务内容。相比从课本教材提取的简单题或企业内部非公开题文献来源提供了可追溯、可同行验证、且天然具备算法工程价值的题源。2.工业级规模与多样性。任务覆盖 5 类优化范式MIP / MINLP / DRO 等、9 类问题类别路径、调度、选址、装箱、网络设计等以及数十个应用领域交通、能源、供应链、医疗等。大实例上一个典型任务约含4 万决策变量、1.8 万约束商用求解器 Gurobi 12单线程在 1 小时预算内无法证明 46.3% 大实例的最优性。换言之FrontierOR 的大实例已超出商用求解器的可靠求解范围模型必须主动设计分解、启发式或混合等算法策略才能应对。3.以 Gurobi 为基线的质量-效率双目标评测协议。每个任务配备一份经专家审核的 Gurobi 参考实现与独立运行的可行性检查器。FrontierOR 围绕解质量与求解效率两个核心目标设计了一套与 Gurobi 参考对照的评分指标。LLM 生成的程序先在小实例上做可行性与质量预筛通过后在大实例上逐项与 Gurobi 参考对照评分。这一切分保证被评测的能力是从自然语言读懂问题 → 自主选择求解方法 → 生成可执行算法的端到端能力而非对参考解或参考模型的拟合。评测流程小实例预筛大实例上评估质量与速度1. 两段式流程如图 2模型生成程序后先在小实例规模约几十个变量上做可行性与质量预筛若程序超时、产生不可行解、或与 Gurobi 在小实例上的 gap 超过 10%则不进入大实例评测由此避免显然失败的程序在大实例上消耗计算资源。通过预筛的程序在每个任务的 5 个大规模实例上分别运行每项指标取达标的 (任务, 大实例) 对占总数的比例。图 2 FrontierOR 评测流程2. 四项评测指标Execution rate可执行率生成程序能否完整执行且无执行报错Feasibility可行性在大实例时间预算内能否给出满足所有硬约束的解Solution quality解质量目标值与 Gurobi 参考解的相对差距是否不超过 1%Quality-Time Efficiency, QTE质效综合目标值与 Gurobi 参考解的相对差距不超过 1%且求解时间不超过 Gurobi 耗时。其中QTE 是 FrontierOR 的核心指标一段程序只有在解质量和求解效率两个维度上同时达标才计为成功单一维度达标不予赋分3. 两类评测范式One-shot模型从零生成一份完整算法程序允许若干次基于执行错误的自调试但不基于评测反馈迭代改写算法。被评测模型包括三个前沿模型Claude Opus 4.6Anthropic、GPT-5.3-CodexOpenAI、Gemini 3.1 Pro PreviewGoogle DeepMind和四个其他主流模型DeepSeek-R1、Grok-4.20xAI、Qwen3-Coder-PlusAlibaba、LLaMA-4-MaverickMetaSelf-evolve以 GPT-5.3-Codex 为骨干在三种代表性测试时自演进框架下迭代改写程序OpenEvolveAlphaEvolve 风格的 MAP-Elites 演化、EoH思维与代码联合演化、CORAL多智能体共享记忆协作。所有框架统一限制 30 次候选并从同一份由 GPT-5.3-Codex 单次生成的种子程序出发以保证差异来自搜索机制本身。主要结果LLM 能否设计出能与 Gurobi 抗衡的高效算法1. One-shot 评测可执行性接近上限解质量和求解效率仍是瓶颈由表 1 可以观察到三个核心规律1对最强模型而言可执行性已不是主要瓶颈。 GPT-5.3-Codex 在 Full全集 上的 Execution rate 达到 0.98Gemini 3.1 Pro 与 Claude Opus 4.6 也均为 0.93但它们的 Feasibility 与 Solution quality 仍显著更低。这表明核心难点不在于生成可执行代码而在于让算法在大实例上仍保持有效。2前沿模型在Full全集与Hard子集上均明显优于其他主流模型。 FrontierOR全集上前沿模型的 Feasibility 分数集中在 0.60–0.62其他主流模型仅 0.18–0.42Hard子集上前沿模型的 Feasibility 区间下移至 0.49–0.64其他主流模型则跌至 0.13–0.37——前沿与其他主流模型之间始终存在清晰的能力分层。3Hard 子集进一步凸显模型之间的算法能力差距。 全集上三个前沿模型的 QTE 落在 0.25 至 0.31 这一窄幅区间几乎并列而 Hard 子集上 Claude Opus 4.6 仍维持 0.32 的 QTEGPT-5.3-Codex 却跌至 0.18二者差距拉至近 2 倍。可见 Hard 子集是前沿模型真正的能力分水岭。图3 求解方法分布左与失败模式分解右2. 求解方法选择上的模型分化将每段生成程序归入 5 类求解方法家族纯求解器调用monolithic solver call、分解decomposition、构造性启发式constructive heuristic、局部搜索-元启发式local search / metaheuristic、数学规划-启发式混合matheuristic。图3揭示了LLaMA-4-Maverick约99%的程序为纯求解器调用Claude Opus 4.6的分布最均衡37% 纯求解器、27% 局部搜索 / 元启发式、27% 数学规划-启发式混合前沿模型显著更频繁地采用非纯求解器调用方法而这类方法在 QTE指标上整体更优这致使求解方法多样性本身构成一种竞争力。3. 失败模式随模型能力发生转移较弱模型主要在数学模型设计、约束规范、I/O schema 三个层面出错较强模型尤其是 Claude Opus 4.6数学模型层的错误显著更少但启发式搜索的深度与质量成为新的瓶颈。换言之随模型能力提升失败的发生环节正在从前期建模向后期搜索系统性后移。测试时自演进方法QTE 最大提升约 233%研究团队从 Hard 子集中遴选最难的 40% 任务构成 self-evolve 测试集让 OpenEvolve、EoH、CORAL 各运行 30 次候选并以最佳结果作为终态。结果如表 3。在三种自演进框架下取得的最优候选程序在每个指标上都显著超越单次生成程序QTE 由 0.15 提升至 0.50意味着在最难的任务上约半数大实例已可被 LLM 生成的算法在质量与时间上同时达标。CORAL 借助多智能体共享记忆机制取得最稳定的提升OpenEvolve 紧随其后EOH的演化性能波动较大、性能回退频繁。图4 三种自演进框架的质量速度演化轨迹左与 Gurobi 的相对 gap右相对速度优势三个框架在质量效率二维演化轨迹上的差异。 图 4 揭示一个稳定的二维特征速度维度往往在前 5 次尝试内即可突破 Gurobi 基线而解质量维度难度显著更高仅 CORAL 在第 16 次之后才稳定越过。这与 OR 工程师的实践经验一致——让算法在大实例上跑得快于求解器并不困难采用轻量构造性启发式即可难在又快的同时仍能达到接近全局最优的解质量。总结与展望FrontierOR 填补了 LLM-for-OR 评估体系中长期缺失的一环对优化算法工程能力的系统化、可量化度量。其核心结论可概括如下单次生成能力上限有限 即使最强的前沿模型单次生成的算法程序也只在 31% 的数据集实例上做到求解时间快于 Gurobi、且目标值与 Gurobi 参考解的相对差距不超过 1%。测试时自演进可显著提升但仍未饱和 引入测试时演化框架进行多轮迭代后最难子集上同时满足上述质量与速度条件的实例比例可提升至50%但仍有相当一部分最难任务尚未得到有效求解。求解方法选择上的模型分化 弱模型几乎只生成纯求解器调用强模型才会主动采用分解、邻域搜索、数学规划-启发式混合等高级求解方法。失败模式随能力分层迁移 较弱模型主要在建模、约束规范、I/O 接口层面出错较强模型则更多受限于启发式搜索的质量。LLM-for-OR 的研究重心正从自然语言到数学公式化与求解器接口生成逐步过渡到面向工业规模的算法设计。FrontierOR 为大模型在运筹优化算法工程维度的能力刻画出第一张系统化地图同时也指明了下一代 LLM-for-OR 系统真正需要突破的瓶颈所在。因此未来值得探索的方向可能在于一方面构建结构化的OR 算法设计技能库skill library让智能体能够根据问题的结构特征与实例规模自动检索并组合合适的算法模板从而提升算法设计的准确率与性能另一方面发展更高效的自演化算法设计系统让 agent 具备对大规模实例评测预算的自主调度能力在搜索过程中主动识别性能停滞与回退从而在有限预算下获得更稳定的提升轨迹。