大家好，我是灸哥，今天和大家一起聊聊人工智能中的 MLOps～

灸哥在一家人工智能数据服务公司任职技术总监两年的时间内，对 MLOps、DataOps、DevOps、FinOps、AIOps 等这些 XOps有了更深刻的理解和掌握，今天会先对 MLOps 进行揭秘，让更多的人理解 MLOps 的概念。

人工智能现在对于我们已经像手机、网络一样，融入到了每个人的工作和生活中，并且已经进入到各个行业中去了。

人工智能从早期在互联网企业的推荐、广告、搜索等场景中大放光彩，发展到在视觉、安防、金融等领域，再到今天走入交通、制造、生命科学等领域，并且在排工排产、自动驾驶等场景中崭露头角。

机器学习通过分析海量数据、总结规律，帮助人们解决众多实际问题。随着机器学习技术的发展，越来越多的企业将机器学习技术作为核心竞争力，并且运用在实际业务中。

但机器学习应用落地并非是一件轻松的事情，AI 开发者需要面对各个环节的挑战，包括目标定义、数据采集、数据清洗、特征提取、模型选择、模型训练、模型部署、模型监控等，其中任何一个环节出现问题，都可能影响算法和策略在最终业务中落地的效果，造成不可估量的损失。

在这样的背景下，就要求我们利用工程化技术去优化模型的自学能力，能够让模型保持持续更新迭代，随着数据和业务的变化不断进行自适应，避免衰退，并且能始终保持在最佳状态，为业务场景带来更好的效果和更多的价值。

除了上述效果以外，机器学习应用的开发效率也是阻碍落地的关键因素，即使像 Google 这样的大佬们，他们的 AI 科学家和工程也会遇到开发一周，上线三个月的情况，需要针对每个模型花费数月的时间去进行正确性检查，覆盖模型鲁棒性能、数据时序穿越、线上线下一致性、数据完整性等各个维度。

从团队协作维度看，数据、模型、算法的开发和部署需要不同的技能和知识，需要团队敏捷地进行沟通和协作，因此，建设一种可以在任何时间、任何环境被信任的团队合作模式、沟通渠道以及反馈机制，形成一个敏捷迭代、Kubernetes 一样的事实标准，可以方便 AI 工程师敏捷、快速地上线 AI 应用。

除了上面讲到的关于效果和效率这两个 AI 开发者应该关注的因素外，以下也是需要进行考虑和权衡的因素：

1. 成本：一般包括软硬件、人力的成本，企业要确保 ROI 可行。

2. 人才：人才短缺，开发者需要更好地精进技能，规划好 AI 工程化的技能树和学习路径，提高工程师自身竞争力。

3. 安全：AI 应用背后的数据、算法和模型必须要符合法规和标准，而且要确保 AI 应用和系统不会向外部泄露数据，不让非法的攻击侵入并影响业务系统。

基于以上的背景分析，MLOps 已经成为了机器学习生产落地中不可或缺的关键能力，构建一个靠谱、可以信任、从容应对新技术演进的机器学习系统，匹配让 AI 工程师高效且省心省力的机器学习应用开发流程，成为当前机器学习领域面临的一个非常关键的问题和挑战。

人工智能的趋势

趋势一：人工智能在企业中加速落地，越来越多地发挥价值

人工智能的技术发展经历了数次高潮和低谷，从 2012 年 AlexNet 在 ImageNet 大赛上夺魁之后，人工智能技术的研究和应用进入了新的高潮。机器学习不仅在学术界取得了很好的发展（AlexNet、VGGNet、GoogleNet、ResNet、Transformer 的 GPT-2、GPT-3、GPT-4 等算法模型层出不穷），在工业界的应用也飞速增长。主要表现为：

1. 落地场景类型增多，不仅在传统的感知类场景中有应用，包括图形识别、语音识别、自然语言处理，还在企业经营决策场景中有应用，包括风控、推荐、预测等。

2. 在企业内部落地的绝对数量上呈现指数级别增长。

趋势二：人工智能的应用从以模型为中心向以数据为中心转变

当前人工智能技术在企业内部正在加速落地，但是在人工智能应用的研究、模型设计和算法性能的提升方面出现了瓶颈，2021 年，吴恩达发表标题为：MLOps：From Model-centric to Data-centric AI 的线上演讲，在行业内引发了很大的反响，也标志着人工智能应用正在从传统的以模型为中心向以数据为中心转变。

吴恩达在演讲中，认为当前在工业界落地人工智能的现状是通过模型调优带来效果提升，这远远比不上通过数据治理调优带来的效果提升。

具体讲就是采用以模型为中心的方法就是保持数据不变，不断调整模型算法，使用更深、更复杂的网络层，更多的网络节点，更多的超参数等，但对最终结果的改善空间很小。

而采用以数据为中心的方法是保持模型算法不变，把主要精力花在提升数据质量上，比如改进数据标签、提高数据标注质量、保持数据在训练和预测等多个阶段的一致性等，相对来说容易取得比较好的结果。对于同一个人工智能问题，改进模型还是改进数据质量，效果提升的差异很大。

通过上图的数据比对，进一步验证了采用以数据为中心的方法在结果准确率提升上完胜采用以模型为中心的方法。

吴恩达的观点认为一个 AI 系统包括了代码和数据两部分，而且在一个真实场景中，AI 工程师有 80% 的时间都在处理数据，只有 20% 的时间是用来调整算法的。

为了顺应以数据为中心的发展趋势，吴恩达提出了 MLOps（Machine Learning Engineering for Production），他认为 MLOps 是帮助机器学习进行大规模企业应用的一系列工程化方法和实践，最重要的任务是在机器学习应用研发生命周期的各个阶段，包括数据准备、模型训练、模型上线、模型监控以及重新训练等，始终保持高质量的数据供给。

人工智能的现状

从业内统计数据来看，目前人工智能技术在企业内部落地成功率非常低，2019 年 05 月，Dimensional Research 发现，78% 的人工智能项目最终没有上线；2019 年 06 月，VentureBeat 发现，87% 的人工智能项目没有部署到生产环境；2022 年，Monte Carlo Data 预估人工智能项目的死亡率在 90% 左右。从这个数据来看，大部分机器学习模型最终没有上线，没有产生业务价值。

从人工智能实际从业者视角看，在企业内部落地人工智能项目的周期往往比预期的要长很多。

人工智能落地的阻碍

为什么在实验室内构建模型比较简单，但是到实际线上运行就困难重重呢？归根到底是人工智能系统研发的工程问题。

问题一：机器学习代码只是整个系统的一小部分

谷歌工程师 2015 年在 NIPS 的论文“Hidden Technical Debt in Machine Learning Systems”中提到人工智能系统包含数据收集、数据验证、资源管理、特征提取、流程管理、监控等诸多环节，但真正和机器学习算法相关的代码工作量仅仅占整个人工智能系统代码量的 5%，其余 95% 的代码量与数据相关。

问题二：数据是最主要的问题

数据给人工智能系统落地带来的问题主要表现为：

1. 可扩展性：海量的特征读取是一个挑战，训练往往需要海量的特征数据，不是 TB 级别，更多是 PB 级别。

2. 低延时：线上预测服务需要做到低延时和高吞吐的要求。

3. 模型效果衰退：机器学习模型是从数据中挖掘、提取规律的，当外部发生变化时，模型效果就会发生衰退，此时需要及时收集数据，重新进行训练，还需要很好的效果监控体系。

4.时序数据穿越：在处理和时间序列相关的数据时容易出现时序数据穿越的问题

时间数据穿越：在机器学习模型训练时，把发生在某一特定时间点之后的行为数据混入需要续连的数据集，这样训练效果往往不错，但是模型上线后效果不达标，因为本应该把特定时间点之后的行为数据排除在模型训练之外的

5. 训练和预测不一致：模型训练和预测使用的数据和代码逻辑不一致，导致线下训练效果不错，但是线上效果差

人工智能规模化落地的挑战

模型在企业内部规模化落地主要面临以下几方面的挑战：

1. 快：需要系统落地时间短，迭代速度快

2. 好：需要每个系统的落地效果达到预期，要体现业务价值

3. 省：需要每个系统的落地成本低，符合预期

人工智能规模化落地的解决策略：MLOps

回到软件研发领域看如何解决软件研发质量和效率问题的，早年，软件研发周期超出预期，代码质量不达标，甚至有线上服务崩溃，不响应用户请求等严重影响用户体验和业务问题出现，为了解决这些问题，采用了 DevOps 来改进研发模式，在保证质量的前提下，更快地提高版本发布的速度，实现更多、更快地研发和部署，从而进行更多的功能迭代和功能试错。通过各个企业内部推行 DevOps 实践和工具，软件研发和部署效率得到很大的提升。

那既然 DevOps 如此成功，我们可以借鉴 DevOps 的实践经验，把机器学习模型和现代软件模型研发结合起来形成一套人工智能系统落地流程，这就是 MLOps。

MLOps 定义

百科定义

MLOps 是一套在生产环境中部署和运维机器学习模型的可靠和高效的实践

这个定义把 MLOps 和 ModelOps 等同，但两者并不完全一样，MLOps 所包含的概念比 ModelOps 的概念要广泛，它不仅关心 Model，还包括 Data 和 Code。

谷歌云定义

MLOps 是一套标准流程和技术能力，用来快速可靠地构建、部署和运维机器学习系统

它认为 MLOps 是将 DevOps 的实现原则应用于机器学习系统，工程方面主要实现机器学习系统的持续交付和流水线。

Nvidia 定义

MLOps 是企业在不断扩大的软件产品和云服务帮助下成功运行人工智能系统的最佳实践。

它强调了软件和云的支撑作用，认为 MLOps 覆盖机器学习模型研发、部署和更新的全生命周期，包括数据采集、数据注入、数据分析、数据标注、数据准备、模型训练、模型评估、模型验证、模型部署等各个环节。

Databricks 定义

MLOps 是机器学习工程的核心功能，旨在简化将机器学习模型推向生产环节的过程，并随后维护和监控它们，MLOps 是一个协作过程，通过由数据科学家、DevOps 工程师和 IT 人员协作完成

这个定义增加了对多种角色协作的关注。

关键点：

1. MLOps 核心是一个包含多个循环的流水线，覆盖人工智能系统落地的全生命周期活动

2. MLOps 包含 CI（Continuous Integration，持续集成）、CD（Continuous Deploy，持续部署）、CT（Continuous Training，持续训练）、CM（Continuous Monitoring，持续监控） 多个活动

3. MLOps 涉及的对象包括代码、模型和数据

MLOps 相关的工具和平台

工具：流水线

为了支持 MLOps 全流程操作，需要借鉴 DevOps 实现原则和实践，通过自动化工具建立各种流水线，以提升整个流程的运转效率。MLOps 的开源流水线工具包括 Airflow 和 MLflow。

平台：针对机器学习场景定制的大数据平台

MLOps 实践需要复用大数据领域的分布式大规模存储和计算平台，并针对机器学习的具体场景做特定优化，以适应机器学习场景中的数据存储和计算的特殊需求。

特征数据和模型的存储和读取：

1. 满足利用海量数据进行训练的可扩展性需求

2. 满足线上预测高吞吐、低延时需求

3. 可考虑两个系统实现：离线训练用数据存储、实时生产用数据存储以及两者之间数据同步机制保障

4. 计算平台：特征计算能力支持，要支持海量文件数据的批处理计算以及来自消息队列的实时数据的流式计算

5. 消息队列：接受实时数据

6. 调度工具：各种计算和存储资源的调度

平台：MLOps 特有平台

1. Feature Store，特征平台，用于注册、发现、共享各种特征

2. Serving Tool，预测工具，提供高效预测服务的工具

3. Model Store，模型平台，用于注册、存储模型的平台

4. Evalution Store，评估平台，用于监控、A/B 测试的平台

MLOps 优势

1. 提高人工智能系统研发和运维效率

2. 提升人工智能业务可扩展性

3. 降低风险

MLOps VS XOps

Databricks 的 MLOps 双环流水线模型

Google Cloud 推荐的机器学习流水线自动化架构

MLOps VS DevOps

MLOps VS AIOps

AIOps（Artificial Intelligence for IT Operations）是在 IT 运维领域利用人工智能技术，基于已有的运维数据，通过机器学习模型进一步提升系统运维能力，提高运维效率，降低运维成本。

应用场景：

1. 流量评估

2. 容量管理

两者都需要使用机器学习模型，都需要读取大量数据，但是 AIOps 的业务场景集中在 IT 运维领域，目标是提升 IT 运维效率和降低成本，而 MLOps 本身没有业务属性，可以应用于各种业务领域。

MLOps VS DataOps

DataOps 是一种应用在数据分析领域的工程实践、流程和技术，覆盖从数据准备到数据报告的整个数据分析生命周期。

应用场景：

1. 数据分析流水线：定义一个数据分析的 DAG，即一系列数据相关的操作，从读取原始数据到抽取数据的某些元素再到终端用户可见的可视化报表。

2. 数据分析任务编排：定义一个数据分析任务，通过分布式计算集群进行计算任务的分发和汇总，最后得到需要的结果。

DataOps 应用在数据分析领域，最终用户感受到的是数据分析报表，MLOps 应用在机器学习领域，最终用户感受到的是依赖模型和数据的预测服务。

MLOps VS ModelOps

ModelOps 关注的对象是机器学习后得到的模型，适用场景是模型训练、模型部署和模型监控，目标是保证模型不断迭代的同时线上模型效果达到预期。MLOps 关注的对象不仅仅是模型，还包括模型所需要的特征数据和训练过程以及预测服务所需要的代码，适用场景是持续集成、持续部署、持续训练和持续监控。ModelOps 是 MLOps 的一个子集。

XOps 的共性：基于 DevOps 原则

1. 自动化：Ops 团队的目标是自动化，把任务所涉及的活动尽可能地通过软件实现自动执行

2. 协同：任务涉及的各方需要很好地沟通、反馈和协作

3. 持续改进：不断对各个阶段的活动进行工具和流程的改进，提升效率

4. 快速反馈：以用户需求为核心，快速反馈，实现闭环

人工智能系统从项目立项，到数据收集、模型训练，再到模型部署上线并最终产生实际业务价值的过程中会涉及各种角色的人员角色，主要包括以下：

多角色类型

产品经理

人工智能项目的发起人，指导团队生产符合预期且给企业带来最终商业价值的人工智能模型，并最终成功部署上线以满足用户需求。

产品经理要对用户需求和用户场景有最深刻的理解，知道如何评估项目的实际效果，了解如何度量项目最终产生的收益。同时需要关注项目落地产生的效果和能带来的商业价值，并从项目研发和运维成本、收益两方面进行衡量。

产品经理需要定义用户场景并给出项目落地收益的方式，同时承担项目商业分析的职能，包括项目的商业价值、用户场景分析、项目成功条件定义等。

数据科学家

也称作为 AI 科学家，是人工智能系统研发和运维中的特有角色，他从产品经理那获得用户需求和用户场景后进行分析，针对具体的商业问题，找出数据驱动的解决方案，产出符合预期的人工智能模型。

数据科学家擅长数据收集、数据统计分析、数据可视化和构建人工智能模型，但他们对模型上线后构建高吞吐、低延时的预测系统、分布式大数据存储、分布式计算系统、底层资源管理的容器编排系统以及监控系统可能不太熟悉。

他的大部分时间是花在模型调优、寻找合适的数据以及对数据进行各种特征工程处理上，最关注模型的效果。

数据工程师

数据工程师主要是配合数据科学家的工作，主要和数据相关。负责提供高质量的数据，一方面提供给数据科学家进行模型训练，另一方面提供给线上预测服务进行预测。

数据工程师擅长和各种分布式存储系统和分布式计算系统打交道，利用这些系统从各种数据源中得到数据，根据数据科学家的需求对数据进行各种处理。

他往往需要编写很多程序脚本或者工具，定义各种数据处理流水线来完成和数据相关的工作。

机器学习工程师

机器学习工程师是一个比较新的角色，数据科学家通过数据收集、数据探索和模型初步训练，得到一个可用的模型，这个模型往往是在规模较小的数据集上训练得到的，这个模型要部署到线上，还需要在线下通过海量数据并消耗海量计算资源来完成训练。而机器学习工程师就是负责完成模型在真实环节的训练，并把训练好的模型部署到线上系统提供稳定、可靠的服务。

他从数据科学家那里接手模型，从数据工程师那里对接数据，进行自动化模型训练、模型测试、效果验证，以及在生产环境中部署和监控模型。

DevOps 工程师

DevOps 工程师主要负责将人工智能预测系统和业务系统连接起来，负责业务系统相关的持续集成和持续部署。

他负责完成集成模型预测服务到最终用户应用程序中的业务，并记录相应行为数据到数据系统，用于后续持续训练。

他擅长业务研发，熟悉各种业务系统常用的架构和编程工具、语言等，但是对人工智能模型构建原理、训练过程可能并不是很了解，他需要关注业务系统的可伸缩性、稳定性和响应性。

运维工程师

运维工程师负责人工智能线上系统的运维，保证线上系统的稳定云效。

他应该对线上系统十分熟悉，擅长建立各种业务监控系统，通过监控发现线上服务稳定性相关的问题并进行各种运维操作，同时要求对云基础设施十分熟悉，比如资源扩容、资源缩容、流量调度等。而且他还需要进行线上系统的安全管理。

多角色协作问题

问题一：技术栈不一致导致模型线上、线下效果不一致

数据科学家擅长特征探索、数据转化、模型开发等工作，比较熟悉 Python 以及基于 Python 的 AI 开发库和工具。

而机器学习工程师、DevOps 工程师比较熟悉各种高级编程语言（Java、Go 等），主要编写高吞吐、低延时系统，同时他们对底层的资源调度、分布式计算、分布式存储、云原生等比较熟悉。

数据科学家使用 Python 技术栈进行各种特征转化的逻辑，这些逻辑并不能 100% 准确通过 Java 重新编写并在线上运行，可能导致模型预测偏差较大。

问题二：关注点不同导致对系统的需求不同

数据科学家关注的是模型或者算法的效果，比如用常见的指标来度量效果，而他对线上系统运行相关的事情不太关心，比如系统的高吞吐和低延时、弹性伸缩等。他会不断尝试引入新的数据进行探索和研究，并不断对模型进行调优或者尝试更复杂的算法，以取得更好的效果，相对来说，他对线上服务的改动会比较激进。

而机器学习工程师、DevOps 工程师往往不关心模型如何实现的，比如网络结构、算法相关的超参数等，他们更关注如何把模型部署到线上，并提供稳定可靠的服务。他要对线上服务负责，需要保证服务可用性，保证服务的 SLA 达标，因此会比较清晰与尽量少做修改，避免因为频繁更新引起故障，他对线上系统更有敬畏之心，改动相对保守一些。

协作问题的解决方案

基于以上两个问题分析，就会出现数据科学家抱怨工程师部署时间长，工程师抱怨科学家不懂线上服务，互相抱怨彼此不给力。

而解决这一协作问题就是需要开发和利用工具和平台，让这些角色各司其职发挥各自价值，这些工具和平台集合就是 MLOps。