建模库无关紧要

在为我的公司构建第一个机器学习管道时，我为在我们的堆栈中包含哪些建模库而苦恼。大多数模型开发人员想要使用什么？我对 scikit-learn 和 PyTorch 有强烈的感觉，但是将我对 ML 框架的意见强加于我们公司的基础架构会产生什么后果？从长远来看，哪个建模库会“获胜”？如果我在几年后就会过时的 DSL 中编写建模代码怎么办？ 2016 年，我参加了一个深度学习入门课程，所有作业都在 Tensorflow 中；我最近的深度学习课程完全是在 PyTorch 中进行的。四年后，我认识的所有机器学习研究人员似乎都在使用 PyTorch。少数不使用 PyTorch 的人使用 TF 1.0，他们的口号是“总有一天我会切换到 TF 2.0 或 PyTorch”。发生了什么？几个月后，我意识到库的选择并不重要，因为建模只是机器学习管道中的一小步。其他步骤同样具有挑战性，即使不是更多，也难以维护：例如，迁移数据管道代码比在 PyTorch 中重写基本 TF 建模代码要困难得多。我已经在 TensorFlow、PyTorch、XGBoost、scikit-learn 和 LightGBM 中为我公司的不同任务编写了模型。我什至用 Scala 编写过非 Python 模型。当我为预测任务迭代机器学习管道时，我会尽可能避免更改模型架构，因为我宁愿更改我更好理解的管道部分，例如数据摄取和更好的特征化。我公司的拉取请求表明，与管道代码相比，人们几乎不会接触他们的建模代码。重要的是拥有“即插即用”ML 模型训练器和预测器的基础设施，因为几乎没有一种编程库可以满足所有需求。有些人会指出研究人员绝大多数倾向于 PyTorch 和 JAX 的趋势，并认为这里的赢家确实很重要，因为研究人员变成了公司的数据科学家，这些数据科学家构建模型，而这些模型将“永远”生产和使用。但作为一个领域，我们仍在努力生产模型、将其输出与人类激励保持一致、迭代这些系统并信任这些管道。对于“大科技”之外的任何 ML 从业者来说，他们最大的问题是模型管道以及客户、他们自己和机器之间的价值一致性。毕竟，这些对于产品开发至关重要。即使我们为这些核心问题构建了框架，建模库仍然无关紧要，因为一个问题的多个软件框架可以愉快地共存。人们很聪明，可以轻松学习不同的框架——事实证明，在几年内从 TensorFlow 到 PyTorch 的转变如此之大，这证明开发人员会找到最适合他们工作的工具。更重要的是他们为他们构建的软件拥有正确的基础。此外，业务考虑可以覆盖框架的选择，甚至构建新框架，尤其是在初创企业中。我公司针对特定 ML 问题的代码库经历了这样的事情：首先，我在我选择的 DSL 中编写了实验代码来“解决”问题。然后当我们不得不构建一个产品时，我重写了管道。然后，当我们稍微调整一下时，我重构了管道以生成我们今天定期发布的实时 ML 产品。随着我对产品的当前版本以及其他利益相关者（技术人员或非技术人员）如何与它进行交互有了更清晰的了解，我意识到这些业务考虑比建模库或我对其他 DSL 的看法更能推动管道开发。因此，建模库的赛马具有误导性，目前“现实世界”ML 中最具挑战性的问题围绕着商业价值、生产化、小型化以及重复训练和推理的流水线。但由于编程语言和基础设施推动了软件的创新，建模库的演变仍然值得思考。在 The Mythical Man-Month: Essays on Software Engineering 中，Fred Brooks 引入了第二系统效应的概念，即“小型、优雅和成功的系统被过度设计的、臃肿的系统所取代的趋势，由于膨胀期望和过度自信。”著名的例子包括 IBM System/360 操作系统（它继承了 1950 年代的 IBM 700/7000 系列）和 Multics 操作系统（它继承了 1960 年代后期的 Compatible Time-Sharing System）。我认为 TF 1.0 是成功的：它加速了许多深度学习研究，范围相当狭窄且经过深思熟虑，并通过 XLA 编译、TPU 等率先在硬件垂直领域进行创新。但随着时间的推移，当数百名 TensorFlow 工程师试图解决该软件的局限性并将 TensorFlow 转变为适用于所有人的机器学习库时，它遭受了二次系统效应并成为了 TF 2.0，一个不为任何人使用的机器学习库（可能除了 Google ）。他们试图解决的一组问题是“使模型在生产环境中工作”：TFX 是一个很好的例子，说明了过度炒作和未充分利用的 TF 2.0 工具。将 PyPI 统计数据与 Kubeflow 的上下文进行比较； TFX 构建了他们的框架以很好地适应 Kubeflow，但 Kubeflow 用户仍然不想使用 TFX。这并不是说生产 ML 的问题不存在；相反，TFX 目前似乎并不是解决许多这些极具挑战性的问题的方法。如果 UX 违反直觉，并且工程师需要成为专业的错误日志解析器才能精通该工具，那么拥有教程也无济于事。

所有这些都是关于我对 TensorFlow UX 的批评，我实际上在工作中使用 TF 2.0——主要是出于懒惰。 Spark 到 TFRecord 到 TFData 到 TF 模型管道有部分文档记录，而 Spark 到 TFRecord 到某些东西到 PyTorch 模型管道的文档几乎没有。但是我的模型的 DSL 几乎不是我每天都在考虑的事情，因为我的大部分问题都不是“我可以多快从头开始编写转换器或 convnet 架构”。这个行业的人很少从头开始构建东西。软件产品建立在增量原则之上；代码和功能会随着时间的推移而积累。所以我对我最初的问题的回答是，从长远来看，哪个建模库会“获胜”是不值得担心的，因为如果多个库都做一些重要的事情，比如拥护数据流范式或轻松的自微分，它们就可以获胜。如果您是工程师，请不要围绕特定的建模库构建管道。如果您是研究人员或数据科学家，则不必担心学习所有建模库或公司职位描述中提到的任何库。软件历史表明，建模框架膨胀是不可避免的，只要这些库的最大优先事项是相互竞争，它们就会收敛到相同的关键任务建模问题的解决方案——急切执行、易于构建从头开始建模，能够很好地查看损失曲线，等等。但这些只是大多数“现实世界”机器学习问题的一小部分，作为机器学习从业者，归根结底，并不是因为您在训练模型方面的专业知识而被聘用；您受雇于使机器学习系统始终如一地为最终用户提供价值。感谢 Reese Pathak、Jay Bhambhani 和 Debnil Sur 对多个草稿的反馈。