本文最初发表在 Towards Data Science 博客上，经原作者 Caleb Kaiser 授权，InfoQ 中文站翻译并分享。

导读：如果将机器学习工程理解为一门学科的话，那么这个问题就迎刃而解了：为什么我们建立了机器学习工程平台而非数据科学平台？

大约一年前，我们中的一些人开始研究开源机器学习平台 Cortex。我们的动机很简单：鉴于从模型中构建应用程序是一种可怕的体验，充满了胶水代码和样板，我们需要一个工具，能将这些都予以抽象化。

虽然我们对自己在 Cortex 上的工作感到非常自豪，但我们只是过去一年来加速趋势的一部分，那就是机器学习工程生态系统的发展。公司雇佣机器学习工程师的速度比以往任何时候都要快，发布的项目也越来越好。

尽管这让我们感到很兴奋，但我们仍然经常听到这样一个问题：“什么是机器学习工程？”

在本文中，我想为读者们解释什么是机器学习工程，以及为机器学习工程师构建一个平台意味着什么。

什么是机器学习工程？为什么它不是数据科学？

让我们先从更多人熟悉的数据科学的背景来定义机器学习工程。

要给数据科学下一个定义，还不会让人愤怒评论，这很难，但我还是会试着下一个定义：

从广义上讲，数据科学是一门应用科学过程从数据中获得见解的学科。
机器学习工程是一门利用机器学习构建应用程序的学科。

显然，这里有很多重叠之处。两者都是封装了机器学习的学科。不同之处主要在于目标。顾名思义，数据科学是一门科学，而机器学习工程是一门工程学科。

这种区别在大多数学科中都存在。想一想生物学和生物医学工程。工程学科显然离不开科学家的工作：机器学习工程是建立在数据科学的工作基础上，但工程学是科学应用于世界的方式。

为了让这两者之间的区别更加具体，我们可以思考一个实际项目，并分解机器学习工程师与数据科学家的职责和需求，是有所帮助的。

从数据科学和机器学习工程的角度来看 Gmail 的 Smart Compose

Gmail 的 Smart Compose（智能撰写）是生产机器学习最普遍的例子之一，就我们的目的而言，它巧妙地阐明了机器学习工程的挑战。

让我们想象一下开发 Smart Compose。首先，我们要确定约束范围，根据 Gmail 的描述，这些约束包括：

Smart Compose 需要与 Gmail 编辑器的用户界面集成；
预测需要在小于 100 毫秒的时间内送达 Gmail 编辑器；
Smart Compose 需要扩展到 Gmail 的 14 亿用户。

这些约束中唯一涉及数据科学的是延迟需求。

训练一个足够准确和快速的模型，实际上是一个非常有趣的数据科学问题，团队通过设计一个混合模型解决了这个问题，该混合模型在准确性方面做出了很小的牺牲，但却在速度方面获得了巨大的提高（我建议读者们阅读完整的报告）。

以数据科学家的创新为基础，机器学习工程师现在必须采用这种模型，并将其转化为 Smart Compose。他们采用的方法是任何软件工程师都熟悉的：

1. 定义架构

这个模型应如何与 Gmail 客户端集成？需要考虑的有以下几点：

模型过大，无法在本地部署到客户端；
相对而言，推理的计算成本昂贵；
Gmail 有 14 亿用户。

在这种情况下，最好的方法是做成微服务架构，在这种架构中，模型作为 Web API 进行部署，可以由 Gmail 客户端查询。这样，推理的计算开销就可以与应用程序的其他部分隔离开来，并且服务可以横向扩展。

然而，在这种架构中也存在一些挑战。

2. 扩展模型微服务

在白板上绘制这种“模型即微服务”（model-as-a-microservice）架构很直观，但实际上，要实现它却是一项挑战。就背景而言，将这一过程自动化是我们构建 Cortex 的核心动机。

Gmail 团队并没有分享他们的推理基础设施的细节，但行业标准的做法是：

将微服务容器化；
将其部署到用于推理的 Kubernetes 集群；
将其公开为负载平衡器背后的 Web 服务。

来源：Cortex 部署架构

除此之外，还有一系列基础设施的问题需要解决。Kubernetes 需要与设备插件集成才能识别 GPU/ASIC，这可能会带来自动缩放的问题。另外还需要监控模型性能。更新需要在不会使 API 崩溃的情况下进行。

构建所有这些云基础设施需要将许多不同的工具融合在一起：Docker、Kubernetes、云服务、Web 框架、服务库等等。在软件工程师向机器学习工程师过渡的过程中，这是最让我们感到沮丧的一步，但也是我们构建 Cortex 来实现自动化的一步：

来源：Cortex 仓库

3. 实现目标延迟

即使使用可扩展的模型进行部署，但延迟仍然是一个问题。Gmail 团队开发的混合模型速度很快，但微服务仍然有“几百毫秒”的平均延迟。

为了将延迟降低到小于 100 毫秒，他们需要改进硬件。具体来说，他们使用的是 TPU，一种由 Google 开发的用于机器学习的 ASIC（特殊应用集成电路），而不是 CPU。在 TPU 上，平均延迟降至 10 毫秒左右。

尽管这在概念上很简单，但实际实现起来相当困难。部署到像 Google 的 TPU 或 Amazon 的 Inferentia 之类的 ASIC，需要进行相当多的配置。

译注：TPU （ tensor processing unit，张量处理器）是 Google 为机器学习全定制的人工智能加速器专用集成电路，专为 Google 的深度学习框架 TensorFlow 而设计。Inferentia 是一个由 AWS 定制设计的机器学习推理芯片，旨在以极低成本交付高吞吐量、低延迟推理性能。Inferentia 将支持 TensorFlow、Apache MXNet 和 PyTorch 深度学习框架以及使用 ONNX 格式的模型。 Inferentia 可以与 Amazon SageMaker、Amazon EC2 和 Amazon Elastic Inference 一起使用。ASIC 是特殊应用集成电路（Application-specific integrated circuit），指依产品需求不同而客制化的特殊规格集成电路；相反地，非客制化的是应用特定标准产品（Application-specific standard product）集成电路。

例如，我们最近在 Cortex 内部开发了 Inferentia 的支持，并面临两个挑战：

为了在 Inferentia 实例上的模型提供服务，Cortex 需要与 AWS 的 Neuron API 集成。Neuron 是用来编译模型的引擎，这些模型在 Inferentia 的“NeuronCores”上运行，并从编译后的模型提供预测。
默认情况下，Kubernetes 不会将 Inferentia（或任何 ASIC）识别为资源。我们必须找到一个设备插件来允许 Kubernetes 与 Inferentia 一起使用。Inferentia 设备插件非常新，目前还处于 beta 测试阶段，因此我们花了很多时间来设计一个稳定的集成。

然而，建立这一切至少需要一个贡献者的长期的、全职的工作，并得到其他人的帮助。对于任何团队来说，必须在内部进行这样的实验，看看它是否能够充分降低延迟，这都是一种冒险的资源消耗。

为什么软件工程和数据科学的交叉如此激动人心

看完所有这些内容后，你可能会觉得，大多数问题都是软件工程问题。架构系统、编写 API、配置云基础架构等等，所有这些都不是纯粹的机器学习工作。

不过，所有的这一切，都还是机器学习特有的。

为部署的模型配置自动缩放，在概念上类似于为任何微服务做同样的事情，但由于推理的特殊性，它需要不同的资源和方法。同样的，用 Python 编写一个 REST API 对大多数软件工程师来说都很熟悉，但编写一个使用 top-k 过滤来解析模型预测的 REST API 却是一个机器学习特有的任务。

换句话说：

数据科学工作流从数据中产生见解，强调有利于实验而不是生产的工具，如 Notebooks。
另一方面，软件工程工作流一直以生产为中心，而不是特定于机器学习。

由于两者之间存在的差距，历来很少有团队能够将模型部署到生产中。机器学习工程填补了这一空白，随着生态系统的成熟，越来越多的团队能够使用模型来构建软件。

非营利组织可以使用图像分类实时抓捕偷猎者。独立工程师可以开发人工智能驱动的视频游戏。两人初创公司可以使用机器学习来“颠覆”电子商务物流。一个小团队可以在资金很少的情况下在美国多个城市推出机器学习驱动的癌症筛查。

数据科学永远是推动前沿的力量，而机器学习工程则是连接实验室中的可能和生产中的实际之间的桥梁。

作者介绍：

Caleb Kaiser，Cortex Lab 创始团队成员，曾在 AngelList 工作，最初在 Cadillac 供职。

原文链接：

https://towardsdatascience.com/why-we-built-a-platform-for-machine-learning-engineering-not-data-science-54004d5b6e95

创作场景

为什么我们建立机器学习工程平台，而不是数据科学平台？