0. 写在前面

AI 目前在互联网行业中非常受欢迎，就像“明星”一样。无论是那些历史悠久的巨头企业，还是新崛起的流量大户，都在积极投入大量精力研发 AI 技术，以便为自己的业务增添力量。配送在外卖平台完整的闭环链条中是一个重要的部分，而配送效率以及用户体验则是配送业务的关键竞争力所在。随着单量的上升，骑手数量的增多，配送场景变得更加复杂。在这些情况下，配送场景的各种算法面临着越来越大的挑战。这些算法需要快速迭代和快速上线，以满足业务需求。同时，业务也越来越依赖机器学习算法来产生正向的效果。此外，算法的各种预测，如预计送达时间等，需要准确逼近真实值。算法从开始调研到最终上线发挥作用，这期间需要进行一系列的工程开发和对接工作，由此产生了新的问题：一是怎样界定算法和工程的边界，让它们各自发挥职责，展现长处；二是如何提升算法迭代上线的速度和效率；三是怎样快速准确地评估算法的效果。本文将为大家分享美团配送技术团队在建设一站式机器学习平台过程中的一些经验和探索，期望能给大家带来帮助或启发。

1. 业务背景

2019 年 7 月，美团外卖的日订单量达到了 3000 万单以上。它占有了较为领先的市场份额。美团配送围绕着用户、商户、骑手这三个方面，构建起了全球领先的即时配送网络。同时，还建设了行业领先的美团智能配送系统。这样就形成了全球规模最大的外卖配送平台。

让配送网络运行效率更高且用户体验更好，这是一项极具难度的挑战。我们得解决诸多复杂的机器学习以及运筹优化等方面的问题，涵盖 ETA 预测、智能调度、地图优化、动态定价、情景感知、智能运营等多个领域。与此同时，我们还需在体验、效率与成本之间实现平衡。

2.1 要明确为何建设一站式机器学习平台。

要解决上述的机器学习问题，就需要一个机器学习平台。这个平台要功能强大且易用，以便辅助算法研发人员。它能帮助大家摆脱繁琐的工程化开发，让大家把有限的精力集中在算法策略的迭代上。

目前业界有很多比较优秀的机器学习平台。其中有大公司研发的商用产品，像微软的（具体产品未提及）、亚马逊的（具体产品未提及）、阿里的 PAI 平台、百度的（具体产品未提及）以及腾讯的 TI 平台。同时也有很多开源的产品，比如加州大学伯克利分校的（具体产品未提及）、（具体机构）的（具体产品未提及）、（具体机构）的（具体产品未提及）以及（具体机构）的（具体产品未提及）等。开源平台大多属于机器学习或深度学习的基础计算框架，其重点在于训练机器学习或深度学习模型；公司的商用产品是以基础的机器学习和深度学习计算框架为基础进行二次开发，能够提供一站式的生态化服务，为用户在数据预处理、模型训练、模型评估、模型在线预测等全流程的开发和部署方面提供支持，目的是降低算法同学的使用门槛。

公司级的一站式机器学习平台，其目标和定位与我们对机器学习平台的需求相契合。它能为用户提供端到端且一站式的服务，有助于用户摆脱繁琐的工程化开发，让他们可以将有限的精力集中在算法策略的迭代上。基于此情况，美团配送的一站式机器学习平台便随之产生了。

美团配送机器学习平台的演进过程可以分为两个阶段：

2.2 MVP 阶段

初始阶段，大家对于机器学习平台的未来发展形态并不清晰，许多事情也难以想得明白。然而，为了推动业务的发展，必须尽快上线并快速尝试错误。所以，在这个阶段，各个业务线分别建设自己的机器学习工具集，依据各自业务的特殊需求进行各自的迭代，以便迅速支持机器学习算法上线并应用到具体的业务场景中，这就是我们所熟知的“烟囱模式”。此种模式是各自为战的，它非常灵活，能够迅速地支持业务的个性化需求，从而为业务抢占市场赢得了先机。然而，随着业务规模逐渐地扩大，这种“烟囱模式”的缺点便凸显了出来，主要在以下两个方面有所体现：

2.3 平台化阶段

美团配送的研发团队组建了一个算法工程小组，目的是避免各部门重复造轮子，提升研发效率，并且统一业务指标和特征的计算口径，标准化配送侧的数据体系。这个小组专门负责规整各业务线的机器学习工具集，希望建设一个统一的机器学习平台，其需求主要涵盖以下几个方面。

3. 图灵平台

具体包括：数据处理、特征生产、样本生成、模型训练、模型评估、模型发布、在线预测和效果评估。为响应这个目标，大家给平台取了个大胆的名字，中文名叫图灵平台。这个名字虽有点“胆大包天”，但也算是对我们团队的一种鞭策。

首先在获取数据时，有在线和离线两个层面的处理。通过采样等手段生产实时特征，通过过滤等手段生产离线特征，然后将这些特征归一化、标准化等，接着推送到在线的特征库，以供线上服务使用。

模型在训练阶段，具备支持分类的功能，也具备支持回归的功能，还具备支持聚类的功能以及支持深度学习的功能等多种模型类型。并且，它还支持自定义 Loss 损失函数。

模型评估阶段，能够支持多种评估指标。其中包括 AUC 这种评估指标。还包括 MSE 这种评估指标。也包括 MAE 这种评估指标。同时还包括 F1 等评估指标。

模型在发布阶段，具备一键部署的功能。此功能支持本地和远程两种模式，本地模式是将模型部署在业务服务本地，远程模式则是部署在专用的在线预测集群。

在线预测阶段，具备支持 AB 实验的能力，能够进行灵活的灰度发布放量，并且可以通过统一埋点日志来实现对 AB 实验效果的评估。

3.1 离线训练平台

离线训练平台的目标包括：搭建起可视化的训练平台；将多个训练框架的差异进行屏蔽；降低算法 RD 的接入门槛。

我们开发了带有可视化界面的离线训练平台，目的是降低算法 RD 进入机器学习领域的门槛。通过拖拉拽各种组件，将它们组合成 DAG 图，这样就能生成一个完整的机器学习训练任务。

每种类别都研发了多个不同的组件，这些组件分别能够支持不同的应用场景。我们为了不失去灵活性，花费了心思，提供了多种功能，比如自定义参数、自动调参、自定义 Loss 函数等，以尽量满足各个不同业务方向算法同学对灵活性的需求。

我们的离线训练平台产出模型时，一方面产出模型文件，另一方面产出一个 MLDL（ ）文件，把各模型的所有预处理模块信息写入该 MLDL 文件里，并且让它与模型保存在同一个目录中。当模型进行发布时，模型文件和 MLDL 文件会一起作为一个整体发布到线上。在线计算时，首先会自动执行 MLDL 里的预处理逻辑，接着再执行模型计算逻辑。借助 MLDL，实现了离线训练与在线预测的打通，其贯穿了整个机器学习平台，这样一来，线下和线上都能使用同一套特征预处理框架代码，从而保证了线下和线上处理的一致性。

发布模型时，我们提供了模型绑定特征功能。此功能支持用户将特征与模型的入参关联起来。这样在进行在线预测时，模型能自动获取特征。这极大地简化了算法 RD 构造模型输入时获取特征的工作量。

3.2 模型管理平台

我们的图灵平台集成了 ML 等三种底层训练框架。基于此，我们的训练平台产出的机器学习模型种类繁多。其中简单的有 LR 和 SVM。树模型包括 GBDT、RF 和 XGB 等。深度学习模型有 RNN、DNN、LSTM 等。我们的模型管理平台旨在提供一系列解决方案，包括统一的模型注册、发现、部署、切换以及降级等。同时，它还能为机器学习和深度学习模型提供高可用的线上预测服务。

模型管理平台支持本地和远程两种部署模式：

超大规模模型单机无法装载，所以需要对模型进行处理。因为美团配送具有业务特性，所以可以按照配送城市/区域来进行分区训练。每个城市或区域会产出一个小模型，多个分区模型会分散部署到多个节点上，这样就能解决单节点无法装载大模型的问题。分区模型要求我们必须提供模型的路由功能，这样业务方就能精准地找到部署相应分区模型的节点。

模型管理平台会收集各个服务节点的心跳上报信息。它会维护模型的状态。它会进行版本切换。这样做是为了确保所有节点上的模型版本一致。

3.3 离线特征平台

配送线上业务每天会记录骑手的数据、商家的数据、用户的数据等多个维度的数据。这些数据经过 ETL 处理后，就得到了所谓的离线特征。算法同学利用这些离线特征来训练模型，并且在线上利用这些特征进行模型在线预测。离线特征平台的作用是把存于 Hive 表内的离线特征数据生产到线上，能够对外提供在线获取离线特征的服务能力，以此来支撑配送的各个业务实现高并发以及算法的快速迭代。

最简单的方案是直接将离线特征存储到 DB 里，线上服务能够直接读取 DB 来获取特征。读取 DB 属于一个很繁重的操作，这种方案显然无法满足互联网大并发的场景，所以直接被舍弃了。

第二种方案，将各个离线特征以 K-V 结构存储在某个地方。线上服务能够依据特征 Key 直接进行读取，从而获取特征。此方案借助了内存 K-V 数据库的高性能，乍一看似乎能够满足业务的需求，然而在实际使用过程中，却存在着较为严重的性能问题。

典型的业务场景如下：我们要预测 20 个商家的配送时长。假设每个商家需要 100 个特征，那么我们就需要 20 乘以 100 等于 2000 个特征来进行模型计算，也就是 2000 个 KV。如果直接单个获取的话，无法满足业务方的性能需求。如果使用提供的批量接口 Mget，每次获取 100 个 KV 的话，就需要 20 次 Mget。缓存 mget 的耗时 TP99 大约是 5ms，20 次 Mget 的 TP99 接近上游服务超时时间（约 50ms），所以也无法满足业务方的性能需求。

我们需要对离线特征的存储和获取方面进行优化。我们提出了特征组这一概念，将同一维度的特征按照特征组的结构聚合成一个 KV，这样就大大减少了 Key 的数量。同时，我们还提供了相对完善的管理功能，能够支持对特征组进行动态调整，比如组装、拆分等操作。

3.4 实时特征平台

传统配送与之相比，即时配送在位置信息方面是瞬息变化的，骑手负载也是如此，当前路网情况如此，商家出餐情况同样如此，实时性要求极高。为使机器学习算法能即时在线上生效，我们需实时收集线上各种业务数据，进行计算，提炼出算法所需特征并实时更新。

3.5 AB 实验平台

AB 实验并非是一个新兴的概念。2000 年，谷歌工程师把这一方法应用到了互联网产品上。从那之后，AB 实验在国内外越来越普及，并且已经成为互联网产品运营精细度的重要体现。最后，根据几组用户的真实数据反馈，科学地帮助产品进行决策。

互联网领域常见的 AB 实验，大多是针对 C 端用户来进行流量选择。例如会依据注册用户的 UID ，或者依据用户的设备标识（像移动用户的 IMEI 号，PC 用户的 ），进行随机或者哈希计算之后进行分流。这类方案在搜索、推荐、广告等领域被广泛应用，体现出了千人千面个性化的特点。此类方案的特点在于实现较为简单，它假设请求是独立同分布的，并且流量之间能够独立决策，互不干扰。此类 AB 实验之所以能够如此操作，是因为 C 端流量较大，样本数量充足，而且不同用户之间不存在相互干扰的情况，只要在分流时足够随机，就基本上能够保证请求是独立同分布的。

即时配送领域进行 AB 实验，是围绕着用户、商户、骑手这三者展开的。用户与商户、骑手之间不是相互独立的，而是相互影响且相互制约的。对于这样的场景，现有的分流方案会导致不同策略相互干扰，不能够有效地对各个流量以及各个策略的优劣进行评估。

因为上述的这些问题，我们把配送侧的 AB 实验划分成了三个不同的阶段。其中一个阶段是事前的 AA 分组，另一个阶段是事中的 AB 分流，还有一个阶段是事后的效果评估。

即时配送的场景较为特殊。例如在按照配送区域或城市进行 AB 实验时，因为样本空间有限，很难找到没有差异的对照组和实验组。所以我们设计了一种分时间片 AB 对照的分流方法，此方法支持按天、小时、分钟进行分片，多个时间片会轮转切换，在不同区域以及不同时间片之间，会对不同的策略进行交替切换以进行 AB 分流，这样能最大限度减少线下因素的影响，从而确保实验科学公正。

4 总结与展望

目前图灵平台对美团配送、小象、LBS 平台等 BU 进行了算法离线训练、在线预测、AB 实验等方面的支撑。这使得算法 RD 能够更加专注于算法策略本身的迭代优化。同时，也显著提升了算法 RD 的效率。未来，我们将在以下方面继续深入进行探索：

1）加强深度学习的建设。

2）在线预测平台化，进一步解耦算法和工程。

作者介绍：

艳伟，美团配送技术团队资深技术专家。

本文转载自公众号美团技术团队（ID：）。

原文链接：