芯技术 | 有机器学习加持，MLOps就比DevOps简单了？

深圳市智慧安防商会

随着机器学习技术的日益成熟，ML逐渐从学术研究走向落地商用，我们需要改进ML的部署过程。技术的成熟促使ML操作流程的改进。

你的公司决定研发机器学习（ML）。

你有一个才华横溢的数据科学家团队。

他们正在开发模型去解决几年前遥不可及的重要问题。

所有性能指标都让人惊喜。

项目展示时，老板们被惊掉了下巴。

高管们问你多久可以在生产中用上这个模型。

“应该很快。”你的内心OS。

毕竟所有最高级的数学问题都搞定了，日常IT工作能有多难呢？

什么是MLOps（机器学习模型运营化）？

MLOps是一门工程学科，旨在统一 ML 系统开发(dev)和 ML 系统部署(ops)，以标准化过程生产高性能模型的持续交付。

主流框架及使用打分（来源：麻省理工公开课）

事实证明，它骨感的不行。

Deeplearning.ai 报告称，“只有22%使用机器学习的公司成功部署了模型。是什么让它这么难？怎么才能改善？

让我们走进科学。

MLOps的挑战

在传统软件开发领域，DevOps 的实践使得在几分钟内将软件交付到生产环境并保持其可靠运行成为可能。DevOps 依靠工具、自动化和工作流来将偶然的复杂性抽象化（因方法不对，导致复杂情况时有发生），让开发人员专注于需要解决的实际问题。这种方法的有效性已经在大量公司的软件开发中广泛实践。那么为什么我们不能继续为ML做同样的事情呢？

虽然代码是在受控开发环境中精心开发的，但数据来自被称为‘现实世界’的无尽的熵源。

根本原因是ML和传统软件之间存在根本区别：ML不仅仅是代码，而是代码加数据。通过将算法应用于大量训练数据来创建 ML 模型，即最终进入生产的组件，这将影响模型在生产中的行为。最重要的是，模型的行为还取决于我们在预测时提供给它的输入数据，这让预测更加无法预测。

ML = 代码 + 数据

虽然代码是在受控开发环境中精心制作的，但数据来自被称为“现实世界”的无尽的熵源。它永远不会停止变化且永不受控。思考代码和数据之间关系的一种形象比喻是，就好像它们生活在共享时间维度，但在所有其他方面都是独立的不同平面上。ML过程的挑战是以受控的方式在这两个平面之间创建桥梁。

代码和数据各自为政，

我们可以将其视为具有共同维度的独立平面。

这种根本性的脱节导致了几个重要的挑战，任何试图将 ML 模型成功投入生产的人都需要迎接这些挑战，例如：

部署缓慢、脆弱且不一致

缺乏可重复性

性能降低（训练服务差）

上文中我们反复提及“数据”一词，让数据变得能用的数据工程确实提供了解决生产中ML难题不可或缺的重要工具和概念。为了破解它，我们需要结合DevOps和数据工程的实践，添加一些ML独有的实践。

因此，MLOps 可以通过以下交集定义：

与之相较DevOps的交集定义：

MLOps 是机器学习、DevOps 和数据工程的交集。

DevOps是开发、运维、质量保障的交集。

现在，让我们通过检查可用于实现 MLOps 目标的各个做法，更详细地了解这实际上意味着什么。

MLOps实践

混合团队？

我们已经确定，生产 ML 模型需要一组我们之前认为彼此独立的技能。为了取得成功，我们需要一个混合团队，共同涵盖这些技能范围。当然，一个人可能在所有方面都足够好，在这种情况下，我们可以称这个人为真正的 MLOps 工程师。但更现实的情况是，一个成功的团队将包括数据科学家或ML工程师，DevOps工程师和数据工程师。

让模型在笔记本上记录和推导出妙笔生花显然是不够的。

团队的确切组成、组织和头衔可能会有所不同，但关键的部分是意识到仅靠数据科学家无法实现 MLOps 的目标。即使一个组织包含所有必要的技能，如果他们不密切合作，它也不会成功。

业务开发或产品团队——用 KPI 定义业务目标

数据工程——数据采集和准备

数据科学 — 构建 ML 解决方案和开发模型

IT 或 DevOps — 完成部署设置，与科学家一起进行监控

另一个重要的变化是数据科学家必须精通基本的软件工程技能，如代码模块化、重用、测试和版本控制;让模型在凌乱的笔记本中工作是不够的。这就是为什么许多公司采用ML工程师的头衔，强调这些技能。在许多情况下，ML 工程师在实践中执行 MLOps 所需的许多活动。

机器学习管道

数据工程的核心概念之一是数据管道。数据管道是我们应用于源和目标之间的数据的一系列转换。它们通常定义为一个图形，其中每个节点都是一个转换，边缘表示依赖关系或执行顺序。有许多专用工具可帮助创建、管理和运行这些管道。数据管道也可以称为 ETL（提取、转换和加载）管道。

ML 模型总是需要某种类型的数据转换，这通常是通过脚本甚至文本中的单元格实现的，这使得它们难以管理和可靠运行。切换到适当的数据管道在代码重用、运行时可见性、管理和可伸缩性方面提供了许多优势。

由于我们还可以将 ML 训练视为数据转换，因此很自然地将特定的 ML 步骤包含在数据管道本身中，将其转换为 ML 管道。大多数模型需要两个版本的管道：一个用于训练，一个用于服务。这是因为通常情况下，数据格式（以及访问它们的方式）在每个时刻都非常不同，特别是对于我们在实时请求中提供服务的模型（而不是批量预测运行）。

Kubeflow Pipelines 中 ML 管道的可视化表示

ML 管道是独立于特定数据实例的纯代码工件。这意味着可以在源代码管理中跟踪其版本，并使用常规 CI/CD 管道自动部署，这是 DevOps 的核心做法。这使我们能够以结构化、自动化的方式连接代码和数据平面：

ML 管道连接数据和代码以生成模型和预测

请注意，有两个不同的 ML 管道：训练管道和服务管道。它们的共同点是，它们执行的数据转换需要以相同的格式生成数据，但它们的实现可能非常不同。例如，训练管道通常在包含所有功能的批处理文件上运行，而服务管道通常联机运行，仅接收请求中的部分功能，从数据库中检索其余功能。

但是，确保这两个管道一致很重要，因此应尽可能尝试重用代码和数据。一些工具可以帮助实现该目标，例如：

像TensorFlow Transform这样的转换框架可以确保基于训练集统计数据的计算（如规范化的平均值和标准偏差）是一致的

特征平台是存储不属于预测请求的值的数据库，例如使用数据流转换根据用户历史记录计算的特征

模型和数据版本控制

为了具有可重现性，一致的版本跟踪至关重要。在传统的软件世界中，版本控制代码就足够了，因为所有行为都由它定义。在 ML 中，我们还需要跟踪模型版本，以及用于训练它的数据，一些元信息，如训练超参数。

我们可以在像 Git 这样的标准版本控制系统中跟踪模型和元数据，但数据通常太大且可变，无法高效实用。避免将模型生命周期与代码生命周期相关联也很重要，因为模型训练通常按不同的计划进行。

还需要对数据进行版本控制，并将每个经过训练的模型与我们所使用的代码、数据和超参数的确切版本相关联。理想的解决方案是专用工具，但到目前为止，市场上还没有明确的共识，从业者主要基于文件/对象存储约定和元数据数据库使用许多不同的方案。

模型验证

另一个标准的DevOps实践是测试自动化，通常采用单元测试和集成测试的形式。通过这些测试是部署新版本的先决条件。拥有全面的自动化测试可以给团队带来极大的信心，从而大大加快生产部署的步伐。

ML 模型更难测试，因为没有模型能给出 100% 正确的结果。这意味着模型验证测试本质上必须是统计的，而不是具有二进制通过/失败状态。为了确定模型是否足以进行部署，需要确定要跟踪的正确指标及其可接受值的阈值，通常是经验性的，并且通常通过与以前的模型或基准进行比较。

这是一门令人兴奋的新学科，其工具和实践可能会迅速发展。

跟踪整个验证集的单个指标也是不够的。正如好的单元测试必须测试多个案例一样，我们需要单独验证相关数据段的模型，称为片段。例如，如果性别可以直接或间接地成为模型的相关特征，那么我们应该跟踪男性、女性和其他性别的单独指标。否则，该模型可能会出现公平问题或在重要细分市场中表现不佳。

如果您设法以自动化和可靠的方式验证模型以及 ML 管道的其余部分，您甚至可以关闭循环并实施在线模型训练（如果它对用例有意义）。

数据验证

一个良好的数据管道通常从验证输入数据开始。常见的验证包括文件格式和大小、列类型、null 或空值以及无效值。这些都是 ML 训练和预测所必需的，否则你可能会有一个行为不端的模型，最终会挠头，寻找原因。数据验证类似于代码域中的单元测试。

除了任何数据管道执行的基本验证外，ML 管道还应验证输入的更高级别统计属性。例如，如果特征的平均或标准偏差从一个训练数据集到另一个训练数据集发生很大变化，则可能会影响训练模型及其预测。

这可能反映了数据的实际变化，也可能是由处理数据的方式引起的异常，因此必须排除系统错误作为可能污染模型的原因，并在必要时修复它们。

TensorFlow Data Validation中的统计数据剖析示例

监测

监控生产系统以使其正常运行至关重要。对于ML系统来说，监控变得更加重要，因为它们的性能不仅取决于我们可以控制的因素，如基础设施和我们自己的软件，还取决于数据，但数据的可控性太低了。

除了监控延迟、流量、错误和饱和度等标准指标外，我们还需要监控模型预测性能。

监控模型性能的一个明显挑战是，在模型处理新数据时，我们通常没有一个经过验证的标签来比对模型的预测。在某些情况下，我们可能有一种间接的方式来评估模型的有效性，例如通过测量推荐模型的点击率。在其他的一些情况下，我们可能必须依赖于时间段之间的比较，例如，每小时计算一个正分类的百分比，并在模型偏离该时间的平均值超过百分之几时设置警报。

就像我们验证模型时一样，跨片段（而不仅仅是全局）监控指标也很重要，以便能够检测影响特定细分的问题。

MLOps 的未来

随着ML从研究到应用业务解决方案的成熟，我们也需要提高其部署流程的成熟度。幸运的是，我们可以ML之前的学科能给到我们许多实践经验。

下表总结了 MLOps 的主要做法以及它们与 DevOps 和数据工程做法的关系：

这是一门令人兴奋的新学科，其工具和实践可能会迅速发展，也会有很多机会开发和应用生产技术到ML。

酷芯自研工具链可智能地帮助客户将Pytorch/Tensorflow/Caffe/ONNX/Paddlepaddle 等工具产生的浮点模型量化为可在开发板端直接运行的定点模型，并采用图优化策略达到性能优化目的，确保量化精度、减少量化损失和上板调试过程，帮助客户高效验证NPU的相关性能。服务的客户覆盖了安防、车载、热成像、图传、无人机、地面机器人、运动相机等行业的头部客户超20余家。用过的客户都说好哦~

点击文末阅读原文：

MLOps: Machine Learning as an Engineering Discipline

来源：酷芯微电子

作者：Cristiano Breuel

翻译：酷芯PR团队

校对：酷芯软件工程部 & NPU设计部

END

继续滑动看下一个