项目开始之前

在一个机器学习项目开始之前，必须先对它进行优先级排序（prioritization）。优先级排序是不可避免的：团队和设备的能力有限，而组织积压的项目可能很长。

要对项目进行优先级排序，就必须估算其复杂度。对于机器学习，准确的复杂度估算几乎不可能做到，因为存在重大的未知因素，例如：所需的模型质量在实践中是否能够达到、需要多少数据、需要哪些特征以及多少特征。

此外，机器学习项目必须有明确定义的目标。基于项目的目标，可以恰当地调整团队并配置资源。

在本章中，我们讨论这些以及相关的、必须在机器学习项目开始之前处理好的活动。

2.1 机器学习项目的优先级排序

机器学习项目优先级排序的关键考量是影响（impact）和成本（cost）。

2.1.1 机器学习的影响

在更广泛的工程项目中使用机器学习，其影响是高的，当：1) 机器学习可以取代工程项目中的一个复杂部分，或 2) 获得廉价（但可能不完美）的预测能带来巨大的好处。

例如，现有系统的一个复杂部分可能是基于规则的（rule-based），包含许多嵌套规则和例外情况。构建和维护这样的系统可能极其困难、耗时且容易出错。当软件工程师被要求维护系统的该部分时，它也可能成为重大挫败感的来源。这些规则能否通过学习获得，而不是逐条编写？能否利用现有系统轻松生成标注数据（labeled data）？如果可以，这样的机器学习项目将具有高影响和低成本。

廉价且不完美的预测可能很有价值，例如在调度大量请求的系统中。假设许多此类请求是"简单"的，可以用某些现有自动化快速解决。其余请求被认为是"困难"的，必须人工处理。

一个基于机器学习的系统，如果能够识别"简单"任务并调度给自动化处理，将为人类节省大量时间，他们只需把精力和时间集中在困难请求上。即使调度器在预测中出错，困难请求也会到达自动化环节，自动化会在它上面失败，人类最终仍会收到该请求。如果人类错误地收到了一个简单请求，也没有问题：这个简单请求仍然可以发送给自动化，或由人类处理。

2.1.2 机器学习的成本

三个因素极大地影响机器学习项目的成本：

• 问题的难度，
• 数据的成本，以及
• 对准确率（accuracy）的需求。

以正确的数量获得正确的数据可能非常昂贵，特别是涉及人工标注（manual labeling）时。对高准确率的需求可能转化为获取更多数据或训练更复杂模型的要求，例如深度神经网络（deep neural network）的独特架构或非平凡的集成架构（ensembling architecture）。

当你考虑问题的难度时，主要的考量是：

• 是否有已实现的算法或软件库能够解决该问题（如果有，问题就大大简化了），
• 是否需要大量的计算能力来构建模型或在生产环境中运行它。

成本的第二个驱动因素是数据。必须做出以下考量：

• 数据能否自动生成（如果可以，问题就大大简化了），
• 人工标注数据的成本是多少（即为未标注示例分配标签（label）的成本），
• 需要多少示例（通常这无法提前知道，但可以从已知的已发表结果或组织自身的经验中估算）。

最后，最具影响力的成本因素之一是模型的期望准确率。机器学习项目的成本随准确率要求超线性增长，如图 1 所示。当模型部署到生产环境中时，低准确率也可能成为重大损失的来源。需要考量的有：

• 每一次错误预测的代价有多大，以及
• 模型变得不切实际的最低准确率水平是多少。

2.2 估算机器学习项目的复杂度

对于机器学习项目，除了与组织执行过的其他项目或文献中报道的项目进行比较之外，没有标准的复杂度估算方法。

2.2.1 未知因素

有几个主要的未知因素，除非你过去做过类似项目或读过相关项目，否则几乎不可能有把握地猜测。这些未知因素是：

图 1：成本随准确率要求的超线性增长。

• 所需的质量在实践中是否能够达到，
• 要达到所需质量需要多少数据，
• 需要哪些特征以及多少特征，才能使模型充分学习和泛化，
• 模型应该有多大（这对神经网络和集成架构尤其重要），以及
• 训练一个模型需要多长时间（换句话说，运行一次实验需要多少时间），以及达到期望性能水平需要多少次实验。

有一件事你几乎可以肯定：如果所需的模型准确率（我们将在第 5 章的 ?? 节中讨论的一种流行的模型质量指标）高于 99%，你可以预期会出现与标注数据数量不足相关的复杂情况。在某些问题中，即使 95% 的准确率也被认为很难达到。（当然，这里我们假设数据是平衡的，即不存在类别不平衡（class imbalance）。我们将在下一章的 ?? 节中讨论类别不平衡。）

另一个有用的参照是人类在该任务上的表现。如果你希望模型表现得和人类一样好，这通常是一个难题。

2.2.2 简化问题

做出更有根据的猜测的一种方法是简化问题，先解决一个更简单的问题。例如，假设问题是把一组文档分类到 1000 个主题中。先做一个试点项目，只关注 10 个主题，把属于其他 990 个主题的文档视为"其他"（Other）。1 为这 11 个类别（10 个真实主题，加上"其他"）人工标注数据。这里的逻辑是，人类只需记住 10 个主题的定义，比记住 1000 个主题之间的区别要简单得多。2

一旦你把问题简化为 11 个类别，就解决它，并测量每个阶段的时间。一旦你看到 11 个类别的问题可以解决，你就有理由期望 1000 个类别的问题也能解决。你保存的测量结果可以用来估算解决完整问题所需的时间，尽管你不能简单地把这个时间乘以 100 来得到准确的估计。学习区分更多类别所需的数据量通常随类别数量超线性增长。

从一个可能复杂的问题中获得更简单的问题的另一种方法，是利用现有数据中的自然切片（slice），把问题拆分成几个简单的问题。例如，假设一个组织在多个地点有客户。如果我们想训练一个预测客户某些属性的模型，我们可以尝试只针对一个地点、或针对特定年龄段的客户来解决这个问题。

2.2.3 非线性进展

机器学习项目的进展是非线性的。预测误差通常在开始时下降得很快，但随后进展逐渐放缓。3 有时你看不到任何进展，于是决定添加可能依赖于外部数据库或知识库的新特征。当你在开发新特征或标注更多数据（或外包这项任务）时，模型性能不会取得任何进展。

由于这种进展的非线性，你应该确保产品负责人（product owner）（或客户）理解这些约束和风险。仔细记录每项活动并跟踪所花的时间。这不仅有助于汇报，也有助于将来估算类似项目的复杂度。

1 把属于 990 个类的示例放入一个类，很可能会创建一个高度不平衡的数据集。如果是这种情况，你会倾向于对"其他"类中的数据进行欠采样（undersample）。我们将在下一章的 ?? 节中讨论数据欠采样。

2 为了节省更多时间，可以对整个未标注文档集合应用聚类（clustering），只人工标注属于一个或几个聚类的文档。

3 80/20 经验法则往往适用：80% 的进展是用最初的 20% 的资源取得的。

2.3 定义机器学习项目的目标

机器学习项目的目标是构建一个解决或帮助解决业务问题的模型。在项目内部，模型通常被视为一个黑盒（black box），由输入（或多个输入）和输出（或多个输出）的结构，以及最低可接受的性能水平（以预测准确率或其他性能指标（performance metric）衡量）来描述。

2.3.1 模型能做什么

模型通常被用作服务于某种目的的系统的一部分。特别是，模型可以在更广泛的系统中用于：

• 自动化（automate）（例如，代表用户采取行动，或在服务器上启动或停止特定活动），
• 提醒或提示（alert or prompt）（例如，询问用户是否应采取某项行动，或询问系统管理员流量是否可疑），
• 组织（organize），以可能对用户有用的顺序呈现一组条目（例如，按与查询的相似度或根据用户偏好对图片或文档排序），
• 标注（annotate）（例如，为显示的信息添加上下文注释，或在文本中突出显示与用户任务相关的短语），
• 提取（extract）（例如，在更大的输入中检测较小的相关信息片段，如文本中的命名实体（named entity）：专有名称、公司或地点），
• 推荐（recommend）（例如，基于条目的内容或用户对过去推荐的反应，在大型集合中检测并向用户展示高度相关的条目），
• 分类（classify）（例如，把输入示例分派到预定义的一组具有不同名称的组中的一个或几个中），
• 量化（quantify）（例如，给对象（如房屋）分配一个数字（如价格）），
• 合成（synthesize）（例如，生成与集合中对象相似的新文本、图像、声音或其他对象），
• 回答明确的问题（answer an explicit question）（例如，“这段文本描述的是那张图片吗？“或"这两张图片相似吗？"），
• 转换其输入（transform its input）（例如，为可视化目的降低其维度、把长文本改写为短摘要、把句子翻译成另一种语言，或通过应用滤镜来增强图像），
• 检测新颖性或异常（detect a novelty or an anomaly）。

几乎任何可以用机器学习解决的业务问题，都可以定义成与上述列表类似的形式。如果你不能把你的业务问题定义成这样的形式，那么机器学习很可能不是你这种情况的最佳解决方案。

2.3.2 成功模型的属性

一个成功的模型具有以下四个属性：

• 它满足输入和输出规范以及性能要求，
• 它为组织带来好处（通过成本降低、销售额或利润增加来衡量），
• 它帮助用户（通过生产力、参与度和情感（sentiment）来衡量），
• 它具有科学严谨性（scientifically rigorous）。

科学严谨的模型的特点是行为可预测（对于与训练所用示例相似的输入示例）且可复现（reproducible）。前一个属性（可预测性）意味着，如果输入特征向量来自与训练数据相同的值分布，那么模型平均必须犯与训练时在留出数据（holdout data）上观察到的相同百分比的错误。后一个属性（可复现性）意味着，使用相同的训练数据、相同的算法和相同的超参数（hyperparameter）值，可以轻松地再次构建出具有类似属性的模型。“轻松"一词意味着重建模型不需要额外的分析、标注或编码，只需要计算能力。

在定义机器学习的目标时，确保你解决的是正确的问题。举一个目标定义错误的例子：想象你的客户养了一只猫和一只狗，需要一个让猫进屋但把狗挡在门外的系统。你可能会决定训练一个模型来区分猫和狗。然而，这个模型也会让任何猫进屋，而不仅仅是他们的猫。或者，你可能会决定，因为客户只有两只动物，你将训练一个区分这两只动物的模型。在这种情况下，因为你的分类模型是二元的，浣熊会被分类为狗或猫。如果它被分类为猫，它就会被放进屋里。4

为机器学习项目定义单一目标可能具有挑战性。通常，在一个组织内部，会有多个利益相关者对项目感兴趣。一个显而易见的利益相关者是产品负责人。假设他们的目标是让用户在网上平台上花费的时间至少增加 15%。与此同时，执行副总裁希望广告收入增加 20%。此外，财务团队希望每月云账单降低 10%。在定义机器学习项目的目标时，你应该在这些可能相互冲突的要求之间找到正确的平衡，并把它们转化为对模型输入和输出、成本函数（cost function）和性能指标的选择。

2.4 组建机器学习团队

根据组织的不同，组建机器学习团队有两种文化。

4 这就是为什么在分类问题中设置"其他"类几乎总是一个好主意。

2.4.1 两种文化

一种文化认为，机器学习团队必须由与软件工程师密切合作的数据分析师（data analyst）组成。在这种文化中，软件工程师不需要有深厚的机器学习专业知识，但必须理解数据分析师同事的词汇。

根据另一种文化，机器学习团队中的所有工程师都必须兼具机器学习和软件工程技能。

每种文化都有利弊。前者的支持者说，每个团队成员都必须在自己所做的事情上做到最好。数据分析师必须是许多机器学习技术的专家，并对理论有深刻的理解，才能快速、以最小的努力为大多数问题提出有效的解决方案。同样，软件工程师必须对各种计算框架有深刻的理解，并能够编写高效且可维护的代码。

后者的支持者说，科学家很难融入软件工程团队。科学家更关心他们的解决方案有多准确，往往提出不切实际、无法在生产环境中有效执行的解决方案。此外，因为科学家通常不编写高效、结构良好的代码，他们的代码必须由软件工程师重写为生产代码；根据项目的不同，这可能变成一项艰巨的任务。

2.4.2 机器学习团队的成员

除了机器学习和软件工程技能之外，机器学习团队还可以包括数据工程（data engineering）专家（也称为数据工程师（data engineer））和数据标注（data labeling）专家。

数据工程师是负责 ETL（Extract, Transform, Load，提取、转换、加载）的软件工程师。这三个概念性步骤是典型数据管道（data pipeline）的一部分。数据工程师使用 ETL 技术，创建自动化管道，把原始数据转换为可分析的数据。数据工程师设计如何结构化数据，以及如何从各种来源集成数据。他们编写对数据的按需查询，或者把最频繁的查询包装成快速的应用程序编程接口（application programming interface，API），以确保数据分析师和其他数据消费者可以轻松访问数据。通常，不期望数据工程师了解任何机器学习。

在大多数大公司中，数据工程师在数据工程团队中独立于机器学习工程师工作。

数据标注专家负责四项活动：

• 根据数据分析师提供的规范，手动或半自动地为未标注示例分配标签，
• 构建标注工具，
• 管理外包的标注员，以及
• 验证标注示例的质量。

标注员（labeler）是负责为未标注示例分配标签的人。同样，在大公司中，数据标注专家可能被组织成两三个不同的团队：一个或两个标注员团队（例如，一个本地团队和一个外包团队）、一个软件工程师团队，外加一个负责构建标注工具的用户体验（user experience，UX）专家。

在可能的情况下，邀请领域专家（domain expert）与科学家和工程师密切合作。在关于模型输入、输出和特征的决策中，采纳领域专家的意见。问他们认为你的模型应该预测什么。仅仅因为你可以访问的数据允许你预测某个数量，并不意味着该模型对业务有用。

与领域专家讨论他们在数据中寻找什么来做出特定的业务决策；这将有助于你进行特征工程（feature engineering）。还要讨论客户为什么买单、什么对他们来说是交易破坏者（deal-breaker）；这将帮助你把业务问题转化为机器学习问题。

最后，还有 DevOps 工程师。他们与机器学习工程师密切合作，自动化模型部署、加载、监控以及偶尔或定期的模型维护。在较小的公司和初创公司中，DevOps 工程师可能是机器学习团队的一部分，或者机器学习工程师可能负责 DevOps 活动。在大公司中，从事机器学习项目的 DevOps 工程师通常在一个更大的 DevOps 团队中工作。一些公司引入了 MLOps 角色，其职责是将机器学习模型部署到生产中、升级这些模型，并构建涉及机器学习模型的数据处理管道。

2.5 机器学习项目为何失败

根据 2017 年至 2020 年间进行的各种估计，74% 到 87% 的机器学习和高级分析（advanced analytics）项目失败或没有进入生产。失败的原因从组织层面到工程层面不等。在本节中，我们考虑其中影响最大的原因。

2.5.1 缺乏有经验的人才

截至 2020 年，数据科学（data science）和机器学习工程都是相对较新的学科。仍然没有标准的教学方法。大多数组织不知道如何招聘机器学习专家，也不知道如何比较他们。市场上大多数可用人才是完成了一门或几门在线课程、没有大量实践经验的人。相当大一部分从业者在课堂环境中的玩具数据集（toy dataset）上获得了肤浅的机器学习专业知识。许多人对整个机器学习项目生命周期没有经验。另一方面，组织中可能存在的经验丰富的软件工程师，不具备恰当处理数据和机器学习模型的专业知识。

2.5.2 缺乏领导层的支持

正如上一节关于两种文化的讨论，科学家和软件工程师通常有不同的目标、动机和成功标准。他们的工作方式也非常不同。在典型的敏捷（Agile）组织中，软件工程团队以冲刺（sprint）为单位工作，有明确定义的预期交付物，不确定性很小。

另一方面，科学家在高度不确定性的环境中工作，通过多个实验向前推进。大多数此类实验不会产生任何交付物，因此，在缺乏经验的领导者看来，这可能被视为没有进展。有时，在模型构建并部署之后，整个过程必须重新开始，因为模型没有带来业务所关心的指标如预期的提升。同样，这可能导致领导层认为科学家的工作浪费了时间和资源。

此外，在许多组织中，负责数据科学和人工智能（artificial intelligence，AI）的领导者，尤其是副总裁级别的，具有非科学甚至非工程的背景。他们不知道 AI 是如何工作的，或者对它有非常肤浅或过于乐观的理解，这种理解来自大众来源。他们可能有这样一种心态：只要有足够的资源（技术和人力），AI 就可以在短时间内解决任何问题。当快速进展没有发生时，他们很容易责怪科学家，或者完全对 AI 失去兴趣，认为它是一种效果难以预测、结果不确定的无效工具。

通常，问题在于科学家无法向上层管理传达结果和挑战。因为他们不共享词汇，技术专长水平也大不相同，即使一个展示得很糟糕的成功，也可能被视为失败。

这就是为什么在成功的组织中，数据科学家是优秀的普及者（popularizer），而负责 AI 和分析的高层管理者通常有技术或科学背景。

2.5.3 缺少数据基础设施

数据分析师和科学家与数据打交道。数据的质量对机器学习项目的成功至关重要。企业数据基础设施必须为分析师提供获取高质量训练数据的简单方法。同时，基础设施必须确保一旦模型部署到生产中，类似质量的数据也将可用。

然而，在实践中，情况往往并非如此。科学家使用各种临时（ad-hoc）脚本获取训练数据；他们还使用不同的脚本和工具来组合各种数据源。一旦模型准备好，结果发现，使用现有的生产基础设施，无法足够快地（或完全无法）为模型生成输入示例。我们将在第 3 章和第 4 章中广泛讨论数据和特征的存储。

2.5.4 数据标注挑战

在大多数机器学习项目中，分析师使用标注数据。这些数据通常是定制的，因此标注是专门为每个项目执行的。截至 2019 年，根据一些报告，5 多达 76% 的 AI 和数据科学团队自己标注训练数据，而 63% 的团队构建自己的标注和注释自动化技术。

这导致熟练的数据科学家花费大量时间进行数据标注和标注工具开发。这是有效执行 AI 项目的主要挑战。

一些公司把数据标注外包给第三方供应商。然而，如果没有适当的质量验证，这些标注数据可能质量低下或完全错误。为了保持跨数据集的质量和一致性，组织必须投资于对内部或第三方标注员进行正式和标准化的培训。这反过来可能拖慢机器学习项目。不过，根据同样的报告，外包数据标注的公司更有可能把机器学习项目推进到生产。

2.5.5 孤岛式组织与协作缺乏

机器学习项目所需的数据通常位于组织内的不同地方，具有不同的所有权、安全约束和不同的格式。在孤岛式（siloed）组织中，负责不同数据资产的人可能互不认识。当某个部门需要访问存储在其他部门的数据时，缺乏信任和协作会导致摩擦。此外，一个组织的不同分支通常有自己的预算，因此协作变得复杂，因为任何一方都没有兴趣花自己的预算去帮助对方。

即使在一个组织的一个分支内，通常也有几个团队在机器学习项目的不同阶段参与。例如，数据工程团队提供对数据或单个特征的访问，数据科学团队负责建模，ETL 或 DevOps 负责部署和监控的工程方面，而自动化和内部工具团队开发持续模型更新的工具和流程。参与团队中任何一对之间缺乏协作，都可能导致项目长时间冻结。团队之间不信任的典型原因是工程师不了解科学家使用的工具和方法，以及科学家缺乏（或干脆无视）软件工程良好实践和设计模式的知识。

2.5.6 技术上不可行的项目

由于许多机器学习项目的高成本（源于高专业知识和基础设施成本），一些组织为了"收回投资”，可能瞄准非常雄心勃勃的目标：彻底改造组织或产品，或提供不切实际的投资回报（return on investment）。这导致非常大规模的项目，涉及多个团队、部门和第三方之间的协作，并把这些团队推向极限。

5 Alegion 和 Dimensional Research，《What data scientists tell us about AI model training today》（数据科学家告诉我们关于当今 AI 模型训练的情况），2019 年。

其结果是，这种过于雄心勃勃的项目可能需要数月甚至数年才能完成；一些关键人物，包括领导者和核心科学家，可能会对项目失去兴趣，甚至离开组织。项目最终可能被降低优先级，或者，即使完成了，也可能太晚进入市场。最好至少在开始时专注于可完成的项目，涉及团队之间简单的协作、易于界定范围、并瞄准简单的业务目标。

2.5.7 技术团队与业务团队缺乏对齐

许多机器学习项目开始时，技术团队对业务目标没有清晰的理解。科学家通常把问题定义为具有技术目标的分类或回归（regression），例如高准确率或低均方误差（mean squared error）。如果没有业务团队对业务目标实现情况（例如点击率（click-through rate）或用户留存（user retention）的提升）的持续反馈，科学家们往往达到模型性能的初始水平（根据技术目标衡量），然后他们不确定自己是否在取得有用的进展，以及额外的努力是否值得。在这种情况下，项目最终被搁置，因为时间和资源被花掉了，但业务团队没有接受结果。

2.6 小结

在机器学习项目开始之前，必须对它进行优先级排序，并且必须组建项目团队。机器学习项目优先级排序的关键考量是影响和成本。

使用机器学习的影响是高的，当：1) 机器学习可以取代工程项目中的一个复杂部分，或 2) 获得廉价（但可能不完美）的预测能带来巨大的好处。

机器学习项目的成本受三个因素的高度影响：1) 问题的难度，2) 数据的成本，3) 所需的模型性能质量。

除了与组织执行过的其他项目或文献中报道的项目进行比较之外，没有标准的机器学习项目复杂度估算方法。有几个几乎不可能猜测的主要未知因素：所需的模型性能水平在实践中是否能够达到，达到该性能水平需要多少数据，需要哪些特征以及多少特征，模型应该有多大，运行一次实验需要多长时间，以及达到期望性能水平需要多少次实验。

做出更有根据的猜测的一种方法是简化问题，解决一个更简单的问题。

机器学习项目的进展是非线性的。误差通常在开始时下降很快，但随后进展放缓。由于这种进展的非线性，最好确保客户理解约束和风险。仔细记录每项活动并跟踪所花的时间。这不仅有助于汇报，也有助于估算将来类似项目的复杂度。

机器学习项目的目标是构建一个解决某个业务问题的模型。特别是，模型可以在更广泛的系统中用于自动化、提醒或提示、组织、标注、提取、推荐、分类、量化、合成、回答明确的问题、转换其输入，以及检测新颖性或异常。如果你不能把机器学习的目标定义为这些形式之一，那么机器学习很可能不是最佳解决方案。

一个成功的模型 1) 满足输入和输出规范以及最低性能要求，2) 为组织和用户带来好处，3) 具有科学严谨性。

根据组织的不同，组建机器学习团队有两种文化。一种文化认为，机器学习团队必须由与软件工程师密切合作的数据分析师组成。在这种文化中，软件工程师不需要有深厚的机器学习专业知识，但必须理解数据分析师或科学家同事的词汇。根据另一种文化，机器学习团队中的所有工程师都必须兼具机器学习和软件工程技能。

除了拥有机器学习和软件工程技能之外，机器学习团队还可以包括数据标注专家和数据工程专家。DevOps 工程师与机器学习工程师密切合作，自动化模型部署、加载、监控以及偶尔或定期的模型维护。

机器学习项目可能因许多原因而失败，实际上大多数项目确实如此。失败的典型原因是：

• 缺乏有经验的人才，
• 缺乏领导层的支持，
• 缺少数据基础设施，
• 数据标注挑战，
• 孤岛式组织与协作缺乏，
• 技术上不可行的项目，以及
• 技术团队与业务团队缺乏对齐。

Machine Learning ENGINEERING

Andriy Burkov

“从理论上讲，理论与实践之间没有区别。但在实践中，是有区别的。"——本杰明·布鲁斯特（Benjamin Brewster）

“完美的项目计划是可能的，只要先把所有未知因素的清单记录下来。"——比尔·兰利（Bill Langley）

“筹款时是 AI，招聘时是机器学习（ML），实施时是线性回归，调试时是 printf()。"——巴伦·施瓦茨（Baron Schwartz）

本书按"先读后买"原则发行。