2.1.1 为什么深度学习系统需要数据集管理

在我们开始查看示例数据集管理服务之前,先让我们花点时间解释一下为什么数据集管理(DM)是深度学习系统中至关重要的一部分。这一节很重要,因为根据我们的经验,如果你没有充分理解原因,就很难设计出能够解决实际问题的系统。

对于为什么需要数据集管理,有两个答案。首先,通过将训练数据的收集与使用解耦,数据集管理可以加速模型开发。其次,设计良好的数据集管理服务可以通过在训练数据集上进行版本跟踪来支持模型的可复现性。让我们详细看看这两点。

1.解耦训练数据收集与使用

如果你是完全独自进行深度学习项目开发,项目开发工作流是以下步骤的迭代循环:数据收集,数据集预处理,训练和评估(见图2.2)。尽管在数据收集组件中更改数据格式可能会破坏下游的数据集预处理代码或训练代码,但这不是一个大问题。因为你是唯一的代码所有者,所以你可以自由进行更改不会影响其他人。

但是,当我们构建一个服务于数十个不同的深度学习项目的严肃的深度学习平台,并向多个人和团队开放时,简单的数据流程图会迅速扩张成复杂的三维图(见图2.3)。

图2.2 单个人深度学习项目开发的工作流是一个线性步骤的迭代循环

图2.3 企业中的深度学习模型开发在多维度上进行。多个团队的人员共同合作,按照不同的阶段推进项目。每个团队专注于工作流的一个步骤,并且同时处理多个项目

图2.3展示了企业中深度学习开发环境的复杂性。在这种情况下,每个人只负责一个步骤,而不是整个工作流。此外他们还在多个项目中从事开发工作。理想情况下,这个过程是高效的,因为人们往往通过专注于一个特定问题来建立自己的专业知识。但是存在一个问题:我们通常会忽略沟通成本。

当我们将工作流的各个步骤(见图2.2)分配给多个团队时,需要为握手协议使用数据模式。如果没有数据合同,下游团队就不知道如何读取上游团队发送的数据。让我们回到图2.3。可以想象一下,如果由4个团队并行开发10个项目,其中每个团队负责工作流的不同步骤,那么我们将需要多少数据模式来在团队之间进行沟通。

现在,如果我们想要向训练数据集中添加一个新的特征或属性(比如文本语言),我们就需要召集每个团队,就新的数据格式达成共识,并实施这些变化。这是一项艰巨的工作,因为企业中跨团队的合作是复杂的。通常需要花上几个月的时间来实现一个小改变,因为每个团队都有自己的优先事项,在他们处理其他优先事项之前,你必须排队等待。

更糟糕的是,深度学习模型的开发是一个迭代的过程。要提高模型的精度,就需要不断调整训练数据集(包括上游数据流程)。这需要数据科学家、数据开发人员和平台开发人员高频率地进行交互,但由于跨团队的工作流设置,数据的迭代速度往往较慢。这也是生产环境中模型开发如此缓慢的原因之一。

另一个问题是,当我们同时开发多种类型的项目(图像、视频和文本)时,数据模式的数量会爆炸。如果我们让每个团队自由定义新的数据模式,又没有妥善管理它们,那么保持系统向后兼容几乎是不可能的。由于我们必须额外花费时间来确保新的数据更新不会破坏过去构建的项目,新数据的更新会变得越来越困难,项目开发速度也将显著减慢。

为了解决缓慢的迭代和数据模式管理问题,我们可以构建一个数据集管理服务。让我们来看看图2.4,以便确定如何在引入数据集管理服务后调整项目开发工作流。

在图2.4中,我们可以看到数据集管理服务将模型开发工作流分为两个独立的空间:数据开发人员空间和数据科学家空间。

图2.4 数据集管理组件通过为训练数据收集和使用定义强类型模式,有效地将二者分离,从而使数据开发和模型算法开发能够在各自的循环中迭代,从而加快项目的开发进度

长迭代循环(图2.2)被分割为两个较小的循环图(图2.4),每个循环由一个团队负责,因此数据开发人员和数据科学家可以分别对数据收集和模型训练进行迭代,从而使深度学习项目的迭代速度大大加快。

你可能还注意到,现在我们将所有的数据模式放在了一个地方:数据集管理服务。该服务管理各种类型的数据集的两种强类型数据模式——摄取数据模式和训练数据模式。通过在DM内部进行数据转换时为数据摄取和训练分别提供两个独立的数据模式,你可以确保上游数据收集中的数据变化不会破坏下游的模型训练。由于数据模式是强类型的,未来的数据升级可以轻松地保持向后兼容性。

在项目初期或试验阶段,定义一个强类型的数据集可能不是一个好主意,因为我们仍在探索各种数据选项。因此,我们还建议定义一种特殊的无模式(schema-free)数据集类型,例如GENERIC类型——它没有强类型模式限制。对于这种数据集类型的数据,DM会直接接受数据,并且不执行数据验证和转换(详细示例见2.2.6节)。从数据处理流程中收集的数据可以直接被训练过程使用。尽管整个工作流可能较为脆弱,但自由数据集类型满足了项目初期对灵活性的要求。一旦项目成熟,我们就可以创建强类型的模式,并为其定义数据集类型。

总结本节,管理数据集类型的两个数据模式是将数据科学家和数据开发人员解耦的关键因素。在2.2.6节中,我们将展示这些模式是如何在我们的示例数据集管理服务中实现的。

2.实现模型可复现性

一个良好设计的数据集管理服务通过在训练数据集上进行版本跟踪来支持模型的可复现性——例如,使用版本字符串来获取之前模型训练运行中使用的确切训练文件。对于数据科学家(模型算法开发)而言,模型可复现性的优势在于,你可以反复在某个数据集上运行深度学习算法(例如,NLP中的自注意力transformer),并获得相同或类似的结果质量。这称为算法可复现性

从深度学习系统开发者的角度来看,模型可复现性是算法可复现性的超集。它要求数据集管理系统能够复现其输出产物(数据集)。例如,我们需要获取确切的训练数据和训练配置,以复现过去训练的模型。

模型可复现性对于机器学习项目来说至关重要,原因主要有两点。第一是信任。可复现性为生成模型的系统创造了信任和可信度。对于任何系统,如果其输出无法复现,人们将不再信任该系统。这对于机器学习项目非常重要,因为应用程序将根据模型输出做出决策——例如,一个聊天机器人会根据用户意图预测将用户的呼叫转接到相应的服务部门。如果我们无法复现一个模型,基于该模型构建的应用程序将变得不确定和不可信。

第二个原因是模型可复现性有助于性能故障排查。当检测到模型性能出现回归时,人们首先想要知道在训练数据集和训练算法代码中发生了什么变化。如果不支持模型可复现性,性能故障排查将变得非常困难。