美团智能配送系统的运筹优化实战

即时配送业务是典型的 O2O 业务，线上和线下存在大量复杂的业务约束和多种多样的决策变量。美团智能配送系统负责订单和骑手的资源优化配置，致力于改善顾客体验、降低配送成本。作为美团智能配送系统最核心的技术之一，运筹优化是如何在各种业务场景落地的？本文整理自王圣尧老师在 ArchSummit 全球架构师峰会 上的演讲内容，以飨广大技术读者。

一、美团智能配送系统架构

美团配送是一个怎样的业务场景呢？下图里的这组数字是 2019 年 5 月份美团配送品牌发布时候的数据。作为服务三方客户的平台（包括商家、骑手、用户），目前我们每天完成的单量峰值已经远不止这个数字。

单独看这几个数字可能没有概念，但是如果告诉大家每年给骑手支付的工资是几百亿的量级，就知道在这样大规模的业务场景下，配送的智能化是多么重要。智能配送的核心是做资源的优化配置。

外卖配送是一个典型的 O2O 场景。既有线上的业务，也有线下的复杂运营。配送连接订单需求和运力供给。为了达到需求和供给的最好平衡，不仅要在线下运营商家、运营骑手，还要在线上将这些需求和运力供给做合理配置，目的是提高效率。配送效率最大化，才能带来良好的顾客体验、较低的配送成本。做资源优化配置的过程，实际上是有分层的。按我们的理解，可以分为三层：

• 基础层是结构优化，它直接决定了配送系统效率的上限。这种基础结构的优化，周期比较长，频率比较低，包括配送网络规划、运力结构规划等。
• 中间层是市场调节，相对来说是中短期的，主要通过定价或者营销手段，使供需达到一个相对理想的平衡状态。
• 再上层是实时匹配，通过调度做实时的资源最优匹配。 实时匹配的频率是最高的，决策的周期也是最短的。

针对智能配送的三层体系，配送算法团队也是这样运作的。图中右边三个子系统，对应三层，最底层是规划系统，中间层是定价系统，最上层是调度系统。同样非常重要的，还包括图中另外四个子系统，在配送过程中做精准的数据采集、感知、预估，为优化决策提供准确的参数输入，包括机器学习系统、IoT 和感知系统、LBS 系统，都是配送系统非常重要的环节，有大量复杂的机器学习问题。

二、实战业务项目

1. 智能区域规划

为了有助于快速理解配送业务的基本背景，首先分享智能区域规划项目中遇到的问题和解决方案。

配送连接的是商家、顾客、骑手三方，配送网络决定了这三方的连接关系。打开 App，哪些商家可以点餐，是由商家配送范围决定的。每个商家的配送范围不一样，看似是商家粒度的决策，但实际上直接影响每个 C 端用户得到的商流供给，这本身还是一个资源分配或者资源抢夺问题。商家配送范围智能化也是很有意思的组合优化问题，但是我们这里讲的是商家和骑手的连接关系。

在公司点外卖，为我服务的骑手是哪一批呢？又是怎么确定的呢？这些是由配送区域边界来决定的。配送区域边界指的是一些商家的集合所对应的范围。为什么要划分区域边界呢？从优化的角度来讲，对于一个确定问题，反而是约束条件越少，目标函数值更优的可能性越大。做优化的同学肯定都不喜欢约束条件，但是配送区域边界实际是给配送系统强加的约束。

在传统物流中，影响末端配送效率最关键的点其实是配送员对他所负责区域的熟悉程度。这也是为什么在传统物流领域，配送站或配送员，都会固定负责某几个小区的原因之一。因为越熟悉，配送效率越高。

即时配送场景也类似，每个骑手需要尽量固定去熟悉一片商家或者配送区域。同时，对于管理而言，站点的管理范围也是比较明确的。另外，如果有新商家上线，也很容易确定由哪个配送站来提供服务。所以，这个问题有很多运营管理诉求在里面。

区域规划这个项目的发起，是因为实际已经存在很多问题需要解决。有这样三类 case：

• 配送区域里的商家不聚合。这是一个典型站点，商家主要集中在左下角和右上角，造成骑手在区域里取餐、送餐时执行任务的地理位置非常分散，需要不停往返两个商圈，无效跑动非常多。
• 区域奇形怪状，空驶严重。之前在门店上线外卖平台的发展过程中，很多地方原本没有商家，后来上线的商家多了，就单独作为一个配送区域。这样的区域形状可能就会不规则，导致骑手很多时候在区域外面跑。而商家和骑手是有绑定关系的，骑手只能服务自己区域内的商家，因此骑手无法接到配送区域外的取餐任务，空驶率非常高。很多时候骑手出去送完餐之后，只能空着跑回来才可能接到新任务。
• 站点的大小不合理。图三这个站点，每天的单量只有一二百单。如果从骑手平均单量的角度去配置骑手的话，只能配置 3~4 个骑手。如果某一两个人突然有事要请假，可想而知，站点的配送体验一定会非常差的，运营管理很难。 反之，如果一个站点非常大，站长又不可能管得了那么多骑手。所以，需要给每个站点规划一个合理的单量规模。

既然存在这么多的问题，那么就很需要做区域规划项目。

优化的三要素是，目标、约束、决策变量。

第一点，首先要确定优化目标。在很多比较稳定或者传统的业务场景中，目标是非常确定的。在区域规划这个场景，怎么定义优化目标呢？首先要思考的是区域规划主要影响的是什么。从刚才几类问题的分析发现，影响的主要是骑手的顺路性、空驶率，也就是骑手平均为每一单付出的路程成本。所以，我们将问题的业务目标定为优化骑手的单均行驶距离。基于现有的大量区域和站点积累的数据，做大量的统计分析后，可以定义出这样几个指标： 商家聚合度、订单的聚合度、订单重心和商家重心的偏离程度。 数据分析结果说明，这几个指标和单均行驶距离的相关性很强。经过这一层的建模转化，问题明确为优化这三个指标。

第二点，需要梳理业务约束。在这方面，我们花费了比较多的时间和精力。比如：区域单量是有上限和下限的；区域之间不能有重合，不能有商家归多个区域负责；所有的 AOI 不能有遗漏，都要被某个区域覆盖到，不能出现商家没有站点服务。

最难的一个问题，其实是要求区域边界必须沿路网。起初我们很难理解，因为本质上区域规划只是对商家进行分类，它只是一个商家集合的概念，为什么要画出边界，还要求边界沿路网呢？其实刚才介绍过，区域边界是为了回答，如果有新商家上线，到底属于哪个站点。而且，从一线管理成本来讲，更习惯于哪条路以东、哪条路以南这样的表述方式，便于记忆和理解，提高管理效率。所以，就有了这样的诉求，我们希望区域边界是“便于理解”的。

目标和约束确定了之后，整体技术方案分成三部分：

• 首先，根据三个目标函数，确定商家最优集合。这一步反而比较简单，因为做运筹优化的同学可以很快速解决这样一个多目标组合优化问题。
• 后面的步骤比较难，怎么把区域边界画出来呢？为了解决这个问题，我们和美团地图团队合作。先利用路网信息，把城市切成若干互不重叠的多边形，然后根据计算几何，把一批商家对应的多边形拼成完整的区域边界。
• 最后，用美团自主研发的配送仿真系统，评测这样的区域规划对应的单均行驶距离和体验指标是否符合预期。因为一线直接变动的成本是很高的，这里仿真系统就起到了非常好的作用。

下面是一个实际案例，我们用算法把一个城市做了重新的区域规划。当然，这里必须要强调的是，在这个过程中，人工介入还是非常必要的。对于一些算法很难处理好的边角场景，需要人工微调，使整个规划方案更加合理。中间的图是算法规划的结果。试点后，城市整体的单均行驶距离下降了 5%，平均每一单骑手的行驶距离节省超过 100 米。可以想象一下，在这么庞大的单量规模下，每单平均减少 100 米，总节省的路程、节省的电瓶车电量，都是非常可观的数字。更重要的是，可以让骑手自己明显感觉到效率的提升。

2. 智能骑手排班

随着外卖配送的营业时间越来越长，衍生出这样一个项目。最早，外卖只服务午高峰到晚高峰，后来慢慢可以点夜宵、点早餐，到如今很多配送站点已经是 24 小时服务了。但是，骑手不可能全天 24 小时开工，劳动法对每天的工作时长也有规定。

另外，外卖配送场景的订单峰谷效应非常明显。上图是一个实际的进单曲线，全天 24 小时内，午晚高峰两个时段单量非常高，而闲时和夜宵相对来说单量又少一些。因此，没办法把一天 24 小时根据每个人的工作时长做平均切分，需要进行排班。

对于排班，有这样两类方案的选型问题。 很多业务的排班是基于人的维度，好处是配置的粒度非常精细，每个人的工作时段都是个性化的，可以考虑每个人的诉求。但是，在配送场景的缺点也显而易见。如果站长需要为每个人去规划工作时段，难度可想而知，也很难保证公平性。

我们最终选用的是按组排班的方式，把所有骑手分成几组，规定每个组的开工时段。然后大家可以按组轮岗，每个人对于每个班次都会轮到。

这个问题最大的挑战是，我们并不是在做一项业务工具，而是在设计算法。算法是要有优化目标的，排班的目标是什么呢？我们问站长，觉得怎么样的排班是好的，他只是说，要让需要用人的时候有人。但这不是算法语言，更不能变成模型语言。

我们首先做的是设计决策变量，决策变量并没有选用班次的起止时刻和结束时刻，那样做决策空间太大了。我们把时间做了离散化，以半小时为粒度。对于一天来讲，只有 48 个时间单元，决策空间大幅缩减。然后，目标定为运力需求满足订单量的时间单元最多。这是因为，并不能保证站点的人数在对应的进单曲线情况下可以满足每个单元的运力需求，所以，我们把业务约束转化为带惩罚的目标函数。这样还有一个好处，没必要知道站点的总人数是多少。

在建模层面，标准化和通用的模型才是好的。所以，我们把人数做了归一化，算法分配每个班次的骑手比例，但不分人数。最终只需要输入站点的总人数，就得到每个班次的人数。在算法决策的时候，不决策人数、只决策比例，这样也可以把单量进行归一化。每个时间单元的进单量除以每天峰值时间单元的单量，也变成了 0~1 之间的数字。这样就可以认为，如果某个时间单元内人数比例大于单量比例，那么叫作运力得到满足。这样，通过各种归一化，变成了一个通用的问题，而不需要对每种场景单独处理。

另外，这个问题有大量复杂的强约束，涉及各种管理的诉求、骑手的体验。约束有很多，比如每个工作时段尽量连续、每个工作时段持续的时间不过短、不同工作时段之间休息的时间不过短……有很多这样的业务约束，梳理之后我们发现，这个问题的约束太多了，求最优解甚至可行解的难度太大了。另外，站长在使用排班工具的时候，希望能马上给出系统排班方案，再快速做后续微调，因此对算法运行时间要求也很高。

综合考虑以上，我们最终基于约束条件根据启发式算法构造初始方案，再用局部搜索迭代优化。这样的方式，求解速度是毫秒级的，而且可以给出任意站点的排班方案。优化指标还不错，当然，不保证是最优解，只是可以接受的满意解。

这个算法也在自营场景做了落地应用，和那些排班经验丰富的站长相比，效果基本持平，一线的接受程度也比较高。最重要的是带来排班时间的节省，每次排班几分钟就搞定了，这样可以让站长有更多的时间去做其它管理工作。

3. 骑手路径规划

骑手的路径规划问题，不是路线规划，不是从 a 到 b 该走哪条路的问题。这个场景是，一个骑手身上有很多配送任务，这些配送任务有各种约束，怎样选择最优配送顺序去完成所有任务。这是一个 NP 难问题，当有 5 个订单、10 个任务点的时候，就已经有 11 万多条可能的顺序。而在高峰期的时候，骑手往往是背负不止 5 单的，甚至有时候一个骑手会同时有十几单，这时候可行的取送顺序就是天文数字了。

再看算法的应用场景，这是智能调度系统中最重要的一个环节。系统派单、系统改派，都依赖路径规划算法；在骑手端，给每个骑手推荐任务执行顺序；另外，用户点了外卖之后，美团会实时展示骑手当前任务还需要执行几分钟，给用户提供更多预估信息。这么多应用场景，共同的诉求是时效要求非常高，算法运行时间越短越好。

但是，算法仅仅是快就可以吗？并不是。因为这是派单、改派这些环节的核心模块，所以算法的优化求解能力也非常重要。如果路径规划算法不能给出较优路径，可想而知，上层的指派和改派很难做出好的决策。

所以，对这个问题做明确的梳理，核心的诉求是优化效果必须是稳定的好。不能这次的优化结果好，下次就不好；另外，运行时间一定要短。

在求解路径规划这类问题上，很多公司的技术团队，都经历过这样的阶段：起初，采用类似遗传算法的迭代搜索算法，但是随着业务的单量变大，发现算法耗时太慢，根本不可接受；然后，改为大规模邻域搜索算法，但算法依然有很强的随机性，因为没有随机性在就没办法得到比较好的解。而这种基于随机迭代的搜索策略，带来很强的不确定性，在问题规模大的场景会出现非常多的 bad case。另外，迭代搜索耗时太长了。主要的原因是，随机迭代算法是把组合优化问题当成一个单纯的 permutation 问题去求解，很少用到问题结构特征。这些算法，求解 TSP 时这样操作，求解 VRP 时也这样操作，求解 Scheduling 还是这样操作，这种类似“无脑”的方式很难有出色的优化效果。

所以在这个项目中，基本可以确定这样的技术路线。首先，只能做启发式定向搜索，不能在算法中加随机扰动。不能允许同样的输入在不同运行时刻给出不一样的优化结果。然后，不能用普通迭代搜索，必须把这个问题结构特性挖掘出来，做基于知识的定制化搜索。

说起来容易，怎么做呢？最重要的，是看待这个问题的视角。这里的路径规划问题，对应的经典问题模型，是开环 TSP 问题，或是开环 VRP 的变种么？可以是，也可以不是。我们做了一个有意思的建模转换，把它看作流水线调度问题：每个订单可以认为是 job；一个订单的两个任务取餐和送餐，可以认为是一个 job 的 operation；任意两个任务点之间的通行时间，可以认为是序列相关的准备时间；每一单承诺的送达时间，包括预订单和即时单，可以映射到流水线调度问题中的提前和拖期惩罚上。

做了这样的建模转换之后，流水线调度问题有大量的启发式算法可以借鉴。我们把一个经典的基于问题特征的启发式算法做了适当适配和改进，可以得到非常好的效果。相比于之前的算法，耗时下降 70%，优化效果还不错。因为这是一个确定性算法，所以运行多少次的结果都一样。但是，我们的算法运行一次，和其它算法运行 10 次的最优结果相比，优化效果是持平的。

4. 订单智能调度

配送调度场景，可以用数学语言描述。它不仅是一个业务问题，更是一个标准的组合优化问题，并且是一个马尔可夫决策过程。

并非对于某个时刻的一批订单做最优分配就够了，还需要考虑整个时间窗维度，每一次指派对后面的影响。每一次订单分配，都影响了每个骑手后续时段的位置分布和行进方向。如果骑手的分布和方向不适合未来的订单结构，相当于降低了后续调度时刻的最优性的天花板。所以，要考虑长周期的优化，而不是一个静态优化问题。

为了便于理解，我们还是先看某个调度时刻的静态优化问题。它不仅仅是一个算法问题，还需要我们对工程架构有非常深刻的理解。因为，在对问题输入数据进行拆解的时候，会发现算法的输入数据太庞大了。比如说，我们需要任意两个任务点的导航距离数据。

而我们面临的问题规模，前几年只是区域维度的调度粒度，一个商圈一分钟峰值 100 多单，匹配几百个骑手，但是这种乘积关系对应的数据已经非常大了。现在，由于有更多业务场景，比如跑腿和全城送，是会跨非常多的商圈，甚至跨越半个城市，所以只能做城市级的全局优化匹配。目前，调度系统处理的问题的峰值规模，是 1 万多单和几万名骑手的匹配。而算法允许的运行时间只有几秒钟，同时对内存的消耗也非常大。

另外，配送和网约车派单场景不太一样。打车的调度是做司机和乘客的匹配，本质是个二分图匹配问题，有多项式时间的最优算法：KM 算法。打车场景的难点在于，如何刻画每对匹配的权重。而配送场景还需要解决，对于没有多项式时间最优算法的情况下，如何在指数级的解空间，短时间得到优化解。如果认为每一单和每个骑手的匹配有不同的适应度，那么这个适应度并不是可线性叠加的。也就意味着多单对多人的匹配方案中，任意一种匹配都只能重新运算适应度，计算量可想而知。

总结一下，这个问题有三类挑战：

• 性能要求极高，要做到万单对万人的秒级求解。我们之前做了一些比较有意思的工作，比如基于历史最优指派的结果，用机器学习模型做剪枝。大量的历史数据，可以帮助我们节省很多无用的匹配方案评价。

• 动态性。 作为一个 MDP 问题，需要考虑动态优化场景，这涉及大量的预估环节。在只有当前未完成订单的情况下，骑手如何执行、每一单的完成时刻如何预估、未来时段会进哪些结构的订单、对业务指标和效率指标产生怎样的影响……可能会觉得这是一个典型的强化学习场景，但它的难点在于决策空间太大，甚至可以认为是无限大的。目前我们的思路，是通过其它的建模转换手段解决。

• 配送业务的随机因素多。比如商家的出餐时间，也许是很长时间内都无法解决的随机性。就连历史每一个已完成订单，商家出餐时间的真值都很难获得，因为人为点击的数据并不能保证准确和完整。商家出餐时刻不确定，这个随机因素是永远存在的，并且非常制约配送效率提升。另外，在顾客位置交付的时间也是不确定的。写字楼工作日的午高峰，上电梯、下电梯的时间，很难准确预估。当然，我们不断努力让预估变得更精准，但随机性还是永远存在。对于骑手，平台没法规定每个骑手的任务执行顺序。骑手在配送过程中是自由发挥的，所以骑手执行顺序的不确定性也是存在的。为了解决这些问题，我们想用鲁棒优化或是随机规划的思想。但是，如果基于随机场景采样的方式，运算量又会大幅增长。所以，需要进行基于学习的优化，优化不是单纯的机器学习模型，也不是单纯的启发式规则，优化算法是结合真实数据和算法设计者的经验，学习和演进而得。只有这样，才能在性能要求极高的业务场景下，快速的得到鲁棒的优化方案。

目前我们团队的研究方向，不仅包括运筹优化，还包括机器学习、强化学习、数据挖掘等领域。这里具有很多非常有挑战的业务场景，非常欢迎大家加入我们。

作者介绍：王圣尧博士，美团资深算法专家，毕业于清华大学自动化系，主要研究调度理论、运筹优化和系统仿真，中国仿真学会智能仿真优化与调度专委会委员，出版专著《分布估计调度算法》。目前负责美团配送智能调度算法团队的技术研发。

ArchSummit 全球架构师峰会（深圳站）2020 ，精选 100+ 国内外专家技术实践落地案例，目前正在邀请专家分享算法和业务结合的话题。此外还设置了 DDD、微服务架构、数据中台、大前端趋势等热门技术方向，7 折门票预售中，立减 2640 元！