为什么大多数机器学习项目无法达到生产以及如何击败赔率

成绩单

ZI：我很幸运能选择机器学习作为我10年前的领域。之后，我一直以应用科学家和机器学习工程师的身份留在该行业，更倾向于建模方面。目前，我是Grammarly的高级机器学习工程师。除了工作之外，我还在多伦多大学教深度学习，证书计划。今年，我还共同创立了多伦多AI从业者网络。这是一个本地的AI聚会小组，我们邀请数百名从业者一起谈论AI，交流想法等等。您以前从事过任何机器学习项目？您是否从事未能生产的机器学习项目？

机器学习项目的故障率

我反思自己的旅程。最近，我最近从几个不同的领域，社交媒体平台，金融科技解决方案和生产力工具从事机器学习项目。他们中的一些人成功获得了生产。他们中的许多人没有。即使每个项目都教会了我一些有趣的东西，而且我能够学习一些精美的技术，但这并不是世界上最好的感觉，您倾心的是最终会产生我们所希望的影响。这促使我探索一个关键问题，例如，我一个人的感觉吗？问题有多严重？事实证明，在这个主题上正在进行一些调查，尽管较旧的研究报告的失败率高达85％，但大多数最近的数据都讲述了一个相当相似的故事。

我在这里显示的图形是Rexer Analytics在2023年进行的研究。您可以看到他们对300多名机器学习从业人员进行了研究，只有32％的人表示他们的项目达到了生产。确切的数字可能因行业而异，这取决于您在哪里工作。许多大型科技公司，他们已经采用了很长时间的AI，因此那里有很多经验。对于像银行业或企业或初创公司这样的传统行业，他们的旅程仍在进行中，并且他们仍在逐步采用更有效和无缝的AI采用。在我们深入讨论之前，我只想认识到并非所有失败本质上都是坏事的事物。机器学习项目通常具有很高的不确定性，因为它是实验性的。

在很多时候，如果可以通过机器学习来修复某些事情，我们将无法得出结论，然后才真正弄脏手，探索数据并尝试一些基线模型。如果您的团队能够进行一些初步研究并迅速确定没有足够的积极信号供您进一步投资于生产，您决定枢转，或者您决定杀死该项目，实际上应该将其视为成功而不是失败，应该庆祝。该原则到处都被采用，称为失败。我认为这对于鼓励良好的创新也至关重要。在谈话中，我们将重点关注不良失败。

由于失败，我的意思是，项目拖延了很长时间，无法在没有明确定义的情况下得出结论，即使性能相当不错，也从未进行过生产的模型。最后，即使我们将模型应用于生产后，也无法采用的解决方案。我们想回答的黄金问题是什么，什么导致了这些机器学习项目的失败？

大纲

我们将从快速概述机器学习项目生命周期的外观以及它与普通软件项目有何不同。了解此过程对我们了解这些失败的确切位置将有所帮助。然后，我们将通过例子深入五个常见的陷阱，以及我的一些想法，例如，我们在哪里可以减少遇到这些问题的机会？最后，我们将总结一下摘要。

机器学习项目生命周期的概述

让我们看一下机器学习项目生命周期。在此图上，它显示了机器学习项目生命周期的六个步骤。这是一个高级，简化的概述，因此魔鬼在我们这里没有显示的细节中。通常，我们首先要确定要优化的业务目标是什么，我们需要根据这个业务目标来构建机器学习项目。一旦概述了机器学习问题，我们就需要介绍数据，探索它，处理数据，以便我们可以使用处理后的数据来训练不同的模型。

一旦对模型进行了训练，希望您会找到一个候选模型，我们认为该模型的性能足够出色，以至于我们想要部署和使用生产线来监视模型的性能。我们从监视过程中获得的反馈将用于完善整个系统。这就是迭代的发生方式。有两个明显的观点值得一提。一个是漫长的多步骤过程。步骤之间和整个团队之间发生了很多切换，自然会增加由于这种复杂性而导致的风险。其次是机器学习项目是以数据为中心的优化问题，这些反馈信号，无论是来自模型，数据还是从监视过程中的反馈信号，都是我们要确保我们在需要的情况下确保我们利用的重要组件从事一个成功的项目。

五个常见的陷阱以及如何改进 - 解决错误的问题

对于我们要涵盖的五个常见陷阱，我想讨论的第一个陷阱是最关键的陷阱之一，就是努力优化一个错误的问题，并最终浪费了很多时间和精力。这是常见的事情吗？让我们回到这里进行的调查。从该图中，什么是在询问人们时，项目目标是在项目启动之前清楚定义的频率？他们中有29％的人回答说，他们以明确的定义开始，其中26％的人说这件事很少发生。缺乏最初的清晰度绝对是机器学习工程师在我们真正致力于一个项目之前战斗的普遍战斗。过去，迭代业务目标并因某种歧义而变化以启动项目实际上很普遍。

对于机器学习项目，这已成为一个更严重的问题。为了使我们了解这一点，我们需要探讨如何将业务目标转变为机器学习解决方案。当然，我们不想错过第一步，这是确定这是否与机器学习有关的问题。很多时候，您也许可以找到一个基于规则的解决方案，该解决方案效果很好，或者您只能将一些操作更改纳入系统，而不是尝试从头到尾探索机器学习解决方案。

一旦我们确保这是一个机器学习问题，这将用于大型翻译步骤。有几件事正在发生。为了解决机器学习问题，我们需要确定什么是什么，使我们可以从中提取信号。这是数据工程团队的一些繁重工作。其次是，我们通常需要训练一堆不同的模型，包括不同的模型架构和工具，使用不同的超参数以使我们找到哪种模型正常。如果我们谈论培训更复杂的模型，这通常涉及使用包括GPU在内的昂贵基础架构。

归根结底，我们试图优化的是数学定义的目标函数。该目标功能高度取决于我们要解决的业务目标类型。如您之前所看到的，枢轴或业务目标的迭代可能不会引起很多问题，但是现在，如果我们想迭代数据，数据，目标函数，甚至整个机器学习管道因此可能需要更新。这通常会导致大量工作被扔掉。这就是为什么要从一个良好的机器学习问题开始，我们通常想提出很多问题，以确保业务，团队非常致力于解决该特定问题。

这是我想与您分享的一个例子，就我们如何增加挑选一个获胜项目的机会而言。这是基于我过去在金融科技公司工作五年以上的经验。我与之合作的组织采用了这种集中的AI资源模型，这意味着所有团队都将前往该团队找到一些AI支持。如今，这种模型非常普遍，因为对许多公司的AI人才短缺仍然是一件事情。在所有具有AI用例的业务线路中，我们负担不起AI团队的负担。这给我们带来了一些独特的优势，但也带来了一些挑战，因为所有业务线都会说他们的项目是我们应该研究的最重要的项目，我们应该优先考虑，通常使用一些我们的财务术语可能会或可能不了解。

我们的团队需要开发一种特殊类型的技能，该技能在所有这些噪音中导航，并确定哪个项目值得投资，并且最终有更高的成功机会。在集中的AI团队中，我有了独特的视角，因为我可以看到该项目的选择和执行方式。全年，我能够从不同的业务领域从事许多不同类型的项目。对于股票研究人员，我们研究了一个特别的新闻建议系统，我们还研究了资本市场股票价格预测问题。从所有这些中，有一个明显的赢家。

整个公司以及我自己也是这个项目，最大的成功。我们为银行的个人和商业银行空间建立了一个可自我解释的预测模型。由于机密性，我无法告诉您解决方案的外观细节，但是如果我回头看，我可以看到三个非常关键的因素，这些因素会导致该项目的成功。第一个是该项目与P＆CB中的团队直接相关。对于在银行系统工作的人们，您可能会知道这是为银行赚钱的最大章节之一。从公司的角度来看，在这里做一些不同的事情。第二个因素是关于相互性的。我们正在开发的模型是端到端系统的一部分，该系统一直坐在那里并为银行服务了十多年。

使用了许多历史数据，那里有很多监视和报告。对于我们将这种模型运送到生产中，我们不需要端到端构建一些东西。我们需要交换模型，仅此而已。最后一个是ML可行性部分。银行使用的原始模型是一个相当简单的模型。如今，借助更复杂的技术，我们非常有信心，如果我们要尝试一些新的模型架构和一些新功能，那么我们可能会找到更好的解决方案。我认为，这三个因素是为该项目成功做出成功的关键因素。

在反思这一点上，我认为这对我们来说是一个成功的项目没有任何更大的理由，而且肯定没有纯粹的运气。最好的机器学习项目是达到最佳位置的项目。我认为重要的三个组成部分是盈利能力，可以从业务利益相关者那里建立，并且可以从技术角度解决。通过找到这些机会，您将能够从一些获胜的方向启动您的团队。找到这些机会并不是那么简单。通常，您需要向您的团队提出一些非常好的问题，以了解情况。

例如，目标是否明确定义，您的潜在利润是否可以证明您将要投入机器学习项目的成本是合理的？您正在做什么假设，甚至是现实的？您的模型可能会暴露出什么风险。如果您的团队在承诺从事该项目之前，请不要对团队感到恼火。您可以回答的这些问题越多，您就越有可能确定团队解决的正确问题。当然，这并不意味着我们不应该冒险。从这里的图表中可以看到，对于高影响力和低风险项目，这些被认为是低悬挂果，我们可以开始使用ML旅程，但是高影响力和高风险项目也值得追求。关键是要意识到我们承担的风险，并在其中建立一个平衡的投资组合。

只有当我们拥有平衡的投资组合时，您才能允许您的机器学习团队取得一些胜利，然后继续进行构建机器学习解决方案的迭代。这也使您可以证明该公司正在投入AI基础架构以及他们正在雇用的所有AI才能的成本。我们还需要一些高风险的项目才能到达那里，因为我们要确保您有机会能够在末尾构建一些更改游戏的解决方案，而短期内而没有任何奖金。

总而言之，启动机器学习项目只是因为其他人都在这样做，或者因为从技术上讲，这是不够的。我们希望花时间与不同的团队合作，以确保我们选择的项目是理想的，有利可图的，而且可行的，并开始良好，并为我们的团队奠定了良好的基础。

数据引起的挑战

我要讨论的第二个问题是数据引起的挑战。这可能是最常见的陷阱之一，也是您的团队最抱怨的陷阱之一。数据在哪里？我们可以处理大量数据处理吗？即使该公司已经在解决这些问题方面投入了很多资金，但这并不意味着没有其他隐藏的挑战会使您的项目最终受到伤害。机器学习世界中有一个著名的谚语，垃圾进了，垃圾出去。机器学习项目完全取决于从数据中识别模式。如果数据有缺陷，那么您从这项研究中发现的结论很可能就不会被信任。

在右边，有一个说明性的示例，您可以直观地理解为什么此数据问题可能是一个问题。示例是，让我们尝试找到代表整个数据集的平均点。顶部是一个没有删除异常值的一个。如您所见，平均值被抓住到异常值的方向，这可能不是一般数据的良好表示。删除异常值后，您将能够获得更好的结果。这只是一个简单的示例，即在进行任何学习之前，要在此之前进行一些数据清洁是多么重要。

多年来，机器学习社区为数据管道开发了一些标准结构，从数据收集，数据处理以及功能工程开始。人们通常还有一系列常见的任务清单，这些任务通常是为了进行数据准备，从重复，离群值，填写丢失的数据，重新采样数据以处理不平衡问题的数据开始。现在，每个正确的机器学习团队基本上都会改编标准程序，以供他们介绍他们的数据。这只是刮擦表面，这还远远不够。这是为什么？如果您有兴趣，则有一个GITHUB存储库，称为机器学习失败，您将能够看到人们确定的一长串失败的机器学习解决方案，也可以公开适合所有人。

这些案例中的大多数因与数据相关的原因而失败。即使所有解决方案都是由应该是机器学习专家的大型科技公司或大学研究人员开发的，但它们不能免疫涉及数据的错误。

这是其中之一。这是2022年普林斯顿大学进行的一项研究。他们仔细研究了22篇论文，同行评审，其中包含损害结果的关键陷阱。在17个不同领域的290篇论文中，有290多篇论文采用了这种陷阱。这意味着，这类问题对于我们来说是非常严重的，在伤害真正重要的事情之前，要看一下。每本失败的纸张中，一个关键问题与数据泄漏部分有关。以最简单的形式，数据泄漏意味着出于某种原因，我们可能会将一部分测试数据输入我们的培训数据中，并使模型具有错误的成功感。

实际上，数据泄漏的定义更为复杂。就像这里的论文中列出的一样，普林斯顿大学的研究人员能够将数据泄漏分为八种不同类型的类别，从混合培训数据和测试数据到采样偏见，甚至超越此。不同类型的数据泄漏的并发症使我们很难尽早识别并从一开始就防止它。我们在幻灯片上看到的另一个例子是在NIH Healthcare领域。我不知道您是否记得大流行的早期，当时有很多人工智能成为新闻头条新闻，说他们能够识别或诊断疾病。对于许多机器学习从业人员来说，这是自豪的工作。

但是，来自英国的研究人员对正在发表的研究进行了仔细的研究，在606个模型中，声称他们可以诊断为covid，其中只有2个具有足够的结果，可以信任并转移到测试阶段。这甚至是在临床使用之前。所有其他型号都是完全没有用的。主要问题再次是与数据有关的。在所有600个型号中，其中400多个正在接受数据样本不足的培训，并将对结论提出一些偏见。这就是为什么我们将无法信任结果并进一步进行过程的原因。这是我们了解了数据质量的重要性及其如何损害您的机器学习项目的另一个苛刻但必不可少的教训。

数据准备工作通常就像探索冰山。您在表面上看到的只是开始。许多问题，尤其是与您自己的数据有关的问题，都隐藏在下面。但是，您可能会要求自己尝试消除一些风险。您是否正在收集代表模型正在访问的现实世界数据的数据？您是否避免了将未来数据泄漏到培训数据中的风险？这两个点是我们从以前的示例中介绍的。挑战并没有停止。在大型组织中，数据筒仓也是一个大问题。团队可能不知道我们能够用于训练模型的所有功能，这将导致团队得出错误的结论，即问题可能无法解决。实际上，它实际上是有些数据没有被忽略的。

最后，我们还想涵盖其他一些大主题，这些主题被标记为数据。标记数据在机器学习中起着至关重要的作用。对于模型学习的角度，我们需要标记的数据来提取信号并优化模型。从评估的角度来看，我们需要标记的数据，以了解模型的性能以及问题的状况，因此我们可以迭代解决这些问题。即使现在有第三方供应商提供了许多AI数据标签解决方案，试图使这一工作更简化，但这仍然需要您自己的团队大量努力。

通常，我们需要收集和标记一个金数据集，以便我们用来评估我们获得的注释质量，并为注释者提供了非常详细的指南，以便他们为他们提供简洁的标签结果。即使在所有这些预防工作之后，在一天结束时，您也许可以发现标记的数据仍然缺乏某些共识，并且无法将其用于模型培训。我敢肯定，如果您以前从事数据标签工作，那么您会了解现场的许多挫败感。随着模型服务或所有可用的预训练模型的兴起，这种挑战变得更加有趣。如该图在左侧所示，现在使用模型服务，我们可以通过仅调用外部API或使用一些预先训练的模型来完全跳过模型培训他们自己的数据集。

这绝对使我们能够比以前更快地提供解决方案。我记得参加社区讨论，每个人都在开发一些Genai解决方案。问题是，您如何评估LLM解决方案？房间的第一个反应是每个人都保持沉默。归根结底，他们所说的是，早期，他们只是在做人类的眼球，或者他们开始​​收集一小部分示例，以便他们对简单统计数据进行一些测试，以便他们有一个粗糙了解其性能。这是可以开始的，因为目前，每个人都害怕错过模式。我们想从门上推出一些Genai解决方案。稍后，这成为一个大问题，因为如果没有标记的数据供您了解模型的性能，就可以不断地反应地添加补丁。

会有一些下游用例，或者您的客户抱怨特定的用例，因此您可以在不知道该补丁对整个数据集的更广泛影响的情况下添加一些问题。它还可以阻止您收集大量数据，进行自己的模型培训，以便将来能够为您解决很多头痛。在本次会议上，您会看到其中的几个与LLM评估有关，并且您会看到为什么生成的AI变得非常痛苦。在我看来，也许一开始就可以跳过这一步骤，但是归根结底，我们仍然需要花费大量精力来制定该评估管道。

第二个组件的结论，虽然从一开始就无法完美地修复所有内容，但它仍然不能强调足够的时间来探索自己的数据，理解自己的数据，寻找新功能，清理数据集基于观察结果，而不是对其应用标准过程，而是投资收集高质量标签。最后，机器学习成功在很大程度上取决于数据。

难以将模型变成产品

我要突出的第三个问题是将机器学习模型变成生产的挑战。这种过渡不仅仅是部署代码。它需要更多的上下文和多次使该解决方案实现。当然，大量的挑战来自MLOP，我们中的许多人都提到了Google的标志性图，以表明这一点。您可以看到整个系统中机器学习代码的比例很少。大部分代码都来自支持基础架构，例如资源管理，服务系统，监视工具，日志记录等。对于那些从事机器学习项目的人来说，这可能就像是打回家。幸运的是，机器学习操作的景观已经发展了很多。我们可以利用的资源很多。

当然，对于初次采用的人来说，这听起来像是繁重的举重，但是当您逐渐开始建立自己的基础和自己的管道时，您就可以支持多个机器学习解决方案并无缝部署它们。要了解机器学习模型与基于机器学习的解决方案之间的差距，让我们以检索增强生成或抹布为例。在Genai时代，Rag引起了很多关注。

从本质上讲，它的作用是，它正在尝试帮助您，从您自己的数据库中提取上下文，并要求您的LLM以意识到此上下文回答问题。最好的部分是，如今，这是在计算机上本地运行的演示中需要工作的工作量。我们只需要利用一些OpenAI API，一些Langchain库和一个矢量数据库，您就可以查询自己的数据库并提出问题。

当涉及到支持生产的功能齐全的抹布系统时，例如，对于客户服务用例，是一个完全不同的故事。左边是Genai系统架构，我最喜欢的博客作者之一Chip Huyen总结了许多公司的Genai Solutions。对于生产解决方案，您需要问问自己并填写空白的一系列方面。

对于质量控制，您进行质量评估的方式是什么？您是否需要先进的抹布技术或代理抹布来提高质量，或者天真的抹布已经足够好了？对于客户信任，您是否需要将解决方案与解释性模型捆绑在一起，以便您的客户知道结果是如何生成的，而不是完全将其视为黑匣子？为了减少延迟，您是否正在做任何缓存？如果您在本地托管任何大型语言模型，您是否进行任何推理优化？此列表继续朝着数据隐私，旨在进行公平和偏见测试，以确保您正在执行负责任的AI。此外，要安全起见，您如何处理每个人在Genai World中谈论的幻觉和越狱问题。

总而言之，一个获胜的机器学习项目团队应具有跨职能，并在一开始紧密合作以形成。他们应该积极地根据要求并逐步解决此问题，而不仅仅是在孤岛中工作，并希望所有问题都将在以后解决。

离线成功，在线失败

第四，离线成功和在线失败。第四个常见的陷阱可能是引起球队最激动人心的浪潮的陷阱。当您有一个运转良好的离线模型，然后将其运送到生产中时，突然之间，它不再起作用了。为什么这种情况会发生？为了更好地了解这一点，我想向您展示有关离线培训和在线服务的图表。如果您可以看一下左侧，可以看到这是离线阶段中发生的事情。我们正在使用历史数据来训练自己的模型并使用离线评估指标对其进行评估。将模型部署到生产中后，我们将使用实时数据并浏览端到端解决方案，并评估我们在在线评估指标上的性能。考虑到此上下文，您可能可以清楚地看到这三个差异可能来自何处。

首先，我们使用的数据不同。一个是经常通过一些采样和清洁或增强来改变数据集的整个结构的历史数据。在生产方面，我们正在使用实时数据进行推理。第二个差异来自解决方案本身。团队通常专注于开发单个模型，而不是研究我们现实中我们使用的整个端到端解决方案。最后一个是我们正在进行的评估。对于离线培训，我们正在使用与机器学习密切合作的离线评估指标，而在在线阶段，我们正在使用与业务指标更加一致的在线评估指标。

让我分享一个例子。这是我多年前首次发行的产品。几年前，我们正在制作一个旨在将摄影师的作品推广到创意摄影社区的照片推荐系统。我们业务的主要担忧之一是，我们的新用户购物是他们来这里，注册，发布一张照片，而他们再也不会回来。考虑到这一点，我们的数据科学团队开始进行一些探索，并试图找出问题所在。他们发现在注册为新用户保留率后的短时间内，有多少个新用户会在很短的时间内获得高度相关性。有了这种见解，就要求一个机器学习团队尽快推广新用户的作品，以便他们可以得到想要的反应并返回我们的网站。

当时，大多数公司仍在依靠相对简单的推荐系统，该系统通常由这种称为协作过滤的技术提供支持。直观的理解显示在图中。对于用户A和用户B，如果他们以前喜欢很多相同的项目，我们认为它们具有相同的口味。然后，我们将尝试找到用户a喜欢的项目，但不受用户B的喜好，并将其作为用户B的建议。这也将解释我们的新用户无法获得的原因许多喜欢，在推荐系统中称为冷启动问题。因为新项目以前没有任何可见性或任何互动，并且建议纯粹基于照片的先前反应，因此新照片，他们真的很难获得第一群反应并获得卷。开始。

We decided to build an additional recommender engine to accommodate the cold-start problem that the collaborative filtering solution brings in, which is called content-based recommender system. What we did is we trained a classification model offline, trying to predict how popular a photo would be purely based on the content of the photo itself. In that case, when a new image comes in, we're able to identify whether this will be popular or not, right away, instead of waiting for the signals to come in. Once we have a good model performing for this classification task, we integrate it into this pipeline.

For user A, we're able to extract the historical behaviors of that user and find similar photos that the user liked before. These similar photos the user has never seen before will be filtered down by this popularity identification model that we built. In that case, we're reducing the chance that the low-quality photos will be recommended to the user, while keeping the content to be relevant to what they liked before.

Offline, what we optimize is the classification model. We're trying to predict the popularity of the images and see what's the accuracy we'll be able to get. When the model is integrated into the production system for A/B testing, we have some mixed signals. While the number of likes new users did receive, which we achieved our tasks in some ways, we also received some warnings from the major dashboard we used to monitor the health of the platform. We saw there's a drop of the average session length that our user is staying on our platform. It means, for some reason, our recommender system is causing a disturbing experience, and they don't want to keep scrolling our website anymore. This is a tough situation. Because it's my first launch, I remember feeling very anxious when there is focus group feedback rolling in, criticizing about what we built. It was a challenging moment.

We went through many rounds of iterations and eventually find a better way of incorporating this popularity prediction signal into the system. That was a long story afterwards. What to add is that the recommender system today has become way more complicated. There are so many models that are being involved for a single recommender system, and there's multi-steps that we're going through for making this happen. Besides the difference we talked about between offline evaluation and online evaluation, and also monitoring a set of business metrics instead of just one primary business metric we're trying to optimize, there's additional complications.

Once the model is integrated into production, it becomes part of the entire solution, a much larger system. We're combining output from many different kind of models, so an offline model that performs pretty well after the incorporation, because the model's output are not orthogonal to each other, the impact of that model may be diminishing after this merging. After we see there are so many ways why the offline success can turn into failure, what we want to emphasize is not to get stuck on overoptimizing incremental succeed in the offline models. What we really want to do is to allow the A/B testing to happen as soon as possible, so we can use this to test out if our optimization target offline is well aligned with the business goal we're really trying to optimize for.

Unseen Non-Technical Obstacles

The last point, which is one that often gets overlooked, is unseen non-technical obstacles. Are the non-technical obstacles really a big problem? This isn't just my opinion, it's also backed by data. Going back to the survey that we looked into before, when people were asked a very straightforward question, what are the main obstacles to deploy models at your organization or your client's organization? The most common answers people get, the top two are not related to technology at all. The first one is that decisionmakers or stakeholders are unwilling to provide the support that the project needed. The second is they have a general lack of active planning. These are non-technical roadblocks, these are organizational and communication blockers. Why is managing stakeholders tricky? Although there's a lot of enthusiasm for AI, especially from the leadership perspective nowadays, it doesn't guarantee that the decisionmakers are able to make the right decision.

The truth is that many stakeholders don't have AI backgrounds before, so they might be influenced by hearing a lot of the news about how AI is making a big impact and making the big wins for the company, without awareness of the risks and the failures they might cause. Also, they might be biased by their own experience managing non-AI traditional self-engineering projects in the past. This is where AI experts actually play a role. It's not just about building the model, it's also about making sure your stakeholder understands what is the right expectation to set for your AI projects.

Some key topics to explain might include how AI learns so they know why there's a heavy dependency on the data, and why we should invest heavily into the data process pipeline. The second question, why machine learning projects are inherently uncertain so they know what's the potential risk that the project will fail at the end. Third, the limitation of the models, so we won't launch a model to production without the business stakeholder means the potential reputation, the uncontrolled output might bring to the company. The realistic cost of building and deploying them, so the cost can be justified by the profit.

Let's talk about how to manage and plan these projects. There are three principles that really stand out. First, scope out an MVP with a clear and simple optimization goal. This helps the team to get focused and start doing their work, reducing their noises around the space. The truth is that starting with a simple baseline model can actually be a better situation than if you start with a more complicated model. Second, once you have MVP outlined, prioritize building an end-to-end solution so you can allow your team to do A/B testing and get the production feedback in place as soon as possible.

Finally, using these feedbacks to iterate and adapt your projects quickly. This might need you to redefine what's your project optimization targets, or adding more data into making your model better. One of the most effective strategies I've seen in the past is outlined here. There is a separation between a project incubator and the product line. In the project incubators, we can do early stage, high-risk idea testing. We use this as bets to figure out which are the models that are actually worth us investing longer term and form a full stack team to work on in the longer term. This approach allows your team to do innovations while managing the risk carefully. The key takeaway here is that managing machine learning projects is different than managing a traditional software engineering project. We need to adapt to these major challenges to make sure your team can get the support from the non-technical perspective.

概括

While there's no way to guarantee we'll avoid all the mistakes, there are some principles or best practice we might consider in reality. We want to choose a project that is feasible, desirable, and profitable. We want to be data centric. We want to encourage early collaboration and active management of cross-functional teams. We want to build an end-to-end solution soon for testing purposes. We want to adapt your project management plan based on the nature of machine learning projects.

This is just a very incomplete list among a lot of other reasons why a machine learning project may fail, but I hope this can be a good starting point for us to kickstart the discussion. I'd like to leave you with a favorite quote of my own, from Charlie Munger, "Learn everything you possibly can from your own personal experience, minimizing what you learn vicariously from the good and bad experiences of others, living and dead".

问答

Participant 1: You mentioned in your talk those business metrics that are used for evaluations. Could you maybe give some more examples of those business metrics? You mentioned retention or session length. What are some other common ones that are being used in your experience?

Zi: There are two types of evaluation metrics I think we should pay attention to. One is specifically about the thing we're optimizing for. For example, at Grammarly, we're doing the rewrite suggestion. One thing we definitely care a lot about is the accept rate. Like, how many of the suggestions we're giving got accepted by the user at the end? It reflected on the quality of the suggestion we're giving. The other metrics are more towards the major health of the entire platform. Like, how many people are buying Grammarly memberships, and how many times they're using Grammarly, for example? This is similar to all the other use cases. You want to make sure whatever you are optimizing for is not hurting the major business that your company is focusing on.

Participant 2: You mentioned the importance of evaluation in the lifecycle. I am just very curious to hear, how are you seeing the roles evolve. In traditional MLOps, evaluation was always like machine learning team, and now the roles are blurring in terms of ML engineering, software engineering, also PMs being more involved in the lifecycle. Who do you think is more responsible for evaluation, more broadly, how are you seeing that evolve?

Zi: I think the one that works best before is the combination. For example, the unit test. Machine learning people don't do a lot of unit tests, but nowadays it's actually pretty helpful. If you can collect a bunch of examples that are really valuable to your company, and when you're doing model iteration, you want to check all those tests are still passing. There's also machine learning metrics that we can use to evaluate the model. Some of them can be automatic or statistics based. In our team, linguistics will be the one working on those automatic metrics. Some are like learn the evaluation metrics that are more state of the art that were recently published. This requires paper ratings and implementation and experimenting before we push this into our major monitoring metrics. This mostly requires machine learning people to get more involved. At the end of the day, we'll use a combination of all these tests to make sure that things are going well.

查看更多presentations with transcripts