一、背景

消费者选择电商平台进行购物，除了独特的商品，购物体验也越来越成为消费者衡量平台的重要标准。如何帮助客户快速的检索到自己想要购买的商品，如何让客户买到性价比最高的商品，如何帮助客户在更短的时间内收到购买的商品，这些都是平台为消费者提供的重要服务。笔者在订单履约时效项目的参与过程中，主要负责通过算法，帮助平台提升订单履约率和准确率。

我们先来直观感受一下时效对体验的影响。从上面 2 张图，我们能够看到，右图订单的交付时效比较长，客户对订单支付意愿就会大大降低，有行业专业人士分析，时效表达多一天，影响的 GMV 就达千万级，可见时效表达越短对应的收益越大，但也会给供应链履约带来更大的成本。从运营的角度，如果想要给消费者更短时效的体验，但却超越了供应链当前的履约能力（比如告知消费者 1 天送达，实际是 3 天），则会带来大量客诉，在得物平台因为有“晚到必赔”规则，会额外增加超时赔付优惠券的负担，引发资损。所以在得物做时效表达，需要同时兼顾时效的准确率（告知消费者 1 天送达，实际也是 1 天）和履约率（告知消费者 1 天送达，实际不超过 1 天）。

在我们长期探索过程中，模型逐渐经历了统计模型、ML 模型、DL 模型的演化。商业环境上也经历了恶劣天气、春节、大促等各种极端场景的考验，算法模型也在一次次的挑战中，变得越来越坚实，并从手工操作逐步实现自动化流程。为了让流程更加高效、稳定，我们引入了 MLOps 的理念，本文抛砖引玉，与大家一起聊聊，我们在结合 MLOps 应用的心路历程，期待能与大家碰撞出思维的火花。

二、什么是 MLOps

附：MLOps 方法论：https://ml-ops.org/content/mlops-principles

MLOps 的核心理念

随着算法模型在工业界的应用越来越深，越来越广，业界逐渐实践出一些标准，让我们能更高效、更稳定、低成本且长久地管理模型的整个生命周期， 涉及模型训练、模型发布、灰度或 AB，及模型的长期监控等等。

其核心理念，主要有以下 7 个方面的模型管理规范：

• Versioning， 数据、模型、代码等是否有版本记录，是否能便捷地回溯；

• Testing， 数据、特征、模型的生成是否有逻辑校验；代码是否有单元测试等；

• Automation，数据、特征的生成是否有自动调度，模型训练、搜参是否自动，代码提交合并是否 CI/CD；

• Reproducibility，基于 Versioning 的保障，是否能在任意时间复现历史某次模型预测结果；

• Deployment，发布在生产、AB、陪跑等环境，是否能保证入参一致性，代码一致性；

• Monitoring，模型精度下降是否能感知，数据漂移、数据泄露等是否会被发现；

• Documentation & Project Structure， 文档、项目结构是否具备可读性，结构性。

MLOps 核心理念落地关键问题

MLOps 的核心理念，应用到业务的过程，并不是一个完全由机器完成，全自动化的过程，而是需要业务团队根据实际业务的情况，不断调整入参，调整模型的过程，会涉及大量的人与机器的交互。因此，如何将这些核心理念应用到具体的业务中，我们需要思考 2 个方面的问题：

算法模型在设计过程中，要保障业务执行的效果

1. 模型复现问题：预测模型是如何生成的，如果模型丢失了，能否重新训练找回丢失的模型？

2. 线上一致性问题线上时效表达时，订单是由哪个模型预测的？同样的入参给到同一个模型预测，是否保持幂等？发布新模型时，如何保障模型上线后的效果符合预期？

3. 模型快速升级问题：线上指标下降了，模型更新流程需要多少人工介入？更新频次的增加，是否带来人工成本线性增长？

如何降低业务使用算法模型的门槛

1. 运营模型的门槛是否可以降低？

2. 业务、产品是否能配置化地训练、选择自己需要的模型？

3. 是否能让更多样化的业务决策能落地，获得更好的业务收益呢？

三、MLOps 关键理念的实践--时效仿真产品

基于上述的思考，我们设计并开发了时效仿真产品，并将 MLOps 的理念融入其中。

模型的可复现性

对于模型训练环节来说，训练集、代码版本和模型参数是三个非常重要的因素。其中代码版本、模型超参可以通过 git 和数据库控制， 比较容易忽略的是训练集的状态，我们通过数据分层和业务日期隔离两种方法确保了训练集的可追溯性。

数据分层，保障数据版本一致性

如下图所示，在训练环节，时效仿真产品的用户可以圈选任意天的订单用作训练。同样圈选了下列日期的样本，站在不同日期训练是不一样的。比如站在 20240903 和 20240902，那么对于 20240901 支付的训练样本，20240903 会比 20240902 多一批已签收订单进入模型训练。越近期的数据越能反映履约网络的变化，一般 20240903 训练得到的模型预测会更准一点。

时效仿真产品-训练样本的圈选

数据分层

这就说明了圈选同样支付日期的订单做训练样本，因为训练日期不同导致已签收订单不同，进而影响实际进入模型训练的样本不同。

针对这个问题，我们做了数据分层，如上右图所示，数仓会将每日订单的最新状态更新完毕， 用户发起仿真任务后，服务端按需取对应订单，通过仿真任务 ID 作为分区，落到训练集和预测集表。随后通过 AI 计算平台调起训练、预测任务，同样传入仿真任务 ID，训练预测任务取相应分区。这样日后需要重新训练，我们能保证同一个仿真任务得到的数据是一样的。

业务日期隔离，防止数据泄露问题

数据分层虽然保障了数据版本的一致性，但时效场景因其特殊性，我们仍可能遇到数据泄露的问题。如下图所示，按经验订单平均在 4 天内能被签收，但是数据上从 20240830 开始订单的签收时间延长了，因为 20240902 是台风摩羯登陆的日子，受到台风天气的影响，签收时间也发生了变化。

针对 20240830~20240901 期间的支付订单，做订单签收时长的时效预测，有一部分订单会在台风前签收，有一部分会在台风后签收，在台风到来前后训练得到的模型是完全不同的，预测的结果也是不同的。

• 在台风前训练，模型平均预测时间就是 4 天，

• 在台风后训练，模型就会预测时间偏长。

如果台风结束后模型没及时调整，那整个时效表达的准确性就会大打折扣，不仅会破坏模型的可复现性，对模型准确性也造成了影响。我们做过测算，在不加干预情况下，台风后预测样本履约率会大幅上升(+2.3pt)，T 日准确率大幅折损(-30.82pt)，模型表达过于保守。

同支付订单 签收区间示意图

如何解决呢？

• 对于可复现性，我们在后台记录了每个仿真任务的执行业务日期， 根据业务执行日期来判断，模型可以看到哪些天已签收订单做训练数据， 这个场景里只要把业务日期固定在台风前，那不管是哪天训练的模型，其效果都是一样的。

• 对于准确性而言，我们希望让模型训练正常日期，预测正常时长，台风、暴雪等异常情况通过 bcp（Business Continuity Planning）加时来保障，台风过后指标能迅速回归正常。基于此，我们在时效仿真产品里设计了订单圈选时间类型，可以按支付或应履约日期来圈选，台风情况就按应履约圈选台风前的样本即可，如下左图。

通过上述的产品设计，我们能保证模型在任意时间训练，任意历史状态下看到的数据都是一致的，为模型可复现性打下了基础。每个模型训练完成后，除了保存模型文件，我们也会记录代码版本、特征、后处理策略等模型必要参数。

线上的一致性保障

当我们得到理想的模型及仿真结果后，接下去要确保安全地上线，如何能确保也是知易行难。仿真可以失败无数次，只要有一次成功就可以，上线却不容许那么多次失败，最好是一次成功。

在时效场景里更特殊的是：

• 随着时间的推移我们的履约网络能力是一个动态变化的过程，相应地模型也需要长期频繁的更新。

• 每次模型上线后，其效果一般要等订单走完支付到签收的生命周期后才能回收效果，一般今天上线的模型，下周才知道线上效果如何。

那么如何保障模型每次更新都是可靠的，通过一段时间的探索，我们找到了模型可靠性三步曲，依靠流量回放、流程保障和自动发布来保障线上模型的效果。

流量回放，确保仿真入参和线上入参一致性，提升模型准确率

我们经常会遇到模型仿真效果很好，但线上陪跑就掉很多精度，排查后发现仿真和线上陪跑的入参存在不一致的情况。比如卖家发货地址、承运商等信息，在支付的时候存在不确定性，线上有入参补齐逻辑，比如用子模型预测，或拿历史众数填充；但仿真时这些信息已成历史，落在表里的是真实数据了。这就导致了线上、线下的入参不一致。

服务端同学为此建设了坚实的流量回放能力。平台不同的业务流程，各环节的预测是不同的。以相对复杂的现货流程为例，需要预测商家发货、头程运输、库内作业和尾程运输，理论上每一段都可以用不同的模型来预测，每一段预测入参都可能不一样。服务端同学设计的统一流量回放能力保障了在每一段的入参、出参、调用模型版本都记录在案，做到了任意订单的可追溯。

复杂的业务流程

统一的流量回放

对应到模型训练、仿真环节， 我们用真实数据做训练， 用线上实际入参来仿真，这样最大化地保障模型精度，减少了仿真与上线之间的精度损失。

流程保障，取得模型稳定性和准确性之间的平衡，最大化业务效果

网络履约能力会受到多种事件变化因素的影响，根据事件因素的特点，大致可分为临时性变化和长久性变化。

• 临时性变化：比如台风恶劣天气、两会管控、春节打烊等事件触发，事件开始时履约能力急剧变差，事件结束后马上又恢复；

• 长久性变化：比如承运商班次调整、仓网变化等，其影响时间较长。

临时性变化不应该放入模型训练， 长久性变化应该让模型去学习，并且越早学习到表达就越准。

如何判断是临时性还是长久性变化呢？如果不加约束，尽量用最新数据训练，难以排除临时性变化影响的样本，这样在事件结束后模型表达会偏保守，如上文的台风后陪跑，会损失指标的稳定性。如果加以约束，用履约已完成的订单做训练，这样可以通过履约时长等统计数据来判断是否属临时性异常，可以减少异常样本的干扰，但也会损失一定准确性。

与产品同学反复沟通了方案后，最终站在业务效果最大化的角度，我们选择在稳定性和准确性之间取其平衡，每周会定时启动较新样本仿真，选其中较优模型进入陪跑，待部分签收后决策是否选择模型上线，详细流程如下图。

模型自动发布，确保模型落地效果

模型的发布涉及到一系列流程，流程中所做的配置和操作，对模型效果会有较大的影响。因此，模型的发布也是非常重要的环节。但模型发布，一般需要等一周后，有部分订单签收，才能看到实际的结果，存在滞后性。在早期曾发生过多起，因为模型发布流程问题，导致模型效果打了折扣，比如新特征模型取错了线上 Redis 特征名、Ark 开关配置错误、模型更新后部分服务器 sdk 未升级等等。基于此，我们建立了模型自动发布流程，将线上逻辑不符合预期的情况提前反映出来。

1. 梳理了模型发布流程图，将发布流程标准化，如下左图所示；

2. 取消发布流程中的手动操作，改为系统自动操作，同时沉淀了 SLA；

3. 接入了模型上线审批流：陪跑回收到符合预期的效果后，需要由业务方决策选用哪个模型上线，模型的上线，将直接决定业务运营的效果和管理成本，为此我们也接入了审批流，如下右图所示；

4. 建立离线陪跑相同模型的方法来验证线上、仿真预测的一致性，离线陪跑的订单及入参通过流量回放获得，两边对比预测结果是否一致；

5. 建立旧模型反向陪跑：尤其模型有新特征或新逻辑的情况下，未来的网络履约能力可能存在较大的波动，如果旧模型直接下线，网络履约能力波动带来的影响将很难，需要有旧模型的陪跑，才能确定是线上逻辑问题，还是网络履约能力变化问题。

发布流程

上线审批流

良好的自动化离不开合理的自动化流程设计，Automation 作为 MLOps 的重要模块，帮助我们较好的解决了手动操作带来的风险和人工成本，在流量回放的一致性验证、模型仿真陪跑流程、发布自动化三方面做的自动化为我们日常低成本运营带来了很大帮助。

模型落地标准化、产品化、自动化，降低业务落地门槛

在模型线上表达比较稳定之后，公司希望在不同的业务场景尝试模型的应用，比如经济型快递独立模型、周末独立模型、支付和应履约模型等，不同的场景应用目的虽然不同，但其底层基础流程大致相同，为了能够让业务根据不同的管理诉求，能够灵活的调整模型训练集，我们跟时效工程、算法工程团队合作，借助 AI 计算平台的调度能力，结合自研的 faas，将模型训练、仿真做成了完全可自助的产品。其大致流程如下：

在产品前端，用户可以按需选择不同的样本，选择灵活性非常大，可以按不同周期、承运商、类目、订单类型、线路等等各种维度来圈选需要训练或仿真的订单。服务端在接受训练、仿真请求后，按需生成训练集和预测集，再调度 AI 计算平台执行相应任务。这里我们通过 faas 解耦与仿真逻辑解析层隔离的方式支撑了产品灵活性和底层架构稳定性。

faas 解耦，提升算法维护模型的灵活性

如下左图，没有 faas，调用 KubeAI 的逻辑非常深地耦合在服务端的代码里，算法同学想要调整这部分配置，就需要服务端同学改代码去发版；

如下右图，有了 faas，服务端只需要关心调用了哪个 function，关键的入参是什么就可以了，其调用如右图。 镜像版本、启动命令、模板 ID 的更新就解耦给到算法同学去维护了，增加了算法迭代灵活性的同时，保障了服务端接口的稳定性。

服务端耦合过多调用 AI 计算平台代码

服务端只关心调用 function 和入参

仿真逻辑解析层隔离，计算任务原子化，适配多种业务场景

业务的需求往往是复杂的，灵活的，多变的，比如：

• 增加多种业务类型如品牌直发、现货；

• 批量训练、预测多个模型择优，不同模型对应不同特征、超参等，最后将较优模型注册到仿真产品；

• 支持多种预测目标，如支付-签收、支付-到仓、发货-签收等不同模型。

面对业务多变的需求，我们需要让计算任务具有原子性，稳定的特点。我们选择在 AI 计算平台实际执行的任务中增加解析层和后处理层的方法，与用户的需求交互，按需生成不同的配置、启动命令来调用 pipline，中间执行的 pipline 是一直稳定的。

如此，我们将工程与算法的交互做了良好的解耦，让工程与算法各司其职；让底层稳定下来，解析层灵动起来。时效仿真产品就变得更敏捷，整个模型的训练、预测可以更高效、自动地运转。

目前，模型的仿真已经基本不需要算法同学介入，极大的解放了研发团队在模型探索业务应用和模型更新上的精力，减少了研发在持续维护模型上的成本。

业务应用效果

综上所述，在保证模型效果的同时，将模型的应用门槛降低，使得产品业务等非研发同学也能参与进模型的应用上来，借助其业务的敏感性和专业性，可以在更多的业务场景中创造进一步价值。

本期我们将为大家介绍，业务在模型使用中，两个比较典型的创新方法，一个是时效 AB 方法，带来了较好的货币化收益，一个是新特征挖掘，显著提升了模型准确率两个典型案例。

时效 AB，货币化收益明显

得物非常重视消费者的购物体验，在时效上，也制定了赔付策略，为用户提供订单时效保障，超时则提供赔付补偿。这套策略提升了客户订单的转化，留存，但也对时效的保障提出了更高的要求，不仅要考虑时效的准确性，还需要兼顾赔付成本和 GMV 收益。如果时效表达过于激进，可能会促转化提高 GMV，但同时增大了订单超时的风险，造成晚到必赔及客诉成本， 表达保守则反之。

那收益和成本之间的平衡点在哪儿呢？

产品同学由此牵头做了 AB 实验，通过仿真产品，我们得到多组履约率和准确率不同的组合，在不同用户 AB 过程中找到了收益和成本之间的平衡点。

新特征挖掘，显著提升模型准确性

业务产品在运营管理中发现，相对日常，周末、节假日期间，部分商家、承运商的网络履约能力会有一定波动，模型预测准确度也会受到影响。

分析后发现，网络履约能力的波动可以由一系列统计指标来刻画，比如昨日支付单量、昨日未揽收单量比例等。那这些指标能否让模型感知到呢？

通过仿真产品测算得到这些指标作为新特征，模型可以显著提升准确率，上线后也能保持相应优势，使得平台在周末、节假日期间也能提供高质量履约服务。

通过产品化降低的使用门槛，我们也期望未来会有更多有意思的场景与产品业务同学共同挖掘，创造更大的价值！

五、延展 scale 的思考

经过近 1 年的建设，供应链算法团队和时效团队配合紧密做了完善的工程建设。但从长远来看，供应链未来会有越来越多的场景要复用同样的能力，从短期来看，当前合作模式也存在一定局限。

1. 算法模型发布灵活性要求更高，预处理、后处理变动灵活，而业务代码又期望稳定。

2. 模型运营上对算法可见度较低，模型版本记录、当前上线陪跑了哪些模型对算法无法有效感知。

3. 模型推理耦合在业务应用里，对机器成本提高了要求。业务逻辑对机器配置要求低，但因为算法模型对机器要求配置高，所以拉高了业务域的机器成本，不便运维降本。

因此在最近供应链算法工程小分队成立了，并且与 AI 计算平台团队强强联合，希望把业务域逻辑和算法逻辑解耦开来，让算法同学能更好地干预、运维模型，让更多场景可以低成本地接入 MLOps 标准。

如上图所示，让 AI 负责底层调度，供应链工程负责抽象公共能力，供应链算法和业务开发团队灵活地在各种场景落地。希望在不久的将来，我们有更多更好的故事可以与诸位分享，也欢迎各位业界大佬能加入我们团队！

文 / 凡飞

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。