如何交付机器学习项目：一份机器学习工程开发流程指南

随着机器学习（ML）成为每个行业的重要组成部分，对机器学习工程师（MLE）的需求急剧增长。MLE需要将机器学习技能与软件工程专业知识相结合，为特定应用程序找到高性能的模型，并应对出现的实施挑战——从构建训练基础架构到准备部署模型。在新的机器学习团队中，遇到最常见的障碍之一是工程师习惯传统软件工程的开发过程，而开发新ML模型的过程从一开始就是非常不确定的，需要不断的尝试才能找到一个比较合适的模型。

许多类型的专业人员都面临着类似的情况：软件和商业开发人员，寻求产品市场契合的初创公司等，这些职业中的每一个都采用了一个共同的框架，以帮助团队高效地工作：软件开发中的agile/scrum，初创公司和美国空军的OODA环。MLE同样可以遵循类似的框架来应对不确定性并快速开发出优质的产品。

ML工程环

在本文中，我们将描述ML的“OODA环”的概念：ML工程循环，其中ML工程师迭代地

1.分析
2.选择一种方法
3.实现
4.测量

快速有效地发现最佳模型并适应未知的环境。此外，我们将为每个阶段，以及优化过程给出具体的提示。

MLE环

ML团队的成功通常意味着在给定的约束条件下提供高性能模型。例如，实现高预测准确性的模型，同时还受到内存使用、预测时间等约束。性能由与最终产品成功最相关的指标定义，无论是准确性、运行速度、输出多样性等。简单起见，本文选择将“错误率”最小化作为性能指标。

当刚开始确定新项目的范围时，就应该准确定义成功的标准，然后将其转换为模型指标。在产品方面，服务需要达到什么样的性能水平？例如，如果在新闻平台上向个人用户推荐5篇文章，我们需要多少相关内容，以及如何定义相关性？鉴于此性能标准和拥有的数据，可以构建的最简单的模型是什么？

ML工程环的目的是围绕开发过程设置一个死记硬背的框架，简化决策过程，专注于其中最重要的步骤。当不确定性增加时，即使是最有经验的工程师，这个框架仍然是非常有价值，例如，当模型意外地无法满足要求时、团队的目标突然改变等情况。

入门

要引导下面描述的循环，您应该从一个涉及非常少的不确定性的最小实现开始。通常我们希望尽快建立足够的系统，以便我们可以评估其性能并开始迭代开发。这通常意味着：
设置训练、开发和测试数据集，以及构建好一个简单的模型。

例如，如果要构建一个树木探测器来测量一个地区的树木种群，可能会使用类似的Kaggle 竞赛中的现成训练集，以及来自目标区域的手工收集的一组照片用于开发和测试集。然后可以对原始像素进行逻辑回归，或者在训练图像上运行预训练网络（如ResNet）。此时的目标不是一次性地完成项目，而是开始迭代周期。以下是一些有所帮助的提示：

提示

关于测试集：

由于团队的目标是在测试集上表现良好，所以测试集应该反映产品或业务的需求。例如，如果正在构建一个应用程序来检测自拍的皮肤状况，请随意对任何一组图像进行训练，但要确保测试集中包含光线不足且质量差的图片。
更改测试集会改变团队的目标，因此尽早修复测试集并对其进行修改以反映项目、产品或业务目标的变化会很有帮助。
测试集合训练集大小都设置足够大，以使获得的性能指标足够准确，以便在模型之间做出良好区分。
尽可能地为开发集和测试集创建对的标签或注释。错误标记的测试集等同于错误指定的产品要求。
了解人类在测试集上的表现如何，或者现有/竞争系统的表现如何，这将为你提供最佳的错误率，即目前可以实现的最佳性能。
最终目标是使测试性能尽可能接近我们的猜测，以获得最佳性能。
关于开发和训练集：
开发集是团队的测试性能代理，可用于超参数的调整。因此，它应该与测试集有相同的分布。一个好方法是首先收集一大堆样本，然后将它们随机分成开发集和测试集。
如果认为生产数据会产生噪音，请确保通过使用数据增强或降级来解决训练集中的噪音问题。

一旦获得初始原型后，应检查其在训练、开发和测试集上的性能，评估测试性能与产品所需性能之间的差距。开始迭代开发模型了！

分析

确定性能瓶颈

分析阶段就像医疗诊断一样：配备了一套可以执行的诊断程序，目标是针对限制模型性能的因素提出最可能的诊断。在实践中，可能会有许多不同的重叠问题导致当前的结果。不要试图全面了解每一个缺点，而是要了解最重要的因素，因为许多小问题会随着模型改进而改变甚至消失。

下面，我们列出了一组常用的诊断流程。

每次分析的一个良好起点是查看训练、开发和测试性能。建议在每次实验结束时使用代码执行此操作，以使自己习惯于每次查看这些数字。一般而言，训练集错误<=开发集错误<=测试集错误（如果每组中的数据遵循相同的分布）。根据上一次实验的训练、开发和测试错误率，可以快速查看这些因素中的哪些是当前的约束约束。

权重直方图

诊断和治疗

如果训练集错误是当前的限制因素，则可能会出现以下问题：

1.优化算法未被精确调整。查看学习曲线，看看loss损失是否在减少，检查是否过拟合。可以通过可视化神经元反应的直方图，以检查它们是否饱和（导致梯度消失）。
2.训练集可能包含错误标记或损坏的数据。在训练算法使用之前，在代码阶段手动检查一些训练样例。
3.模型可能太小或泛化能力不强。

如果开发集错误是当前限制因素，这可能是由以下问题引起的：

1.模型可能太大或过拟合。
2.没有足够的训练数据来学习基础模式的良好模型。
3.训练数据的分布与开发或测试数据分布不匹配。
4.模型的超参数设置很差。
5.模型归纳与数据匹配不佳。

如果测试集错误是当前限制因素，这通常是由于开发集太小或者实验过程中过度拟合开发集导致。
对于上述任何一种情况，可以通过手动检查模型出错的一组随机示例来了解模型的失败。

1.尝试通过可视化数据来识别常见的错误类型，然后浏览这些示例并记录每种错误发生的频率。
2.某些样本可能被错误标记或具有多个合理标签。
3.一些样本可能比其他样本更难预测，或者可能缺少做出正确决策所需的上下文。

请注意，上述许多诊断都有直接而明显的应对方法。例如，如果训练数据太少，那么只需获取更多训练数据即可！我们仍然发现在心理上将分析阶段和选择阶段分开是有用的，因为很多人容易陷入尝试随机方法而不真正深入挖掘潜在的问题。此外，以开放的心态努力回归错误分析通常会发现更有用的见解，可以改善做出的决定。

例子

众所周知，卫星数据噪声很大，通常需要检查。以Insight为例，当AI研究员Jack Kwok正在建立一个帮助灾难恢复的分割系统时，他注意到虽然他的分割模型在他的卫星图像训练集上表现良好，但它在开发集上表现不佳。原因是飓风图像质量较低且比训练数据更模糊。向训练管道添加额外的增强操作，对图像应用模糊有助于缩小训练和开发性能之间的差距。

选择方法

找到解决瓶颈的最简单方法

在进行分析之后，需要很好地了解模型所出现的错误类型以及影响性能的因素。对于给定的诊断，可能存在几种可能的解决方案，下一步是枚举并优化它们。

上面的一些诊断有着潜在的解决方案。例如，如果训练数据集太小，收集更多训练数据可能是一个相当快速和简单的解决方案。

建议ML工程师列举尽可能多的想法，然后偏向简单、快速的解决方案。如果现有解决方案可能有效，请尝试在此基础之上使用迁移学习。

提示

根据诊断，以下是一些常见的解决方案。
如果需要调整优化器以更好地适应数据：

对于数值优化器，尝试调整学习速率或动量设置。
尝试不同的初始化策略，或从预先训练的模型开始。
尝试一种更容易调整的模型。在深度学习中，具有批量归一化的剩余网络或网络可能更容易训练。

如果模型无法很好地拟合训练数据：

使用更大或更具表现力的模型类。
检查模型在标记错误、缺少字段等的训练集上出错的示例。在训练数据清理中投入时间可以显著改善性能。

如果模型没有在开发集表现不好：

添加更多训练数据。
使用真实训练示例生成的新样本扩充数据。例如，如果注意树检测器在模糊图像上始终表现不佳，请使用OpenCV对图像增强，使图像看起来有点模糊。
搜索更广泛或更细粒度的超参数范围，以确保在开发集上找到表现最佳的模型。
尝试不同形式的正则化（例如权重衰减、dropout或决策树的修剪）。
尝试不同的模型，不同类型的模型可以改变数据拟合程度以及泛化能力。最好先从最简单的模型开始。

实现

只构建需要构建的内容，并快速完成
这个阶段的目标是快速实现基础模型，以便可以测量出结果，并从中学习，之后快速回到开发循环周期中。因此，建议专注于构建当前实验所需的内容。

提示

大多数人高估了收集和标记数据所带来的成本，并低估了在数据匮乏的环境中解决问题的困难。

当收集和标记数据时：

定期查看数据。查看原始数据，在预处理后查看、查看标签。这一点非常重要！通过在每个步骤中密切关注数据来捕获许多错误。
标签和清洗数据是一项常见任务。大多数人高估了收集和标记数据所带来的成本，并低估了在数据匮乏的环境中解决问题的困难。一旦进入节奏，可以轻松地每分钟标记20张图像。思考下，你是想花一个小时标记图像，并花一个小时来解决1200个图像数据集的简单分类问题，或者花3个星期试图从5个样本中学习模型呢？

当构造新的模型时，请从类似的现有实现开始。许多相似的研究论文都开源代码，这将节省大量的开发时间。对于任何问题，建议连续执行以下步骤：

1.找到解决类似问题的模型的实现。
2.在现有模型（相同数据集和超参数）的条件下重现实验。
3.慢慢调整模型和数据以满足任务的需求。
4.重写所需的任何部件。

编写测试程序以检查梯度、张量值、输入数据和标签是否格式正确。在最初设置模型时执行此操作，这样一旦捕获错误并解决后，之后再也不会遇到了。

测量

打印出需要的测试结果和任何其他指标。

如果实验结果的表现有所改善，这可能说明你正走上正轨。在这种情况下，可能是弄清楚运行良好组件的好时机，并确保团队中的其他人可以复现该实验。

另一方面，如果性能变差或没有足够的改善，你需要决定是再次尝试（回到分析阶段）还是放弃当前的想法。这点取决于二者的成本，尝试成本和沉没成本。

提示

有用的绩效指标包括模型的准确性和损失，以及业务价值指标。注意，业务相关的指标最终是重要的，因为它们决定了目前开发的模型的有用性。如果测试指标与业务指标不同，则此测量周期结束是停止并考虑更改优化标准或测试集的好时机。
由于在每个开发循环结束时都打印出相关的指标，此时也是计算其他指标的时机，可以在分析阶段帮助你看决定是否继续使用当前的想法。
最终会建立一个“仪表板”，其中包含测试指标和业务指标，以及每次实验结束时可以看到的其他有用数据。

优化循环

尽管任务固有的不确定性，上面的ML工程环将帮助开发者朝着更好的模型方向前进。遗憾的是，它无法保证立刻开发出正确的模型，还需要我们需要培养自己在每个阶段做出正确选择的能力，比如确定性能瓶颈、决定尝试哪些解决方案、如何正确实现，以及如何衡量应用程序的性能。

此外，还应该花时间考虑提高迭代的质量和速度，以便在每个周期中取得最大进展，并且可以快速完成多次迭代。

提示

如果在分析阶段的结果并不满意的话，请创建一个总结实验结果的脚本，从训练和开发集中收集错误，并对其进行格式化。“仪表板”经常使用的诊断输出能帮助你克服这一时刻的思维。
如果觉得自己想要尝试什么，那就只选择一个方向对其进行实验。试图一次做太多事情会减慢速度。
收集数据是获得更好性能的常用方法，投资工具以使数据更易于收集、清理和标记是有意义的。
如果感觉困在诊断瓶颈或不知道如何选择一个好的模型来尝试下一步时，请考虑联系该领域的专家。专家通常可以在错误分析期间提供有用的见解，而研究论文或经验丰富的ML从业者可能会有创造性的解决方案添加到您要尝试的事物列表中。
好的实现技能很重要，编码规范可以防止错误。
如果实验花费的时间太长，请考虑花一些时间寻找代码的优化，或者与系统专家讨论如何加快训练速度。

与其他决策一样，只有在解决当前的痛点时才能处理这些项目。有些团队花费太多时间构建“完美”框架，却发现真正令人头疼的事情在其他地方。