为什么软件工程过程和工具不适用于机器学习

“人工智能就是新的电。”至少，这是安德鲁·吴(Andrew Ng)在今年的亚马逊再保险：火星大会上提出的建议。在他的主旨演讲中，Ng讨论了人工智能(AI)的快速增长-它稳步进军一个又一个行业；人工智能突破、技术或恐惧的无情出现在每天的头条新闻中；来自寻求现代化的老牌企业(见几周前的索尼)以及乘坐专注于人工智能的创始人浪潮空降市场的风险投资者的巨额投资。

“人工智能是下一个大变革，”Ng坚持说，我们正在关注这场变革的展开。

虽然人工智能可能是新的电力(作为彗星的数据科学家，我不需要太多的说服力)，但该领域要实现这一潜力仍然存在重大挑战。在这篇博客文章中，我将讨论为什么数据科学家和团队不能依赖软件工程团队在过去20年中一直在使用的工具和过程来进行机器学习(ML)。

对软件工程的工具和过程的依赖是有意义的--数据科学和软件工程都是主要工具是代码的学科。然而，在数据科学团队中正在做的事情与在软件工程团队中正在做的事情是截然不同的。检查这两个学科之间的核心差异是一次有益的练习，有助于澄清我们应该如何思考如何构建我们的人工智能工具和流程。

在Comet，我们相信采用专门为人工智能设计的工具和流程将帮助从业者解锁并实现Ng所说的革命性转型类型。

软件工程是一门学科，从广义上看，它的目标是设计和实现计算机可以执行以执行定义的功能的程序。假设软件程序的输入在预期的(或受约束的)输入范围内，则其行为是可知的。在2015年ICML的一次演讲中，Leon Bottou很好地阐述了这一点：在软件工程中，算法或程序可以被证明是正确的，在某种意义上，如果给定关于输入的特定假设，当算法或程序终止时，某些属性将为真。

软件程序的可证明正确性塑造了我们为进行软件工程而构建的工具和过程。考虑软件编程从可证明的正确性中得出的一个推论特征：如果程序对于某些输入值是可证明正确的，则该程序包含对于这些输入值也是可证明正确的子程序。这就是为什么一般而言，像敏捷这样的工程过程对于软件团队来说是成功和高效的。将这些项目分解为子任务是可行的。大多数瀑布和Scrum实现还包含子任务。

我们看到许多数据科学团队使用与这些软件方法相同或大致相似的工作流流程。不幸的是，它们的效果不是很好。原因呢？软件工程的可证明的正确性并不延伸到人工智能和机器学习。在(有监督的)机器学习中，我们对所建立的模型唯一的保证是，如果训练集是来自某个分布的IID(独立同分布)样本，那么在同一分布的另一个IID样本上的性能将接近于训练集的性能。因为不确定性是机器学习的固有属性，子任务可能会导致不可预见的下游影响。

部分答案在于这样一个事实，即(A)我们感兴趣并且(B)服从于机器学习解决方案(例如自动驾驶汽车、对象识别、标记图像和生成性语言模型等)的问题没有明确的可重现的数学或编程规范。机器学习系统代替规范输入大量数据，以便检测模式并生成预测。换句话说，机器学习的目的是创建一个统计代理，作为这些任务之一的规范。我们希望我们收集的数据是真实世界分布的代表性子样本，但在实践中，我们不能确切地知道这一条件得到了多好的满足。最后，我们使用的算法和模型体系结构非常复杂，足够复杂，以至于我们不能总是将它们拆分成子模型来准确地理解正在发生的事情。

从这个描述中，机器学习系统可知性的障碍应该是比较明显的。对于机器学习来说，这类问题的固有之处在于缺乏明确的数学规范。我们在没有规范的情况下使用的统计代理正在积累大量的环境数据，我们希望这些数据是真实的和具有代表性的。我们用来从收集的数据中提取模式的模型非常复杂，我们不能可靠地将它们拆分开来，准确地理解它们是如何工作的。我在Comet的同事Dhruv Nair已经写了一个关于机器学习中的不确定性的三部分系列文章(这里有到第一部分的链接)，如果您想更深入地挖掘这个主题的话。

那么，考虑一下机器学习项目中使用的敏捷方法的含义。我们不可能希望将机器学习任务分解为子任务，作为某个更大的冲刺的一部分来处理，然后像乐高一样拼凑成一个完整的产品、平台或功能，因为我们不能可靠地预测子模型或模型本身将如何工作。

吴昌俊也在Re：Mars上讨论了这个话题。他透露了他的团队是如何采用专门为ML：1天冲刺设计的工作流系统的，结构如下：

Ng的1天冲刺方法论反映了一些对理解和设计实践机器学习的团队至关重要的东西：这是一门内在的实验科学。因为正在建造的系统缺乏明确的规范，因为数据收集是一门不完美的科学，而且因为机器学习模型非常复杂，所以实验是必要的。与围绕数周的冲刺来构建团队流程相比，快速测试许多不同的体系结构、功能工程选择和优化方法通常更有成效，直到开始出现什么在起作用、什么没有起作用的粗略图像。1天的冲刺使团队可以快速行动，在短时间内测试许多假设，并开始围绕建模任务建立直觉和知识。

假设您采用Andrew Ng的1天冲刺方法或类似的方法(您应该这样做)。您正在设置新的超参数，调整您的功能选择，并每晚运行实验。您使用什么工具来跟踪每个模型培训的这些决策？您如何比较实验以了解不同配置的工作方式？你是如何与同事分享实验的？你的经理或同事能可靠地复制你昨天做的一个实验吗？

除了过程之外，您用来进行机器学习的工具也很重要。在Comet，我们的使命是通过为您提供完成此任务的工具，帮助公司从机器学习中提取业务价值。我们采访的大多数数据科学团队都在使用git、电子邮件和(信不信由你)电子表格的组合来记录每个实验周围的所有工件。

考虑一个建模任务，其中您跟踪20个超参数、10个度量、数十个体系结构和功能工程技术，所有这些都是在快速迭代并一天运行数十个模型的情况下完成的。手动跟踪所有这些工件可能会变得非常单调乏味。构建一个好的ML模型常常类似于调谐一台有50个旋钮的收音机。如果您没有跟踪您尝试过的所有配置，那么在建模空间中查找信号的组合复杂性可能会变得很麻烦。

我们基于这些需求(以及我们在Google、IBM以及作为哥伦比亚大学和耶鲁大学研究小组的一部分自己从事数据科学和机器学习时所需要的)构建了Comet。每次训练模型时，都应该有一些东西可以捕获实验的所有工件，并将它们保存在某个中央分类帐中，在那里您可以查找、比较和筛选您(或您的团队)的所有工作。Comet就是为了向机器学习的实践者提供这一功能而构建的。

测量工作流效率是出了名的困难，但我们的用户报告说，使用Comet平均节省了20-30%的时间(注：Comet对个人和研究人员免费-您可以在这里注册)。这没有考虑到独特的洞察力和知识，这些洞察力和知识来自于对您的超参数空间的直观理解、实时指标跟踪、团队范围的协作和实验比较。获取这些知识可以节省时间，也许更重要的是，能够构建更好的模型。

完全忽略有关ML工具和过程的问题是很有诱惑力的。在一个负责自动驾驶汽车、语音助手、面部识别和更多突破性技术的领域，人们跳到自己制造这些工具的争斗中，而不考虑如何最好地制造它们，这是情有可原的。

如果您确信软件工程堆栈足够好地工作于人工智能，那么您将不会被证明是对是错。毕竟，这是一个由不确定性定义的领域。但也许最好是以数据科学家考虑建模任务的方式来考虑这个问题：可能的未来的概率分布是什么？什么是或多或少的可能性？像人工智能这样强大和有前途的领域将继续依赖为不同学科构建的工具和流程，还是会出现新的工具和流程来最大限度地增强从业者的能力？

如果您对这些ML工具感兴趣或有任何问题，请随时通过[email protected]联系我。