如何从先期的失败中找到一条成功之路，本文试图作了一番探讨。——Caleb Kaiser写于2020年4月24日。2019年初，我们几个人尝试构建一个端到端的机器学习（ML – Machine Learning）框架。我们从这次尝试中得到的基本体会是，构建机器学习管道是一个令人沮丧的、毫无逻辑的体验，而且我们应该可以构建更好的东西。我将在本文对这次尝试作一个详尽地介绍，下面先介绍大致情况：- 我们使用Kaggle数据集为机器学习管道的数据接收、训练、部署等不同阶段编写了抽象。
- 我们将代码库开源并共享。一个月后，我们的项目登上了HN的首页。每个人都喜欢那些改进机器学习用户体验的想法。
- 六个月后，我们只收获了几百颗GitHub星星，几乎没有人使用它。我们不得不将我们的傲气搁到一边，删除了代码库中90%的代码。
在经历了以上这些过程后，我们构建了一个更好的项目 - Cortex，我们的模型服务基础设施。对于任何对机器学习研究和/或应用感兴趣的人来说，我们想让这个过程成为一种警示：生产型机器学习系统确实需要更好的用户体验，但是机器学习生态系统是非常复杂和不断变化的，这使得构建一个涵盖大量用例的解决方案非常困难。
为什么想构建端到端的机器学习框架？
我们大多数人（Cortex的贡献者）都有devops和web开发的背景，习惯于将应用程序的不同层抽象为单个接口的框架。
当我们进入机器学习时，每个人都被工具的支离破碎所震惊。我们想构建推荐引擎和聊天机器人（或者更确切地说，会话代理），但在这样做的过程中，我们发现自己不得不在不同的环境之间（Jupyter Notebook、终端、AWS控制台等等）跳跃。然后把包含有胶水代码和TensorFlow样板文件的整个文件夹写到一起，用一个称为“管道”的强力胶带粘合起来。如果我们可以用一个配置文件和命令粘合在一起来代替以上所有的步骤，比如：
$ deploy recommendation_engine
所以我们就这么做了。我们构建了这样的一个框架，它使用Python转换数据，使用YAML构建管道，并使用一个CLI（命令行界面）控制所有步骤：当你使用我们支持的窄技术堆栈，同时加上对API的限制，向它提供Kaggle数据集时，成为了一个非常好的框架。然而，如果你想尝试在现实世界中使用它，基本上很可能它不会与你的技术堆栈一起工作。毫无疑问这是一个问题。虽然这个问题的其中一部分原因归结于我们的设计，但很大一部分原因实际上是因为构建端到端机器学习框架的固有局限，我们只是在构建了这个端到端机器学习框架之后才发现这一点。简单的一种说法是：对于端到端的框架来说，生产型机器学习生态系统太简单，不可能既不灵活又正确无误。机器学习工程师希望使用更好的UX工具，这一点我们没有错。我们的错误在于我们以为可以构建一个覆盖多个用例的端到端机器学习框架（特别在只有几个贡献者的情况下）。有一件事很值得去做（而在项目的早期被我们忽略了），那就是思考一下曾经给我们启发的web框架，并记住他们第一次崭露头角的时候。Rails、Django和Symfony，作为web应用的新MVC框架浪潮的一部分，它们都是在2004年到2005年间发布的。当时的web开发还不能称为“稳定”，尤其是考虑到自那以后它们是如何变得成熟的（在很大程度上要感谢那些框架），但是web开发人员所做的工作和现在相比仍然有高度的相似性。事实上，Rails最早的口号之一是“你不是一片美丽而独特的雪花”，正是基于这样的一个事实：大多数web开发人员正在构建架构上类似的应用程序，这些应用程序可以在相同的配置上运行。生产型机器学习系统还未发展到那个阶段。一切仍在变化之中。数据科学家处理的数据类型、使用的模型体系结构、喜欢的语言/框架、应用程序的推断要求，以及几乎所有你能想象到的一切东西，都在不断变化中。而且，这个领域本身变化也很快。自18个月前Cortex首次发布以来：
PyTorch已经从一个仅仅前景看好的项目发展成为最流行的机器学习框架，在此期间许多专门的机器学习训练库（如微软的DeepSpeed）已经发布出来。
OpenAI发布了有史以来最大的模型，可以运行带有15亿个参数的GPT-2。此后，谷歌、Salesforce、微软和Nvidia都发布了更大的机型（有些是同一数量级的）。
大量初创企业已经开始使用迁移学习（Transfer Learning）和预训练模型来优化和部署具有少量数据的模型（比如说，并非每个人现在都需要一个100节点的Spark群集）。
所有这些都在不断变化中，所以试图构建一个支持“合适”技术堆栈的端到端框架从一开始就注定了失败。每个人都会要求他们需要的“一个特性”，而没有人有相同的要求。我们试图构建一些通用的特性，但很快就发现这是不可行的，至少不是我们想象的那样。
专注于模型服务基础设施
构建一个端到端的机器学习框架是很困难的，因为大部分的机器学习生态系统仍然是“蛮荒的西部”。然而，其中的“模型服务”已经具有了稳定性和一致性。不管他们使用什么堆栈，大多数团队都是通过先将模型封装在API中，然后部署到云端（尽管他们不喜欢这样做）来将其投入生产，。数据科学家不喜欢它，因为用于构建弹性web服务的工具，如 Docker、Kubernetes、EC2/GCE、负载均衡器等等，都不在他们的触手可及之处。DevOps工程师对模型推断的独特之处感到恼火。但是对我们来说，这是一个机会。“模型作为微服务（model-as-a-microservice）”的设计模式对所有团队来说是一致的，而它提供的工具，因为它是基础设施（而不是机器学习生态系统）的一部分，所以非常稳定。更有利的是，作为软件工程师，我们在构建生产型web服务方面比在构建机器学习管道方面更有经验。所以，我们想在模型服务上尝试一下。我们应用了相同的设计原则，抽象了声明性YAML配置和最小CLI背后的所有低层次的不同，并自动化了将一个经过训练的模型转换为一个可伸缩的生产型web服务的过程：通过专注于模型服务，我们可以对堆栈的其余部不加理会（只要模型有Python绑定，Cortex就可以为其服务）。因为Cortex可以插入任何堆栈，所以我们对Cortex在底层使用的工具有了话语权，这又使得构建更高级别的特性变得更加容易。例如，自从发布用于模型服务的Cortex以来，我们增加了对GPU推断、基于请求的自动缩放、滚动更新和预测监视的支持。我们不需要为十几个不同的容器运行时和集群编排器实现这些功能。Cortex在底层使用Docker和Kubernetes，用户从来不需要接触它们中的任何一下。
将web开发经验应用到机器学习工具中
从哲学上讲，网络框架对我们如何看待Cortex有很大的影响。Rails和Django之类的框架使得程序员的工作效率和幸福感倍增。要构建一个web应用程序，你不必担心配置SQL数据库、实现请求路由、或编写自己的SMTP方法来发送电子邮件。所有这些都从直观，简单的界面中抽象出来。简而言之，这就是我们对Cortex的看法。数据科学家不必学习Kubernetes，他们应该专注于数据科学。软件工程师们不必花上几天的时间来研究如何避免5 GB的模型浪费他们的AWS账单，他们应该可以自由地构建软件。希望随着机器学习生态系统的成熟和稳定，我们能够将这一理念扩展到堆栈的其余部分。目前，模型服务是一个不错的开始。https://towardsdatascience.com/we-tried-to-build-an-end-to-end-ml-platform-heres-why-it-failed-190c0f503536
更多精彩推荐
