为什么机器学习部署起来这么难？

作者：Alexandre Gonfalonieri 编译：ronghuaiyang

导读

根据我作为顾问的经验，只有非常少的机器学习项目能够投入生产。一个人工智能项目可能会因为多种原因而失败，其中之一就是部署。

在做了几个人工智能项目之后，我意识到，对于那些愿意通过人工智能创造价值的公司来说，大规模部署机器学习(ML)模型是最重要的挑战之一。

根据我作为顾问的经验，只有非常少的机器学习项目能够投入生产。一个人工智能项目可能会因为多种原因而失败，其中之一就是部署。对于每个决策者来说，完全理解部署是如何工作的，以及在达到这一关键步骤时如何降低失败的风险是非常关键的。

部署的模型可以定义为无缝集成到生产环境中的任何代码单元，并且可以接收输入并返回输出。

我曾经看到，为了将他们的工作投入生产，数据科学家通常必须将他或她的数据模型进行工程实现。在这一步中，出现了一些最常见的数据科学问题。

挑战

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

管理数据科学语言

你可能知道，机器学习应用程序通常由使用不同的编程语言编写组成。它们之间的相互作用并不是很好。我曾多次看到，机器学习pipeline从R开始，在Python中继续，并以另一种语言结束。

一般来说，Python和R是机器学习应用程序中最流行的语言，但我注意到，由于各种原因(包括速度)，很少使用这些语言部署生产模型。将Python或R模型移植到像c++或Java这样的生产语言中是很复杂的，并且通常会降低原始模型的性能(速度、准确性等)。

当软件的新版本发布时，R包可能会崩溃。此外，R速度慢，无法高效地处理大数据。

对于原型设计来说，它是一种很棒的语言，因为它允许简单的交互和解决问题，但是需要将它翻译成Python或c++或Java来进行生产。

诸如Docker之类的容器化技术可以解决由大量工具引入的不兼容性和可移植性挑战。然而，自动依赖项检查、错误检查、测试和构建工具将不能解决跨越语言障碍的问题。

可复现性也是一个挑战。实际上，数据科学家可以使用不同的编程语言、库或同一库的不同版本来构建模型的多个版本。手动跟踪这些依赖关系很困难。为了解决这些挑战，需要一个机器学习生命周期工具，它可以在训练阶段自动跟踪并记录这些依赖项，并将它们作为代码的配置，然后将它们与训练的模型一起打包到一个随时可以部署的工件中。

我建议你使用一种工具或平台，它可以立即将代码从一种语言转换为另一种语言，或者允许你的数据科学团队在API背后部署模型，以便在任何地方集成它们。

计算能力和GPU

神经网络通常会非常深，这意味着训练和使用它们进行推理需要大量的计算能力。通常，我们希望我们的算法运行得更快，对于很多用户来说，这可能是一个障碍。

此外，现在许多生产上的机器学习都依赖于GPU。然而，它们既稀缺又昂贵，这很容易给机器学习的扩展任务增加另一层复杂性。

可移植性

模型部署的另一个有趣的挑战是缺乏可移植性。我注意到这通常是遗留分析系统的问题。由于缺乏将软件组件轻松迁移到另一个主机环境并在那里运行的能力，组件可能会被锁定在特定的平台上。这可能为数据科学家在创建和部署模型时制造障碍。

可扩展性

对于许多AI项目来说，可扩展性是一个真正的问题。实际上，你需要确保你的模型能够扩展并满足生产中性能和应用程序需求的增长。在项目开始时，我们通常依赖于可管理范围内的相对静态数据。随着模型进入生产环境，它通常会接触到大量的数据和数据传输模式。你的团队将需要一些工具来监视和解决性能和可扩展性方面的问题，这些问题将随着时间的推移而出现。

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

机器学习峰值计算

一旦你的算法被训练好了，它们并不是时时刻刻被使用——你的用户只会在需要的时候调用它们。

这可能意味着你只需要支持上午8:00时的100个API调用，而在8:30时需要支持10,000个API调用。

根据我的经验，我可以告诉你，使用动态扩大或缩小你的服务来确保不为你不需要的服务器付费是一个挑战

由于所有这些原因，只有少数数据科学项目最终真正进入生产系统。

模型的稳定和鲁棒

我们总是花很多时间准备模型。我们需要把原型变得稳定和鲁棒，这样它就可以实际服务于大量的用户，这通常需要大量的工作。

在许多情况下，整个模型需要用一种适合体系结构的语言重新编码。仅这一点往往就会导致大量痛苦的工作，从而导致几个月的部署延迟。完成之后，必须将其集成到公司的IT体系结构中，包括前面讨论的所有库问题。此外，在生产环境中访问数据也常常是一项困难的任务。

更多的挑战

在做项目的过程中，我也注意到了以下问题:

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

测试和验证的问题

正如你可能已经知道的，模型由于数据更改、新方法等而不断发展。因此，每次发生这样的变化时，我们都必须重新验证模型的性能。这些验证步骤引入了几个挑战：

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

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

自动化机器学习平台

有些人可能听说过自动化机器学习平台。这可能是一个快速生成模型的好方法。此外，该平台可以支持多个模型的开发和比较，因此企业可以选择最适合其预测准确性、延迟和计算资源需求的模型。

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

许多模型经历了漂移(性能随时间降低)。因此，需要监视已部署的模型。每个部署的模型都应该记录所有的输入、输出和异常。模型部署平台需要提供日志存储和模型性能可视化。密切关注模型性能是有效管理机器学习模型生命周期的关键。

必须通过部署平台监视的关键元素

发布策略

探索许多不同的方式来部署你的软件，“shadow mode”和“Canary”部署对机器学习应用程序特别有用。在“shadow mode”中，你捕获生产中新模型的输入和预测，而实际上并不服务于这些预测。相反，你可以自由地分析结果，如果检测到错误，则不会产生重大后果。

当你的体系结构成熟时，请考虑启用渐进的或“Canary”版本。这种做法是指你可以向一小部分客户发布产品，而不是“要么全部发布，要么什么都不发布”。这需要更成熟的工具，但它可以最小化错误。

总结

机器学习仍处于初级阶段。实际上，软件和硬件组件都在不断发展，以满足机器学习的当前需求。

Docker/Kubernetes和微服务体系结构可以用来解决异构性和基础设施方面的挑战。现有的工具可以单独地极大地解决一些问题。我认为，将所有这些工具结合起来以使ML运作化是当今最大的挑战。

部署机器学习是并且将继续是困难的，这只是组织将需要处理的一个现实。值得庆幸的是，一些新的架构和产品正在帮助数据科学家。此外，随着越来越多的公司扩展数据科学操作，他们也在实现使模型部署更容易的工具。