厦门的网站,织梦网站需要付费吗,网站淘宝推广怎么做,wordpress查询系统主题深入各个产业已经成为互联网目前的主攻方向#xff0c;线上和线下存在大量复杂的业务约束和多种多样的决策变量#xff0c;为运筹优化技术提供了用武之地。作为美团智能配送系统最核心的技术之一#xff0c;运筹优化是如何在美团各种业务场景中进行落地的呢#xff1f;本文… 深入各个产业已经成为互联网目前的主攻方向线上和线下存在大量复杂的业务约束和多种多样的决策变量为运筹优化技术提供了用武之地。作为美团智能配送系统最核心的技术之一运筹优化是如何在美团各种业务场景中进行落地的呢本文根据美团配送技术团队资深算法专家王圣尧在2019年ArchSummit全球架构师峰会北京站上的演讲内容整理而成。 美团智能配送系统架构 美团配送业务场景复杂单量规模大。下图这组数字是2019年5月美团配送品牌发布时的数据。 更直观的规模数字可能是美团每年给骑手支付的工资目前已经达到几百亿这个量级。所以在如此大规模的业务场景下配送智能化就变得非常重要而智能配送的核心就是做资源的优化配置。 外卖配送是一个典型的O2O场景。既有线上的业务也有线下的复杂运营。配送连接订单需求和运力供给。为了达到需求和供给的平衡不仅要在线下运营商家、运营骑手还要在线上将这些需求和运力供给做合理的配置其目的是提高整体的效率。只有将配送效率最大化才能带来良好的顾客体验实现较低的配送成本。而做资源优化配置的过程实际上是有分层的。根据我们的理解可以分为三层 基础层是结构优化它直接决定了配送系统效率的上限。这种基础结构的优化周期比较长频率比较低包括配送网络规划、运力结构规划等等。中间层是市场调节相对来说是中短期的主要通过定价或者营销手段使供需达到一个相对理想的平衡状态。再上层是实时匹配通过调度做实时的资源最优匹配。 实时匹配的频率是最高的决策的周期也最短。 根据智能配送的这三层体系配送算法团队也针对性地进行了运作。如上图所示右边三个子系统分别对应这三层体系最底层是规划系统中间层是定价系统最上层是调度系统。同样非常重要的还包括图中另外四个子系统在配送过程中做精准的数据采集、感知、预估为优化决策提供准确的参数输入包括机器学习系统、IoT 和感知系统、LBS系统这都是配送系统中非常重要的环节涉及大量复杂的机器学习问题。 而运筹优化则是调度系统、定价系统、规划系统的核心技术。接下来我们分享几个典型的运筹优化案例。 实战业务项目 智能区域规划 为了帮助大家快速理解配送业务的基本背景这里首先分享智能区域规划项目中经常遇到的问题及其解决方案。 配送连接的是商家、顾客、骑手三方配送网络决定了这三方的连接关系。当用户打开App查看哪些商家可以点餐这由商家配送范围决定。每个商家的配送范围不一样看似是商家粒度的决策但实际上直接影响每个C端用户得到的商流供给这本身也是一个资源分配或者资源抢夺问题。商家配送范围智能化也是一个组合优化问题但是我们这里讲的是商家和骑手的连接关系。 用户在美团点外卖为他服务的骑手是谁呢又是怎么确定的呢这些是由配送区域边界来决定的。配送区域边界指的是一些商家集合所对应的范围。为什么要划分区域边界呢从优化的角度来讲对于一个确定问题来说约束条件越少目标函数值更优的可能性就越大。做优化的同学肯定都不喜欢约束条件但是配送区域边界实际上就是给配送系统强加的约束。 在传统物流中影响末端配送效率最关键的点是配送员对他所负责区域的熟悉程度。这也是为什么在传统物流领域配送站或配送员都会固定负责某几个小区的原因之一。因为越熟悉配送效率就会越高。 即时配送场景也类似每个骑手需要尽量固定地去熟悉一片商家或者配送区域。同时对于管理而言站点的管理范围也比较明确。另外如果有新商家上线也很容易确定由哪个配送站来提供服务。所以这个问题有很多运营管理的诉求在其中。 当然区域规划项目的发起存在很多问题需要解决。主要包括以下三种情况 1. 配送区域里的商家不聚合。这是一个典型站点商家主要集中在左下角和右上角造成骑手在区域里取餐、送餐时执行任务的地理位置非常分散需要不停往返两个商圈无效跑动非常多。 2. 区域奇形怪状空驶严重。之前在门店上线外卖平台的发展过程中很多地方原本没有商家后来上线的商家多了就单独作为一个配送区域。这样的区域形状可能就会不规则导致骑手很多时候在区域外跑。 而商家和骑手都有绑定关系骑手只能服务自己区域内的商家因此骑手无法接到配送区域外的取餐任务空驶率非常高。很多时候骑手送完餐之后只能空跑回来才可能接到新任务。 3. 站点的大小不合理。图三这个站点每天的单量只有一二百单。如果从骑手平均单量的角度去配置骑手的话只能配置3~4个骑手。如果某一两个人突然有事要请假可想而知站点的配送体验一定会变得非常差运营管理难度会很高。 反之如果某一个站点变得非常大站长也不可能管得了那么多的骑手这也是一个问题。所以需要给每个站点规划一个合理的单量规模。 既然存在这么多的问题那么做区域规划项目就变得非常有必要。那么什么是好的区域规划方案基于统计分析的优化目标设定。 优化的三要素是目标、约束、决策变量。 第一点首先要确定优化目标。在很多比较稳定或者传统的业务场景中目标非常确定。而在区域规划这个场景中怎么定义优化目标呢首先我们要思考的是区域规划主要影响的是什么。从刚才几类问题的分析可以发现影响的主要是骑手的顺路性、空驶率也就是骑手平均为每一单付出的路程成本。所以我们将问题的业务目标定为优化骑手的单均行驶距离。基于现有的大量区域和站点积累的数据做大量的统计分析后可以定义出这样几个指标商家聚合度、订单的聚合度、订单重心和商家重心的偏离程度。数据分析结果说明这几个指标和单均行驶距离的相关性很强。经过这一层的建模转化问题明确为优化这三个指标。 第二点需要梳理业务约束。在这方面我们花费了大量的时间和精力。比如区域单量有上限和下限区域之间不能有重合不能有商家归多个区域负责所有的AOI不能有遗漏都要被某个区域覆盖到不能出现商家没有站点的服务。 基于业务场景的约束条件梳理 最难的一个问题其实是要求区域边界必须沿路网。起初我们很难理解因为本质上区域规划只是对商家进行分类它只是一个商家集合的概念为什么要画出边界还要求边界沿路网呢其实刚才介绍过区域边界是为了回答如果有新商家上线到底属于哪个站点的问题。而且从一线管理成本来讲更习惯于哪条路以东、哪条路以南这样的表述方式便于记忆和理解提高管理效率。所以就有了这样的诉求我们希望区域边界更“便于理解”。 在目标和约束条件确定了之后整体技术方案分成三部分 首先根据三个目标函数确定商家最优集合。这一步比较简单做运筹优化的同学都可以快速地解决这样一个多目标组合优化问题。后面的步骤比较难怎么把区域边界画出来呢为了解决这个问题配送团队和美团地图团队进行合作。先利用路网信息把城市切成若干互不重叠的多边形然后根据计算几何将一批商家对应的多边形拼成完整的区域边界。最后用美团自主研发的配送仿真系统评测这样的区域规划对应的单均行驶距离和体验指标是否符合预期。因为一线直接变动的成本非常高仿真系统就起到了非常好的作用。下面是一个实际案例我们用算法把一个城市做了重新的区域规划。当然这里必须要强调的是在这个过程中人工介入还是非常必要的。对于一些算法很难处理好的边角场景需要人工进行微调使整个规划方案更加合理。中间的图是算法规划的结果。经过试点后测试城市整体的单均行驶距离下降了5%平均每一单骑手的行驶距离节省超过100米。可以想象一下在这么庞大的单量规模下每单平均减少100米总节省的路程、节省的电瓶车电量都是一个非常可观的数字。更重要的是可以让骑手自己明显感觉到自己的效率得到了提升。 智能骑手排班 业务背景 这是随着外卖配送的营业时间越来越长而衍生出的一个项目。早期外卖只服务午高峰到晚高峰后来大家慢慢可以点夜宵、点早餐。到如今很多配送站点已经提供了24小时服务。但是骑手不可能全天24小时开工劳动法对每天的工作时长也有规定所以这一项目势在必行。 另外外卖配送场景的订单“峰谷效应”非常明显。上图是一个实际的进单曲线。可以看到全天24小时内午晚高峰两个时段单量非常高而闲时和夜宵相对来说单量又少一些。因此系统也没办法把一天24小时根据每个人的工作时长做平均切分也需要进行排班。 对于排班存在两类方案的选型问题。 很多业务的排班是基于人的维度好处是配置的粒度非常精细每个人的工作时段都是个性化的可以考虑到每个人的诉求。但是在配送场景的缺点也显而易见。如果站长需要为每个人去规划工作时段其难度可想而知也很难保证分配的公平性。 配送团队最终选用的是按组排班的方式把所有骑手分成几组规定每个组的开工时段。然后大家可以按组轮岗每个人的每个班次都会轮到。 这个问题最大的挑战是我们并不是在做一项业务工具而是在设计算法。而算法要有自己的优化目标那么排班的目标是什么呢如果你要问站长怎么样的排班是好的可能他只会说要让需要用人的时候有人。但这不是算法语言更不能变成模型语言。 为了解决这个问题首先要做设计决策变量决策变量并没有选用班次的起止时刻和结束时刻那样做的话决策空间太大。我们把时间做了离散化以半小时为粒度。对于一天来讲只有48个时间单元决策空间大幅缩减。然后目标定为运力需求满足订单量的时间单元最多。这是因为并不能保证站点的人数在对应的进单曲线情况下可以满足每个单元的运力需求。所以我们把业务约束转化为带惩罚的目标函数。这样做还有一个好处那就是没必要知道站点的总人数是多少。 在建模层面标准化和通用的模型才是最优选。所以我们把人数做了归一化算法分配每个班次的骑手比例但不分人数。最终只需要输入站点的总人数就得到每个班次的人数。在算法决策的时候不决策人数、只决策比例这样也可以把单量进行归一化。每个时间单元的进单量除以每天峰值时间单元的单量也变成了0~1之间的数字。这样就可以认为如果某个时间单元内人数比例大于单量比例那么叫作运力得到满足。这样通过各种归一化变成了一个通用的问题而不需要对每种场景单独处理。 另外这个问题涉及大量复杂的强约束涉及各种管理的诉求、骑手的体验。约束有很多比如每个工作时段尽量连续、每个工作时段持续的时间不过短、不同工作时段之间休息的时间不过短等等有很多这样的业务约束梳理之后可以发现这个问题的约束太多了求最优解甚至可行解的难度太大了。另外站长在使用排班工具的时候希望能马上给出系统排班方案再快速做后续微调因此对算法运行时间要求也比较高。 算法核心思想 综合考虑以上因素我们最终基于约束条件根据启发式算法构造初始方案再用局部搜索迭代优化。使用这样的方式求解速度能够达到毫秒级而且可以给出任意站点的排班方案。整体的优化指标还不错当然不保证是最优解只是可以接受的满意解。 落地应用效果 站点体验指标良好一线接受度高。排班时间节省2h/每站点每次这种算法也在自营场景做了落地应用跟那些排班经验丰富的站长相比效果基本持平一线的接受程度也比较高。最重要的是带来排班时间的节省每次排班几分钟就搞定了这样可以让站长有更多的时间去做其它的管理工作。 骑手路径规划 具体到骑手的路径规划问题不是简单的路线规划不是从a到b该走哪条路的问题。这个场景是一个骑手身上有很多配送任务这些配送任务存在各种约束怎样选择最优配送顺序去完成所有任务。这是一个NP难问题当有5个订单、10个任务点的时候就存在11万多条可能的顺序。而在高峰期的时候骑手往往背负的不止5单甚至有时候一个骑手会同时接到十几单这时候可行的取送顺序就变成了一个天文数字。 再看算法的应用场景这是智能调度系统中最为重要的一个环节。系统派单、系统改派都依赖路径规划算法。在骑手端给每个骑手推荐任务执行顺序。另外用户点了外卖之后美团会实时展示骑手当前任务还需要执行几分钟要给用户提供更多预估信息。这么多应用场景共同的诉求是对时效要求非常高算法运行时间要越短越好。 但是算法仅仅是快就可以吗并不是。因为这是派单、改派这些环节的核心模块所以算法的优化求解能力也非常重要。如果路径规划算法不能给出较优路径可想而知上层的指派和改派很难做出更好的决策。 所以对这个问题做明确的梳理核心的诉求是优化效果必须是稳定的好。不能这次的优化结果好下次就不好。另外运行时间一定要短。 在求解路径规划这类问题上很多公司的技术团队都经历过这样的阶段起初采用类似遗传算法的迭代搜索算法但是随着业务的单量变大发现算法耗时太慢根本不可接受。然后改为大规模邻域搜索算法但算法依然有很强的随机性因为没有随机性在就没办法得到比较好的解。而这种基于随机迭代的搜索策略带来很强的不确定性在问题规模大的场景会出现非常多的Bad Case。另外迭代搜索耗时太长了。主要的原因是随机迭代算法是把组合优化问题当成一个单纯的Permutation问题去求解很少用到问题结构特征。这些算法求解TSP时这样操作求解VRP时也这样操作求解Scheduling还是这样操作这种类似“无脑”的方式很难有出色的优化效果。 所以在这个项目中基本可以确定这样的技术路线。首先只能做启发式定向搜索不能在算法中加随机扰动。不能允许同样的输入在不同运行时刻给出不一样的优化结果。然后不能用普通迭代搜索必须把这个问题结构特性挖掘出来做基于知识的定制化搜索。 说起来容易具体要怎么做呢我们认为最重要的是看待这个问题的视角。这里的路径规划问题对应的经典问题模型是开环TSP问题或是开环VRP的变种么可以是也可以不是。我们做了一个有意思的建模转换把它看作流水线调度问题每个订单可以认为是job一个订单的两个任务取餐和送餐可以认为是一个job的operation。任意两个任务点之间的通行时间可以认为是序列相关的准备时间。每一单承诺的送达时间包括预订单和即时单可以映射到流水线调度问题中的提前和拖期惩罚上。 算法应用效果 做了这样的建模转换之后流水线调度问题就有大量的启发式算法可以借鉴。我们把一个经典的基于问题特征的启发式算法做了适当适配和改进可以得到非常好的效果。相比于之前的算法耗时下降70%优化效果不错。因为这是一个确定性算法所以运行多少次的结果都一样。我们的算法运行一次跟其它算法运行10次的最优结果相比优化效果是持平的。 订单智能调度 配送调度场景可以用数学语言描述。它不仅是一个业务问题更是一个标准的组合优化问题并且是一个马尔可夫决策过程。 并非对于某个时刻的一批订单做最优分配就足够还需要考虑整个时间窗维度每一次指派对后面的影响。每一次订单分配都影响了每个骑手后续时段的位置分布和行进方向。如果骑手的分布和方向不适合未来的订单结构相当于降低了后续调度时刻最优性的天花板。所以要考虑长周期的优化而不是一个静态优化问题。 为了便于理解我们还是先看某个调度时刻的静态优化问题。它不仅仅是一个算法问题还需要我们对工程架构有非常深刻的理解。因为在对问题输入数据进行拆解的时候会发现算法的输入数据太庞大了。比如说我们需要任意两个任务点的导航距离数据。 而我们面临的问题规模前几年只是区域维度的调度粒度一个商圈一分钟峰值100多单匹配几百个骑手但是这种乘积关系对应的数据已经非常大了。现在由于美团有更多业务场景比如跑腿和全城送是会跨非常多的商圈甚至跨越半个城市所以只能做城市级的全局优化匹配。目前调度系统处理的问题的峰值规模是1万多单和几万名骑手的匹配。而算法允许的运行时间只有几秒钟同时对内存的消耗也非常大。 另外配送和网约车派单场景不太一样。打车的调度是做司机和乘客的匹配本质是个二分图匹配问题有多项式时间的最优算法KM算法。打车场景的难点在于如何刻画每对匹配的权重。而配送场景还需要解决对于没有多项式时间最优算法的情况下如何在指数级的解空间短时间得到优化解。如果认为每一单和每个骑手的匹配有不同的适应度那么这个适应度并不是可线性叠加的。也就意味着多单对多人的匹配方案中任意一种匹配都只能重新运算适应度其计算量可想而知。 总结一下这个问题有三类挑战 性能要求极高要做到万单对万人的秒级求解。我们之前做了一些比较有意思的工作比如基于历史最优指派的结果用机器学习模型做剪枝。基于大量的历史数据可以帮助我们节省很多无用的匹配方案评价。动态性。 作为一个MDP问题需要考虑动态优化场景这涉及大量的预估环节。在只有当前未完成订单的情况下骑手如何执行、每一单的完成时刻如何预估、未来时段会进哪些结构的订单、对业务指标和效率指标产生怎样的影响……可能会觉得这是一个典型的强化学习场景但它的难点在于决策空间太大甚至可以认为是无限大的。目前我们的思路是通过其它的建模转换手段进行解决。配送业务的随机因素多。比如商家的出餐时间也许是很长时间内都无法解决的随机性。就连历史每一个已完成订单商家出餐时间的真值都很难获得因为人为点击的数据并不能保证准确和完整。商家出餐时刻不确定这个随机因素永远存在并且非常制约配送效率的提升。另外在顾客位置交付的时间也不确定。写字楼工作日的午高峰上电梯、下电梯的时间很难准确进行预估。当然我们也在不断努力让预估变得更精准但随机性永远存在。对于骑手来说平台没法规定每个骑手的任务执行顺序。骑手在配送过程中可以自由发挥所以骑手执行顺序的不确定性也一直存在。为了解决这些问题我们尝试用鲁棒优化或是随机规划的思想。但是如果基于随机场景采样的方式运算量又会大幅增加。所以我们需要进行基于学习的优化优化不是单纯的机器学习模型也不是单纯的启发式规则优化算法是结合真实数据和算法设计者的经验学习和演进而得。只有这样才能在性能要求极高的业务场景下快速的得到鲁棒的优化方案。目前美团配送团队的研究方向不仅包括运筹优化还包括机器学习、强化学习、数据挖掘等领域。这里具有很多非常有挑战的业务场景欢迎大家加入我们。 作者简介 圣尧2017年加入美团美团配送团队资深算法专家。
