【MLOps】第 2 章 : MLOps中的人

 🔎大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流🔎

📝个人主页－Sonhhxg_柒的博客_优快云博客 📃

🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝​

📣系列专栏 - 机器学习【ML】 自然语言处理【NLP】  深度学习【DL】

​​

 🖍foreword

✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。

如果你对这个系列感兴趣的话，可以关注订阅哟👋

文章目录

主题专家

商业决策建模

数据科学家

操作化和 MLOPS

数据工程师

软件工程师

开发运维

模型风险经理/审计师

机器学习架构师

总结

---

 尽管机器学习模型主要是由数据科学家构建的，认为只有数据科学家才能从强大的 MLOps 流程和系统中受益的观点是一种误解。事实上，MLOps 是企业人工智能战略的重要组成部分，影响着每个从事机器学习模型生命周期或从机器学习模型生命周期中受益的人。

本章介绍了这些人在机器学习生命周期中所扮演的角色，他们应该在一流的 MLOps 计划下理想地与谁联系并一起工作，以从机器学习工作中获得最佳结果，以及 MLOps 对他们的要求可能有。

值得注意的是，这个领域在不断发展，带来了许多可能未在此处列出的新职位，并在 MLOps 职责中提出了新的挑战（或重叠）。

在我们潜水之前详细信息，让我们看一下下表，该表提供了概述：

角色	在机器学习模型生命周期中的作用	MLOps 要求
主题专家	提供应围绕其构建 ML 模型的业务问题、目标或 KPI。 持续评估并确保模型性能符合或解决初始需求。	从业务角度理解已部署模型性能的简便方法。 用于标记不符合业务预期的模型结果的机制或反馈循环。
数据科学家	构建模型来解决主题专家提出的业务问题或需求。 交付可操作的模型，以便它们可以在生产环境和生产数据中正确使用。 与主题专家一起评估模型质量（原始模型和测试模型），以确保他们回答最初的业务问题或需求。	自动化模型打包和交付，以便快速、轻松（但安全）地部署到生产中。 能够开发测试以确定已部署模型的质量并进行持续改进。 从一个中央位置查看所有已部署模型（包括并行测试）的性能。 能够调查每个模型的数据管道以进行快速评估和调整，而不管模型最初是谁构建的。
数据工程师	优化数据的检索和使用以支持 ML 模型。	了解所有已部署模型的性能。 能够查看各个数据管道的完整详细信息，以解决底层数据管道问题。
软件工程师	将 ML 模型集成到公司的应用程序和系统中。 确保机器学习模型与其他非基于机器学习的应用程序无缝协作。	版本控制和自动测试。 在同一应用程序上并行工作的能力。
开发运维	执行和构建操作系统并测试安全性、性能、可用​​性。 持续集成/持续交付 (CI/CD) 管道管理。	将 MLOps 无缝集成到企业更大的 DevOps 策略中。 无缝部署管道。
模型风险经理/审计师	将 ML 模型投入生产给公司带来的整体风险降至最低。 在将 ML 模型投入生产之前确保符合内部和外部要求。	强大的、可能是自动化的报告工具适用于所有型号（当前或曾经生产的型号），包括数据沿袭。
机器学习架构师	确保为 ML 模型管道（从设计到开发和监控）提供可扩展且灵活的环境。 在适当的时候引入新技术，以提高机器学习模型在生产中的性能。	模型及其消耗的资源的高级概述。 能够深入研究数据管道以评估和调整基础设施需求。

主题专家

第一个简介考虑作为 MLOps 工作的一部分是主题专家（SME）；毕竟，ML 模型生命周期以它们开始和结束。虽然面向数据的人才（数据科学家、工程师、架构师等）拥有多个领域的专业知识，但他们往往缺乏对业务以及需要使用机器学习解决的问题的深入理解。

主题专家通常带着他们想要实现或解决的明确定义的目标、业务问题和/或关键绩效指标 (KPI) 来到谈判桌前，或者至少他们应该来到谈判桌前。在某些情况下，它们的定义可能非常明确（例如，“为了达到本季度的目标，我们需要将客户流失率减少 10%”或“由于计划外维护，我们每季度损失 N 美元；我们如何才能更好地预测停机时间？”）。在其他情况下，目标和问题可能不太明确（例如，“我们的服务人员需要更好地了解我们的客户以向他们追加销售”或“我们如何让人们购买更多小部件？”）。

在流程健康的组织中，以更明确的业务问题启动机器学习模型生命周期并不一定总是必要的，甚至不是理想的场景。对于主题专家来说，使用不太明确的业务目标可能是一个很好的机会，可以在开始任何数据探索或模型实验之前直接与数据科学家直接合作，以更好地构建问题并集思广益可能的解决方案。

如果没有来自主题专家的这一关键起点，其他数据专业人员（尤其是数据科学家）就有可能开始机器学习生命周期过程，试图解决问题或提供不服务于更大企业的解决方案。最终，这不仅对需要与数据科学家和其他数据专家合作构建解决方案的主题专家不利，而且对可能难以提供更大价值的数据科学家本身不利。

当 SME 不参与 ML 生命周期时，另一个负面结果是，如果没有真正的业务成果，数据团队随后将难以获得牵引力和额外预算或支持以继续高级分析计划。最终，这对数据团队、中小企业和整个企业都是不利的。

围绕中小企业参与、业务决策建模方法添加更多结构可以用来形式化要解决的业务问题，并确定机器学习在解决方案中的作用。

商业决策建模

决策建模创建决策过程的业务蓝图，允许主题专家直接构建和描述他们的需求。决策模型很有帮助，因为它们将机器学习置于主题专家的背景下。这使得模型能够与业务规则集成，并帮助中小企业充分了解决策背景和模型更改的潜在影响。

包含主题专家业务决策建模组件的 MLOps 策略可以成为一种有效的工具，确保对于那些不深入了解底层模型本身如何工作的人来说，真实世界的机器学习模型结果能够正确地融入情境。1个

主题专家不仅在机器学习模型生命周期的开始阶段发挥作用，而且在结束时（后期制作）也发挥作用。通常，为了了解机器学习模型是否表现良好或符合预期，数据科学家需要主题专家来关闭反馈循环，因为传统指标（准确度、精确度、召回率等）是不够的。

例如，数据科学家可以构建一个简单的客户流失预测模型，该模型在生产环境中具有非常高的准确性；然而，营销并不能阻止任何人流失。从业务角度来看，这意味着该模型不起作用，这是需要返回给构建 ML 模型的人员的重要信息，以便他们能够找到另一种可能的解决方案，例如引入提升模型来帮助营销更好地定位目标可能接受营销信息的潜在流失者。

鉴于 SME 在 ML 模型生命周期中的作用，在构建 MLOps 流程时必须具备一种让他们从业务角度理解已部署模型性能的简单方法。也就是说，他们不仅需要了解模型的准确性、精确度和召回率，还需要了解模型对预先确定的业务流程的结果或影响。此外，当性能出现意外变化时，主题专家需要一种可扩展的方式，通过 MLOps 流程来标记不符合业务预期的模型结果。

在这些明确的反馈机制之上，更一般地说，MLOps 应该以增加主题专家透明度的方式构建。也就是说，他们应该能够使用 MLOps 流程作为探索模型背后的数据管道、了解正在使用的数据、如何转换和增强数据以及正在应用哪种机器学习技术的起点。

对于也关心机器学习模型是否符合内部或外部法规的主题专家来说，MLOps 是提高这些流程透明度和理解性的另一种方式。这包括能够深入研究模型做出的个人决策，以了解模型做出该决策的原因。这应该是对统计和汇总反馈的补充。

最终，MLOps 作为一种反馈机制和与数据科学家就他们正在构建的模型进行交流的平台，与主题专家最相关。然而，还有其他 MLOps 需求，特别是与负责任的 AI 相关的透明度方面的需求，这些需求与主题专家相关，并使他们成为 MLOps 画面的重要组成部分。

数据科学家

的需要数据科学家是构建 MLOps 策略时要考虑的最关键的问题。可以肯定的是，他们有很多收获；当今大多数组织的数据科学家经常处理孤立的数据、流程和工具，因此很难有效地扩展他们的工作。MLOps 可以很好地改变这一点。

虽然大多数如果将数据科学家在 ML 模型生命周期中的角色严格视为模型构建部分，那么它（或者至少应该）要广泛得多。从一开始，数据科学家就需要与主题专家一起参与，理解并帮助构建业务问题，以便他们能够构建可行的机器学习解决方案。

现实情况是，ML 模型生命周期中的第一个关键步骤通常是最困难的。这对数据科学家来说尤其具有挑战性，因为这不是他们接受培训的地方。大学和在线的正式和非正式数据科学课程都非常强调技术技能，而不一定是与企业业务方面的主题专家进行有效沟通的技能，这些专家通常并不十分熟悉机器学习技术。再一次，业务决策建模技术可以在这里提供帮助。

这也是一个挑战，因为它需要时间。对于想要深入研究并亲自动手的数据科学家来说，在开始解决问题之前花费数周的时间来框架和概述问题可能是一种折磨。最重要的是，数据科学家通常与业务核心和主题专家隔离（在物理上、文化上或两者兼而有之），因此他们根本无法访问促进这些配置文件之间轻松协作的组织基础设施。强大的 MLOps 系统可以帮助解决其中的一些挑战。

克服第一个障碍后，根据组织的不同，项目可能会移交给数据工程师或分析师来进行一些初始数据收集、准备和探索。在某些情况下，数据科学家自己管理机器学习模型生命周期的这些部分。但无论如何，当需要构建、测试、强化然后部署模型时，数据科学家就会介入。

部署之后，数据科学家的角色包括不断评估模型质量，以确保其在生产中的工作方式能够回答最初的业务问题或需求。许多组织的根本问题通常是数据科学家是否只监控他们参与构建的模型，或者是否由一个人处理所有监控。在前一种情况下，当员工流失时会发生什么？在后一种情况下，建立良好的 MLOps 实践至关重要，因为监控人员还需要能够在模型漂移并开始对业务产生负面影响时迅速介入并采取行动。如果他们不是构建它的人，MLOps 如何让这个过程无缝衔接？

操作化和 MLOPS

整个2018年以及2019 年初，运营化是企业中 ML 模型生命周期和 AI 的关键流行语。简而言之，数据科学的操作化是将模型推向生产并根据业务目标衡量其性能的过程。那么操作化如何适应 MLOps 的故事呢？MLOps 使操作化更进一步，不仅包括推动生产，还包括在生产中维护这些模型以及整个数据管道。

尽管它们截然不同，但 MLOps 可能被视为新的操作化。也就是说，在企业实施的许多主要障碍已经消失的情况下，MLOps 是下一个前沿领域，并为企业中的机器学习工作提出了下一个重大挑战。

上一节中的所有问题都直接指向这里：数据科学家在 MLOps 方面的需求。从流程结束开始并向后工作，MLOps 必须为数据科学家提供对所有已部署模型以及任何正在接受 A/B 测试的模型的性能的可见性。但更进一步，这不仅仅是监控，还包括行动。一流的 MLOps 应该让数据科学家能够灵活地从测试中选择获胜模型并轻松部署它们。

透明度是 MLOps 的首要主题，因此毫不奇怪，它也是数据科学家的关键需求。深入了解数据管道并进行快速评估和调整（无论最初是谁构建模型）的能力至关重要。自动化模型打包和交付以快速轻松（但安全）地部署到生产环境是透明度的另一个重要方面，它是 MLOps 的重要组成部分，尤其是将数据科学家聚集到一个与软件工程师和 DevOps 团队信任的地方。

除了透明度之外，掌握 MLOps 的另一个主题——尤其是在满足数据科学家的需求方面——是纯粹的效率。在企业环境中，敏捷性和速度很重要。对于 DevOps 来说是这样，对于 MLOps 来说也是如此。当然，数据科学家可以以临时方式部署、测试和监控模型。但他们将花费大量时间重新发明每一个 ML 模型的轮子，而这永远不会为组织增加可扩展的 ML 流程。

数据工程师

数据管道位于的核心ML 模型生命周期和数据工程师又是数据管道的核心。由于数据管道可能是抽象且复杂的，因此数据工程师可以从 MLOps 中获得很大的效率。

在大型组织中，在 ML 模型应用之外管理数据流是一项全职工作。因此，根据企业的技术栈和组织结构，数据工程师可能更关注数据库本身而不是管道（特别是如果公司正在利用数据科学和 ML 平台来促进其他数据管道的可视化构建从业者，如业务分析师）。

最终，尽管组织的角色略有不同，但数据工程师在生命周期中的角色是优化数据的检索和使用，以最终为机器学习模型提供支持。一般来说，这意味着与业务团队（特别是主题专家）密切合作，以确定手头项目的正确数据，并可能为使用做好准备。另一方面，他们与数据科学家密切合作，解决任何可能导致模型在生产中表现不佳的数据管道问题。

鉴于数据工程师在 ML 模型生命周期中的核心作用，支撑着构建和监控部分，MLOps 可以带来显着的效率提升。数据工程师不仅需要了解生产中部署的所有模型的性能，还需要能够更进一步，直接深入到各个数据管道以解决任何潜在问题。

理想情况下，为了实现数据工程师（以及其他人，包括数据科学家）的最大效率，MLOps 不能包含简单的监控，而应该成为通往底层系统的桥梁，用于调查和调整 ML 模型。

软件工程师

这很容易排除传统软件工程师从 MLOps 角度考虑，但从更广泛的组织角度来看，考虑他们的需求以建立一个有凝聚力的企业范围的机器学习策略是至关重要的。

软件工程师通常不构建 ML模型，但另一方面，大多数组织不仅生产ML 模型，还生产经典软件和应用程序。软件工程师和数据科学家共同努力以确保更大系统的运行非常重要。毕竟，机器学习模型不仅仅是独立的实验；而且 机器学习代码、培训、测试和部署必须适合软件其余部分使用的持续集成/持续交付 (CI/CD) 管道。

例如，假设一家零售公司为其网站构建了基于 ML 的推荐引擎。机器学习模型是由数据科学家构建的，但要将其集成到网站的更大功能中，软件工程师必然需要参与。同样，软件工程师负责整个网站的维护，其中很大一部分包括机器学习模型在生产中的运行。

鉴于这种相互作用，软件工程师需要 MLOps 为他们提供模型性能详细信息，作为企业软件应用程序性能大图的一部分。MLOps 是数据科学家和软件工程师使用相同语言并对跨企业孤岛部署的不同模型如何在生产中协同工作有相同基线理解的一种方式。

软件工程师的其他重要功能包括版本控制，以确保他们当前正在处理什么；自动测试，以尽可能确定他们当前正在处理的内容是否正常工作；以及在同一应用程序上并行工作的能力（多亏了像 Git 这样允许分支和合并的系统）。 

开发运维

MLOps 为诞生于 DevOps 原则，但事实并非如此意味着它们可以作为完全独立和孤立的系统并行运行。

DevOps 团队在 ML 模型生命周期中有两个主要角色。首先，他们是执行和构建操作系统以及测试的人员，以确保机器学习模型的安全性、性能和可用性。其次，他们负责 CI/CD 流水线管理。这两个角色都需要与数据科学家、数据工程师和数据架构师密切合作。当然，紧密协作说起来容易做起来难，但这正是 MLOps 可以增加价值的地方。

对于 DevOps 团队，需要集成 MLOps融入企业更大的 DevOps 战略，弥合传统 CI/CD 和现代 ML 之间的差距。这意味着系统从根本上是互补的，并且允许 DevOps 团队自动化 ML 测试，就像他们可以自动化传统软件测试一样。

模型风险经理/审计师

在某些行业（特别是金融服务业），模型风险管理（MRM）功能是对于监管合规性至关重要。但不仅是受到高度监管的行业才应该受到关注，或者应该具有类似的功能；MRM 可以保护任何行业的公司免受性能不佳的 ML 模型带来的灾难性损失。此外，审计在许多行业中都发挥着作用，并且可能是劳动密集型的，这就是 MLOps 发挥作用的地方。

说到在 ML 模型生命周期中，模型风险经理发挥着关键作用，不仅分析模型结果，还分析 ML 模型寻求解决的初始目标和业务问题，以最大限度地降低公司的总体风险。他们应该在生命周期的一开始就与主题专家一起参与，以确保基于机器学习的自动化方法本身不会带来风险。

当然，他们在监控方面可以发挥作用（他们在模型生命周期中更传统的位置），以确保模型投入生产后风险得到控制。在概念和监控之间，MRM 也是模型开发和预生产后的一个因素，确保最初符合内部和外部要求。

MRM 专业人员和团队可以从 MLOps 中获益良多，因为他们的工作通常是艰苦的手动工作。由于 MRM 及其合作团队经常使用不同的工具，标准化可以极大地提高审计和风险管理的速度。

当涉及到特定的 MLOps 需求时，适用于所有模型（无论是当前正在生产还是过去已经投入生产）的强大报告工具是首要工具。该报告不仅应包括性能详细信息，还应包括查看数据沿袭的能力。自动化报告为 MLOps 系统和流程中的 MRM 和审核团队增加了额外的效率。

机器学习架构师

传统的数据架构师负责了解整体企业架构和确保它满足整个企业的数据需求。它们通常在定义如何存储和使用数据方面发挥作用。

如今，对架构师的要求要高得多，他们通常不仅要了解数据存储和使用的细节，还要了解 ML 模型如何协同工作。这增加了角色的复杂性，并增加了他们在 MLOps 生命周期中的责任，这就是为什么在本节中，我们将他们称为机器学习架构师，而不是更传统的“数据架构师”头衔。

机器学习架构师在ML 模型生命周期，确保为模型管道提供可扩展且灵活的环境。此外，数据团队需要他们的专业知识来引入新技术（在适当的时候），以提高 ML 模型在生产中的性能。正是出于这个原因，数据架构师的头衔还不够。他们需要深入了解机器学习，而不仅仅是企业架构，才能在 ML 模型生命周期中发挥这一关键作用。

这一角色需要整个企业的协作，从数据科学家和工程师到 DevOps 和软件工程师。如果不完全了解每个人和团队的需求，机器学习架构师就无法正确分配资源以确保机器学习模型在生产中的最佳性能。

当谈到 MLOps 时，机器学习架构师的角色是对资源分配有一个集中的看法。由于他们具有战略和战术角色，因此他们需要了解情况以识别瓶颈并使用该信息来寻找长期改进。他们的职责之一是确定可能的新技术或基础设施以供投资，不一定是无法解决系统可扩展性核心问题的操作性快速修复。

总结

MLOps 不仅适用于数据科学家；整个组织中的多元化专家小组不仅在 ML 模型生命周期中发挥作用，而且还在 MLOps 策略中发挥作用。事实上，每个人——从业务方面的主题专家到最具技术性的机器学习架构师——在生产中的 ML 模型维护中都发挥着关键作用。这一点最终很重要，不仅可以确保 ML 模型的最佳结果（良好的结果通常会导致对基于 ML 的系统的更多信任以及增加构建更多的预算），而且，也许更有针对性地保护业务免受概述的风险在上一章中。