图片：METAL
摘要
- 谷歌研究院于9月18日在 GitHub 上公开了中程物流实例生成器 MilleMiglia。
- 中程环节中货物要多次换乘车辆，因此现有的车辆路径问题求解器无法直接使用。
- 该工作是与布雷西亚大学、巴黎高科路桥学校的合作，并且专用求解器和 API 也在开发中。
物流研究此前无法触及的环节，其数据以开源形式出现了。谷歌研究院于9月18日公开了 MilleMiglia，这是一个生成模拟中程物流网络问题的开源工具。这篇文章由广告与商务部门软件工程师 Aymane Lotfi 和谷歌研究院软件工程师 Thibaut Cuvelier 共同撰写，文中表示源代码与文档已发布在 GitHub 上。
中程指的是货物在各区域配送中心之间移动的环节。文章写道，这一环节承担了旅程中最长的距离，占整体成本的很大一部分，并决定货物到达时是新鲜还是变质。即便如此，研究仍集中在从生产者到集货点的首程，以及送往消费者的末程。
原因在于数据。文章写道"大多数物流公司把自身的网络结构和需求量视为高度敏感的专有信息"。没有公开的高质量数据，学界的进展因此受阻。
问题的形态也不同。在首程和末程中，一件货物从起点到终点始终装在同一辆车上，优化的核心是决定哪辆车承担哪些货物、按什么顺序停靠。而在中程，一件货物要换乘多辆车穿越大陆规模的网络，有时在出发一周后才抵达。文章写道"中程的运作方式像一场接力赛"。
换乘带来的是同步问题。在中转配送中心，货物被卸下、按目的地分拣、与其他货物合并，然后装上下一辆车。如果没有在特定时间窗内到达以赶上预定的出港卡车，它就要在中心里等到下一个周期，延误随之大幅增加。
文章以一个问题开篇：一块荷兰点心如何能在次日送达700公里外的家中，答案归功于物流优化。随后举的例子是从荷兰格罗宁根到法国凡尔赛的路线。货物先汇集到乌得勒支的区域中心，当天前往安特卫普，因为最近一班开往巴黎的卡车已满，第二天搭上第二辆卡车，夜间抵达巴黎，次日进入末程配送。一件货物的行程被拆分到三天完成。
现有工具解决不了这个问题。谷歌把它建模为时空图上的多商品流问题，其中节点代表特定时间区间内的特定配送中心，弧代表车辆的移动或货物在中心的滞留。固定时刻表、中心每小时的分拣吞吐上限，以及一辆车的到达构成另一辆车出发前提的同步关系，都是难以放松的约束，因此文章写道"现有的车辆路径问题求解器无法适用于中程"。
生成器所把握的是真实性与保密之间的平衡。配送中心用引力模型或空间聚类布置，以反映真实的人口与产业密度；需求则以符合现实货量与重量分布的起讫点对生成。车辆班次也不是节点之间的随意连接，而是连接两个大型中心，或一个大型中心与其邻近的小型中心。这些分布是在业界公开信息与非公开提供的数据之间插值得到的。
实现采用 C++，序列化使用 Protocol Buffers。一个实例装在一个文件里，因此用其他语言编写的求解器也能直接读取。车辆路径问题一侧为容量或时间窗等条件分别设置变体，而这一格式把固定班次、吞吐上限与同步前提全部纳入同一种文件格式。
METAL 读到的这篇文章还列出了将要提供的实例范围。从用于检验精确算法的学界玩具问题规模，到需要高级启发式方法的大陆规模工业问题，中间规模也包含在内。文章还为生成用于训练机器学习算法的大规模数据集留出了空间。
这项工作是谷歌与布雷西亚大学、巴黎高科路桥学校的学术伙伴之间的合作。谷歌表示正在开发专门面向中程运营问题的求解器与 API，并称这是为中程建立标准化基准套件的第一步，相当于车辆路径领域的 CVRPLIB。团队还写道，希望发起一项挑战赛以吸引学界与产业界的求解器开发者。
METAL 曾报道过缓解复杂 AI 搜索推理瓶颈的 R4T，也报道过由教师自己制作的学习互动内容库。三者指向同一处：不是把模型做得更大，而是把问题改造成可以处理的形态。供应链优化的下一步进展，如今更可能来自一套公开的问题集，而不是更大的模型。
评论