Why AI Still Can’t Solve Your Real Mathematical Optimization Problem

若你尝试用AI构建真实业务问题的数学优化模型，可能已遇到同样的困境：AI在教科书案例中表现完美，但当你输入真实数据和真实问题时，它立刻崩溃。

这种差距并非偶然。这是设计使然，也是我开发ORPilot的原因。

人工智能驱动优化的承诺

运筹学（OR）数十年来默默推动着商业领域最具影响力的决策——从配送路线规划到工厂排产调度，从供应链设计到货物承运商分配。其数学理论已成熟，求解器性能卓越。瓶颈始终在于将业务问题转化为数学模型所需的人类专业知识。

大型语言模型（LLM）看似是完美解决方案。包括OptiMUS系列、OR-LLM在内的多项研究表明，最先进的LLM能够为定义明确的线性规划（LP）和混合整数规划（MIP）问题生成正确的求解器代码。结果令人印象深刻，演示效果极具说服力。

然而当你尝试将这些工具应用于真实问题时，裂痕立即显现。

现有工具的失效点

几乎所有面向运筹学的LLM工具都隐含一个假设：问题描述完整无歧义，以单个格式良好的提示符呈现，所有数据整齐内嵌其中。

这与现实世界相去甚远。

考虑供应链团队构建优化模型的真实场景：

1. 问题描述不完整且模糊。业务分析师会说“我们想最小化运输成本”，却忘记提及每个配送中心的吞吐量限制、某些路线不存在，或开设设施会产生一次性固定成本。这些遗漏并非疏忽——它们是分析师认为理所当然的假设，恰恰因此变得危险。过早建模的AI系统会产生技术上正确但实际错误的模型。
2. 数据规模超出提示符承载能力。真实供应链问题可能涉及数百个生产地、配送中心、客户，数千种产品及多周期需求。仅需求表就可能包含百万级条目。无法将其嵌入提示符，即使强行塞入，也会大幅增加幻觉风险。
3. 现有数据与模型需求不匹配。模型可能需要各地点间的距离矩阵，而你只有GPS坐标表；模型可能需要按产品和周期汇总的需求数据，而你只有逐笔订单交易记录。从原始数据计算衍生参数是重大工程步骤，现有LLM工具均未自动处理。
4. 可移植性和可复现性至关重要。若需在更新数据上重运行模型、切换开源求解器，或跨设备共享模型，除非工具生成通用持久化工件，否则一切归零。大多数工具仅输出特定求解器代码。

这些不是边缘案例，而是工业优化部署的标准条件。现有LLM工具为教科书世界而生，一旦脱离便显露出缺陷。

ORPilot的诞生

ORPilot是一个专为生产环境设计的开源AI代理。据我所知，它是首个明确针对工业优化混乱、大规模、数据密集特性的LLM工具。

大多数AI优化工具在获取问题描述后立即开始编写代码。ORPilot则采取不同策略：先提问。

这一设计选择优先理解而非速度，遵循核心原则：AI代理应像熟练人类运筹顾问般工作。

优秀顾问不会在客户会议开场就在白板上写数学模型。他们会提问、倾听、澄清模糊之处、确保数据准备就绪，直到完成这些步骤才会动笔。

ORPilot的流程通过五个依次连接的阶段体现这一严谨性。

第一阶段：访谈代理

访谈代理是入口。它接收初始业务问题描述（可能是模糊、不完整甚至自相矛盾的），并通过结构化对话填补空白。核心设计原则是：访谈完成前不启动建模。

该代理被训练识别当前描述的信息缺口，每轮提出至多一个问题（避免信息过载），并在目标函数、决策变量、约束条件和数据需求全部明确后终止。

实际对话示例：

ORPilot：“设施一旦启用，是否会在后续周期持续开放，还是允许关闭？”

ORPilot：“此模型处理单一产品类型还是多产品？”

ORPilot：“您提到的运输成本是指单位运费、单次运输费用（无论数量），还是其他形式？”

在结束访谈之前，代理会呈现一份包含目标函数、决策变量、约束条件、参数、索引的完整结构化摘要，并给予您机会在该摘要传递至下游环节前进行修正。这一机制旨在防范LLM-for-OR工具中最常见的失效模式：建模错误的问题。

第二阶段：数据收集代理

此阶段在现有大多数LLM-for-OR工具中并不存在，是ORPilot最重要的架构创新之一。

现有大多数LLM-for-OR工具假定数据已嵌入问题文本且规模小到足以放入提示符中。对于教科书案例这可行，但在现实场景中存在两大缺陷：其一，真实数据集规模过大（例如500客户、500产品、12周期的供应链问题需3,000,000条需求数据）；其二，将数据嵌入提示符会增加幻觉风险并浪费上下文窗口容量。

ORPilot的解决方案是彻底将数据与提示符分离。数据存储于CSV文件中，AI仅通过编写和执行代码访问数据。数据收集代理的核心任务是确定这些CSV文件的具体格式：

• 模型中存在的实体（集合）
• 各实体所需的属性（参数）
• 每个必要表格的精确架构：列名、类型、语义

代理会向您展示该规范并等待您以正确格式提交所有文件。在继续下一步前会验证数据完整性。

至关重要的是，代理具备灵活性：若缺少特定模型就绪数据（例如模型需要距离矩阵而您仅有GPS坐标），只需告知实际拥有的数据，代理会相应调整架构——将缺口传递给下一阶段处理。

第三阶段：参数计算代理

几乎所有现有LLM-for-OR工具都假设模型所需数值量直接存在于用户提供的数据中。而在实际运营研究问题中，这种情况几乎从未出现。两个典型示例：

• 车辆路径规划模型需要成对距离矩阵，用户仅有GPS坐标。欧氏或地理距离计算完全超出线性/混合整数规划的范畴。
• 多周期生产模型需要按周期汇总需求，用户却拥有逐行订单的交易账本。模型参数需从原始数据中进行求和聚合。

参数计算代理自动弥合这一鸿沟。它接收问题规范及原始CSV文件，执行以下步骤：

1. 识别无法直接从原始表读取的模型参数
2. 生成用于计算派生参数的Python脚本
3. 在沙盒环境中执行脚本
4. 将结果写入附加CSV文件，供建模阶段使用

这确保建模代理看到的数据已清洗、类型正确、索引恰当且模型就绪。实验表明，该步骤显著降低了代码生成失败率和重试次数。

另一个参数计算代理可发挥作用的常见场景是计算BigM值。在ORPilot的某些实验中，代理计算了约束连续运输变量与二进制设施启用决策所需的BigM值——这类派生参数若要求用户直接提供将极不切实际。

第四阶段：代码生成代理

当问题规范、原始数据及派生参数全部就绪后，代码生成代理将为您选定的后端（ORPilot目前支持Gurobi、CPLEX、PuLP、Pyomo、OR-Tools五种）生成完整的Python求解器脚本。

生成的代码会在沙盒环境中立即执行。若发生语法错误、运行时异常或求解器返回不可行/无界结果，完整错误信息及堆栈跟踪将连同先前生成的代码反馈给LLM。代理将在用户配置的最大重试次数内尝试修复。

实践中，多数失败可在一两次重试内解决。ORPilot重试循环高效的关键在于：上游阶段已完成核心工作——问题规范正确、数据模型就绪，代理仅需修正代码级错误而非重构整个模型结构。

第五阶段：报告代理

成功求解后，报告代理将数值结果转化为通俗易懂的语言，解释应开启哪些设施、采用何种路线、生产多少数量，使用原始业务问题的领域语言，供业务用户而非运筹学专家解读。

为何顺序至关重要

该流水线刻意采用串行设计。每个阶段均以前一阶段成功完成为前提。访谈必须结束后才能开始数据收集，数据验证通过后方可启动参数计算，参数就绪后才生成代码。

这种顺序设计能防范LLM-based OR工具中最常见的失效模式：模糊的问题描述在流水线中层层传播，最终生成语法正确却建模错误的目标函数。

规模化应用形态

我在几个运筹学（OR）问题上测试了ORPilot，其中一个问题是包含50个生产点、50个配送中心、500个客户、500种产品和12个周期的供应链网络设计问题。生成的模型包含超过970万个决策变量和96.3万个约束条件。ORPilot成功完成了从初始对话到数据收集、参数计算、代码生成及解决方案报告的完整流程，并通过Gurobi获得了最优解。您可以查看我的论文https://arxiv.org/abs/2605.02728，了解更多测试案例的结果。

入门指南

ORPilot现已开源：

GitHub: https://github.com/GuangruiXieVT/ORPilot 论文: https://arxiv.org/abs/2605.02728

安装仅需几分钟即可完成。ORPilot支持OpenAI、Anthropic、Google和DeepSeek作为大型语言模型（LLM）提供商，并兼容Gurobi、CPLEX、PuLP、Pyomo和OR-Tools等求解器后端。

在本系列的下一篇文章中，我们将深入探讨中间表示（IR）——这一与求解器无关的JSON工件使ORPilot的结果具备可复现性和跨后端便携性，无需再次调用LLM。敬请期待！