大数跨境

如果计划员可以和优化引擎对话,决策会发生什么改变

如果计划员可以和优化引擎对话,决策会发生什么改变 闻道-供应链思维
2026-07-20
4
导读:优化算法负责给出那个唯一正确的答案,而这一整套解耦协同的架构,负责让人在按下确认键之前,真正理解、也真正敢于相信这个答案。这才是AI与算法结合真正该有的样子,不是替代人类决策,而是让决策第一次变得可以

在2026年Edelman奖,两家科技公司给出了未来供应链优化同样的方向:AI+OR(英伟达走上2026 Edelman奖讲台:OR + AI才是计划的终极答案

每天深夜,微软的供应链系统都要处理一项极其复杂的任务:将数千条云硬件需求,与分布在全球仓库中的数万台机柜相匹配,再安排这些设备进入数百座数据中心。每一次分配,都要同时考虑电力、空间和上线时间


优化算法离不了人的价值判断

2019年,微软开发了智能履约引擎,摆脱了用人工完成上千次分配判断。系统使用混合整数线性规划,同时计算“用哪批硬件、发往哪里、何时上线”这几个变量。
它的难点不在算法本身,而在算法开始运行之前的那一步:如何把业务团队心里那些说不清道不明的取舍偏好,翻译成机器能懂的约束条件。
有一个真实的场景,现有资源总量足以覆盖所有需求,但其中一条低优先级需求受兼容性限制,只能使用眼下可以到货的某批设备;另一条高优先级需求则有多个可选批次。

如果先把这批设备分给受限需求,两条需求最终都能得到满足,但高优先级客户可能要多等半个多月。如果优先保证高优先级需求,另一条需求就可能面临更长的延期,甚至暂时找不到合适资源。

系统无法替业务团队定义什么更重要。它只能按照已经设定的目标和约束进行计算。因此,团队必须先明确,是更看重整体需求满足率,还是更看重高优先级客户的交付时间。写入模型的每一条约束,都会体现这种业务选择。

当需求量增长到原来的五倍。团队又通过图剪枝和库存池化缩小计算范围,使系统在更大规模下仍能稳定求解。

系统提高了排程效率,但也带来了一个新问题:计划员越来越依赖系统,却也对无法解释的结果越来越担心。

云硬件需求涉及的金额往往很高,有些决策达到百万美元级别。当计划员看到一个不符合直觉的结果时,他们自然会追问:“为什么系统为这条需求分配了供应商A的设备,而不是供应商B的设备?”

当有此类需求的时候通常需要提交工单,再由产品经理、工程师和业务负责人共同排查。得到答案平均需要两天半。

对于一个局势按天变化、单次决策可能涉及数百万美元的业务来说,这样的反馈速度显然太慢。


"让数学的归数学,让语言的归语言"

为了了解决这个问题,微软基于大模型的能力开发了OptiGuide,让计划员可以直接用自然语言向优化系统提问。

OptiGuide的核心原则很明确:大语言模型不负责求解优化问题,只负责在人类语言和优化模型之间进行转换。

计划员提出问题后,大语言模型先把自然语言转化为对现有模型的一项局部修改。例如,当计划员询问某条需求能否按期上线时,系统会在模型中增加一条“必须按期上线”的约束。

随后,原有的优化引擎重新计算。求解完成后,大语言模型再把结果整理成计划员能够理解的说明。

在这个架构中,大语言模型负责理解问题和组织语言,经过验证的优化引擎负责计算。两者职责分开后,大模型不会直接生成分配结果,也降低了其编造决策依据的风险。

案例中有这样一次演示:一条需求预计将延迟18天,计划员询问能否让它按时上线。系统随即重新求解。

几秒钟后,OptiGuide给出结果:可以按时上线,但整体运营成本将上升1.76%。要做到这一点,系统需要更换这条需求所使用的供应资源。调整之后,大约七十条需求会出现小幅延迟,另有十六条需求会提前上线。

计划员由此看到的,不再只是“可以”或“不可以”。系统同时说明了改变这一条件需要付出多少成本,以及会影响哪些其他需求。

优化引擎负责计算不同方案的结果,OptiGuide则把方案之间的取舍解释清楚。


分工、制衡、自我纠错的智能化团队

如果说“分工”是这套系统的设计原则,那么真正把它落实到产品中的,是一组彼此配合、相互制约的AI Agent。

微软工程团队借助开源框架AutoGen,将原本超过430行的控制流程,重构为不到100行的模块化协作网络。系统中的三个主要角色,分别负责编写代码、安全审查和结果解释。

第一个Agnet是编写者。

业务人员的问题首先交给它处理。它负责把自然语言转换为具体的代码片段或参数变化,但修改范围从一开始就受到限制。系统只允许它在预先标记的区域增加约束或调整数据,不能改动目标函数。

第二个Agnet是安全审查者。

新生成的代码不会直接执行,而是先经过安全检查。审查内容包括恶意指令、越权访问、未经授权的数据读取,以及可能泄露本地运行环境信息的操作。

代码通过审查后,才能进入执行队列。如果被判定存在风险,流程会立即中止,并向用户返回错误说明。

第三个Agnet是解释器。

求解器完成计算后,解释器会结合用户最初的问题,对技术结果进行说明。它需要回答的不是“目标函数值是多少”,而是“成本变化了多少”“瓶颈在哪里”“下一步可以如何调整”。

这套系统的可靠性,在模型无法求解时表现得更明显。

例如,新加入的一项业务约束可能导致模型无解。需求突然增长,而现有产能无论如何都无法满足,便是一个典型场景。

此时,系统不会直接退出。编写者员工,会调用求解器的高级诊断功能,找出彼此冲突的约束,并生成相应的诊断信息。这些信息随后被反馈给编写者。

编写者根据诊断结果调整约束或寻找替代方案,再次调用求解器。这个过程会持续到模型找到可行解,或者达到预设的重试上限。

由此形成了一个清晰的闭环:求解器提供事实依据,语言模型根据事实进行修正。


当算法可以被对话,决策会发生什么变化

当优化引擎可以通过自然语言进行交互,当“最优解”可以被不断追问,它的含义也会随之变化。

最优解不再是一个计算完成后便不容置疑的答案。它只是模型在一组既定目标、约束和假设下找到的最佳方案。只要其中一个条件发生变化,原来的结果就需要重新检验。

计划员每提出一个“如果”,实际上都在检查这个答案成立的边界:如果改变交付日期,结果是否仍然合理?如果提高某类客户的优先级,成本会增加多少?如果更换供应来源,又会影响哪些需求?

这才是对话式优化带来的重要变化。它没有把决策交给机器,也没有让算法自动获得权威。相反,它真正的把决策权还给了人,算法成为了最强助手。








【声明】内容源于网络
0
0
闻道-供应链思维
一个有态度的专业供应链公众号,坚持原创,不发软文
内容 125
粉丝 0
闻道-供应链思维 一个有态度的专业供应链公众号,坚持原创,不发软文
总阅读951
粉丝0
内容125