当前位置:网站首页>即时配送的订单分配策略:从建模和优化-笔记
即时配送的订单分配策略:从建模和优化-笔记
2022-06-12 18:27:00 【Tyan】
文章作者:Tyan 博客:noahsnail.com | CSDN | 简书
本文为美团文章学习的笔记整理。
1. 引言
外卖平台中,配送时效、准时率作为履约环节的重要指标,是外卖平台的核心竞争力之一。要提升用户的配送时效和准时率,最直接的方法是配备较多的配送员,扩大运力规模,然而这也意味着配送成本会很高。怎么在配送体验和配送成本之间取得最佳的平衡,是即时配送平台生存的根基和关键所在。在用户满意度持续提升的同时,降低配送成本、提高骑手满意度、驱动配送系统的自动化和智能化,是外卖配送团队要解决的难题。
Note: 招募更多的配送员,配送成本很高,应该想办法减少成本,即用更少的骑手配送更多的订单。
2. 即时配送智能调度系统
措施
- 首先通过优化设定配送费以及预计送达时间来调整订单结构;
- 在接收订单之后,考虑骑手位置、在途订单情况、骑手能力、商家出餐、交付难度、天气、地理路况、未来单量等因素,在正确的时间将订单分配给最合适的骑手,并在骑手执行过程中随时预判订单超时情况并动态触发改派操作,实现订单和骑手的动态最优匹配;
- 系统派单后,为骑手提示该商家的预计出餐时间和合理的配送线路,并通过语音方式和骑手实现高效交互;
- 在骑手送完订单后,系统根据订单需求预测和运力分布情况,告知骑手不同商圈的运力需求情况,实现闲时的运力调度。
结果 通过上述技术和模式的引入,持续改善了用户体验和配送成本:
- 订单的平均配送时长从2015年的41分钟,下降到32分钟,进一步缩短至28分钟;
- 另一方面,在骑手薪资稳步提升的前提下,单均配送成本也有了20%以上的缩减。
Note:
- 缩短配送时间,如果配送时间本来就很短,可以考虑稍微牺牲配送时间,提高其它指标
- 降低配送成本,在保证订单完成率的情况下减少配送骑手,骑手多单配送并行,减少每单配送成本
3. 订单分配问题
3.1 订单分配的发展
外卖订单的分配问题一般可建模为带有若干复杂约束的DVRP(Dynamic Vehicle Routing Problem)问题。这类问题一般可表述为:有一定数量的骑手,每名骑手身上有若干订单正在配送过程中,在过去一段时间(如1分钟)内产生了一批新订单,已知骑手的行驶速度、任意两点间的行驶距离、每个订单的出餐时间和交付时间(骑手到达用户所在地之后将订单交付至用户所需的时间),那么如何将这批新订单在正确的时间分配至正确的骑手,使得用户体验得到保证的同时,骑手的配送效率最高。
订单和服务提供方的匹配问题是一个非常关键的问题。在外卖行业发展初期主要依赖骑手抢单模式和人工派单模式。
- 抢单模式 抢单模式的优势是开发难度低,服务提供者(如司机、骑手)的自由度较高,可以按照自身的需要进行抢单,但其缺点也很明显:骑手/司机只考虑自身的场景需求,做出一个局部近优的选择,然而由于每个骑手掌握的信息有限又只从自身利益出发来决策,导致配送整体效率低下,从用户端来看,还存在大量订单无人抢或者抢了之后造成服务质量无法保证(因为部分骑手无法准确预判自己的配送服务能力)的场景,用户体验比较差。
- 人工派单模式 人工派单的方式,从订单分配的结果上来看,一般优于抢单模式。在订单量、骑手数相对比较少的情形下,有经验的调度员可以根据订单的属性特点、骑手的能力、骑手已接单情况、环境因素等,在骑手中逐个比对,根据若干经验规则挑选一个比较合适的骑手来配送。一般而言,人工调度一个订单往往至少需要半分钟左右的时间才能完成。然而,随着外卖订单规模的日益增长,在热门商圈(方圆3公里左右)的高峰时段,1分钟的时间内可能会有50单以上,在这种情况下,要求人工调度员每1-2秒钟做出一次合理的调度决策,显然是不可能的。另一方面,由于即时配送过程的复杂性,要做出合理的匹配决策,要求调度员对配送范围内各商家的出餐速度、各用户地址的配送难度(例如有的写字楼午高峰要等很长时间的电梯)、各骑手自身的配送工具/熟悉的商家和用户范围/工作习惯等等要有非常深入的了解,在此基础上具备统筹优化能力,考虑未来进单量、减少空驶等因素,做出全局近优的选择,这对人工调度员而言,又是一项极其艰巨的任务。
系统派单具备如下优势:
- 系统可以在全局层面上掌握和配送有关的骑手、商家、用户、订单等各类信息,在此基础上,可以做出全局较优的方案,从而提升配送效率和配送体验,减少配送成本;
- 显著减轻人工调度员的工作,从而降低人工成本,人工调度员只需要在一些意外场景(如配送员出现紧急情况无法继续配送等)发生的时候进行干预即可。
Note: 派单模式与抢单模式并存,派单一般优于抢单
3.2 即时配送大数据平台
美团外卖每天产生巨量的订单配送日志、行驶轨迹数据。通过对配送大数据进行分析、挖掘,会得到每个用户、楼宇、商家、骑手、地理区域的个性化信息,以及有关各地理区块骑行路径的有效数据,那么订单智能分配系统的目标就是基于大数据平台,根据订单的配送需求、地理环境以及每名骑手的个性化特点,实现订单与骑手的高效动态最优匹配,从而为每个用户和商家提供最佳的配送服务,并降低配送成本。
即时配送大数据平台实现对骑手轨迹数据、配送业务数据、特征数据、指标数据的全面管理和监控,并通过模型平台、特征平台支持相关算法策略的快速迭代和优化。
- 机器学习模块负责从数据中寻求规律和知识,例如对商家的出餐时间、到用户所在楼宇上下楼的时间、未来的订单、骑行速度、红绿灯耗时、骑行导航路径等因素进行准确预估,为调度决策提供准确的基础信息;
- 运筹优化模块则在即时配送大数据平台以及机器学习的预测数据基础上,采用最优化理论、强化学习等优化策略进行计算,做出全局最优的分配决策,并和骑手高效互动,处理执行过程中的问题,实现动态最优化。
3.3 订单分配问题建模
准确建模是实际决策优化项目的第一步,也是最关键的一步。准确建模,包括两个方面的问题:
- 正确理解了实际业务场景的优化问题,并且通过某种形式化语言进行了准确描述;
- 建立的模型中,涉及的各类参数和数据,能够准确得获取。
在上述两个前提下,采用相应的高效优化算法求解模型所得到的最优解,就是符合实际场景需求的最优决策方案。第一个问题,一般是通过业务调研、分析并结合建模工具来得到;而解决第二个问题,则更多地需要依赖数据分析、机器学习、数据挖掘技术结合领域知识,对模型进行精确的量化表达。
一个决策优化问题的数学模型,一般包括三个要素:
- 决策变量,决策变量说明了希望算法来帮助做哪些决策
- 优化目标,优化目标则是指通过调整决策变量,使得哪些指标得到优化
- 约束条件,约束条件则是在优化决策的过程中所考虑的各类限制性因素
即时配送场景下的订单分配问题,符号定义:
在即时配送调度场景下,决策变量包括各个订单需要分配的骑手,以及骑手的建议行驶路线:
优化目标一般包括希望用户的单均配送时长尽量短、骑手付出的劳动尽量少、超时率尽量低等。可表述为:
实际场景下的订单分配问题,设置目标函数是一个较为复杂的问题。
- 该优化问题是多目标的,且各个目标在不同时段、不同环境下会有差别。
- 缺乏有助于量化优化目标的数据。针对该难题,首先通过深入调研业务痛点和目标,在此基础上,采用机理和数据相结合的办法,由人工设定目标函数的结构,通过仿真系统和实际数据去设定目标函数的参数,来确定最终采用的目标函数形态。
即时配送调度问题的约束条件类型:
除了以上约束外,有时还需要考虑部分订单只能由具备某些特点的骑手来配送、载具的容量限制等。
Note: 载具容量限制,订单类型要求订单只能单独配送,不能与其它订单混合在一起。
以上只是针对给定的一批订单进行匹配决策的优化问题在建模时所需考虑的部分因素。在外卖配送场景中,希望的不是单次决策的最优,而是策略在一段时间应用后的累积收益最大。不追求某一个订单的指派是最优的,而是希望一天下来,所有的订单指派结果整体上是全局最优的。在进行决策的时候,既需要考虑已确定的订单,还需要考虑未来的尚未确定的订单。运筹优化领域中的马尔可夫决策过程描述的就是这样的一类在不确定、信息不完备环境下的序贯决策优化问题。
Note: 最简单的方法是贪心,追求当前订单最优指派,实现简单,但可能不是全局最优的。追求全局最优复杂,不一定比局部最优好,只有全局最优明显优于局部最优时,才值得上。
即时配送订单分配场景下的数据包括两类:
- 直接通过业务系统采集可获取的数据,例如订单数据、骑手负载数据、骑手状态数据等。
- 无法直接采集得到,需要预测或统计才能获取的数据,如商户出餐时间、用户驻留时间(骑手到达用户处将订单交付给用户的时间)、骑手配送能力等。
第一类数据的获取一般由业务系统、骑手端App直接给出,其精度通过提升工程质量或操作规范可有效保证;而第二类数据的获取是即时配送调度的关键难点之一。
在订单的配送过程中,骑手在商家、用户处的取餐和交付时间会占到整个订单配送时长的一半以上。商家出餐时间的长短,跟品类、时段、天气等因素都有关,而交付时间更为复杂,用户在几楼,是否处于午高峰时段,有没有电梯等等,都会影响骑手交付订单给用户的时间。为解决这些问题,利用机器学习工具,利用历史的骑手到店、等餐、取餐的数据,并充分考虑天气等外部因素的影响,建立全面反映出餐能力的预测模型,并通过实时维度的特征进行修正,可以得到准确的出餐/交付时间估计。
Note: 骑手在路上的时间比较简单,也比较好估计,就是距离/骑手速度。但等餐、取餐时间,用户交付时间涉及的因素比较多,也比较杂。例如商户的订单积压情况,用户的楼层、电梯情况等。这也是将配送时间分成多段预测的原因之一。整体预测可能偏差较大,分成几部分,其中一部分的时间可以更准确的预测。
优化算法的作用则是在构建的解空间里找到最优的策略。配送调度问题属于典型的NP-Hard优化问题,解空间巨大。如何设计好的优化算法,从庞大的解空间中搜索得到一个满意解是一个很大的挑战,即时配送对于优化算法的另一个要求是高实时性。
针对此难题,采用了两个关键思路。一是问题特征分析。针对配送调度的场景,这个问题可以被分解为两个层次:骑手路径优化和订单分配方案的优化。骑手路径优化问题要解决的问题是:在新订单分配至骑手后,确定骑手的最佳配送线路;而订单分配优化问题要解决的问题是:把一批订单分配至相应的骑手,使得关注的指标(如配送时长、准时率、骑手的行驶距离等)达到最优。这两个问题的关系是:通过订单分配优化算法进行初始的订单分配,然后通过骑手路径优化算法获取各骑手的最佳行驶路线,进而,订单分配优化算法根据骑手路径优化结果调整分配方案。这两个层次不断反复迭代,最终获得比较满意的解。第二个思路是跨学科结合。订单分配问题在业内有两类方法,第一类方法是把订单分配问题转换成图论中的二分图匹配问题来解决。这种做法是一个不错的近似方案,优点是实现简单计算速度快,但它的缺点是会损失一部分满意解。第二类方法是直接采用个性化的算法进行订单分配方案的优化,优点是不损失获得满意解的可能性,但实际做起来难度较大。结合领域知识、优化算法、机器学习策略以及相关图论算法,基于分解协调思想,设计了骑手路径优化算法和订单分配优化算法。进一步,利用强化学习的思想,引入了离线学习和在线优化相结合的机制,离线学习得到策略模型,在线通过策略迭代,不断寻求更优解。通过不断地改进算法,在耗时下降的同时,算法的优化效果提升50%以上。为了有效降低算法运行时间,对优化算法进行并行化,并利用并行计算集群进行快速处理。
Note: 批量分配算法,二分图匹配问题,简单速度快,第2种需要集群。
即时配送过程的一个突出特点是线下的突发因素多、影响大,突发事件造成的一个恶劣结果是,虽然在指派订单的时刻,所指派的骑手是合理的,然而过了一段时间之后,由于骑手、订单等状态发生了变化,会变得不够合理。现有方法主要通过人工来完成,即:配送站长/调度员在配送信息系统里,查看各个骑手的位置、手中订单的状态及商户/用户的位置/期望送达时间等信息,同时接听骑手的电话改派请求,在此基础上,分析哪些订单应该改派,以及应该改派给哪位骑手,并执行操作。
Note: 突发事件需要人工介入(2017年)。
针对即时配送的不确定性特点,提出了两点创新:一是延迟调度策略,即在某些场景订单可以不被指派出去,在不影响订单超时的情况下,延迟做出决策;二是系统自动改派策略,即订单即便已经派给了骑手,后台的智能算法仍然会实时评估各个骑手的位置、订单情况,并帮助骑手进行分析,判断是否存在超时风险。
针对即时配送场景,建立了相应的仿真模型,开发了配送仿真系统。
Note: 算法需要在仿真系统上进行测试,调整。
Reference
边栏推荐
- Installation and configuration of window version pytorch entry depth learning environment
- Typescript type declaration file (III)
- MYSQL:Expression #4 of SELECT list is not in GROUP BY clause and contains nonaggregated column
- What is SAP support package stack
- C language learning -- data storage in memory
- Review of MySQL (I): go deep into MySQL
- A story on the cloud of the Centennial Olympic Games belonging to Alibaba cloud video cloud
- Gd32f4xx controls dgus touch keys
- 2022.6.12-----leetcode.890
- Esp32-c3 esp-idf configuring smartconfig and SNTP to obtain network time
猜你喜欢
GD32F4xx控制DGUS触控按键
What is SAP support package stack
Comparison of disk mapping tools for network disk and object cloud storage management
Write a select based concurrent server
Title 37: sorting 10 numbers
HTTP缓存<强缓存与协商缓存>
迄今微软不同时期发布的SQL Server各版本之间的大致区别,供参考查阅
Review of MySQL (VII): use of tables
Analyzing mobx responsive refresh mechanism from source code
Mise en œuvre de l'ACL réflexe dans le simulateur Cisco Cisco Packet Tracer
随机推荐
[Huawei cloud stack] [shelf presence] issue 10: difficulties and solutions of it monitoring and diagnosis in the cloud scenario of government enterprise hybrid in the cloud native Era
General differences between SQL server versions released by Microsoft in different periods so far, for reference
JS judge palindromes
DRM driven MMAP detailed explanation: (I) preliminary knowledge
GD32F4xx控制DGUS 变量显示
torch. New usage of where (old but ignored usage)
Explanation of core interrupt of Godson processor
Title 37: sorting 10 numbers
Title 68: there are n integers, so that the previous numbers are moved backward m positions, and the last m numbers become the first m numbers
JS sum of two numbers
js判断回文数
Shenzhen has been shut down for 7 days since March 14. Home office experience | community essay solicitation
Leetcode491 increasing subsequence
ftrace
Global lock, table lock, row lock
Regression analysis based on elasticnetcv
When openharmony meets openeuler
"Big fat • small lesson" - talk about big file segmentation and breakpoint sequel
JS中的字符串(含leetcode例题)<持续更新~>
Gossip about the source code of redis 89