文章目录
本文转载自:https://www.jianshu.com/p/d40d6861694f。
本文来自美团技术研究院
AI是目前互联网行业炙手可热的“明星”,
无论是老牌巨头
,
还是流量新贵
,
都在大力研发AI技术,
为自家的业务赋能。
配送
作为外卖平台闭环链条
上重要的一环,
配送效率
和用户体验
是配送业务的核心竞争力
。
随着单量上涨、骑手增多、配送场景复杂化,
配送场景的各种算法在
更快(算法需要快速迭代、快速上线)、
更好(业务越来越依赖机器学习算法
产生正向的效果)、
更准(算法的各种预测
如预计送达时间
等,需要准确逼近真实值)
的目标下也面临日益增大的挑战。
算法从调研到最终上线发挥作用,
需要有一系列的工程开发和对接,
由此引发了新的问题:
如何界定算法和工程的边界,各司其职,各善其长?
如何提升算法迭代上线的速度
和效率?
如何快速准确评估算法的效果
?
本文将为大家分享美团配送技术团队
在
建设一站式机器学习平台
过程中的一些经验和探索,
希望对大家能有所帮助或者启发。
1、业务背景
2019年7月份,
美团外卖的日订单量已经突破3000万单,
占有了相对领先的市场份额。
围绕着用户、商户、骑手,
美团配送构建了全球领先的即时配送网络
,
建设了行业领先的美团智能配送系统
,
形成了全球规模最大的外卖配送平台
。
如何让配送网络运行效率更高,
用户体验更好,
是一项非常有难度的挑战。
我们需要解决大量复杂的机器学习
和运筹优化
等问题,
包括
- ETA预测
- 智能调度
- 地图优化
- 动态定价
- 情景感知
- 智能运营
等多个领域。
同时,我们还需要在
- 体验
- 效率
- 成本
之间达到平衡。
2、美团配送机器学习平台演进过程
2.1、为什么建设一站式机器学习平台
如果要解决上述的机器学习问题,
就需要有一个功能强大且易用的机器学习平台
来辅助算法研发人员,
帮助大家脱离繁琐的工程化开发
,
把有限的精力聚焦于算法策略的迭代
上面。
目前业界比较优秀的机器学习平台有很多,
既有大公司研发的商用产品,
如
- 微软的Azure
- 亚马逊的SageMaker
- 阿里的PAI平台
- 百度的PaddlePaddle
- 腾讯的TI平台
也有很多开源的产品,
如
- 加州大学伯克利分校的Caffe
- Google的TensorFlow
- Facebook的PyTorch
- Apache的Spark MLlib
等。
而开源平台
大都是机器学习
或者深度学习基础计算框架
,
聚焦于训练机器学习或深度学习模型
;
公司的商用产品则是基于基础的机器学习和深度学习计算框架
进行二次开发
,
提供一站式的生态化的服务
,
为用户提供从
- 数据预处理
- 模型训练
- 模型评估
- 模型在线预测
的全流程开发和部署支持,
以期降低算法同学的使用门槛。
公司级的一站式机器学习平台
的目标和定位,
与我们对机器学习平台的需求不谋而合:
- 为用户提供端到端的一站式的服务,帮助他们脱离繁琐的工程化开发,把有限的精力聚焦于算法策略的迭代上面。
鉴于此,美团配送的一站式机器学习平台应运而生。
美团配送机器学习平台的演进过程可以分为两个阶段:
MVP阶段
:灵活,快速试错,具备快速迭代能力。平台化阶段
:- 业务成指数级增长,需要机器学习算法的场景越来越多
- 如何既保证业务发展,又能解决系统可用性、扩展性、研发效率等问题。
2.2、MVP阶段
初始阶段,大家对机器学习平台要发展成什么样子并不明确,很多事情也想不清楚。
但是为了支撑业务的发展,必须快速上线、快速试错。
因此,在此阶段,各个业务线独自建设自己的机器学习工具集
,
按照各自业务的特殊需求进行各自迭代,
快速支持机器学习算法上线落地应用到具体的业务场景,
也就是我们所熟知的“烟囱模式”
。
此种模式各自为战,非常灵活,
能够快速支持业务的个性化需求,
为业务抢占市场赢得了先机。
但随着业务规模的逐渐扩大,
这种“烟囱模式”的缺点就凸显了出来,
主要表现在以下两个方面:
-
重复造轮子:
- 特征工程
- 模型训练
- 模型在线预测
- 都是各自研发,从零做起,算法的迭代效率低下。
-
特征口径混乱:
- 各个业务方
重复开发特征
,相同特征的统计口径也不一致,导致算法之间难以协同工作。
- 各个业务方
2.3、平台化阶段
为了避免各部门重复造轮子,
提升研发的效率,
同时统一业务指标
和特征的计算口径
,
标准化配送侧的数据体系,
美团配送的研发团队组建了一个算法工程小组
,
专门规整各业务线的机器学习工具集
,
希望建设一个统一的机器学习平台,
其需求主要包括以下几个方面:
- 该平台底层依托于
Hadoop/Yarn
进行资源调度管理
,集成了- Spark ML
- XGBoost
- TensorFlow
- 三种机器学习框架,并保留了扩展性,方便接入其它机器学习框架,
- 如美团自研的
MLX
- 超大规模机器学习平台
- 专为搜索、推荐、广告等排序问题定制
- 支持
百亿级特征
和流式更新
- 通过对Spark ML、XGBoost、TensorFlow机器学习框架的封装,
- 我们实现了
可视化离线训练平台
, - 通过拖拉拽的方式生成
DAG图
, - 屏蔽多个训练框架的差异,
- 统一模型训练和资源分配,
- 降低了算法RD的接入门槛。
- 我们实现了
- 模型管理平台
- 提供统一的模型
注册
、发现
、部署
、切换
、降级
等解决方案, - 并为机器学习和深度学习模型
实时计算
提供高可用在线预测服务
。
- 提供统一的模型
- 离线特征平台
- 收集分拣线下日志,计算提炼成
算法所需要的特
征,并将线下的特征应用到线上。
- 收集分拣线下日志,计算提炼成
- 实时特征平台
- 实时收集线上数据,计算提炼成
算法所需要的特征
,并实时推送应用到线上。
- 实时收集线上数据,计算提炼成
- 版本管理平台
- 管理算法的版本以及算法版本所用的
模型
、特征
和参数
。
- 管理算法的版本以及算法版本所用的
- AB实验平台
- 通过科学的分流和评估方法,更快更好地验证算法的效果。
3、图灵平台
平台化阶段,我们对美团配送机器学习平台的目标定位是:
一站式机器学习平台,给算法同学提供一站式服务,覆盖算法同学
- 调研
- 开发
- 上线
- 评估算法效果
的全流程,
包括:
- 数据处理
- 特征生产
- 样本生成
- 模型训练
- 模型评估
- 模型发布
- 在线预测和效果评估
为了响应这个目标,
大家还给平台取了个大胆的名字——Turing,
中文名称为图灵平台,
虽然有点“胆大包天”,
但是也算是对我们团队的一种鞭策。
- 1)首先在获取数据阶段,支持在线和离线两个层面的处理,分别通过
- 采样
- 过滤
- 归一化
- 标准化
- 等手段生产
实时和离线特征
,并推送到在线的特征库
,供线上服务使用。
- 2)模型训练阶段,支持
分类
、回归
、聚类
、深度学习
等多种模型,并支持自定义Loss损失函数
。 - 3)模型评估阶段,支持多种评估指标,如
AUC
、MSE
、MAE
、F1
等。 - 4)模型发布阶段,提供
一键部署功能
,支持本地
和远程
两种模式- 分别对应将模型部署在
业务服务本地
和部署在专用的在线预测集群
。
- 分别对应将模型部署在
- 5)在线预测阶段,支持AB实验,灵活的
灰度发布放量
,并通过统一埋点日志
实现AB实验效果评估。
3.1、离线训练平台
离线训练平台的目标是:
- 搭建可视化训练平台,屏蔽多个训练框架的差异,降低算法RD的接入门槛。
为了降低算法RD进入机器学习领域的门槛,
我们开发了带有可视化界面的离线训练平台,
通过各种组件的拖拉拽组合成DAG图,
从而生成一个完整的机器学习训练任务。
目前支持的组件大致分为:
- 输入
- 输出
- 特征预处理
- 数据集加工
- 机器学习模型
- 深度学习模型
等几大类,
每种类别都开发了多个不同的组件,
分别支持不同的应用场景。
同时为了不失去灵活性,
我们也花费了一番心思,
提供了多种诸如
- 自定义参数
- 自动调参
- 自定义Loss函数
等功能,
尽量满足各个不同业务方向算法同学各种灵活性的需求。
我们的离线训练平台在产出模型时,
除了产出模型文件
之外,
还产出了一个MLDL(Machine Learning Definition Language)文件
,
将各模型的所有预处理模块信息
写入MLDL文件
中,
与模型保存在同一目录中。
当模型发布时,
模型文件
连带MLDL文件
作为一个整体共同发布到线上。
在线计算时,
先自动执行MLDL中的预处理逻辑
,
然后再执行模型计算逻辑
。
通过MLDL打通了离线训练
和在线预测
,
贯穿整个机器学习平台,
使得线下
和线上
使用同一套特征预处理框架代码
,
保证了线下和线上处理的一致性。
在发布模型时,
我们还提供了模型绑定特征
功能,
支持用户把特征和模型的入参
关联起来,
方便在线预测时
模型自动获取特征,
极大地简化了算法RD构造模型输入时
获取特征的工作量。
3.2、模型管理平台
前面介绍了,
我们的图灵平台集成了Spark ML、XGBoost、TensorFlow三种底层训练框架,
基于此,
我们的训练平台产出的机器学习模型种类
也非常多,
简单的有
- LR
- SVM,
树模型有
- GBDT
- RF
- XGB
等,
深度学习模型有
- RNN
- DNN
- LSTM
- DeepFM
等等。
而我们的模型管理平台的目标就是提供统一的
- 模型注册
- 发现
- 部署
- 切换
- 降级
等解决方案,
并为机器学习和深度学习模型
提供高可用的线上预测服务
。
模型管理平台支持本地
和远程
两种部署模式:
- 本地:
模型和MLDL
统一推送到业务方服务节点
上,同时图灵平台提供一个Java的Lib包
,嵌入到业务方应用
中,业务方通过本地接口
的方式调用模型计算
。 - 远程:图灵平台维护了一个专用的
在线计算集群
,模型和MLDL统一部署到在线计算集群
中,业务方应用通过RPC接口
调用在线计算服务
进行模型计算
。
-
对于超大规模模型,单机无法装载,需要对模型进行
Sharding
。- 鉴于美团配送的业务特性,可以按照
配送城市/区域
进行分区训练
,每个城市或区域产出一个小模型, - 多个
分区模型
分散部署到多个节点上,解决单节点无法装载大模型的问题。 - 分区模型要求我们必须提供
模型的路由功能
,以便业务方精准地找到部署相应分区模型的节点。
- 鉴于美团配送的业务特性,可以按照
-
同时,
模型管理平台
还收集各个服务节点的心跳上报信息
,维护模型的状态和版本切换
,确保所有节点上模型版本一致。
3.3、离线特征平台
配送线上业务每天会记录许多骑手、商家、用户等维度的数据,
这些数据经过ETL处理
得到所谓的离线特征
,
算法同学利用这些离线特征训练模型
,
并在线上利用这些特征进行模型在线预测
。
离线特征平台
就是将存放在Hive表中的离线特征数据生产到线上,
对外提供在线获取离线特征的服务能力
,
支撑配送各个业务高并发及算法快速迭代。
最简单的方案,
直接把离线特征
存储到DB中,
线上服务直接读取DB获取特征Value
。
读取DB是个很重的操作,
这种方案明显不能满足互联网大并发的场景,
直接被Pass掉。
第二种方案,
把各个离线特征
作为K-V结构存储到Redis
中,
线上服务直接根据特征Key读取Redis获取特征Value。
此方案利用了Redis内存K-V数据库的高性能,
乍一看去,好像可以满足业务的需求,
但实际使用时,
也存在着严重的性能问题。
典型的业务场景:
比如我们要预测20个商家的配送时长,
假设每个商家需要100个特征,
则我们就需要20*100=2000个特征进行模型计算
,
2000个KV。
如果直接单个获取,满足不了业务方的性能需求;
如果使用Redis提供的批量接口Mget
,如果每次获取100个KV,则需要20次Mget。
缓存mget的耗时TP99
约5ms,20次Mget,TP99接近100ms,也无法满足业务方的性能需求(上游服务超时时间约50ms)。
因此,我们需要对离线特征从存储和获取进行优化。
我们提出了特征组
的概念,
同一维度的特征,
按照特征组的结构进行聚合成一个KV,
大大减少了Key的数目;
并且提供了相对完善的管理功能,
支持对特征组的动态调整(组装、拆分等)。
3.4、实时特征平台
相比于传统配送,
即时配送无论是在位置信息、骑手负载,
还是在当前路网情况,
以及商家出餐情况等方面都是瞬息变化的,
实时性要求非常高。
为了让机器学习算法能够即时的在线上生效,
我们需要实时地收集线上各种业务数据,
进行计算,
提炼成算法所需要的特征,
并实时更新。
3.5、AB实验平台
AB实验并不是个新兴的概念,
自2000年谷歌工程师将这一方法应用在互联网产品以来,
AB实验在国内外越来越普及,
已成为互联网产品运营精细度
的重要体现。
简单来说,
AB实验在产品优化中的应用方法是:
在产品正式迭代发版之前,
为同一个目标制定两个(或以上)方案,
将用户流量对应分成几组,
在保证每组用户特征相同的前提下,
让用户分别看到不同的方案设计,
根据几组用户的真实数据反馈,
科学的帮助产品进行决策。
互联网领域常见的AB实验,
大多是面向C端用户进行流量选择,
比如基于注册用户的UID或者用户的设备标识(移动用户IMEI号/PC用户Cookie)进行随机或者哈希计算后分流。
此类方案广泛应用于搜索
、推荐
、广告
等领域,
体现出千人千面个性化的特点。
此类方案的特点是实现简单,
假设请求独立同分布,
流量之间独立决策,
互不干扰。
此类AB实验之所以能够这样做是因为:
C端流量比较大,
样本足够多,
而且不同用户之间没有相互干扰,
只要分流时足够随机,
即基本可以保证请求独立同分布。
即时配送领域的AB实验是围绕用户、商户、骑手三者进行,
用户/商户/骑手之间不再是相互独立的,
而是相互影响相互制约的。
针对此类场景,
现有的分流方案会造成不同策略的互相干扰,
无法有效地评估各个流量各个策略的优劣。
鉴于上述的问题,
我们将配送侧的AB实验分为三个阶段:
-
事前的AA分组
-
事中的AB分流
-
事后的效果评估。
-
AA分组
- 将候选流量按照既定的规则预先分为
对照组
和实验组
- 基于数理统计的理论确保对照组和实验组
- 在所关注的业务指标上没有显著差异。
- 将候选流量按照既定的规则预先分为
-
AB分流
- 将线上请求实时分到对照或者实验版本。
-
效果评估
- 根据对照组和实验组的数据对比评估AB实验的效果。
由于即时配送的场景较为特殊,
比如按照配送区域或城市进行AB实验时,
由于样本空间有限,
很难找到没有差异的对照组和实验组,
因此我们设计了一种分时间片AB对照
的分流方法:
支持按天、小时、分钟进行分片,
多个时间片进行轮转切换,
在不同区域、不同时间片之间,
对不同的策略进行交替切换进行AB分流,
最大限度减少线下因素的影响,
确保实验科学公正。
4、总结与展望
目前图灵平台支撑了
- 美团配送
- 小象
- LBS平台
等BU的算法离线训练、在线预测、AB实验等,
使算法RD更加关注算法策略本身的迭代优化,
显著提高了算法RD的效率。
未来我们会在以下方面继续深入探索:
- 1)加强深度学习的建设。
- 加强深度学习的建设,
- 全面支持深度学习,
- 实现深度学习相关组件与机器学习组件一样
- 在可视化界面可以和任意组件组合使用。
- 离线训练支持更多常用深度学习模型。
- 支持直接写Python代码自定义深度学习模型。
- 2)
在线预测平台化
,进一步解耦算法和工程。- 简化图灵平台SDK
- 剥离主体计算逻辑
- 建设在线预测平台。
- 在线预测平台动态加载算法包
- 实现算法、业务工程方、图灵平台的解耦。
- 作者简介
- 艳伟
- 美团配送技术团队资深技术专家。