Algorithmia 简介

Algorithmia 是一个机器学习开发与运维 (MLOps) 平台，可帮助数据科学和机器学习负责人部署、管理和扩展其 ML 产品组合。 这是一个完全集成的机器学习运营环境，允许人们从任何地方进行部署，并从一个中央位置安全地管理公司的机器学习产品组合。 该公司在大规模部署人工智能和管理机器学习生命周期方面取得了成功。

一个问题：机器学习 != 生产机器学习

Diego 从一个重要的观点开始。 他指出，机器学习 (ML) 并不等同于生产机器学习。

“……如果你今天要带着什么离开……那就是机器学习和生产机器学习是两种完全不同的东西”

在生产机器学习方面有多个因素需要考虑，而在典型的机器学习方面可能不会考虑。 我们考虑数据收集、建模和准确性，但还有其他重要变量需要考虑：基础设施、与 DevOps 工具的集成以及部署。

在生产机器学习方面，集成到软件中是“最终目标”。 生产 ML 是创建最终产品的工具，因此思考 ML 如何与软件集成/交互非常重要。

团队还可以做得更多

Algorithmia 每年都会进行一项调查，并从 500 多名从业者那里收集数据，他们得出了一些关键发现：

• 75% 的时间花在基础设施任务上，25% 的时间花在训练模型上
• 面临的 30% 挑战与支持不同的语言和框架有关
• 30% 面临的挑战与模型管理任务有关，例如：版本控制和可重复性
• 38% 的挑战在于以必要的规模部署模型

要查看 2020 年数据，您可以查他们的数据可视化交互或阅读他们的白皮书：2020 年企业机器学习状态。

团队将大部分时间花在运行基础设施任务上，比如：设置环境和解决依赖关系，而不是花时间在实际模型上。

参与者还面临一些关键挑战。

• 新的框架和语言正在以相当大的速度发布。当似乎每天都有新技术出现时，将所有这些技术生产化是一个挑战。
• 下一个挑战是如何管理模型。创建模型后，随着技术的不断发展，如何对模型进行版本化并获得可重复性存在挑战。
• 最后一个挑战是以适当的规模部署模型。模型变得越来越庞大，它们占用了大量资源，在大规模实施的同时交付人们想要的软件实验已成为一项真正的工程挑战。

Gartner 的一份报告还显示，交付商业价值的主要障碍是缺乏成功的项目生产。

继续这个问题：应该从哪里开始？

许多公司才刚刚开始探索使用 ML。他们拥有所有这些数据，并看到了这项新兴技术，现在他们正试图了解如何使用数据以及如何使用这些新工具。基本上，他们正试图找出从哪里开始，以及如何开始。人们是如何用 ML 做决定的？需要什么工具？应该雇佣谁？当聘请纯学术背景的人时，他们将面临在企业环境中工作的挑战。

传统的 DevOps 和 ML 生命周期 DevOps 是不同的。由于动态变量（如：不同的硬件或数据更改），后者需要非常快的迭代。ML 比传统的应用程序开发速度更快，而且 ML 开发生命周期也在不断发展。这是一个复杂的问题，但归根结底，DevOps 的目标是加快生产速度。

ML 和成本的快速增长

在第一次部署 ML 时，并不十分困难。资源很容易获得、托管（hosted）和管理（managed），对产品的需求也很低。你可以使用一些介于1-2种语言之间的模型和框架，拥有一个自我管理的 DevOps 团队，并有望支持一些终端用户（end-users）。

然而，事情会呈指数增长。很快，就需要支持数百个模型、帮助服务低可发现性的自动化系统，以及每秒数千次对API的调用。随着不断的增长，支持变得非常昂贵。

一个重要的收获是，ML 开发生命周期变化得非常快，将 ML 开发和应用程序开发分开非常重要，并且应该这样区别对待。

这个问题的战术与技术视角对比

Diego 将 ML 部署问题分解为两个方面：战术和技术。

战术视角

如今部署 ML 在经济上具有挑战性，这是由很多因素造成的：

技术视角

以下是 ML 生命周期的简化以及 Algorithmia 如何看待该过程：数据 > 训练 > 部署 > 管理

连接到您的数据管理系统，通过 API、Git 或 CI/CD 流水线从您选择的训练平台发布，部署和管理模型，并与您的其他模型和产品应用程序集成。

需要考虑的事情

训练和生产不同

训练和生产条件有很大不同。 训练具有较长的计算周期、固定的负载、有状态且只有一个用户。 在生产中，计算突然出现时间短，需要弹性，可以是无状态的，并且有很多用户。

异构工具和依赖项

有数十种不同框架、语言、硬件和依赖项的组合。如前所述，似乎每天都有新技术出现。第一次构建一个堆栈时，一件事就是让它全部工作。在构建过程中，它们需要以一种可以升级的方式适应所有依赖项。

可组合性加剧了挑战

许多模型没有投入生产，因为它们在投入生产之前就分崩离析，人们希望能够修补这些部件。依赖项和部件如何组合在一起非常重要。 ML 模型是由流水线构建的，有人会希望流水线的每一部分都成为最好的部分。依赖关系可能会变得非常复杂，他们希望能够将它们分解成碎片（部件）。

多样性使可审计性和治理复杂化

需要确保他们符合组织的规则。一些大问题是谁在调用什么，谁可以访问它，以及某人如何管理依赖关系？ Diego 回忆了一个金融服务客户的故事，他们在依赖项、包等方面采取了很多安全措施。数据科学家不断从 PyPy 中提取东西而没有检查，当他们发现时，DevOps 团队变得愤怒。

缺乏可重用性会减缓增长

每个人都应该为可重用性而构建。不断地重新发明轮子并重写相同的功能变得低效，并浪费时间更新依赖项。更好的做法是构建可在整个组织中使用的可重用服务。

测量模型性能

成功和性能非常依赖环境。

在学术界，目标是发现真相并提高准确性。如果需要 10 年时间才能将准确率从 90% 提高到 93%，那么这是一项有效的投资。

在企业中，情况就不一样了。例如，如果有人在亚马逊上买了东西并被推荐了相同的商品，这没什么大不了的。

这两种情况的成功取决于背景、目标和优先事项。没有一种解决方案适合每项工作。

如何辨别常见的陷阱和关键要点

Diego 引用了一位朋友的话，对上述所有考虑事项进行了如下说明：

• 不要重新发明轮子
• 关注结果，而不是过程
• 不要试图完美
• 对锁定说不（保持开放）
• 工具不是解决方案
• 正当的审核，不断的修订

总结

如果说这次讨论有什么可以借鉴的，那就是 “机器学习!=生产机器学习”。