饿了么张浩:AI派来的外卖送餐员

原创
网络 通信技术
7月21日上午WOTI2017主会场,饿了么副总裁张浩进行了主题为《AI派来的外卖送餐员》的精彩演讲。51CTO记者将持续为您带来WOTI2017全球创新技术峰会前方精彩报道。

【51CTO.com原创稿件】2017年7月21日-22日,由51CTO主办的以人工智能为主题的WOTI2017全球创新技术峰会在北京富力万丽酒店隆重举行。峰会期间,30+AI明星,数十场围绕人工智能主题的精彩演讲与圆桌论坛缓缓揭开面纱。除了场内的精彩演讲,场外还有专门为AI爱好者搭建的动手实验室和科技体验区,这一切都让本次大会亮点十足。

7月21日下午WOTI2017主会场,饿了么副总裁张浩进行了主题为《AI派来的外卖送餐员》的精彩演讲。以下是演讲实录,让我们先睹为快!

[[197646]]
饿了么副总裁张浩


大家下午好!很高兴有机会和大家分享,也感谢WOTI给的这个分享平台。同行业者已经从最早的外卖走向本地生活,我下面开始我的演讲。我今天的分享分三个阶段:第一,简单介绍一下饿了么。第二,讲一讲AI在饿了么的应用。第三是我的主题,四个案例,给大家分享一下运筹优化与机器学习应用实例。

当你把APP打开以后,首先看到的是交易平台,就像咱们在淘宝和京东看到的是一样的,只不过搜的不是衣服,主要是以交易为主,搜索、推荐、菜品挖掘等等这些。今天,我要给大家讲的更多的是第二部分,本地的物流网络。物流到现在很多年了,而且这个行业应用从运筹学到统计优化,一直到机器学习,这三个合起来对我们现代物流体系有很大帮助。我们的用户现在已经到2.6亿,B端商家全国已经是130万,更重要的是我们的配送员,在我们平台注册的配送员已经达到300万,覆盖全国两千家城市地区。

互联网行业,衣、食、住、行,淘宝、携程、滴滴、饿了么分别代表四个方向,我想做个铺垫,因为这个行业特点,和其他三家有什么不同的地方和独特的挑战。首先是淘宝,淘宝纯粹是以用户和商户为主,线下当你下了单以后,线下走开放平台,时效性通常是以天计算,所以它的挑战更多的是能够把转化率提到最高,很短时间内找到自己想要的东西。而携程也是一个纯粹以线上用户和商户为主的交易平台,基本上没有线下订单,不管是订酒店还是别的都是线上完成,相对而言,滴滴和饿了么都是O2O的两个比较大的方面,这里有不同之处在于,滴滴推荐搜索不是特别重要,不会上去搜这个车不喜欢搜另外的车,更多是通过系统最优结果推荐给你,这是比较大的区别。另外一个比较大的区别是在时间上的要求,一般我们要求几分钟车到达,但上了车以后就是司机和乘客的问题了,平台不会为此负责任。最后是饿了么,线上以用户和商户为主,但不同的是线下更为复杂,更重要的是时效性比如准时达、30分钟、40分钟,一旦超过这个时间,平台将为用户进行赔偿,这对我有很大的挑战。

在本地物流行业,或者即时配送,说即时配送更好一些,因为物流太大了。我们希望当你下了单以后30分钟,整个交易不仅是菜出来送到你手里,整个完成过程我们希望控制在30分钟。所以这里有几个大的不同的地方,纯粹线上交易,首先就是运筹优化,第二才是学习,更重要的是大数据,我们通过离线计算,然后实时算法。

这是一个比较粗略的一览图,我们的业务里边算法分三个部分。第一个是基于LBS,我们根据你的定位搜到本地配送范围,所以LBS是我们最重要的服务。其次就是machine learning和optimization。对我们来说,站点网格配送范围是最重要的,有了这些后面配送才有了最合理的结果。第二个是选址,除了餐厅以外,很多同行业也在做自主餐厅,加盟商在我们厨房里做品牌,选址就非常关键了。

后面的就简单了,推荐搜索,我们是交易平台。紧接着是供需预测、订单运单预测,最后我们的物品是通过人,不管是走动还是骑电动车,给你送到手里,我们需要提前一个季度甚至半年做好规划,我们需要根据历史数据依据算法推测出,比如夏天北京经常下雨,大概需要多少运力和运单,所以供需预测和运单预测非常重要。用户商户分层,这个精细化运营要做到。后面智能补贴、路径规划,这都是实际物流当中非常重要的,动态定价指的是我们在配单的时候,必须根据当时的运力情况调整和控制流量,同时对路径进行规划。出餐时间、送餐时间的预估,这几个是我下面在算法模块里详细讲到的重点,我先跳过。我分两个部分,第一个是讲机器学习在饿了么业务的应用。第二个是在机器学习基础之,上运筹优化和机器学习在饿了么中的应用。

第一个是出餐时间预估,当你订了一个餐以后,我们希望30分钟能够送到,这当中包括餐厅出餐时间,所以对餐厅的出餐时间预估是我们配送环节最难的一个,因为我们对它完全没有控制,我们不知道它什么时候能出完。这点和滴滴的出发时间预估差别就在这个地方,滴滴场景大家可以看到左边的图,你在那个地方,通常希望一到两公里之内就有车到达,这个平台不用管。

右边是饿了么场景,餐厅配餐时间受很多因素影响,首先是堂食的因素,餐品的品类,烹饪方式,订单大小,实际情况当中餐厅备完以后他不会告诉你ready,必须通过机器学习方法预测。我们怎么做呢?我们从开始到现在大概经历了三个版本,当然,任何做机器学习的最开始都会做线性模型,毫无疑问,没什么特别讲的。

误差方面,我们当时调了很多特征,最后平均是6分钟左右,后来我们用了非线性模型,误差240秒左右。最简单的统计特征,这个餐厅过去的出餐时间,他大概有多少人吃饭,今天是周五还是星期天,包括这个餐厅的菜品品类,比如做云南菜,他的菜品一定会花的时间更长,如果是麦当劳,30秒肯定能出来,这些特点都在里面。另外一个特点,我们会用到天气,尤其天气这个比较多。这些都会对误差进行影响。我们做到240秒以后很长一段时间都难以再提高。

最后一个,我们今年开始用深度学习的办法,因为我们可以把出餐方法当作时间序列进行处理,采用RNN、LSTN模型来做,现在误差是3分钟,平均时长不代表什么,因为餐厅爆单的情况下,或者特殊情况下,误差会比较大一点。这是我们用的模型,实际当中会有不一样。我们用的是两层RNN模型,每层大概是1500个(英文),用了65%的dropout,右上角的图是我们的公式,会随机根据当时的概率来抓取。

第二个是行程时间预估,行程时间预估相对好一些,当骑手取到这个餐以后,开始从餐厅出来一直到客户手里,整段时间是行程时间预估,因为我们有GPS采样,所以我们知道他在过程当中花多长时间,这里的挑战在哪里?这里的挑战在于数据是非常难收集的。因为我们和其他的出行行业不一样,我们整个过程有三分之一到一半时间,尤其大城市,都是在大厦里边,高峰时间,上班时间,我们的白领也在大厦里边,大厦里边GPS定位是非常不准确的。

所以我们和别的公司合作,用WiFi来提高精确的定位。还有出餐时间方面,比较困难的是走的方式,不像滴滴Uber这样开到公路上,有的时候步行等电梯上下楼等多种方式,而且楼宇里边交通非常复杂。左边这个图是一个聚类算法的图,大家可以看到这些点,这些点是我们收到的GPS位点,这里误差非常大,如果全部用GPS位点来做,O点和D点,交通行业O点是起点,D是终点。

我们首先有一个聚类,把那些误差比较大的先去掉,然后通过聚类以后把GPS位点弄到POI上,match到一个点上。我们做同样的事情,去掉绝大多数噪音。第二个是轨迹聚类,当你知道行程起点和终点以后必须要知道轨迹,右边的图刚好是一条河,这个很讨厌,我们很多时候不知道,也无法预测骑手怎么走,有的可能走小路,有的不知道走大路,所以预测的时候比较困难。轨迹聚类也有一些心得体会。

其中我们把GPS位点噪音点去掉,让轨迹更加精准一些。下一个是讲开单场景,组合优化的问题,你不会从一个点只拿一个单,是很多的单,当你决定把这个单配给谁的时候,你要靠服务。还有行程时间预估,恶劣天气,各种活动,还有节假日,如果是周末或者节假日,这些也是有影响的。

第二个,机器学习与运筹优化算法组合在饿了么应用场景,最重要的是智能分单,什么叫智能分单?在没有智能分单以前,分单是人来做的,整个分单过程是基于当地一个网络,所以这个单不会全程分,以前都是人来做的,当你每天可能只有几十单、几百单的时候,有一个地图,能看到谁和谁离单比较近,很快来解决问题。但是当量上来以后人是不可靠的,也做不到最优,体量比较大的时候这是非常困难的。和其他推荐系统比,它的角色会更多,除了商家还有骑手,骑手还有用户和团队的区别,复杂度也更高。

大家可以看看右边这个图,一个骑手通常同时送五到十个餐,所以分单的时候是指数级的问题,我们需要知道他身上已有三到五单,是不是再给他另外五单,在时效性和准确性上要求比较高。这是我们做的第一个版本,当我们拿到这个问题的时候很自然就想到这是很经典的路径规划问题,因为你从这个点出发要经历这么多订单,最后还要回到起点,因为通常大家会聚集在一个地方,这是很传统的车辆路径规划问题,这里输入是订单、骑手、骑手容量、成本,输出是订单和骑手间的匹配以及行走路线。优化目标是最小化时间或者行驶距离,约束条件,比如骑手背单数,骑手数量,最晚到达时间等,当你下一个单的时候,我们说40分钟到,这是最晚到达时间,我们希望99%都能在40分钟到。

VRP问题,你到了目的地之后还需要把你的东西拉回来,左边TSPB的问题,还有TSPTW的问题,当你有多个车的时候是MTSP,在此基础上演进一下VRP的变种,比如最远不超过多少,这些都是这个问题的变种,对我们完全不是新的东西。

我们使用的一种方法是模拟退火算法,大家看看左边的图,稍微讲下背景。这是一种很传统的运筹优化问题,方法有很多,当我们量大的时候,比如动态优化,大家都知道VRP问题,或者通常组合问题,是很难找到最优的解,所以更多的是用(英文)。这是随机迭代算法,还有别的算法,这里文献就特别多了,大家如果搜的话有上千篇文章,书有很多本,有兴趣大家可以看看。我们采用的一种算法是模拟退火算法,是随机的最优算法。

看看右边的图,首先是随机产生一些解,我们定义下来目标函数,这里最关键的是随机的对当前的解,跟物理退火一样,找到最优解,没有最优解没关系,数量有一个上限。这是概率算法,不一定找到最优,所以下面的判断是是否达到迭代次数,因为我们可能无限次解下去,达到以后就终止。这是整个算法的过程,现在这个模拟算法已经成熟了,更多挑战是规模比较大的时候,分布式计算怎么更有效一些,这个也有很多文献可以看。用的方案也比较多,比如大型模拟,生产调度,控制工程,机器学习,神经网络,信号控制等等。

现在我们的方案用的是2.0,基于代价函数的优化问题。VRP方案遇到的挑战在哪里?刚才讲到计算复杂度问题,这只是一个方面,更重要的是我们对每个(英文),整个结果就完全的不符合逻辑,这是我们遇到的最大困难。时间预估的不准确性,造成从A点到B点预估时间是不准确的,这个时候做出的结果往往很差,尤其小城镇,大城市还好,因为有足够的样本量,比如北京,可以大概估计一下时间。但小城市很难,很多时候POI都到了镇政府,而不是餐厅,所以这种情况下我们的VRP完全没有用。除此之外,还有基础的送餐习惯,很多时候骑手不会按照你推荐的送,他会这个先送那个后送,影响比较大。

所以我们现在的方案是这样的。简单讲,这是一个代价矩阵,我们有N个订单包,N个骑手,这么一个二维的矩阵,我们希望能够把每个订单包都分到一个人身上,中间的就是代价矩阵,希望输出的是订单包和骑手之间最优匹配。这里的代价定义和计算方法也经过几版的迭代,最开始毫无疑问的,当你决定把一个单分给骑手的时候,代价是其他单不会因此受影响,也不希望他距离跑太长,因为电动车跑两公里送一单肯定是最坏的选择。所以我们最开始用规则的方法,通过大量的离线分析,比如大概20个特征,这些特征每个权重多少,算出来以后,后面是优化问题,最后的结果是得到右边的矩阵。一个订单分给了这个骑手,匹配用的什么算法?我们用的是比较成熟的最优匹配KM算法,KM算法求的是完备匹配下最大权匹配,KM算法也有很多流程,和开始的VRP解决方案比较接近,不断优化。最开始算法流程初始化可行顶标的值,用匈牙利算法寻找完备匹配。

当然,我们还有很多的不足,我们大概解决了基本的问题,但后来我们意识到,分单如果有一个订单来了,马上分给一个骑手去接,这往往不是最优选择,如果你再等两分钟,同样餐厅同样路线上会出现更多的单,所以就出现了蓄水,也许等两分钟,等更多的单。蓄水之后我们通过两个单打包出来,这是2.1版本。打包的时候还有很多不足之处,任何做机器学习都要用规则来,什么样的包可以打在一起,同取同送,GPS不准的情况下同取同送带来的结果就是订单完成不了,比如这栋楼A座和这栋楼B座。所以2.2版本,去掉了打包规则,我们用机器学习方法学习,人工调度的时候,什么样的单人工分成什么样的包和模型,用订单相似度模型,但是这还不够。

因为我们推广过程当中发现,在不同的地方有不同的习惯,而这个习惯会造成对骑手满意度和推广难度很大的影响。所以我们又出了一个新的叫订单与骑手匹配模型,我们来定什么样的是好的,刚才讲的更多是我们通过离线算出来的,用一个公式去match全国几千个站点分单逻辑,这是做不到的,用这种规则一定做不好。所以我们做了订单与骑手匹配模型,把数据按照当地站点取出来,我们进行学习,学到人工调度习惯,我们机器学习抓住这个特征,真正做到当地化、本地化,这是我们2.3标准。每个站每个地区都是独特的模型。我们正在做的是3.0版本,增强学习,大家对这个也比较熟悉。

2.3的时候在模型上就很难再提高了,但不管怎么说,模型更新一定是离线过程,可能一个星期,可能一天,我们希望变得更快,怎么更快?现在比较流行的增强学习,我们通过在线反馈,骑手喜不喜欢,如果不喜欢会换单,这个信号我们曾经抓到了,但是通过离线进行补偿,通过增强学习在线上自动学习,还在开发过程中。

整个算法过程是这样的,但最大的问题是我们的基础数据,刚才我反复提到POI点,不管算法怎么分,它看到的是我们告诉它从这个点到那个点,POI的准确性一直以来是最大的挑战,所有以LBS为服务的任何公司,POI相当于地址库,就像Google map为什么值钱,因为它的POI做的好,导航算法是你优化的,光有算法没用,重点在POI的准确性,当然,Google不仅仅在美国,他在全世界做的都比较好,这是他的财富,就是数据。我们自己也在不断积累POI。ETA、出餐时间预测、骑手模型、餐厅画像,这些都需要长期提升。骑手模型讲的是这个骑手他的习惯、他的能力,对路线的熟悉程度,包括比如给他五个单他能不能准时送到,什么时候单可以分给某个人,他比较靠谱。餐厅画像也很重要。

最后一个是最优餐厅选址问题,这个跟菜鸟搞仓储的不同,但意思是一样的,比如菜鸟决定在全国建主站网,仓库负责哪个区域,从A仓库到B仓库怎么设计路线,这是比较经典的FACILITY LOCATION PROBLEM。在城市里面我们希望餐厅有交错,能够囊括最大的用户。左边的公式,从两个点之间他们的代价也最小,这个是我们现在还在经营的业务,叫未来餐厅,我们希望自己能够在最便宜地点选到最大化潜在的最多GMV增长。

最后是总结。很多朋友不太清楚,实际上本地生活场景算法非常大,可能送外卖比较多,但想象它不是外卖,而是运筹优化,尤其因为是本地生活圈问题导致很多不规则的东西,所以挑战非常非常多,不比任何一家互联网公司小。第一个问题,基础数据的完整性和准确性,这点没有人帮到我们,因为行业特点是靠自己,长期通过人来收集这些数据,餐厅、骑手,甚至电梯难易程度对我们的算法都有影响。

还有对人的行为理解,人的行为理解,在我们分单的时候觉得这样是最好的,但实际运营当中我们受到很多阻力,别人不喜欢这样做。比如追单,在五楼接了一个单,刚刚到楼下同样分一个餐厅的单,骑手不喜欢,好不容易下来的不想再取单了,我们发现你这个时候再回去总的时间会更少,但骑手不喜欢,他觉得跑上去麻烦,很多时候要等电梯,或者有各种他不喜欢的行为。这都是我们后来意识到,很多时候需要和业务结合才能有一个完整的解决方案。最后一个,优化算法与机器学习的结合,在物流场景更多的是成本优化,机器学习更多是对因素的学习。所以优化算法和机器学习只有结合起来才能完美解决我们的这些问题。我的内容就分享到此,谢谢大家!

51CTO记者将持续为您带来WOTI2017全球创新技术峰会前方精彩报道,敬请期待!

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:刘妮娜 来源: 51CTO
相关推荐

2015-03-31 18:19:37

饿了么动画效果

2015-08-03 10:08:36

公司变卖

2015-08-03 09:08:41

公司卖掉发工资

2017-07-26 18:49:00

京东机器学习人工智能

2015-02-01 10:12:05

O2O京东腾讯

2017-12-05 15:03:45

人工智能饿了么大数据

2018-01-03 09:57:19

异地双活数据库

2017-10-27 15:44:24

饿了么张龙前端基础设施

2018-08-17 09:14:43

饿了么容器演进

2017-06-12 09:13:02

饿了么技术运营运维

2020-07-06 08:40:36

阿里饿了么思考

2020-06-05 09:09:06

代码摆地摊外卖

2017-08-08 15:02:00

半月刊

2018-11-29 09:36:56

大数据调度系统

2018-02-28 10:45:10

技术变革混合云架构

2017-08-04 10:39:45

白熊视频技术八卦程序员

2016-04-01 18:25:21

中国科技网

2016-08-26 22:36:18

大数据

2019-01-04 16:11:50

2021-07-12 08:39:14

程序员外卖小哥代码
点赞
收藏

51CTO技术栈公众号