部署机器学习非常困难，并将一直如此...

AI科技评论

发布于 2019-11-26 16:15:52

3810

发布于 2019-11-26 16:15:52

文章被收录于专栏：AI科技评论

作者 | Alexandre Gonfalonieri 翻译 | MrBear 编辑 | 唐里

机器学习技术正在令我们的生活发生日新月异的变化。对于学术界来说，科研人员的工作往往止步于原型算法的研制。然而，在真实的工业生产场景下，将原型机器学习算法部署到应用程序中又是一项充满挑战的课题。

经手过一些人工智能项目后，我意识到：对于希望通过人工智能创造价值的公司来说，大规模地部署机器学习（ML）模型是最重要的挑战之一。如今，随着模型变得越来越复杂，这只会变得越来越难。

根据我作为顾问的经验，我发现只有很小一部分机器学习项目能够被成功投入生产。人工智能项目失败的原因有很多，而「难以部署」就是其中之一。对于每个决策者来说，充分理解项目部署的内在机制，以及如何降低在达到这个关键步骤时失败的风险是至关重要的。

我们可以将部署的模型定义为任意被无缝集成到生产环境中的代码单元，它可以接收输入并返回一个输出结果。

我所看到的是，为了使他们的工作能够被投入生产，数据科学家通常必须将他们的数据模型的构建工作移交给工程实现部分。正是在这一步中，出现了一些最为常见的数据科学问题。

一、挑战

机器学习有一些独特的特性，使其大规模部署更加困难。这也正是我们当前正在处理的一些问题：

1、数据科学语言管理

如你所知，机器学习应用程序通常由不同编程语言编写的元素组成，而这些元素往往不能很好地进行交互。我总是能发现类似这样的情况：在一个机器学习应用的工作流程中，可能开始使用的是 R 语言，接着则转而使用 Python，最终又使用了另一种语言。

一般而言，对于机器学习应用来说，Python 和 R 是目前最流行的语言。但是我注意到，出于各种原因（包括运行速度），用于生产的模型很少使用这些语言进行部署。然而，将 Python 或 R 语言编写的模型移植到 C++ 或 Java 这种生产环境下常用的语言是十分复杂的，通常会降低原始模型的性能（运行速度、准确率，等等）。

当软件的新版本出现时，R 的程序包很可能会崩溃。此外，R 的运行速度也很慢，无法高效处理大数据。

R 是一种很好的原型开发语言，因为它使我们可以进行简单的交互和问题求解，但是在生产环境下则需要将其转换为 Python、C++ 或 Java。

容器化技术（Containerization，例如 Docker），可以解决由于工具类型繁多而引发的不兼容性问题和可移植性的挑战。然而，自动依赖检查、误差检查、测试以及不同的构建工具这些问题则无法跨越语言障碍得以解决。

复现性也是一个巨大的挑战。事实上，数据科学家可以使用不同的编程语言、程序库或同一种程序库的不同版本来构建各个版本的模型。想要手动跟踪这些依赖是很困难的。为了解决这些挑战，我们需要一个机器学习生命周期工具，它可以在训练阶段自动跟踪并且以配置代码的形式记录这些依赖，然后将它们与训练好的模型捆绑在一个待部署的组件中。

我建议你使用能够将代码从一中语言即时转换为另一种语言的工具，或者使你的数据科学团队能够使用某种 API 部署模型，以便这些模型在任何地方集成。

2、算力和 GPU

现代神经网络往往非常深，这意味着训练和使用它们进行推理需要耗费大量的算力。通常，我们希望我们的算法能够快速运行，而这对于很多用户来说这可能是一大障碍。

此外，现在许多生产环境下的机器学习系统都依赖于 GPU。然而，GPU 既稀缺又昂贵，这很容易使机器学习的大规模部署变得更加复杂。

3、可移植性

模型部署的另一个有趣的问题是缺乏可移植性。我注意到，这往往是历史遗留的分析系统所造成的问题。由于没有能力轻松地将软件组件移植到另一种主机环境下并在那里运行它，这种软件组合可能会被限制在一个特定的平台上。这回给数据科学家在创建和部署模型时设置障碍。

4、可扩展性

对于许多人工智能项目来说，可扩展性是一个很现实的问题。实际上，你需要确保你的模型能够进行扩展，并且满足生产中对性能和应用程序需求的增加。在项目的开始阶段，我们通常依赖于可管理规模的相对静态的数据。随着模型向生产环境不断变化，它通常需要面对更大量的数据和数据传输模式。你的团队将需要多种工具来监管并解决性能和可扩展性方面的挑战，随着时间的推移，这些挑战将会显现出来。

我相信，通过采用一致的、基于微服务的方法进行生产分析，可以解决可扩展性的问题。团队应该能够通过简单的配置更改，快速地将模型从批处理按照需求迁移到流处理模式下。类似地，团队应该有扩展计算和内存占用的选项，以支持更复杂的工作负载。

5、在极限状态下进行机器学习计算

当你的算法被训练好后，他们并不总是会被立刻使用，你的用户只会在他们需要的时候调用这些算法。

这意味着，也许在上午 8 点时你只要支持 100 次 API 调用，但是到了 8 点半这一数值猛增到了 10,000 次。

根据我的经验，我可以告诉你，要想在确保不为你不需要的服务付费的情况下，扩大和缩减部署规模都是一个巨大的挑战。

由于上述这些原因，只有很少的数据科学项目最终真正落地到了生产系统中。

二、提升鲁棒性使模型可以运行

我们往往需要花费大量的时间试图使我们的模型准备就绪。提升模型的鲁棒性包括获取原型并准备它，从而使它实际上能够为所涉及的用户服务，这通常需要大量的工作。

许多情况下，我们需要使用适合现有架构的语言重新编码整个模型。仅这一点往往就会带来大量痛苦的工作，导致部署工作推迟好几个月。一旦完成，它必须被集成到公司的 IT 架构中，包括之前讨论过的所有程序库的问题。此外，在生产环境下访问数据往往是一项困难的任务，这些数据往往承受着数据仓库的技术上和组织上的负担。

三、其它的挑战

在我经手过的项目中，我还注意到以下问题：

如果我们改变了一个输入特性，那么剩余特性的重要性、权值或用途都可能改变，也可能不改变。机器学习系统必须要被设计地能够方便地跟踪特性工程和选择的变化。
当模型不断地迭代并微妙地变化时，在保持配置的清晰性和灵活性的同时跟踪配置的更新成为了一个新的负担。
一些数据输入可能会随着时间而改变。我们需要一种方法来理解和跟踪这些变化，以便能够充分理解我们的系统
在机器学习应用程序中会出现一些传统的单元测试/集成测试无法识别的问题。例如，部署错误版本的模型，遗漏某个特征，以及在过时的数据集上进行训练。

四、测试和验证的问题

正如你可能已经知道的那样，由于数据变更、使用新的方法等原因，模型会不断地演进。因此，每次发生这样的变更时，我们都必须重新验证模型的性能。这些验证步骤带来了如下挑战：

必须使用相同的测试集和验证集来评价模型，从而对比不同机器学习模型的性能。
如果我们更新了测试集和验证集合，为了保证可比性，就需要对不同的机器学习模型重新进行评价。这使得在生产环境下自动训练并部署新版本的机器学习模型的过程变得更加困难。
为了保证可比性，在不同的时间和不同的模型上，对于度量指标应该使用相同的代码。
对于某种新的模型来说，性能的提升可能也会带来预测时间的增长。为了体现出这种影响，验证过程应该包括基准对比测试和负载/压力测试。

除了在离线测试中验证模型之外，在生产环境下评估模型性能也十分重要。通常我们在部署策略和监管部分对此进行规划。

机器学习模型需要比常规软件应用更频繁地更新。

自动化的机器学习平台

你们可能对自动化机器学习平台有所耳闻，这可能是用来更快地创造模型的一个很好的解决方案。此外，这样的平台还可以支持多个模型的开发和比较。因此企业可以选择最适合他们对于预测准确率、计算延迟和计算资源需求的模型。

多达 90% 的企业级机器学习模型可以通过自动化的方式开发。数据科学家们可以与业务人员合作，开发目前自动化方法无法实现的小部分模型。

许多模型都会遭受「模型漂移」（性能随着时间推移而下降）的问题。因此，我们需要对部署后的模型进行监管。每个部署后的模型应该记录所有的输入、输出和异常。模型部署平台需要提供日志存储和模型性能可视化功能。密切关注模型的性能是有效管理机器学习模型生命周期的关键。

必须通过部署平台监管的关键要素

五、发布策略

探索各种不同的方法来部署软件（这是一个值得长期学习的课题，可参考资料：https://medium.com/@copyconstruct/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e），通过「影子模式」和「金丝雀模式」（注：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为「瓦斯检测指标」，以便在危险状况下紧急撤离。）部署机器学习应用程序是十分有效的。

在「影子模式」中，你可以获知生产环境下的新模型的输入和预测结果，而实际上并没有基于这些预测展开服务。相反，你可以自由地分析结果，如果检测到一个 bug 也不会造成重大的后果。

随着架构的逐步成熟，你可以开始启用这个渐进或「金丝雀模式」的发布策略。在这里，你可以向一小部分客户发布应用，而不是「全部都发布」或者「什么都不发布」。这样做需要更成熟的工具，但是当错误发生时，可以将损失降到最小。