LLM在优化建模的现状与挑战过去两年LLM在「自然语言到数学模型」「自然语言到求解器代码」方面进步显著能读懂题目、写出MIP公式并调用求解器具备初步优化建模能力。然而在真正的工业规模问题上这远远不够。真正的难题并非将约束翻译成数学表达式而是设计一套能在大实例上高效运行的算法。即便MIP模型正确交给通用求解器后也可能在一小时内无法获得可证明的高质量解。因此现实中的OR工程师仍需编写分解算法等多种算法。FrontierOR面向大规模优化算法设计能力的评测基准近日来自麻省理工学院等机构的研究者提出了FrontierOR这是一个面向大规模优化算法设计能力的LLM评测基准。不同于传统只考察「能否建模」或「能否调用求解器」的benchmarkFrontierOR关注LLM能否像真正的OR研究者和工程师一样针对复杂问题结构设计出可扩展、高质量且高效率的算法。其核心问题是今天最强的大模型能否从真实问题出发自主设计有竞争力的高效算法能否像OR专家一样根据问题结构选择合适策略这项工作的意义在于将LLM - for - OR的评估重心从「会不会写模型」推进到「会不会设计算法」这是大模型走向真实工业决策系统必须跨越的门槛。研究背景已有不少基准关注LLM在优化问题中的建模能力但难以回答更贴近工业部署的问题模型能否在求解器性能饱和的大规模实例上主动创造更有效的算法路径在运筹优化实践中通用求解器只是起点真实问题常具有特殊结构优秀的算法工程师会利用这些结构求解。因此一个真正面向OR的大模型基准需满足题源真实、实例大、评测严格三个条件。FrontierOR正是在此背景下提出它将过去三十多年OR文献中经过同行评审的复杂问题转化为可自动评测的算法设计任务。研究方法FrontierOR的构造流程可概括为四步一是真实文献选题数据源覆盖1992–2025年间20余家OR期刊的180篇论文入选任务需问题定义清晰且体现专用算法相对通用求解器的工程价值二是标准化任务组件将每篇论文转化为自然语言问题描述、数学模型、Gurobi参考实现、参考解和独立可行性检查器三是两层质量验证先通过自动交叉验证检查Gurobi参考解与可行性检查器是否一致再由15名OR专家多轮审核核查模型、描述、代码与检查器的一致性四是Hard子集筛选从180个任务中选出50个更难任务聚焦组合爆炸、规模更大、约束更耦合且Gurobi在1小时预算内无法证明最优的场景。评测协议评测流程强调端到端能力。模型先根据自然语言任务生成完整算法程序程序先在小实例上进行可执行性、可行性和质量预筛若超时、不可行或与Gurobi的小实例gap超过10%则不进入大实例评测。通过预筛后程序将在每个任务的多个大规模实例上运行并与专家审核过的Gurobi参考解对照。Frontier OR使用四项指标Execution rate可执行率、Feasibility可行性、Solution quality解质量和Quality - Time EfficiencyQTE质效综合其中QTE最严格只有目标值与Gurobi参考解相对差距不超过1%或者超过Gurobi的解才算成功。实验结果One - shot方面在one - shot设置中模型需从零生成完整算法程序可有限自调试但不能根据评测反馈反复改写算法。结果显示最强模型的可执行性已很高如GPT - 5.3 - Codex在Full全集上的Execution rate达到0.98Gemini 3.1 Pro与Claude Opus 4.6也都达到0.93说明「代码能否跑起来」不再是主要瓶颈。但可执行不等于会解Feasibility、Solution quality和QTE仍显著低于Execution rate大模型写出形式完整的优化程序不难但要在工业级规模上保持可行、接近最优且比Gurobi更快仍困难。从整体分层看前沿模型在Full全集与Hard子集上都显著优于其他主流模型。Hard子集进一步拉开了前沿模型之间的算法能力差距成为「算法工程能力分水岭」。算法选择出现分化研究团队分析模型生成程序的求解方法分为纯求解器调用、分解、构造性启发式、局部搜索/元启发式和数学规划 - 启发式混合方法五类。较弱模型高度依赖纯求解器调用如LLaMA - 4 - Maverick约99%的程序是monolithic solver callClaude Opus 4.6的方法分布最均衡。非纯求解器方法在QTE指标上更有优势说明「方法多样性」是竞争力模型越能根据问题结构选择合适算法越有可能在大实例上兼顾质量与速度。失败模式迁移失败模式分析显示随着模型能力提升错误发生位置后移。较弱模型主要在前期环节出错较强模型在基础环节错误减少新瓶颈转向启发式搜索的深度与质量这与人类算法工程师的成长路径相似。因此FrontierOR能告诉我们「谁得分更高」和「能力瓶颈在哪里」对下一代LLM - for - OR系统设计很重要。自演化单次生成只是第一步现实中算法设计是迭代过程。FrontierOR评估了三种测试时自演化框架OpenEvolve、EoH和CORAL。实验选取Hard子集中最难的40%任务作为self - evolve测试集以GPT - 5.3 - Codex单次生成的程序作为初始种子每个框架限制30次候选程序以最终最佳结果作为终态。结果亮眼在三种自演化框架下最优候选程序各项指标均显著超越单次生成QTE从one - shot的0.15提升至最高0.50。其中CORAL凭借多智能体共享记忆机制取得最稳定提升QTE达到0.50OpenEvolve紧随其后QTE为0.49EoH有明显改进但性能波动大QTE为0.33。观察演化轨迹发现速度维度往往在前5次尝试内突破Gurobi基线解质量维度更困难。这表明LLM的自演化需记住历史失败、识别性能瓶颈、动态调整搜索方向并在速度与质量间做结构化权衡。未来应用FrontierOR的价值不仅在于给模型排榜更在于为下一代智能优化系统提供研发方向。若大模型能稳定读懂真实业务需求、识别优化结构、调用或组合合适算法技能并自我改进有机会成为工业决策系统中的「AI算法工程师」。在供应链、能源、交通与城市系统等场景中它可发挥重要作用。更进一步FrontierOR暗示了agentic optimization的未来形态LLM将成为算法设计智能体。展望未来可构建OR算法设计技能库将常见策略沉淀成可检索、可组合、可执行的技能模块发展更可靠的verifier/evaluator将执行反馈转化为设计方向提升自演化的预算调度能力学会合理安排评测推动LLM与传统优化器深度融合LLM负责发现结构与设计算法传统求解器负责局部精确优化与可信验证。总结来看FrontierOR为大模型的OR算法工程能力画出了系统化地图大模型已能写出部分有竞争力的优化算法但真正决定上限的是结构发现、搜索设计和自我进化能力。如果说前一阶段的LLM - for - OR研究回答的是「大模型会不会建模」那么FrontierOR开始追问更难更现实的问题大模型能不能成为真正的算法设计者