带艳伟网名——伟和艳字组成的网名

2022-12-18 03:27:31 发布在网名大全

作者 | 艳伟，美团配送技术团队资深技术专家

责编 | 唐小引

封图 | CSDN 下载自东方 IC

本文为美团技术团队投稿

AI 是目前互联网行业炙手可热的“明星”，无论是老牌巨头，还是流量新贵，都在大力研发 AI 技术，为自家的业务赋能。配送作为外卖平台闭环链条上重要的一环，配送效率和用户体验是配送业务的核心竞争力。随着单量上涨、骑手增多、配送场景复杂化，配送场景的各种算法在更快（算法需要快速迭代、快速上线）、更好（业务越来越依赖机器学习算法产生正向的效果）、更准（算法的各种预测如预计送达时间等，需要准确逼近真实值）的目标下也面临日益增大的挑战。

算法从调研到最终上线发挥作用，需要有一系列的工程开发和对接，由此引发了新的问题：如何界定算法和工程的边界，各司其职，各善其长？如何提升算法迭代上线的速度和效率？如何快速准确评估算法的效果？本文将为大家分享美团配送技术团队在建设一站式机器学习平台过程中的一些经验和探索，希望对大家能有所帮助或者启发。

业务背景

2019 年 7 月份，美团外卖的日订单量已经突破 3000 万单，占有了相对领先的市场份额。围绕着用户、商户、骑手，美团配送构建了全球领先的即时配送网络，建设了行业领先的美团智能配送系统，形成了全球规模最大的外卖配送平台。

如何让配送网络运行效率更高，用户体验更好，是一项非常有难度的挑战。我们需要解决大量复杂的机器学习和运筹优化等问题，包括 ETA 预测、智能调度、地图优化、动态定价、情景感知、智能运营等多个领域。同时，我们还需要在体验、效率和成本之间达到平衡。

美团配送机器学习平台演进过程

为什么建设一站式机器学习平台？

如果要解决上述的机器学习问题，就需要有一个功能强大且易用的机器学习平台来辅助算法研发人员，帮助大家脱离繁琐的工程化开发，把有限的精力聚焦于算法策略的迭代上面。

目前业界比较优秀的机器学习平台有很多，既有大公司研发的商用产品，如微软的 Azure、亚马逊的 SageMaker、阿里的 PAI 平台、百度的 PaddlePaddle 以及腾讯的 TI 平台，也有很多开源的产品，如加州大学伯克利分校的 Caffe、Google 的 TensorFlow、Facebook 的 PyTorch 以及 Apache 的 Spark MLlib 等。而开源平台大都是机器学习或者深度学习基础计算框架，聚焦于训练机器学习或深度学习模型；公司的商用产品则是基于基础的机器学习和深度学习计算框架进行二次开发，提供一站式的生态化的服务，为用户提供从数据预处理、模型训练、模型评估、模型在线预测的全流程开发和部署支持，以期降低算法同学的使用门槛。

公司级的一站式机器学习平台的目标和定位，与我们对机器学习平台的需求不谋而合：为用户提供端到端的一站式的服务，帮助他们脱离繁琐的工程化开发，把有限的精力聚焦于算法策略的迭代上面。鉴于此，美团配送的一站式机器学习平台应运而生。

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

MVP 阶段：灵活，快速试错，具备快速迭代能力。
平台化阶段：业务成指数级增长，需要机器学习算法的场景越来越多，如何既保证业务发展，又能解决系统可用性、扩展性、研发效率等问题。

MVP 阶段

初始阶段，大家对机器学习平台要发展成什么样子并不明确，很多事情也想不清楚。但是为了支撑业务的发展，必须快速上线、快速试错。因此，在此阶段，各个业务线独自建设自己的机器学习工具集，按照各自业务的特殊需求进行各自迭代，快速支持机器学习算法上线落地应用到具体的业务场景，也就是我们所熟知的“烟囱模式”。此种模式各自为战，非常灵活，能够快速支持业务的个性化需求，为业务抢占市场赢得了先机。但随着业务规模的逐渐扩大，这种“烟囱模式”的缺点就凸显了出来，主要表现在以下两个方面：

重复造轮子：

特征工程、模型训练、模型在线预测都是各自研发，从零做起，算法的迭代效率低下。

特征口径混乱：

各个业务方重复开发特征，相同特征的统计口径也不一致，导致算法之间难以协同工作。

平台化阶段

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

该平台底层依托于 Hadoop/Yarn 进行资源调度管理，集成了 Spark ML、XGBoost、TensorFlow 三种机器学习框架，并保留了扩展性，方便接入其它机器学习框架，如美团自研的 MLX（超大规模机器学习平台，专为搜索、推荐、广告等排序问题定制，支持百亿级特征和流式更新）。
通过对 Spark ML、XGBoost、TensorFlow 机器学习框架的封装，我们实现了可视化离线训练平台，通过拖拉拽的方式生成 DAG 图，屏蔽多个训练框架的差异，统一模型训练和资源分配，降低了算法 RD 的接入门槛。
模型管理平台，提供统一的模型注册、发现、部署、切换、降级等解决方案，并为机器学习和深度学习模型实时计算提供高可用在线预测服务。
离线特征平台，收集分拣线下日志，计算提炼成算法所需要的特征，并将线下的特征应用到线上。
实时特征平台，实时收集线上数据，计算提炼成算法所需要的特征，并实时推送应用到线上。
版本管理平台，管理算法的版本以及算法版本所用的模型、特征和参数。
AB 实验平台，通过科学的分流和评估方法，更快更好地验证算法的效果。

图灵平台

平台化阶段，我们对美团配送机器学习平台的目标定位是：一站式机器学习平台，给算法同学提供一站式服务，覆盖算法同学调研、开发、上线、评估算法效果的全流程，包括：数据处理、特征生产、样本生成、模型训练、模型评估、模型发布、在线预测和效果评估。为了响应这个目标，大家还给平台取了个大胆的名字——Turing，中文名称为图灵平台，虽然有点“胆大包天”，但是也算是对我们团队的一种鞭策。

首先在获取数据阶段，支持在线和离线两个层面的处理，分别通过采样、过滤、归一化、标准化等手段生产实时和离线特征，并推送到在线的特征库，供线上服务使用。
模型训练阶段，支持分类、回归、聚类、深度学习等多种模型，并支持自定义 Loss 损失函数。
模型评估阶段，支持多种评估指标，如 AUC、MSE、MAE、F1 等。
模型发布阶段，提供一键部署功能，支持本地和远程两种模式，分别对应将模型部署在业务服务本地和部署在专用的在线预测集群。
在线预测阶段，支持 AB 实验，灵活的灰度发布放量，并通过统一埋点日志实现 AB 实验效果评估。

离线训练平台

离线训练平台的目标是：搭建可视化训练平台，屏蔽多个训练框架的差异，降低算法 RD 的接入门槛。

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

目前支持的组件大致分为：输入、输出、特征预处理、数据集加工、机器学习模型、深度学习模型等几大类，每种类别都开发了多个不同的组件，分别支持不同的应用场景。同时为了不失去灵活性，我们也花费了一番心思，提供了多种诸如自定义参数、自动调参、自定义 Loss 函数等功能，尽量满足各个不同业务方向算法同学各种灵活性的需求。

我们的离线训练平台在产出模型时，除了产出模型文件之外，还产出了一个 MLDL（Machine Learning Definition Language）文件，将各模型的所有预处理模块信息写入 MLDL 文件中，与模型保存在同一目录中。当模型发布时，模型文件连带 MLDL 文件作为一个整体共同发布到线上。在线计算时，先自动执行 MLDL 中的预处理逻辑，然后再执行模型计算逻辑。通过 MLDL 打通了离线训练和在线预测，贯穿整个机器学习平台，使得线下和线上使用同一套特征预处理框架代码，保证了线下和线上处理的一致性。

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

模型管理平台

前面介绍了，我们的图灵平台集成了 Spark ML、XGBoost、TensorFlow 三种底层训练框架，基于此，我们的训练平台产出的机器学习模型种类也非常多，简单的有 LR、SVM，树模型有 GBDT、RF、XGB 等，深度学习模型有 RNN、DNN、LSTM、DeepFM 等等。而我们的模型管理平台的目标就是提供统一的模型注册、发现、部署、切换、降级等解决方案，并为机器学习和深度学习模型提供高可用的线上预测服务。

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

本地：模型和 MLDL 统一推送到业务方服务节点上，同时图灵平台提供一个 Java 的 Lib 包，嵌入到业务方应用中，业务方通过本地接口的方式调用模型计算。
远程：图灵平台维护了一个专用的在线计算集群，模型和 MLDL 统一部署到在线计算集群中，业务方应用通过 RPC 接口调用在线计算服务进行模型计算。

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

同时，模型管理平台还收集各个服务节点的心跳上报信息，维护模型的状态和版本切换，确保所有节点上模型版本一致。

离线特征平台

配送线上业务每天会记录许多骑手、商家、用户等维度的数据，这些数据经过 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 的数目；并且提供了相对完善的管理功能，支持对特征组的动态调整（组装、拆分等）。

实时特征平台

相比于传统配送，即时配送无论是在位置信息、骑手负载，还是在当前路网情况，以及商家出餐情况等方面都是瞬息变化的，实时性要求非常高。为了让机器学习算法能够即时的在线上生效，我们需要实时地收集线上各种业务数据，进行计算，提炼成算法所需要的特征，并实时更新。

AB 实验平台

AB 实验并不是个新兴的概念，自 2000 年谷歌工程师将这一方法应用在互联网产品以来，AB 实验在国内外越来越普及，已成为互联网产品运营精细度的重要体现。简单来说，AB 实验在产品优化中的应用方法是：在产品正式迭代发版之前，为同一个目标制定两个（或以上）方案，将用户流量对应分成几组，在保证每组用户特征相同的前提下，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，科学的帮助产品进行决策。

互联网领域常见的 AB 实验，大多是面向 C 端用户进行流量选择，比如基于注册用户的 UID 或者用户的设备标识（移动用户 IMEI 号/PC 用户 Cookie）进行随机或者哈希计算后分流。此类方案广泛应用于搜索、推荐、广告等领域，体现出千人千面个性化的特点。此类方案的特点是实现简单，假设请求独立同分布，流量之间独立决策，互不干扰。此类 AB 实验之所以能够这样做是因为：C 端流量比较大，样本足够多，而且不同用户之间没有相互干扰，只要分流时足够随机，即基本可以保证请求独立同分布。

即时配送领域的 AB 实验是围绕用户、商户、骑手三者进行，用户/商户/骑手之间不再是相互独立的，而是相互影响相互制约的。针对此类场景，现有的分流方案会造成不同策略的互相干扰，无法有效地评估各个流量各个策略的优劣。

鉴于上述的问题，我们将配送侧的 AB 实验分为三个阶段：事前的 AA 分组，事中的 AB 分流，事后的效果评估。

AA 分组：将候选流量按照既定的规则预先分为对照组和实验组，基于数理统计的理论确保对照组和实验组在所关注的业务指标上没有显著差异。
AB 分流：将线上请求实时分到对照或者实验版本。
效果评估：根据对照组和实验组的数据对比评估 AB 实验的效果。

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

总结与展望

目前图灵平台支撑了美团配送、小象、LBS 平台等 BU 的算法离线训练、在线预测、AB 实验等，使算法 RD 更加关注算法策略本身的迭代优化，显著提高了算法 RD 的效率。未来我们会在以下方面继续深入探索：

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