Studio.ML弥合了数据科学家与DevOps工程师之间的鸿沟

当数据科学家和ML研究人员与DevOps会面以尝试在生产和商业环境中部署，审核和维护最先进的AI模型时，会出现许多问题。本文讨论了一种名为Studio.ML的新开源软件工具，该工具提供了许多解决此问题的方法。

如今，机器学习（ML）和人工智能（AI）使技术渗透到大多数行业。就像早期计算机时代的软件一样，ML和AI不再是研究人员的玩具，而已成为企业重要的创收工具。与业务目标驱动软件开发的方式类似，有必要使开发到生产ML模型的周期更短，更健壮并且更易于复制。这种需求通常会与“新奇事物”综合症相冲突，综合症是软件工程中已知的反模式。但是对于ML / AI驱动的企业来说，使用最新研究结果的能力通常意味着竞争优势和可观的利润。

换句话说，如果贵公司的数据科学家和平台工程师使彼此的生活陷入困境，请不要惊慌-这并不罕见。实际上，这正是我们在Sentient Technologies发现的情况。当我们尝试构建一个生产上可靠的深度学习和分布式计算框架以与Java一起使用时，我们发现所有新雇用的数据科学家都更喜欢使用Python构建模型。

为了更详细地说明问题的根源，请考虑图1中的典型数据科学和DevOps管道。要清楚地说明，我们并没有要求用这种简化的图片来涵盖所有可能的用例，而仅涉及到最频繁且最相关的情况。生产AI / ML模型。在数据科学世界中，如A行所示，典型过程始于收集数据，对数据进行迭代并调试代码。然后，通常可以通过手工或使用现代自动方法（例如神经进化）来优化超参数和神经网络体系结构，从而开始进行繁重的计算。最后，该过程已训练出最佳模型。之后，数据科学家通常会做一个模糊的事情，即“将模型推入生产阶段”，这通常归结为将最佳模型交给DevOps或工程团队。

同时，在B行所示的DevOps世界中，该过程从一个容器开始。容器必须通过一堆单元测试和回归测试，升级到暂存阶段，通过浸泡测试，然后才能投入生产。然后，模型容器成为微服务体系结构的一部分，开始与其他生产系统组件进行交互，然后进行自动缩放和负载平衡。牢记这两个世界，就可以看到事物容易掉入的裂缝。当模型与容器的绑扎程度不够时，当容器在波涛汹涌的海上运输时，模型会反弹。

DevOps倾向于名义上测试容器功能-无需检查模型是否正常运行-而数据科学家的测试并未考虑模型将在容器中工作的事实。权重文件等的预处理功能位置可能位于不同的文件夹中。我们的经验告诉我们，正是这些小事情最终被忽视了。

DevOps和数据科学的二分法促使我们创建了开源项目Studio.ML。Studio.ML旨在弥合必须不断地追逐新事物和新事物的研究型数据科学与可以完全再现结果并避免“在我的机器上运行”的良好软件工程或DevOps实践之间的鸿沟问题。Studio.ML还可以自动执行诸如超参数优化之类的重要数据科学任务，并以无缝方式利用云计算资源，而不会给数据科学家带来任何额外的认知负担，以使其了解容器或实例AMI。

该项目的核心思想是尽可能不侵入数据科学家或研究人员的代码，集中存储实验数据，以使其具有可复制性，可共享性和可比性。实际上，Studio.ML通常无需更改任何代码即可提供可观的价值。唯一的要求是该代码使用Python。自从我们使用Java构建深度学习框架并尝试使用Lua以来，Python便成为了机器学习社区的事实上的标准。这是由于其庞大的数据分析和深度学习库集，因此，如果您是研究ML / AI前沿技术的研究人员，则很可能会自然满足编写Python代码的要求。

从研究人员的角度来看，如果以下命令行：

python my_awesome_training_script.py arg1 arg2

训练模型，然后：

studio run my_awesome_training_script.py arg1 arg2

运行培训并存储重现实验所需的信息，例如一组带有版本，命令行和当前工作目录状态的python软件包。实验的日志（即stdout和stderr流）存储并显示在简单的UI中：

如果其他研究人员想重新运行相同的实验，则可以通过：

studio rerun <experiment_key>

包装实验具有可重复性，这是一个非常强大的想法。如果可以在另一位研究人员的机器上复制实验，那么它也可以在具有许多GPU的功能强大的数据中心机器上运行，也可以在云机器上运行。例如：

studio run --cloud=ec2 --gpus=1 my_awesome_training_script.py arg1 arg2

将使用具有一个GPU的实例在Amazon EC2中运行我们的实验，就好像它在本地运行一样。请注意，要获得相同的结果，研究人员必须与DevOps工程师合作，或者了解EC2 AMI，实例和租户类型，GPU驱动程序安装等。

再加上其他功能，例如超参数搜索，使用便宜的现货/可抢占式云实例，与Jupyter笔记本电脑及其他产品的集成，Studio.ML的存在使数据科学家的工作变得更加轻松。但是障碍的另一面是：DevOps工程师？Studio.ML还具有服务功能，因此可以将构建的模型用作单个命令行：

studio serve <experiment_key>

一方面，这允许对构建的模型进行简单的容器化和部署。但是更重要的是，简单服务可以使数据科学家自己进行单元/回归测试，从而消除了模型在训练和验证中表现良好时的频繁故障模式。服务使用的是未经测试的略有不同的预处理代码。内置的容错数据管道可以使DevOps工程师的工作更加轻松，它的另一个Studio.ML功能可以在GPU上以高速率进行批量推断，同时清除不良数据。

在后台，Studio.ML由几个松散耦合的组件组成，例如实验包装器，工作程序，排队系统，元数据和工件存储，可以将其交换为Hone Studio.ML，以满足项目的个别需求，例如自定义计算场或内部存储敏感的实验数据。

Studio.ML仍是一个相当早期的项目，它在机器学习社区中得到了很大的塑造。即使在此阶段，与成熟的服务（例如Google Cloud ML或Amazon SageMaker）相比，它提供的可重现实验所产生的摩擦（例如代码更改和对数据科学家的认知负担）也要少得多。如果您对有关此数据感兴趣，请参阅我们的博客，以使用SageMaker和Studio.ML再现最新的AI模型。

总之，现代AI / ML驱动的企业需要结合ML模型的行业级可靠性和可重复性以及研究敏捷性，以利用并为最先进的数据科学做出贡献。Studio.ML以简洁，非侵入性的方式满足这些需求。在我们看来，它将通过引入越来越多的高级ML自动化功能，继续弥合数据科学家与DevOps工程师之间的鸿沟。