优步在过去几年里经历了指数级增长，现在每天支持1400万次出行，我们的工程师证明了他们可以进行规模化建设。这种价值延伸到其他领域，包括超级ATG(Advanced Technologies Group)及其开发自动驾驶汽车的探索。
这项工作的一个重要部分涉及创建机器学习(ML)模型，以处理诸如处理传感器输入、识别对象和预测这些对象可能去哪里等任务。解决这个问题所需的许多模型，以及从事这些工作的大量工程师团队，本身就产生了管理和版本控制问题。
我们最初通过为自动驾驶车辆中的ML模型的训练和部署定义一个五步生命周期来解决这个问题。这个生命周期从数据摄取开始，一直到模型服务，并沿着这个过程的步骤确保我们的模型执行良好。这个过程让我们有效地加速了自动驾驶汽车组件的迭代，不断地改进它们，以达到最高标准。
通过自动化这个过程，我们可以进一步受益，以帮助管理开发中的许多模型。由于ML模型在自动驾驶领域的高度依赖性和开发复杂性，我们开发了VerCD，一套工具和微服务来支持我们的ML工作流程。VerCD允许我们使用自动化持续交付(CD)来跟踪和管理ML工件的版本依赖性。
ML团队正在大规模开发模型你可能会发现，我们在优步ATG为自动驾驶汽车开发的五步模型生命周期和VerCD的实践和工具，可以应用于许多用例，帮助他们在自己的基础设施上迭代。
无人驾驶汽车组件
我们的许多自动驾驶汽车组件使用ML模型，使它们能够安全、准确地驾驶。一个组件由一个或多个ML模型组成，所有组件一起组成了我们的自动驾驶汽车软件：
- 知觉:该组件使用来自车辆的传感器信息，通过ML模型检测给定场景中的角色。它识别每个对象类型(车辆、行人、自行车等)及其3D坐标的概率。探测功能使自动驾驶汽车能够看到环境中不同的物体，解释它们是什么以及在哪里。
- 预测:该组件使用Perception组件输出(场景中所有参与者的类型和3D坐标)以及高清地图来预测参与者的未来轨迹n在给定场景中使用ML模型。预测组件允许自动驾驶车辆预测角色在未来的不同时刻最有可能位于何处。
- 运动规划:该组件使用自动驾驶车辆的目的地、场景中所有参与者的预测轨迹、高清地图和其他机制来规划车辆的路径。
- 控制:该组件控制自动驾驶汽车的车轮，操作刹车和加速器，以遵循运动规划组件创建的路径。
每个组件都建立在前一个组件生成的输出基础上，以帮助我们的自动驾驶汽车在正确的路线上安全驶向目的地。包含这些组件的ML模型通过我们的五步迭代过程，确保它们的最佳操作。
我们的机器学习模型生命周期
ML模型基于使用历史数据的训练进行预测、预测和估计。在Uber ATG的自动驾驶汽车开发中，我们使用从装有传感器的车辆(包括激光雷达、摄像头和雷达)收集的数据作为我们的训练数据，这些数据来自各种各样的交通状况。我们将这些数据从车辆卸载到我们的服务器，在那里我们的标签团队创建标签，形成我们希望ML模型学习的地面真相输出。
通常，标签团队会手动为给定场景中的角色分配标签。这些标签为场景中的每个参与者提供位置、形状和其他属性，例如对象类型。我们使用这些标签来训练ML应用程序，以便它们以后能够预测标签包含的信息(对象类型及其坐标)，以获取从传感器捕获的新数据。
一旦我们收集了足够的数据，我们处理这些信息，通过使用包含所有对象类型和坐标以及高清映射的地面真相标签来开发ML模型。我们在ML堆栈中开发和运行ML模型，它由多个层组成，从位于最高层的ML应用程序本身到位于最低层的它们所运行的硬件。中间层包括常见的ML库，例如TensorFlow而且PyTorch，以及GPU加速。
我们的ML模型生命周期，如下面的图1所示，由五个阶段组成。
我们将ML模型放在生命周期的每个阶段，以确保它们在部署到自动驾驶汽车之前展示高质量的模型、系统和硬件指标。
数据摄取
一旦我们收集了用于ML模型训练的数据，它就会被我们的ML堆栈吸收。数据摄取过程包括选择计划使用的日志并从中提取数据。
我们将这些日志数据分为训练数据、测试数据和验证数据;75%的日志用于培训，15%用于测试，10%用于验证。我们使用这些比例，以便用大部分数据训练ML模型，提高模型的准确性，然后在训练过程中进行验证。最后，我们在训练期间没有看到的一小部分数据上测试模型效率。在以后的文章中，我们将介绍GeoSplit，这是一个数据管道，它可以选择日志，并根据它们的地理位置将它们划分为训练、测试和验证。
一旦我们划分了数据，我们就从数据生成日志中提取数据Petastorm， Uber ATG的开源数据访问库用于深度学习。我们从日志中提取的数据包括:
- 车辆摄像头拍摄的图像
- 激光雷达3D点信息
- 雷达信息
- 车辆的状态，包括位置，速度，加速和航向
- 地图信息，例如车辆的路线和车道
- 地面实况标签
我们将这些信息逐个日志地保存在HDFS上。然后，我们使用Apache Spark从多个日志中并行提取数据。以这种方式提取数据将以优化的格式保存数据，以便我们的培训管道可以轻松快速地使用。当我们运行培训管道时，我们不希望等待长时间、繁重的API调用来查找某些信息。在这个系统中，我们从HDFS加载模型后，所有我们需要的信息(提取的数据)都存储在训练模型的gpu的内存中，确保管道可以有效地读取训练数据。
下面的图2显示了在CPU集群上运行的提取过程的示例，并将提取的数据保存到HDFS:
数据验证
在数据管道选择和提取我们将用于训练、测试和验证的数据之后，我们运行查询来获取场景中的帧数和数据集中不同标签类型的出现次数。我们将这些查询的结果与以前的数据集进行比较，以了解条件是如何变化的，以及它们是否符合预期。例如，如果一种标签类型出现的次数比其他标签类型急剧增加，那么我们将触发进一步的分析，以理解这种更改以及它将对模型产生什么影响。
模型训练
一旦我们正确地选择、提取并验证了我们的数据，我们就有了训练模型所需的资源。我们利用Horovod的分布式训练，利用提取的数据快速训练它们。我们将数据以数据并行的方式分布在不同的gpu上，如图3所示，这意味着我们在不同的gpu上用不同的数据部分训练相同的模型。例如，如果我们使用两个GPU，那么数据被分成两个，同一个模型在第一个GPU上训练第一部分数据，在第二个GPU上训练第二部分数据。
每个进程独立于其他进程执行正向和向后传递(正向传递指的是计算来自网络所有层的输入的输出以及来自损失函数的损失，而向后传递指的是计算损失相对于网络中每个节点的变化速率)。
接下来，我们使用Horovod的ring-allreduce算法，使工作节点能够平均梯度并将它们分散到所有节点，而不需要参数服务器，将每个进程学到的信息分配给所有其他进程。
利用TensorFlow和PyTorch作为ML框架，工程师可以通过该框架监控培训作业TensorBoard验证培训是否按预期进行。
Uber ATG对ML计算资源采用混合方法，培训作业在GPU和CPU集群供电的本地数据中心运行，同时在云端运行培训作业。
为了利用配备gpu的内部数据中心编排培训工作，我们使用Peloton，一个由Uber开发的开源统一资源调度程序。通过将容器部署到集群上的进程，Peloton可以轻松地将作业扩展到多个gpu或cpu上。对于基于云的培训，我们使用Kubernetes，它跨主机集群部署和扩展应用程序容器。
一旦我们用所选择的、提取的和验证的数据训练了ML模型，我们就可以评估它们完成任务的效果，无论是识别场景中的对象还是预测演员的路径。
模型评价
在我们训练了一个给定的模型之后，我们评估模型本身的性能以及整个系统的性能。我们使用特定于模型的度量和系统度量来测试我们的ML模型。我们还评估硬件指标，以了解我们的模型在最终部署它们的硬件上的运行速度。
模型相关的指标
我们在给定的测试集中计算各种特定于模型的度量．例如，对于Perception组件中的对象检测模型，我们计算模型指标，如精度(被证明是正确的检测的百分比)和召回率(模型正确识别的基本事实对象的比例)。
回顾指标为我们提供了关于模型如何执行的重要见解，以便我们能够不断地增强它们。当我们确定模型表现不佳的场景时，我们通过以下方法调整数据管道包括类似案件，使模型可以处理更多的数据。在这些实例中，我们有时会给予那些场景更多的权重，这意味着这些数据实例将对训练模型做出更多的贡献，而不是其他场景，以努力优化相关的模型。
当我们用更多的场景训练我们的模型时，它最终会在这些场景上表现得更好。然而，我们还希望确保我们的模型性能不会在它表现良好的现有场景中倒退。
系统指标
系统指标包括对整个车辆运动的安全性和舒适性的测量，在一个大型测试集上执行。一旦给定模型的特定于模型的度量显示出良好的结果，我们就在模型开发的后期阶段评估系统度量。鉴于自动驾驶堆栈中的不同ML模型相互依赖(例如，我们的预测组件使用我们的感知组件的输出)，系统指标为我们提供了一个重要的、全面的概述，可以了解系统的所有部分在组件版本之间的执行情况。度量系统指标可以帮助我们的团队更全面地了解新模型可能如何影响系统中的其他组件。定期评估系统指标允许我们发现并修复由于ML模型更新而发生在其他组件中的问题。
硬件指标
Uber ATG有一个内部基准测试系统，允许开发人员分析我们软件的某个部分，比如对特定模型的推断，并评估它在我们的自动驾驶汽车硬件上的运行速度。我们使用来自自动驾驶汽车的真实数据进行评估，确保在部署模型之前了解它们的性能。
模型服务
一旦我们训练好了一个模型，验证它可以独立工作，并确认它与系统的其他部分运行良好，我们就会将它部署到自动驾驶汽车的推理引擎上。该系统通过经过训练的模型运行输入，以便产生输出。例如，运行Perception组件将提供场景对象类型及其坐标，而Prediction组件将提供对象未来的轨迹。
在我们为他们服务之后，我们继续迭代所有的模型，使用我们的五步过程使它们更好，关注模型需要改进的地方，这通常是我们在模型评估步骤中发现的。
通过持续集成和交付加速ML研究雷竞技是骗人的
尽管我们将过程归结为五个步骤，从数据集摄取到模型服务，但每个步骤本身涉及各种不同的系统，整个端到端工作流很容易跨越数周。当人工驱动时，有很多人为错误的机会，所以我们投资了更好的工具和平台，以尽可能地自动化工作流。
VerCD就是这样一个平台，它在整个工作流中跟踪代码、数据集和模型之间的依赖关系，并编排这些ML工件的创建，使其成为我们流程的关键部分。具体来说，VerCD所涵盖的工作流从数据集提取阶段开始，覆盖模型训练，并以计算度量结束。
由于在自动驾驶领域中ML模型的深度依赖和开发复杂性，我们需要一个持续交付(CD)系统，该系统利用敏捷原则专门跟踪和管理ML工件的版本依赖。虽然开源工具如Kubeflow而且TensorFlow扩展提供构建数据集和训练模型的高级编排，它们需要大量的集成。此外，它们停留在交付单一工作流上，并没有完全启用持续交付(CD)和持续集成(CI)。
另一方面，有一些传统的软件工具，例如Git而且詹金斯，支持版本控制和CI/CD。尽管这些工具并不在我们的自动驾驶软件中的ML工件上运行，但我们将它们作为构建VerCD的灵感。
敏捷原则的机会毫升workflows
大多数软件开发人员使用版本控制、依赖项跟踪、持续集成和持续交付来生成频繁的软件版本敏捷开发流程．由于这些概念在标准软件开发中是众所周知的，在这里我们将只关注它们在ML工作流空间中的应用。
应用于ML领域的版本控制原则允许分析对ML工作流某些部分的更改对下游依赖关系的影响。例如，如果跟踪代码和ML工件版本，更新特定数据集或模型，或生成那些工件的支持软件的ML工程师可以更好地理解这些更改的影响。在这里，版本控制允许我们独立于另一个开发人员的更改跟踪一个开发人员更改的影响，即使他们是并行工作的。
ML领域的依赖性跟踪的一个例子是，对标签和原始数据的调整可能会改变数据集的性质，这反过来又会影响训练结果。此外，数据提取或模型训练代码和配置中的更改会影响他们负责构建的工件。因此，首先在旧数据集上训练一个模型，然后再提取一个新数据集是没有意义的，因为数据将与训练过的模型不一致。在这种情况下，应该先提取数据集，然后再构建模型，依赖约束捕获顺序。
虽然有许多成熟的工具可以实现对传统软件代码库的持续交付，但我们发现，同样类型的机器学习工具目前还没有达到这种成熟度和标准化水平。与CD工作流相比，ML工作流涉及代码、数据和模型，而传统的软件工程工具只处理其中的第一个。下面的图4说明了CD工作流中的一些差异，图5说明了构建最终ML工件所需的系统的范围和复杂性:
通过实现敏捷过程，CD使工程师能够快速适应不断变化的需求，尽早且经常地捕捉bug，并促进所有ML部件的并行开发，从而提高开发人员的生产力。然而，频繁的更改和在ml密集型组织中常见的并行模型开发需要解决版本控制问题，由于自动驾驶软件堆栈中的深度依赖图，这个问题在自动驾驶领域中更加困难，如上所述。这样的依赖关系图不仅包括单个ML模型的代码、数据和模型，还包括各种ML模型之间的依赖关系。
自动驾驶领域的深度依赖图
在自动驾驶汽车的开发中，依赖图尤其深入。这种深度是自动驾驶软件堆栈分层体系结构的结果，其中每一层提供不同的ML函数。为了演示这一点，我们在图6中展示了一个由三个ML模型按顺序连接起来的高级体系结构:
在上面的图6中，我们的ML层包括:
- 一个以传感器原始数据为输入的物体检测模型，
- 路径预测模型，其输入为对象检测模型检测到的对象集合，
- 规划模型的输入是路径预测模型的输出。
对于这些模型中的每一个，都有一个包含代码和工件的复杂依赖关系图，如图6左边的图表所示。所示的层本身有几层深，并涉及生成三个工件:
- 一个数据集，由原始源数据、源图像数据中不同对象(即标签)周围的边界框和数据集生成代码组成。
- 一个训练过的模型，它需要数据集工件、模型训练代码和管理模型训练的配置文件作为输入。
- 一个指标报告，它需要作为输入的训练模型工件、数据集和指标生成代码。
路径预测和规划模型的依赖图与目标检测模型的依赖图一样复杂;在某些情况下，当我们观察整个系统时，完全展开的图至少有15层深。图的深度给CD带来了特别的挑战，因为这些ML组件的并行开发大大增加了CD系统必须管理的版本数量。
为Uber ATG构建VerCD
我们开发了VerCD，一套工具和微服务，为Uber ATG的自动驾驶汽车软件提供版本控制和所有ML代码和工件的持续交付。构成VerCD的许多组件是广泛可用的，因此我们的大量工程工作都花在了添加特定于公司的集成上，以使现有的编排器能够在整个端到端ML工作流中与异构系统集进行交互。
与传统的版本控制和持续交付系统不同，VerCD跟踪每个ML组件的所有依赖关系，除了代码之外，它通常还包括数据和模型构件。VerCD提供的这个元数据服务跟踪依赖关系图，并被持续集成协调器用于定期运行整个ML工作流管道，以生成数据集、训练过的模型和度量。对于那些经常需要将新的实验与历史基线进行比较，或者检查历史构建以跟踪bug的工程师来说，VerCD确保了ML工件总是可复制和可跟踪的。
VerCD的系统架构
在设计VerCD时，我们结合了实验和生产工作流程。我们不仅需要系统支持由编配器驱动的持续集成和持续交付(CI/CD)工作流，我们还希望VerCD拥有在实验期间代表工程师构建数据集、训练模型和运行度量的功能。这些多方面的需求意味着VerCD接口需要对人和机器都可访问。为了获得可重用的接口，我们选择了一个带有Python库绑定的REST API，如下面的图7和图8所示。
出于同样的原因，VerCD被设计为一组独立的微服务，用于数据集构建、模型训练和度量计算。我们选择利用基于微服务的架构，这在优步很受欢迎，其中每个微服务负责一个特定的功能，允许系统扩展并在服务之间提供隔离。然而VerCD CI/CD工作流是线性和固定的，实验工作流需要更大的灵活性，经常涉及自定义工作流和临时运行，可能只关注数据集提取、模型训练或度量评估的子集。拥有一组独立的微服务可以提供在这两个不同的工作流中利用相同功能所需的灵活性。
为了解决依赖性跟踪问题，用户提供任何数据集、模型或在VerCD上注册的度量构建的显式依赖性，然后系统在数据库后端管理这些信息。如下图9所示，我们使用一个常用的Jenkins协调器启动常规构建，并通过提供连接器和集成代码来增强协调器的功能，以便它能够解释依赖元数据并操作atg特定的系统。
例如，我们的协调器可以调用这些原语来构建用于测试的自动驾驶车辆的运行时，与我们的代码存储库交互，或使用深度学习或Apache Spark库创建图像。其他原语包括在数据中心之间复制数据集，以及在云之间复制数据集，如果模型训练在这些位置进行的话。
事件序列示例:注册一个新数据集
在用户注册新数据集之后，VerCD数据集服务将依赖项元数据存储在我们的数据库中。对于数据集、模型和度量，依赖项将包括存储库的Git散列和到代码入口点的路径。根据构建的工件的不同，还会有对其他版本化元素的引用(例如，标签和源数据的版本化集合，或者另一个版本化数据集或模型)。我们期望所有的依赖都是版本化的和不可变的;例如，在数据集的情况下，依赖项将是来自版本化源的传感器数据的时间序列。
作为注册的最后一步，元数据服务使用协调器服务启动构建。这将启动一个Apache Spark作业来运行代码、监视作业(如果需要则重新启动)，最后将数据集复制到托管存储位置(例如内部数据中心或云)。然后，用我们将数据复制到的不同位置更新元数据服务。
Microservice api
我们的每个微服务的api都是为促进我们的生产和实验工作流的编程访问而设计的。由于我们系统的目标是确保数据集构建、模型训练和度量运行的可再现性和可跟踪性，我们要求在注册期间指定这三个工作流的所有版本化的不可变依赖项。api通过提供对构建信息的访问来确保可追溯性，例如工件在哪里生成以及构建生命周期。当试图调试ML工件或性能回归时，这些信息尤其重要。
数据集服务API
数据集服务负责跟踪构建给定数据集的依赖关系。REST API支持创建新的数据集、读取数据集的元数据、更新数据集的元数据、删除数据集和获取数据集的工件位置(例如在S3或HDFS中)的功能。当用户注册一个新的数据集时，后端协调器立即开始构建和验证数据集。
数据集是由名称和版本号唯一标识的，VerCD跟踪的依赖项，允许我们每次重新生成完全相同的数据集工件:
- 自动驾驶车辆的传感器记录了每一次训练、测试和验证的id
- 用于从原始传感器数据中提取数据集的代码的Git散列
- 提取脚本的入口点
- 描述数据集生命周期以及特定版本是否最新的元数据
可以用数据集的当前生命周期状态对其进行注释，例如何时注册数据集、何时构建失败或中止、何时构建成功且已知是好的、何时数据集已弃用，以及最后何时数据集处于生命周期的末尾。
模型服务API
模型训练服务负责跟踪训练给定模型的依赖关系。REST API支持训练新模型、为它读取元数据、更新已注册模型的元数据以及促进生产的功能。当用户注册一个新模型时，后端协调器立即对其进行训练。
模型是由名称和版本唯一标识的，VerCD跟踪的依赖项，它允许我们重现相同的训练运行:
- 版本化数据集，如前一节所述
- 获取用于训练的代码的散列
- 培训脚本的入口点
- 培训配置文件路径
- 最终训练工件的路径
- 描述数据集生命周期以及特定版本是否最新的元数据
实验、验证和生产工作流
几乎所有新的ML模型都是从实验开始的，因此VerCD支持验证步骤，以允许实验模型和生产模型之间的平稳过渡。这个验证步骤对模型训练施加了额外的约束，以确保再现性和可追溯性，这两者都是生产设置所必需的，然而这样的约束可能会在实验期间阻碍快速开发。
如图10所示，一旦ML工程师在VerCD的模型服务API中定义了实验模型，我们的系统就开始训练它。
根据它的执行情况，我们将模型指定为失败、中止或成功。如果模型失败或必须中止，ML工程师可以选择使用一组新的参数重新构建。
VerCD可以异步启动模型的验证。如图10所示，我们的实验和验证过程包括相同的基本步骤，除了实验图运行我们的模型训练代码，而验证图运行我们的模型验证代码。我们的验证代码在模型训练管道上执行各种健全检查，例如验证构建成功、输出工件是否存在，以及依赖是否不可变和版本化。这种检查将取决于正在训练的特定模型。
只有当实验构建和验证都成功，并且两者都可以在任何时间点以任何顺序调用时，模型才可以被提升到生产环境。在模型推广过程中，用户提供名称空间、名称、主要版本和次要版本。端点然后对训练工件进行快照，并将它们与模型训练元数据一起进行版本化，以供将来参考。而在实验阶段，代码和模型的性能往往波动较大。到开发人员准备推广的时候，实验将在很大程度上产生积极的结果，系统将被允许将结果存档。
度量服务API
ML工作流的VerCD覆盖的最后一步是对训练过的模型进行度量评估。与我们的其他微服务一样，为了确保度量的可跟踪性和可再现性，体系结构的度量服务有一个元数据服务，它跟踪运行度量作业及其结果工件所需的必要依赖关系。类似于数据集和模型的情况，我们跟踪:
- 如前一节所述的版本化模型
- 用于运行度量作业的代码的Git散列
- 指标运行代码的入口点
- 配置文件路径
- 描述数据集生命周期以及特定版本是否最新的元数据
数据集和模型入职和结果
今天，VerCD为我们的许多数据集构建、模型训练和度量管道提供定期的每日集成测试。这些频繁的集成测试确保我们知道这些工作流的当前可跟踪性和可再现性状态，即使有无数版本的代码、数据和模型工件，以及将整个系统连接在一起的深度依赖关系图。
例如，VerCD数据集服务已经成为Uber ATG自动驾驶传感器训练数据的可靠真相来源。在拥有能够持续交付传感器数据的服务之前，我们的数据集生成过程非常手工，无论是编排还是记录保存。通过将数据集构建工作流移植到VerCD上，我们已经将新数据集构建的频率提高了10倍以上，从而带来了显著的效率提升。维护经常使用的数据集的库存还提高了ML工程师的迭代速度，因为开发人员可以立即继续他们的实验，而不必等待几天来构建一个新的数据集。
此外，我们还为自动驾驶汽车的旗舰目标检测和路径预测模型提供每日和每周的培训工作。这种频繁的培训节奏将检测和修复某些错误的时间缩短到几天，而在CICD培训之前，错误的窗口期在很大程度上是未知的，需要许多工程师的关注。
前进
我们的ML模型生命周期过程和我们构建的简化它的工具(如VerCD)，帮助我们管理我们使用的许多不同的模型，并更快地迭代模型。这些实践和解决方案来自于我们在开发精确的自动驾驶汽车系统时高效工作的需求。
通过在ML开发中建立不同的工作流阶段，以及反过来开发支持系统(如VerCD)来管理日益增加的ML工作流的复杂性，我们已经能够取得很大的进展。随着技术的不断成熟，复杂性和复杂性的增加，依靠人工、人工干预来管理ML工作流阶段变得越来越不可行。这些工具使工程师能够更快地迭代ML组件，从而提高自动驾驶汽车的性能。
致谢
这个项目是与Uber的几个团队和工程师合作的结果，包括Ivan Dimitrov, Luke Duncan, Joshua Goller, Yevgeni Litvin和Sidney Zhang。
