本文是我在2024年旧金山QCon大会上演讲的总结。在过去的十年里，我作为一名应用科学家和机器学习工程师，在包括社交媒体、金融科技和生产力工具等多个领域工作。多年来，我看到许多项目取得了成功，但同样也有许多项目未能投入生产。这篇文章反思了成功或失败的原因，以及我们能从中学到什么。
在这篇文章中，我讨论了导致机器学习项目失败的常见陷阱，比如机器学习的固有不确定性、不一致的优化目标以及从业者之间的技能差距。首先，我概述了机器学习项目的生命周期以及它与普通软件项目的不同之处。然后，我深入探讨了五个常见陷阱（通过示例），并解释了我们如何减少遇到它们的机会。
机器学习项目的失败率
我在包括社交媒体平台、金融科技解决方案和生产力工具在内的各个领域都参与过机器学习项目。其中一些项目投入了生产，而许多项目没有。每一次努力都教会了我一些有趣的东西，并让我接触到了新技术，但当你全身心投入的一个项目没有产生你所希望的影响时，感觉并不好。我想知道：是我一个人吗？这个问题有多严重？
较早的研究报告称，机器学习项目的失败率高达 85%。最近的调查也得出了类似的结论。在2023年Rexer Analytics的一项研究中，超过三百名机器学习从业者中，只有 32%的人表示他们的项目投入了生产。不同行业的比率有所不同：大型科技公司有多年的 AI 应用历史，而传统企业和初创公司仍在寻找有效、无缝的 AI 应用之路。
并非所有的失败都是坏事。机器学习项目本质上是不确定和实验性的。通常，在探索数据并尝试一些基线模型之前，你无法知道机器学习是否会帮助你得出结论。如果根据这些初步研究，你决定快速改变方向或终止项目，那么应该被认为是一种成功，这是鼓励创新的经典快速失败原则。
在这篇文章中，我关注的是糟糕的失败：那些没有明确定义就拖延的项目，尽管离线性能良好但没有部署的模型，或者即使部署后也没有被采用的解决方案。
机器学习项目的生命周期
从高层次、简化的角度来看，一个典型的机器学习项目生命周期有六个步骤。它从确定一个使用机器学习优化的业务目标开始，这需要作为一个机器学习问题被构建。构建问题涉及探索和处理相关数据以训练各种模型。表现最佳的训练模型被部署和监控。我们从监控过程中得到的反馈将用于完善整个系统。
一个说明机器学习项目生命周期的简化高层图。（来源：作者）
这个迭代生命周期有两个要点：
这是一个漫长、多步骤的过程，涉及多个团队之间的交接，由于涉及到固有复杂性，增加了失败的风险。
机器学习项目是以数据为中心的优化问题。来自数据、模型和监控的反馈信号对于成功的结果同样重要。
陷阱 1：解决错误的问题
在我们想要讨论的五个常见陷阱中，其中最关键的一个是优化错误的问题。在 Rexer Analytics 的调查中，当机器学习从业者被问及在开始之前是否明确定义目标时，29%的人回答“大多数时候”，26%的人表示这种情况很少发生。这种清晰度的缺乏是机器学习工程师在承诺项目之前就经常面临的共同挑战。
在过去，对业务目标进行迭代并在开始项目时保持一定的模糊性是很常见的。然而，对于机器学习项目来说，这种迭代已经成为一个更严重的障碍。为了理解这个问题，我们需要探索业务目标是如何被转化为机器学习解决方案的。当然，我们不想错过第一步，那就是确定这个问题是否与机器学习相关。
一旦我们确定这是一个机器学习问题，我们需要将其构建为一个 ML 问题，这涉及到识别用于提取信号的具体数据（数据工程）以及训练多个模型/架构/超参数的设置。根据模型的复杂性，训练步骤可能经常需要更昂贵的基础设施（例如，GPU）。
归根结底，我们试图优化一个数学定义的目标函数。这个目标函数高度依赖于我们试图解决的业务目标类型。业务目标的后期变化需要对数据、目标函数和管道进行调整，这可能导致工作的损失。这就是为什么，为了从一个良好的机器学习问题开始，我们通常希望向业务团队提出许多问题。
以下是我想分享的一个例子，它展示了我们如何增加挑选获胜项目的机会。几年前，我曾是一个支持多个业务线的集中式 AI 金融科技团队的一员。每条业务线都将其项目标榜为“最重要的”，通常使用我们不熟悉的术语。我们的团队不得不在噪音中导航，优先考虑最有可能成功的投资。
在一年中，我能够参与各种不同类型的项目，涉及不同的业务线。最大的成功——对公司和我来说——是一个对个人和商业银行（P&CB）领域来说不言自明的预测模型。三个因素导致了这个项目的成功：
直接收入相关性：P&CB 是一个主要的利润中心，因此有强烈的高层推动力。
与现有系统的互惠性：我们的模型可以嵌入到一个长期运行的端到端系统中，具有监控/报告功能；我们只需要替换模型。
机器学习可行性：现有的模型简单，具有现代架构和功能，因此我们有信心可以超越它。
仅仅因为其他人都在做机器学习项目，或者技术上可行，就启动一个机器学习项目是不够的。最好的机器学习项目达到了理想（利益相关者拉动）、有利可图（业务影响证明成本）和可行（技术上可解决）的最佳点。事先问一些尖锐的问题：目标是否明确定义？预计的利润是否合理？哪些假设是现实的？模型可能暴露哪些风险？
投资组合平衡也很重要。低风险/高影响项目是“唾手可得的果实”。如果你意识到风险并保持投资组合平衡，那么高影响/高风险项目是值得追求的。胜利证明了在 AI 基础设施和人才上的投资，而风险更大的赌注可能会改变游戏规则。
陷阱 2：数据陷阱
第二个陷阱是由数据带来的挑战。这是机器学习项目最常见的陷阱之一，也许是你的团队抱怨最多的一个。数据在哪里？我们能处理大量数据处理吗？尽管公司已经在解决这些问题上投入了很多，但这并不意味着没有其他隐藏的挑战最终会损害你的项目。在机器学习领域有一句名言：“垃圾进，垃圾出”。机器学习项目完全依赖于识别数据中的模式。如果数据是有缺陷的，那么你从这项研究中得到的结论很可能是不可信的。
多年来，机器学习社区建立了一个标准的数据管道结构，包括数据收集、处理和特征工程。还有一份人们通常为数据准备执行的常见任务清单：过滤重复项和异常值、填充缺失数据以及重新采样以处理数据不平衡。每个合适的机器学习团队都使用或适应这些标准程序，但它们的使用远远不够。
如果你对机器学习项目是如何失败的感兴趣，这个GitHub存储库包含了一长串多年来发现的失败的机器学习解决方案。这些失败大多数与数据有关。尽管大型科技公司或大学研究人员开发了所有解决方案，但他们也难免会出现涉及数据的错误。
2022年普林斯顿大学的一项审查发现，在 22 篇同行评审的论文中存在关键陷阱；这些结果传播到了 17 个领域的 290 多个后续研究中。其中一个关键问题是数据泄露。研究将数据泄露分为八个不同的类别，从混合训练和测试数据到抽样偏差。处理各种类型的数据泄露使其难以识别和预防。
数据准备工作通常感觉像是在探索冰山。你在表面看到的只是开始。许多问题，特别是与你自己的数据相关的问题，都隐藏在下面。大型组织也面临数据孤岛的问题：团队可能不知道所有可用的特征，导致错误的“无法解决”的结论。标记是另一个主要挑战。通常，我们需要收集和标记一个黄金数据集进行评估，提供详细的注释指南，并执行质量检查。即便如此，你可能会发现标记的数据仍然缺乏一些共识，你不能将其用于模型训练。
有了模型即服务和预训练模型，团队可以通过外部 API 跳过训练，但评估仍然困难。在早期的 GenAI 工作中，许多团队依赖于人工观察或微小的示例集。在最初阶段这是可以的，但如果没有强大的评估管道，你最终会得到被动的补丁和未知的爆炸半径。最终，我们仍然需要在 LLM 和 GenAI 的评估上投入大量资金。
虽然从一开始就不可能完美地解决所有问题，但这一点仍然需要强调：花时间探索和理解你的数据。根据你的观察寻找新特征并清理它，而不是应用一个标准过程。投资于收集高质量的标签。最终，机器学习的成功在很大程度上取决于数据。
陷阱 3：从模型到产品
我想强调的第三个问题是将机器学习模型转变为服务于大规模、实时用户的功能性产品的挑战。这种转变不仅仅是部署代码。要解决生产约束和额外要求，需要付出巨大的努力。
真实世界机器学习系统的工程系统概览。（来源）
谷歌的著名图表显示了与周围的基础设施相比，ML 代码是多么的小。大多数代码来自支持基础设施，包括资源管理、服务系统、监控工具、日志记录和其他相关组件。MLOps 领域已经成熟，并且有许多资源可以提供帮助。当然，对于首次采用者来说，这听起来很繁重，但一旦你建立了基础管道，你就可以支持多个机器学习解决方案，并更无缝地部署它们。
为了了解机器学习模型和完整的机器学习驱动解决方案（超出 MLOps 单独可以覆盖的范围）之间的差距，让我们以检索增强生成（RAG）为例。本质上，RAG 从你自己的数据库中提取相关信息。它将其提供给大语言模型（LLM），允许模型在考虑额外上下文的情况下回答问题。一个快速演示看起来可能非常简单（一个 LLM API、一个向量数据库和一些编排）。但是将其转变为一个生产就绪的 RAG 系统（例如，一个为客户支持提供动力的 RAG 系统）是完全不同的故事。你需要评估性能和控制质量的方法。你可能还需要一个更高级或代理式的 RAG 设置，而不仅仅是基本的 RAG 设置，以及可解释性功能，以便客户可以信任答案。除此之外，还有工程方面：通过缓存或推理调整减少延迟，并保持隐私、公平和安全（包括防御幻觉和越狱）。
除了技术指标外，监控业务导向的指标也很重要。这些指标可以包括产品质量的衡量（例如，用户采用或参与新功能的频率）、客户体验（例如，满意度或保留率）以及整个平台的健康状况（例如，收入增长、活跃使用或流失率）。关键原则是，技术方面的优化工作不应破坏业务的更广泛成功和可持续性。
简而言之，获胜团队是跨职能的，并在早期就要求、质量门槛和生产约束达成一致，而不是在孤岛中工作，希望问题稍后会被修复。
陷阱 4：离线与在线
第四个陷阱是离线成功和在线失败。这个陷阱可能是引起团队最多情感波动的一个。为什么坚实的离线模型在线失败？因为数据、解决方案和指标在不同阶段有所不同。离线模型使用历史（通常是清洁/抽样）数据和以机器学习为中心的指标。在线模型使用实时数据、端到端系统和与业务对齐的指标。
（来源：作者）
让我分享一个来自我的第一个生产发布的例子，这是很多年前的事了。当时，我们正在开发一个照片推荐器，以在创意社区内推广摄影师的作品。业务团队提出了一个担忧，即新用户会注册，发布一两张照片，然后再也不回来。考虑到这一点，我们的数据科学团队开始进行一些探索，以找出问题所在。他们发现早期点赞和留存之间有很强的相关性。有了这个洞见，任务就变成了通过尽快推广每个新用户的照片，让他们更快地获得他们想要的反应，并返回我们的网站。
当时，大多数推荐器都依赖于协同过滤：如果用户 A 和 B 喜欢许多相同的项目，我们推荐 A 喜欢但 B 未见过的项目。这也解释了为什么我们的新用户没有收到很多点赞，这种现象被称为冷启动问题：因为新项目之前没有任何互动，它们也几乎没有可见性。
为了解决冷启动问题，我们构建了一个基于内容的推荐系统，从图片本身预测照片的受欢迎程度。流程：对于用户 A，找到与过去喜欢的相似照片，然后使用受欢迎程度分类器进行过滤，以减少低质量的推荐。
一旦分类模型被优化，我们就将其集成到生产管道中。然而，在线 A/B 测试结果参差不齐：点赞增加了，但会话长度下降了，这是一个关于参与度的负面信号。出于某种原因，我们的推荐系统正在造成令人不安的体验；用户不再想继续滚动浏览我们的网站。
经过多次迭代，我们最终找到了一个更好的方法来整合受欢迎的信号。结果，推荐系统变得更加复杂。这是一条漫长的道路，铺满了多个步骤，不仅涉及离线评估和在线评估之间的差异，还涉及监控一组业务指标，而不仅仅是一个主要的业务指标。
一旦模型集成到生产中，它就成为了一个更大系统的一部分，涵盖了整个解决方案。推荐系统经常合并多个模型，这些模型的输出并不正交，因此一个在离线环境中表现强劲的模型在合并后的系统中可能影响会减弱。这里的教训是：不要过度优化离线环境。要尽快推动 A/B 测试，以验证与业务目标的一致性。
陷阱 5：非技术障碍
最后一个陷阱，经常被忽视，与看不见的非技术障碍有关。回到我们之前的调查，当人们被问及在部署模型时面临的主要障碍时，两个最常见的答案与技术无关：缺乏利益相关者的支持和不充分的积极规划。
根据 Rexer Analytics 的调查，这些是问题“在你的组织和/或你的客户组织中，模型部署的主要障碍是什么？”的前十名答案：
决策者不愿意批准对现有业务的变更
缺乏充分的、积极的规划
缺乏正确执行部署的理解
评分模型所需的数据可用性问题
没有指定人员负责部署
员工不愿意或无法有效使用模型输出
在计算分数或将模型或其分数实施/集成到现有系统中的技术障碍
隐私/法律问题
模型性能被决策者认为不够强
无法提供决策者所需的模型透明度
管理利益相关者是棘手的，因为许多决策者没有人工智能背景；他们可能受到头条新闻或之前的软件经验的影响，低估了机器学习的风险和不确定性。这就是人工智能专家真正发挥作用的地方。这不仅仅是关于构建模型，还关于确保你的利益相关者了解你的 AI 项目的正确期望。
这意味着我们的工作包括教育。利益相关者需要了解机器学习是如何学习的（以及为什么数据管道很重要），为什么机器学习项目本质上是不确定的，模型限制（声誉和安全风险），以及构建和部署的实际成本。
还有管理和规划机器学习项目的问题。三个指导原则脱颖而出：
定义一个清晰的最小可行产品（MVP），并设定一个简单的优化目标。通常，从简单开始比从复杂开始表现更好。
尽早构建端到端，使 A/B 测试成为可能，并尽快获得生产反馈。
根据反馈快速迭代，重新审视目标，并根据需要扩展数据。
（来源：作者）
我看到的一个有效策略是将项目孵化器（用于早期的高风险赌注）与产品线（用于扩展经过验证的解决方案）分开。这在管理风险的同时实现了创新。
这里的关键要点是，管理机器学习项目与管理工作传统软件工程项目不同。我们需要适应这些主要挑战，以确保你的团队可以从非技术角度获得支持。
结论
虽然没有方法可以保证我们能避免所有错误，但我们可以在现实中考虑一些原则或最佳实践。我们希望选择一个可行、可取且有利可图的项目。我们希望以数据为中心。此外，我们希望鼓励早期合作和积极管理跨职能团队。我们希望快速构建端到端解决方案以进行测试。我们希望根据机器学习项目的性质调整你的项目管理计划。
这只是机器学习项目可能失败的部分原因列表，还有许多其他原因，但它可以作为我们启动讨论的良好起点。我想以我最喜欢的查理·芒格的一句引语结束：“尽可能从自己的个人经历中学习一切，尽量减少从他人的好经验或坏经验中间接学习，无论是活着的还是死去的”。
原文链接：
https://www.infoq.com/articles/why-ml-projects-fail-production/
