🔎大家好，我是Sonhhxg_柒，希望你看完之后，能对你有所帮助，不足请指正！共同学习交流🔎
📝个人主页－Sonhhxg_柒的博客_CSDN博客 📃
🎁欢迎各位→点赞👍 + 收藏⭐️ + 留言📝
📣系列专栏 - 机器学习【ML】 自然语言处理【NLP】 深度学习【DL】
🖍foreword
✔说明⇢本人讲解主要包括Python、机器学习（ML）、深度学习（DL）、自然语言处理（NLP）等内容。
如果你对这个系列感兴趣的话，可以关注订阅哟👋
文章目录
在所有章节中，您都了解了传统软件开发过程和机器学习( ML ) 之间的区别。您已经了解了 ML 生命周期，并且了解它与传统的软件开发生命周期有很大不同。我们向您展示了如何使用开源软件在 Kubernetes 上构建完整的机器学习平台。我们向您展示了 ML 项目的生命周期，通过这些活动，您体验了项目生命周期的每个阶段是如何执行的。
在本章中，我们将向您展示我们想要提出的一些关键想法，以加深您对该主题的了解。本章将涵盖以下主题：
- 识别 ML 平台用例
- 操作机器学习
- 在 Kubernetes 上运行
这些主题将帮助您决定何时何地使用我们在本书中介绍的机器学习平台，并帮助您建立正确的组织结构，以便在生产中运行和维护平台。
识别 ML 平台用例
正如前面章节中所讨论的，理解什么是机器学习以及它与其他机器有什么不同是非常必要的。密切相关的学科，例如数据分析和数据科学。可能需要数据科学作为 ML 的前身。它在您不确定 ML 算法是否可以解决问题的研究和探索阶段很有帮助。在前面的章节中，您使用了数据科学实践，例如问题定义、业务指标隔离和算法比较。虽然数据科学是必不可少的，但也有一些机器学习用例不需要那么多数据科学活动。这种情况的一个例子是使用 AutoML 框架，我们将在下一节中讨论。
确定 ML 是否能最好地解决问题并选择 ML 平台有点像鸡和蛋的问题。这是因为，为了确保 ML 算法能够最好地解决某个业务问题，它需要一些数据科学工作，例如数据探索，因此需要一个平台来工作。如果您处于这种情况，最好的选择是选择一个开源平台，例如我们在本书中介绍的开放数据中心( ODH )。因为它是完全开源的，所以不需要商业协议和许可证即可开始安装和使用平台，你已经看到了平台的能力。一旦你有了一个平台，你就可以使用它来启动你的研究和数据探索，直到你可以断定 ML 是否是解决业务问题的正确方法。然后，您可以在项目生命周期的剩余时间内继续使用该平台，也可以放弃它而不会产生任何平台成本。
在某些情况下，您可能已经知道 ML 可以解决业务问题，因为您在其他地方看到过类似的实现。在这种情况下，选择我们介绍的 ML 平台也是一个不错的选择。但是，您也可能处于没有强大的数据科学团队的情况。您可能有一些数据工程师和 ML 工程师了解模型开发的过程，但对他们的数据科学技能没有信心。这就是 AutoML 作为考虑因素出现的地方。
考虑 AutoML
为了以最简单的形式定义它，AutoML 是关于自动生成 ML 模型，几乎没有需要数据科学工作。稍微详细一点，它是关于自动算法选择、自动超参数调整和自动模型评估。
AutoML 技术以框架或软件库的形式出现，可以从给定的数据集生成 ML 模型。在撰写本书时，市场上已经有几个 AutoML 框架可用。以下列表显示了当前可用的一些流行的 AutoML 框架。还有很多其他 AutoML 框架没有在这里列出，我们鼓励您探索它们：
- BigML – 端到端的 AutoML商业化销售的企业平台。
- MLJAR——一个开放的源 AutoML 框架。
- H2O.ai – 一个完整的开源包含 AutoML 框架的 ML 平台。
- TPOT – 将自己视为数据科学家助理。这是一个开发的开源 AutoML 框架由宾夕法尼亚大学计算遗传学实验室提供。
- MLBox – 一个开放的源 AutoML Python 库。
- Ludwig – 一个工具箱零代码 ML 模型开发包括 AutoML。
- Auto-sklearn – 一个开放的基于 scikit-learn ML 库的源 AutoML 工具包。
- Auto-PyTorch – 具有自动神经网络的开源 AutoML 框架架构搜索。它可以自动优化神经网络架构。
- AutoKeras – 一个开源 AutoML 框架基于 Keras ML 库。
同样重要的是要注意可以使用其中一些框架和库在我们的机器学习平台或任何机器学习平台内或与之结合。
商业平台
ML 平台的商业供应商，包括云提供商，也包括 AutoML 产品和他们的投资组合中的服务。谷歌有 Google Cloud AutoML，微软有 Azure 机器学习，亚马逊有 Sagemaker Autopilot，IBM 有带有 AutoML 和 AutoAI 组件的 Watson Studio。但是，这些供应商将其 AutoML 产品和服务作为其 ML 平台产品的一部分出售，这意味着您必须使用他们的 ML 平台才能利用 AutoML 功能。
ODH
您已经了解 ODH 如何允许您选择要安装的组件，它还允许您安装通过更新kfdef清单文件将一个组件替换为另一个组件。这增加了额外的灵活性，您可以选择哪些组件作为平台的一部分。例如，假设您的数据科学团队只需要 JupyterHub 和 MLflow 就可以开始探索使用 ML 解决业务问题的可能性。在这种情况下，您可以选择仅安装这些组件。这将节省您的计算资源，从而减少云计算费用。
无论您选择哪个 ML 平台，都必须清楚地建立可操作 ML 平台的路径。这包括找到可以在生产中运行平台的合适人员，并将 ML 生命周期中的角色映射到现有组织。这还包括建立一些流程和沟通渠道，这将我们带入下一个主题。
操作机器学习
如前几章所述，如果您的模型获得在生产环境中部署和使用。操作化不仅仅是部署 ML 模型。要在生产中成功地启用支持 ML 的应用程序，还需要解决其他一些问题。让我们开始吧。
设定业务预期
确保业务利益相关者了解开展业务的风险非常重要使用 ML 模型的预测做出决策。您不希望您的组织因机器学习而失败。Zillow 是一家房地产公司，其产品Zestimate 对 ML 进行了大量投资，但由于对房地产价格的错误估计而损失了 5 亿美元。他们最终以 ML 模型设定的价格购买房产，最终以低得多的价格出售。
ML 模型并不完美；他们犯错误。企业必须接受这一事实，并且不能完全依赖 ML 模型的预测而不查看其他数据源。如果企业未能接受这一事实，则可能会因错误的期望而导致无法弥补的损失。这些损害包括声誉损害、企业失去信任，甚至是监管罚款和处罚。
另一种情况是某些算法，尤其是深度学习，是无法解释的。它必须传达给企业，因为在某些情况下，出于监管目的可能需要可解释的算法。一些监管机构可能需要您解释商业决策背后的原因。例如，假设 ML 模型确定新的银行客户不是有风险的个人，但结果却是被某些监管机构列入黑名单或制裁的个人；在调查和事后分析期间，金融机构可能需要向监管机构解释这一决定背后的原因。或者，更糟糕的是，该组织可能会被罚款数百万美元。
避免对业务过度承诺结果。IBM Watson 的想法是，机器学习可以通过理解来自多个医疗机构的诊断数据来诊断癌症，并且可能帮助甚至替代医生在未来进行更可靠的癌症诊断。这引起了很多关注，许多组织都对这个想法进行了投资。然而，事实证明这是一项非常艰巨的任务。它不仅造成了损失，而且还以某种方式损害了品牌。
总而言之，在决定是否使用 ML 模型来预测业务决策之前，请确保业务了解模型未按预期运行时的风险和后果。设定正确的期望。对什么是可能的，什么是困难的保持透明。一些 ML 模型可能能够在特定业务流程中替代人类，但并非所有 ML 模型都能实现超人的能力。
处理肮脏的现实世界数据
您用于模型训练的数据是在受控环境中测试的准备好的数据集。然而，在现实世界的环境中并非如此。在你的模型得到之后部署到生产环境中，您必须期待脏数据。您可能会收到结构错误的数据，并且大部分数据是新的，并且在训练期间模型从未见过。为确保您的模型适合生产，请避免过度拟合，并使用与其在生产中看到的数据集最接近的数据集彻底测试模型。如果可能，使用数据增强技术甚至制造数据来模拟生产场景。例如，一个在使用胸部 X 射线扫描诊断患者方面效果很好的模型可能在一个诊所中运行良好，但在另一个使用较旧医疗设备的诊所中可能不适用。这背后有一个真实的故事，它不起作用的原因是 X 射线扫描仪生成的扫描显示机器传感器中存在灰尘颗粒。
总而言之，避免过度拟合。将可靠的数据清理过程作为推理的一部分管道。通过拥有来自各种来源的合适数据集，为可能出现的最坏输入数据做好准备。当您的模型没有返回预期的结果时，请做好准备。
处理不正确的结果
想象一下，您有一个信用卡欺诈检测，它将常规交易标记为欺诈。这可能有很多原因，例如您的模型可能没有意识到圣诞节期间的支出高于正常水平。您需要有能力调查此类这就是为什么在适当的位置进行日志记录至关重要的原因。这将允许您回忆模型对生产中向其提出的特定问题的回答。您将需要它来调查模型问题。
发生这种情况时，您必须准备好面对模型返回的错误信息的后果。而且，您必须能够通过不时使用新数据集更新模型来解决错误的结果。您还必须能够随时间跟踪模型的性能。您已经在前一章中看到了监控是如何进行的。模型性能随时间的变化也称为漂移。有两种漂移。模型启动时发生数据漂移接收未经训练的新型数据。例如，保险欺诈检测模型运行良好，直到它开始看到新数据，其中包括该模型以前从未见过的新保险产品。在这种情况下，模型不会产生可靠的结果。换句话说，您的模型性能已经下降。另一个例子是你的模型是针对某个人口或年龄组进行训练的，然后突然出现了一个新的年龄组。同样，ML 模型返回不可靠结果的可能性也更高。概念漂移是指输入数据和标签之间的函数关系已经改变。例如，在欺诈检测模型中，根据新规定，以前不被视为欺诈的交易现在被标记为欺诈或异常。这意味着该模型将产生更多的假阴性结果，从而使该模型不可靠。
在这些情况下，您必须有一套流程来解决这些问题。您必须有一个流程来确定何时手动重新训练模型，甚至在检测到漂移时自动重新训练模型。您可能还想实现异常检测在输入数据中。这可确保您的模型仅在输入数据有意义时才放弃结果。这也避免了对模型的滥用或攻击。这些自动化要求可以集成为您的持续集成和部署管道的一部分。
保持持续交付
您已经了解了如何在平台中手动运行模型构建和模型部署。您还了解了如何使用 Airflow 自动化部署工作流程。虽然数据团队中的科学家或 ML 工程师可以手动执行或触发此类操作，在现实世界中，您还需要有人或团队来维护这些管道以确保它们始终正常工作。您可能希望有一个专门的平台团队来维护执行管道的底层平台，或者您可以将此责任分配给数据工程团队。无论您选择哪种方法，重要的是必须有人负责确保部署管道始终正常工作。
尽管 ODH 运营商完全管理 ML 平台，但您仍然需要有人负责维护它。确保 Kubernetes 操作员是最新的。必要时应用安全补丁。
对于一些关键工作负载，您可能无法自动部署到生产环境。在将更新发布到生产中的模型之前，需要手动批准。在这种情况下，您需要通过将此流程嵌入平台或通过与手动审批流程相互协商来建立此审批流程。然而，目标是让某人负责维护持续交付服务。
总之，持续交付必须始终有效，这样模型开发生命周期才能有更快的反馈周期。此外，如果检测到漂移，您将始终拥有一个随时可用的交付管道，可以交付更新版本的模型。
管理安全
在实施 ML 项目时，安全性是另一个需要关注的关键领域。你在前面看到过ML 平台可以通过使用OpenID Connect ( OIDC ) 或OAuth2（一种标准）来保护的章节认证机制。不同的平台组件可以利用为更无缝的用户提供相同的身份验证机制经验。您使用了一个名为 Keycloak 的开源工具，它是身份和访问管理( IAM ) 系统的行业标准实现，主要支持 OIDC、安全断言标记语言( SAML ) 等。Seldon Core API 允许暴露于 REST 的 ML 模型受到相同身份验证机制的保护。有关更多详细信息，请参阅 Seldon Core 文档。
总而言之，ML 平台必须受到身份验证机制的保护，最好是 OIDC。这也允许实现单点登录( SSO )。此外，您还需要保护您部署的模型，以确保只有目标受众可以访问您的 ML 模型。最后，必须有人负责维护您的平台使用的 Keycloak 实例，并且必须有人或团队管理对平台资源的访问。
遵守合规政策
在某些业务环境中，合规性是运营的核心。金融机构有一个完整的部门来管理合规性。这些合规规则通常来自监督金融机构运营的监管机构。根据您的 ML 平台将在哪个国家/地区使用和托管，监管政策可能会阻止您将数据移出本地数据中心。或者，可能需要加密静态数据。
好消息是您的平台足够灵活，可以针对此类合规措施进行配置。多亏了 Kubernetes，它可以在本地或任何云提供商中运行。您还可以在云中运行 ML 平台，同时拥有本地存储或利用混合云策略。
另一件事是平台中的每个组件都是可更换和可插拔的。例如，您可以使用现有的监管机构批准的 OIDC 提供商，而不是使用 Keycloak 的专用实例。
合规性通常会成为 ML 项目进展的障碍。如果您打算使用商业平台而不是您在本书中构建的平台，请始终考虑在决定之前的合规性或监管要求。云中的一些商业平台可能无法遵守数据主权，尤其是在主要云提供商还没有本地数据中心的国家。
换句话说，在规划 ML 平台的架构时，请始终考虑合规性要求。
应用治理
考虑到上述考虑因素后，另一个需要清除以运行 ML 平台的重要领域是治理。这是你的地方将设计组织结构、角色和职责、协作模型和升级点。作者主张建立一个具有非常高协作水平的跨职能团队。然而，这在现实世界中并不总是可能的。有些组织具有非常明确的层次结构和孤岛，拒绝改变现状。如果您在这种类型的组织中，则在实施我们在此处介绍的 ML 平台时可能会遇到一些障碍。
该平台的主要特点之一是它是一个自助服务平台。它允许数据科学家、ML 工程师和数据工程师启动他们的笔记本服务器和 Spark 集群。但是，这也将导致更难以预测的云计费或运营成本。如果你是项目的数据架构师，你的部分工作就是说服领导团队和平台团队相信他们的数据科学家和机器学习工程师。
理想情况下，围绕 ML 项目设计组织结构的最佳方式是拥有一个平台团队。该团队负责运行 ML 平台。然后，该团队在软件即服务( SaaS ) 模型中充当数据和应用程序团队（也称为流对齐团队）的服务提供者。平台团队的目标是确保流对齐的团队可以执行他们在平台上的工作尽可能顺利和迅速。数据科学和数据工程团队可以是流对齐的团队，他们是平台的主要用户和平台团队的主要客户。DevSecOps 或 DevOps 团队可以一起坐在同一个组织单元中，因为平台团队为流对齐的团队提供 DevOps 服务。图 11.1显示了一个组织结构示例，您可以使用 Team Topologies 表示法来实施该组织结构以运行 ML 项目：
图 11.1 – 示例 ML 项目团队结构
在图 11.1中，共有三个流对齐的团队，即数据科学团队、数据工程团队和软件工程团队。所有三个流对齐的团队正在相互协作，目标是在生产中交付支持 ML 的应用程序。还有三个平台团队。云基础架构团队正在向另外两个平台团队提供云平台即服务( PaaS )：ML 平台团队和 MLOps 团队。ML 平台团队和 MLOps 团队都将 ML PaaS 和 MLOps 作为服务提供给所有三个流对齐的团队。紫色框代表一个支持团队。这就是中小企业和产品所有者所在的位置。该团队为所有流对齐的团队启用并提供支持。
您必须注意，这只是一个示例；您可能希望将 ML 平台团队和 MLOps 团队或数据科学和数据工程团队合并在一起，这完全可以。
如果您想了解有关此类组织设计符号的更多信息，您可能需要阅读有关团队拓扑的信息。
我们可以总结如下：
- 使用您在第 2 章“理解 MLOps ”的图 2.7中看到的 ML 生命周期图来绘制团队当前的组织结构。
- 清楚地传达角色和职责。
- 设置协作渠道和反馈点，例如设计高峰会议和聊天组。
假设你不能打破筒仓；在筒仓之间建立定期会议，并建立一个更简化移交流程。但是，如果您想充分利用 ML 平台的潜力，我们强烈建议您组建一个跨职能和自组织的团队来交付您的 ML 项目。
在 Kubernetes 上运行
使用 ODH 运算符，ML 平台真正释放了 Kubernetes 作为 ML 平台基础设施层的全部潜力。运营商生命周期管理（OLM）框架使ODH运营商能够简化运维ML 平台。几乎所有的操作工作以 Kubernetes 原生方式完成，您甚至可以启动多个 ML 平台只需点击几下。Kubernetes 和 OLM 还允许您实施平台即代码( PaC ) 方法，使您能够实施 GitOps 实践。
您在本书中看到的 ML 平台适用于普通 Kubernetes 实例或任何其他类型的 Kubernetes，甚至是基于 Kubernetes 的平台。事实上，最初的 ODH 存储库主要是为 Red Hat OpenShift 设计和构建的。
避免供应商锁定
Kubernetes 保护您免受供应商锁定。由于额外的容器化和容器编排层，您的所有工作负载都不会直接在基础架构层上运行，而是通过容器运行。这允许 ML 平台托管在任何有能力的基础设施。无论是在本地还是在云端，操作都是一样的。这还允许您在需要时无缝切换到不同的云提供商。与云供应商提供的商业平台相比，这是使用此 ML 平台的优势之一。您不受供应商锁定的约束。
例如，如果您使用 Azure ML 作为您选择的平台，您将无法使用 Azure 作为您的基础架构提供程序。如果不更改平台和部署架构，您将无法将整个 ML 项目转移到另一个云供应商。换句话说，切换到不同的云供应商的成本是如此之高，以至于你基本上被原供应商所困。
考虑其他 Kubernetes 平台
此 ML 平台并非必须仅在 vanilla Kubernetes 平台上运行。如中所述在上一节中，最初的 ODH 被设计为在 Red Hat OpenShift 上运行，而在本书中，您设法让它在 minikube（一个单节点 vanilla Kubernetes）上运行。
还有许多其他 Kubernetes 平台，包括主要云提供商提供的平台。以下列表包括最常见的列表，不按特定顺序排列，但其他新兴的基于 Kubernetes 的平台刚刚进入市场或要么处于测试阶段或开发中在撰写本文时：
- Kubernetes
- 红帽 OpenShift 容器平台( OCP )
- 谷歌 Kubernetes 引擎( GKE )
- 亚马逊 弹性 Kubernetes 引擎( EKS )
- Azure Kubernetes 服务( AKS )
- VMware Tanzu
- Docker 企业版( Docker EE )
虽然我们已经在 Kubernetes 和 Red Hat OpenShift（ML 平台）中测试了这个平台你在 minikube 中构建的可以也可以在上述任何 Kubernetes 平台和其他平台上构建。但是，未来呢？ODH 将走向何方？
路线图
ODH 是一个活跃的开源项目，主要由世界上最大的开源公司 Red Hat 维护。ODH 将不断更新，为产品。但是，由于 ML 和 MLOps 领域也相对较新并且仍在不断发展，因此随着时间的推移，看到项目中的重大变化和枢纽并不是不自然的。
在编写本书时，ODH 的下一个版本包括以下更改（如图 11.2所示）：
图 11.2 – ODH 的下一个版本
您还没有探索 ODH 的其他功能，因为它们更适合数据工程和数据分析空间。一个例子是数据虚拟化和使用 Trino 和 Superset 进行可视化。如果您想了解有关这些功能的更多信息，您可以在您构建的同一 ML 平台中探索它们，只需更新kfdef文件以将 Trino 和 Superset 包含为您的 ML 平台的组件。您将在 ODH GitHub 项目中找到这些kfdef文件的一些示例。
您可以在以下 URL 查找 ODH 的未来路线图：https ://opendatahub.io/docs/roadmap/future.html 。
未来，可能会有另一个开源 ML 平台项目出现在市场上。保持开放的心态，永远不要停止探索其他开源项目。
概括
您在本书中获得的有关 ML、数据科学和数据工程、MLOps 以及 ML 生命周期的知识也适用于任何其他 ML 平台。您不仅获得了有关在 Kubernetes 中运行 ML 项目的重要见解和知识，还获得了从头开始构建平台的经验。在后面的章节中，您能够获得实践经验并戴上数据工程师、数据科学家和 MLOps 工程师的帽子。
在写这本书的时候，我们意识到这个主题很广泛，深入研究书中涵盖的每个主题可能对某些人来说太过分了。尽管我们已经接触了 ML 平台的大部分组件，但对于每个组件还有很多需要了解的地方，尤其是 Seldon Core、Apache Spark 和 Apache Airflow。为了进一步了解这些应用程序，我们建议您浏览官方文档页面。
ML、AI 和 MLOps 仍在不断发展。另一方面，尽管 Kubernetes 已经有将近 8 年的历史，但对于大多数企业组织来说，它仍然相对较新。正因为如此，这个领域的大多数专业人士仍在学习，同时建立新的标准。
随时了解最新的 ML 和 Kubernetes 趋势。您已经拥有足够的知识来自行推进该主题的学习。
1287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
