1. 从Model-Centric到Data-Centric
近年来在国际国内的人工智能研究和应用上出现明显的趋势即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”，用一个简单的公式来表示。
Better AI = Data✖️(80%) + Code✖️(20%)
在一个真实的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的认识。
2. 人工智能在企业内的现状是落地成功率低，成本高
首先从业内分析师看来，目前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%部分的工作量。
3. 一方面，数据带来的挑战非常大
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工程化的里程碑式的文档之一。
而笔者认为，数据对一个真实的机器学习系统的挑战主要在于以下几点：
- Scale（可扩展性）： 海量的特征读取是一个挑战，训练往往需要海量的特征数据，不是T的规模，更多是P的规模（例如各大媒体网站和电商网站的推荐系统，都需要处理海量的用户行为数据包括点击、收藏、观看等，都是每天几P、几十P规模的数据。）
- Low Latency（低延迟）：预测服务需要做到低延迟和高吞吐。提供预测服务往往需要同时达到高吞吐和低延迟的服务能力，才能满足像风控、推荐等业务场景的需求，保证基本的用户体验，从而实现业务价值。
- Model decay（模型效果衰退）：现实世界是不断变化的，机器学习模型是从现实的数据中挖掘提取规律的；当世界发生变化的时候，模型效果会发生衰退，如何来应对？往往需要及时搜集更新的数据和重新进行训练，同时需要很好的效果监控体系。
- Time Travel（时间穿越）：在处理跟时间序列相关的特征数据处理容易出现“时间穿越”的问题。（“时间穿越”是指在机器学习训练的时候，把发生在某一特定时间点之后的行为数据也混入整体需要训练的数据集进行训练，这样训练的结果往往是模型训练的效果不错，但是模型上线之后效果却不达标。它本应该把这个特定时间点之后的行为数据排除在模型训练之外的。）
- Training/Serving skew：模型训练和模型预测使用的数据和代码逻辑不一致，导致线下离线训练效果不错，但是在线上生产环境下在线预测效果却很差。
以上列举的都是机器学习里面数据相关的一些挑战。
- 此外，Data Freshness，即数据的保鲜程度也很重要，需要保持数据是更新的，只能采用实时数据，而实时数据是能更贴近用户场景的最新的数据。 在一些对于企业来说价值非常高的机器学习场景（例如电商的推荐、金融行业的风控、物流的预测）中，需要引入实时数据，而实时数据会带来更大的挑战。
最后一点，是特征数据的共享和复用。 机器学习的项目需要采集大量的原始数据（Raw Data），然后进行各种数据聚合、转换后进行训练。在一个企业内的多个业务线的多个业务场景下的机器学习模型，他们需要使用大量的特征，往往存在重复的情况。即一个特征，是从原始的日志文件读取开始，然后再通过一系列的特征工程步骤，最后得到一个表现力强的特征，这个特征可以被模型A所使用，也可以被模型B使用，这就是一个特征共享和复用的问题。很显然，如果不能共享，那么所有这些从海量原始文件中读取，然后一系列的特征工程任务，全部需要重复执行，这会浪费大量的存储资源和计算资源。
4. 另一方面：人工智能在企业内加速落地所带来的规模化的需求
大企业内同时运行的机器学习模型数量在快速增长。以笔者熟悉的一个国内大型金融企业为例，该企业内部的机器学习场景非常丰富，同时有1000多个应用场景下运行1500+个模型，在线上的风控、推荐、预测等场景中发挥着重要和关键的作用。
这么多模型如何支撑？ 即如何在技术上支撑业务，做到机器学习在企业内部“多、快、好、省”的落地？
- 多：需要围绕关键业务的流程落地多个场景，对大企业来说可能是1000甚至上万的量级。
- 快：每个场景落地时间要短，迭代速度要快。比如推荐场景中，常常需要做到每天1次全量训练，每15分钟甚至每5分钟做到1次增量训练。
- 好：每个场景的落地效果都要达到预期，至少要比没有落地前强。
- 省：每个场景的落地成本比较节省，符合预期。
精心完善一个模型的训练和部署并不特别困难，但是要做到落地上千的模型并发挥作用而且还需要比较低的成本，这需要非常好的可扩展性，只能通过加强机器学习系统的工程技术能力来实现。
那么如何解决这些机器学习中的这些上线慢，效果不佳，效果甚至回退的，同时又要规模化的问题呢？
我们可以回顾一下当年我们是如何解决计算机软件或者线上系统的质量和效率问题的。当年也是存在编码完成功能的时间很长，上线的质量不达预期，甚至还有线上服务崩溃、不响应用户请求的情况。在这种情况下，我们使用一种叫做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的具体含义如下：
- CI即Continuous Integration持续集成，即数据、代码、模型不停的产生，产生之后将引发流水线一系列的操作，例如对于代码有单元测试、功能测试，还有代码风格坚持，代码质量检查等，还有编译、打包等过程，最后生成二进制文件或者容器镜像包保存在软件制品仓库里面，都是利用各种工具自动化的进行。对于数据，当产生新的数据之后，例如又有用户使用我们的App或者小程序服务，他的浏览、点击、下拉、点赞等活动，都会被后台的计算机系统自动的记录下来，然后通过数据ETL（抽取、转化、装置 ）等进行处理，然后保存到一个特定的地方，供下游的服务继续使用和消费。
- CD即Continuous Deploy持续部署，即代码、数据、模型等持续被部署到生产环境中，供用户使用来产生价值。例如对于代码，在完成持续集成的过程后进入软件制品仓库保存后，下一步是把这些制品部署到线上环境里面，操作过程包括小流量验证，分级部署，全量部署等。对于数据和模型也是如此，被持续的部署到线上的制定环境中来发挥作用。
- CT即Continuous Training持续训练，这个是特指机器学习的模型。在数据不断产生并部署之后，需要不断的进行训练，包括离线环境下的全量训练，也包括利用线上实时数据的在线训练，都是希望保持线上的模型能更快反应现实的规律，更能贴近用户的实时爱好等。
- CM即Continuous Monitoring持续监控，是指当模型、代码、数据都部署到线上之后，24x7的不间断运行，这时候需要对线上系统的稳定性和可靠性进行持续的监控，还需要对线上机器学习系统的预测效果进行监控。对于前者，如果线上服务出现故障可以实时触发报警，然后运维同学可以或者人工介入来处理，或者按照预先设定的规则自动进行处理。对于后者，如果线上预测效果有较大的降低，低于一定阈值后需要重新更新模型，会触发后台的持续训练过程完成模型的自动训练和更新。
另外，传统软件开发领域的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都是机器学习领域中新兴的应用和平台，因为有时候线上会同时跑多个模型，要实现快速迭代，需要很好的基础设施来保留这些信息，从而让迭代更高效，这些新应用、新平台就应运而生。
MLOps的特有项目——Feature Store
下面简要介绍一下Feature Store，即特征平台。作为机器学习领域特有的平台，Feature Store具有很多特性。
第一，需要同时满足模型训练和预测的要求。特征数据存储引擎在不同的场景有着完全不同的应用需求。模型训练时需要扩展性好、存储空间大；实时预测则需要满足高性能、低延迟的要求。
第二，必须解决特征处理在训练时候和预测阶段不一致的问题。在模型训练时，AI科学家一般会使用Python脚本，然后用Spark或者SparkSQL来完成特征的处理。这种训练对延迟不敏感，在应付线上业务时效率较低，因此工程师会用性能较高的语言把特征处理的过程翻译一下。但翻译过程异常繁琐，工程师要反复跟科学家去校对逻辑是否符合预期。只要稍微不符合预期，就会带来线上和线下不一致的问题。
第三，需要解决特征处理中的重用问题，避免浪费，高效共享。在一家企业的AI应用中，经常会出现这一情况：同一个特征被不同的业务部门使用，数据源来自同一份日志文件，中间所做的抽取逻辑也是类似的，但因为是在不同的部门或不同的场景下使用，就不能复用，相当于同一份逻辑被执行了N遍，而且日志文件都是海量的，这对存储资源和计算资源都是巨大的浪费。
综上所述，Feature Store主要用于解决高性能的特征存储和服务、模型训练和模型预测的特征数据一致性、特征复用等问题，数据科学家可以使用Feature Store进行部署和共享。
目前市面上主流的特征平台产品，大致可分为三大类。
- 各个AI公司自研。只要业务有实时训练的需求，这些公司基本都会自研一个类似的特征平台，用于解决上面的三个问题。但这个特征平台是为业务所深度绑定的。
- 云厂商提供的SAAS产品或者机器学习平台的一部分。比如AWS提供的SageMaker、Google提供的Vertex、微软提供的Azure机器学习平台。它们在机器学习平台里会内置一个特征平台，方便用户进行各种复杂特征的管理。
- 一些开源的和商业的产品。举几个例子，Feast，开源的Feature Store产品；Tecton提供完整的开源商业特征平台产品；OpenMLDB，开源的Feature Store产品。
MLOps的成熟度模型
成熟度模型是用来衡量一个系统、一套规则的能力目标，在DevOps领域经常用成熟度模型来评估一个公司的DevOps能力。而在MLOps领域也有相应的成熟度模型，不过目前还没有形成规范。这里简要介绍一下Azure的关于MLOps的成熟度模型。它按照机器学习全流程的自动化程度的高低，把MLOps的成熟模型分成了（0，1，2，3，4）个等级，其中0是没有自动化的。（1,2,3）是部分自动化，4是高度自动化。
- 成熟度为0，即没有MLOps。这一阶段意味着数据准备是手动的，模型训练也是手动的，模训部署也都是手动的。所有的工作全都是手动完成，适合于一些把AI进行创新试点的业务部门来做。
- 成熟度为1，即有DevOps没有MLOps。其数据准备工作是自动完成的，但模型训练是手动完成的。科学家拿到数据之后进行各种调整和训练再完成。模型的部署也是手动完成的。
- 成熟度为2，即自动化训练。其模型训练是自动化完成的，简言之，当数据更新完了之后，立马启动类似的pipeline，进行自动化的训练，不过对训练结果的评估和上线还是由人工来完成。
- 成熟度为3，即自动化部署。模型自动化训练完成之后，对模型的评估和上线是自动完成的，不需要人工干涉。
- 成熟度为4，即自动化重训和部署。它在不断监控线上的模型，当发现Model DK发生线上模型能力退化的时候，会自动会触发重复训练。整个过程就全部自动化完成了，这就可以称之为成熟度最高的系统。