发帖
雷达卡
在特征存储作为机器学习的基础中，我们讨论了特征存储如何成为机器学习工作流程的一个组成部分。它们通过简化特征定义和提取来提高数据工程的投资回报率、降低每个模型的成本并加速模型上市。
虽然特征存储很重要，但它们只处理一种特定于 ML 工作流程的数据。还有更多类型的 ML 特定数据，作为 ML 工程师，您应该有一种方便的方法来发现、验证和监控所有这些数据。
就像特征库充当有利于机器学习的特征仓库一样，数据目录可以帮助您访问数据和 ML 工程师处理代码和数据方面所需的所有类型的数据实体（包括特征库） ML 模型。
特征存储充当 ML 工程师可以发现以在其 ML 工作流程中使用的特定于 ML 的数据源
本文概述了一种数据目录类型，它可以结合 DE 和 DS 团队的努力，促进以数据为中心的 MLOps，改进 ML 模型的 TTM 并消除组织扩展 ML/AI 工作的障碍 - 并解释为什么所有这对 ML 工程师很重要。
为什么 ML 工程师需要专为机器学习设计的数据目录
即使不考虑 ML 工程师的工作流程，充分利用数据也可能具有挑战性，主要是由于以下趋势：
数据格式的数量和复杂性正在飙升
数据管道变得过于复杂，无法使用现有工具进行有效处理
数据发现的现代需求比解决它们的解决方案发展得更快
ML 模型生命周期也带来了额外的挑战：
机器学习管道越来越复杂
机器学习和数据实体的孤立发现阻止了机器学习操作的扩展
用于发现和观察 ML 实体以及数据的工具尚未发展
当今存在的数据目录和可观察性工具尚未与 ML 实体集成——至少在架构级别上没有。虽然考虑了机器学习因素，但很明显：
数据发现工具不包括与 ML 相关的数据实体
沿袭和可观察性工具中不存在 ML 实体
当 ML 管道中的数据出错时，利益相关者对此一无所知
数据和机器学习工程师不知道管道的另一部分正在发生什么，这阻碍了他们的协作和协同作用
DE 和 ML 团队之间的协作差距导致难以检测的黑盒问题，这通常会导致利润损失和声誉受损
自机器学习出现以来，与机器学习相关的实体（如机器学习管道、机器学习模型、特征存储等）已成为数据领域不可或缺的一部分。尽管如此，以及数据作为定义 ML 产品质量的关键组成部分的作用，它们在现有的数据发现和可观察性解决方案中仍然不存在。
直到最近，数据目录和可观察性平台还没有设计为将 ML 实体作为第一公民。整体画面是这样的：
当前的数据发现/可观察性生态系统中不存在 ML 世界。
在我们最新的题为“数据发现和可观察性平台缺失的部分：元数据的开放标准”的文章中，我们仔细研究了数据目录和可观察性平台的状态。我们还解释了为什么他们在努力跟上数据和机器学习领域专业人士快速发展的需求。
孤立数据和机器学习发现的后果
在机器学习项目开始时，了解业务用例后的第一步是数据发现——搜索、理解和评估数据以满足您的目标的过程。由于机器学习驱动的产品质量与数据质量密切相关，因此找到可以信任的数据与您的模型一起使用非常重要。
数据目录是一种旨在帮助发现步骤的工具类别。但问题是，现有的数据目录都没有在设计时考虑到 ML 工程师的需求和 ML 模型生命周期。虽然它们提供数据搜索和评估功能，但您不能使用它们从您发现其他类型数据的平台上发现所有与 ML 相关的实体。
特定于 ML 的数据流包括许多属于 ML 生命周期的实体：ML 管道、模型实验、模型指标、模型工件、ML 生产服务等。
机器学习工程师的数据发现
数据发现与 ML 工作流程的其他步骤之间的不自然差距导致管理 ML 相关数据操作的效率低下。
为了构建能够产生最大业务价值的 ML 模型，了解数据的来源、演变方式及其具体特征的全貌至关重要。
无法发现的机器学习实体可能会破坏和减慢在 ML 环境中处理数据的整个过程。无法管理无法发现和评估的内容是不可能的。因此，数据驱动的组织发现将 ML 扩展到其全部潜力变得越来越具有挑战性。在数据发现工作流程中忽视机器学习也剥夺了公司扩展其机器学习和人工智能业务的关键机会。
DE 和 ML 团队各自为战的后果
数据发现工具中没有 ML 实体也意味着数据管道的数据和 ML 工程部分是孤立的，使每个团队对另一边发生的事情一无所知。这种缺乏可观察性可能会导致不可预测且难以检测的黑盒问题。
由于缺乏跨部门协作而导致的黑盒故障的一个典型例子是未检测到的数据延迟。假设您有一个网站推荐模型的数据和 ML 管道，由两个部门/团队负责：数据工程和数据科学。DE 团队使用 Airflow 到 ETL 并将数据发布到特征存储，DS 团队支持使用来自特征存储的数据的 Kubeflow 训练管道。
如果没有适当的可观察性，几乎不可能注意到算法的偶尔变化。
例如，如果 DE 团队部署了新版本的 Airflow ETL 管道，计划在每天凌晨 12:00 运行，而 ML 训练管道在每天凌晨 1:00 运行，则很难注意到 Airflow 管道执行时间从 1 小时增加到 1.5 小时，现在在 ML 管道开始后终止，落后了。
该模型最终会不断地在前一天的过时数据上运行，而不考虑全天收集的新数据。
可以收集和发现哪些与机器学习相关的数据？
数据已经变得极其复杂，而用于跟踪 ML 相关实体的现代工具（与数据目录跟踪其他类型数据的方式相同）尚未发展。这样的目录可以帮助计划和运行 ML 培训、实验和测试，缩短模型到生产的时间，并促进更清洁的模型开发。
这些目录可能涉及复杂的实体和关系，这就是控制并能够自动跟踪这些实体很重要的原因。
作为 ML 工程师，您可以使用现有数据目录来发现适当的训练数据。但是其他应该与您的工作流程不可分割的工件呢？
简化的 ML 模型生命周期如下所示：
了解业务案例
数据发现（为模型训练找到正确的数据）
运行实验
训练模型
为模型推理找到正确的数据
模型推理（在新数据上运行 ML 模型以获取预测）
机器学习实验。在处理 ML 模型时，您必须进行大量实验——测试假设的程序（关于您的模型的问题，例如哪个模型表现更好）。您运行实验以了解模型的不同部分在不同情况下如何组合在一起。例如，您可能想要：
使用不同的模型和模型超参数
使用不同的训练或评估数据
运行不同的代码（包括您想快速测试的小代码更改）
在不同的环境中运行相同的代码
ML 模型是从数据生成预测的机器学习算法。作为 ML 工程师，您肯定希望不同版本的 ML 模型工件能够通过数据发现解决方案进行搜索和发现。
ML 模型指标。ML 工程师使用模型评估指标（如准确度、精确度、召回率、特异性、对数损失和其他分数）来评估其模型的性能。它们对于任何数据科学项目都至关重要，并且可以作为帮助理解下一步方向的指路明灯。
用于 ML 模型推理的数据。推理是在新数据上使用经过训练的算法来驱动预测的过程。就像训练和测试数据一样，您还需要发现推理阶段的数据，并确保它符合您的要求。
特色商店。特征存储是一个数据仓库，它在转换、聚合和验证后从不同来源提取特征数据。然后，来自特征存储的数据可用于模型训练和推理阶段。
集成的 ML 工作流程、数据发现和可观察性如何使数据团队受益
ML 工程师的典型工作流程包括以下步骤：搜索组织中存在的数据，根据项目评估数据并定义其质量，获得对数据的适当访问，使用它来运行实验，选择最佳假设，对 Kubeflow 中的数据运行 ML 模型训练，将模型注册到模型注册表，并将其连接到特征存储以确保正确推理。
当 ML 工程师开始一个项目时，在每个步骤中操作高质量、可靠的数据非常重要。即使模型已准备好并已部署，它也完全取决于底层数据。如果数据中断，模型也会中断。乍一看似乎无害的更改，例如分布的轻微变化或较小的数据延迟，有可能迅速滚雪球成重大问题。
面向 ML 和数据工程师的开放数据发现平台
在考虑上述问题时，我们开发了一个考虑到 ML 和数据工程师的解决方案。ODD Platform 是第一个开源数据发现和可观察性平台。它填补了数据发现的缺失部分，使 ML 工程师能够轻松找到属于其 ML 工作流程一部分的所有实体。它还可以帮助数据工程师发现数据工程所需的一切。
机器学习工程师的数据发现
ODD 自动从所有连接的数据源（包括特定于 ML 的数据源）收集元数据，并将它们注册到沿袭。每个数据产品的沿袭部分显示其所有上游和下游连接。如果 ML 工程师用于其 ML 模型的数据发生变化，沿袭和丰富的警报将帮助他们在几分钟内主动找到问题的根本原因，而不是几小时或几天。受影响数据产品的所有所有者将立即收到更改通知。
ODD 平台基于开放数据发现规范——一种开源的、行业范围的元数据标准，旨在为如何以自动化方式收集、处理和管理元数据建立规则。
与现有的数据目录和其他数据可观察性工具不同，ODD 不需要任何付费或复杂的基础设施。部署过程非常简单。唯一困难的要求是拥有 PostgreSQL。ODD 作为微服务集群运行，您可以轻松地在设置中添加或删除数据源。
ODD 在 Apache 2 许可下获得许可。该团队致力于永远保持开源，并在没有任何隐藏议程的情况下公开构建产品。
结论
数据质量对于构建可持续且可靠的机器学习模型至关重要。为了随时掌握相关、可靠和随时可用的数据，ML 工程师需要一个数据发现和可观察性系统，该系统将 ML 实体作为一等公民来运营，以提供公司范围内的数据发现、质量保证和透明度。
这样的工具将消除数据工程师和数据科学家之间目前存在的障碍，并促进协作。这将结束这些角色的人们目前所经历的脱节，并使他们充分了解其他人在数据管道中的部分。
| 相关帖子DA内容精选 |
京公网安备 11010802022788号
