不要让机器学习模型成为孤儿


不要让机器学习模型成为孤儿


Written by Jepson(Jiaping) Du 杜嘉平, 文章同步公众号: 持续学习的杜吉普





写在前面:

《不要让机器学习模型成为孤儿》之所以文章以这个标题命名是我在一些真实客户案例以及在行业调研的过程发现了一个目前机器学习模型使用的一个小问题——很多“高大上”的机器学习模型在企业生产环境中使用后就会变成孤儿,没有人进行后续的照顾与培养,这就让模型实际的能够发挥价值的“寿命”非常的短。只要业务背景发生变化导致数据情况发生变化,那么模型就会失去原本的价值。


如何对于模型进行持续的照看与培养,这是一个非常有趣的话题,我将用《探索MLOps》系列文章来探索关于模型持续运营MLOps以及模型持续交付CD4ML等相关话题。





机器学习模型应用现状

模型有数据科学通过实验性代码实现并由数据工程师以API基础架构的形式进行模型部署。而数据工程师的工作仅仅是将其功能以低延时服务的方式从实验环境中打包部署于生产环境中实现。这种方式的模型训练与部署会导致“训练-应用偏差”。


1. 模型发布迭代不频繁或不会迭代:模型需要进行持续迭代来适应业务的发展与变化,否则模型的“有效期”将会非常短暂。

2. 缺少模型测试,通常测试代码是脚本执行的一部分,通过脚本源代码实现模型训练、指标评估与可视化的工作。

3. 部署仅为实现预测服务,而不是整个机器学习系统。

4. 缺少主动性能监控:不会跟踪与记录模型的预测和操作。而上述的预测和操作行为都是监测模型性能下降和其他模型行为偏移所必须的信息。



目前模型使用挑战与解决思路

挑战

上述模型使用方式不需要进行模型的验证以及模型的更改。但是在现实环境中,模型通常会失效,原因是无法适应环境的动态变化以及描述环境的数据发生了变化。


解决思路

对于模型我 需要进行优化与重新训练升级,以应对在模型监测过程中所识别出的模型性能下降的情况。


1. 对于模型在生产环境中的监控:去识别模型表现的下降以及模型的过时问题。然后在新的手动实验环境下使用新的数据的迭代中重新训练模型。——环境因素导致

2. 生产模型的持续训练以应对我们所补货的新机会点,与新的业务特征。——业务流程因素导致

3. 持续使用新的技术更新模型:例如feature engineering、超参调整。——新技术带来的改变



解决方案:ML Pipeline Automation


一句话总结就是:

通过自动化的ML pipeline进行持续的自动的模型训练,以提供预测服务。


(上图:ML Pipeline Automation逻辑)


特点:

1. 快速实验:整个模型建立的实验过程是精密安排的(在pipeline中每一个步骤都会经历),所以整个实验环境中的模型迭代将会非常迅速。在实验模型建立后,会快速的将整个pipeline用于生产中;

2. 数据新鲜:每次模型自动训练的数据都是最新鲜的数据,数据的发送重新训练来自于Pipeline Triggers, 即当到达一个条件,就会启动pipeline作为pipeline的触发条件,pipeline会引发数据的跑批,将数据喂给整个模型训练的pipeline。

3. 组件和pipeline的模块化代码:对于pipeline的构建代码是模块化、可复用的、可共享的。EDA代码是可以在notebook中的,但是组件的源代码必须是模块化的。此外组件最好容器化,这样可以更好的:

a. 1)将执行的生产环境与自定义代码运行时的环境分离

b. 2)使代码在开发和生产环境之间复用

c. 3)隔离流水线之间的每个组件,因为每个组件之间有自己运行时的环境版本,并且可以有不同的语言和packages

4. 可持续交付:模型可以根据新数据进行重复训练,以得到持续输出根据最新数据训练出模型的预测能力。并且整个过程是自动化的。

5. Pipeline的部署而非模型的部署。



ML Pipeline Automation关键行为

1. 数据与模型验证:触发Pipeline trigger从而为模型提供新数据并且重新训练模型之前,我们需要进行data validation与model validation去保证数据与模型的可用性,并且符合我们预设的标准。

a. 数据验证:数据自身与数据总体发生变化,与预期训练的pipeline数据情况不符。决定是否开始重新训练模型(模型开始更新),或者是否停止执行Pipline(模型停止更新)。一般会验证以下两点:

数据发生偏差:即输入的数据出现异常,这就意味着之后的模型建立自动化过程是不match新数据源的,不可以用新数据应用于本身通过老数据为依据而建立的流水线中。一旦发生这种情况,我们应该停止流水线,从而进行数据情况的调研,同时对于流水线进行修复和更新。一般data schema skewness的情况为:输入数据产生了新的意外特征、缺少了预期的特征、预期特征存在outlier。

据数值(data value)发生偏差:数据整体的统计情况(数据pattern)发生变化,例如整体的统计分布情况。这就需要我们重新对于模型进行训练。


b. 模型验证:这一步发生在数据验证后并且重新训练了模型之后,模型部署生产之前。这一步是离线验证,验证主要为以下四点:

i. 通过evaluation metric value去验证模型预测的质量(常规的model performance validation)

ii. 新模型的表现与当前未更新模型表现的对比,确认新模型的表现比旧模型相比有所提高。

iii. 检验新模型的表现是否存在极大的variance。

iv. 确定新模型可部署


在进行了数据验证与模型验证之后(我统称其为内部验证或离线验证),最主要的要进行在线模型验证。(通过Canary或AB test)


2. 特征存储

在数据进入pipeline之前对于数据特征进行集中存储,其中包含对于数据特征的定义、存储、对于访问进行标准化处理,以方便后续的模型训练。特征存储区需要为特征值提供高吞吐量批量服务和低延时实时服务的 API,以及支持训练和服务工作负载。换成人话就是,这是一道关卡,对于进入到模型新联中数据进行第一道管理、筛选与使用。保证每次输入进pipeline的数据是可以被重复训练的。解决痛点:pipeline中缺少对于特征的灵活处理,不像测试环境下那样灵活的进行特征工程。所以需要在数据进入前定义好数据。

Feature Store的应用可以通过API的形式实现。

特征存储所实现的功能:

a. 自动化的数据转化:Automated Data Transformation

将数据从raw data进行转换为有用的特征,为之后数据进入pipeline做准备。

b. 数据登记:Consistent Feature Registry

数据等级包含对于特征进行标准化定义(standardized feature definition),与元数据metadata进行关联,让组织和数据科学家能够获知进入模型的数据特征即训练集数据字段。这样能够更好的为之后的模型训练做准备,因为DS只需要挑选需要feature即可,不需要重复的去写代码。

c. 模型建设与重建:Model Training and Retraining

Feature store(后面简称FS)可以提供最新的数据训练集给模型训练。

d. 实时特征服务:Real-Time Feature Serving

除了服务于模型的训练之外,feature store可以直接提供给数据消费者目前存储的最新特征数据,为他们进行数据服务。例如一些指标的计算。(类似DM层)。并且可以提供离线数据给DS做实验。


同时FS还可以通过域管理来特区数据,例如人口特征数据、产品特征数据等。

e. 模型监控:Model Monitoring.

对于这一点不太确定,可以将预测结果作为feature存储与feature store中,通过最新的预测值与历史值进行对比起到模型表现的作用,以此来进行模型的监控。


3. 元数据管理

元数据管理记住这ML pipeline职行开始之后的所有信息。

元数据管理将会记录一下元数据:

a. Pipeline总体以及各个组件的版本

b. Pipeline的开始时间、起始时间、持续时间、pipeline中完成每一步骤的时间

c. Pipeline的执行者

d. 传递给pipeline的参数(不懂)

e. 指向流水线每个步骤生成的工件的指针,例如准备好的数据的位置、验证异常情况、计算的统计信息以及从分类特征中提取的词汇。跟踪这些中间输出有助于您在流水线因某个步骤失败而停止时,从最近的步骤继续执行流水线,而不必重新执行已完成的步骤。

f. 指向之前训练的模型的指针(如果您需要回滚到之前的模型版本,或者需要在流水线在模型验证步骤中获得新的测试数据时为之前的模型版本生成评估指标)。

g. 模型建设中所产生的评估指标,历史数据都存在。可以进行新模型与老模型的对比。


4. Pipeline Trigger 流水线触发

按照一定的条件来触发流水线的执行对于模型对于重新训练

条件可以为以下几点:

a. 按需,手动触发,一般来源于业务场景的变化

b. 按时间,设置训练频率,例如每天/每月等对模型进行重新训练。

c. 根据数据的可用性

d. 模型性能下降时(可选择的策略:通过定期持续的模型表现监控,设定下降阈值)

e. 数据分布发生重大变化时。包括数据本身的变化与数据整体的偏移。





写在后面

思考的到此结束,下面是在进行了上述思考后留下的焦虑:


上面整套对于MLOps的流程看起来真的非常完美,再加上最近市面上出现的各种机器学习平台除了上述自动化的功能之外,还具备模型自动训练)以及模型自动优化(Model Retrain)的功能,再加之最近所服务的某大型银行客户也正在采购机器学习平台,种种信息让曾经在Kaggle留下世界排名5%成绩的我感到非常焦虑,这样一来数据科学家不就很完美的被替代了?事实上是这样吗?



人的价值

人的价值在哪里?我陷入了无比的焦虑之中,希望从行业领先者那里得到一些思路,于是我向我曾经的良师益友P(H2O Senior Director/BNH.ai Principal Scientist)寻求了灵感,得到如下令人振奋的回复:


I would NEVER trust Watson or any other AutoML product for any serious ML application (… and please understand that I was instrumental in building a very high-end autoML system for another company). My experience is that these solutions are only suitable for low-risk, low-effort models. Humans must still build and deploy important models.


Can some parts of training, deployment, and monitoring be automated, with careful supervision? Yes! Are we ready for full autoML? No … and I wouldn't believe any marketing that says otherwise. I have seen horrible failures when junior data scientists use AutoML to tackle serious problems.



关于下一篇思考

总体而言,如果企业需要的是简单、低风险并且效果不强烈的模型,那么我所焦虑的自动化机器学习全流程是可以用机器学习平台所替代的,反之,则必须由人来进行建模。自动化的模型存在若干风险,也会在未来出现很严重的问题,所以对于serious的model,还是要人来建模的。


但是具体两者的适用场景究竟有什么差别?人工建模的优势究竟在什么地方,我会继续进行研究与总结,并发布后续系列文章,估计下个文章会叫做《MLOps是要靠人的》


参考资料

https://learn.datacamp.com/courses/designing-machine-learning-workflows-in-python

https://github.com/visenger/awesome-mlops

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning

https://neptune.ai/blog/continuous-integration-and-continuous-deployment-in-machine-learning-projects

https://developers.google.com/machine-learning/guides/rules-of-ml/#training-serving_skew

https://www.forbes.com/sites/forbestechcouncil/2019/04/03/why-machine-learning-models-crash-and-burn-in-production/?sh=5168482c2f43

https://towardsdatascience.com/do-you-need-a-feature-store-35b90c3d896