大学毕业第一份工作的时候，我自以为对机器学习很了解。我在Pinterest和KhanAcademy做过两次构建机器学习系统的实习。在伯克利的最后一年，我开始研究计算机视觉的深度学习，并在Caffe工作，Caffe是最早流行的深度学习库之一。毕业后，我加入了一家名为“Cruise”的小型创业公司，专门制造自动驾驶汽车。现在在水族馆，我帮助公司部署深度学习模型来解决重要的社会问题。多年来，我构建了一个非常酷的深度学习和计算机视觉堆栈。与我在伯克利做研究时相比，现在有更多人在生产应用程序中使用深度学习。他们现在面临的许多问题与我在2016年Cruise面临的问题相同。我有很多关于深度学习在生产中的经验教训，我想与大家分享，这样你就不必费力去学习它们.图注：作者团队开发出第一个部署在汽车上的机器学习模型1将ML模型部署到自动驾驶汽车上的故事首先，让我谈谈Cruise有史以来第一个部署在汽车上的ML模型。在我们开发模型时，工作流程感觉很像我在研究期间所习惯的。我们在开源数据上训练开源模型，将它们集成到公司的产品软件堆栈中，并将它们部署到车辆上。经过几周的工作，我们合并了最终的PR，在汽车上运行模型。“任务完成！”我心想，我们应该继续下一场火灾。我不知道的是，真正的工作才刚刚开始。该模型正在生产中运行，我们的QA团队开始注意到其性能问题。但我们还有其他模型要构建，还有其他任务要做，所以我们没有立即解决这些问题。3个月后，当我们调查问题时，我们发现训练和验证脚本都坏了，因为代码库自我们第一次部署以来发生了变化。经过一周的修复，我们查看了过去几个月的故障，并意识到模型生产运行中观察到的许多问题无法通过修改模型代码轻松修复，我们需要从我们的模型中收集和标记新数据公司车辆，而不是依赖开源数据。这意味着我们需要建立一个标签流程，包括该流程所需的所有工具、操作和基础设施。又过了3个月后，我们运行了一个新模型，该模型根据我们从汽车中随机挑选的数据进行训练。然后，用我们自己的工具标记它。但是当我们开始解决简单问题时，我们必须对哪些变化可能产生影响变得更加敏感。大约90%的问题是通过针对困难或罕见场景的仔细数据争论来解决的，而不是通过深度模型架构更改或超参数调整来解决。例如，我们发现模型在下雨天表现不佳（在旧金山很少见），因此我们标记了更多的雨天数据，在新数据上重新训练模型，模型的性能得到了提升。此外，我们发现该模型在绿色截锥体上表现不佳（与橙色截锥体相比很少见），因此我们收集了绿色截锥体的数据，经过同样的处理，模型的性能得到了改善。我们需要建立一个流程来快速识别和解决这些类型的问题。组装模型的1.0版本需要数周时间，而新改进版本的模型又需要6个月的时间。随着我们在某些方面的工作越来越多（更好的标签基础设施、云数据处理、训练基础设施、部署监控），模型可以每月或每周重新训练和重新部署。随着我们从头开始构建更多的模型管道并努力改进它们，我们开始看到一些共同的主题。将我们学到的知识应用到新的管道中，可以更轻松、更快速地运行更好的模型。2KeepIterativeLearningLegend：许多不同的自动驾驶深度学习团队的模型管道的迭代周期非常相似。从上到下：Waymo、Cruise和Tesla。我曾经认为机器学习主要是关于模型的。实际上，工业生产中的机器学习多为流水线。成功的最佳预测因素之一是在模型管道上有效迭代的能力。这不仅仅意味着快速迭代，还意味着智能迭代，第二部分很关键，否则你的管道会很快产生糟糕的模型。传统软件大多强调快速迭代和敏捷交付过程，因为产品需求是未知的，必须通过适配才能发现，所以与其在前期使用不稳定的假设进行详细规划，不如快速交付一个MVP并进行迭代。正如传统的软件需求很复杂一样，机器学习系统必须处理的数据输入领域也非常广泛。与普通软件开发不同，机器学习模型的好坏取决于它在代码中的实现以及代码所依赖的数据。这种对数据的依赖意味着机器学习模型可以通过数据集构建/管理“探索”输入域，使其能够理解任务需求并随着时间的推移适应它，而无需修改代码。要利用此属性，机器学习需要一种持续学习的概念，强调对数据和代码的迭代。机器学习团队必须：发现数据或模型性能中的问题诊断问题发生的原因更改数据或模型代码以修复它们验证模型在重新训练后变得更好部署新模型并重复团队应该至少每月尝试一次以经历这个循环。如果你做得好，也许每周都做一次。大公司可以在不到一天的时间内完成模型部署周期，但快速自动构建基础设施对于大多数团队来说非常困难。不太频繁地更新模型会导致代码腐烂（由于代码库更改导致模型流水线中断）或数据域转移（生产中的模型无法泛化到数据随时间的变化）。大公司可以在一天内完成一个模型部署周期，但快速自动构建基础设施对于大多数团队来说非常困难。不太频繁地更新模型会导致代码腐烂（由于代码库更改导致模型流水线中断）或数据域转移（生产中的模型无法泛化到数据随时间的变化）。但是，如果做得好，团队可以进入良好的节奏，将改进后的模型部署到生产环境中。3建模反馈回路校准的不确定性是一个诱人的研究领域，模型可以在其中标记它认为可能失败的地方。有效迭代模型的一个关键部分是专注于解决最具影响力的问题。要改进模型，您需要知道它出了什么问题，并能够根据产品/业务优先级对问题进行分类。有很多方法可以创建反馈循环，但它始于发现和分类错误。利用特定领域的反馈循环。如果有的话，这可能是获得模型反馈的一种非常强大和有效的方式。例如，预测性任务可以通过对实际发生的历史数据进行训练，“免费”获得标记数据，使其能够不断地被提供大量新数据，并相当自动地适应新情况。建立一个工作流程，人们可以在其中查看模型的输出并在错误发生时标记错误。当通过许多模型推理很容易发现错误时，这种方法特别有用。发生这种情况的最常见方式是客户注意到模型输出中的错误并向机器学习团队投诉。这一点不容小觑，因为此渠道允许您将客户反馈直接纳入开发周期！一个团队可以让人类仔细检查客户可能错过的模型输出：想象一名操作员看着机器人在传送带上分拣包裹，并在发现错误时点击按钮。建立一个工作流程，人们可以在其中查看模型的输出并在错误发生时标记错误。当大量模型推理中的错误很容易被人工审查发现时，这尤其合适。最常见的方式是当客户注意到模型输出中的错误并向ML团队投诉时。这一点不容小觑，因为此渠道允许您将客户反馈直接纳入开发周期。一个团队可以让人类仔细检查客户可能错过的模型输出：想象一个操作员看着机器人在传送带上分拣包裹，每当他们发现有问题时点击一个按钮。当模型运行如此频繁以至于人类无法检查时，请考虑设置自动审查。当很容易针对模型输出编写“健全性检查”时，这尤其有用。例如，只要激光雷达对象检测器和2D图像对象检测器不一致，或者帧到帧检测器不同意时间跟踪系统，就进行标记。当它工作时，它会提供很多关于故障条件发生位置的有用反馈。当它不起作用时，它只是暴露了你检查系统中的错误，或者遗漏了系统出错的所有情况，这是非常低风险的高回报。最通用（但最困难）的解决方案是分析模型运行数据的不确定性。一个简单的例子是查看在生产中产生低置信度输出的模型示例。这可以显示模型真正不确定但不是100%准确的地方。有时一个模型可能是错误的。有时模型是不确定的，因为缺乏可用于做出良好推断的信息（例如，人类难以理解的嘈杂输入数据）。有解决这些问题的模型，但这是一个活跃的研究领域。最后，可以利用模型对训练集的反馈。例如，检查模型与其训练/验证数据集之间的不一致（即具有高损失的示例）表明失败或错误标记具有高置信度。神经网络嵌入分析可以提供一种了解训练/验证数据集中故障模式模式的方法，并且可以发现训练和生产数据集中原始数据分布的差异。图例：大多数人的时间很容易从典型的再培训周期中删除。即使这是以降低机器时间效率为代价的，它也消除了很多体力劳动的痛苦。加速迭代的全部意义在于减少完成迭代周期所需的工作量。然而，总有办法让事情变得更简单，所以你必须优先考虑需要改进的地方。我喜欢用两种方式来思考努力：时钟时间和人类时间。时钟时间是指运行某些计算任务所需的时间，例如数据的ETL、训练模型、运行推理、计算指标等。劳动时间是指人必须主动干预运行管道的时间，例如在管道中间手动检查结果、运行命令或触发脚本。例如，必须通过在步骤之间手动移动文件来手动顺序运行多个脚本，这很常见，但很浪费。一些纸巾纸背面的数学：如果机器学习工程师每小时花费90美元，并且每周浪费2小时手动运行脚本，那么每人每年加起来9360美元！将多个脚本和人工突破组合到一个完全自动化的脚本中，可以更快、更轻松地运行模型管道循环，节省大量资金，并让您的机器学习工程师不那么古怪。相比之下，时钟时间通常需要“合理”（例如，可以在一夜之间完成）。唯一的例外是机器学习工程师正在进行大量实验，或者存在极端的成本/扩展限制。这是因为时钟时间通常与数据大小和模型复杂性成正比。从本地处理转移到分布式云处理时，时钟时间显着减少。之后，云中的水平扩展往往会解决大多数团队的大部分问题，直到问题扩展。不幸的是，完全自动化某些任务是不可能的。几乎所有生产机器学习应用程序都是监督学习任务，并且大多数依赖于一定程度的人机交互来告诉模型它应该做什么。在某些领域，人机交互是免费的（例如，社交媒体推荐用例或其他具有大量直接用??户反馈的应用程序）。在其他情况下，人工时间更有限或更昂贵，例如训练有素的放射科医师为训练数据“标记”CT扫描。无论哪种方式，重要的是尽量减少改进模型所需的劳动时间和其他成本。虽然早期团队可能依赖机器学习工程师来管理数据集，但让没有机器学习知识的操作用户或领域专家来承担数据管理的繁重工作通常更经济（或者，对于放射科医生而言，这是必要的）。在这一点上，使用良好的软件工具建立用于标记、审查、改进和版本化数据集的操作流程变得非常重要。5.鼓励ML工程师健身。注意：当ML工程师举重时，他们也会举起他们模型学习的重量。构建足够多的工具来支持新领域或新用户群可能需要花费大量时间和精力，但如果做得好，结果将是非常值得的。在Cruise，我的一位工程师非常聪明（有些人会说懒惰）。工程师建立了一个迭代循环，其中操作反馈和元数据查询的组合将从模型表现不佳的地方提取数据进行标记。然后，离岸团队将标记数据并将其添加到新版本的训练数据集中。之后，工程师们建立了基础设施，允许他们在计算机上运行脚本并启动一系列云任务，以自动重新训练和验证新添加数据的简单模型。每周，他们都会运行重新训练脚本。然后，他们在模型训练和验证的同时去健身房。经过几个小时的锻炼和晚餐后，他们会回来查看结果。巧合的是，新的和改进的数据将导致改进的模型，在快速仔细检查以确保一切都有意义之后，他们将新模型投入生产，汽车的驾驶性能将得到改善。然后，他们花了一周的时间完善基础设施，试验新的模型架构，并构建新的模型管道。这位工程师不仅在本季度末获得晋升，而且身体状况良好。6结论总结：在研究和原型制作阶段，重点是构建和发布模型。但是，当系统进入生产阶段时，核心任务是构建一个能够以最小的努力定期发布改进模型的系统。你做得越好，你可以建立的模型就越多！为此，我们需要专注于以规律的节奏运行模型管道，并专注于比以前更好地交付模型。每周或更短时间内将新的改进模型投入生产！建立从模型输出到开发过程的良好反馈循环。找出模型在哪些示例上表现不佳，并将更多示例添加到您的训练数据集中。自动执行管道中特别繁重的任务并建立团队结构，使您的团队成员能够专注于他们的专业领域。特斯拉的AndrejKarpathy将理想的最终状态称为“假期行动”。我建议，设置一个工作流程，让您的ML工程师去健身房，让您的ML管道完成繁重的工作！最后需要强调的是，以我的经验来看，绝大多数关于模型性能的问题都可以用数据来解决，但有些问题只能通过修改模型代码来解决。这些更改通常非常特定于手头的模型架构，例如在图像对象检测器上工作了几年之后，我花了太多时间担心某些方向比的最佳先验框分配和改进特征图小对象的分辨率。然而，随着Transformers显示出作为一种适用于许多不同深度学习任务的多功能模型架构类型的前景，我怀疑其中许多技巧将变得不那么相关，机器学习开发的重点将进一步转向改进数据集。
