Introducing MLOps 解读（一）

一、什么是MLOps？

MLOps是一个帮助组织和商业高管创造长期价值并降低机器学习等模型风险的过程。MLOps的核心是机器学习全生命周期的标准化和精简化。MLOps的主题是透明度（可视化、可追溯）和效率（敏捷性、速度）

二、什么时候需要mlops？

当模型面临大规模性的企业级投产时，各团队正在寻找方法，将一个多阶段、多学科、多过程的流程形式化、标准化。
早几年的时候，大多数组织面向生产的机器学习模型的开发和落地部署还是新生事物，模型数量较少易管理，公司领导对理解这些模型及相关依赖的兴趣很少。而随着决策自动化的发展，像金融贷款风险评级、保险理赔核保、无人驾驶、个性化推荐、法律文书判决、缺陷检测识别等应用不断深化，模型数量越来越庞大，组织中不同AI团队的模型存在冗余无序、质量良莠不齐的问题，同时企业决策层对关系重大的模型的风险和可解释问题倍加关注。
**MLOps的标准化正是实现机器学习模型生产的流水线过程，每一个环节把控风险和工序、确保跨团队的衔接和协作，要求数据、模型、元数据（代码等）等资产的版本管理和可追溯，关注可视化，管理模型风险、模型质量、流水线，不仅实现降本增效，也保证了模型的透明性和可解释性。**而精简化是出于模型规模化生产的必然需要，通过持续监控、度量反馈去优化流程中的不足，从而在规模化生产中会形成聚变效应。
总的来说，MLOps既是高质量、可持续地大规模部署ML工作的重要组成部分，同时，也有助于降低ML模型在生产中的风险。

三、践行MLOps面临的挑战是什么？

MLOps应用于机器学习模型的大规模生产时，会面临以下问题：
1.**模型的许多依赖项不断变化。**数据在不断变化，业务需求也在不断变化。业务需求：需要不断将结果反馈给业务部门，以确保模型在生产和生产数据中的真实性与预期一致，并在关键方面解决原始问题或实现原始目标。数据：数据存在数据漂移和概念漂移的问题，发现存在漂移后，要及时进行模型回退或模型下线。

2.**跨团队协作存在壁垒。**尽管机器学习生命周期涉及来自商业、数据科学和IT团队的人员，但这些团队中没有一个使用相同的流程或工具，甚至在许多情况下，没有一个共享相同的基础技能作为交流的基线。

3.**数据科学家分身乏术。**毕竟数据科学家不是软件工程师，大多数人专门从事模型构建和评估，他们不一定是编写应用程序的专家。虽然随着时间的推移，随着一些数据科学家在部署或操作方面变得更加特殊，这一点可能会开始发生变化，但现在许多数据科学家发现自己必须同时扮演许多角色，这使得彻底完成其中任何一个角色都具有挑战性。随着越来越多的模型需要管理，数据科学家们被拉得太细，在规模上变得尤其成问题。当考虑到数据团队人员的更替时，复杂性变得指数级，突然间，数据科学家不得不管理他们没有创建的模型。

四、MLOps与Devops的异同点？

MLOps的概念脱胎于软件工程中的DevOps，而DevOps极大简化了软件的变更和更新的实践。
同:
1.稳健的自动化和团队间的信任；
2.团队间的协作和沟通；
3.端到端的服务生命周期（构建、测试、发布）
4.优先考虑持续交付CD和高质量。
异：
MLOps和DevOps之间有一个关键的区别，这使得后者不能立即转移到数据科学团队：将软件代码部署到生产中与将机器学习模型部署到生产中有根本的不同。虽然软件代码是相对静态的（“相对”的，因为许多现代软件即服务（software-as-a-service）[SaaS]公司确实有DevOps团队，可以快速迭代并每天在生产中部署多次），但数据总是在变化，这意味着机器学习模型在不断学习和适应，视情况而定，以适应新的输入。这种环境的复杂性，包括机器学习模型由代码和数据组成的事实，使MLOP成为一门新的、独特的学科。

五、MLOps有哪些特点？

1.模型开发

1.1 建立业务目标
业务目标包括性能目标、技术基础设施要求和成本约束。

1.2 数据来源和探索性数据分析
寻找可用的数据可能是整个开发过程中最困难的部分。有以下问题需要考虑：
·有哪些相关数据集可用？
·这个数据集是否足够准确和可靠？
·利益相关者如何拿到这些数据？
·通过组合多个数据来源，哪些数据特征可以被保留？
·这些数据能否实时获取？
·模型一旦部署后，数据如何更新？

数据治理的约束下，有以下问题：
·所选数据集能用于这个目的吗？
·所用条款是什么？
·是否包含有必须修改或匿名的个人身份信息？
·是否存在不能在这种商业环境下使用的特征，如性别？

1.3特征工程和选择
1.4训练和评估
实验追踪工具：帮助记忆数据、特征、模型参数及性能指标的过程，还能帮助实验的对比，突出性能差异。
评价模型好坏的2种标准：定量指标（准确率、召回率、误差等）+定性指标（可解释性、部署难度）
1.5 可再现性
没有可再现性，数据科学家就不能自信地迭代模型，更不可能提交给DevOps人员，以查看实验室中创建的内容能否在生产中忠实复现。再现性要求所有的资产和参数进行版本控制，包括用于训练和评估的数据、软件环境的记录等。
1.6 可信AI
缓解不确定性、帮助防止意外后果的技术：
部分依赖图，用于观察特征对预测结果的边际影响；
子群分析，用于观察模型如何处理特定子群，是许多公平性分析的基础；
单个模型预测，如Shapley值，这解释了每个特性的价值如何作用于特定的预测；
假设分析（what-if-analysis），这有助于用户理解预测对于输入的敏感性。

2.生产和部署

产品化和部署模型是MLOps的一个关键组成部分，它提出与开发模型完全不同的技术挑战。这是软件工程师和DevOps团队的领域，要想管理数据科学家与这些团队之间的信息交换，组织上的挑战不容忽视。
2.1模型部署类型和内容
通常有2种类型的模型部署：
a.模型即服务或实时评分模型：
一般将模型部署到一个简单的框架中，以提供实时响应请求的REST API端点。（API可以通过这个端点访问执行任务所需资源）
b.嵌入式模型：
模型被打包放在一个应用程序中，然后发布。比如一个提供多请求批量打分的应用程序。

要部署的模型由什么组成取决于所选的技术，但通常包括一组代码（Python/R/Java等）和数据构件。它们都可能对运行时长和包有版本依赖关系，需要在生产环境下加以匹配，因为不同版本可能导致预测结果不同甚至出现报错。
减少对生产环境依赖的一种方法是将模型导出为可移植格式，如PMLL、PFA、ONNX或POJO。这些旨在提高系统间的模型可移植性并简化部署。但是，它们有局限性：每种格式只支持有限范围内的算法，有时可移植模型的行为方式与原始模型略微不同。是否使用可移植格式是基于对技术和业务环境的透彻理解而做出的选择。

2.2 容器化
容器化（集装箱化）是解决部署ML模型过程中的依赖项相关的问题。Docker技术是虚拟机的轻量级替代品，允许应用程序在独立、自包含的环境中部署，与每个模型的确切要求相匹配。它支持使用蓝绿部署保证新模型无缝发布。另外，多容器能实现多模型计算资源的弹性调度。对于多容器的编排，一般采用Kubernetes，云上和本地都可使用。

2.3模型部署的要求
我们一直追求的是用快速、自动化的部署替代劳动密集型过程。
–对于短生命周期、自服务的应用程序，通常不用太担心测试和验证问题。如果模型的最大资源需求能通过Linux cgroup安全地限制住，那么全自动化的一键部署可能就够了。
–对于面向客户、任务关键型用例中，需要一个更健壮的CI/CD管道。要求至少如下：
·确保符合所有编码、文件和签核标准。
·在接近生产环境的情况下重新创建模型。
·重新验证模型精度。
·执行解释性检查。
·确保满足所有治理要求。
·检查数据制品的质量。
·在负载下测试资源使用。
·嵌入到更复杂的应用程序中，包括集成测试。

–在强监管行业（如金融、制药）治理和监管要求会更多，而且可能涉及手动干预。类似DevOps，MLOps的目标是尽可能自动化CI/CD管道。这不仅能加快部署过程，而且支持更广泛的回归测试，并减少部署中出错的可能性。

3.监控闭环

一旦模型部署到生产环境中，随着时间的推移，它持续保持良好的性能时至关重要的。但对于不同的团队来说，好性能的定义各不相同。

• 对DevOps团队：模型完成工作是否足够快？ 模型是否使用合理的内存数量和运行时间？
  如果需要重新训练，那么要考虑资源的可伸缩性。

• 对数据科学家：数据科学家基于模型会随时间而退化而关注监控，这种退化不是传统软件面临的问题，而是ML固有的问题。ML数学构建了训练数据的模式的表示，并试图反映真实的世界。但现实世界并非静止不动，反而是飞速前进变化的。三个月前用于欺诈检测的模型的训练数据无法反映近一个月内出现的新型欺诈。一个给定的网站开始吸引越来越多的非既定目标人群，原有的广告投放策略也会失效。当模型的性能变得不可接受时，需要进行再训练，而模型隔多久需要重新训练取决于现实世界变化的速度和对模型准确度的预期。更重要的是，取决于构建和部署更好的模型的难易程度。
  那么首先，数据科学界如何判断模型的性能正在下降呢？
  有2种常用方法：a.基于基本事实（ground truth）；b.基于输入漂移。
  a.基本事实就是模型被要求解决问题的真实正确答案，如：该信用卡交易是否真的具有欺诈性？
  有些情况下，预测后能很快得到基本事实的反馈，如个性化推荐的广告是否被用户点击。但多数情况下，获得基本事实需要等待漫长的时间，如模型预测交易具有欺诈性，持卡人极有可能在审查每月交易时才会报告这些欺诈交易，延时很久。在模型预测欺诈案例中，基本事实无法使数据科学家每天准确监控绩效。在需要快速反馈的时候，输入漂移可能是更好的方法。
  b.输入漂移
  如果把最近已部署模型的请求与训练数据作比较，发现存在明显差异，则模型很可能受到某种影响，这是漂移检测的基础。这种方法的优点在于，该测试所需的所有数据已经存在，无需等待基本事实或其他信息。识别漂移是适应性MLOps战略最重要的组成部分之一，可为企业的AI工作带来灵活性。

• 对业务部门：模型是否给企业创造价值？模型带来的好处是否超过了开发和部署模型的成本？以及我们如何度量好处和成本？
  模型重新训练会面临很多问题，比如：
  新的训练数据是否符合预期？通过预定义的度量指标和检查的自动验证是有必要的。
  数据是否完整且可持续？
  在获取基本事实速度较慢的环境下，可能几乎没有可用于训练的新标记数据。这种情况下，数据科学家需要分析漂移的原因，并想办法调整已有的训练数据，以更准确地反映最新的输入数据。也有可能删除特定特征或对现有的训练数据进行采样可能会得到更好的优化模型。

4.模型治理

治理是对企业的一系列控制，保证企业向所有利益相关者（股东。员工、社会公众和国家政府）履行其职责，包括金融、法律和道德义务，这三点是公平的基本原则。各国政府现在开始着手将ML作为监管的重点关注对象，希望减轻使用AI带来的负面影响。
将治理应用到MLOps是有挑战的，流程复杂、技术不透明、数据存在各种依赖，这些都是问题。MLOps治理广义上分为2类：
一类是数据治理：确保适当使用和管理数据；
它关注以下问题：
数据来源是什么？
原始数据如何收集的，使用条款是什么？
数据是否准确且是最新的？
是否存在不应使用的PII或其他形式的敏感数据？
数据集来源是哪里以及我可以如何使用它？
如果我修改部分数据，会对下游产生什么影响？

另一类是流程治理：使用定义良好的流程，确保在模型生命周期的正确点处理好所有治理相关的考虑事项，并保留了完整准确的记录。
流程治理侧重于把MLOps流程中的步骤形式化，并将行动与之关联。通常这些行动是审查、签署和证明材料的截图等。
目标有2：一、确保在正确的时间进行与治理相关的每一项考虑，并采取正确行动。如，在通过所有验证检查前，不应将模型部署到生产环境。二、实现严格的MLOps流程外的监督。审计师、风险经理、合规官及整个业务部门都希望能在以后的阶段跟踪进度并审查决策。
有效的治理难以实施的原因：

• ML生命周期的正式流程很少能准确定义。对整个流程的理解分散在涉及到的各个团队中，通常没有一个人对整个流程有详细理解。
• 要想成功实现流程治理，每个团队都必须全心全意地采用该流程。

5.MLOps与可信AI

团队需要良好的MLOps原则来践行可信AI，可信AI需要MLOps的策略。