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

摘要： 本文描述机器学习任务的“OODA环”的概念，迭代地执行四个过程：分析、选择方法、实现、测量步骤，循环此过程以提高开发效率。

随着机器学习（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从业者可能会有创造性的解决方案添加到您要尝试的事物列表中。
• 好的实现技能很重要，编码规范能够防止错误。
• 若是实验花费的时间太长，请考虑花一些时间寻找代码的优化，或者与系统专家讨论如何加快训练速度。

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

结论

机器学习项目具备内在的不肯定性，上面推荐的方法旨在为开发者提供一些指导。虽然每次实验的结果没法预测，很难让本身对达到特定的准确度目标负责，但至少可让本身负责完成错误分析、制定想法列表、编写代码并查看其工做原理。

本文做者：【方向】

阅读原文

本文为云栖社区原创内容，未经容许不得转载。