MLOps过度拟合的原因
MLOps过度拟合的原因' can be condensed as 'MLOps过度拟合原因'.
VC调查显示，今天有数百家公司自称属于MLOps类别。
MLOps系统为机器学习实践者提供基础设施，使他们能够以稳健且可重现的方式管理其工作的整个生命周期，从开发到生产。MLOps工具可以满足端到端的需求，也可以专注于特定阶段（例如研究/开发）或过程中的特定部分（例如特征）。
数据领域涉及从主要使用特定SQL语句的分析师到运行专有算法的博士之间的一系列数据从业人员。
是否存在一种DevOps方法适用于所有情况，还是机器学习是一种独特的实践，需要自己的最佳实践和相匹配的基础设施？
为了回答这个问题，我们将探讨DevOps的基础以及DataOps作为DevOps中的一种自然专长，以满足数据从业人员的需求。之后，我们将研究机器学习的需求，并尝试了解它是否以及如何与DataOps有所不同。
最后但并非最不重要的是，我们将探讨机器学习从业者应该处理多少基础设施的问题。它与其他任何数据从业人员有何不同？与软件工程师相比又处于什么位置？
这个问题与手头的问题相关，因为它驱动了为从业者提供Ops的需求。
什么是DevOps？
**“DevOps是软件开发和IT行业中的一种方法论。作为一套实践和工具，DevOps将软件开发（Dev）和IT运维（Ops）的工作整合和自动化，以改善和缩短系统开发的生命周期。”
DevOps是敏捷软件开发的补充；DevOps的一些方面来自于敏捷工作方法。”
让我们来详细看一下。敏捷方法论是DevOps方法论的一部分；它依赖于产品设计师和用户之间保持短的反馈循环的能力。
为了保持短的反馈循环，必须具备从开发到生产的高效软件交付生命周期。维护这个过程所需的基础设施和工具由DevOps团队负责。
所以，效率是关键。
简而言之，主要组成部分包括：
- 开发环境：一个允许协作和测试新代码或更改代码的开发环境。
- 持续集成：在保持质量的同时，能够持续添加新的/更改的代码到代码库中。
- 分段：为了确保包括新的/更改的功能在内的系统质量，在部署到生产环境之前，在类似于生产环境的环境中设置并运行质量测试。
- 持续部署：能够将新的/更改的功能部署到生产环境中。
- 监控：观察生产的健康状况，并通过回滚快速恢复问题。
- 模块化：能够轻松地向生产环境中添加组件，例如新服务，同时保持生产稳定性和健康监控。
根据组织结构（DevOps/SRE/生产工程）可能会有很多职位头衔，但他们的职责保持不变。
该职能负责为代码从开发到生产提供基础设施。产品工程团队可以参与选择一些更适合自己专业知识的工具，例如开发环境的一些方面。
为了支持这个目标并允许这些敏捷过程，软件工程师接受了各种工具的培训，包括源代码控制（如Git）和自动化工具（如Jenkins、Unit和集成测试平台）。
任何软件工程师都知道，他们在工作中最重要的培训是了解应用程序的生命周期管理并与支持它的工具一起工作。一旦掌握了这些，你的生产力就会大大提高，并且它将成为你日常工作的自然组成部分。
来源：AWS
什么是DataOps？
DataOps是面向数据密集型应用的DevOps。这些应用依赖于数据管道来产生应用的核心数据派生物。
数据密集型应用的示例包括：
- 内部BI系统，
- 依赖大量患者数据集来改进疾病诊断和治疗的数字健康应用，
- 汽车的自动驾驶能力，
- 优化生产线，
- 生成式AI引擎，
- 以及许多其他应用…
DataOps团队的目标与DevOps团队类似，但他们的技术栈包括专业知识，使数据从业者能够实现快速的反馈循环。
这些技术包括分布式存储、分布式计算引擎、分布式摄取系统、编排工具以管理数据流水线，以及数据可观测性工具，以允许对数据密集应用的数据方面进行质量测试和生产监控。
简而言之，这种专业知识将允许：
- 开发环境：一个允许协作和测试新的或更改的数据流水线的开发环境。基础设施将不仅包括功能代码的管理，还包括流水线代码和数据的管理。
- 代码的持续集成：能够持续向代码库中添加新的/更改的代码
- 数据的持续集成：能够持续向数据集中添加新的/更改的数据
- 分阶段测试：在将新的/更改的功能部署到生产环境之前，确保系统的质量。这将包括对代码和数据进行测试。
- 持续部署：能够自动将新的/更改的功能或数据部署到生产环境
- 监控生产的健康状况，并能够快速恢复。这将包括应用程序和其中包含的数据。
- 能够轻松地向生产环境添加组件，例如新的服务/数据工件，同时保持生产的稳定性和健康监控。
MLOps与DataOps的区别
在DevOps和DataOps的背景下，MLOps是针对ML生命周期的DataOps案例。
在这里，我们被要求回答本文的主要问题。MLOps是否真的与DataOps不同？如果是，又有何不同？
由于基于ML的应用程序需要代码、数据和环境版本控制、编排和数据技术的提供，它们在这些领域的需求与其他数据从业者相似，并且完全符合此处定义的DataOps。
数据质量工具和数据监控工具也是如此。虽然在某些测试的部分，这些工具可能是特定于ML的，但这与C++开发人员的工具与JavaScript开发人员的工具之间的差异没有什么不同。
我们不将其定义为与DevOps不同的类别，对吗？
请注意，对此类工具的需求是无可置疑的，数据质量和数据监控类别将取得成功，但它们不会改变DevOps范 paradigm 或将MLOps变为一个实际的产品类别。
这使我们真正的差异所在：开发环境。这个差异在DevOps中是众所周知的，而且是真实存在的。
软件工程领域的每个从业者都对他们的开发环境有自己特定的要求。这些需求是在基本的代码和数据版本控制以及所需的良好配置的笔记本之上的。
例如，ML从业者需要一个良好的实验管理系统，一个优化超参数的好方法，以及一个创建训练集的好方法。
训练集！哦，那确实是一个区别！数据科学家需要基础设施来存储和管理他们用于训练模型的数据的标记。
虽然这些基础设施中的一些是通用的，例如用于保存标记元数据的存储或数据库，但其中一些对标记过程本身和训练集的管理非常特定。
这是否证明了一个新的Ops类别？我不这么认为。这就像说需要图数据库的应用程序需要一个新的Ops类别一样。
为什么我们过度拟合了MLOps？
在讨论数据科学家的基本软件技能的基础设施需求时，会提出这样的问题。比如说“不要期望数据科学家理解Git的概念”，“数据科学家无法创建具有适当日志记录的代码，因为他们不是软件工程师”等等。
我对这种思维方式感到不满，并且我认为这使我们过度拟合了MLOps。
数据科学家是高技能的个体，他们可以迅速掌握版本控制的概念，并掌握与CI/CD自动化服务器一起工作的复杂性。正如我上面提到的，初级软件工程师在工作中学到这一点，我相信数据科学家也应该如此，他们打算为商业公司带来价值。我觉得我们正在创造一类工具来解决数据科学家的培训差距。这项调查支持这种观点。
话虽如此，运维软件工程师应该接触多少内容仍然未定，不同的组织对DevOps在组织内的实施有不同的看法。
共同的理解是，DevOps团队负责提供基础架构，软件工程师应该理解并使用它，并提出需求以确保其持续改进。
当转向数据工程师时，期望保持不变。为什么对于机器学习工程师/数据科学家会改变呢？
结论
拥有大量数据运营的组织（很快所有组织都会如此）应确保其DevOps团队具备数据专业知识，为所有数据从业人员提供高质量和通用的数据基础设施和最佳实践，同时确保所有数据从业人员都接受过良好的教育，知道如何使用这些基础设施来优化管理他们的流程。在企业中，这可能确实需要一个专门的部门。
良好的实践和内部教育可能消除了对过度定制工具的需求，这些工具最终会限制数据从业人员对通用运维工具所提供的非常需要的灵活性的使用。
过度定制工具的优势是，在短期内，对于一个非常简单的系统，它提供了一个一站式解决方案来满足所有需求。
如果我们可以直接购买这个端到端的工具，为什么要与我们的DevOps团队合作呢？但是从长远来看，需求从简化的用例中发展出来，需要专家系统的深度。例如，对于编排，公司将不再使用提供简化编排等功能的端到端工具，而是转向强大的编排系统，如Airflow、Prefect或Dagster。
