ACM通信

实践

声明式机器学习系统

作者:皮耶罗·莫利诺，克里斯托弗·Ré
ACM通信，2022年1月，第65卷第1期，42-49页
10.1145 / 3475167
评论

在过去的20年里，机器学习(ML)已经逐步从一项学术努力发展成为一项普及技术，几乎应用于计算的各个方面。基于ml的产品现在已经嵌入到我们数字生活的方方面面:从推荐看什么，到预测我们的搜索意图，再到为消费者和企业设置的虚拟助手提供支持。此外，最近在自然科学领域应用人工智能的成功表明，人工智能可以用来解决当今人类面临的一些最棘手的现实问题。¹⁹

基于这些原因，ML已经成为科技公司战略的核心，并从学术界获得了比以往任何时候都更多的关注。导致当前以ML为中心的计算世界的进程被以下几个因素加速了，包括硬件的改进支持大规模并行处理，数据基础设施的改进导致训练大多数ML模型所需的大量数据集的存储和消费，以及允许更好的性能和可伸缩性的算法改进。

尽管取得了成功，这些采用ML的例子只是冰山一角。目前，培训和使用ML模型的人员通常是在大型组织中工作多年的有经验的开发人员，但是下一波ML系统应该允许大量的人员(可能没有任何编码技能)执行相同的任务。这些新的ML系统将不需要用户完全理解模型是如何训练和用于获得预测的所有细节——这是进入的一个重要障碍，但将为他们提供一个更抽象的界面，要求更低，更熟悉。声明性接口非常适合实现这一目标，因为它隐藏了复杂性并支持兴趣分离，并最终提高了生产率。

我们通过开发两个声明性ML系统——overton来处理这种抽象接口¹⁶和路德维希¹³这要求用户只声明他们的数据模式(输入的名称和类型)和任务，而不必编写低级的ML代码。本文的目的是描述当前ML系统的结构，强调哪些因素对ML项目的成功是重要的，哪些因素将决定更广泛地采用ML，当前ML系统面临的问题，以及我们开发的系统如何解决这些问题。最后，本文描述了从ML和系统多年来的发展轨迹中可以学到什么，以及下一代ML系统将是什么样子。

软件工程遇到ML。在ML的成功中，一个没有得到足够重视的因素是对生成真实的ML应用程序的过程的更好理解，以及它与传统软件开发的不同之处。构建一个工作的ML应用程序需要一组新的抽象和组件，David Sculley等人很好地描述了这些抽象和组件。¹⁸他还指出了ML项目的特殊方面如何可能导致技术债务的大幅增加(例如，通过偷工减料而不是遵循软件工程原则来重做解决方案的成本)。ML开发的这些定制方面与软件工程实践是相反的，主要原因是每一步都存在大量的不确定性，这导致了更面向服务的开发过程。¹

尽管每个ML项目都有定制的方面，但研究人员首先和工业界后来都提取了通用模式，这些模式将构建ML项目的最机械部分抽象为一组工具、系统和平台。例如，考虑一下像scikit-learn、TensorFlow、PyTorch和许多其他项目是如何通过更标准化的过程允许广泛采用ML和快速改进模型的:实现一个ML模型曾经需要高技能的ML研究人员多年的工作，现在可以在几行大多数开发人员能够编写的代码中完成同样的工作。在她的文章“硬件彩票”中(参见通信(2021年12月，第58页)Sara Hooker认为加速器硬件的可用性决定了ML算法的成功，这可能比它们的内在优点更重要。⁸我们同意这一评估，并补充说，为ML算法量身定制的易于使用的软件包的可用性对它们的成功和采用至少同样重要，如果不是更重要的话。

即将到来的ML系统浪潮。关于编译器、数据库和操作系统的几代工作可能会引发新的基本问题，即如何构建下一代ML驱动的系统，使没有ML专业知识的人可以通过更抽象的接口训练模型并获得预测。在整个计算历史中，从这些系统中学到的许多教训之一是，采用的大幅增加总是伴随着利益分离和复杂性的隐藏，如图1在不同的计算领域中，对学习和使用软件工具(语言、库或整个产品)的复杂性与潜在能够使用它的用户数量之间的关系进行了近似描述。

图1。学习的复杂性与软件工具的使用。

正如编译器将低级机器代码的复杂性隐藏在更高级、更容易读懂的语言的外观后面一样，正如数据库管理系统将数据存储、索引和检索的复杂性隐藏在声明性查询语言的外观后面一样，ML系统的未来应该朝着隐藏复杂性和暴露更简单的抽象的方向发展，很可能以声明性的方式。这种转变所隐含的利益分离将允许高技能的ML开发人员和研究人员以一种类似于编译器维护人员和数据库开发人员改进他们的系统的方式改进底层模型和基础设施，同时允许更广泛的用户通过在更高的抽象级别与它们交互来使用ML技术。这很像程序员在不知道如何在机器代码中编译的情况下用简单语言编写代码，或者数据分析师在不知道数据库索引中使用的数据结构或查询计划器如何工作的情况下编写SQL查询。这些相似之处表明，声明性接口是下一波ML系统的良好候选对象，隐藏复杂性和兴趣分离是将ML带给非编码人员的关键。

在这里，我们概述了ML开发生命周期和ML平台的当前状态，以及ML系统面临的一些挑战和需求。本文描述了在构建新的声明性抽象方面的一些初步尝试，这些抽象是我们一手处理的，可以解决这些挑战。事实证明，通过避免编写低级易出错的ML代码，这些声明性抽象有助于使最终用户更容易访问ML。最后，我们将介绍从这些尝试中得到的教训，并对未来可能发生的情况进行推测。

回到顶部

机器学习系统

许多关于机器学习项目的开发生命周期的描述已经被提出，但采用的是在图2是一个简单的粗粒度视图，由四个高级步骤组成:

图2。ML项目的生命周期。

1. 业务需求识别
2. 数据挖掘和收集
3. 管道建设
4. 部署和监控

这些步骤中的每一个都由许多子步骤组成，整个过程可以视为一个循环，从ML系统的部署和监视中收集的信息有助于确定下一个周期的业务需求。尽管过程是连续的，但每一步的结果都是高度不确定的，任何一步的消极结果都可能将过程送回前面的步骤。例如，数据探索可能揭示可用数据不包含足够的信号来解决已确定的业务需求，或者管道构建可能揭示，给定可用数据，没有模型能够达到足够高的性能来解决业务需求，因此应该收集新的数据。

由于ML过程固有的不确定性，为ML项目编写代码通常会导致特殊的实践:几乎没有代码重用，抽象之间没有逻辑/物理分离，甚至在过程早期所做的微小决策也会影响下游代码的每个方面。这与在数据库系统中所发生的情况相反，在数据库系统中抽象通常定义得很好:在数据库系统中，存储数据方式的更改不会改变应用程序代码或编写查询的方式，而在ML项目中，数据大小或分布的更改最终会改变应用程序代码，使代码难以重用。

机器学习平台和AutoML。ML过程的每个步骤都由一组工具和模块支持，其潜在优势是使这些复杂的系统更易于管理和理解。

不幸的是，这些工具和模块之间缺乏定义良好的标准接口，限制了模块化方法的好处，并使体系结构设计选择难以更改。其结果是，如果在流程的任何阶段发生错误或更改，特别是在早期(例如，在发布带有bug的记号赋予器的新版本时)，这些系统将遭受一连串的复合效应，并且所有以下部分(嵌入层、预训练模型、预测模块)开始返回错误的结果。到目前为止，数据框架抽象是组件之间唯一被广泛使用的接触点，但由于不同实现之间广泛的不兼容，它可能存在问题。

为了解决这个问题，越来越多的端到端平台正在构建中——大多作为大公司的单一内部工具——但这往往以组织或技术层面的瓶颈为代价。ML平台团队可能成为整个组织中ML进展的把关人(例如，当一个研究团队设计了一个不符合平台已经支持的模型的新算法，这使得将新算法投入生产非常困难)。在不断变化的ML环境中，ML平台可能成为过时实践的结晶。

与此同时，AutoML系统承诺通过超参数优化等技术，自动化过程中某些部分(特别是在管道构建中)所涉及的人工决策¹⁰和建筑搜索,^3.对ML过程的建模部分进行抽象。

AutoML是一个很有前途的方向，尽管研究工作通常集中在优化管道的单个步骤上(特别是，找到模型架构)，而不是优化整个管道，而且找到一个比普遍接受的解决方案稍好的解决方案的成本可能最终会超过收益。在某些情况下，这恶化了可重用性问题，并与最近的研究结果形成对比，这些研究结果表明，与模型的大小相反，架构实际上可能不是模型中最具影响力的方面，至少对于在足够大的数据集上训练的自回归模型是这样的。⁷尽管如此，AutoML带来的自动化通常是积极的，因为它允许开发人员专注于最重要的事情，并自动化了开发过程中更平凡和重复的部分，从而减少了他们必须做出的决策的数量。

这些平台和AutoML系统封装最佳实践并简化部分ML过程的意图是非常值得赞赏的，但是可以有一种更好的、不那么单一的方式来考虑ML平台，它可以使这些平台的优势得以发挥，同时大大减少它们的问题，同时可以合并AutoML的优势。

挑战和站。我们在开发研究和工业ML项目和平台方面的经验使我们确定了一组它们大多数共同面临的挑战，以及一些理想的解决方案，这影响了我们开发声明式ML系统。

挑战1:爆炸指数决定。构建ML系统涉及到许多决策，所有决策都需要是正确的，在每个阶段都存在复合错误。

跨国项目1:良好的默认值和自动化。应该通过促使开发人员采用合理的默认值和可重复的自动化过程(例如，超参数优化)来减少决策的数量。

挑战2:新的model-itis。ML生产团队试图构建一个新的模型，但由于缺乏对以前模型的质量和故障模式的理解，未能提高性能。

跨国项目2:标准化，注重质量。ML过程的低附加值部分应该通过标准化的评估和数据处理以及自动化的模型构建和比较实现自动化，将注意力从编写低水平的ML代码转移到监控质量和改进监督上，将注意力从一维的基于性能的模型排行榜转移到整体评估上。

挑战3:组织的深渊。在管道中工作的团队之间存在差距，这使得共享代码和想法变得困难(例如，当实体消除歧义和意图分类的团队在一个虚拟助理项目中是不同的，不共享代码库，这导致了复制和技术债务)。

需要3:常见的接口。通过提供支持实现的模块化和互换性的标准接口，可以提高可重用性。

挑战四:缺乏专业知识。很少有开发人员能够编写低级ML代码，甚至在大公司中也是如此。

跨国项目4:更高级的抽象。开发人员不应该手动设置超参数或实现他们的定制模型代码，除非真的有必要，因为它只占项目生命周期的很小一部分，而且差异通常很小。

挑战5:缓慢的过程。由于需要多次迭代，在一些组织中ML项目的开发可能需要数月或数年才能达到预期的质量。

需要5:快速迭代。ML项目的质量通过结合从每次迭代中学到的东西来提高，所以每次迭代越快，在相同的时间内就能实现更高的质量。自动化和高级抽象的结合可以提高迭代的速度，进而帮助提高质量。

挑战6:许多不同的利益相关者。许多涉众都与ML项目的成功有关，他们具有不同的技能集和兴趣，但只有一小部分人有能力亲自操作系统。

需要6:利益的分离。使用多个用户视图实现利益分离将使堆栈中的更多人员能够访问ML系统，允许开发人员专注于交付价值和改进项目结果，而消费者可以更容易地利用所创建的价值。

回到顶部

声明式毫升系统

声明式ML系统可以通过实现大部分所需的功能来解决上述挑战。在大量关于ML模型和系统的文献中，这个术语可能被过度使用，因此在这里，声明性ML系统的定义仅限于那些将ML系统应该做什么和实际如何做之间进行分离的系统。的什么部分可以使用配置进行声明，根据其复杂性和组合性，可以将其视为声明性语言，并可以包含关于ML系统要解决的任务的信息和应该对其进行训练的数据的模式。这可以被认为是一种低/无/零代码的方法，因为声明性配置不是命令式语言如何，因此声明式ML系统的用户不需要知道如何实现ML模型或管道，就像编写SQL查询的人不需要知道数据库索引和查询计划一样。声明性配置被翻译/编译到一个可训练的ML管道中，该管道遵循所提供的模式，然后可以使用训练过的管道获得预测。

多年来已经提出了许多声明性ML方法，其中大多数使用逻辑或概率论，或两者都作为其主要声明性接口。这种方法的一些例子包括概率图形模型⁹以及他们对关系数据的扩展，如概率关系模型^5，12和马尔可夫逻辑网络²或纯逻辑表示，如Prolog和Datalog。在这些模型中，领域知识可以指定为变量(和关系)之间的依赖关系，表示模型的结构，它们的强度作为自由参数。自由参数和结构也可以从数据中得到。这些方法是声明性的，因为它们将规范语义从推理算法中分离出来。

然而，在这些模型上执行推断通常是困难的，可伸缩性成为一个主要挑战。比如Tuffy，¹⁴DeepDive,²¹为了解决这个问题，已经引入了其他方法。尽管如此，通过将推理与表示分离，这些模型在允许声明多任务和高度联合模型方面做得很好，但通常被更强大的特征驱动引擎(例如，基于深度学习的方法)所超越。这些声明性ML模型根据它们的作用域与系统区别开来;后者专注于以声明的方式定义整个生产ML管道。

其他潜在的高级抽象隐藏了ML管道部分的复杂性，它们有自己的优点，但我们不认为它们是声明性ML系统。此类抽象的例子可以是允许用户(ML开发人员)编写更简单的ML代码的库，免去了必须编写神经网络层实现(如Keras所做的)或必须编写可分发和可并行的for循环(如PyTorch Lightning所做的)的负担。其他抽象方法，如Caffe，允许通过声明其体系结构的层来编写深度神经网络，但它们是在一种接近命令式语言的粒度级别上进行的。最后，像Thinc这样的抽象为参数化模型提供了一个健壮的配置系统，但也需要编写可由配置系统参数化的ML代码，从而不分离什么从如何去做。

第一个数据。至少从20世纪90年代开始，集成数据挖掘和ML工具一直是几个主要研究和工业努力的重点。例如，2001年发布的Oracle的Data Miner以高级sql风格的语法为特色，以使用Java或通过PMML(预测模型标记语言)标准在外部定义的模型和支持的模型。这些模型是围绕用户定义函数的有效语法，用于执行过滤或推断。当时，ML模型是使用专门的求解器专门构建的，需要大量使用线性代数包(例如，L-BFGS是最流行的ML模型之一)。

然而，ML界开始意识到一种称为SGD(随机梯度下降)或增量梯度法的极其简单的经典算法可以用来训练许多重要的ML模型。俾斯麦项目⁴表明SGD可以利用数据库系统中已经广泛使用的现有数据处理原语(与SciDB相比，后者从线性代数的角度重新考虑了整个数据库)。

反过来，集成梯度下降及其变体使数据库管理系统能够管理训练。这导致了一种将训练和推理结合起来的新系统。他们提供SQL语法扩展，以声明式的方式训练模型，以管理数据库内部的训练和部署。俾斯麦，MADlib就是这样的例子⁶(Impalva、Oracle、Green-plum等都集成了它)和MLlib。¹¹Bismarck和MADlib中提出的SQL扩展仍然很流行，因为这种方法的变体集成在谷歌的大查询建模语言中¹⁷以及在SQLFlow等现代开源系统中。^20.

以数据为中心的观点的优点是使模型在数据所在的同一环境中可用，避免了潜在的复杂数据管道。出现的一个问题是，通过将模型训练公开为SQL中的原语，用户无法对建模过程进行细粒度控制。对于某些类型的模型来说，这是一个巨大的挑战，因为将数据传输到模型的痛苦(这些系统大大减少了)被执行特性化和调优模型的痛苦所取代。因此，许多模型存在于数据库之外。

第一个模型。在计算机视觉、语音识别和NLP(自然语言处理)的深度学习模型取得成功后，研究和行业的重点都转向了模型优先的方法，在这种方法中，训练过程更加复杂，并成为主要重点。反向传播和区分的错误实现将比数据预处理和深度学习算法在加速硬件(如gpu转换模型)上的高效计算更影响ML项目的性能，而gpu转换模型速度太慢，无法训练成特定ML问题的标准解决方案，特别是感知问题。在实践中，拥有一个高效的GPGPU(通用GPU)库包装器比通用的数据预处理管道更有价值。像TensorFlow和PyTorch这样的库专注于抽象复杂的底层C代码来进行张量计算。

这些库的可用性允许更简单的模型构建，因此研究人员和实践者开始共享他们的模型，并根据他们的目标调整其他人的模型。这种将预先训练好的模型中的(部分)转移到新的任务中并对其进行调整的过程开始于单词嵌入，但后来被应用于计算机视觉，现在像hugs Face的变形金刚这样的库使其变得更容易。

苹果内部构建的Overton和Uber的开源系统Ludwig都是模型优先的，专注于现代深度学习模型，但通过添加兴趣分离，它们也具有数据优先方法的一些特征(特别是声明性质)，而且它们都能够使用迁移学习。

简而言之，奥弗顿。欧¹⁶从本文开头所表达的相同观察结果中衍生出来:商品工具改变了ML的现状，现在可以构建能够将开发人员推向堆栈顶端的工具，允许用户专注于监管的质量和数量。Overton的设计目的是确保人们不需要在搜索、信息提取、问题回答、命名实体消除歧义和其他任务中为生产应用程序编写新的模型，同时使评估模型和通过摄入额外的相关数据来提高性能变得容易，从而在最终部署的模型上获得高质量的结果。

受关系数据库的启发，用户将声明一个描述传入数据源的模式有效载荷。此外，用户还将描述任务之间的高级数据流，可选地使用多个(弱)监督源，如图3，这是一个用于复杂NLP任务的Overton应用程序示例。左边是一段文本的示例数据记录，它的有效负载(输入、查询、标记化和候选实体)和任务(输出、词性、实体类型、意图和意图参数);中间是Overton模式，详细描述了输入的有效负载和输出的任务，以及它们各自的类型和参数;右边是一个调优规范，详细说明了Overton将从中选择和比较每个有效负载的粗粒度架构选项。

图3。复杂NLP任务的Overton应用实例。

该系统能够使用这些基本信息编译可训练的模型(包括数据预处理和符号映射);利用数据编程技术结合监督;¹⁵用张量流、PyTorch或Core ML编译模型;生产性能报告;最后在Core ML、张量流或ONNX(开放神经网络交换)中导出可部署模型。

一个关键的技术思想是，许多子问题，如体系结构搜索或超参数优化，可以用简单的方法来完成，例如粗粒度的体系结构搜索(只选择体系结构的类，而不是它们的所有内部超参数)或非常简单的网格搜索。用户可以覆盖其中的一些决策，但自定义选项在运行时没有进行大量优化。其他功能包括多任务学习、数据切片和使用预训练模型。

Overton用户的角色变成了监控绩效，通过增加新的实例提高监督质量，提供新的监督形式;他们不需要用低级ML代码编写模型。在苹果，奥弗顿负责搜索和问答应用程序的质量大幅提高(错误减少了40%到82%);因此，工程团队的工作空间大大减少，而且没有人编写低级的ML代码。

简而言之就是路德维希。路德维希¹³是一个允许其用户通过声明性配置构建端到端深度学习管道、训练它们并使用它们来获得预测的系统。管道包括将原始数据转换为张量的数据预处理、模型架构构建、训练循环、预测、数据后处理和管道评估。Ludwig还包括一个用于模型性能分析和比较的可视化模块，以及一个声明式超参数优化模块。

Ludwig的一个关键思想是，它将数据模式和任务抽象为数据类型特性接口，因此用户只需要定义输入和输出特性的列表，包括它们的名称和数据类型。这允许模块化和可扩展性:每次实例化包含文本特征的模型时，都重用相同的文本预处理代码和相同的文本编码体系结构代码，而例如，每次将集合特征指定为输出时，都采用相同的多标签分类代码进行预测和评估。

这种灵活性和抽象是可能的，因为Ludwig对其构建的深度学习模型的结构有自己的看法，遵循Molino等人介绍的ECD(编码器-组合-解码器)体系结构，¹³这允许轻松定义多模式和多任务模型，这取决于训练数据中可用的输入和输出的数据类型。ECD体系结构还定义了精确的接口，这极大地提高了代码重用和可扩展性:例如，通过强制设置图像编码器的输入和输出张量的尺寸，该体系结构允许图像编码的许多可互换实现(例如，卷积神经网络堆栈、剩余块堆栈或变压器层堆栈)，在配置中选择使用哪一个只需要更改一个字符串参数。

让路德维希一般是,这取决于类型的输入和输出的组合配置中声明,儿童早期开发的特定模型实例化架构解决了一个不同的任务:一个文本输入和输出级将路德维希编译一个文本分类架构,而图像输入和文本输出将导致一个image-captioning系统,图像和文本输入的文本输出会导致视觉问题模型。此外，基本的Ludwig配置很容易编写，并且隐藏了构建深度学习模型的大部分复杂性，但与此同时，它们允许用户指定架构、训练循环和预处理的所有细节，如果他们愿意的话。

图4展示了Ludwig配置的三个例子:(a)一个简单的文本分类器，它包含关于分类消息的作者的附加结构化信息;(b)图像字幕示例;(c)模型的详细配置，根据书名和销售数字，预测其用户评分和标签。A和B显示了简单的配置，而C显示了每个编码器、合成器和解码器的控制程度，以及训练和预处理参数，同时还强调了Ludwig如何支持每一个可能的配置参数的超参数优化。陈述式超选择部分显示在图4 (c)使架构、培训和预处理决策自动化成为可能。

图4。路德维希构型的三个例子。

最后，Ludwig既是一个模块化的系统，也是一个端到端系统:内部是高度模块化的，允许Ludwig开发人员添加选项、改进现有选项和重用代码，但从Ludwig用户的角度来看，它完全是端到端(包括处理、培训、hyperopt和评估)。

相似点和不同点。尽管Overton和Ludwig是完全独立开发的，但它们都采用了相似的设计决策——特别是采用了声明性配置，该配置包括(尽管语法不同)输入数据模式和Overton中模型应该解决的任务的概念，以及Ludwig中输入和输出特性的类似概念。两个系统都有与数据相关联的类型的概念，这些类型通知了它们所构建的管道的各个部分。

这两个系统的不同之处在于一些假设、一些功能和它们的重点。Overton更关心以各种格式编译模型的能力——特别是用于部署的模型——而Ludwig只有一条生产路线。Overton还允许以更明确的方式定义与数据相关的方面，如弱监管和数据切片。另一方面，由于ECD体系结构的组合性，Ludwig覆盖了更广泛的用例，其中输入和输出的不同组合可以定义不同的ML任务。

尽管存在差异，但这两个系统都解决了本文前面强调的一些挑战。这两个系统都促使开发人员通过自动化生命周期的一部分来做出更少的决策(需求1)，并通过提供体系结构的标准实现和评估(也可以以更全面的方式组合在一起)来重用已经对他们可用的模型并彻底分析它们(需求2)。

在这两个系统中，数据类型的接口和使用以及相关的高级抽象(需求4)有利于代码重用(需求3)并解决专业知识的稀缺性。声明性配置提高了模型迭代的速度(需求5)，因为开发人员只需要更改声明中的细节，而不是使用级联效果重写代码。这两个系统还部分地提供了利益分离(需求6):它们将添加新模型、类型和特性的系统开发人员与使用声明性接口的用户分离开来。

回到顶部

下一个是什么?

科技公司在现实场景中采用奥弗顿和路德维希的做法表明，它们至少在解决这些公司面临的一些具体问题。通过将它们的优势与声明性ML系统的数据优先时代的更紧密的数据集成结合起来，可以挖掘出更多的价值。最近的这一波深度学习工作表明，使用相对简单的构建块和AutoML，对训练和调优过程的精细控制可能不再是必要的，从而解决了数据优先方法没有解决的主要痛点，并为向无缝集成模型训练、推断和数据的新、更高级别系统的融合打开了大门。

在这方面，可以从计算的历史中吸取教训，通过观察导致通用系统取代定制解决方案出现的过程:

的用户数量。ML不仅需要被更广泛地采用，而且需要被没有任何编码技能的人开发、培训、改进和使用，甚至需要更高级别的抽象。再拿数据库系统做一个类比，我们仍然处于ML的COBOL时代;正如SQL允许大量的人编写数据库应用程序代码，同样的情况也会发生在ML上。

显式的用户角色。并不是每个与未来的ML系统交互的人都将接受ML、统计学甚至计算机科学方面的培训。正如数据库发展到实现更快算法的数据库开发人员、管理实例安装和配置的数据库管理员、编写应用程序代码的数据库用户和获得对其请求的快速响应的最终用户之间存在明显的分离一样，这种角色分离预计将出现在ML系统中。

性能优化。更抽象的系统倾向于在表达性或性能方面做出妥协。路德维希实现了最先进的技术，奥弗顿取代了生产系统，这表明这可能已经是一个错误的权衡。编译器的历史表明了一个类似的模式:随着时间的推移，优化的编译器通常可以击败手工调优的机器代码内核，尽管任务的复杂性可能在一开始就表明了相反的情况。这一方向的发展将导致定制的解决方案，该解决方案可能仅限于组织内(不断增长的)ML任务长尾中较长部分的高度特定的任务，在这些任务中，即使是微小的改进也很有价值，类似于今天的任务关键用例，其中可能需要编写程序集代码。

系统和库之间的共生关系。未来可能会有更多的ML库，它们将与ML系统共存，并以良性循环的方式帮助改进ML系统。在计算的历史上，这种情况发生了一次又一次;最近的一个例子是，像Apache Lucene这样的全文索引库的出现填补了当时大多数dbms的功能空白，Lucene首先被用于定制应用程序，后来被用作完整搜索系统的基础，如Elasticsearch和Apache Solr，最后被集成到dbms中，如OrientDB、GraphDB和其他。声明式ML系统仍面临一些挑战:它们必须证明自己在未来研究中对机器学习的变化是稳健的，支持不同的训练方案，并表明它们所代表的任务类型包含了很大一部分实际用途。这件事还没有定论。

当技术能够被更多的人利用，而不是那些能够创造它们的人使用时，技术就会改变世界，因此我们相信，机器学习的未来及其对每个人生活的影响最终取决于我们将其交到其他人手中的努力。

回到顶部

致谢

作者要感谢Antonio Vergari, Karan Goel, Sahaana Suri, Chip Huyen, Dan Fu, Arun Kumar和Michael Cafarella的深刻评论和建议。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2022 ACM, Inc.

---

没有发现记录