世界启动Ⅹ--了解机器学习工程中的挑战和机遇

前言

• ML 工程师从事的 4 项主要任务。

图 1：ML 工程工作流程中的常规任务。

• 上述每个任务为机器学习工作流程增加了什么价值？
• 决定机器学习成功的 3V 因素是什么？
• 如何处理机器学习工程的实验性质？
• 如何将以产品为中心的指标与传统的 ML 指标相结合来选择正确的模型。
• 在将模型投入生产后，如何才能保持模型的最佳性能？

了解上述内容可以让我们更深入地了解推动 ML 工程成功的因素。一旦我们了解了这一点，我们就可以了解如何应对目前困扰各地 ML 工程师的以下挑战 -

• 开发-生产不匹配：开发和生产环境之间存在差异。这包括数据泄漏；Jupyter Notebook 使用理念不同；以及非标准化代码质量——所有这些都会导致生产中出现意想不到的错误。使用提供类似环境同时支持不同迭代速度的工具来弥合这一差距至关重要。我还强烈建议利用异步文档/样式指南检查 + 团队文化来标准化其中许多实践，以便您的工程师无意识地遵循您已建立的 SOP。正如一位智者（我）曾经说过的那样——潜意识的洗脑往往在教育失败的地方取得成功。关于这一点的更多内容将在未来的文章中介绍。
• 处理数据错误：机器学习工程师在处理一系列数据错误（例如模式违规、缺失值和数据漂移）方面面临挑战。困难在于确定每种错误类型的适当响应，并减轻误报导致的警报疲劳。这些问题可以通过开发/购买用于实时数据质量监控和自动调整警报标准的工具来解决。
• 驯服 ML 错误的长尾：由于错误不可预测且通常是定制的，因此调试 ML 管道带来了独特的挑战。虽然症状可能相似，但找出根本原因可能非常耗时，并导致“调试创伤”的感觉。对错误进行分类并开发能够深入了解性能下降及其根本原因的工具是潜在的解决方案。这就是我执着地强调更好的透明度和监控框架的原因——它们可以帮助您避免巨大的重复性错误。
• 冗长的多阶段部署：机器学习实验的迭代和不可预测性 + 多阶段部署流程可能导致验证和推出新模型或功能的时间表延长。这通常会导致由于优先级的转变或用户行为的演变而放弃一些想法。精简部署和预测端到端收益的工具可以最大限度地减少浪费的努力。然而，最好的办法是接受“少即是多”的格言。寻找尽快验证（不）想法的方法，因为这将为您节省大量时间和精力。记住，你赢得每一场你不打的仗。
• 观察到的反模式：多种反模式阻碍了 MLOps 的发展，包括行业需求与课堂教育不匹配、渴望让 GPU 不断运行实验而缺乏战略重点、在观察结果后修改解释的倾向以及对特定管道的了解没有记录。解决这些反模式需要改进教育资源、自动化文档工具，并在实验中转向优先考虑质量而不是数量。

最后，作者讨论了 MLOps 工具的总体情况。总体情况可分为四层：用于管理执行的运行层；用于指定依赖项和计算的管道层；用于单个计算单元的组件层；以及用于底层资源的基础设施层。

如果您是 MLOps 工具构建者，请了解这些层，并寻找显著提升其中 3V 的方法。本节的两个要点是：

1. 工程师喜欢能够增强他们体验的工具。我们在姊妹刊物《Tech Made Simple》中深入讨论了这个问题。改善用户体验（尤其是对于比较成熟的工具/应用程序）的投资回报率往往高于改善工程设计（让火车跑得更快很昂贵，但在火车上安装 WiFi 让旅途变得轻松却很容易）。
2. 随着我们深入研究，变化的频率会降低。运行层有很多变化，而基础层的变化往往很少。许多团队倾向于通过非常短期的视角来做出基础决策（“AWS 给了我们一个很好的折扣”或“我们雇佣的团队只知道 Azure”），