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

作者：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运作化是当今最大的应战。

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

英文原文：https://towardsdatascience.com/why-is-machine-learning-deployment-hard-443af67493cd

请长按或扫描二维码关注本公众号

秀起来~

LZ敢整点更有创意的不？兄弟们等着围观捏~

报告！别开枪，我就是路过来看看的。。。