本文介绍了MLOps在机器学习生命周期中的关键组件，包括模型开发、数据源探索、特征工程、模型训练与评估、可重复性、负责任的人工智能和生产化部署。强调了从业务目标开始，经过数据源选择、特征工程，到模型训练和监控的重要性。文章还讨论了模型部署的挑战，如依赖管理、容器化和监控，并提到了输入漂移和业务问题。最后，提到了治理和合规性，包括GDPR原则和数据治理的必要性。
🔎大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流🔎
📝个人主页－Sonhhxg_柒的博客_CSDN博客 📃
🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝
📣系列专栏 - 机器学习【ML】 自然语言处理【NLP】 深度学习【DL】
🖍foreword
✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。
如果你对这个系列感兴趣的话，可以关注订阅哟👋
文章目录
MLOps 影响整个组织中的许多不同角色，进而影响机器学习生命周期的许多部分。本章从较高的层次介绍了 MLOps 的五个关键组件（开发、部署、监控、迭代和治理），作为后续章节的基础，深入探讨了这些组件的更多技术细节和要求。
机器学习入门
要了解 MLOps 的主要特征，首先必须了解机器学习的工作原理并熟悉其特性。尽管它作为 MLOps 一部分的作用经常被忽视，但算法选择（或机器学习模型的构建方式）最终会对 MLOps 过程产生直接影响。
从本质上讲，机器学习是计算机算法的科学，它可以根据经验自动学习和改进，而不是通过显式编程来实现。这些算法分析样本数据（称为训练数据），以构建可以进行预测的软件模型。
例如，图像识别模型可能能够通过搜索图像中区分每种电表的关键模式，从照片中识别电表的类型。另一个例子是保险推荐模型，它可能会根据类似客户的先前行为来建议特定现有客户最有可能购买的其他保险产品。
当面对看不见的数据时，无论是照片还是客户，机器学习模型都会使用从以前的数据中学到的知识，基于未见过的数据与以前的数据在某种程度上相关的假设来做出最佳预测。
机器学习算法使用广泛的数学技术，模型可以采用多种不同的形式，从简单的决策树到逻辑回归算法，再到更复杂的深度学习模型（有关详细信息，请参阅“什么是机器学习模型？” ）。
模型开发
让我们更深入地了解 ML 模型开发作为一个整体，以便更全面地了解其组件，所有这些组件都会在部署后对 MLOps 产生影响。
制定业务目标
的过程开发机器学习模型通常从业务目标开始，该目标可以很简单，例如将欺诈交易减少到 < 0.1%，或者能够识别社交媒体照片上的人脸。业务目标自然伴随着绩效目标、技术基础设施要求和成本约束；所有这些因素都可以被捕获为关键绩效指标（KPI），这最终将使生产中模型的业务绩效得到监控。
重要的是要认识到机器学习项目不会在真空中发生。它们通常是较大项目的一部分，而该项目又会影响技术、流程和人员。这意味着建立目标的一部分还包括变更管理，这甚至可以为应该如何构建 ML 模型提供一些指导。例如，所需的透明度将强烈影响算法的选择，并可能推动提供解释和预测的需求，以便预测在业务层面转化为有价值的决策。
数据源和探索性数据分析
业务清晰目标确定后，是时候将主题专家和数据科学家聚集在一起，开始开发机器学习模型的旅程了。这首先是搜索合适的输入数据。查找数据听起来很简单，但在实践中，这可能是整个旅程中最艰巨的部分。
寻找数据来构建机器学习模型的关键问题包括：
-
有哪些相关数据集可用？
-
这些数据是否足够准确和可靠？
-
利益相关者如何获取这些数据？
-
这些数据可以实时获取吗？
-
是否需要用要预测的“基本事实”来标记某些数据，或者无监督学习是否有意义？如果是这样，这将花费多少时间和资源？
-
应该使用什么平台？
-
模型部署后，数据如何更新？
-
使用模型本身会降低数据的代表性吗？
-
所选数据集可以用于此目的吗？
-
使用条款是什么？
-
是否有某些特征（例如性别）在法律上不能在此业务环境中使用？
由于数据是驱动机器学习算法的重要组成部分，因此它总是有助于建立对数据模式的理解在尝试训练模型之前。探索性数据分析 (EDA) 技术可以帮助建立关于数据的假设，确定数据清理要求，并为选择潜在重要特征的过程提供信息。EDA 可以直观地进行，以获得直观的洞察力；如果需要更严格的要求，还可以进行统计。
特征工程与选择
EDA自然领先进入特征工程和特征选择。特征工程是从选定数据集中获取原始数据并将其转换为更好地代表要解决的潜在问题的“特征”的过程。“特征”是固定大小的数字数组，因为它是机器学习算法理解的唯一对象。特征工程包括数据清理，就花费的时间而言，这可能是 ML 项目的最大部分。
培训与评估
通过特征工程和选择来准备数据后，下一步是训练。训练和优化新机器学习模型的过程是迭代的；可以测试几种算法，可以自动生成特征，可以调整特征选择，并调整算法超参数。除了 - 或者在许多情况下由于 - 其迭代性质，就计算能力而言，训练也是 ML 模型生命周期中最密集的步骤。
当迭代很快变得复杂时，跟踪每个实验的结果。对于数据科学家来说，没有什么比无法重新创建最佳结果更令人沮丧的了，因为他们记不起精确的配置。实验跟踪工具可以大大简化记住数据、特征选择和模型参数以及性能指标的过程。这些使得可以并排比较实验，突出性能差异。
确定什么是最佳解决方案需要定量标准，例如准确性或平均误差，以及有关算法可解释性或其部署难易程度的定性标准。
再现性
虽然许多实验可能是短暂的，但需要保存模型的重要版本以供以后使用。这里的挑战是再现性，这通常是实验科学中的一个重要概念。机器学习的目标是保存有关模型开发环境的足够信息，以便可以从头开始以相同的结果重现模型。
如果没有可重复性，数据科学家几乎不可能自信地迭代模型，更糟糕的是，他们不太可能将模型移交给 DevOps，以查看实验室中创建的内容是否可以在生产中忠实地再现。真正的可再现性需要对所有涉及的资产和参数进行版本控制，包括用于训练和评估模型的数据，以及软件环境的记录。
负责任的人工智能
能够重现模型只是操作化挑战的一部分；DevOps 团队还需要了解如何验证模型（即模型做了什么、应该如何测试以及预期结果是什么？）。那些高度受监管的行业可能需要记录更多细节，包括模型的构建方式和调整方式。在关键情况下，模型可以独立重新编码和重建。
文档仍然是解决这一沟通挑战的标准解决方案。自动模型文档生成，从而工具会自动创建与任何经过训练的模型相关的文档，可以使任务变得不那么繁重。但在几乎所有情况下，都需要手工编写一些文档来解释所做的选择。
机器学习模型难以理解是其统计性质的一个基本结果。虽然模型算法带有标准的性能测量来评估它们的功效，但这些并不能解释预测是如何做出的。“如何”作为对模型进行健全性检查或帮助更好地设计特征的一种方式很重要，并且可能有必要确保满足公平性要求（例如，围绕性别、年龄或种族等特征）。这是可解释性领域，它与第一章中讨论的 Responsible AI 相关，并将在后面中进一步详细讨论。
随着全球对不受约束的人工智能影响的日益担忧，可解释性技术变得越来越重要。它们提供了一种减少不确定性并帮助防止意外后果的方法。当今最常用的技术包括：
正如我们在本节中所见，尽管模型开发发生在很早的时候，但它仍然是合并 MLOps 实践的重要场所。在模型开发阶段预先完成的任何 MLOps 工作将使模型更易于管理（尤其是在推向生产时）。
生产化和部署
生产和部署模型是一把钥匙MLOps 的组成部分提出了与开发模型完全不同的技术挑战。这是软件工程师和 DevOps 团队的领域，管理数据科学家和这些团队之间信息交换的组织挑战不容小觑。正如第一章所述，如果团队之间没有有效的协作，部署延迟或失败是不可避免的。
模型部署类型和内容
了解什么发生在这些在各个阶段中，退后一步问一下：到底要投入生产的是什么？模型由什么组成？模型部署通常有两种类型：
模型即服务或实时评分模型
通常是模型被部署到一个简单的框架提供实时响应请求的 REST API 端点（API 可以通过该端点访问执行任务所需的资源）。
嵌入式模型
这里的模型是打包成应用程序，然后发布。一个常见的示例是提供请求批量评分的应用程序。
当然，要部署的模型的组成取决于所选择的技术，但它们通常由一组代码（通常是 Python、R 或 Java）和数据工件组成。其中任何一个都可能对需要在生产环境中匹配的运行时和包具有版本依赖性，因为使用不同版本可能会导致模型预测不同。
一种减少方法对生产环境的依赖是将模型导出到可移植格式，例如 PMML、PFA、ONNX 或 POJO。这些旨在提高系统之间的模型可移植性并简化部署。然而，它们是有代价的：每种格式支持的算法范围有限，有时便携式模型的行为方式与原始模型略有不同。是否使用可移植格式是基于对技术和业务环境的透彻理解而做出的选择。
容器化
容器化是解决部署机器学习模型时依赖问题的日益流行的解决方案。Docker 等容器技术是虚拟机的轻量级替代方案，允许将应用程序部署在独立、自包含的环境中，满足每个模型的确切要求。
他们还可以使用蓝绿部署技术无缝部署新模型。1模型的计算资源也可以使用多个容器进行弹性扩展。编排许多容器是技术的作用，例如作为 Kubernetes，可以在云端和本地使用。
模型部署要求
那么呢生产化过程从完成模型开发到实际部署到生产中，需要解决哪些问题？有一点是肯定的：快速、自动化的部署始终优于劳动密集型流程。
对于生命周期短的自助服务应用程序，通常无需过多担心测试和验证。如果模型的最大资源需求可以通过 Linux cgroup 等技术安全地限制，那么完全自动化的单步推送到生产可能就完全足够了。使用这种轻量级部署模式时，甚至可以使用 Flask 等框架来处理简单的用户界面。除了集成的数据科学和机器学习平台之外，一些业务规则管理系统还可能允许对基本机器学习模型进行某种自主部署。
在面向客户的关键任务用例中，需要更强大的 CI/CD 管道。这通常涉及：
-
确保满足所有编码、文档和签核标准
-
在接近生产环境的环境中重新创建模型
-
重新验证模型的准确性
-
执行可解释性检查
-
确保满足所有治理要求
-
检查任何数据工件的质量
-
测试负载下的资源使用情况
-
嵌入到更复杂的应用程序中，包括集成测试
重重地对于受监管的行业（例如金融和制药），治理和监管检查将是广泛的，并且可能涉及人工干预。正如 DevOps 一样，MLOps 的愿望是尽可能自动化 CI/CD 管道。这不仅加快了部署过程，而且还支持更广泛的回归测试并减少部署中出现错误的可能性。
监控
一旦模型部署到生产中，这一点至关重要随着时间的推移，它继续表现良好。但良好的性能对于不同的人来说意味着不同的事情，特别是对于 DevOps 团队、数据科学家和企业来说。
DevOps 关注点
-
该模型是否足够快地完成工作？
-
它是否使用了合理数量的内存和处理时间？
这是传统的 IT 性能监控，DevOps 团队已经知道如何做好这件事。ML 模型的资源需求在这方面与传统软件没有太大区别。
计算资源的可扩展性可能是一个重要的考虑因素，例如，如果您要在生产中重新训练模型。深度学习模型比更简单的决策树有更大的资源需求。但总的来说，DevOps 团队中用于监控和管理资源的现有专业知识可以很容易地应用于 ML 模型。
数据科学家的担忧
数据科学家是对监控机器学习感兴趣模型的一个新的、更具挑战性的原因是：它们会随着时间的推移而退化，因为机器学习模型实际上是它们所训练的数据的模型。这不是传统软件面临的问题，而是机器学习固有的问题。ML 数学构建了训练数据中重要模式的简明表示，希望这是对现实世界的良好反映。如果训练数据很好地反映了现实世界，那么模型应该是准确的，因此是有用的。
但现实世界并不是静止不动的。六个月前用于构建欺诈检测模型的训练数据不会反映最近三个月开始出现的新型欺诈。如果给定的网站开始吸引越来越年轻的用户群，那么生成广告的模型可能会生成越来越不相关的广告。在某些时候，性能将变得不可接受，并且模型重新训练成为必要。需要多长时间重新训练模型取决于现实世界变化的速度以及模型需要的准确性，但重要的是，还取决于构建和部署更好模型的难易程度。
但首先，数据科学家如何判断模型的性能正在下降？这并不总是那么容易。有两种常见的方法，一种基于真实情况，另一种基于输入漂移。
地面实况
基本事实，把简而言之，正确答案是该模型需要解决的问题，例如，“这笔信用卡交易实际上是欺诈性的吗？” 在了解模型所做的所有预测的基本事实后，人们可以判断该模型的表现如何。
有时，预测后会快速获得基本事实，例如，在决定在网页上向用户显示哪些广告的模型中。用户可能会在几秒钟内点击广告，或者根本不点击广告。然而，在许多用例中，获取事实真相要慢得多。如果模型预测交易是欺诈性的，如何确认这一点？在某些情况下，验证可能只需要几分钟，例如致电持卡人。但是模型认为正常但实际上不正常的交易又如何呢？最好的希望是持卡人在审查每月交易时能够报告这些情况，但这可能会在事件发生后一个月内发生（或根本不会发生）。
在欺诈示例中，事实真相无法使数据科学团队每天准确地监控性能。如果情况需要快速反馈，那么输入漂移可能是更好的方法。
业务问题
-
该模型是否为企业带来了价值？
-
该模型的好处是否超过了开发和部署它的成本？（我们如何衡量这一点？）
确定的 KPI最初的业务目标是这个过程的一部分。在可能的情况下，应该自动监控这些，但这很少是微不足道的。在我们之前的示例中，将欺诈行为减少到交易量低于 0.1% 的目标依赖于建立基本事实。但即使监控这一点也无法回答这个问题：以美元计算，企业的净收益是多少？
这对软件来说是一个古老的挑战，随着机器学习支出的不断增加，数据科学家展示价值的压力只会越来越大。在缺乏“美元计”的情况下，有效监控业务 KPI 是最佳选择。基线的选择在这里很重要，理想情况下应该允许具体区分 ML 子项目的价值，而不是全局项目的价值。例如，可以根据基于主题专业知识的基于规则的决策模型来评估机器学习性能，以区分决策自动化和机器学习本身的贡献。
迭代和生命周期
开发和部署模型的改进版本是 MLOps 生命周期的重要组成部分，也是更具挑战性的部分之一。开发新模型版本的原因有多种，其中之一是模型漂移导致模型性能下降，如上一节所述。有时需要反映精细的业务目标和 KPI，而其他时候，只是数据科学家想出了更好的模型设计方法。
迭代
在一些快速发展的商业环境中，每天都有新的训练数据可用。模型的日常再训练和重新部署通常是自动化的，以确保模型尽可能反映最近的经验。
使用最新的训练数据重新训练现有模型是迭代新模型版本的最简单场景。但是，虽然特征选择或算法没有变化，但仍然存在很多陷阱。尤其：
-
新的训练数据看起来是否符合预期？通过预定义的指标和检查自动验证新数据至关重要。
-
数据是否完整、一致？
-
特征的分布与之前训练集中的特征分布大体相似吗？请记住，目标是完善模型，而不是从根本上改变它。
构建新模型版本后，下一步是将指标与当前实时模型版本进行比较。这样做需要在同一开发数据集上评估两个模型，无论是以前的版本还是最新版本。如果指标和检查表明模型之间存在很大差异，则不应重新部署自动化脚本，而应寻求手动干预。
即使在使用新训练数据的“简单”自动再训练场景中，也需要基于评分数据核对（可用时使用基本事实）、数据清理和验证、先前模型版本和集合的多个开发数据集经过仔细考虑的检查。其他情况下的再培训可能会更加复杂，不太可能实现自动重新部署。
例如，考虑通过检测显着输入漂移而进行的再训练。如何改进模型？如果有新的训练数据，那么用这些数据进行再训练是成本效益比最高的动作，可能就足够了。然而，在获取真实数据速度较慢的环境中，可能几乎没有新的标记数据。
这种情况需要数据科学家的直接发明，他们需要了解漂移的原因，并找出如何调整现有的训练数据以更准确地反映最新的输入数据。评估由此类变化生成的模型是很困难的。数据科学家必须花时间评估情况（时间随着建模债务的数量而增加），并估计对性能的潜在影响并设计自定义缓解措施。例如，删除特定特征或对现有的训练数据行进行采样可能会导致模型得到更好的调整。
反馈回路
在大型企业中，DevOps 最佳实践通常规定实时模型评分环境和模型再训练环境是不同的。因此，新模型版本在再训练环境中的评估很可能会受到影响。
一种方法为了减轻这种不确定性，可以进行影子测试，其中新模型版本与现有模型一起部署到实时环境中。所有实时评分均由现有模型版本处理，但每个新请求都会由新模型版本再次评分并记录结果，但不会返回给请求者。一旦两个版本都对足够的请求进行了评分，就可以对结果进行统计比较。影子评分还可以让 SME 对模型的未来版本有更多的了解，从而可以实现更平稳的过渡。
在前面讨论的广告生成模型中，如果不让最终用户有机会点击它们，就不可能判断模型选择的广告是好还是坏。在此用例中，影子测试的好处有限，A/B 测试更为常见。
在 A/B 测试中，两个模型都部署到实时环境中，但输入请求在两个模型之间分配。每个请求都由一个模型或另一个模型处理，而不是同时由两者处理。记录两个模型的结果以供分析（但绝不会针对同一请求）。从 A/B 测试中得出具有统计意义的结论需要仔细规划测试。
后面将更详细地介绍 A/B 测试的操作方法，但作为预览，最简单的 A/B 测试形式通常称为固定范围测试。这是因为在寻找具有统计意义的结论时，必须等到仔细预先确定的样本数量经过测试。在测试完成之前“偷看”结果是不可靠的。但是，如果测试是在商业环境中实时运行，则每个错误的预测都可能会造成损失，因此无法尽早停止测试可能会付出高昂的代价。
贝叶斯，特别是多臂老虎机，测试是越来越“频率论”固定范围测试的流行替代方案，目的是更快地得出结论。多臂老虎机测试是自适应的：决定模型之间划分的算法会根据实时结果进行调整，并减少表现不佳模型的工作量。虽然多臂老虎机测试更加复杂，但它可以降低将流量发送到性能不佳的模型的业务成本。
在边缘上迭代
迭代 ML 模型部署到数以百万计的设备，例如智能手机、传感器或汽车，对企业 IT 环境中的迭代提出了不同的挑战。一种方法是将数百万个模型实例的所有反馈转发到一个中心点并集中执行训练。特斯拉的自动驾驶系统在超过 500,000 辆汽车上运行，正是这样做的。对其 50 个左右的神经网络进行完全重新训练需要 70,000 个 GPU 小时。
谷歌对其智能手机键盘软件GBoard采取了不同的方法。而不是集中化重新训练时，每部智能手机都会在本地重新训练模型，并将发现的改进摘要集中发送给 Google。对每台设备的这些改进进行平均并更新共享模型。这种联邦学习方式意味着不需要集中收集单个用户的个人数据，每部手机上的改进模型可以立即使用，并且整体功耗下跌降落。
治理
治理是对企业实施的一套控制措施，以确保其履行对所有利益相关者的责任，从股东和员工到公众和国家政府。这些责任包括财务、法律和道德义务。支撑这三者的是公平的基本原则。
法律义务是最容易理解的。早在机器学习出现之前，企业就受到法规的约束。许多法规针对特定行业；例如，金融监管旨在保护公众和更广泛的经济免受金融管理不善和欺诈的影响，而制药业必须遵守规则以保障公众健康。商业实践受到更广泛的立法的影响，以保护社会的弱势群体，并确保在性别、种族、年龄或宗教等标准上的公平竞争环境。
最近，各国政府世界各地都制定了法规，以保护公众免受企业使用个人数据的影响。 2016 年欧盟通用数据保护条例 (GDPR) 和2018 年加州消费者隐私法案 (CCPA) 代表了这一趋势，它们对完全依赖数据的 ML 的影响是巨大的。例如，GDPR 试图保护个人数据免遭工业滥用，目的是限制对个人的潜在歧视。
GDPR 原则
GDPR 规定了处理个人数据的原则，值得注意的是，CCPA 的建立是为了密切反映其原则，尽管它确实存在一些重大差异。处理包括个人数据的收集、存储、更改和使用。这些原则是：
-
合法、公平、透明
-
目的限制
-
数据最小化
-
准确性
-
存储限制
-
完整性和保密性（安全）
-
问责制
各国政府现在开始将监管目光专门转向 ML，希望减轻其使用的负面影响。欧盟正在带头制定立法，以定义各种形式的人工智能的可接受用途。这并不一定是为了减少使用；而是为了减少使用。例如，它可以实现目前受数据隐私法规限制的面部识别技术的有益应用。但显而易见的是，企业在应用 ML 时必须注意更多监管。
除了正式立法之外，企业是否关心对社会的道德责任？从目前环境、社会和治理 (ESG) 绩效指标的发展情况可以看出，答案越来越多地是肯定的。信任对消费者很重要，而缺乏信任对企业不利。随着公众对这一主题的积极活动不断增加，企业正在参与负责任的人工智能的理念，即人工智能技术的道德、透明和负责任的应用。信任对股东也很重要，ML 风险的全面披露正在进行中。
将良好治理应用于 MLOP 具有挑战性。流程复杂，技术不透明，对数据的依赖是根本。MLOps 中的治理举措大致分为以下两类之一：
数据治理
确保适当使用和管理数据的框架
流程治理
使用明确定义的流程来确保所有治理考虑因素都在模型生命周期的正确时间点得到解决，并保留完整准确的记录
数据治理
数据治理关心的是正在使用的数据，尤其是用于模型训练，它可以解决以下问题：
-
数据的来源是什么？
-
原始数据是如何收集的以及使用条款是什么？
-
数据准确且最新吗？
-
是否存在不应使用的 PII 或其他形式的敏感数据？
机器学习项目通常涉及重要的管道，包括数据清理、组合和转换步骤。了解数据沿袭很复杂，尤其是在功能层面，但它对于遵守 GDPR 风格的法规至关重要。团队（以及更广泛的组织，因为这对高层也很重要）如何确保不使用 PII 来训练给定模型？匿名或伪匿名数据并不总是管理个人信息的充分解决方案。如果这些流程执行不正确，仍然有可能挑出个人及其数据，这违反了 GDPR 的要求。
尽管数据科学家的初衷是好的，但模型中的不适当偏差可能会很偶然地出现。ML 招聘模式对女性存在着众所周知的歧视，因为它发现某些学校（全是女性学校）在公司高层管理人员中的代表性较差，这反映了男性在该组织中历史上的主导地位。要点是，根据经验进行预测是一种强大的技术，但有时后果不仅适得其反，而且是非法的。
能够解决这些问题的数据治理工具还处于起步阶段。大多数人专注于回答有关数据沿袭的以下两个问题：
-
该数据集中的信息从何而来？这告诉我如何使用它？
-
该数据集是如何使用的，如果我以某种方式更改它，会对下游产生什么影响？
在现实世界的数据准备管道中，这两个问题都不容易完全准确地回答。例如，如果一位数据科学家编写了一个 Python 函数来在内存中处理多个输入数据集并输出一个数据集，那么如何确定新数据集的每个单元格是从哪些信息中导出的呢？
流程治理
流程治理注重形式化MLOps 流程中的步骤以及与其关联的操作。通常，这些操作是审查、签署和获取支持材料（例如文档）。目的是双重的：
-
确保每一项与治理相关的考虑都在正确的时间做出并正确执行。例如，在通过所有验证检查之前，不应将模型部署到生产中。
-
实现严格 MLOps 流程之外的监督。审计师、风险经理、合规官员和整个企业都希望能够在后期跟踪进度并审查决策。
有效实施流程治理是困难的：
-
机器学习生命周期的正式流程很难准确定义。对完整过程的理解通常分散在所涉及的许多团队中，通常没有人对整个过程有详细的理解。
-
为了成功应用该流程，每个团队都必须愿意全心全意地采用它。
-
如果这个过程对于某些用例来说过于沉重，团队肯定会颠覆它，并且会损失很多好处。
如今，流程治理在组织中最为常见传统上沉重的监管和合规负担，例如财务。除了这些之外，还是很少见的。随着 ML 逐渐渗透到商业活动的各个领域以及对负责任人工智能的日益关注，我们将需要新的创新解决方案来解决这个问题可以适用于所有企业。
总结
鉴于对 MLOps 所需的功能和受 MLOps 影响的流程的概述，显然数据团队——甚至整个数据驱动的组织——都不能忽视这一点。它也不是要从列表中勾选的项目（“是的，我们做 MLOps！”），而是技术、流程和人员之间复杂的相互作用，需要纪律和时间才能正确完成。
以下章节将深入探讨在 MLOps 中发挥作用的每个 ML 模型生命周期组件，介绍应如何完成每个组件以更接近理想的 MLOps 实现。
扫一扫
218
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
