配送交付时间轻量级预估实践

1. 背景

可能不少同窗都不知道,从打开美团App点一份外卖开始,而后在半小时内就能够从骑手小哥手中拿到温热的饭菜,这中间涉及的环节有多么复杂。而美团配送技术团队的核心任务,就是将天天来自祖国各地的数千万份订单,迅速调度几十万骑手小哥按照最优路线,并以最快的速度送到你们手中。html

在这种场景下,骑手的交付时间,即骑手到达用户附近下车后多久能送到用户手中,就是一个很是重要的环节。下图是一个订单在整个配送链路的时间构成,时间轴最右部分描述了交付环节在整个配送环节中的位置。交付时间衡量的是骑手送餐时的交付难度,包括从骑手到达用户楼宇附近,到将餐品交付到用户手中的整个时间。前端

交付时间的衡量是很是有挑战的一件事,由于骑手在送餐交付到用户手中时会碰到不一样的问题,例如:骑手一次送餐给楼宇内多个用户,骑手对于特定楼宇寻址特别困难,骑手在交付楼宇附近只能步行,老旧小区没有电梯,写字楼没法上楼,或者难以等到电梯等等。交付时间预估须要具有刻画交付难度的能力,在订价、调度等多个场景中被普遍使用。例如根据交付难度来肯定是否调节骑手邮资,根据交付难度来肯定是否调节配送运单的顺序,从而避免超时等等。总的来讲,交付时间预估是配送业务基础服务的重要一环。git

可是,交付时间预估存在以下的困难:github

  • 输入信息较少,且多为非数值型数据,目前可以被用来预估的仅有以下维度特征:交付地址、交付点的经纬度、区域、城市,适配常规机器学习模型须要从新整理且容易丢失信息。
  • 计算性能要求很高。因为是基础服务,会被大量的服务调用,须要性能TP99保证在10ms之内,整个算法平均响应时间须要控制在5ms内,其中包括数据处理及RPC的时间。且该标准为CPU环境下的性能要求,而非GPU下的性能要求。

上图为部分版本所对应的性能,平响时间均在5ms内,TP99基本在10ms内

总结起来,交付时间预估的问题,在于须要使用轻量级的解决方案来处理多种数据形式的非数值型数据,并提取有效信息量,获得相对准确的结果。在相同效果的前提下,咱们更倾向于性能更优的方案。算法

在本文中,咱们介绍了交付时间预估迭代的三个版本,分别为基于地址结构的树模型、向量召回方案以及轻量级的End-to-End的深度学习网络。同时介绍了如何在性能和指标之间取舍,以及模型策略迭代的中间历程,但愿能给从事相关工做的同窗们有所启发和帮助。后端

2. 技术迭代路径

首先,在交付时间预估的技术迭代上,咱们主要经历了三个大版本的改动,每一版本在5ms计算性能的约束下,追求轻量化的解决方案,在兼顾提高效果的基础上,不显著增长性能的消耗。网络

本章节分别叙述了3个模型的迭代路径,包括技术选型、关键方案及最终效果。数据结构

2.1 树模型

技术选型框架

最先也是最容易被考虑到的是利用规则,核心思路是利用树结构衡量地址类似性,尽量在类似的交付地址上积聚结构化数据,而后利用局部的回归策略,获得相对充裕的回归逻辑,而未能达到回归策略要求的则走兜底的策略。机器学习

为了快速聚积局部数据,树模型是一个较为合适的解决方案,树的规则解析可以有效地汇集数据,同时一个层级并不深的树,在计算速度上,具有足够的优点,可以在较短的时间内,获得相对不错的解决方案。

观察用户填写地址以及联系实际中地址的层级结构,不难发现,一个地址能够由四级结构组成:地址主干词(addr)、楼宇号(building)、单元号(unit)、楼层(floor)。其中的地址主干词在实际中可能对应于小区名或者学校名等地标名称。例如望京花园1号楼2单元5楼,解析为(望京花园,1号楼,2单元,5楼)。经过分析,实际交付时长与楼层高低呈正相关关系,且不一样交付地址的交付时长随楼层增长的变化幅度也有所区别,因此可使用线性回归模型拟合楼层信息和交付时长的关系,而地址主干词、楼宇号、单元号做为其层级索引。但用户填写的地址中并不必定包含完整的四级结构,就会存在必定比例的缺失,因此利用这样的层级结构构建成一棵树,而后充分利用上一层已知的信息进行预估。预测时,只需根据结点的分支找到对应的模型便可,若是缺失,使用上一层结构进行预测。对于没有达到训练模型要求数据量的地址,使用其所在的区域平均交付时长做为交付时长的预估结果,这部分也能够看做区域信息,做为树结构的根节点。

迭代路径

总体的思路是基于离散特征训练树模型,在树的结点上基于楼层训练线性回归模型。树结点训练分裂规则:(1)数据量大于阈值;(2)分裂后MAE(平均绝对偏差)的和小于分裂前。考虑到数据的时效性,采用加权线性回归增长近期数据的权重。

2.2 树模型+向量召回方案

技术选型

向量召回做为主流的召回方案之一,被业界普遍使用,在使用LSH、PQ乘积量化等经常使用开源工具基础上,高维向量召回性能一般在毫秒量级。

而从算法上考虑,树模型中NLP地址解析结果可以达到模型使用要求的仅为70%+,剩余20%+的地址没法经过训练获得的模型从而只能走降级策略。利用高维向量来表达语义类似性,即利用向量来表达地址类似性,从而用类似数据对应的模型来替代类似但未被召回数据,将地址主干词进行Embedding后,摆脱主干词彻底匹配的低鲁棒性。

例如,在地址上可能会出现【7天酒店晋阳街店】数据量比较充足,但【7天连锁酒店太原高新区晋阳街店】数据量不充足从而没法训练模型的案例,这多是同一个交付位置。咱们但愿尽量扩大地址解析的成功率。

迭代路径

整个技术路径较为清晰简单,即利用Word2Vec将charLevel字符进行Embedding,得到该地址的向量表示,而且融入GPS位置信息,设计相应兜底策略。

向量召回方案决策路径

最终效果

比较大地提高了总体策略的召回率,提高了12.20pp,对于未被上一版本树模型召回的地址,指标有了显著的提高,其中ME降低87.14s,MAE降低38.13s,1min绝对误差率减少14.01pp,2min绝对误差率减少18.45pp,3min绝对误差率减少15.90pp。

2.3 End-to-End轻量化深度学习方案

技术选型

在树模型的基础上,迭代到向量召回方案,整个模型的召回率有了较大幅度的增加,但仍然不是100%。分析发现,召回率提高的障碍在于NLP对于地址解析的覆盖率。

整个方案的出发点:

从模型复杂度考虑,一样仅仅使用地址信息的话,在提高模型VC维的基础上,使用其余的模型方案至少能够持平树模型的效果,若是在这基础上还能融入其余信息,那么对于原模型的基线,还能有进一步的提高。

考虑到不只仅须要使用地址数据,同时须要使用GPS数据、大量ID类的Embedding,对于各种非数值类型的处理灵活性考虑,采用深度学习的方案,来保证多源且多类型特征能在同一个优化体系下优化学习。

工程上须要考虑的点:

交付模型做为基础模型,被普遍应用在路径构造、订价、ETA等各个业务中频繁调用,在树模型版本中,对于性能的要求为平均响应时间5ms,TP99在10ms左右,本方案须要考虑沿袭原业务的性能,不能显著增长计算耗时。

交付模型的难点在于非数值型特征多,信息获取形式的多样化,当前的瓶颈并不在于模型的复杂度低。若是能够轻量地获取信息及融合,不必对Fusion后的信息作较重的处理方案。

因此总体的设计思路为:利用深度学习融合非数值型特征,在简单Fusion的基础上,直接获得输出结构,对于组件的选择,尽量选用Flops较低的设计。该设计背后意图是,在充分使用原始输入信息,在尽量避免信息损失的基础上,将非数值型的信息融入进去。并将信息充分融合,直接对接所须要的目标。而选用的融合组件结构尽量保证高性能,且具有较高学习效率。这里分别针对地址选用了较为Robust的LSTM,针对GPS选用了自定义的双线性Embedding,兼顾性能和效果。

迭代路径

开始采用端到端的深度学习模型,这里首先须要解决的是覆盖率问题,直接采用LSTM读取charLevel的地址数据,通过全链接层直接输出交付时间。做为初版本的数据,该版本数据基本持平树模型效果,但对于树模型未召回的20%数据,有了较大的提高。

地址信息输入charLevel模型

在采用charLevel的地址奏效后,咱们开始采用加入用户地址GPS的信息,因为GPS为经纬度信息,非数值型数据,咱们使用一种基于地理位置格点的双线性插值方法进行Embedding。该方案具有必定的扩展性,对不一样的GPS均能合理获得Embedding向量,同时具有平滑特性,对于多对偏移较小的GPS点可以很好的进行支持。

最终方案将地址Embedding后,以及GPS点的Embedding化后,加入下单时间、城市ID、区域ID等特征后,再进行特征融合及变换,获得交付模型的时间预估输出。整个模型是一个端到端的训练,全部参数均为Trainable。

模型结构示意图

扩展组件

在证明End-to-End路径可行后,咱们开始进行扩展组件建设,包括自定义损失函数、数据采样修正、全国模型统一等操做,获得一系列正向效果,并开发上线。

特征重要性分析

对于深度学习模型,咱们有一系列特征重要性评估方案,这里采用依次进行Feature Permutation的方式,做为评估模型特征重要性的方式。

考虑GPS经纬度和用户地址存在较大程度的信息重叠,评估结果以下。Shuffle后,用户地址的特征重要性高于GPS经纬度的特征重要性。加入GPS后ME降低不如地址信息明显,主要是地址信息包含必定冗余信息(下文会分析),而其余信息的影响则能够忽略不计。

特征 特征重要排名
用户地址 1
GPS经纬度 2
其余特征 ......

注:在配送的其余案例中,商户GPS的经纬度重要性>>用户地址重要性>>用户GPS的经纬度重要性,该特征重要性仅仅为本案例特征重要性排序,不一样学习目标下可能会有比较明显差异。

最终效果

End-to-End深度学习模型的最终效果较为显著:对于树模型及向量召回方案的最痛点,覆盖率获得完全解决,覆盖率提高到100%。ME降低4.96s,MAE降低8.17s,1min绝对误差率减少2.38pp,2min绝对误差率减少5.08pp,3min绝对误差率减少3.46pp。同时,对于以前树模型及向量召回方案未能覆盖到的运单,提高则更为明显。

3. 模型相关分析

在整个技术迭代的过程当中,因为整个解决方案对于性能有着较为苛刻的要求,须要单独对方案性能进行分析。本章节对向量召回方案及深度学习方案进行了相应的性能分析,以便在线下确认性能指标,最终保证上线后性能均达到要求。下文分别着重介绍了向量匹配的工具Faiss以及TensorFlow Operation算子的选取,还有对于总体性能的影响。

同时对比End-to-End生成向量与Word2Vec生成向量的质量区别,对于相关项目具有必定的借鉴意义。

3.1 向量召回性能

最近邻搜索(Nearest Neighbor Search)指的是在高维度空间内找到与查询点最近点的问题。在数据样本小的时候,经过线性搜索就能知足需求,但随着数据量的增长,如达到上百万、上亿点时候,倾向于将数据结构化表示来更加精确地表达向量信息。

此时近似最近邻搜索ANN(Approximate Nearest Neighbor)是一个可参考的技术,它能在近似召回一部分以后,再进行线性搜索,平衡效率和精度。目前大致上有如下3类主流方法:基于树的方法,如K-D树等;基于哈希的方法,例如LSH;基于矢量量化的方法,例如PQ乘积量化。在工业检索系统中,乘积量化是使用较多的一种索引方法。

针对向量召回的工具,存在大量的开源实现,在技术选型的过程当中,咱们参照ANN-Benchmarks以及Erikbern/ANN-Benchmarks中的性能评测结果。在众多ANN相关的工具包内,考虑到性能、内存、召回精度等因素,同时能够支持GPU,在向量召回方案的测试中,选择以Faiss做为Benchmark。

Faiss是FaceBook在2017年开源的一个用于稠密向量高效类似性搜索和密集向量聚类的库,可以在给定内存使用下,在速度和精度之间权衡。能够在提供多种检索方式的同时,具有C++/Python等多个接口,也对大部分算法支持GPU实现。

下图为Faiss测评曲线:

交付时间模型召回的性能测试以下,能够达到性能需求。

  • 召回候选集数量:8W条向量【因为采用了GPS距离做为距离限制,故召回测试采用8W数量级】
  • 测试机器:Mac本机CPU【CPU已知足性能,故再也不测试GPU】

3.2 序列模块性能

在TensorFlow系统中,以C API为界限,将系统划分为【前端】和【后端】两个子系统,前端扮演Client角色,完成计算图的构造,而后由Protobuf发送给后端启动计算图计算。计算图的基础单元是OP,表明的是某种操做的抽象。在TensorFlow中,考虑到实现的不一样,不一样OP算子的选择,对于计算性能具备较大影响。

为了评测深度学习交付模型的性能瓶颈,首先对整个模型进行Profile,下图即为Profile后的Timeline,其中整个计算大部分消耗在序列模块处理部分,即下图中的蓝色部分。故须要对序列模块的计算性能进行OP算子的加速。

考虑到序列处理的需求,评估使用了LSTM/GRU/SRU等模块,同时在TensorFlow中,LSTM也存在多种实现形式,包括BasicLSTMCell、LSTMCell、LSTMBlockCell、LSTMBlockFusedCell和CuDNNLSTM等实现,因为整个交付模型运行在CPU上,故排除CuDNNLSTM,同时设置了全链接层FullyConnect加入评估。

从评估中能够发现,全链接层速度最快,可是对于序列处理会损失2.3pp效果,其他的序列模型效果差别不大,但不一样的OP实现对结果影响较大。原生的BasicLSTM性能较差,contrib下的LSTMBlockFusedCell性能最好,GRU/SRU在该场景下未取得显著优点。

这是LSTMBlockFusedCell的官方说明,其核心实现是将LSTM的Loop合并为一个OP,调用时候整个Timeline上更为紧凑,同时节约时间和内存:

This is an extremely efficient LSTM implementation, that uses a single TF op for the entire LSTM. It should be both faster and more memory-efficient than LSTMBlockCell defined above.

如下是序列模块的性能测试:

  • 环境:Tensorflow1.10.0,CentOS 7。
  • 测试方法:CPU inference 1000次,取最长的地址序列,求平均时间。
  • 结论:LSTMBlockFused实现性能最佳。【FullyConnect性能最快,但对性能有损失】

注:在评估中,不只仅包括了序列模型,也包括了其余功能模块,故参数量及模型大小按照整体模型而言

lstm结构OP 时间(ms) FLOPs 可训练参数量 模型大小(MB) 效果差别
Fully Connect 1.18 27.83M 7.00M 29.1 -2.3pp
SRU 4.00 27.96M 7.06M 29.4 差别不显著
GRU Block 3.64 28.02M 7.10M 29.6 差别不显著
GRU 4.44 28.02M 7.10M 29.6 差别不显著
LSTMBlockFused 2.48 28.09M 7.13M 29.7 差别不显著
LSTM Block 4.34 28.09M 7.13M 29.7 差别不显著
LSTM 4.85 28.09M 7.13M 29.7 差别不显著
BasicLSTM 4.92 28.09M 7.13M 29.7 差别不显著

3.3 向量效果分析

将向量召回与深度学习模型进行横向比较,两者中间过程均生成了高维向量。不难发现,两者具有必定的类似性,这里就引起了咱们的思考:

相较于向量召回,深度学习模型带来的提高主要来自于哪里?

有监督的lstm学习到的Embedding向量与自监督的Word2Vec获得的向量在地址类似性计算中有多大差异,孰优孰劣?

首先,咱们分析第一个问题,End-to-End模型提高主要来自哪里?

ME MAE 1min绝对误差率 2min绝对误差率 3min绝对误差率
End-to-End模型 - Word2Vec模型 4.14 -0.45 -0.31% 0.05% -0.41%

咱们直接将End-to-End模型获得的char embedding抽取出来,直接放入到Word2Vec方案内,取代Word2Vec生成的char embedding,再进行向量召回的评估。结果以下表所示,单独抽取出来的char embedding在向量召回方案中,表现与Word2Vec生成的向量基本一致,并无明显的优点。

注:

  • 1min绝对误差率定义:|pred-label|<=60s
  • 2min绝对误差率定义:|pred-label|<=120s
  • 3min绝对误差率定义:|pred-label|<=180s

此时的变量有2个方面:

  • a)对于charLevel地址的学习结构不一样,一个为Word2Vec,一个为LSTM

  • b)输入信息的不一样,Word2Vec的信息输入仅仅为地址主干词,而End-to-End的信息输入则包括了地址主干词、地址附属信息、GPS等其余信息。

注:

  • 完整地址:卓玛护肤造型(洞庭湖店) (洞庭湖路与天山路交叉路口卓玛护肤造型)
  • 地址主干词:卓玛护肤造型店
  • 地址附属信息:(洞庭湖店)(洞庭湖路与天山路交叉路口卓玛护肤造型)

为了排除第二方面的因素,即b的因素,使用地址主干词做为输入,而不用地址附属信息和其余模型结构的输入,保持模型输入跟Word2Vec一致。在测试集上,模型的效果比完整地址有明显的降低,MAE增大约15s。同时将char embedding提取出来,取代Word2Vec方案的char embedding,效果反而变差了。结合2.3节中的特征重要性,可知,深度学习模型带来的提高主要来自对地址中冗余信息(相较于向量召回)的利用,其次是多个新特征的加入。另外,对比两个End-to-End模型的效果,地址附属信息中也包含着对匹配地址有用的信息。

ME MAE 1min绝对误差率 2min绝对误差率 3min绝对误差率
End-to-End模型 - Word2Vec模型 -1.28 0.64 0.90% 0.85% 0.35%

针对第二个问题,有监督的End-to-End学习到的Embedding向量,与自监督的Word2Vec获得的向量在地址类似性计算中有多大差异,孰优孰劣?

采用地址主干词代替完整地址,做为End-to-End模型的输入进行训练,其余信息均保持不变。使用地址主干词训练获得的Embedding向量,套用到向量召回方案中。

从评估结果来看,对于不一样的阈值,End-to-End的表现差别相对Word2Vec较小。相同阈值下,End-to-End召回率更高,可是效果不如Word2Vec。

从类似计算结果看,End-to-End模型会把一些语义不相关可是交付时间相近的地址,映射到同一个向量空间,而Word2Vec则是学习一个更通用的文本向量表示。

例如,如下两个交付地址会被认为向量距离相近,但事实上只是交付时间相近: 南内环西街与西苑南路交叉口金昌盛国会<=>辰憬家园迎泽西大街西苑南路路口林香斋酒店

若是想要针对更为复杂的目标和引入更多信息,可使用End-to-End框架;只是计算文本类似性,从实验结果看,Word2Vec更好一些。同时,经过查看Case也能够发现,End-to-End更关注结果类似性,从而召回一部分语义上彻底不相关的向量。两个模型目标上的不一样,从而致使告终果的差别。

4. 总结与展望

在本篇中,依次展现了在配送交付场景下的三次模型策略迭代过程,以及在较为苛刻性能要求限制下,如何用轻量化的方案不断提升召回率及效果。同时,对迭代过程当中的性能进行简单的分析及衡量,这对相关的项目也具有必定的借鉴意义,最后对Word2Vec及End-to-End生成的向量进行了比较。

事实上,本文中说起的向量召回及深度学习融合非数值型特征的方案,已经在业界被普遍使用。但对于差别化的场景,本文仍具有必定的借鉴价值,特别是对于订单-骑手匹配、订单-订单匹配等非搜索推荐领域的场景化应用,以及TF OP算子的选用及分析、Embedding生成方式带来的差别,但愿可以给你们提供一些思路和启发。

5. 关联阅读

交付时间预估与ETA预估及配送其余业务关系:

6. 做者介绍

  • 基泽,美团点评技术专家
  • 闫聪,美团点评算法工程师

7. 招聘信息

美团配送AI团队支撑全球领先的即时配送网络——美团配送,并创建了行业领先的美团智能配送系统。美团配送AI团队主要来自一线互联网公司以及知名科研机构,研发实力和氛围卓越。目前美团配送业务仍处于快速发展期,新的场景、新的技术难题不断涌现,成长空间巨大。

美团配送AI团队现诚聘算法策略工程师、机器学习工程师和运筹优化工程师,欢迎有兴趣的小伙伴投递简历至:tech@meituan.com(邮件标题注明:美团配送AI团队)

相关文章
相关标签/搜索