来源：市场资讯
（来源：杨仔 运筹OR帷幄）
摘要
供应链优化系统通常以混合整数规划为计算内核。模型能够给出成本较低且满足业务约束的方案，但规划人员仍需理解某项决策为何产生，并反复分析供应商变化、路线中断或需求调整后的结果。完成一次这样的分析，往往需要工程人员修改模型代码、重新运行求解器，再把输出整理成业务人员可以理解的说明。
Li 等人提出的 OptiGuide 将大语言模型接入已有优化系统。用户用自然语言提出假设性问题，Coder 将问题转换为可执行的 Python 代码，Safeguard 检查代码，Gurobi 在新约束下重新求解，Interpreter 再把数值结果写成自然语言。大模型负责语言、代码和解释之间的转换，最优解仍由组合优化求解器计算。在生成约束与业务问题一致的前提下，解的可行性和目标值由优化模型与求解器确定，不依赖语言模型的数值推理能力。
论文在设施选址、多商品网络流、人员分配、旅行商和咖啡配送五类问题上建立了问答基准。GPT-4 在分布内测试中的最高集合准确率为 ，在分布外随机示例设置下达到 。作者还将该框架接入微软 Azure 的服务器履约系统。该系统的输入数据约为 ，涉及数百个数据中心，并由 Gurobi 每小时重新优化一次。论文报告的初步分布内准确率超过 。
引言
供应链中的采购、运输和产能分配通常可以写成混合整数规划。设连续决策为 ，离散决策为 ，一个简化模型为
求解器返回最优方案 和目标值 。但业务人员提出的问题很少停留在“最优值是多少”。更常见的问法是，若停止使用某个供应商，成本会增加多少。若某个数据中心必须提前交付，现有产能是否足够。若一条运输路线关闭，哪些订单会被重新分配。这些问题都要求在原模型上增加或修改约束，然后再次求解。
设原可行域为 ，用户问题 对应一组附加约束 。问题的数学含义可以写为
其中 汇总所有连续变量和整数变量。规划人员关心的通常是新旧方案的差值
以及决策变量 的变化。传统流程中的困难并不完全来自求解。业务语言如何准确落到变量、索引和约束上，才是反复占用工程时间的环节。
OptiGuide 的出发点由此确定。它不让大模型直接猜测 ，而是让大模型生成模型增量，再调用原有求解器计算。论文给出了一套由 Coder、Safeguard 和 Interpreter 组成的交互架构，同时构造了可重复的问答基准。真实案例来自 Azure 服务器供应链，说明这种接口可以接入已经运行的大规模优化系统。公开仓库保留了论文的 what-if 实现、基准问题和咖啡配送示例。
方法
OptiGuide 需要一个已经建立并可以运行的优化模型。设模型源代码为 ，变量与辅助函数说明为 ，上下文示例为 ，原始求解日志为 。Coder 接收用户问题 后生成代码片段
其中 表示大语言模型。代码不会替换整个应用，而是插入预先指定的位置。论文开源实现分别保留数据代码和约束代码的插入标记，以提示模型围绕已有变量和优化对象进行修改。代码能否安全执行仍由后续检查决定。
若用户要求禁止供应商 向烘焙厂 发货，语言模型生成的核心语句相当于
将代码片段并入原模型记为 ，求解过程写为
包含新的目标值、变量取值和运行日志。Interpreter 根据问题、新结果和基准结果生成回答
这两个语言模型调用承担不同任务。Coder 需要生成可以执行的约束代码，Interpreter 只整理已经计算出的结果。把二者分开后，最终说明中的成本变化可以直接追溯到求解器输出。
Safeguard 位于代码生成与执行之间。它根据原始代码判断新片段是否包含危险操作。通过检查后，系统才会插入并执行代码。若出现语法错误、运行异常或超时，错误信息会返回给 Coder。论文实验允许最多三次修正。这个机制能排除一部分明显失败，却不能证明代码在业务语义上必然正确。一个能够正常运行的约束仍可能误解变量含义，因此应用侧的变量说明、示例和允许调用的辅助函数十分重要。
论文用咖啡配送说明整个过程。设供应商集合为 ，烘焙厂集合为 ，咖啡店集合为 。 表示供应商 运往烘焙厂 的咖啡豆数量， 和 分别表示浅烘焙和深烘焙咖啡的配送量。三个变量均取非负整数。设供应商到烘焙厂的运输成本为 ，两类烘焙成本为 和 ，烘焙厂到咖啡店的运输成本为 。目标函数为
每座烘焙厂满足流量守恒
供应商的发货量不能超过产能
两类产品还需满足各咖啡店的需求 和
在这个模型中，“停止某条供应路线”只需增加一个等式约束。若问题改为“咖啡店 的浅烘焙需求提高 ”，相应约束可以写成
语言模型完成的是从句子到上述约束的编译。成本最小化、约束传播和整数变量搜索仍交给 Gurobi。
图 1 为论文中的系统架构。应用侧保存求解器、数据库、辅助函数和文档。专有数据可以停留在本地应用中，语言模型主要接收源代码结构、必要说明和执行结果。不过，能否做到严格的数据隔离仍取决于实际部署时向模型发送了哪些提示内容，框架本身并不自动消除所有隐私风险。
Azure 案例中的决策包括服务器供应商、部署时间和数据中心内的放置位置。其目标可以概括为
这里的三个可行域分别表示供应商与数据中心容量、硬件兼容关系和位置偏好。OptiGuide 读取已有模型的对象与结果，对用户指定的情景增加约束并重新计算。它因此更接近优化系统的自然语言操作层，而不是一个从零建立供应链模型的通用智能体。
实验结果
论文选取五类问题，包括设施选址、多商品网络流、人员分配、旅行商和咖啡配送。每类问题先用模板生成问题及其标准代码，再由 GPT 改写问法，以减少固定句式带来的偏差。分布内测试从同一问题集合中选择上下文示例，分布外测试则从其他问题集合中选择示例。示例可以随机抽取，也可以根据文本嵌入选择近邻。
每个场景重复运行 次，每次包含不少于 个问题集合，每个集合通常含 至 个问题。只有当一个集合中的所有问题均回答正确时，该集合才计为成功。设场景数为 ，场景 的集合数为 ，成功指示变量为 ，论文采用的准确率为
该指标比逐题准确率严格。某个集合中只要有一道题失败，整个集合的得分就为零。论文表 1 的平均结果如下。
示例数
模型
分布内随机
分布内近邻
分布外随机
分布外近邻
0
text-davinci-003
0.32
0
GPT-4
0.59
1
text-davinci-003
0.78
0.39
0.44
1
GPT-4
0.85
0.90
0.66
3
text-davinci-003
0.90
0.92
0.49
0.44
3
GPT-4
0.90
0.92
0.74
0.69
5
text-davinci-003
0.93
0.52
0.48
5
GPT-4
0.92
0.93
0.78
0.73
10
text-davinci-003
0.92
0.93
0.67
0.61
10
GPT-4
0.93
0.84
0.80
注：无上下文示例时不存在随机选择与近邻选择的差别，表中为便于比较重复列出同一结果。
GPT-4 在零样本条件下达到 ，高于 text-davinci-003 的 。加入示例后，两种模型的分布内结果很快接近 。差距主要出现在分布外问题。使用 个随机示例时，GPT-4 的准确率为 ，text-davinci-003 为 。近邻选择在分布内略有帮助，但在示例数大于 的分布外实验中反而低于随机选择。论文给出的解释是，随机样本具有更高的结构多样性，近邻检索容易使提示过度集中在相似问法上。
真实部署部分更能说明框架的使用边界。Azure 的服务器履约模型约有 输入数据，覆盖数百个数据中心，并按小时求解。规划人员提出的内容包括资源是否可用、某项供应商或位置决策为何产生、跨区域运输情况以及约束变化后的成本。论文称，部署 OptiGuide 以前，一个假设性问题可能需要三名以上运营人员协调，再由一名值班工程师检查计划输出。接入系统后的初步分布内准确率超过 。
这个结果不能理解为大模型已经独立解决了大规模供应链优化。论文仍依赖成熟的数学模型、Gurobi、应用文档和人工编写的辅助接口。用户问题若过于含糊，或代码虽然可运行却错误理解了业务语义，系统仍会给出错误回答。分布外准确率也明显低于分布内结果。OptiGuide 的实际价值在于缩短已有优化系统的情景分析链路，让规划人员能够直接提出约束变化，再由求解器给出可核查的数量结果。
参考文献 [1] B. Li, K. Mellou, B. Zhang, J. Pathuri, and I. Menache, “Large Language Models for Supply Chain Optimization,” arXiv preprint arXiv:2307.03875, 2023.
代码：[microsoft/OptiGuide](https://github.com/microsoft/OptiGuide)
热门跟贴