全文共2660字，预计学习时长10分钟

 

图源：unsplash

 

大约一年前我们已经开始在开源机器学习平台Cortex上工作了，动机很简单：从模型中构建应用程序实在是一种可怕的体验，充满了胶水代码（gluecode）和样板代码（boilerplate code），所以我们需要一个能把它抽象化的工具。

 

我们在Cortex上的研究代表了过去一年来加速趋势的一部分，即机器学习工程生态系统的发展。公司雇佣机器学习工程师的速度比以往任何时候都要快，发布的项目也越来越好。

 

这让我们感到很兴奋。但有一个问题仍然时常出现：“什么是机器学习工程？”本文将带你找到答案，以及为机器学习工程师构建一个平台意味着什么。

 

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

 

先从更多人熟悉的数据科学的背景来定义机器学习工程。我试着给数据科学下了一个定义：

 

· 从广义上讲，数据科学是一门应用科学过程从数据中获得见解的学科

· 机器学习工程是一门用机器学习构建应用程序的学科

 

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

 

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

 

为了让这两者之间的区别更加具体，最好从一个实际项目中分析机器学习工程师与数据科学家的职责和需求。

 

图源：unsplash

 

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

 

Compose

 

Gmail的Smart Compose是生产机器学习最普遍的例子之一，它巧妙地阐明了机器学习工程的挑战。想象一下如果要开发Smart Compose该怎么做？

 

首先，确定约束范围，根据Gmail的描述，这些约束包括：

 

· Smart Compose需要与Gmail编辑器的用户界面集成；

· 预测需要在小于100毫秒的时间内提供给Gmail编辑；

· Smart Compose需要扩展到Gmail的14亿用户。

 

这些约束中唯一与数据科学紧密相关的是延迟需求。

 

训练一个足够准确、快速的模型，实际上就是一个非常有趣的数据科学问题，团队通过设计一个混合模型解决了这个问题，该混合模型牺牲了很小的准确性度，却在速度方面获得了巨大的提高。

 

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

 

1. 定义一个架构

 

图源：unsplash

 

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

 

· 模型太大，无法在本地部署到客户端；

· 相对而言，推理的计算成本昂贵；

· 再次强调，Gmail有14亿用户。

 

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

 

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

 

2. 扩展一个模型微服务

 

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

 

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

 

· 将微服务容器化；

· 将其部署到用于推理的Kubernetes集群；

· 将其公开为负载平衡器背后的web服务组合。

 

图源: Cortex部署架构

 

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

 

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

 

3.实现目标延迟

 

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

 

为了将延迟降低到小于 100 毫秒需要改进硬件，他们使用的是张量处理单元（TPU），一种由谷歌开发的用于机器学习的特定用途集成电路（ASIC），而不是中央处理器。在张量处理单元上，平均延迟降至10毫秒左右。

 

尽管这在概念上很简单，但实现起来却相当困难。部署到像谷歌的张量处理单元或亚马逊的Inferentia之类的特定用途集成电路，需要进行相当多的配置。例如，我们最近在Cortex内部开发了Inferentia的支持，我们面临两个挑战：

 

· 为了在Inferentia实例上为模型提供服务，Cortex需要和AWS的Neuron API集成。Neuron是用来编译模型的引擎，这些模型在Inferentia的“NeuronCores”上运行，并从编译后的模型中提供预测。

 

· 默认情况下，Kubernetes不会将Inferentia（或任何特定用途集成电路）识别为资源，我们必须找到一个设备插件来允许Kubernetes与Inferentia一起使用。Inferentia设备插件非常新，目前处于beta测试阶段，我们花了很多时间来设计一个稳定的集成。

 

建立这一切至少需要一个人长期投入自己全部的时间，且同时还需要他人的帮助。对于任何团队来说，在内部进行这样的实验，看它是否能够充分降低延迟，这都是一种冒险的资源消耗，但却也是必须要进行的任务。

 

图源：unsplash

 

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

 

现在，你是不是会觉得大多数问题都是软件工程问题，架构系统、编写API、配置云基础架构等等，所有这些都不是纯粹的机器学习工作。不不不，所有的这一切，都还是机器学习特有的。

 

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

 

换句话说，数据科学工作流从数据中产生见解，强调比起生产更有利于实验的工具，如Notebooks；而软件工程工作流一直以生产为中心，而不是特定于机器学习。

 

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

 

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

 

图源：unsplash

 

数据科学永远是推动前沿的力量，而机器学习工程则是连接实验室中的可能和生产中的实际之间的桥梁。二者关注点不同但却有万千联系，交叉联合，未来有无限潜能。

 

一起分享AI学习与发展的干货

欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）