企业官网建设流程全解析

论文标题：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.25246

Github链接：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.6（Anthropic）、GPT-5.3-Codex（OpenAI）、Gemini 3.1 Pro Preview（Google DeepMind）和四个其他主流模型：DeepSeek-R1、Grok-4.20（xAI）、Qwen3-Coder-Plus（Alibaba）、LLaMA-4-Maverick（Meta）

• Self-evolve：以 GPT-5.3-Codex 为骨干，在三种代表性测试时自演进框架下迭代改写程序：OpenEvolve（AlphaEvolve 风格的 MAP-Elites 演化）、EoH（思维与代码联合演化）、CORAL（多智能体共享记忆协作）。所有框架统一限制 30 次候选，并从同一份由 GPT-5.3-Codex 单次生成的种子程序出发，以保证差异来自搜索机制本身。

主要结果：LLM 能否设计出能与 Gurobi 抗衡的高效算法

1. One-shot 评测：可执行性接近上限，解质量和求解效率仍是瓶颈

由表 1 可以观察到三个核心规律：

（1）对最强模型而言，可执行性已不是主要瓶颈。 GPT-5.3-Codex 在 Full全集 上的 Execution rate 达到 0.98，Gemini 3.1 Pro 与 Claude Opus 4.6 也均为 0.93，但它们的 Feasibility 与 Solution quality 仍显著更低。这表明核心难点不在于生成可执行代码，而在于让算法在大实例上仍保持有效。

（2）前沿模型在Full全集与Hard子集上均明显优于其他主流模型。 FrontierOR全集上前沿模型的 Feasibility 分数集中在 0.60–0.62，其他主流模型仅 0.18–0.42；Hard子集上前沿模型的 Feasibility 区间下移至 0.49–0.64，其他主流模型则跌至 0.13–0.37——前沿与其他主流模型之间始终存在清晰的能力分层。

（3）Hard 子集进一步凸显模型之间的算法能力差距。 全集上三个前沿模型的 QTE 落在 0.25 至 0.31 这一窄幅区间，几乎并列；而 Hard 子集上 Claude Opus 4.6 仍维持 0.32 的 QTE，GPT-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 具备对大规模实例评测预算的自主调度能力，在搜索过程中主动识别性能停滞与回退，从而在有限预算下获得更稳定的提升轨迹。