未来，机器学习所需的工程量会大大减少

未来，构建 ML 产品将更加有趣，并且这些系统会工作得更好。随着 ML 自动化工具的不断改进，数据科学家和 ML 工程师将把更多的时间花在构建优秀的模型上，而花在与生产级 ML 系统相关的繁琐但必要的任务上的时间会更少。

本文最初发布于KDnuggets，经原作者授权由 InfoQ 中文站翻译并分享。

AI是一个系统工程问题。

构建一个有用的机器学习产品需要创建大量的工程组件，其中只有一小部分涉及 ML 代码。构建生产级 ML 系统涉及到很多工作，比如构建数据管道、配置云资源和管理服务基础设施。

传统上，ML 的研究主要集中于创建更好的模型，推动语言建模和图像处理等领域前沿技术的发展。很少有人在系统层面关注设计和实现生产级 ML 应用程序的最佳实践。尽管得到的关注较少，但是 ML 系统层面的设计和工程挑战仍然非常重要——创建有用的东西比构建良好的模型需要的东西更多，它需要构建良好的系统。

真实世界的 ML

2015 年，谷歌的一个团队绘制了下面这幅图：

它显示了真实世界的 ML 系统中专门用于建模的代码量（小黑框）与 ML 应用程序的支撑设施和管道所需的代码的比较。这张图表并没有多么令人惊讶。对于大多数项目来说，构建一个生产系统所涉及到的大多数令人头痛的问题并不是来自典型的 ML 问题，如过拟合或欠拟合，而是来自于在系统中构建足够的结构以使模型可以按预期工作。

生产级 ML 系统

构建一个生产级 ML 系统可以归结为构建一个工作流——从数据摄取到模型服务的一系列步骤，其中每个步骤前后串联，并且足够健壮，可以在生产环境中运行。

工作流从一些数据源开始，包括创建模型端点所需的所有步骤——输入数据预处理、特征工程、训练和评估模型、将模型推送到服务环境，以及在生产环境中持续监控模型端点。

这个工作流中的特征工程>训练>调优部分通常被认为是机器学习的“艺术”。对于大多数问题，特征设计、模型架构构建和超参数调整，都有许许多多的方法，以至于数据科学家/ML 工程师只能依赖于直觉和实验的混合。建模过程也是机器学习的一个有趣部分。

建模与工程

在不同的应用场景和问题域中，这个建模过程都会有所不同。如果你训练一个模型在 Netflix 上推荐内容，这个建模过程与你为客户服务构建聊天机器人会有很大的不同。不仅底层数据的格式会不同（稀疏矩阵 vs 文本），而且预处理、模型构建和调优步骤也会有很大的不同。但是，尽管建模过程在跨应用场景和问题域时基本上都是特有的，但工程上的挑战很大程度上是相同的。

无论你将哪种类型的模型投入生产，围绕该模型构建生产工作流的工程挑战在很大程度上是相同的。

这些跨 ML 领域的工程挑战的同质性是一个巨大的机会。在未来（大部分是现在），这些工程挑战将在很大程度上实现自动化。将 Jupyter Notebook 中创建的模型转换成生产级 ML 系统的过程将变得更加容易。不需要创建专门的基础设施来解决这些挑战，数据科学家/ML 工程师已经使用的开源框架和云服务将在底层自动实现这些解决方案。

大规模数据摄取

所有生产级 ML 工作流都从一个数据源开始。通常，与数据来源相关的工程挑战是围绕大规模数据摄取展开的——我们如何从各种数据来源导入和预处理数据集，因为这些数据及太大，无法装入内存。

开源机器学习框架通过开发数据加载程序，在很大程度上解决了这个问题。这些工具（包括 TensorFlow 的tf.data API和 PyTorch DataLoader库）将数据分段加载到内存中，并且几乎可以用于任何大小的数据集。它们还提供动态特征工程，并且可以扩展到生产环境。

加速模型训练

ML 社区做了大量的工作来减少训练大型模型所需的时间。对于大型训练工作，通常会将训练工作分配给一组机器（训练集群）。还有一种常见的做法是使用专门的硬件（GPU 和现在的 TPU）来进一步减少训练模型所需的时间。

传统上，在多台机器和设备上分配训练操作需要修改模型代码，这并不简单。为了能真正获得使用机器集群和专用硬件所带来的效率提升，代码必须针对每个训练步骤智能地分割矩阵操作并合并参数更新。

现代工具使这个过程变得更加容易。TensorFlow Estimator API从根本上简化了将模型代码配置为在分布式集群上进行训练的过程。使用 Estimator API，设置一个参数就可以将训练图自动分布到多台机器/设备上。

像AI Platform Training这样的工具能够提供随需应变的资源供应，实现分布式集群上的模型训练。可以使用bash shell命令为训练作业提供多种机器和设备类型（高性能 CPU、GPU 设备、TPU）。

可移植、可扩展、可重复的 ML 实验

创建一个既能实现快速原型设计又能够标准化实验过程的环境会面临一连串的工程挑战。

如果没有一个清晰的方法来重复过去的实验，并将模型元数据（参数值）与观察到的评估指标关联起来，超参数调优（更改模型参数的值以降低验证错误）的过程就不可靠。快速迭代和高效运行实验的能力需要分布式和硬件加速器支持下的大规模训练。此外，如果 ML 代码不可移植，实验过程将变得不可管理——其他团队成员/涉众无法复制实验，并且随着新数据的出现，生产中的模型也无法重新训练。

就我个人而言，我在团队中为AI Hub构建容器，我们正在努力帮助解决这些挑战。我们将 ML 算法（XGBoost、ResNet等）的高性能实现构建为 Docker 容器。容器提供了对 AI 平台的原生支持，并且会默认保存模型元数据，提供了一个可重复的过程来运行实验。这些容器支持分布式训练，可以在 GPU 或 TPU 设备上运行。它们还具有可移植性——只要安装了 Docker，容器就可以在任何地方由任何人运行。

服务基础设施

生产级 ML 系统两端的规模都很大：大规模的数据摄取和模型训练，以及大规模的模型服务。一旦一个模型被训练过，它就必须被导出到一个环境中，用来生成推断。正如消费者网站需要处理 Web 流量的巨大波动一样，模型端点也必须能够处理预测请求的波动。

像AI Platform Prediction这样的云工具为模型服务提供了一个可扩展的解决方案。云服务的弹性特性允许服务基础设施根据预测请求的数量伸缩。这些环境还允许对模型进行持续监控，并且可以编写测试过程来检查模型在生产过程中的行为。

未来更好的 ML 系统

未来，构建 ML 产品将更加有趣，并且这些系统会工作得更好。随着 ML 自动化工具的不断改进，数据科学家和 ML 工程师将把更多的时间花在构建优秀的模型上，而花在与生产级 ML 系统相关的繁琐但必要的任务上的时间会更少。