近年来在国际国内的人工智能研究和应用上出现明显的趋势即AI应用对于模型和算法的提升目前达到一个瓶颈,目前正在从传统的Model-centric(即以模型为中心),在向Data-centric(以数据为中心)进行转变。
曾任斯坦福大学人工智能实验室主任,谷歌人工智能大脑负责人和百度首席人工智能科学家的业内著名学者Andrew Ng(吴恩达)教授2021年在美国通过他创办的DeepLearning.AI发表线上演讲,演讲的题目是《MLOps:From Model-centric to Data-centric AI》,在人工智能行业内引起了很大反响。在他的演讲中,他认为当前在工业界落地人工智能的现状是通过模型调优进行效果提升,远远不如通过数据质量调优带来的效果提升,所以带来的AI落地趋势为从Model-centric向Data-centric进行转变。
具体来说,采用Model-centric的方法就是保持数据不变,不断调整模型算法,比如使用更多更深的网络层、更多的超参数调整等,对最终结果的改善提升空间已经很小了;相反的是采用Data-centric的方法,即保持模型算法不变,把精力花在提升数据质量上,比如改进数据标签、提高数据标注质量、保持数据在各个阶段的一致性等,反而容易取得比较好的结果。对于同一个AI问题,改进模型还是改进数据,效果完全不同。
例如,在如下钢板缺陷的检测任务当中,基线的准确率为76.2%。采用Model-centric的方法,即各种换模型调参数的操作之后,对准确率的提升幅度非常小,三个例子分别为+0%,+0.04%,+0%,最终效果几乎没有提升。但是采用Data-centric的方法,即保持模型算法不变,对数据进行优化(包括引入更多数据,提升数据质量等),最终结果是模型准确率提升的幅度要大得多,三个例子分别为+16.9%,+3.06%,+0.4%,(不要小看提升的幅度为十几点或者几个点,在模型调优的过程中已经非常难得了。)比较一下,采用Data-centric的方式在效果提升上完胜采用Model-centric的方法。
之所以会这样,是因为数据远比想象中更重要,大家都知道“Data is Food for AI”,用一个简单的公式来表示。
在一个真实的AI应用中,大概有80%的时间是处理跟数据相关的内容,其余20%则用来调整算法。这个过程就像烹饪,八成时间用来准备食材,对各种食材进行处理和调整,而真正的烹调可能只有大厨下锅的几分钟。可以说,决定一道菜是否美味的关键,在于食材和食材的处理。所以,吴恩达教授提出MLOps(“Machine learning Engineering for Production”)。他认为,MLOps是帮助机器学习进行大规模企业应用(Production)的一系列工程化的东西(Engineering),MLOps最重要的任务就是在机器学习生命周期的各个阶段,包括数据准备、模型训练、模型上线,还有模型的监控和重新训练等等各个阶段,始终保持高质量的数据供给。用他的原文就是“MLOps’ most important task is to make high quality data available through all stages of the ML project lifecycle.”
为此,他还联合业内的几名专家,在他所负责的Cousera.ai培训平台上推出了《Machine Learning Engineering for Production (MLOps) 》专项课程,内容包括如何构建和维护在生产环境中持续运行的机器学习系统,如何处理不断变化的数据,如何以较低成本不间断运行并产生最高性能等。(见链接https://www.coursera.org/specializations/machine-learning-engineering-for-production-mlops)开课至今已经有3万8千多人上过这一系列的课程,上过的人都感叹他的课程保持一如既往的高质量,在企业内部部署机器学习应用并产生价值做了非常全面的讲授,同时也非常实用,介绍了不少能快速上手的工具。
以上是以吴恩达教授为代表的AI科学家对于MLOps的认识,他们已经认识到MLOps的重要性和关键点。
我们再来看看AI分析师和AI工程师对于MLOps的认识。
首先从业内分析师看来,目前AI项目的失败率是惊人的高。
2019年5月Dimensional Research调研发现,78%的AI项目最终没有上线;2019年6月,VentureBeat的报告发现,87%的AI项目没有部署到生成环境中。2020年Monte Carlo Data预估AI项目的死亡率在90%左右。就是说,虽然AI科学家、AI工程师一起做了大量的工作,包括数据准备和数据探索、模型训练等,但是大部分的机器学习模型最终没有上线,即没有产生业务的价值。
然后从AI工程师看来,在企业内部落地AI项目,目前明显有如下三个缺点。
1. 落地慢: 往往一个机器学习模型模型落地时间是机器学习模型调优完成的数倍以上。
一个AI科学家在一次分享会上感叹:” It took me 3 weeks to develop the model. It has been >11 months, and it is still not deployed.”即他只花了3个星期来开发模型算法,但是之后过去了11个月,该模型仍然没有被部署到生产环境中来发挥作用。事实上,这不是一件单独的事情,在业内是普遍现象,在业内经常能听到类似的抱怨。
2. 效果不达预期:机器学习的模型在线下训练的时候效果很好,各种指标都达到项目预定的目标,但是当该模型被部署到线上环境后对接真实的线上数据和线上流量来提供预测服务的时候,效果往往大打折扣,跟线下训练的效果差异非常大。
3. 效果还会回退:一个模型上线后一段时间(例如一周)内效果还可以,但是随着时间推移,模型的效果越来越差,一个月后差一些,三个月后就更差了,最后该模型的效果差到完全不可用。
为什么会产生这种结果?
长期研发和运维机器学习模型和服务的著名科技企业谷歌发现:AI科学家实现并训练一个机器学习模型,在给定的相关训练数据下,可以在离线环境下给出效果非常出色的模型出来。但是真正的挑战并不是得到一个效果不错的模型,真正的难点在生产环境下构建一个持续运行的机器学习系统,并保持不错的效果。为此,谷歌的工程师2015年在NIPS上发表的论文《Hidden Technical Debt in Machine Learning Systems》(见链接https://research.google/pubs/pub43146/)中提到,在一个真实上线的AI系统里面,包含了数据采集、验证、资源管理、特征抽取、流程管理、监控等诸多内容。但真正跟机器学习相关的代码,仅仅只占整个AI系统的5%,其余95%的内容都是跟工程相关,跟数据相关。而数据是最重要的部分,也是最容易出错的部分。
如图所示,真正跟机器学习模型计算相关的“ML Code”只占整个系统极小的部分。 而周围的配置管理、数据搜集,特征处理,数据验证,机器资源管理和调度,预测服务、监控等占据了其余95%部分的工作量。
Data is the hardest part of ML and the most important piece to get right… Broken data is the most common cause of problems in production ML systems.
— Uber.
翻译成中文就是:“数据是机器学习中最难的部分,也是为得到争取结果最重要的部分。错误数据又是生产环境中出问题最常见的原因。”
这是Uber的机器学习工程师在一篇很有名的机器学习博客中提到的。这篇博客名为“Meet Michelangelo: Uber’s Machine Learning Platform”,见链接https://www.uber.com/en-HK/blog/michelangelo-machine-learning-platform/,这篇博客系统的阐述了Uber内部机器学习平台的构建思路和实践,被认为是AI工程化的里程碑式的文档之一。
而笔者认为,数据对一个真实的机器学习系统的挑战主要在于以下几点:
以上列举的都是机器学习里面数据相关的一些挑战。
最后一点,是特征数据的共享和复用。 机器学习的项目需要采集大量的原始数据(Raw Data),然后进行各种数据聚合、转换后进行训练。在一个企业内的多个业务线的多个业务场景下的机器学习模型,他们需要使用大量的特征,往往存在重复的情况。即一个特征,是从原始的日志文件读取开始,然后再通过一系列的特征工程步骤,最后得到一个表现力强的特征,这个特征可以被模型A所使用,也可以被模型B使用,这就是一个特征共享和复用的问题。很显然,如果不能共享,那么所有这些从海量原始文件中读取,然后一系列的特征工程任务,全部需要重复执行,这会浪费大量的存储资源和计算资源。
大企业内同时运行的机器学习模型数量在快速增长。以笔者熟悉的一个国内大型金融企业为例,该企业内部的机器学习场景非常丰富,同时有1000多个应用场景下运行1500+个模型,在线上的风控、推荐、预测等场景中发挥着重要和关键的作用。
这么多模型如何支撑? 即如何在技术上支撑业务,做到机器学习在企业内部“多、快、好、省”的落地?
精心完善一个模型的训练和部署并不特别困难,但是要做到落地上千的模型并发挥作用而且还需要比较低的成本,这需要非常好的可扩展性,只能通过加强机器学习系统的工程技术能力来实现。
那么如何解决这些机器学习中的这些上线慢,效果不佳,效果甚至回退的,同时又要规模化的问题呢?
我们可以回顾一下当年我们是如何解决计算机软件或者线上系统的质量和效率问题的。当年也是存在编码完成功能的时间很长,上线的质量不达预期,甚至还有线上服务崩溃、不响应用户请求的情况。在这种情况下,我们使用一种叫做DevOps的方法,来改进我们的研发模式和工具系统,在保证质量的前提下,更快的提高版本发布的速度,实现更多更快的部署,从而进行更多的迭代和试错。为此我们采用了大量的自动化的工作来进行流水线(俗称Pipeline)作业,即从代码提交开始,触发流水线进行一系列自动化的任务,完成包括代码静态检查、代码编译、代码动态检查、单元测试、自动化接口测试、自动化功能测试、小流量部署、蓝绿部署、全流量部署等。在容器成为计算机系统的主流后,还加上了打包成为容器的镜像、把容器镜像部署到容器仓库、从容器仓库中按需拉取容器等相关步骤。当然这一系列任务,是需要能做到尽可能的自动化的。
借鉴DevOps领域内的20年的实践经验,业内把机器学习开发和现代软件开发结合起来形成一整套的工具和平台以及研发流程,我们称之为“MLOps”。
MLOps是企业内进行机器学习成功落地中的一套最佳工程实践,参考DevOps的原则和实践,涉及AI工程师和AI科学家等多个角色,覆盖机器学习中包括定义项目、搜集和加工数据、模型训练和迭代、模型部署和监控等全生命周期,体现在包含代码、模型、数据的持续集成、持续部署、持续训练和持续监控等一系列动作。
拆解开来细说:
(1) MLOps是一套工程实践:偏重于工程,不是算法和模型
(2)用于企业内部线上环境:不是用于实验室的研究场景,而是用在企业内部是需要跟企业的业务场景结合的
(3)目的是成功落地机器学习项目:为了让AI在企业内发挥价值
(4)参考DevOps的实践: DevOps的很多实践都被MLOps参考并做了扩展
(5)涉及多个角色:包括AI科学家,AI工程师等多个角色
(6)阶段包括AI全生命周期: 覆盖端到端的机器学习全生命周期活动
(7)对象包括代码、模型、数据(特征):不仅仅只有代码
(8)活动包括CI、CD、CT、CM:不仅仅只有CI和CD
如上图所示,MLOps覆盖机器学习系统落地的全生命周期活动,即机器学习系统从第一步的定义项目,到第二步的特征数据加工,到第三步的模型训练和迭代,到第四步的模型部署和监控,采用流水线的方式连续进行。其中有若干小循环,例如模型训练不理想,可能需要返回到上一步重新进行数据加工;模型监控下发现线上模型的效果有回退,需要返回到上一步重新进行模型训练等;或者把模型部署到线上后发现效果不达预期,可能需要返回到之前的步骤,包括搜集更多数据,进行更多特征工程等。
其中CI、CD、CT、CM的具体含义如下:
另外,传统软件开发领域的DevOps实践中,往往只包含代码,代码相关的操作包括代码管理、代码编译、代码测试、产出物或打包等;MLOps相对于DevOps,还增加了模型和数据相关的操作。
当然,MLOps不仅仅只是流程和Pipeline,它还包括更大更多的内容。比如:
(1) 存储平台: 特征和模型的存储和读取
(2) 计算平台:流式、批处理用于特征处理
(3) 消息队列:用于接收实时数据
(4) 调度工具:各种资源(计算/存储)的调度
(5) Feature Store:注册、发现、共享各种特征
(6) Model Store:模型的特征
(7) Evaluation Store:模型的监控/ AB测试
其中Feature Store、Model store和Evaluation store都是机器学习领域中新兴的应用和平台,因为有时候线上会同时跑多个模型,要实现快速迭代,需要很好的基础设施来保留这些信息,从而让迭代更高效,这些新应用、新平台就应运而生。
下面简要介绍一下Feature Store,即特征平台。作为机器学习领域特有的平台,Feature Store具有很多特性。
第一,需要同时满足模型训练和预测的要求。特征数据存储引擎在不同的场景有着完全不同的应用需求。模型训练时需要扩展性好、存储空间大;实时预测则需要满足高性能、低延迟的要求。
第二,必须解决特征处理在训练时候和预测阶段不一致的问题。在模型训练时,AI科学家一般会使用Python脚本,然后用Spark或者SparkSQL来完成特征的处理。这种训练对延迟不敏感,在应付线上业务时效率较低,因此工程师会用性能较高的语言把特征处理的过程翻译一下。但翻译过程异常繁琐,工程师要反复跟科学家去校对逻辑是否符合预期。只要稍微不符合预期,就会带来线上和线下不一致的问题。
第三,需要解决特征处理中的重用问题,避免浪费,高效共享。在一家企业的AI应用中,经常会出现这一情况:同一个特征被不同的业务部门使用,数据源来自同一份日志文件,中间所做的抽取逻辑也是类似的,但因为是在不同的部门或不同的场景下使用,就不能复用,相当于同一份逻辑被执行了N遍,而且日志文件都是海量的,这对存储资源和计算资源都是巨大的浪费。
综上所述,Feature Store主要用于解决高性能的特征存储和服务、模型训练和模型预测的特征数据一致性、特征复用等问题,数据科学家可以使用Feature Store进行部署和共享。
目前市面上主流的特征平台产品,大致可分为三大类。
成熟度模型是用来衡量一个系统、一套规则的能力目标,在DevOps领域经常用成熟度模型来评估一个公司的DevOps能力。而在MLOps领域也有相应的成熟度模型,不过目前还没有形成规范。这里简要介绍一下Azure的关于MLOps的成熟度模型。它按照机器学习全流程的自动化程度的高低,把MLOps的成熟模型分成了(0,1,2,3,4)个等级,其中0是没有自动化的。(1,2,3)是部分自动化,4是高度自动化。
|