机器学习项目管理指南-全-

机器学习项目管理指南（全）

原文：Managing Machine Learning Projects

译者：飞龙

协议：CC BY-NC-SA 4.0

前置材料

前言

我无法确定一个时刻或编织一个令人信服的故事来解释我是如何意识到写一本关于如何管理机器学习项目的书是一件好事的。其核心在于，在 2019 年某个时候，我意识到我在与很多开始机器学习项目并陷入困境的人交谈，而且通常我知道原因。

没有一种常见的疾病或甚至一个单一的主题，而是失败似乎来自很多不同的方向。尽管这些项目的失败各不相同，但这里有一个共同的原因。领导这些项目的人有才能、聪明、善于表达和有技能，但他们缺乏经验。

我在职业生涯的时间安排上非常幸运。我进入机器学习领域时，它正处于应用的边缘。在 20 世纪 90 年代末，机器学习在野外，我们可以用我们的三层感知器和决策树做些真正的事情。交付起来要困难得多，算法需要手动编码，数据非常罕见，而且一切运行得非常慢。最重要的是，机器学习技能像需要它们的那些项目一样罕见，应用机器学习被视为研发。对我来说，这意味着我有机会发展和从事一个接一个的项目。大多数都失败了——但那些成功实施的项目真的非常成功。

那些罕见的成功让我继续工作，并推动了我的职业生涯。反过来，这支付了抵押贷款并填满了冰箱。事后看来，我可以说我现在认为，失败才是最有价值的。我有失败的奢侈和学习的经历，这在今天并不常被赋予人们。我还得到了加入经历相似的人们的社区的机会，我们都会喝得酩酊大醉，互相讲述悲伤（和有趣）的灾难故事。当时在那些大西方公司工作的 AI 研究人员圈子中，一些实践和行为成为了常识。我处于边缘，幸运地能够收集这一切，然后加以利用。

有了足够经验来引导一个或多个机器学习项目走向成功的运气，如果不分享这些经验那就太愚蠢了。机器学习和人工智能是能够用于善的目的的技术，希望有助于应对气候变化、流行病和经济困境。也许通过分享如何管理机器学习项目的知识，我可以帮助其他人完成几个让世界变得更美好的项目！

两件事情真正促使了这本书从想法变为现实。首先，我的上司安迪·罗斯特，当时告诉我，我的团队需要有一种方法论来向客户说明我们将如何解决他们的问题。我意识到我实际上无法指向一个具体的方法，所以我必须自己写一个。如果不是第二个事件——COVID-19 大流行——意味着我停止了长时间的旅行并开始有时间投入到写作中，那么这也许不会走得太远。

因此，这就是它。感谢你购买它。我希望你会发现它有用，最重要的是，我希望你能分享任何关于如何改进它的想法或思考，这样我下次就能做得更好。

致谢

任何写过书的人都知道这是一件不合理地困难的事情。我需要很多帮助。我的编辑道格·鲁德和曼宁团队超出了预期，帮助我把一大堆杂乱无章的手稿变成了我希望对读者更有用的东西。

我认为，任何没有与曼宁合作过的人都无法真正了解他们能带来多少价值。如果别人写了这本书，可能会更好，但如果没有曼宁的每一位成员所付出的努力，它将变得无法估量地糟糕。

曼宁安排了一个广泛的审稿过程，为我提供了匿名反馈，当然，我不知道谁做了哪篇评论，但每一篇评论都非常有价值：Andrei Paleyes、Chris Fry、Darrin Bishop、Florian Roscheck、Igor Vieira、João Dinis Ferreira、Kay Engelhardt、Khai Win、Kumar Abhishek、Lakshminarayanan AS、Laurens Meulman、Maria Ana、Marvin Schwarze、Mattia Di Gangi、Maxim Volgin、Ricardo Di Pasquale、Richard Dze、Richard Vaughan、Sanket Naik、Sriram Macharla、Vatsal Desai、Vojta Tuma、William Jamir Silva。你们提供的努力、对细节的关注和坦率、直接的反馈简直令人惊叹。

谢谢，如果我们在某次相遇时，请叫上我喝一杯啤酒或你喜欢的饮料。我确实欠你一个人情。

我非常幸运，在我的职业生涯中遇到了一些了不起的导师，我认为任何人都能做的最重要的事情之一就是找到一些人在你发展技能和能力时帮助你。

马克斯·布拉默教授在我成为博士研究生时给了我机器学习的惊人起点，我在 20 世纪 90 年代中期度过了四年精彩的探索，这改变了我的人生。

当保罗·奥布赖恩在 BT 实验室招聘我时，他承担了类似的风险。保罗是我的职业楷模，是我渴望成为的经理和导师。实际上，每当我工作中遇到问题时，我都会想“保罗会怎么做”。

另一件事，每个人都需要的是能够包容你的想法和独特思考的同事，指出你的错误，并分享他们的想法。为此，我特别感谢罗布·克拉克顿，他花了几百个小时与我讨论任何与数据科学、人工智能和机器学习相关的话题。在 BT、图灵研究所和麻省理工学院还有许多其他人愿意让我考验他们的耐心，并给了我不应得的时光，但过去二十多年里我与罗布的对话（现在仍然是）对我的智力发展产生了深远的影响。

当我写这本书时，我通常脾气暴躁，心不在焉，总的来说让人难以忍受。我的妻子宝菲和我的女儿阿尔文有时会忍受这种胡闹，但大多数时候会告诉我停下来。这正是我所需要的。

宝菲和阿尔文，我非常爱你们。

感谢每一位。

关于本书

这本书旨在提供一份逐步实施的指南，用于实施机器学习项目。它基于自 1990 年代以来出现的大量工作，这些工作针对的是机器学习开发者面临的各种挑战。

本书记录的方法并非原创，尽管其中一些尚未发表，因为我在尝试将最佳实践和学术出版物规范化。我已经尽力提供参考文献，但我确信我遗漏了一些。无论如何，请假设在没有参考文献的地方没有发明或新颖性的声明——只是我找不到归属，如果无意中冒犯了您，请原谅。

关于人工智能和机器学习的技术书籍有很多，所以这本书并不试图填补这个空白。如果您对这些主题没有很好的掌握，那么在尝试应用这种方法之前，以下列出的文本是很好的起点：

• *《人工智能：现代方法》，作者 Stuart Russell 和 Peter Norvig，Pearson 出版社，2016 年。这本教科书被用作大多数本科人工智能课程的骨干，并概述了人工智能作为主题的关键关注点。这是一个很好的起点。

• *《使用 Scikit-Learn、Keras 和 TensorFlow 进行机器学习实践》，作者 Aurelien Geron，O'Reilly 出版社，2019 年。本书侧重于一系列机器学习技术的实际应用，但涵盖了从业者对领域概述所需的大部分内容。对于来自软件背景且对机器学习的数学方面不太感兴趣的读者来说，这本书是个不错的选择。

• *《概率机器学习：导论》，作者 Kevin Patrick Murphy，麻省理工学院出版社，2021 年。本书对人工智能和机器学习的核心方面进行了全面的现代处理。它适合那些想了解技术的基础和机制，并且有数学倾向的读者。

列出的书籍提供了关于人工智能开发并试图解决的技术和问题的阐述。相比之下，本书汇集了交付人工智能项目所需的工具和方法，并提供了在商业环境中处理商业挑战和交付的视角。

本书组织结构：路线图

在每一章中（除了这一章），内容都以结构化的方式呈现，目的是实现准确性和简洁性。

• 第一章描述了我在撰写本书时心中所持有的核心概念和动机，并希望让读者对本书试图传达的内容以及它如何有所帮助有一个清晰的了解。

• 第二章概述了在客户、自己和组织之间建立项目共同理解的步骤，无论组织是否与客户分开，或者是否在不同部门。你将学习如何组织流程，与客户合作建立需求，深入了解客户数据，并确定必要的工具。

• 第三章涵盖了创建一个团队和利益相关者都能理解的项目假设的过程，这包括创建估算过程，以便项目能够得到适当的资金和资源，以及为了使项目正式同意并运行所需完成的工作。你将学习为了开始项目需要理解什么，谁需要理解它，以及谁需要同意。

• 第四章介绍了第 0 个冲刺所需的工作。这个冲刺包含启动项目工作的活动，并将团队纳入项目。在第四章中，你将了解使团队能够开始工作并在 ML 项目中变得高效所需的内容。

• 第五章涵盖了第 1 个冲刺的前半部分。这项工作要求有一个技术团队到位，并且能够访问所需进行进展的系统和信息。在这一章中，重点是获取团队创建机器学习模型所需的数据，并将其放入一个可以用于支持建模的环境。

• 第六章通过使用数据管道来理解客户数据并构建第一个原型模型，完成了第 1 个冲刺的工作。你将学习需要哪些类型的数据探索，以及需要采取哪些步骤来为团队成功开始构建模型奠定基础。

• 第七章开始第 2 个冲刺的工作，重点关注使用结构化和系统化的过程构建有用的模型，并确定将进行详细评估和选择的模型，以便集成到生产系统中。在第七章中，你将学习建模团队应该采用哪些结构和流程。

• 第八章通过在线和离线环境中的结构化测试和模型选择指南完成了第 2 个冲刺，并包括了对在评估模型时经常遇到的陷阱和问题的讨论。你将学习在评估和比较 ML 模型时需要注意什么，以及如何管理这些比较的过程。

• 第九章深入探讨了第 3 个冲刺的实施，详细说明了将选定的模型集成到生产系统并部署它们的过程。它还强调了在提供用户友好的界面时必须考虑的重要事项。在这里，你将学习将模型从有趣的实验转变为成为组织运行系统一部分所需的一切。

• 最后，在第十章中，描述了在生产中管理机器学习系统的含义和所需实践。第十章的目的是展示需要建立和运行哪些流程和结构，以便将 ML 项目作为一个价值引擎来维持。

LiveBook 讨论论坛

购买《管理机器学习项目》包括免费访问 liveBook，曼宁的在线阅读平台。使用 liveBook 的独特讨论功能，您可以在全球范围内或特定章节或段落中附加评论。为自己做笔记、提出和回答技术问题，以及从作者和其他用户那里获得帮助都非常简单。要访问论坛，请访问livebook.manning.com/book/managing-machine-learning-projects/discussion。您还可以在livebook.manning.com/discussion了解更多关于曼宁论坛和行为准则的信息。

曼宁对读者的承诺是提供一个平台，在这个平台上，读者之间以及读者与作者之间可以进行有意义的对话。这并不是对作者参与特定数量活动的承诺，作者对论坛的贡献仍然是自愿的（且未支付报酬）。我们建议您尝试向作者提出一些挑战性的问题，以免他的兴趣转移！只要书籍在印刷中，论坛和先前讨论的存档将可通过出版社的网站访问。

关于作者

西蒙·汤普森在开发 AI 系统方面投入了 25 年的时间，通常但并非总是使用机器学习。他在英国 BT 实验室领导 AI 研究项目，帮助公司在大数据技术方面进行创新，并管理了近十年的应用研究实践。他的团队交付的项目使用了贝叶斯机器学习、深度网络、以及传统的决策树和关联规则挖掘，为大型企业的电信网络、客户服务和业务流程提供了洞察。西蒙于 2019 年离开 BT，现在从事咨询工作。目前，他和他的团队正忙于作为顾问为银行、保险公司和制造业提供机器学习项目，使用云 AI 平台、大型语言模型和向量数据库。西蒙是一个家庭男人，热爱他的花园和狗。您可以在 Twitter 上关注他@AISimonThompson，或在 LinkedIn 上查找他。

关于封面插图

《管理机器学习项目》封面上的插图“Le Marchand De Coco”或“热巧克力摊贩”取自路易·库默尔于 1841 年出版的书籍。每一幅插图都是手工精心绘制和着色的。

在那些日子里，仅凭人们的服饰就能轻易识别他们居住的地方以及他们的职业或社会地位。曼宁通过基于几个世纪前丰富多样的地域文化的书封面，庆祝计算机行业的创新精神和主动性，这些文化通过如这一系列图片的收藏得以重现。

1 引言：交付机器学习项目是困难的；让我们做得更好

本章涵盖：

• 描述本书的结构和目标

• 定义什么是机器学习

• 解释为什么机器学习很重要

• 探讨为什么机器学习项目与众不同

• 列出其他机器学习开发方法

本书描述了一个端到端的过程，用于交付一个机器学习（ML）项目来解决一个足够大且足够困难的业务问题，以至于需要团队。随着 ML 兴趣的迅速增长以及 LeCun 等人[1]和其他高级方法（如 Carpenter 等人[2]讨论的 MCMC 算法）的发展，ML 项目的新机会层出不穷。因此，很多人将管理这些项目，这是一本为他们准备的指南。

为什么需要专门为机器学习项目编写指南？据 Gartner 称，85%的机器学习项目失败[3]，尽管追踪这一说法的确切起源和证据比作者愿意投入的工作要多！即便如此，从学术研究中可以看出，在机器学习开发工作流程的这些步骤中存在“挑战”，并且在开发过程的每个阶段，实践者都会面临问题。例如，参见 Paleyes 及其合作者的工作[4]。随着开发和部署 ML 系统困难性的日益明显，越来越多的人担心 ML 正在被不道德和有害地应用[5]。从根本上讲，ML 项目与普通软件项目相比，具有不同的开发过程（从数据构建模型），在组织和基础设施方面有不同的需求，并且提供的结果（ML 模型）需要以与普通程序不同的方式处理。

本书背后的一个主要思想是，进行 ML 项目有点像乘坐过山车。明亮的过山车是每个人关注的焦点，但乘坐它只需要三分钟。要乘坐它，你必须让所有人上车，开车一个小时，停车，走到售票处，购票，然后排队等候。重点是，为了好玩，你必须做好准备。过山车之后呢？好吧，然后你到达过山车的真正目的。你可以和你的孩子坐在一起吃冰淇淋，谈论它有多好，你接下来要做什么，以及为什么。如果这个过程的前后部分不好，那么有趣的部分（ML 项目中的 ML）就不会发生。

这本书主要关注使用机器学习（ML）所需的准备，使用结果所需的工作，以及防止 ML 误入歧途的安全措施。毕竟，如果你从过山车上掉下来，那么那天早上留在床上可能更好。

本书主要面向非技术读者；旨在帮助人们了解需要做什么以及存在的问题，但并不提供太多关于交付的细节。在本书的一些部分，会有技术示例和解释。这些内容是为了在无法避免变得稍微技术性的情况下提供指导。然而，非技术读者可以安全地跳过这些示例，而不会错过文本中的主要主题和概念。

了解 SQL 以及一些基本的数学技能会有所帮助，但即使你不知道或不关心这些事情，本书也应该对你大部分内容都是可访问的。另一方面，预计大多数读者将拥有深厚的机器学习和数据科学知识，他们阅读这本书是因为他们对软技能和项目实践感兴趣，这些技能和实践可以帮助他们应用他们的 AI 魔法。

在下一节中，我们将描述机器学习的基本概念以及它们如何应用于为新进入该领域的人设定场景。对于已经熟悉机器学习概念和技术的人来说，可以自由地跳到 1.4 节，在那里介绍本书的其余部分，或者更远的地方开始阅读本书的核心内容。对于其他读者，1.2 节介绍了一些基本术语，然后在那之后，在 1.3 节中描述了机器学习的重要性以及推动对机器学习项目采取特殊方法的问题和挑战。在 1.4 节中，我们将概述为开发软件和机器学习系统所尝试的其他方法。最后，本书的路线图以及说明如何使用所倡导的工具和方法的案例研究也将被展示。

因此，让我们继续学习机器学习以及针对机器学习项目需要采取的特殊方法，或者直接跳到第二章，开始项目！

1.1 什么是机器学习？

机器学习（ML）是一组算法，我们可以使用这些算法从数据中创建（学习）模型。模型可以用多种方式表达，例如，一组 if/then/else 语句、决策树或神经网络的一组参数或权重。机器学习算法从输入的数据中生成一个模型：

机器学习 + 数据 = 模型

模型是近似值。你可以想象一个将有四条腿和有毛发与狗联系起来的模型。当然，这个描述过于笼统，没有实际用途。要创建一个能够捕捉狗和猫之间的差异或大丹犬和吉娃娃之间的共同点的模型，需要更多的信息。在这种情况下，模型结合了关于实体的部分数据（例如，腿的数量、毛发、大小等）以及关于缺失数据（类型或实体）的推断，这些是机器学习算法可以提取的：

模型 + （部分）数据 = 推断

当人类手动构建模型时，他们会选择关联规则或网络参数，因此他们可以进行的实验数量是有限的。机器学习方法的优点是机器可以检查大量的参数或关联。机器可以快速且便宜地搜索数百万或数十亿种不同的设置和链接。人类的优点（例如，统计学家或流行病学家）是他们知道自己在做什么。通常，这种应用常识和更广泛世界知识的才能意味着人类选择和创建的模型优于机器学习的模型。这也意味着人类可以构建模型而无需访问大量数据。然而，最近，机器学习的重要性日益增加，因为使用现在可用的巨大计算能力来处理大量数据比手动设计模型要便宜得多，也容易得多。

图 1.1 展示了机器学习开发者正在构建的系统示意图。在图象的左侧，数据进入系统，经过处理和转换，然后提供给机器学习算法，这些算法创建模型。这些模型被集成到应用程序和人类驱动的流程中。在图象的右侧，从模型中创建的推理影响人类用户。

在数据被模型消耗之前，它需要被处理。这通常意味着它必须被清理并组装成可以传递给模型的示例。一旦完成，模型就可以消耗它。有时我们可以使用单个模型，但如图 1.1 所示，也常见的是生成一系列模型并将它们串联起来以创建我们所需的推理，这些模型需要由操作员的支持团队进行管理和治理。偶尔，模型的输出会由一个监督人类进行审查，并做出关于它们将如何影响最终消费者的决策。在其他情况下，模型的结果由另一个系统进行调解，然后更直接地被用户消费。

图 1.1 机器学习项目试图交付的系统类型

机器学习算法可以从人类难以处理的数据集中学习模型，并且可以集成到极其有用的系统中（例如，为互联网搜索、数据网络和电影推荐等现代生活的许多方面提供动力的系统）。似乎每个人都同意，机器学习可以是一项重要的技术，能够改变我们的经济和社会。然而，机器学习可能很难应用，并且存在许多可能给机器学习团队带来问题的难题。为了更详细地探讨可能导致机器学习团队遇到问题的具体问题，下一节将更深入地探讨机器学习的承诺和陷阱。

1.2 为什么机器学习很重要？

机器学习（ML）有什么令人兴奋和有前景的地方？在过去的几年里，机器学习研发领域取得了变革性的成果，这些成果导致了能够做到以下事情的机器的发展：

• 编写难以或无法与人类努力区分的文字，如大型语言模型 GPT-3 [6]的输出。

• 在推导蛋白质形状方面展现出革命性的性能，就像 Alphafold-2 [7]所做的那样。

• 根据 DeepMind 在 AlphaZero [8]上的工作，在所有棋类游戏中超越所有人类。

此外，机器学习还创建了可以基于文本提示创建新颖且相关图像的模型，就像 DALL-E 模型[9]所展示的那样。许多人将这些进步视为路标，表明机器学习技术的潜力，并且普遍预期更多地震级的创新即将到来。同时，许多评论员指出，机器学习的承诺和炒作与现实模型能够做到的事情之间仍然存在差距，Gary Marcus 是突出的例子[10]。重要的是，模型的工作方式和它们犯的错误可能会产生深刻的伦理问题[11][5]。

值得注意的是，机器学习（ML）不仅仅是硅谷的一些技术大师和世界上的顶尖大学的专属。你可以免费下载现成的模型和库，然后轻松使用它们。这使得程序员（越来越多的是非程序员）能够将机器学习组件集成到他们的项目中。现在有机器学习驱动的工具可以识别工厂中的安全风险，选择适合消费者口味的音乐，或检查电子邮件语法。这些都为许多人的生活和幸福做出了微小但实际且宝贵的贡献。每天，机器学习可能每隔几分钟就会以某种方式改变我们的生活。

技术人员发现这一切都令人惊叹，但不出所料，当这项技术应用于现实世界时，出现了一些问题。模型可能被用于做一些它们并不适合的事情，例如根据人们的外貌判断他们是否可能是罪犯，以及确定罪犯应该在监狱中服刑多久。这种应用如此有问题，以至于有整本书专门用来详细解释其所有方面[11]。可以说，使用算法来决定一个人的生活道路不是一个好主意。

当实际应用尝试时，很容易找到机器学习产生令人失望结果的故事。一个很好的例子是看看机器学习社区为治疗 COVID-19 所投入的巨大努力。一项研究[12]调查了 232 个开发出来的模型，但发现只有两个模型的质量足够高，值得进一步测试。关于旨在解释医学图像或诊断癌症的系统，也有类似的故事。据报道，甚至埃隆·马斯克也说过，制造自动驾驶汽车比他想象的要困难得多[13]。

那么，机器学习项目的复杂性和挑战的驱动因素是什么？对于软件项目来说，机器学习项目必须理解和适应在特定领域工作的挑战，无论是销售自行车的企业、肿瘤学还是流行病学。除了这些问题之外，一个应用领域的机器学习项目之所以复杂，是因为它处理和操作复杂的数据资源、复杂的模型以及编排它们的代码。在复杂性和挑战方面，以下这些观点是值得记住的：

• 机器学习系统依赖于数据，特别是它们用于创建最终系统中使用的模型的那些数据资产的结构和质量。现代数据资产庞大且极其复杂。对于即将交付的团队来说，需要理解和处理复杂、嘈杂、大规模且充满个人和敏感数据的数据资产的做法和流程。数据需要在系统层面和统计或价值层面进行理解和处理。我们需要对其进行工程化并理解其含义。

• 机器学习项目创建和使用模型。创建的模型特性需要被团队测量和理解，这种理解必须指导模型嵌入的系统设计过程。我们需要构建模型，同时，我们还需要评估它们（在技术层面和商业环境中），并且需要管理它们的生命周期。

• 机器学习系统应根据 Wixom 及其合著者[14]的建议与科学、利益相关者和社会要求保持一致。在开发机器学习系统的过程中，必须将商业和广泛的伦理考虑因素融入其中。

图 1.2 展示了如何将这些三个关注点表示为维恩图。这个图很有帮助，因为我们可以用它来规划机器学习项目中的工作和责任。

图 1.2 机器学习项目复杂性的驱动因素：领域、数据和模型

机器学习项目带来的挑战是一回事，但除了解决这些问题之外，还有一些任务需要完成，以确保我们能够及时、高效、高质量地交付成果。在这本书中，确定了四个需求：

• 尽快识别项目中的风险和机遇。 在机器学习交付中理解项目风险需要工作和时间。

• 使团队能够快速反应和适应问题。 团队需要应对意外问题，并且能够在项目进行中随着用户需求的明确而改变方向。能够转向处理意外的模型性能问题是至关重要的。

• 将客户纳入流程中。 建立参与和赞助，以及获取反馈和信息，使项目对任何企业都变得有用和有效。

• 提供运行和维护系统所需的一切。 构建机器学习系统的团队认为他们是在交付一个系统，但他们还必须提供理解、使用、运行和维护系统所需的一切。特别是，如果系统将影响人类的生活和幸福，那么适当的文档和记录保存是必需的，当然，当你的团队继续前进时，还需要适当的文档来指导将来的团队运行和维护代码和模型。

总结来说，机器学习项目处理起来很困难，机器学习模型是近似的、难以解释的，并且难以开发。它们大多数时候不能给出正确答案，对于某些应用来说是稳健和合适的，但对于其他应用则不是。机器学习项目中的不确定性和风险比正常软件开发要多。此外，机器学习系统高度依赖于大规模数据资源。数据是由有议程的人收集的，无论他们是否意识到这一点，因此它充满了偏见。人类与机器学习系统互动的方式可能会产生原始设计师感到惊讶的行为循环和螺旋。可靠和高效地处理大量数据资源是有问题的，对于习惯于运行软件项目的团队来说可能具有挑战性。

为了解决这些问题，我们需要一种不同且定制的机器学习方法。未能以正确的方式处理机器学习项目可能会失败，甚至更糟，并造成对他人有害的结果。这不仅是一个专业人士难以陷入的境地，而且对于这样做的人，中国[15]和欧盟（EU）[16]有严厉的新法律和处罚。

跟随本书中描述的过程并不能保证你的项目会成功（它也不会阻止你构建一个有害的系统）。希望书中阐述的步骤将有所帮助，以及对如何将这些步骤与其他步骤串联起来并用于交付最终产品的理解。在接下来的两个部分中，将解释我们如何得出书中概述的工作结构，包括对其他人如何构建类似项目的参考。

1.3 其他机器学习方法

人们已经创建了超过 50 年的软件系统，其中很大一部分时间他们也在构建机器学习系统。因此，检查其他人做了什么是有价值的。多年来，软件开发是围绕预测交付项目所需的复杂性和工作量来计划和组织的。我们称这种方法为“瀑布”。本质上，这个想法是收集所需的信息，并将其转化为设计。然后，将设计转化为程序员的作业计划，接下来，程序员编写代码并将其提交给测试。最后，系统被用户接受——这就是瀑布。

随着软件系统变得更加复杂，并且不再受其运行硬件基础（因为硬件变得更快）的限制，瀑布方法的价值逐渐枯竭。瀑布开发系统的最终用户发现，软件与其真实需求无关，因为他们与产生该软件的过程脱节。还存在其他问题，包括项目经理由于与实施活动本身距离太远，无法正确估计复杂性和成本。

遵循结构化瀑布方法规定的显著成本，加上缺乏这些实践带来明确价值的证据，导致了人们对“一开始就提出大量需求”方法的广泛幻灭。反过来，这导致了瀑布方法作为更迭式方法的重估，在每个阶段都有“向上反馈”（Royce 1970），以及新方法的发展和探索：螺旋模型（Boehm 1986），它基于计划-执行-研究-行动周期，旨在支持压力下的决策，以及 V 模型。这些方法中最广泛采用和最受欢迎的是敏捷开发（Beck et al 2001）。

敏捷强调早期交付可工作的软件，与客户合作（“个人和互动”而不是“流程”），以及接受变化。项目中的变化和发现被认为可以通过这种方法更好地管理，因为客户迅速获得有用的东西，而不是一长串无法使用的特性和组件。

敏捷思维的进一步发展是 DevOps（Ebert 2016）的概念，它试图在开发者（dev）和运营软件的支持团队（ops）之间架起一座桥梁。驱动 DevOps 的洞察是，运维团队是一群专家，比组织中的任何其他部分都更了解软件。使用这种软件的主要障碍是开发团队对生产环境理解和现实之间的不匹配成本。这种成本由开发团队（试图实现其交付软件的目标）和运维团队（试图实现其无故障业务连续性的目标）共同承担。

图 1.3 说明了 DevOps 项目中的关键活动，它支持快速和适应性强的软件开发。DevOps 团队围绕开发和交付软件的过程开发自动化。这使得他们能够在项目成熟时专注于开发本身。通过降低在开发周期后期更改软件的成本和风险，促进了项目活动中的信息流。通常，这是在项目后期（用户和利益相关者意识到它实际上将要做什么以及它将如何创造价值）时。在这个阶段具有灵活性对交付软件的质量有不成比例的影响。

图 1.3 一个通用的 DevOps 生产和交付流程（基于 Ebert，2016；由作者重新绘制和修改）

过去曾尝试为机器学习和人工智能系统开发提供具体的指导。例如，KADS（诞生于 1990 年）是 20 世纪 80 年代末和 90 年代初在欧洲开展的一项旨在开发共同工程方法的大规模努力。当时我们使用知识工程来创建基于规则的推理系统，以在复杂领域做出决策。这种系统最终证明不如预期实用，而且由于机器学习系统不同，这使得 KADS 变得或多或少过时。

一个更相关的努力是 CRISP-DM，这是一种从 1997 年到大约 2007 年开发的数据挖掘方法论。数据挖掘使用了早期的机器学习技术，从数据中提取模式以获得关于正在发生的事情的见解。在 2007 年的一项调查中，CRISP-DM 被引用为数据挖掘从业者使用最多的方法论（Piatentsk-Shapiro 2007）。

近年来，许多机器学习社区成员在 MLOps 的旗帜下采用了受敏捷和 DevOps 启发的做法。此外，如Machine Learning as the High Interest Credit Card of Technical Debt（Sculley 等人，2014）中描述的工作，阐述了一些机器学习系统开发的问题。机器学习社区通过开发借鉴 DevOps 系统开发风格但专门针对机器学习项目的方法来回应。一个例子在在线手册Machine Learning System Design（MLSD）（Huyen 2020）中概述，为希望成为机器学习工程师的人提供信息。MLSD 提供了一个结构和创建生产级机器学习系统所需任务的信息。手册通过对比研究实施的需求，解释了我们在开发生产系统时应应用的不同视角和考虑因素。还包括设计考虑因素（性能要求和计算要求）的概述。手册的主体部分描述了四个阶段（图 1.4）：

• 项目设置是确定手头问题尽可能多的细节的过程。完成这一过程的方法被表述为技术面试中的讨论，信息来源被视为面试官。目标、用户体验、性能约束、评估、个性化以及项目约束（人员、计算能力和基础设施）被确定为需要考虑的重要元素。

• 数据管道元素考虑了隐私和偏差、存储、预处理和可用性。

• 模型化考虑了模型选择、训练、调试、超参数调整和扩展（在覆盖大量训练数据的意义上）。

• 服务被界定为对模型的评估以及在我们将模型应用于实际场景时需要理解的一些假设。

图 1.4 如 Huyen 和 Hopper（2020）所述的机器学习项目流程。图由作者重新绘制和改编。箭头表示依赖关系，而不是工作流程。

在书中，还给出了描述这种方法的另一种尝试，即机器学习工程（MLE）(Burkov 2020)，它对机器学习工程的最佳实践和设计模式进行了全面回顾。

MLSD 和 MLE 有显著的共同点，两者都将建模过程描述为迭代的，并需要重新进入开发生命周期的其他部分。这两本书[18, 19]都可以被视为 MLOps；它们是敏捷和适应性强的，强调以管道开发的形式进行自动化。此外，这些方法利用了一系列支持自动化目标的各种工具。版本控制用于代码、模型和特征；自动化的管道用于移动和转换数据以及测试和部署模型。

最近，一些研究工作强调了文档的作用，特别是在数据及其模型的来源方面。一个例子是 Google 和 Hugging Face 发布的一些模型的 Model Cards/Model Reports 的发布。这一过程的演变是 TeleManagement Forum (TM Forum)倡导的开发过程，它提供了维护一个保管链以确保模型被理解和控制[20]。这些实践强调了记录生成的模型的需求，使它们能够在未来被适当且容易地选择和使用。

1.4 理解本书

如 1.3 节所述，DevOps（由自动化支持的迭代开发）、强大的文档、以及仔细的伦理评估和流程控制对于机器学习开发来说非常重要，并且被广泛采用。因此，它们在这本书中占据了重要地位。除了展示我们如何使用这些工具创建机器学习模型外，本书还涉及：

• 项目启动和运行，包括估算项目成本和持续时间。

• 与团队协作和组织以交付项目。

• 处理支撑项目的数据资产，构建数据管道，处理为不同目的收集的多样化数据，以及设置和运行探索性数据分析。

• 评估机器学习模型并决定使用哪些模型（如果你在考虑“最好的那些”，那么请做好惊喜的准备）。

• 将机器学习模型从开发和测试转移到生产环境。

• 在应用中使用机器学习模型。

本书使用敏捷开发项目的约定[17]来解释工作的结构。每一块工作（图 1.5）被描述为sprint，而每章的任务列表被称为backlog。backlog 列表之后是详细说明每个子任务的结构和方法的详细信息，以及帮助工程师进行工作的额外解释。

图 1.5 本书中描述的项目结构；从创建和开发项目到管理生产中的最终模型。

在每个冲刺的结束时，提供一份清单，以便团队一起工作，确保所有任务都已完成。清单标记了特定项目阶段中任务的文档要求，确保汇编了一个不断增长的文档集合，详细记录了团队取得的进展。这些文档是宝贵的资产，提供了一种信息共享和再利用的方式。此外，这些文档还支持生产系统中系统的维护和管理。

在本书中穿插着一个案例研究（自行车店），其叙述旨在说明所描述的技术和任务的过程和应用。有些章节（第二章、第五章和第七章）没有提到案例研究，因为它们是冲刺的开始，相关的叙述将在下一章出现。

大多数项目步骤都是旨在被视为迭代和自适应的，如图 1.5 所示，预期项目中的某些步骤可能会产生需要重新工作的发现。特别是，第 5-8 章中描述的 EDA、建模、评估和集成过程在实践中是迭代的。假设由于发现和适应，可能会出现错误的开始和重复。例如，建模过程可能会导致发现数据特征，这些特征在 EDA 过程中没有被暴露出来。这意味着需要更多或不同的数据。

集成可能会暴露出意外的模型属性，这需要重新启动和重复建模。EDA 阶段以及建模和评估阶段中任务的顺序和细节被设计成最小化这种情况，并尽早暴露问题。它还旨在使项目领导者（你）和你的团队能够向利益相关者传达正在发生的情况，让他们放心，你已经尽最大努力避免意外的死胡同和项目重置。

使用这本书的目标是帮助你确定在重要的机器学习项目每个步骤中需要做什么，并在执行过程中提供一些支持。希望它还能为你提供指导，告诉你需要多少时间，如何向项目赞助商证明活动和费用的合理性，以及如何适应必要的调整和迭代的方法。

1.5 案例研究：自行车店

为了使这本书生动起来，我们包括了一些基于现实世界数据和项目经验的讨论。匿名化和重新构想，它将在下面描述。

一家自行车连锁店（The Bike Shop）使用不同的系统来管理其销售和库存数据。销售由一个软件即服务（SaaS）系统管理，而库存则由一个现成的库存系统管理，该系统由 The Bike Shop 的 IT 团队管理的服务器集群运行。通过将这两个系统中的数据迁移到单个云数据库中，The Bike Shop 的管理团队希望产生洞察力，并创建一个业务案例来证明这一点，仅仅基于共同托管数据并提供一个仪表板界面，允许业务用户消费它。然而，他们有一个想法，即应用机器学习（ML）到他们的业务将带来巨大的好处，但他们几乎没有确切知道如何实现这一点。

在每一章的结尾，从你的视角讲述了你作为 The Bike Shop 机器学习项目的项目经理，如何管理机器学习系统。这包括：

• 制定提案并估算成本。

• 构建和组建团队。

• 访问系统和数据以了解数据中有什么。

• 确定机器学习（ML）可以利用数据做什么。

• 理解用户将如何使用结果。

• 选择要使用的模型并设置构建模型。

• 构建模型并将它们集成到生产系统中。

在下一章中，这段旅程开始了。

摘要

• 过去 10 年中数据和计算爆炸式增长证明机器学习（ML）已成为一项重要技术。

• 在成功交付机器学习项目以及它们交付时可能产生的负面影响方面都存在问题。

• 机器学习项目与其他项目不同，因为它们依赖于复杂的数据，需要团队产生和管理从数据中创建的模型，并且需要仔细与用户和利益相关者的需求保持一致。

• 一个成功的机器学习项目消除了需求和数据的风险，捕捉了非功能性需求和功能性需求，并开发了处理和评估模型的能力。

• 机器学习项目需要在整个生命周期中与社会和利益相关者的需求保持一致，以避免不理想的结果。

• 我们可以借鉴敏捷软件开发和 DevOps 社区的理念来帮助我们开发项目。

2 项目前阶段：从机会到需求

本章涵盖：

• 理解项目类型和利益相关者对规模和结构的期望

• 建立预销售/项目流程

• 理解模型性能需求

• 理解数据资产

• 理解项目的一般需求

• 掌握工具和基础设施以成功交付

项目成功与失败由围绕其的项目前/预销售活动定义。挑战是从知道有一个可以赚取机器学习项目报酬的机会转变为一个可以用来支付按揭的工作。本章的目的是概述需要发生哪些活动和行动，以了解机器学习项目是否可行以及是否有用。然后，我们需要确定完成项目所需的努力以及由谁来完成。

很容易陷入过度精细化的陷阱，因为我们可以在深度细节中完成所有这些活动。不幸的是，我们生活在一个竞争激烈的世界，有时组织在达成一致之前很难在项目上投入时间和金钱。从现实的角度来看，我们需要理解，在合同签署之前，组织对深入分析客户数据或访问高性能服务器的承诺是不存在的。到那时，每个人的职责就是让项目发生。在此之前，一切都只是理论。因此，在资金到位和时间可以分配之前我们所做的工作只是后来发生事情的一小部分。

对此过程给予强烈关注可以降低你和团队承担的风险。未能理解项目的业务需求会使你的团队处于风险之中，误导他们的努力，并且很可能会低估提供交付所需资源的报价。未能理解可用的数据资源意味着无法确定如何使用机器学习来处理项目或判断成功的可能性。此外，未能理解安全、隐私或伦理方面的考虑意味着让你、你的团队和你的组织面临尴尬和责任风险。现在审视项目的所有这些方面，可以让你做出一些及时有效的决策，这可能会使未来的生活变得更好。

在某些方面，这些问题适用于任何项目。然而，机器学习项目的一些特定风险必须得到解决：

• 开发机器学习模型通常很容易，但开发具有解决特定业务问题所需特性的模型则要困难得多。

• 数据质量差或不可访问会引入相当大的摩擦，并且直到获得数据，项目进度通常都会停滞。

• 数据来源和使用限制可能意味着使用项目结果是不道德的或非法的。例如，如果个人数据的来源未知，使用它可能侵犯消费者隐私，数据所有者可能不会同意其使用。

• 在事前预测学习模型中机器学习算法的性能是困难的。尽管团队付出了最大努力，结果可能令人失望。

• 对 IT 架构的误解或未预见，该架构在生产中部署机器学习系统，可能导致项目结果无法使用。

在本章和第三章中描述了缓解这些问题的努力。正如第一章所承诺的，以下项目前期待办事项列表提供了为交付项目前期活动所需的任务清单。之后，我们描述了设置此活动所需的工作，然后讨论理解客户概述的需求所需的内容。随后的章节将处理理解数据资源、安全和隐私、伦理以及 IT 架构。

2.1 项目前期待办事项

表 2.1 提供了创建成功项目前期结果所需活动的摘要。我们可以使用此列表作为预销售（PS）待办事项。每个条目都可以是一个系统（如 Jira 或 GitLab）中的票据，这使我们能够跟踪进度，从而防止遗忘任务。使用票据系统跟踪进度很方便，因为它将很容易确定何时应该召开会议，并看到谁负责每个任务以及他们做了什么。

表 2.1 项目前期预销售待办事项

票号	项目项
PS1	设置项目待办事项/任务板并使用它。
PS2	创建一个文档存储库，并将其提供给项目团队。
PS3	建立一个风险登记册，以确定未知勤勉的程度，并估算缓解所需的内容。
PS4	创建一个组织模型来支持你对客户及其挑战的了解。通过将项目利益相关者映射到组织结构图，并分析对特定业务单元（如果受影响）和业务优先级（增加收入、降低成本、市场增长等）的影响，进行组织分析。
PS5	理解系统架构和非功能性约束。
PS6	获取数据样本，并记录关于数据资源的已知信息：统计信息、非功能性（规模、速度、历史等）和系统属性（它在哪，它依赖于什么基础设施，它做什么）。
PS7	检查并记录安全和隐私要求，并将其作为项目假设包括在内。
PS8	检查并记录企业社会责任和伦理要求，然后挑战、提供反馈，并将其作为项目假设包括在内。创建 PDIA 和 AIA 文档。
PS9	制定一个高级交付架构。该架构应涵盖开发、测试和生产组件（有时也包括预生产和预部署），并且能够支持客户的不功能性需求，例如可用性、弹性、安全性和吞吐量。如果可能的话，与适当的利益相关者进行反馈，以对该架构进行资格认证。将其作为项目的假设记录下关键架构方面。
PS10	理解业务问题：使用共识来构建项目假设，并由客户和交付团队验证。确保在任何合同协议中明确沟通和记录。
PS11	承担项目尽职调查。利益相关者是否可用？数据是否可用且可管理？哪些团队成员可用以及他们有什么技能？
PS12	为一个模型项目估算工作，交付所需的项目假设，考虑到可用的团队和工作所需的规模。确保你的估算中考虑了所有项目风险。
PS13	制定团队设计和资源配置计划，并与客户分享。
PS14	举行审查会议并检查清单以确保预销售流程得到适当完成。

在本章中，我们涵盖了 PS1 至 PS9 的票据，该章节涉及识别和记录项目的需求。在第三章中，我们涵盖了 PS10 至 PS14 的票据，这些票据使用那些需求来创建估算和提案。这确保了资金到位，并使项目准备就绪。首先要进行的是 PS1。

项目管理基础设施票据：PS1

• 设置项目待办事项/任务板并使用它。

我们可以使用 Jira、GitLab、GitHub、Microsoft ADO 或许多其他选项来实现此票据。一旦完成，你就可以签署 PS1！恭喜你，你已经开始了预项目工作。PS2 和 PS3 接下来。通过建立项目管理基础设施（基于票据系统），你可以更容易地推进其他所有工作。

2.2 项目管理基础设施

PS2 和 PS3 是设置项目管理基础设施的票据，使其投入使用。因此，它们是一个很好的起点。作为提醒，它们在此列出。

项目管理基础设施票据：PS2

• 创建一个项目文档存储库，并将其提供给项目团队。

项目管理基础设施票据：PS3

• 建立一个风险登记册，以确定未知勤勉的情况，并估算缓解这些情况所需的内容。

根据 PS2，完成预销售流程的第一步是创建一个共享的项目文档存储库，我们可以在这里保存涵盖预销售活动的文档。我们可能会使用整个项目的存储库，尽管客户数据保留和管理要求可能意味着我们将它迁移到另一个客户拥有的、标准化的存储库。即便如此，在这一步收集到的信息将一直有用到交付结束，甚至可能更久，从现在开始对文档进行组织是至关重要的。

需要记住的一件事是，您的组织可能有一个文档保留政策；这可能需要在特定时期或项目结束时删除文档。或者，它可能意味着文档被存档，以便以后可以找到。尽管检查保留政策很重要，但收集到的信息很可能是您组织的财产。如果预销售失败，且没有适当的项目，那么如果客户将来带着另一个项目回来，这些文档仍然是有用的。

重要的是，在所有情况下，您现在开发和捕获的文档都支持您团队和您的工作实践的发展。通过这样做，您从第一天开始就捕捉到了价值，并且也在帮助自己。人们常常会想，“哦，我以前遇到过那样的问题，然后我们决定……”如果将来你能记住这一点并取出文档，你会发现你真的有优势。

在第一天要做的另一件事是建立一个风险登记册。确定可能出错的事情和未知的事情是创建可管理项目的一个关键步骤。这是一种防止重要问题被遗忘的方法，也是确定项目工作所产生差异的方法。当你将已识别的风险从活跃状态转移到退休状态时，问题得到了解决，这些问题是由你和团队解决的。

我们可以通过将风险项转化为需要探索的问题来处理它们。如果项目的目标在需要回答的问题的术语中得到了充分定义，那么风险就会大大降低。这种方法揭示了在建立业务价值之前我们需要处理的不确定性。以这种方式揭示问题也使客户了解到需要进行探索的价值。

建立项目风险登记册听起来像是一个复杂而花哨的事情，但实际上很简单。风险登记册是在您的存储库中标识和版本化的文档（当然！）。它记录了所有项目的风险和行动。如果行动成功，风险登记册也会记录我们已经缓解了风险并将它们从登记册中移除。

在实际项目中，风险的识别和管理是项目的心跳（很快就会详细介绍）的一部分，并在每周与关键项目利益相关者的会议上进行管理。所有各方都接受新风险进入登记册，并同意它们是否得到处理。

在销售前过程中，风险由销售前团队紧密管理。在这个阶段，风险也是项目团队的关注点，因为评估和控制项目风险定义了团队提供的估计。这也支持了客户是否采用团队提案的决定。

2.3 项目需求

在建立带有票据系统、文档存储库和风险登记册的工作项目基础设施后，真正的工作开始了。PS4 和 PS5 要求制定项目需求。

需求票据：PS4

• 创建一个组织模型来支持你对客户及其挑战的了解。

• 通过以下方式进行组织分析：

  • 将项目利益相关者纳入组织结构图。

  • 对特定业务单元（如果受影响）和业务优先级（增加收入、降低成本、市场增长等）的影响。

需求票据：PS5

• 理解系统架构和非功能性约束。

了解你的客户。弄清楚他们需要什么才能在预算用完时使这个项目成功。这种知识使你能够批准项目的精神以及合同的文字，并使谈判和管理变更变得更加容易和轻松。

2.3.1 资金模式

第一个挑战是理解项目的资金模式。有三种类型的项目：固定价格、时间和材料、以及任务驱动。固定价格和时间和材料项目交付特定的成果，这通常是在一开始就定义的。任务驱动项目更具探索性，旨在提高业务某个领域的性能或为较小的业务（或较大的项目）转型。我们交付的项目类型影响我们管理它的方式以及我们应采取的方法。

在固定价格、固定时间的项目中，我们应该在特定时间交付定义的结果，因此交付组织承担交付风险。重要的是要注意，当项目出错时，风险以两种方式显现：

• 团队经历“冲刺”并过度工作以交付成果。

• 项目的成本上升，对交付该项目的商业造成损害

通常，这两件事都会发生。Verheyen [12] 讨论了使用敏捷方法处理固定价格合同的挑战。他得出结论，固定价格合同的问题如此严重，以至于简直是道德败坏！

尽管存在缺陷，但固定价格、以结果为导向的合同仍然是许多团队每天都要应对的商业现实。这是因为这些合同为顾客授权支付服务提供了一个被充分理解的机制。事实上，这种安排如此简单，即使在正式合同不存在的情况下，与固定资源、固定时间结构合作也可以提供清晰度和利益相关者的承诺。

与固定价格、固定时间（以及大约固定结果）的结构相比，最大的优点是透明度。团队知道他们将要承担什么，客户也知道（客户能知道多少）他们将得到什么。权衡的是，固定价格项目的风险主要转移到交付团队。团队可能最终会被迫通过加班来弥补估计错误或定价错误的项目。作为团队领导，你需要在项目开始前通过调查和准备来防范这种情况。

基于时间和材料的项目在团队完成项目或客户用完资金时收费。时间和材料项目有其自身的缺陷。例如，很容易设定不切实际的目标，项目团队和其他技术利益相关者可能直到项目后期才意识到项目的真实期望和目标。这反过来又导致了一种情况，即预算持有者的压力转移到团队，团队面临不可能的目标和需求，或者项目失败。然而，普遍认为，时间和材料项目风险更多地转移到客户利益相关者。

与固定价格或时间和材料相比，以使命为导向的项目有时可能像一场梦。团队有一个高级别的使命，以及由他们的利益相关者支持的想法和直觉议程。这些都是团队追求以获得结果的事情。

在最佳情况下，随着团队对项目的深入了解，他们会看到越来越多的机会；在最坏的情况下，他们会看到越来越多的问题。团队成员可能会因为工作的重要性和价值而变得充满活力和参与感。他们可能会开始认为自己通过拯救业务等方式拥有能动性和重要性。另一方面，人们可能会因为不断出现的新尝试和令人失望的结果而感到沮丧。有时团队的成绩会被理解和认可，但有时这些成绩会被纳入其他商业倡议中。

如果你正在调查的项目看起来可能基于时间和材料的基础来资助，或者它是一个更开放和以使命为导向的项目，那么这一章和下一章可能对你和你的团队不太相关。然而，使用结构化的项目前流程对三种类型的项目都有帮助：

• 对于固定价格，它为你组织提供了在特定水平上投标（或不投标）的证据。

• 对于时间和材料，它限制了加班和利益相关者挫败感的危险。

• 对于以使命为导向的，它聚焦团队，帮助团队和组织管理和结构化他们打算如何追求他们想要抓住的战略机会。

2.3.2 业务需求

在确定了项目的资金模式并做出进行结构化预项目调查的决定后，下一步是查看客户的企业目标。我们通常将需求分析视为软件开发“前期大设计”方法的一部分。但对于机器学习项目来说，有一些问题必须理解，以确定项目是否可行。例如，无论团队多么敏捷，他们都无法让一个大型的通用模型在旧慢处理器上运行得像许多用户所期望的那样快，优化它的努力也不会便宜。我们需要了解分析中三种一般类型的需求：

• 功能需求: 系统将为谁做什么？模型的职能是什么，它将驱动交付的系统？从客户数据构建的模型预期执行哪些分类、推荐或标记任务？模型在准确性、对异常事件和数据的鲁棒性以及面对变化时的可靠性方面必须表现得多好？

• 非功能需求: 模型必须多快执行或运行？需要多少吞吐量？模型必须在多长时间内对反应？以金钱和碳足迹来衡量，执行模型将花费多少？

• 系统需求: 模型将驻留在何处？它将如何维护？它必须与哪些系统集成？模型的结果将如何被消费？需要哪些工作才能使其可消费？需要哪些弹性和业务连续性措施？

按顺序解决这些需求并不现实。相反，我们需要一个澄清和反思的过程，深化对理解。接下来，我们可以具体确定需求和以特定方式提供它的含义。然后，我们如何开始呢？

显而易见的第一步是倾听客户或赞助者关于他们想要什么的说法。这可能是高层次的表达，或者可能是客户缺乏技术背景来以技术可实现的方式描述他们的需求。或者，你可能会立即得到详细且连贯的规范。在仔细倾听客户的理解后，我们需要进一步深入，询问为什么、谁和什么。

业务需求：为什么？

重要的是要了解客户为什么有这些需求和目标。如果你能理解这一点，那么你就可以做几件事情：

• 将客户需求与技术可实现解决方案相匹配。

• 精炼客户需求，以提供更多价值。

• 开发几条替代的价值实现路径，您可以在项目中进行探索。

想象一个想要创建智能建筑的客户：明确的目标是开发使用在整个建筑中收集的传感器数据来更有效地控制供暖和空调的模型。为什么？可能的答案包括：

• 为了降低成本。

• 为了改善建筑内部用户的环境。

• 为了减少碳消耗。

• 为了减少空调中特定化学物质的使用。

• 为了提升公司的形象。

• 因为有人告诉我们这样做。

所有这些都是实现目标的有效理由；所有都暗示了潜在的替代解决方案。接下来要问的问题是：谁？

业务需求：谁？

做一件简单的事情就是从客户那里获取组织结构图：你交付的是哪个组织，客户在哪里？图 2.1 显示了识别对自行车店客户重要的部门和职责的示例。启动项目的人位于 IT 部门，但最终用户位于零售部门的制造、营销和运营部分。图中的点表示项目的接触点。有趣的是看到项目将如何与客户的组织摩擦，以及它不会在哪里摩擦。

图 2.1 自行车店组织结构图。点代表利益相关者和用户，项目的接触点。

定位并装饰带有联系人用户名称和角色的组织结构图是一个良好的开端，但我们可以使用更正式的策略来建立更深入的理解。建立组织模型的概念来自 CommonKADS 知识方法论[6]。作者建议迭代地开发客户的模型，关注导致您参与合作的问题：

• 问题和机会: 客户用来证明与您合作合理性的感知问题和机会的简短列表。

• 组织背景: 将问题置于特定视角的组织属性，包括组织的使命或愿景，影响组织的外部因素（竞争、监管、经济），组织的战略，它所处的价值链（它从哪里购买，它向谁销售，组织的商品和服务最终客户和生产者是谁）。

• 解决方案: 关于您可能提供的解决方案的想法。

在 KADS 世界中，建议我们可以从组织的利益相关者那里获得这种知识。需要注意的是，KADS 在其利益相关者图中使用了一个过时的层次结构。在现代组织中，利益相关者可能包括：

• 预算负责人: 你将为他们带来价值的人。他们可能是你的客户，也可能是来自财务或采购部门的人，他们必须同意分配给客户的资金被合理使用，或者组织采购政策和标准得到遵守。

• 业务专家: —那些理解领域以及你的系统如何与他们的业务连接的人。

• 最终用户: 将使用你的系统并会受到其影响的人员。

• 安全确认人: 评估你的系统以确保其符合组织的安全标准的人员。

• 系统确认人: 同意你已经合规地设计和实施了系统的人员。

• 数据管理员: 给你提供所需数据资源访问权限的人员。

• 数据保护确认人: 确认你已合规处理数据的人员。

• 质量保证确认人: 核实你已经实现了一个工作质量系统的人员。

许多这些人可以否决结果：这个项目是会成功还是失败。挑战在于识别他们，并弄清楚他们将从你和你团队那里提出什么要求。确定他们是谁，他们想要什么，以及如何与他们沟通。

这是一个令人畏惧的名单。现实情况下，你必须优先考虑你将接触的人。与组织内的利益相关者（而不是客户）合作，确保你有权与已识别的人进行接触。在咨询公司中负责机会的参与经理和账户发展执行人员不会因为让你接触不允许商业原因交谈的人而感谢你，这可能会破坏投标。

如果这是一个内部项目，在资金竞争的情况下，必须考虑政治因素，因此在这个阶段接触错误的相关方可能会导致项目在开始之前就被否决。一旦你有了合格的联系人名单，你还需要回答以下额外的问题：

• 组织环境: 该单位的使命是什么？商业压力的来源（法规、竞争、供应、中断等）是什么？客户如何赚钱并证明他们在组织中的地位？

• 问题和机会: 你正在接触的人为什么需要一个解决方案？他们是否可以更有效率？他们是否在重复性任务上浪费时间？他们是否因为缺乏信息而无法做出良好决策？他们是否被选项压得喘不过气来？事情是否进展得太快？

这些问题的答案定义了项目功能部分的需求和机会。当然，如果有一个明显且明确的功能需求（例如，一个执行x的系统），那么一切都很顺利，因为那就是功能需求。然而，事情可能更加模糊，你可能会得到一系列需求和想法。这是可以的。通过理解可以做什么的限制，你将能够从你为此任务创建的清单中综合、评估和选择。这引出了下一个澄清问题：什么？

业务需求：什么？

确定系统“是什么”的过程的第一步是掌握客户组织中的系统或 IT 架构。然后，开始了解关于规模和速度的非功能性需求。

不幸的是，不可能得到一张漂亮的图表来表示大型组织的 IT 设置或架构（第一步）。公司通常有成百上千个应用程序（在某些情况下甚至有数万个）。关键任务是理解组织目前实施的一般政策和设施，以及可能影响项目的遗留资产。关键问题是：

• 使用了哪些类型的数据系统：Hadoop？Presto？Oracle？SAP？是否存在单一供应商政策（“我们是微软店”）还是以用户/应用程序为第一的政策（“只要它能工作，任何数据库都行”）？

• 可用的处理系统有哪些：SPARK？Kubernetes？OpenShift？

• 有什么遗漏的吗？有没有你认为应该可用但实际不存在的关键基础设施？这会成为一个问题，对项目以及可行解决方案的可能性会有什么影响？

• 组织是否在云上？哪个云？关于在该云中使用相关组件的政策是什么？（通常，组织出于成本和安全考虑会选择不使用某些组件。）

• 有没有必须与之交互的遗留组件？例如，相关架构的一部分是在本地，而新潮的东西在云上？

然后，你需要了解业务挑战的规模。这样，你可以确定现有的基础设施是否能够完成手头的任务：

• 有多少客户？

• 他们花了多少钱？

• 组织每天运行多少笔交易？

• 一笔典型交易涉及多少方？

• 组织的关键交易时间是什么时候？

在调查过程中，肯定会聚焦更多的问题。为了获得答案，你需要创建一个运营环境和将要创建的系统将运行的景观图。

这种知识和对系统功能需求的了解是构建项目假设的基础。客户和团队希望项目达到的解决方案是什么？这还将极大地帮助在项目演变过程中构建用户故事和确定更具体的需求。但就目前而言，您正在构建的模型告诉您和您的组织这是否与机器学习相关，以及那件事是否可行。

因为您正在从事机器学习项目而不是应用开发，所以您需要更具体的问题。这些问题将在接下来的几节中探讨，从第 2.4 节中的主要问题开始：您正在处理哪种类型的数据？

2.4 数据

进行机器学习项目的人需要了解数据。通过尽早获取数据信息，您可以洞察团队将面临的挑战的规模和深度以及他们真正能做什么。这包括从统计角度理解数据的特征，以及为实现实施所需的数据工程，以及它的局限性或潜力。PS6 要求您深入了解本项目将使用的数据。

数据发现工单：PS6

• 获取数据样本并记录关于数据资源的已知信息：

  • 数据的统计属性

  • 非功能属性（规模、速度、历史等）

  • 系统属性（它的位置、它所依赖的基础设施、它的功能）

您的客户可能对可用于训练机器学习模型的数据有一个清晰的想法，但深入了解他们关于可用数据的了解是非常有价值的。这使您能够构思可能存在的机器学习解决方案。这样做有四个好处：

• 通过询问关于客户系统中可用数据的开放式问题，您可以揭示可能对客户来说并不相关的数据来源，并充分利用这些资源。

• 即使在这个阶段只是以狭窄和简单的方式，您也可以探索和验证客户已知并推荐的数据集。

• 您可以了解客户拥有的数据的不足之处，这会告知您需要从开源或商业来源寻找数据以补充所需。

• 您可以了解使用数据所需的工作，包括提高质量和清理数据，以及您是否需要采用从有限数据集中榨取更多价值的方法。

首先是要获取你将要处理的数据样本。获取完整的数据集可能是理想的，但在这个阶段，由于以下几个原因，这可能是不现实的：提取大量数据集的技术难度可能很大，可能需要在这个阶段无法获得的资金。此外，完整的数据集可能包含商业机密和其他知识产权，在建立合同关系之前不能发布。（通常，企业数据存储的访问安全要求在假设项目中是无法协商的。）最后，处理和管理数据所需的工作量可能很大，目前可能负担不起。然而，获取一个代表性的样本应该是可行的，并且极其重要。即使获取样本的过程本身也可能揭示客户对数据和数据基础设施理解的重要问题。

如果完整的数据集可用，并且项目规模和风险提供了商业理由来支付这笔费用（你仍然处于项目前期，所以这一点取决于你），那么你可能希望将本书后面部分的数据调查和 EDA（探索性数据分析）练习提前到项目前期。你现在能获得的深度越深，你以后面临的风险就越少。然而，从现实的角度来看，在这个阶段，可能只能获得样本。

关于统计特性和在数据样本中需要寻找的内容，包括以下问题：

• 它是否真的具有代表性？是否有在数据积累的时间段内跨越的数据点？是否有来自所有源系统的数据点？是否有来自数据范围极端的数据点？

• 样本中实体的值范围是多少？它是稀疏的，只有少量或不相似的项目吗？它是密集的，有很多重复的值吗？

• 数据是如何收集的？它是调查的一部分吗？它是来自实验的吗？它是业务流程的废气吗？是在常规间隔还是事件中收集的？

• 这些数据让你想起了你之前使用过的其他数据吗？这是否是适合由知名机器学习算法处理而无需大量转换的数据？例如，如果它是图像数据，那么它是 256 x 256 像素，8 种颜色，还是 2.4M 颜色的吉像素图像？它与哪个知名数据集相似？

一些需要询问的非功能性问题是：

• 可用数据的规模是多少？如果源数据很大，那么提供的样本可能无法代表大部分数据，即使它是从源中以合理的方式抽取的。（通常，样本数据不是系统性地抽取的。）

• 为了创建样本，汇集了多少不同的数据资产或表？这花了多长时间，查询的成本和时间是多少？这些数据是否可以轻易地从企业信息架构中获取，或者是否是通过英勇、耐心和巧妙的方式获得的？是否有任何来自第三方或异国来源的数据？

• 数据变化有多快？更新频率如何？有多少数据到达以及速度有多快？

• 用于创建样本集的数据资产的架构是什么？有时样本作为大型平坦表提供，这些表是从底层数据库中连接的。了解源架构可以显示存在问题的地方以及在哪里需要 ETL 过程中的努力来使用这个资产。

系统问题包括：

• 哪些平台托管数据？你们团队是否有访问和操作这些平台数据的技能？如果没有，如何预期数据会被提供给团队？

• 在其生命周期中，数据集是否发生了任何重大事件？例如，是否进行了数据迁移或数据质量改进活动？

• 哪个业务单元或利益相关者拥有源表和派生数据？哪个组织拥有实施和管理数据表的系统？这些知识将引导对团队将运营的 IT 系统环境以及所需的安全和隐私制度进行调查。这在项目道德方法的发展中将非常重要。

• 准备样本的过程是什么？虽然可以从对前一个问题的回答中猜测所使用的过程，但总是值得尝试获取有关此过程的文档，特别是为了了解是否存在任何手动步骤，例如“然后我们挑选项目，丢弃那些不合适的。”在项目的第一阶段，团队可能希望重现提供的样本以测试他们对资源的理解。是否有足够的信息来做这件事？

不幸的是，有时客户在项目前期过程中可能无法或不愿意披露真实数据。这可能是因为合同问题，或者仅仅是因为他们的基础设施需要工作才能提取数据。许多客户甚至不知道如何获取所需的数据。

你交谈的人可能不知道你所有问题的答案，而且没有时间让他们回答。解决方案：将这些事项列入风险登记册。如果你正在签订合同，确保它们被写入工作说明书中作为假设。这些都是重大风险事项；本质上，除非你对将使用的数据有很好的了解，否则你在项目的机器学习部分将是在盲飞。

如果是这样的话，那么一个替代的方法是推动一个短期项目来了解组织的机器学习准备情况。这应该提供合同保障来支持数据的提取和检查，包括隐私、数据保留、使用以及关于安全和数据处理的承诺。这项工作使团队能够对数据有深入的了解，从而对在项目建模阶段应得到的结果有一定的信心。

尽管获取数据资源的挑战很大，但努力理解和记录团队将要工作的数据模型，以及理解数据的真实特征是至关重要的。在没有充分了解数据的情况下尝试对机器学习项目进行维度和结构化是危险的。如果这些任务没有打好基础，那么在项目估算中引入重要的应急项目是很重要的，无论是从时间还是资金的角度来看。这确保了你的团队不会在深夜连续几周拼命地围绕巨大的数据问题编码。记住，如果没有人知道“里面有什么”，那么这是一个强烈的迹象，表明有真正的问题等待被发现。

2.5 安全性和隐私

机器学习项目与数据资源紧密相连，通常是敏感且重要的数据资源，许多业务流程都依赖于这些资源，或者包含既受法律保护又对个人私密的详细信息。这使我们想到了我们的预售待办事项中的 PS7。

安全性和隐私票据：PS7

• 检查并记录安全性和隐私要求，并将两者都作为项目假设包括在内。

任何不安全的工程项目都可能为组织创造漏洞，因此一个机器学习项目需要满足其合作组织的安全要求是自然的。为了实现这一点，有必要尽快与目标组织的安全基础设施进行接触。在项目的预售阶段，我们希望收集评估和考虑安全约束和要求影响所需的信息。

不同的组织通常负责系统安全方面的签字确认。有时安全组织与 IT 完全分离，CSO 直接向 CEO 汇报。在最佳情况下，有一个单一的安全利益相关者参与客户组织，我们可以识别出来。更常见的是，需要几个安全利益相关者参与项目。

图 2.2 展示了我们可能需要在机器学习项目中参与的安全组织示例。可能需要从多个业务线获取数据集，包括为该项目聘请团队的业务线。可能还需要从集团运营（例如，定价和成本信息）获取额外数据。一个跨领域的关注点是开发基础设施和活动的 IT 安全，以及部署系统所需的必要生产平台访问。

图 2.2 大型公司内部一个安全组织的示例。每个面向市场的单位都拥有与该业务线相关的安全责任。一组营销单位也拥有安全职能，该职能向 CFO 汇报，还有一个 IT 安全单位，该单位向 CIO 或 CTO 汇报。

对于每个核心数据集、相关组织和 IT 平台，有必要建立相关的安全利益相关者。此外，我们需要了解数据隐私问题和需求（最初从高层次开始），以及需要协商的过程和需求。

同样重要的是，确定（最好与安全利益相关者一起）在安全过程中可能暴露出的问题。通常，安全人员会说要求很简单，不太可能成为问题。如果他们不愿意这么说，这可能是一个迹象，表明可能存在重大的障碍。在这个阶段确定处理该问题的方法可能是不可能的，但将其记录在项目风险登记册中是至关重要的。要么解决方案成为合同假设，为团队提供覆盖和灵活性范围，要么它成为一个需要仔细考虑的财务问题，在评估该项目是否可行以及可能花费多少时需要考虑！

2.6 企业责任、法规和伦理考量

关于安全方面，许多读者在阅读到这本书的这一部分时会说：“这应该是首先考虑的事情”，他们某种程度上是正确的。在理解项目之前，很难去思考企业社会责任（CSR）和伦理问题。一旦项目假设明确，就需要批判性地、从伦理角度思考你所做的事情。这是 PS8 的任务。

企业责任、法规和伦理考量事项：PS8

• 检查并记录 CSR 和伦理要求。

• 挑战并提供反馈，并将其包括在项目假设中。

• 创建 PDIA（隐私与数据影响评估）和 AIA（算法影响评估）文档。

在机器学习项目中，道德非常重要。法律和合法性，如欧洲通用数据保护条例（GDPR），对您应该考虑做的事情施加了限制。目前，关于机器学习系统的具体立法并不多，而且对算法定义及其监管方式存在混淆。这种状况可能会发生变化。

注意了解相关法律非常重要。请记住，由于无知而导致团队未能理解和遵守法规，与故意违反或规避规则一样糟糕。抓住每一个机会熟悉可能适用于您项目和团队的规定和法律。

同样重要的是要了解您所在领域的任何适用法律，以及相关司法管辖区生效的通用数据和机器学习法律。例如，您需要了解与医疗患者安全和测试相关的相关立法、与金融风险和流程相关的立法，以及与工业健康和安全相关的立法。有必要调查和明确是否有任何特定领域的立法适用于正在考虑的系统。

仅遵守与项目相关的法律，并不能为客户、您的组织以及您的团队创造良好的结果。英国信息专员办公室（ICO）已经为人工智能和机器学习系统的审计制定了一个框架[8]。该指南强调，这些系统必须对数据保护负责，并且这一点必须是可证明的。系统（在 ICO 看来）必须：

• 允许客户负责合规性。

• 允许评估和减轻系统的风险。

• 允许展示系统如何符合规定，并证明所做选择的合理性。

ICO 还指出，“由于人工智能供应链中通常涉及的各种处理方式的复杂性和相互依赖性，您需要仔细理解和识别控制器/处理器关系”，并且“证明您如何解决这些复杂性是问责制的重要要素。”

除了实施方面的考虑，所提议系统的道德影响也必须纳入需求分析。这些影响非常真实且影响深远。许多专著[9]以及更广泛的会议[3]和期刊[11]都讨论了关于人工智能、机器学习和算法决策影响的担忧。这些影响对我们社会中边缘化和无权力的群体尤为重要。

此外，目前正在努力捕捉和管理所谓的 AI 事件数据库[2]。在撰写本文时，该数据库记录了 1,225 起事件。其中一些例子包括那些没有考虑到常识或工作场所外员工需求的细粒度工作调度系统的影响。其他例子包括社交媒体上的内容审核和内容生成问题（例如，由 AI 机器人和多个账户导致的工业机器人致命事故）。

尽管文献中的讨论范围广泛且信息丰富，但它们是从学术和哲学的角度出发的。这意味着，在商业组织中工作的团队面临着一个额外的挑战：既要创建能够提供商业价值并具有道德完整性的系统。

支持计算机系统发展的商业案例通常涉及道德上有争议的权衡。在办公自动化的第一波浪潮中，许多坐在办公桌上的工作失去了，因为可以以成本效益的方式实施和安装能够完成数百或数千名索赔处理员、发票调整员或费用管理员的任务的计算机系统。这些系统犯的错误更少，并且可以更快地重新编程以反映业务政策的变化，比重新培训原有员工更快。（虽然有时会这样声称，但在这个背景下失败的系统升级的漫长历史使一些人对此有些怀疑。）这些系统不道德吗？从数百万失去工作的人的角度来看，它们似乎是如此，而且确实，有关这些项目的罢工和抗议活动已经组织起来[10]。

然而，共识是技术创新是不可避免的，那些未能创新和实施这些系统的组织或经济部门将变得过时，被竞争所摧毁。此外，在开发这些创新的同时，全球经济增长的需求是迫切的。这是普遍存在儿童饥饿和饥荒的时代。回顾过去，似乎经济的变化确实改善了数十亿人的条件，但所有社会中不平等的增长都表明新技术的部分应用作为工具，有利于社会中的统治阶级和社会主导群体。20 世纪后期和改变经济的第三次工业革命改变了创新不是选择而是坏选择的看法。有时，对某些人来说，它确实是一个坏选择。

这些教训以及社交网络应用对社会产生的负面影响提醒了机器学习从业者：看似整体积极的商业案例必须仔细权衡，并与所有受影响者的观点相平衡。我们需要从受影响者的角度审查一个拟议的项目，包括整体假设、用户故事和系统概述，并在可能的情况下，直接获取他们的反馈。我们还需要进行个人数据影响评估，并从应用的责任和治理要求的角度审查系统。关于与人工智能系统相关的伦理考虑，最先进的技术正在出现，在撰写本文时，受到相当大的争议。例如，参见《Wired》杂志上的 Bender 等人[4]的文章。

在评估一个系统的影响和含义时，很难避免个人和主观的偏见。尽管每位工程师都有责任尝试通过他们构建的解决方案避免伤害他人，但在工程师之间存在着经验和能力的分布。可能你和你团队富有同理心、洞察力，并且拥有理解你所推进的解决方案长期后果所需的各种视角。也可能你和你团队有着与某些人类相同的盲点和偏见倾向，因此你可能会忽略这一点。

考虑到人类的易错性，利用引入到评估中的结构化工具是有意义的。一个例子是加拿大政府开发的算法影响评估（AIA）工具[5]。该工具提供了一个问卷，用于确定将算法推理引入商业领域的项目可能造成的伤害或伤害程度。该工具在应用领域有限，例如缺乏关于医学、建筑和制造等领域的专业问题。然而，它提供了关于此类目的的工具形状和未来使用的指示。

算法影响评估工具的应用另一个例子来自 Ada Lovelace 研究所[1]。他们的指导有助于建议我们如何有效地使用这些工具来支持人工智能和机器学习从业者必须做出的选择。一些可用的模型允许采取实用主义的方法来交付一个安全且符合伦理的人工智能系统。例如，Hendrycks 等人[7]关于机器学习系统中安全性的研究提倡一种分层的安全保障模型。图 2.3 展示了构建一系列检查和防护层以捕捉系统可能造成的更多错误的概念。

图 2.3 中的层级包括：

• 外部安全或部署风险： 采用系统性的开发方法意味着你可以确定失败的原因。你可以逐步识别问题并将它们分类解决。

  风险登记册提供了一种实现这一目标的机制；其他包括运行明确的评估和与用户审查。然而，最终，系统将发布到野外，因此指定一个开发后的系统很重要，该系统应该安全运行。

• 监控: 通过系统检查，其行为被通知给用户和所有者。系统行为应被揭示并记录，并且应该有一个警报和通知的程序，将问题带到用户和利益相关者的注意中。

• 鲁棒性: 描述和测试系统在特定情况下的表现或行为，可以用（并应被理解）作为接受服务的流程的一部分。

• 对齐: 考虑谁控制着系统以及实施和报告这些机制的机制，以便它可以被适当的人类有意义地引导和控制。

图 2.3 机器学习安全分层模型（改编自 Hendrycks 等人[7]）

关键的是，您必须考虑并记录如果系统按预期运行，谁会受到伤害，如果它没有按预期运行，谁会受到伤害。例如（功能/失败）：

• 生成艺术: 可能会使艺术家失业或可能产生有害的图像。

• 生成文本: 可能会使记者失业或可能使互联网充满废话。

• 面部识别: 可能允许识别和逮捕持不同政见者，或者可能意味着无辜者被误认为是罪犯。

通过考虑这些对，可以开始确定您的系统可能产生的有害影响，这允许做出决定，是否继续开发它是一个好主意，或者相反，您需要开发哪些缓解措施以确保其安全部署。

在本节中我们涵盖了大量的内容。总结如下：

• 审查项目假设、用户故事和系统概述，以确定受实施影响以及由它们或其社区中的数据用于在系统中训练模型的影响的相关利益相关者名单。

• 从利益相关者的角度审查系统，并在可能的情况下，直接获取他们的输入，以确定系统对每个人的影响。

• 使用算法影响评估工具对拟议的系统进行系统评估。

• 将评估结果传达给项目利益相关者。

2.7 开发架构和流程

除了为用户生产的系统外，团队还需要生产或上线系统，允许创建和交付模型。PS9 概述了理解完成这项工作所需工作的要求。

开发架构票据：PS9

• 制定高级交付架构。

• 架构应涵盖开发、测试和生产组件（有时还包括预生产/测试阶段），并且能够支持客户非功能性需求，如可用性、弹性、安全性和吞吐量。

• 如果可能，与适当的利益相关者进行反馈，以验证这个架构。

• 将架构的关键方面作为项目的假设进行记录。

在运营领域，我们通常需要设置三到四层环境，然后配置并使用这些环境向真实用户展示内容。这些层包括团队工作的开发环境、测试环境，我们在这里检查系统的有效性和质量，以及实际运行的生产环境。在某些情况下，还可能有预生产环境，这是由于监管或数据保护问题而提供的。在这个环境中，我们可以进一步筛选测试系统在敏感数据面前的行为。这些层通常被称为开发、测试、生产和预生产（或 QA）。图 2.4 说明了这些层的排列、它们之间的流程以及用于管理代码和其他工件版本控制系统的使用。

图 2.4 交付环境；有时还需要一个完全复制生产的预生产或测试阶段层。

图 2.4 显示了这三个环境：

• 开发（dev）: 你的团队工作以创建解决方案的地方。开发环境可能包括用于模型训练的编译器、GPU 或 TPU 等专用工具，或者大型并行计算系统或多核机器用于模型搜索和评估。

  继续阅读，了解为什么在开发环境中推动这些机器可能很重要。许多开发环境不包含实时或敏感数据，而机器学习开发环境通常需要包含这类数据。这一需求需要明确并有效管理。

• 测试: 我们在这里进行模型评估，并测试生产所需组件。这个环境通常以高保真度复制生产系统，除了通常包含数据快照或模拟的系统数据库，以保护机密性并允许进行测试。

• 生产（prod）: 我们向客户交付结果的地方。生产环境应从需求分析期间与组织的互动中理解。

为了确定团队交付模型所需的系统方面，你需要理解开发和测试。同时，了解这些方面与生产环境之间的流程也很重要。此外，了解客户组织中的标准流程，你还需要深入研究特定于机器学习系统的相关问题。

2.7.1 开发环境

架构的开发层是团队工作的地方，它提供了他们快速有效地交付所需的支持。因此，你需要确定团队可以使用什么。幸运的是，有一些参考资料概述了 MLOps 团队将用于交付项目的机制（Treviel 2021）。

MLOps 环境包括团队快速迭代和发布新模型和解决方案所需的组件集。这些工具还允许他们控制和管理模型的演变，并以系统化的方式作为团队工作。

团队将使用客户的 MLOps 设置或需要构建的一个。如果已经存在 MLOps 基础设施，那么验证它是否符合你的需求是很重要的。否则，你需要确定（如果可能的话）可以做什么（如果有的话）来将其提升到满足团队需求的水平。当客户没有 MLOps 时，需要询问和回答的问题包括以下内容：

• 所需的源代码控制系统是否可以容纳项目产生的工件？如果不能，是否可能存在例外，并且达成一致？

• 开发环境中是否有可用的数据？

• 是否有适合建模工作的服务器（GPU、多核系统）以及足够的内存？

• 开发系统如何到达测试环境（特别关注非标准环境的路径）？

• 从测试迁移到生产需要哪些测试？

• 订单或获取所有三个交付层基础设施的时间表是什么？

• 谁批准基础设施的订单和支出？

• 是否有任何数据系统需要特殊的访问安排？有时我们只能从客户的场所或从安全列表中的笔记本电脑访问数据库，该笔记本电脑已安全设置以防止共享截图或其他数据导出技巧或解决方案被使用。

为了确定你是否拥有适合 ML 团队的工作环境，请考虑以下问题：

• 是否有地方可以托管模型存储库和特征存储库？

• 我们在哪里可以托管一个工具，用于在环境之间移动文件和工件？例如，我们可以在哪里运行 Jenkins 服务器？

• 我们在哪里可以运行数据管道工具？例如，我们可以在哪里托管一个 Airflow 服务器来运行更新和重新格式化任务？

• 需要多少努力才能建立这些系统，谁将承担这项任务？

如果你确信已经实施了 MLOps 系统，请获取技术描述，并在可能的情况下，由一位经验丰富的数据科学家进行验证。理想情况下，这个人将是项目建模团队的一员。

2.7.2 生产架构

开发架构中可用的内容将指导你如何构建模型并将它们开发成系统。生产（prod）架构，即客户日常使用的 IT 设备，决定了你将要构建的系统结构。

当你确定了模型特性和要求后，需要做大量工作来创建一个可以实施的详细系统架构。在这个阶段，需要的是一个高级别的解决方案，它可能作为开发成果交付。为了分解这个要求：

• 我们需要在高级别定义解决方案，这意味着我们识别将负责系统不同功能的组件。这些组件的使用方式和它们如何交互在此阶段没有详细定义。

• 我们有可能交付解决方案，这意味着组件在客户的架构中可用，团队和客户知道如何部署和使用它们。

创建此设计的目的是展示有一种合理的方式来交付系统。如果在创建此类高级设计时出现问题，因为所需的某些组件缺失或团队没有足够的经验来使用它们，那么这项任务已经完成了它的职责。现在需要揭露必须填补的差距，因为如果在项目后期修复它将太迟。

回到智能建筑示例，提供解决方案需要哪些系统组件？建筑中的传感器数据需要流入数据库，并且需要一个执行环境来运行模型以确定建筑的控制信号。这些信号需要从建筑执行器中调用动作，并且系统生命周期中的事件和决策信息需要展示给用户和业主，以便了解正在发生什么。以下是一些高级要求：

• 一个管理从传感器到执行器信息流的消息系统。

• 一个存储传感器信息和执行器指令历史的数据库。

• 执行环境。

• 一个仪表板系统。

• 一个身份验证系统（用于管理用户账户）。

建筑业主的系统架构师知道目前在使用什么。例如，他们可能有一个现有的数据库和一个用于管理所有员工和进入建筑的认证系统。在这个例子中，结果架构将是：

• 数据库使用 MySQL。

• 仪表板使用 Tableau。

• 身份验证使用 Active Directory。

在这个架构中，消息系统是新的。那么需要问的问题是，引入像 Apache Kafka 这样的消息系统是否可以接受？为了使 Apache Kafka 被接受并部署到生产环境需要做什么？这项工作必须有人来做，但预期是谁来做，以及何时完成？

摘要

• 如果你想成功管理风险，开发一个项目的结构化流程是必要的。

• 理解如何管理项目以及理解所需的项目管理基础设施是很重要的。

• 机器学习项目具有特定的特征，这些特征需要作为需求来捕捉。

• 需要特别注意将支撑项目的数据资产，以及了解可用的数据情况。

• 了解数据如何被访问以及可用于操作和准备数据以供机器学习使用的功能是很重要的。

• 我们需要了解关于数据资产安全和隐私的具体要求；这可能会给项目带来更高的成本。

• 需要一个理解透彻且适合目的的开发基础设施，并且项目将要交付的 IT 架构需要清晰明确。

• 应从项目开始时就考虑企业的责任和伦理方面。

3 项目前期：从需求到提案

本章涵盖：

• 创建项目假设

• 生成努力和时间估算

• 完成文件工作以启动项目

• 完成您的销售前清单

在第二章中，我们涵盖了项目前期工作的一半。首先，你设置了完成必要工作所需工具和基础设施。然后，你承担了一些任务来收集项目需求，强调项目关注的机器学习特定问题。特别是，你研究了项目数据集，并发现团队获取数据的难易程度。你还记录了数据特定的安全问题、隐私问题，并了解该项目的关键伦理和社会关注点。

这些需求现在需要综合成一个声明，说明将要发生什么，该意图存在的问题以及这将花费多少。一旦掌握这些，您的组织和客户的业务就可以做出是否继续项目的理性决定。这是我们将在本章中涉及的工作。

3.1 构建项目假设

项目假设阐述了项目的目的和需要克服的主要挑战。从第二章的销售前待办事项继续，让我们看看票据 PS10。这是理解项目核心问题的必要工作。

项目假设票据：PS10

• 理解业务问题：通过达成共识来构建项目假设，并经客户和交付团队验证。确保这一点在任何合同协议中得到明确沟通和记录。

机器学习项目的一个特点是，业务很少清楚地阐述机器学习部分，即使阐述得清楚，也往往是现实主义的，或者不太可能创造太多价值。如果你不知道特定的机器学习算法是如何工作的，就很难想象一个机器学习系统是如何解决问题的。目前，在我们的项目中，我们想要：

• 记录股东阐述的挑战和好处。

• 反思数据、系统架构和非功能性约束。

• 根据已知情况记录潜在结果。

• 向利益相关者提供反馈，以达成项目共识。

想象一个能解决任何问题的神奇盒子是有用的。这导致我们在机器学习项目描述背后的思维存在巨大的差距，有时就像一个断言，即机器学习可以修复任何需要修复的东西。这也导致了让利益相关者接受并理解您和您的团队提出的任何现实项目的难题。有时，现实可能不像我们希望的那样性感。也许随着机器学习变得更加主流，这种情况会改变，但机器学习的多样性和复杂性使这种现实变得有些可疑。毕竟，微软 Excel 已经主流了 20 年或更长时间，但统计学家仍然需要设计试验和实验，并对结果进行有意义的分析。

您和您的团队需要识别并（有说服力地）阐述一个概念，该概念利用可用数据为业务创造价值；它还必须具有足够的价值以证明投资的合理性。您可以使用迄今为止所做的工作来向自己、信任的合作伙伴或潜在团队成员简要介绍项目的问题和挑战。

您需要捕捉两类需求：

• 功能性需求：系统需要执行的过程。功能性需求描述了一组输入和所需的输出。将输入转换为输出的过程是团队需要构建的内容。例如，输入 = {用户资料，预算，日期} 输出 = {推荐书 _1，推荐书 _2，...，推荐书 _n}。

• 非功能性需求：对功能性需求必须如何表现的限制。例如，推荐必须成本低于$0.0001，推荐必须在 200ms 内生成。

需求分析应产生一份挑战和商业机会的清单。这些是可能改善客户业务的事情，但其中一些可能不可行或不切实际。因此，该清单需要根据自捕获以来关于数据、项目设置和安全的所有发现进行验证。

如果您确实得到了一个可行的概念的列表，那么请对这些概念的描述增加一些细节。敏捷项目使用系统故事（概念如何交付）和用户故事（谁将使用并受项目影响）。在这个阶段，这些活动是为了验证：是否有可行的实施路径，以及是否有机制允许解决方案产生影响和商业效果？稍后，如果项目运行，您将拥有资金和资源来深入了解这一点，并详细阐述这些故事。通过现在编写用户故事，您希望：

• 识别并记录关键功能和需求。

• 确定可能成为项目验收标准的项目项。

• 建立必须避免的重要问题和危害。

• 建立会使系统无关或无法工作的边缘情况。

您应该为尽可能多的相关利益相关者（业务赞助商、员工/用户、客户/受影响的人）开发用户故事，并涵盖三种揭示机器学习系统重要需求的情况：系统首次使用或接触利益相关者时，正常使用时，以及系统停止使用时。对于您的项目，重要的是要确定并描述在每个这些故事中用户调用的机器学习模型。这就是必须构建的模型！考虑：

• 它是什么样的模型？

• 需要哪些数据来创建它？

• 运行它需要哪些数据？

此外，每个故事都必须描述模型将在这个特定故事中为特定利益相关者做什么。这应该在较高层次上揭示每个利益相关者需求之间的共性和差异，所需模型的范围以及每个模型的要求。

项目假设票据：PS11

• 承担项目尽职调查。利益相关者是否可用？数据是否可用且可管理？哪些团队成员可用以及他们有什么技能？

一旦完成这些，就用假设（例如，我们将测试我们是否可以使用表 XYZ 中的数据创建一个预测客户流失的模型）和调查（例如，我们将调查该模型如何在企业的运营背景下使用）的术语来构建概念。这种构建将项目从必须构建的概念转变为需要采取的一系列行动：测试、创建、建模、调查、使用。通过检查以下内容来验证产生的概念：

• 技术可行性：这个项目对您的团队来说有多大的风险、新颖和困难？显然，如果他们以前做过类似的事情并且熟悉核心技术，那么风险就会降低。

  然而，通常项目的一些方面对团队来说是新颖的。重要的是要确定这一点，了解它代表了多大的差距，并确定如果它很大，可能的缓解措施是什么。此外，考虑客户的基础设施是否能够应对（可能）的非功能性需求。

• 可行的商业案例：您可能无法获得足够的访问权和洞察力来构建详细的案例；客户需要开发这个案例以获得资金。然而，了解节省的规模、收入增长、生活质量改善等，以及项目所启用的机制，为您提供了强大的指南，以引导未来的结果。

• 商业可行性：是否有资金来支付完成整个项目所需的所有工作？这与商业案例要求是不同的考虑。一个项目可以为金钱提供惊人的价值，但如果支付它的资金不可用，那么项目就不会发生。

在构建概念时，还需要考虑的其他事项包括：

• 该概念解决了客户哪些战略业务优先事项（如有组织模型，请参考）？

• 项目能否使用客户描述的数据资源来完成？

• 客户是否有有效利用成果的方法？

图 3.1 展示了这些元素如何相互作用以创建一个功能性的项目。如图所示，业务优先级和业务案例解锁了充足的资金。通常，组织有长长的业务案例列表，但由于它们只为更好的和更有战略性的项目使用资金，所以没有得到资助。通常，仅仅案例本身并不足以就项目达成一致并启动它。如果有资金，你需要确保执行项目的技术手段到位，数据资源能够支持它。最后，尽管你有一个完全可行且价值高的系统准备就绪，但现在的问题是它是否可以被使用？也就是说，那些应该利用成果的人实际上是否真的会利用它？这个解决方案是否有用且可行？

图 3.1 项目驱动因素（业务优先级和业务案例）、支持组件（充足的资金、技术手段和数据资源）以及促进因素（利用方法）。

如果图 3.1 中的所有元素都已就绪，那么你可以编写并传达一个可行的项目假设。在这个过程中存在一定的迭代性，伴随着理解，因为你探索并阐明项目的价值和客户资助的意愿。希望你所发展的结构能让所有利益相关者验证这个项目是值得做的。

当然，你可能找不到这个项目的可行概念。图 3.1 中的某些部分可能难以捉摸，但你现在看到这一点是好事。无论如何，以这种方式审视项目意味着你已经使用了一个结构化和专业的流程来确定进行项目的风险和项目的潜在收益是否适合所需的资金。

3.2 创建估算

明确的项目定义是很好的，但除非这个定义可以转化为估算，否则它就像一个由蜡制成的茶壶一样无用。工单 PS12、PS13 和 PS14 定义了帮助我们从定义到估算的任务。

估算构建工单：PS12

• 为一个模型项目创建一个工作估算，确保满足所需的项目假设，同时考虑到可用的团队和所需工作的规模。

• 确保你的估算中考虑到了所有项目风险。

估算构建工单：PS13

• 创建并推广团队设计和资源配置。

估算构建工单：PS14

• 举行审查会议并检查清单以确保预销售过程得到适当完成。

你现在有了项目概念的大纲，一些关于顶级系统设计外观的数据，你已经系统地审查了它，以确保没有已知的法律或道德限制。你已经记录了这些事情，所以下一个任务是把这个大纲转换成一个项目描述，它将捕捉到需要做什么，由谁来做，以及何时交付。事实上，你的团队将适应项目展开的现实。你在这里创建的是一个可信的资源资金包裹，以便能够得到一个可行的结果。

3.2.1 时间和努力估算

到目前为止的所有准备和调查还没有产生一个估算。从你设计的项目结构转移到时间和成本估算，需要采取两个行动：

• 使用本书每一章的后备清单来创建你项目的任务清单作为起点。随着项目的演变，你将发现工作的内容。你可以根据需求自由添加和删除任务，但如果你在寻找一个起点，那么这就是它。

• 如果将要进行工作的人们与你一起制定估算，他们将从一开始就拥有这个计划。将你的团队带到桌前，共同制定估算。挑战他们深入挖掘需要完成的所有必要任务的工作。让他们揭示在机械和行政任务上需要花费的时间，除了高调的技术工作之外。

虽然还有待发现，但我们现在已经掌握了我们面临的挑战的非功能性和系统方面。与估算每个项目任务所需努力的每个人分享并阐明这些内容。构建必须满足广泛和严格非功能要求，同时还要功能正常运行的模型是困难的。将要服务于数千用户的用户界面，比只服务于少数用户的用户界面要困难得多，也昂贵得多。关于你需要参与此过程的任何专家，要明确说明。此外：

• 确保你捕捉到对材料的需求。例如，你对计算消耗有什么需求？你是否需要特殊硬件，如耳机、电话、传感器，或者顶级的笔记本电脑或显示器（由专家开发者所需）？

• 捕获模型训练或数据处理的特殊需求和成本。团队很容易假设访问强大的 GPU 将不会很贵，但发现他们需要在 GPU 上消耗数百小时，而这非常昂贵，这会带来问题。另一个容易被忽视的成本是将数据导入和导出到云基础设施，这些是收费且昂贵的，但在机器学习项目中，这可能需要反复大规模地进行。

除了创建任务列表或项目待办事项列表，这些列表会随着项目的演变而持续优化，你还需要估计待办事项列表中每项工作的规模。这可以通过使用t-shirt sizing来实现。这是一种简单的方法，可以对一系列任务的整体规模进行估计。（之所以称为 t-shirting，是因为任务的努力程度仅以小、中、大和 XL 来衡量，没有更多的粒度。）通常，进行这项工作的人可以就这些类别达成一致，而无需太多争论，项目的整体规模很快就会显现出来。

使用 t-shirt sizing 有两种方式。首先，当任务规模达成一致时，你可以将每个尺码类别的任务分组，并亲自向团队询问每个类别中每个任务的估算人天数。例如，团队可能会查看所有被提名的小型任务，并同意这些任务可能需要一个人一天的时间来完成。有时，这会导致一些任务被重新排列，但这是可以的。这允许你将每个类别的所有任务，然后是所有类别加总，以给出一个努力程度的估计。

T 恤尺码的第二种用途是记录需要完成的任务实际所需的时间，然后利用这些信息来确定随着项目的展开，努力估计的可靠性。如果原本认为小任务只需一天就能完成，但开始持续需要更多时间，那么你的估计就是错误的，你需要做一些紧急工作来确定项目是否陷入困境。

在对项目中要完成的任务以及完成每项任务所需的工作规模有了总体了解之后，接下来要考虑的是谁将完成所有这些工作？让我们接下来看看这个问题的答案。

3.2.2 机器学习项目的团队设计

对于机器学习项目，所需的团队决定了项目成本的最大部分，虽然有些项目成本较高，但通常，团队的时间将是项目成本的最大部分。如果你要准确估计项目将给你的组织带来多少成本，或者如果适用，应该收取多少费用，那么理解团队设计（谁将交付工作？）是至关重要的。

要从项目路线图中执行实际资源配置工作，你需要有系统性和确保每个任务都有一个分配的资源，该资源覆盖了预期挑战的规模。这很难做到准确，但将项目分解成一系列任务，并逐个估计每个任务，会使问题更容易处理。一个好的做法是在团队中这样做，也许可以邀请在项目前期过程中与你一起工作的人，或者调用高级资源来处理项目本身。本质上，你想要确定哪种类型的人能够完成指定的任务，以及他们完成该任务所需的时间。为了了解谁可以预期完成每个任务，了解可能为项目提供帮助的人的类型是有益的。

在专业角色方面，有四个角色是从机器学习项目中复杂性的三个驱动因素（图 3.2）的交叉中出现的。在第一章中，图 1.2 指出，机器学习项目的复杂性是由专家克服来自数据、建模和领域对齐的挑战的需求驱动的。

图 3.2 机器学习项目中由三个复杂性驱动因素创建的团队角色

图 3.2 还展示了在这些困难领域工作的某些角色。这四个角色是：

• 商务翻译员: 这是一种流行的说法，指的是那些对机器学习系统有深入了解，并擅长在领域专家和机器学习专家之间架起桥梁的商业分析师和软件工程师。

  商务翻译员的想法对 IT 领导者来说很有吸引力，因为它解决了一些关于机器学习专家和团队脱离现实的常见抱怨。在某种程度上，到 2022 年，商务翻译员如何有效地为机器学习项目做出贡献仍然不清楚，尤其是当机器学习工程师和数据科学家可能有自己的强烈观点时。然而，一个对与用户和利益相关者紧密合作以收集和发展团队领导者的见解感兴趣的人，在繁忙的项目中可能是一个救星。

  在某些团队中，这个角色主要由充当产品所有者的客户承担（以下是对此要求的描述）。在其他情况下，产品所有者的时间对于详细业务调查来说太宝贵了，你需要为这个角色引入一个专家。

• 数据工程师: 他们是获取、移动、调动和操作资源的专家。他们拥有关于平台、工具、编程语言、安全性、成本和效率的知识。

  数据工程师可以帮助你的团队应对尴尬的数据资源。由于在组织中的先前项目工作，他们可能对要操作的数据的结构和属性有一些见解，并且对数据的业务用途有一些了解。然而，在许多情况下，他们将纯粹是技术贡献者，依赖于业务翻译者或产品所有者来了解数据存储中的内容。

• 机器学习（ML）工程师：这些人员与项目产生的模型一起工作。他们创建并使用存储、版本控制和管理的模型的基础设施，但他们还承担设置测试系统和运行评估等任务。对于机器学习工程师来说，另一个重要任务是实施有效的模型服务机制，以便在场景中运行模型并产生结果。能够以弹性、低延迟、高吞吐量或低成本完成这项任务可以是一项真正的壮举，因此这是任何团队都应具备的宝贵技能。

  当模型嵌入到有效的服务基础设施中时，机器学习工程师通常致力于将结果子系统与业务应用程序集成，以释放价值。这就是他们与业务翻译者重叠和互动的地方。

• 数据科学家：中间人员，专门从事创建模型。他们还了解对数据进行条件化以进行有效建模和测试以及评估模型以确定其有效性的方法。

你也可能有专注于机器学习项目之外的人员作为资源可用。这些人也可以帮助团队：

• 软件工程师：拥有在团队中生产可靠和可管理软件所需特定技能的程序员。开发者通常是更注重个人主义的程序员，他们更多地作为单独的问题解决者和故障排除者工作。在征用这些资源时要小心，因为有些人对软件工程师或开发者的理解模糊，因此这些术语通常可以互换使用。

• DevOps 工程师：专门负责设置和管理软件开发基础设施。通常，他们在大型项目中工作，其中开发基础设施是一个很大的开销。有时，机器学习工程师具有 DevOps 工程技能和背景，因此他们可能能够满足这些要求。引入 DevOps 工程师可以填补机器学习工程师的一些工作。

• 云工程师：专门负责设置和管理云基础设施，如私有网络和 IAM（身份和访问管理）配置。他们通常也擅长使用云管理服务组件，如数据仓库。如果数据工程资源不可用，你通常可以使用这些人来支持数据科学家。

• 交付经理： 能够通过组织和管理会议、与利益相关者交谈、创建报告和管理文档流程来促进和支持项目管理的人。

• UX 工程师： 通过与系统用户交谈并了解他们对系统的影响来开发用户界面和交互设计的专家。

• 测试和 QA 工程师： 专注于创建和运行测试系统，使您的系统能够获得批准并投入生产。在机器学习项目中，对模型进行广泛的测试以评估其性能（在第七章和第八章中详细说明）。除了从事模型测试的机器学习工程师和数据科学家外，还可能需要从用户或平台的角度对系统进行测试。

要明确，这些角色通常由多个团队成员或单个团队成员共同承担。也可以说，对于每个确定的角色的技能矩阵和分配，都有其他看法。例如，一些组织认为数据工程师是通才，他们在机器学习项目的生命周期中工作，有时支持数据科学家或机器学习工程师。这个概念并不比之前的分解更错或更差；它只是不同，对于某些组织来说更为合适。

决定团队成员的另一个因素是哪些人可用。项目经理很难找到能够为工作组建完美团队的成员。你必须准备好并能够根据实际情况调整计划。以下是一些应对这一挑战的建议：

• 先匹配大块部分： 这是一种陈词滥调，但如果你首先关注项目团队最重要的元素，那么你就可以围绕更外围的活动和角色进行即兴创作。

• 优先寻找正确的行为而不是成就： 分享技能和见解并指导同事的团队成员特别有价值。同时，能够批判性和建设性地思考并为团队的创造性问题解决做出贡献的团队成员也非常有价值。

• 通才往往比专家更有用。 尤其是在小型团队中，那些既有专业技能又愿意并且能够根据需要担任通才角色的人是宝贵的资源。这些人就是传说中的T 型人才，与只有狭窄而深入的专长的I 型人形成对比。

  更倾向于通才型的人可以在整个项目中做出贡献，而不是仅仅参与几周然后离开。通常，从项目开始到结束全程参与的人更有动力。另一个优点是，坚持项目的成员了解正在发生的事情；在简报人们等方面需要付出的努力要少得多。

  一个共同努力深入理解特定挑战的团队可以更快地交付更高质量的整体成果。这里的大前提是，如果项目需要专业技能，专家贡献者不仅有用，而且是必需的。通常，这是在更大、更复杂的项目中。幸运的是，这些项目（以及维持它们的组织）可以承担聘请所需专家的费用。

• 寻找团队的发展机会： 通过帮助人们获得技能和经验，你正在确保未来的价值。他们希望再次与你合作，并且当使用时，团队中的资深成员也将从指导经验中受益。另一方面，你只能承担这么多，否则团队的生产力会受到影响。

图 3.3 展示了随着技能需求的变化、新团队成员的加入以及做出贡献的人离开，一个团队在项目中的演变过程。例如，在冲刺 1（图 3.3）中为云工程师分配的短期任务可能存在一些问题。工程师可能会对被突然加入到项目中解决几个问题感到不满，或者他们可能喜欢在长期工作之间的快速任务。

图 3.3 项目冲刺期间的团队演变

在图中，仅显示了第 3 个冲刺的 HCI（人机交互）工程师，也可以称为 UX 工程师。在这种情况下，为期两周的分配可能对这个人来说效果很好，因为这是一个真正为展示项目增加价值的机会。另一方面，如果 HCI 工程师缺乏完成适当工作的项目背景，这可能会成为问题。这些问题有时很难避免。实际上，你能做的就是与相关人员保持联系，并尽你所能使分配对每个人都是可行的。

当你对团队结构有一个很好的了解时，设立一些项目前的团队导向会议可能是个好主意。这可以让团队了解对他们个人的期望，并弄清楚他们将和谁一起工作。此外，检查在任务需要时资源是否可用。然后汇总任务和分配，为项目中的每个冲刺创建一个敏捷团队。

项目团队的核心成员在整个项目期间应保持稳定，但如前所述，一些人可能会加入或退出以提供所需的专长和交付能力。总结一下，这个过程是：

1. 使用书中回溯中概述的任务集创建一个任务列表，并在可能的情况下与项目团队补充和详细说明。

2. 确定完成每个任务所需的角色和专长。

3. 估算每个任务的所需工作量。

4. 汇总工作量并确定每个角色所需的承诺程度。

5. 制定一个最接近所需努力的职责资源计划。

6. 确定一个符合职责资源计划的潜在团队设计。

7. 确定团队所需承诺成本的整体成本。

除了所有这些考虑因素之外，重要的是要理解客户也需要支持项目。他们需要提供知识和 IT 支持，你需要知道（来自客户的）谁将担任产品负责人。在这个阶段，通常不可能将客户的人预订到你的项目中并预留他们的时间；还没有达成任何协议，但有一些已确定的候选人会让人感到安心。通常，你需要识别：

• 产品负责人：能够提供反馈和输入的客户代表，这使团队能够集中精力，有效地对与客户需求一致的问题和发现做出反应。

• 技术/行政问题解决者：能够帮助团队克服他们遇到的任何行政障碍的人。内部代表通常更了解如何处理他们组织内部的问题，并且在与客户的设施和行政沟通方面处于更有利的地位。

关于团队的一个最后要点：你期望加入团队的人可能存在冲突（已预订假期或其他事件），这会阻止他们参与项目。如果你认为某人可能加入你的团队，但他们即将退休或转到另一个组织，那么这个资源选项就根本无法行得通！

一旦确定了团队并掌握了完整的任务清单，你就可以审查你创建的项目路线图，并检查潜在的优化或问题。为了优化，并行运行任务，并确保高价值资源集中在高价值的生产性工作上。在这个阶段可以识别的问题通常是那些需要完成以解锁项目的任务，但它依赖于其他有风险的任务。

这是一个敏捷项目，我们不会知道将要出现的问题和故障的一半。尽管如此，在这个阶段尽可能多地了解未知因素，以尝试避免明显的陷阱是好的。

3.2.3 项目风险

在创建了资源估算之后，重要的是要审查风险登记册。你是否已经考虑了缓解和解决项目面临的风险的可能成本？如果没有，那么请确保你在估算中添加适当的工作量和弹性来应对这些问题。例如：

• 确定潜在的缓解措施或替代方案。之前成功使用的缓解措施价值较高；新的缓解措施价值较低。

• 估算缓解成本并将其包含在预算中。将低置信度估算与高风险溢价（通常为 100%）一起添加。例如，如果低置信度缓解的估算为 500 美元，则将其作为项目成本中的 1000 美元输入。将高置信度缓解以 30%的溢价添加。例如，500 美元的缓解将添加为 650 美元。

  注意缓解价格是一项可收费项目；客户预期为此类工作支付的金额，而不是作为您组织的成本。风险溢价是额外的，加上您组织增加的利润率，以允许其作为一家成功的业务运营。

• 进行审查以确保没有高影响（可能导致项目失败和收入损失）和低价值缓解（没有明确的解决方案路径）的风险。

• 让您组织的一名官员（在项目失败的情况下负责的人）签署预算并确认他们接受您提出的风险。您的任务是确保他们了解并理解组织所承担的风险。

记录此过程，并与签署风险的人共享文档。例如，在签署会议后发送一封电子邮件，其中包含您用于向所有人简要介绍的内容。当机器学习项目运行时（本书其余部分详细说明），您可能希望每周与项目利益相关者举行一次审查和更新会议，以讨论和共享风险登记册。

一些风险是无法管理的。事实是，如果数据不存在或由于质量或可用性问题而无法使用，则无法从中开发出有用的模型。如果您无法检查数据或明确建立模型将如何开发或实施到有用的系统中，那么您无法承担估算。如果是这种情况，那么需要进行进一步的研究和付费，这取决于具体情况，可能由您的组织或客户承担。要明确，并确保您将此类项目作为实验或调查来界定。尽管在您组织签订的合同中应该有技术上的法律条款来保护您，但与客户进行清晰沟通非常重要。

3.3 预销售/项目前期管理

项目前期管理工单：PS15

• 确保所有适当的文件都已到位：

  • 主服务协议

  • 工作说明书

  • 根据项目要求签订的保密协议和其他正式文件

在某些项目中，需要正式合同。这些包括：

• 主服务协议（MSA）: 规定了您组织与客户之间的支付和责任机制，并管理整个关系。许多项目都由一个主服务协议覆盖。

• 工作说明书： 定义了交付项目所需的努力和活动，并提供了关于将要交付内容的法律协议。重要的是，它还规定了应支付哪些报销以及何时支付。

• 保密（NDA）、保密性和知识产权协议： 取决于 MSA 以及你所在司法管辖区。

总是将这些文档的开发工作交给那些在法律上合格且在组织上负责的人员。永远不要被诱惑自己去完成这些工作，或者只是简单地跟随客户提出的建议。最终，如果你在讨论初期就涉及法律团队，这将节省时间（并提高项目的质量和结果）。他们可能会提出令人不舒服的反对意见，并在互动中提出令人烦恼的要求（例如，禁止进行持续工作，直到达成协议），但将他们引入以撤销由此产生的损害的后果要大得多。

当你创建了一个有充分依据的协议并适当签署（通常，可能需要区域 CTO 和 COO 都签署）并且它已获得客户批准并签署后，项目工作就可以开始了。然而，在你准备好获取签名之前，通过清单进行检查以确保没有遗漏是有帮助的，并且可以提供安慰。

3.4 预项目/销售前清单

在处理完之前列出和描述的项目后，你应该能够完成以下预项目/销售前清单。此清单（表 3.1）让你检查每个项目，以验证是否有足够的证据表明任务已适当完成。

表 3.1 预项目/销售前清单

票号	项目	备注
PP1.0	项目文档存储库	在文档存储系统上设置一个特定的工作空间、文件夹或目录，用于此工作，并将所有文档复制到那里以供参考。预项目阶段产生的文档已存储，没有遗漏。每个人都可以检索文档。存储库符合数据保留和信息安全管理政策。
PP1.1	风险登记册	风险登记册在存储库中可用。所有有权访问它的人员都可以查看当前的风险集合。已退役风险的历史和证据可访问。最终登记册已与项目利益相关者/经理/老板审查，并确保审查有证据记录，显示风险已按文档记录。
PP1.2	项目假设	项目目的是否已经明确描述并作为假设或调查来界定？交付团队是否理解可行的商业案例？假设是否被团队清楚地理解，并记录在任何项目声明中，所有利益相关者是否都了解并批准了它？
PP1.3	谨慎完成	确保以下内容已完成并可在存储库中找到：详细说明利益相关者、最终用户、目标和关系的组织图。数据访问信息，包括在哪里、什么以及如何访问。包含提供和已知需求/问题的可能时间表的高级解决方案和客户/预期部署架构。获取的任何数据样本以及对其进行的任何评估或调查。用于证明合法和道德交付路线的数据保护、隐私和道德要求文件。
P1.4	高级交付计划	完成的高级别任务列表，可能基于本书中的项目结构，但针对实际要执行的项目进行了定制。完成这些任务所需努力量的估计。所需的团队以及他们是否可用。
PP1.5	估算	对时间和材料进行估算：交付成本加上解决或缓解已知风险所需的努力以及针对这些风险给予的适当溢价。
PP1.6	预售管理	所有 NDA（保密协议）、主服务协议和任务说明都到位。所有文件都经过法律团队的验证并获得同意。文件已准备好供授权签字（COO 等）。

与你的团队一起过一遍这个清单，确保他们和你都认为这些项目是完整的。一个技巧是不要自己主持这个会议，而是让团队中相对较年轻的人来主持。可能不是最年轻的那个人，因为那样有点不公平，但应该是团队尊重并且会从主持一些会议的经验中受益的人。通过让他们来安排会议并主持它，你可以避免每个人都认为他们应该只是同意的情况。从你的角度来看，你现在想要知道是否有什么被忽略了，现在还来得及，在你仍然（希望）能够修复事情之前。

第二章和第三章概述的整个预项目流程在实际中是如何展开的？下一节提供了一个描述现实生活中可能发生的事情的叙述。这是关于自行车店项目的第一个小故事，旨在帮助说明本书中的方法如何在实践中应用。

3.5 自行车店预售

（虚构的）咨询销售团队在虚构的制造和零售公司“自行车店”中识别到一个 RFI（信息请求）机会。运行业务运营的 SaaS 和本地部署软件包需要大量的资本投资，这主要是因为许可证续费以及需要新的硬件来替换现有的。

通过转向循环运营支出（OpEx）模式，而不是大爆炸资本支出（CapEx）投资模式，公司可以释放资金来投资新的物流设施，以及更新和升级公司的品牌和商店。为此，自行车商店希望转向基于云的解决方案。

对于自行车商店的管理层来说，一个令人沮丧的地方是，他们无法使用当前系统来创建一个关于业务状况的单一概述，并从该概述中生成商业智能。在非正式讨论之后，你被拉入工作，参与预销售机会。

自行车商店项目的初始 RFI 没有包含任何关于所需应用程序的细节。在客户 RFI 流程的一次会议中，你的团队询问了这个问题，并透露业务的关键优先事项是减少开支，以释放资金来改善他们过时的分销系统。他们希望通过提高客户保留率来实现这一点。逻辑是，通过让客户保持更长时间并让他们花更多钱，他们就不需要开发新市场并吸引新客户到业务中。

这促使你建议可能可以使用自行车商店的数据来识别哪些客户有很高的流失风险。此外，你可能还能提出一些可能阻止客户流失的干预措施。这是一种许多其他公司都使用的标准应用。在自行车商店的情况下，他们分散的 IT 资产阻止了他们能够利用数据进行类似的事情。

在随后的讨论中，潜在客户指出，新物流系统的一个原因是因为公司经常发现很难利用增长并管理来自客户的需求。为了满足增长需求，业务必须持有大量组件的库存。拥有过多的组件成本高昂，但拥有过少的组件意味着损失收入。你建议，可能可以根据自行车商店的历史和开源数据来预测需求，这些数据揭示了经济和社会趋势。客户似乎对可能性感到兴奋，电话结束后，你开始撰写提案和估算，作为对 RFI 的回应。

你使用你组织标准工具（在这种情况下，是 Confluence）设置了一个文档库，并在你组织的 Jira 中创建了一个待办事项列表。你创建的第一个文档是项目风险登记册。表 3.2 显示了完成登记册的一个示例（显然，当它首次创建时，它是空的）。

表 3.2 自行车商店机器学习项目的风险登记册

风险 ID	描述	状态	负责人
TBS1	无法获取高质量的天气/经济开源数据	开放	你
TBS2	由于数据清洗，客户行为历史记录不足	开放	你
TBS3	不可用的数据科学资源	开放	你

预售待办事项中的下一项是通过对组织建模来了解更多关于你的客户的信息。首先，你询问 RFI 项目团队是否有一个客户捕获的组织结构图，他们确实有。图 3.4 显示了这张图，你将其捕获并保存在你的存储库中供参考。

你还考虑了另外两个组织问题：首先，谁是这个项目的利益相关者和客户，其次，谁是最终用户？通过与 RFI 团队的成员交谈，你确定 CIO Karima Shar 是商业智能总监，这可能是关键的利益相关者。你联系 RFI 团队的业务经理，要求在下一场与客户的 RFI 更新会议议程中包含一项内容，并请求与 Karima 会面，讨论潜在的项目。

图 3.4 The Bike Shop 的组织结构图

在与 Karima 的会议中，你揭示了工作的概念，并询问这项功能将在业务中的哪个部分被使用。Karima 能够告诉你，The Bike Shop 零售部门的客服团队使用客户流失信息，而制造部门使用你描述的库存预测功能。她对此可能性表现出兴奋，并认为在整体计划中整合工作流以将 The Bike Shop 的数据迁移到云并提升其能力有很大的潜力。

在这个阶段，Karima 无法与你分享任何数据，但她似乎有信心这些数据存储在 SAP 数据仓库（opdis2）中，该仓库由 CIO 负责运营以支持业务。Karima 知道其中一些数据可以个人识别客户，但对此没有任何非同寻常的安全或隐私担忧。此外，她也不知道 The Bike Shop 更倾向于开发哪种类型的系统架构来交付所提出的系统。

这些概念已写入工作说明书的背景部分，以定义你的团队将工作的整体挑战。你以假设的形式来撰写它们：

• 挑战 1: 该项目将验证是否可以使用 The Bike Shop 的 opdis2 数据库和其他资产来构建一个客户流失预测系统，并将测量该系统在预测的召回率和精确率方面的性能。

• 挑战 2: 该项目将验证是否可以使用 The Bike Shop 的 opdis2 数据库和其他资产来构建一个需求预测系统，并将测量该系统在预测的召回率和精确率方面的性能。

• 挑战 3: 你调查了一种实施方法，该方法使用从 opdis2 迁移到新云平台的数据和数据流，为制造和零售服务领域的用户提供及时、可操作的信息。这使得他们能够优化与库存、供应和客户互动相关的业务决策。

• 挑战 4: 如果 1-3 号挑战得到客户的满意完成，你将实施并交付一个提供所需功能的系统。

在与客户代表的讨论中，提出并讨论了许多假设。你意识到，如果这些假设没有在工作说明书中记录，那么在项目后期可能会出现重大的争议，因此你创建了一个项目假设文档，将其存档，完成工单，并喝了一杯茶：

• 假设 1: 数据库和数据流迁移到云上正在进行中，并通过了其项目里程碑和关卡。

• 假设 2: 你和你的团队能够访问 opdis2 和其他所需数据资产，将数据提取到批准的开发环境中，在那里你有账户和适当的授权。

• 假设 3: 团队将此数据与开发环境中的开源数据相结合。

• 假设 4: 你使用应用程序环境提供测试和生产数据。

• 假设 5: 你需要访问自行车商店的商业专家，以帮助阐明和改进你做出的预测的性质。

下一步是审查与“自行车商店”项目相关的伦理和 CSR 问题。现在，时间和金钱都很紧张，所以你们对在这个问题上应该做多少有不同的看法，但你记得在某个数据保护培训手册中读到以下内容：

在处理类型，特别是使用新技术，并考虑到处理的性质、范围、背景和目的的情况下，可能会对自然人的权利和自由造成高风险，控制者应在处理之前，对预期处理操作对个人数据保护的影响进行评估。单个评估可以针对一组具有相似高风险的类似处理操作。

机器学习技术可能不会被技术人员视为新，但在这个项目进行的时候，它们对绝大多数普通人来说都是新的。那么问题是关于风险的：这是否是一个对受试者来说高风险的项目？再次，你查阅了 ICO 的网站，并注意到了可能表明该项目具有高风险的因素列表：

• 评估或评分 ✓

• 具有法律或类似重大影响的自动化决策

• 系统性监控 ✓

• 敏感数据或高度个人性质的数据

• 大规模处理数据 ✓

• 匹配或合并数据集 ✓

• 与易受伤害的数据主体相关的数据

• 创新使用或应用新的技术或组织解决方案 ✓

• 阻止数据主体行使权利或使用服务或合同

你检查了这些项目；很明显，你将评估和评分客户，以查看他们是否可能停止在自行车店购买。但意图并不是用这个来做出自动化决策，而是将信息传递给那些将在自己的研究中使用它的人。你所做的是系统的。所有客户都可能被检查，但数据不是个人的；毕竟，拥有自行车不像拥有宗教。

你认为这将需要大规模处理，因为客户有数百万。主体可能很脆弱，但你所做的不与他们脆弱性相关。技术是创新的，但你并没有计划阻止人们做任何事情或使用自行车店的设施。

可能值得创建一个数据保护影响评估（DPIA），这是一种了解项目中使用数据可能如何影响个人的方法。英国信息专员办公室建议完成一个 DPIA，以帮助你和团队了解你们使用这些数据所承担的风险 [1]。

首先，你考虑数据的性质、范围、背景和目的，你发现这些数据正在用于内部流程。它仍然在自行车店的掌控之下。数据的保留和安全不会改变。主要问题是这是新颖的处理方式：在范围上，这是购买行为记录与客户人口信息之间的对比。背景是这些客户拥有银行账户或信用卡，所以他们不是儿童，他们的目的是合法的。自行车店的业务是卖自行车，这也是为什么客户与公司有关系的理由。然而，客户是否知道他们的数据可能会被用于这种模型？他们是否同意了这一点？

你调查了可能对个人产生风险的风险清单（例如，无法行使权利、受限访问服务、失去控制等），并确定唯一的潜在挑战可能是可能的经济损失，因为从数据中做出的决策可能会被用来创建包括一些客户但排除其他人的特别优惠。你写下了你的初步评估，并记录了三个结论：

• 存在风险，客户可能没有允许使用迄今为止收集的数据以这种方式。

• 结论不应用于创建独家优惠。

• 当项目更加成熟时，你必须重新审视你最初的 DPIA。

在这个阶段，出现了一段停顿。在获取工作的过程中，必须对 RFI 的反馈进行回应，因此你被要求写几段话用于回应文档，你照做了。在你等待公司对提案进行审核的过程中，你转而去做一些之前积压的工作。但这并没有持续太久。

几周后，你被召集参加一个会议，被告知自行车店希望你的组织正式提出一个迁移和数据价值的提案。（显然，目前没有其他投标者，你的贡献确实激发了自行车店管理层加速他们的计划并推进项目的热情。）现在需要的是更具体地说明可以做什么，以及起草正式工作提案所需的材料。你被分配到投标团队，负责这项工作。

由于现在你和自行车店之间有保密协议和保密协议，你可以做的事情在某种程度上有所变化。他们承诺让这个项目启动并运行。你现在和你的团队面临的问题是，如果承担这个项目，谁会参与其中，以及这项工作在高级别上包括哪些内容？在过去，你曾与组织中的一些有才华的数据科学家和机器学习工程师合作，所以你查阅了内部网络上的任务数据库，发现其中之一，罗布，目前处于待命状态。你前往投标响应经理那里，询问是否可以预订一些罗布的时间来制定资源和项目计划，并且得到了同意。

你向罗布介绍了项目，并回顾了到目前为止获得的信息。使用本书中的模板，你指定了一个涵盖以下内容的计划：

• 第 0 个冲刺阶段，让项目启动并运行。这在规模和范围上都很明确，并且与项目相似，所以你同意这些任务需要三个人工作两周，可能是罗布、一个基础设施工程师和你自己。

• 第 1 个冲刺阶段，构建数据管道并详细探索数据集。

• 第 2 个冲刺阶段，构建模型，评估和选择建模方法，并完成最终模型以供使用。

• 第 3 个冲刺阶段，将模型集成到应用程序中。

罗布明确表示，在更具体地说明建模可以做什么以及数据准备和建模阶段需要多长时间之前，你需要先更好地了解数据。你联系卡拉玛，问她在你准备投标的时候，是否可以从 opdis2 中提取一些数据，这些数据展示了库存水平和客户历史记录的存储方式。结果证明，由于自行车店对项目充满热情，卡拉玛非常乐意安排这项工作。显然，客户信息将被匿名化。

同时，你和 Rob 请求 Karima 安排与制造和零售服务潜在用户的会议，以了解模型结果将如何被消费。Karima 已经确定，模型将为用户提供仪表板信息，在会议上，你提出了一些关于哪种仪表板会有用的概念性想法。制造团队遵循工程典型要求，要求表格数据带有电子表格下载，而零售服务团队希望数据“更容易理解”。

当数据样本到达时，情况比你和 Rob 希望的更为复杂。看起来数据存储在许多表中，记录着不同类型的交易，而要了解特定一天库存或客户的状态，需要大量的数据处理和操作。此外，数据库中大约有 3000 万行数据，代表着五年的商业交易，由两个来源创建。两年前，一个旨在解决交易管理系统数据质量问题的项目已完成，这意味着有一个包含三年噪声数据的遗留数据存储库和一个包含最后两年记录的干净数据源。

在系统架构方面，这似乎将是一个绿色领域的云服务项目。在 Rob 的帮助下，你可以指定开发/测试/生产设置，并将其提交给投标团队的云工程师进行审查。一旦完成，你和 Rob 就拥有了完成估算和顶层计划所需的一切。Rob 建议邀请他之前合作过的一些人，为任务进行 T 恤尺码会议。

通过解决第 4、5、6 和 7 章的待办事项，估算出五人团队加上你自己大约需要 10 周时间来完成项目，如之前商定的，有两个星期的冲刺 0。团队同意，到目前为止你从流程中识别出的风险在资源方面不是实质性的，但指出数据权限问题仍然存在。

你安排与 Karima 会面，讨论项目风险，并简要介绍需要限制系统使用的排他性。你还提到，如果数据权限问题得不到解决，可能会导致系统无法使用。鉴于对数据可能状态的研究发现，你为工作说明书中添加了一个子项目：

挑战 5：我们将验证 2-5 年前的数据在创建收入和流失模型时是否足够高质量，并将量化这些数据质量对从可用数据中提取的模型排名和有用性的影响。

在投标中涵盖此项目的工包中，记录了挑战，以及之前提到的假设和数据使用相关的假设：

假设 6：你需要有适当的权限来使用自行车店提供的数据。

描述的最后一部分是 Rob 和你与团队为估算所创造的工作。在法律协议中，这项工作被注明为在发现过程中可能发生变化。

与销售前期团队进行了审查，并将项目评估为低风险、高灵活性，因此，没有在项目估算中添加明确的应急计划。所有协议文件都由法律顾问准备，并举行会议来审查和完成销售前期清单。会议产生了几个小行动，在所有这些行动都关闭后，文件被发送到自行车店的授权官员以及你所属的咨询/交付组织。文件被签署，销售已经完成。现在项目必须执行。

3.6 项目前期后续

这是一个胜利！自行车店的销售已经完成，投标团队正在庆祝。这是一个愉快的故事，但项目前期的活动可能是一个对抗性的过程；你与其他团队和其他人一起使用不同的技术和方法。在商业世界中，你的项目也要与其他众多项目竞争。可能是因为正在缩小行政团队规模的转型计划今年需要更多的资金。可能是因为你提高服务生产力的机器学习项目并不像吸引网站更多关注的机器学习项目那样被视为重要。在咨询领域，也存在明显的商业竞争。其他公司可能比你能提供更低的价格或更快的交付。

有时候，你的组织可能真的需要这个项目，出于财务或组织（政治）原因。你的管理者或销售团队可能已经投入了大量的努力，让你达到可以提出和讨论项目的阶段。这意味着在项目前期阶段有很大的压力要取得成功，甚至可能根本不进行，直接交付结果。

显然，你和你的团队应该力争赢得尽可能多的工作。毕竟，这是支付账单的方式，你的工作是承担和交付项目。事实上，赢得错误类型的工作可能会产生灾难性的影响：耗尽你的团队，损害你的声誉，等等。一个注定要失败的项目所投入的团队成本是巨大的。如果你处于可以拒绝一个你认为将会失败的项目的情况，拒绝并让客户将钱花在其他地方是道德的，这也可能符合你自己的最大利益。海里还有其他鱼；你不会耗尽你的团队或声誉，而且客户将来可能会带着更好的想法回来。

本章概述的过程之一是为了在特定价格和特定时间内进行机器学习项目建立一个坚实和事实性的案例。这可能导致您的组织放弃一个项目，或者您的团队获得一个对客户来说现实且有价值的项目。不幸的是，这也可能导致您的报价被客户拒绝，转而选择竞争对手。这是一种更难以接受的失败，有时会对您和团队带来真正的负面影响。好事是，当您被问及为什么会发生这种情况时，您将会有证据证明您正在做正确的事情，并且还有可以长期学习的材料。然而，退一步想，重新审视并认识到每个故事都有两面性是值得的。也许客户是对的；也许您不是与他们合作的正确团队。如果客户错了，那么他们这次做出了错误的决定。不用担心。在您的竞争对手无法解决问题后，他们会回来的。

摘要

• 为了制定一个项目提案，需求需要转化为一个假设，明确预期的结果和关键挑战。

• 然后，可以根据假设以及您在第二章中收集到的交付环境信息进行结构化的估算过程。

• 一个有用的估算需要考虑团队的结构以及满足需求所需的承诺。

• 在向客户提及成本之前，确保您的项目文档得到适当的审查和批准。

• 如果项目前期阶段失败，那么项目肯定也会失败，这要糟糕得多。

4 开始

本章涵盖：

• 在合作开始时关注准备

• 获取所有必需的访问权限和许可

• 降低项目风险

• 验证开发环境并在必要时实施缓解措施

第三章中介绍的第 0 阶段（sprint 0）的目的是将所有事情都设置好并准备好，以便项目团队可以在第一天进入并开始工作。在理想的世界里，这个阶段充当了一个缓冲区，介于尚未开始的项目和正在运行且花费大量资金的项目之间。这是一个在大量现金被浪费之前发现严重问题的机会，也是可以投入精力来提高交付团队生产力的时间。

在第 0 阶段，您将正式为客户的项目工作。这意味着您将“进入帐篷”并允许访问和您在项目前期过程中没有的信息。由于这种差异，第 0 阶段允许您有足够的时间提出访问、信息和账户的请求，并在项目团队无所事事、翻弄手指、等待之前解决这些问题。这也为您作为项目经理提供了时间来同意并传达项目的工作流程，并加深您对前方风险和挑战的理解。最后，第 0 阶段还允许您进一步检查项目是否可行，以及您的估计是否仍然有效。

4.1 第 0 阶段待办事项

与项目前期阶段一样，第 0 阶段的待办事项列表列出了需要完成此项目阶段（表 4.1）的任务或票据。同样，与项目前期任务一样，这些任务需要根据您面临的项目现实情况进行分解和进一步发展。

表 4.1 开始阶段的待办事项

任务编号	项目
设置 1	创建、沟通并最终确定团队设计和资源分配。
设置 2	确定并共享一种工作方式：  ▪ 项目脉搏（项目日常运行的方式）  ▪ 工作标准和最佳实践确定并共享一组常用工具。创建、确定并共享沟通计划。创建并共享文档计划。
设置 3	建立并共享基础设施计划。
设置 4	执行项目前期数据调查。
设置 5	审查项目 CSR 和伦理。建立并共享隐私、安全和数据处理计划。
设置 6	建立并共享项目路线图。

从销售前期的一个重要变化是，现在您需要使用客户的基础设施来设置流程和交互，以交付您的机器学习项目。您需要将您的工作实践与他们的工作实践相结合。第 0 阶段实现了这三件事：

• 您的团队已经准备就绪，拥有明确的议程和所有完成工作所需的工作系统。

• 您和您的团队现在已成为客户组织的一部分。

• 你已经掌握了项目的数据资源，并已验证你在项目前期对数据的描述是正确的。

4.2 最终确定团队设计和资源配置

项目团队是交付的引擎。没有合适的人员，所需的工作就无法完成。因为团队设计和资源配置是其中最重要的活动之一，在冲刺 0 阶段，确保将合适的人员分配到项目中。

团队设计票据：设置 1

• 创建、沟通并最终确定团队设计和资源配置。

在项目前期阶段，你创建了一个团队设计，以便你能对成本进行估算。作为该过程的一部分，你检查了团队所需的人员是否可用。你很可能使用了一些资源预留和分配系统来记录项目所需的人员。如果团队已被预留，那么现在剩下的基本上就是“按按钮”并开始为顾客项目组建团队。

不幸的是，有几件事情可能会出错。潜在的团队成员可能被其他项目吸引，他们可能已经离开公司，或者他们只是生病了。你可能需要找到一个替代者，或者你可能需要重新设计团队，因为你在前期工作和估算中用来构建团队的关键石已经不再存在。

如果你的团队设计和资源配置计划已经脱轨，那么请在风险登记册上记录。一个不充分的团队是一个需要处理的红灯。现在项目已经获得资金，在大多数情况下，快速内部升级将解决问题，要么是确保最初确定的资源，要么是寻找替代方案。

如果没有足够的资源来支持原始工作，那么一种替代的缓解措施是重新规划工作。而不是根据你的口袋裁剪布料，你必须调整你的口袋以获得不同的布料！重新规划有时意味着在项目不同阶段有适当的资源来满足需求。另一种缓解措施是交付组织（你的公司）安排外部承包商填补空缺。这很昂贵，可能会损害或破坏进行项目的商业案例，但这对你的组织来说可能更可取，以保护与客户的合作关系。

4.3 一种工作方式

假设项目团队已经确定，下一步是开始与客户一起开发和达成一致的项目工作流程。工作流程是大家一致认为完成任务所需的活动的集合。

工作实践票据：设置 2

• 就一种工作方式达成一致并共享：

  • 项目脉搏（项目日常运行的方式）

  • 工作标准和最佳实践

• 就一套共同工具达成一致。

• 创建、达成一致并共享沟通计划。

• 创建并共享文档计划。

4.3.1 流程和结构

清晰地说明项目将如何运作，以及活动将如何被组织和达成一致。这不仅对于团队和您了解期望内容至关重要，而且对于将质量融入项目也是基础性的。如果团队采用对他们有效的工作实践，那么他们和您都能得到更好的结果。

关于如何运行（或定义）敏捷项目的文献资料非常丰富[14] [4] [15]。您会发现不同的流派和派别要求特定的实践和行为：敏捷团队在冲刺中工作，看板团队进行持续交付，等等。偏离 Scrum、DevOps、看板或其他任何形式的敏捷实践可能会被视为异端。尽管有很多关于项目应该如何运作的强烈观点，但实际上几乎没有证据支持只有一种方式可以每天和每周运行项目。明确的是，不同的团队发现不同的实践对他们有效，而且这些有效的方法会随着时间和环境的变化而变化。

不幸的是，不同的组织随着管理潮流的起伏而强制实施不同的实践。如果您的组织规定了某种工作方式，如 SAFe [15]，那么您需要找到一种方法来遵守规定的实践。如果您有灵活性，并且已经找到了对您的团队和客户都有效的工作方式，那么请使用它！尽管如此，有四件事情必须明确：

• 将要使用的流程和结构。

• 采用的工具。

• 团队所需遵循的标准和工作实践。

• 一切将如何被记录。

基于冲刺的项目基于敏捷的 Scrum 方法，这种组织项目的方式目前很受欢迎。基于冲刺的结构融入了本书中，这使得叙事得以发展。

敏捷项目的现实意味着任务将从一次冲刺溢出到下一次，项目团队将发现推动项目前进所需的额外工作和活动。例如，在一个具有新颖硬件的项目中，您可能需要进行关于相机或传感器性能的详细实验，以了解它们产生的数据。另一个例子是当团队必须使用特定的开发平台，并需要将大量代码移植到其中以开始工作。通过适应项目演变中的工作计划来承认和适应这些发现是敏捷方法的核心。

基于冲刺的敏捷方法允许设定里程碑并定期进行审查以监控进度。在每个冲刺结束时，需要做出决定，关于接下来需要做什么（或不做什么）。团队现在可以了解并控制未来几周的项目，并可以制定如何管理他们的工作负载和承诺的计划。然而，这种项目结构并不是运行敏捷项目的唯一方式。

�看板项目以一个不断演变的单一计划运行；任务随着出现而添加到项目中，团队不断更新和重新排序任务列表，以尽可能高效和快速地推进项目。一些团队通过使用这种方法来紧密协调他们的工作而蓬勃发展，并且这种方法似乎在团队深刻理解领域和项目的地方效果良好。当需要产品所有者和领域专家的系统输入时，以冲刺为导向的项目节奏会更加结构化。

4.3.2 心跳和沟通计划

作为项目负责人，你的角色之一就是充当一个人类信息转换器：收集需要传达给团队的信息，一次性地传达出去，然后收集团队的信息并处理以采取一系列行动。你需要定义如何实现这一点，并从所有相关方获得同意：你的经理、客户和团队。

尽管人们经常抱怨他们从流程中获得的信息没有他们希望的多，但他们发现项目中的信息共享节奏是令人放心的。每个人都应该知道他们应该如何分享和接收信息。有两种沟通方式：

• 举行会议

• 分发文档和报告

在项目中（即使是不合理的）常见的抱怨是我们不知道发生了什么。制定一个计划并承诺执行可以消除抱怨和不满的机会。相反，关于会议太多的抱怨在一定程度上可以通过计划的存在来管理；你可以用这个来解释为什么会有这么多会议，以及为什么一开始大家都认为这是一个好主意。当然，这两种类型的抱怨可能都有实质内容，所以请小心。要开放接受信息共享的数量可能已经变得没有意义或过于详细且不相关。

有时候你会发现你和你的团队被拖入多个“其他”会议和跟进会议。这可能很难管理，但这是你需要意识到的。对于团队工程师来说，一天一次的项目会议是足够的。一些工程师可能会对即使一次会议的负担感到不满，但现实是，他们需要检查进度，长时间消失的工程师往往会被孤立。如果你不了解发生了什么，就很难对工作承担责任。

一天中安排超过一次的项目会议可能会导致生产力下降，因为没有时间来设置和专注于手头的任务。如果团队和你决定使用基于冲刺的结构来运行项目：

• 与产品负责人、客户的代表或故障排除人员以及你的团队一起举行每日站立会议。

• 与产品负责人进行每周回顾会议。利用这次会议提供关于项目的总体更新，并审查风险登记册。记录这次会议的纪要，包括行动，并将这些行动每周滚动更新。

• 在每个冲刺的开始安排与产品负责人的规划会议。这允许就冲刺的工作分配达成一致。记住，作为一个敏捷/适应性项目，随着项目的进展，工作将会有显著的变化。

• 与团队、关键利益相关者和产品负责人一起举行冲刺结束和签字会议。在这个会议中，展示已完成的工作，并让团队展示新的功能；例如，预览从数据中生成的工作模型或运行数据管道、用户界面等。

• 安排与关键利益相关者和产品负责人进行冲刺回顾会议。在这里，你回顾任何挑战或问题，以便它们可以在冲刺规划会议中解决。

在所有会议中记笔记是个好主意，但有些会议和项目的其他方面需要记录并作为报告分享。报告是一种文档，但它们在排名上有特殊性，因为它们旨在确保项目状态被理解。

如前所述，应在每周回顾会议中记录会议纪要，并将其分发给参与者。进行这两项活动可以创建一个关于事情进展状况的报告。对于冲刺结束和规划会议，你的笔记需要转化为一致的行动，并为下一个冲刺的任务板提供信息。一个关键的报告机制是风险登记册。你可以使用它来维护一个协议，即存在未解决的问题，或者对于已经解决的问题有进展。

无论你选择哪种模式，你都需要安排会议。这使参与者意识到有一个定期安排的承诺，并让他们为此做准备。在参与者的日历中安排时间可能很困难，但这样做对于项目的顺利运行至关重要。

你定义的会议和沟通模式是项目的脉搏。迭代运行这些序列推动项目前进，或者在不太乐观的情况下，它们会告诉你和你的赞助者事情并不顺利。在任何情况下，这种常规都能让你收集信息和证据，这些信息和证据表明你和团队正在朝着项目目标努力。然而，为了高效有效地实现这些目标，项目需要建立许多工具和实践。让我们从工具开始。

4.3.3 工具

与所有团队成员和客户就首选工具达成明确协议。通常，项目的客户会强制要求这些工具。以下列出了一些这些工具：

• 文档存储库（SharePoint、Confluence、Microsoft Teams 等）

• 工作票系统（Jira、GitLab、Azure DevOps Services）

• 源代码控制（GitHub、Bitbucket、Subversion）

• 文档制作（Microsoft Office 365、Google Docs、Open Office）

• 技术图表制作（Visio、Lucidchart）

• 构建管理系统（Gradle、Jenkins）

• 依赖关系管理系统（Conda、Python 的 pip）

• 测试（Python 的 pytest、JUnit）

有时使用错误的工具可能意味着工作必须重写才能被客户接受，有时使用错误的工具将违反合同。这可能会导致后续更大的问题。提前明确这一点是值得的，因为机器学习项目需要自己的工具。在撰写本文时，这是一个新兴领域，但很明显，通过标准化支持机器学习开发项目中一些痛点的工具可以获得显著的收益。

数据管道

现代数据库反映了它们所支持的复杂和动态组织。数据科学和 AI 项目要求许多这些资源以临时方式统一，以创建覆盖问题区域的有用数据表示。关系数据库在数据科学和 AI 项目中仍然非常有价值且被广泛使用，但越来越多地，需要适应并使用来自传感器或自然语言的无结构数据。

支持 AI 项目可能需要大量数据资源，这些资源可能会（并且通常确实）频繁变化。这种需求没有得到 ETL 工具的良好支持，这些工具旨在支持提供关系型数据仓库的数据集成项目。Beauchemin [3] 识别了这些驱动因素，并阐述了采用数据管道实现更灵活和开放数据基础设施的必要性。

数据管道是由工作流引擎和调度器管理的转换序列。工作流引擎通过一个简单的程序将一系列任务链接在一起；具体来说，没有循环。技术上，这被称为 DAG（有向无环图）。

图 4.1 展示了 ELT 任务的示例 DAG。DAG 上的每个步骤都是一个在目标机器上执行的脚本，处理数据存储或虚拟机上的数据。整个 DAG 在工作流引擎中指定，该引擎按顺序调用每个步骤。在这种情况下，表 X 从系统 A 加载，表 Y 从系统 B 加载。执行了连接操作，然后运行一个清理步骤以删除空值。这些步骤中的每一个都可能有不同的内部步骤，并且每个都可以独立运行另一个工作流。图中的虚线箭头显示了第一个步骤可能执行的动作。

图 4.1 一个示例 DAG：它是定向的（D），因为信息沿着箭头单向流动。它是无环的（A），因为没有循环，它是一个图（G），因为这就是这类事物被称呼的原因。

许多编程语言被用于此类脚本活动，但管道引擎的理念是抽象管理这些活动以及将它们连接在一起的复杂性。这种技术与 Hadoop 实现一起以 Oozie 调度器[1]的形式出现，它使得管理存储在 Hadoop 集群中的大数据资源变得更加容易。

在 2015 年，Airbnb[1]需要一个支持在多种技术堆栈上集成和管理各种复杂数据管道的解决方案。Airbnb 的项目后来发展成为 Apache Airflow。像 Oozie 和 Airflow 这样的管道工具提供了一种抽象，描述了对数据资产所需进行的操作，而一个引擎允许执行和管理创建来完成这些操作所需的代码。

使用这种技术的庞大且复杂的数据流库正在迅速变得可用，对于 AI 团队来说，实现数十个定义数据导入和准备、模型训练、模型评估和生产的流程是很常见的。没有这些工具，这类工作容易出错、难以管理，并且非常耗时。有了像 Airflow 这样的工具，流程就变得容易检查和良好管理，而且之前困扰数据项目的许多记账和脚本管理现在都外包给了引擎。

版本控制

机器学习项目不仅产生和依赖代码，还产生许多其他资产。它们产生不同的模型，经过调整和优化以提高性能的某个方面。机器学习项目还依赖于特定的训练、验证和测试集。除了训练集之外，机器学习项目还使用复杂的管道来整合不同的数据，并产生学习算法处理的特征。

幸运的是，现在有大量的专用版本控制系统可供存储和管理这些事物。这包括 DVC、MLflow 和 Weights & Biases 等工具。此外，像 Amazon Web Services (AWS)上的 SageMaker 这样的 ML 开发系统已经集成了我们可以使用的版本控制组件，以及像 Apache Iceberg 和 Project Nessie 这样的最新版本文件系统，它们允许有效地识别和版本化数据集。

团队可以在没有专用基础设施和工具的情况下跟踪模型版本和其他工件。但请注意，这迅速变成了一项巨大的管理负担，并可能导致复杂和令人沮丧的配置错误。在最坏的情况下，由于项目推送过程中的某些配方组件丢失，您的团队可能无法重现他们开发的“良好”模型的特性。这至多令人尴尬，在最坏的情况下，会腐蚀客户/用户对您和模型的信任。能够对团队工件进行版本控制，可以支持 ML 项目成功的重要因素。

第一个优点是可重现性。能够精确地定义进入模型的组件，就可以重新创建它。仅仅拥有模型的二进制文件是不够的，因为你可能需要在不同的计算基础设施上重新创建它，或者某些组件可能出现问题。在这种情况下，仅用那个替换部分重新创建模型，可以让你检查之前所做的是否有效，或者你确实遇到了问题。

能够跟踪进入模型的所有工件的第二大优点是，它允许模型从环境到环境进行测试和发布。模型依赖于其他组件，而这个依赖图需要与二进制文件一起移动。

数据测试

我们可以通过使用数据管道技术来改进项目数据基础设施的管理。这是因为使用的过程可以明确且容易地监控。失败的管道会被清楚地识别，并可以采取补救措施。在最基本的概念形式中，失败意味着管道中的错误导致某个作业没有运行——发生了程序性故障。然而，拥有数据基础设施，就创造了运行测试以评估管道中是否存在数据故障的机会。通过设置和运行数据测试，团队可以确保流入模型开发和生产环境的数据资产的质量和属性。

数据错误可能源于收集过程中的问题（如传感器故障、调查执行不当、数据录入质量差等），也可能源于中介传感器的数据基础设施。您的系统将这些错误描述为产生“不良数据”的错误和数据管理错误[7]。

布雷克[6]建议了一系列与机器学习模型开发相关的数据测试，包括测试分布是否符合预期以及确定排除的项目是否被排除。此外，布雷克还建议进行测试，以确定所有特征是否由管道代码正确地从源数据构建。还提出了对数据进行系统级测试（例如，测试项目类别之间的不变性或因果关系是否成立）。请注意，始终应该只有一个厨师负责一锅特定的汤。

在开发基础设施方面，几个项目试图展示这一点[10]，但由于在大规模和快速数据源上进行数据测试的计算成本，出现了具体问题。甚至从大量数据源中选择代表性示例都可能带来显著的开销，这会影响数据基础设施的性能和项目的成本。将基于集群的处理器（如 Spark 或 Kubernetes）集成到数据管道中以进行大规模测试可能是有效的，但需要考虑和相当多的工程来实现这一点。从计算成本和碳的角度来看，这也是昂贵的。

在项目中进行这个决定的时候，你需要决定你的政策将如何涉及这些工具。它们是否会涵盖你团队需求的各个方面？它们是否会成为团队表现的拖累而不是刺激？数据基础设施和建模过程的复杂性，以及你所工作的组织和领域的成熟度，在决策中起着重要作用。一个将成为战略商业活动基础的项目值得在基础设施上投入大量资金。如果你正在进行价值证明或快速启动项目，你可能更适合建立一个轻量级的系统。

4.3.4 标准和惯例

除了了解团队将如何行动之外，了解他们如何行动也很重要。作为领导者，确保团队的行为得当是你能做的事情中最重要的事情之一。不同的团队以不同的方式工作，因此了解你团队的需求是很重要的。以下实践可以作为创建顺畅和积极团队动态的一般指南：目标是创造一个团队精神，让每个人的见解和想法都得到体现，每个人都感觉像是在作为工程师做出贡献和成长。

• 尊重和礼貌是基本准则。一旦失去这些，人们开始自我审查并停止披露真正发生的事情。评论和建议必须是积极和尊重的。没有人应该打断（如果你这样做，没关系，但请道歉并归还被打断的人的时间）。

  每个人都应该认真倾听他人所说的话。同时，每个人都应该尊重他人的时间，并确保他们说话简洁并紧扣主题。你可以做的最有影响力的事情就是树立榜样。

• 应在项目采用的票务系统中记录和跟踪工作。如果某项工作值得在站立会议中讨论，你应该记录并创建票务。在这种类型的会议中，每个人都应该有一些工作可以讨论。

• 工作或票务应产生可识别的结果。文档、代码或其他工件（模型、功能、数据集、测试结果等）可以存档在文档存储库中。然后可以将其推送到版本控制系统，并由适当的团队成员进行审查。

• 工作应进行同行评审。如果一个团队成员（或几个团队成员）接受了一个任务，那么在另一个团队成员对其进行评审之前，不应将其视为已关闭。这促进了知识在两个方向上的流动：如果资深工程师完成了一个任务，而初级工程师对其进行评审，这为从资深贡献者的工作实践中学习提供了机会。如果情况相反，那么资深工程师就有机会为初级团队成员提供指导和支持。近似同行评审还允许技术知识在项目团队中流动。

标准和惯例也适用于客户。关于客户和交付价值的工作方式设定，重要的是就以下内容达成一致：

• 当某项工作完成时签字意味着什么。良好的做法是在项目会议中宣布可交付成果已审查，并发送给产品负责人（客户可能希望指定是其他人）。如果没有提出问题，例如在五天内，这些可交付成果就被视为已签字。

• 客户支持项目的责任包括什么。例如，这可能意味着产品负责人和联系人参加会议并可供讨论。

所有团队都应该经历同意他们工作方式的过程。显然，如果你看到某个团队设定低标准或创建不良惯例，你会遇到问题。在这种情况下，你必须制定一个基本框架并强制执行。你可以通过以身作则，展示你希望从团队中得到的那些行为来影响结果，但在大多数情况下，提问（而不是强加你的答案）并观察结果对他们来说可能具有强大的塑造作用。

看到经验丰富的专业人士在关于人们应该如何一起工作的问题上展现的推理深度和洞察力，常常给人留下深刻印象。重要的是，做出决定的团队强烈地希望坚持他们的决定，并且很可能会在几乎没有提示的情况下吸纳和指导新成员。无论你得出什么结论和协议，都要记录下来，并在尽可能的情况下坚持它。

4.3.5 文档

长期以来，一些软件开发者已经不再重视文档。敏捷宣言指出：“工作软件[比]全面的文档更有价值。”这一格言通常被视为无需文档的许可，尽管敏捷宣言明确指出，其作者也认为全面的文档和可工作软件同样有价值[4]。近年来，一个常见的观点是代码应该是自我文档化的，并且运行中的代码在项目进度中优于其他任何证据。

“代码高于文档”的见解有很多可说的。软件团队应专注于让代码运行的想法是基于人们在软件开发中积累的几年经验的一些学习。例如，让一些代码工作是一个强有力的进度和价值指标。专注于代码和功能的另一个优点是它迫使进行详细思考，这可以揭示设计师思维中的空白。设计不工作通常是因为所需的代码无法编写，或者更常见的是，设计遗漏了大量细节。

最近，一个更全面的观点变得越来越普遍。软件项目（包括机器学习项目）的目的是交付一个运行良好且完全维护的系统。没有文档，没有人会知道如何使用该系统，更不用说如何修复它。

尽管随着时间的推移，技术人员可以理解代码，但业务方面不知道如何开始找到正确的技术人员去查看正确的位置，而且可能没有时间去做。本质上，糟糕或缺失的文档是系统杀手。开发者们也已经意识到，文档在推进日常工作中是一个巨大的资产。对他们来说，能够依赖团队产生的文档是有帮助的。如今，指出六周前需要文档来理解你所做事情的人将是你自己，已经成为一种陈词滥调。总的来说，有两种类型的文档：

• 开发者在执行待办事项时产生的排气轨迹。

• 更新客户进度或本身构成可交付成果的正式文件。

在关于工作轨迹方面，重要的是团队需要记录每个任务并将文件存入仓库，但这些文件并不是正式交付给客户。相反，这份工作记录为团队和未来的团队提供了理解系统和其演变所需的信息。团队工作笔记的另一个功能是，它们是团队活动和进展的证明，可以用来说服利益相关者团队的勤奋和努力。此外，如果要求另一位高级工程师审计项目，那么拥有大量技术笔记和工作文件的仓库是让他们相信团队没有闲着的绝佳方式。每个任务都应该作为常规进行记录，技术笔记应保留并供所有团队成员使用。

在正式文件方面，必须有文档交付成果来总结和向客户和高级管理层呈现信息以供审查。如果你愿意，这些文档的谨慎行为。这些文档就项目的进度达成一致，并作为团队思考和理解特定主题或活动的焦点。计划是开发文档交付成果并与客户沟通。例如，对于一个典型的机器学习项目，以下文档可以交付：

• 文档计划

• 沟通计划

• 数据故事

• 隐私和安全计划

• 基础设施计划

• 技术架构

• 路线图

• Sprint 0 报告

• 数据调查

• 伦理报告

• 业务问题分析

• 数据测试计划

• EDA 报告

• Sprint 1 报告

• 模型设计

• 特征工程报告

• 模型开发报告

• 模型评估报告

• Sprint 2 报告

• 应用设计

• 用户界面设计

• 记录和监控方法

• 实施报告

• 测试报告

• 最终项目报告

可选，你可能需要单独制作 Sprint 3 报告，并将准备最终项目报告的任务分离出来，这取决于谁将批准项目的不同部分。一些客户有利益相关者，他们可能会同意项目部分或 Sprint 的完成，但希望有更高级别的人来审查并拥有整个项目。无论你具体客户的哪些要求，在 Sprint 0 期间，你可以确保你开发的文档计划得到他们的批准，并明确说明将向谁以及何时交付什么内容。在确立了你的工作方式后，现在是时候专注于你实际上将要与之合作的内容了！

4.4 基础设施计划

本节涵盖了你需要设置的系统，以允许你的团队工作。在这里，我们了解了团队将要构建的必要基础设施。

基础设施票据：设置 3

• 构建并共享基础设施计划。

机器学习项目与标准企业数据架构的数据架构要求有很大不同。在企业的数据架构和基础设施上运行机器学习系统有时会对其他应用程序产生不可接受的影响。然而，您可能有限或没有选择，因此需要一种务实的架构设计和开发方法。

4.4.1 系统访问

从项目前期的工作中，您对数据的位置有了一定的了解，因此现在有两个步骤要采取：首先，质疑并确认信息，其次，达到您有权访问一组技术接口（API、SQL 查询、文件名等）的程度。可能的情况是，这些信息无法从您交谈的人那里获得，或者您被告知数据位于特定的数据库中。您需要迅速解决关于系统访问的任何不明确之处，因为缺乏对数据资源的适当访问可能会几乎停止项目上的技术活动，直到问题解决。

立即开始讨论，明确获取数据所需访问权限和权限。当您拥有这些信息时，开始授予访问权限的过程。请记住，团队不仅需要申请访问权限，他们可能还需要进行一些培训，以便有资格或获得认证来处理数据。这可能需要每个团队成员 2 到 8 小时来完成，但确定和安排培训以使团队能够加入客户的基础设施是一个优先事项。这是那种真正值得提出所有显而易见或愚蠢的问题的时候，因为其中之一可能揭示出对团队生产力的关键阻碍。

在某些情况下，用于托管数据的环镜访问可能仅限于具有特定构建的特定笔记本电脑，这阻止（或限制）了数据流出。在这种情况下，为团队安排访问笔记本电脑或能够使他们连接到数据服务器的办公空间。

安排这些权限、培训和访问所需系统通常比预期花费的时间更长，因为处理这些问题的流程往往优先级低且资金不足。有时，执行这一过程没有现成的流程，或者这是第一次执行。教训是，这一步骤处理得越快、越有活力，项目团队就会越顺利。

4.4.2 技术基础设施评估

在第二章中，我们分享了项目使用的开发/测试/生产环境规范。这应该是在关于客户环境的最佳可用信息的基础上完成的。在大多数情况下，项目前期参与涉及客户的技术和安全架构师，以及对可用资源的准确了解。

不幸的是，当你询问时，可能会发现原本希望使用的资源根本不存在。可能是销售前团队未能从客户那里获得适当的技术专业知识，或者技术环境是工作说明书中的一项风险项目。也可能是假设的基础设施因为错误或误解而根本不可用。比如说，假设项目开始时，会有一个用于生产的 GPU 服务器。通过提问，你可能会很快发现，实际上，GPU 服务器正在订购中，但九个月后才会交付并投入使用！

如果在这个阶段发现了这类问题，那么你必须富有创意地思考，并与团队一起制定解决方案，或者客户需要更改基础设施配置，或者项目应该被取消。这就是你可以重新协商项目范围的地方：是否有其他方法或可行的应用不需要 GPU？尽快获取承诺的基础设施细节和你的风险登记册上可用的基础设施，并开始处理所需的缓解措施和范围变更。确保客户在发现差异后立即予以确认。

在请求访问和提供这些请求的过程的另一边，关于团队将使用的基础设施有确定性。把它写下来并记录下来！

4.5 数据故事

再次强调，数据，数据，数据。这是在 Sprint 0 的正常软件项目中你将关注的重点与 ML 项目需要做的事情之间的重要区别。设置 4 个任务要求你进行另一项数据调查。但，为什么现在？

数据故事票据：设置 4

• 执行项目前的数据调查。

在项目前的过程中，我们提到了在项目销售前阶段获取数据样本的重要性，我们也指出了确定数据使用是否道德和合法的重要性。Sprint 0 是进行付费工作的第一次机会（受商业协议保护并授权），旨在了解客户数据。现代统计学的发明者罗纳德·费希尔是一个有点奇怪的人，但显然，他说：

实验完成后咨询统计学家通常只是要求他进行尸检。他或许可以说出实验失败的原因。

—— R.A. Fisher，1938 年向第一届印度统计学会的总统演讲

这在这里有几个相关的原因。您和您的团队被要求构建客户运营领域的图像，这产生了用于建模的数据。可用的资源定义了您可以制作多好的图像。如果您很幸运，所有的一切都将整洁地排列在一个漂亮的数据表中，供团队工作。更有可能的是，您需要从各种不整洁、不干净的部分组装出建模团队需要的表格，因此您需要深入了解团队面临的问题。随着您通过项目工作，您将需要理解这个过程的几个迭代。

在团队加入之前，在数据访问可用之前，是时候构建一个关于数据的叙事故事了，使用您的时间和项目授权作为主要工具。在冲刺 1 中，您需要从系统的角度创建一个数据调查调查。数据调查确定了哪些数据在哪些资源中，以及如何使其可用。然后，在完成数据调查后，团队将能够进行适当的 EDA，以找出数据集中真正包含的内容。

接下来，模型师们加入进来，进行所有有趣的部分。如果遵循定位和挖掘数据的这个迭代过程，您可以有希望他们不会发现巨大的颠覆性问题，这会阻止项目进行。目前，在没有完全建立技术访问的情况下，降低这种情况发生的风险的最佳方式是开发一个数据故事。

数据故事是客户希望您访问和使用的数据集组成部分的历史。在这个阶段，您得到的将是客户对数据构成及其来源的看法。这通常与技术现实不同。然而，这种观点很重要且有用，因为它阐述了关键事件和驱动因素的企业记忆，这些因素使得数据成为现在的样子。

有现成的框架可供使用，您可以用它来构建关于数据的提问结构。例如，为了理解数据资产，使用 5W1H+R 框架[16]。这是基于记者用来深入故事核心的长期理念；他们询问关于为什么、谁、什么、何时、何地以及如何的问题。此外，5W1H+R 框架引入了询问数据与基础设施中其他数据关系的概念。数据的血统和来源至关重要，因此需要理解和揭露。

完整的 5W1H+R 框架提出了 27 个问题，涵盖了数据治理、集成和合规的各个方面。如果所有 27 个问题的元数据都可用，那么就可以用它来理解资产。很可能您会发现没有预先准备好的数据目录或 MDM 系统或目录是不完整的。为了涵盖这个背景，需要询问的主要问题是：

• 数据是如何被创建的，以及它是打算如何被使用的？

• 谁拥有数据，谁可以授予访问权限？

• 与数据相关的隐私和安全问题有哪些？

• 使用哪些源系统来获取数据集？

• 这些系统中的数据是如何存储的？它是否可以轻松查询？

• 存储的数据类型有哪些（非结构化、表格型、关系型）？

• 数据和系统是什么时候创建的？这些系统的生命周期中发生了哪些重大事件（例如，数据丢失的故障、为业务变更而重新利用、将其他系统聚合到该系统中、重新平台化等）？

• 系统上的数据来源是什么（例如，从传感器收集、由操作员输入、网站日志、手机历史记录、从数据经纪人购买、交易日志等）？

• 数据资产规模有多大？这些系统历史上的数据规模特征是什么？（例如，一个系统可能最初交易量很小，但经过几年扩展到大量交易）？

• 每个组件中的数据质量有何意义？客户是否信任它？

5W1H+R 框架对于提取数据信息很有用，但它主要关注支持数据治理任务。建模以及由此扩展到使用数据用于机器学习会引发更多问题。即便如此，你将使用的数据的故事至少有四种方式会影响你的机器学习模型：

• 动机和背景: 数据收集的原因。

• 收集: 数据收集的机制和所做的测量。

• 数据来源: 将数据带入当前形式和存储状态的过程。

• 事件: 数据发生了什么。

4.5.1 数据收集动机

并不令人惊讶的是，数据收集的目的在决定你可以如何使用它方面起着重要作用。毕竟，当我们还在学校的科学实验室里时，我们被灌输的观念是，我们进行的实验会产生不同的（并且有限的）结果。用火炬照亮地下室楼梯以避免绊倒，与打开灯光看到架子上所有的酒瓶相比，提供的信息大相径庭。拿着火炬的人可能根本没看到任何酒瓶。

对于你将要从事的工作来说，更相关的事实是，作为受控实验研究的一部分收集的数据集与纯粹观察数据集不同，并且从不同动机的数据收集活动中得出有效推论需要不同的方法[2]。根据定义，故意选择变量的分布将与变量的自然分布不同。

考虑收集动机对数据集的影响的一个简单方法是想象蝴蝶收藏的画面。我们通常对任何事物的最罕见案例更感兴趣，并将关于常见案例的数据丢弃（然而，在蝴蝶收藏的情况下，预期稀有物会被过度代表）。此外，蝴蝶收藏者可能没有收集与蝴蝶共生的其他昆虫，也许他们按颜色或大小排列它们。这些参数相当任意。也许所有标本都是在夏季月份收集的，也许记录了收集日期，或者记录了地点——也许没有。

数据收集者的行为与生态学家或昆虫学家不同。企业系统中收集的数据受到类似的偏差影响，这既不是好也不是坏，但它确实影响了可用于模型的信息。这需要被理解和允许。

4.5.2 数据收集机制

数据收集方法产生的影响的一个好例子是总体调查误差的概念，其中样本数据总是略微或在一定程度上与总体或引入了在提问方式或界面设计方式上的偏差不同[13]。已经收集并反复更新的数据（如人员记录或库存）通常由于输入和更新数据的人员使用的界面而存在系统性错误。例如，当数据输入用户从列表中选择一个特定参数时，通常情况下列表上的第一个项目被不成比例地选择。

另一方面，想象一个要求用户提供敏感信息的网站 UI，而你被要求找出该网站用户的构成，但有一部分用户拒绝提供他们的详细信息。这可能是因为这部分用户是均匀分布的。更有可能的是，具有敏感特征的人不太可能回应，因为遗憾的是，在我们的社会中，他们已经学会了透露他们的身份可能会造成损害。关键是，关于网站用户的数据将存在偏差，尽管它代表了愿意回应敏感特征调查的用户！

从传感器捕获的数据存在一系列不同的问题。工程师和物理科学家在特定情境中会仔细考虑并处理这些问题，确保从传感器收集的数据必须是可靠的 [12]。使用校准和严格的安装标准，例如在 NASA 的组装指南 [11] 中报告的标准，来防止传感器错误。尽管如此，网络传感器可能会停止响应或被安装在不正确的位置。在最坏的情况下，传感器可能被正确安装，看起来功能正常，但仍然会提供错误的结果。为了理解数据集中传感器数据，团队需要结合组织内部和实施所需理解系统的过程和检查来获取一个视角。

4.5.3 线索

供分析项目使用的数据集通常与它们报告的问题、日志和传感器读数有几步之遥。数据可能以如此之快和如此之大的规模生成，以至于需要特殊的实时数据库来收集。将这些数据库扩展以长期存储数据或支持分析查询可能既昂贵又复杂。将此类数据镜像到称为数据仓库的更便宜的存储基础设施中是常见的。

在大型组织中，政治、成本限制、法规和一般的不胜任很容易产生许多这些通用数据存储。这会导致一个庞大的拜占庭式数据架构。另一种导致庞大数据架构的力量在于资本主义的行动和机制。大型公司经常被出售、接管或拆分。数据仓库和数据湖作为所有这些金融工程的结果而被收购、继承或镜像。最后，法规可能导致不自然和复杂的数据架构，因为特定数据被分区或镜像以促进和促进竞争。由于这一系列动态，特定表中数据的来源可能不清楚且难以解码。

如果客户实施了数据目录或数据线索系统，如 Alation 或 Collibra，那么查找数据表的线索会容易得多。或者，组织可以利用其数据架构中的元数据管理设施和流程，因此可能有一个主数据模型可供使用，作为理解现有数据来源的路线图。

在撰写本文时，一些关于通过使用数据发现技术自动追踪数据来源的研究正在出现。例如，使用实体相关性的度量，如社交网络分析[9]或嵌入向量相似性[8]。支持并自动化这一过程的工具在它们开发成熟时将非常有帮助。但这类复杂的实践可能需要一段时间才能在所有数据架构中得到实施，因此应尽可能多地收集先前收集的线性信息。如果有一个跟踪组织中数据的电子表格，那也比没有好。

在最坏的情况下，如果架构中没有预先建立的全局数据视图作为工作基础，那么至少需要绘制出你和你团队将工作的那部分。从你的角度来看，重要的是要确定数据集的最终来源。这不仅有助于你深入了解动机和收集问题，而且可以避免同一数据被用于向同一模型或模型集生成多个信号。

用于在数据架构中提升和转移数据以及将其映射到不同格式的流程也必须理解。脚本和管道可以生成被解释为领域特征的数据，但实际上是收集和汇总它的引擎的产物。例如，你可能会发现每 10 分钟收集一次的传感器数据具有时间戳，这些时间戳每六小时应用一次，因为数据从运营数据存储中被拉出并放入数据仓库。这些时间戳的目的是用来检查数据提取是否成功（可能通过计数来检查是否到达了正确的数字），但随后它们在实际数据收集时间被使用。令人惊讶的是，人们在下班回家、上床睡觉或起床时会发生多少错误，而系统在其他时间工作得有多好。（尽管在这个场景中，没有人能解释中午发生了什么。）

深入探究所有构成对数据及其用途看法的假设和神话极为困难。在数据集中，关于某个领域起源和意义的后期揭示改变机器学习项目创建的模型解释和价值并不罕见。完全消除这种情况发生的可能性是不可能的，但通过定位或收集可用的信息，然后质疑关于血统的断言为何值得信赖，可以减少和管理这种风险。

4.5.4 事件

数据存储在多年中可能会遭遇各种灾难。投资不足可能导致存储空间不足，导致数据被丢弃。有时这是系统性地发生的；有时是随机发生的。事故也会发生。一些数据可能由于查询编写不当而丢失，直到无法恢复或硬件故障导致表格随时间损坏，才有人注意到。诸如不良舍入或类型转换等隐秘事件和错误可能会逐渐将噪声引入数据。

数据存储可能需要进行质量改进练习、重构和重新平台化。这些变化可能对数据及其用于表示建模感兴趣的人群的用途没有影响，但这些都可能出错。引入以支持新用例的变化和功能可能伴随着错误或可能需要更新，这会影响数据。数据字段可以从短整数迁移到长整数，或浮点数。有时这会做得很好，但数据并不重要；有时舍入或对存储类型（例如，从 32 位移动到 64 位）的简单修正可能会引入噪声。

理解客户认为定义数据集演变的连锁事件，可以解释团队在创建模型时得到的奇怪和引人注目的结果。这很具挑战性，但全面了解这一图景可以节省大量时间追踪那些令人兴奋但虚幻的模式。现在谨慎和彻底可以防止你的团队以后浪费时间。

你收集的有关数据的资料对于深化和改变你对项目伦理方面的看法也很重要。数据的获取地点和方式会影响你如何处理它：它可能没有说的事情以及它所说的内容。最近在 AI 和 ML 领域关于语言模型行为及其使用伦理的辩论，强烈受到支撑它们的底层数据的来源的影响[5]。收集和记录这些信息，并尽可能考虑这些信息，如果有人质疑你对模型适当使用及其用户安全性的看法，这将非常重要。

4.6 隐私、安全和伦理计划

如前所述，了解数据收集的动机、收集数据的方法、数据源流以及影响存储数据集的事件，有助于形成使用数据的伦理影响图景。话虽如此，对建模团队来说，重要的技术问题虽然必要，但不足以全面了解团队需要处理的伦理、隐私和安全问题。在冲刺 0 的待办事项中，需要执行设置 5，以构建更全面的图景，使你能够就这些关键问题现在以及项目后期做出明智的决策。

隐私、安全和伦理计划：设置 5

• 审查项目的企业社会责任和伦理。

• 构建并共享隐私、安全和数据处理计划。

在项目前期工作中，推动项目进行的思想和假设经过了审查，以确保它们合法且符合伦理。例如，我们对“自行车店”进行了数据保护影响评估（DPIA）。随着信息的不断涌现，以及你获得更多关于客户及其问题的访问权限，Sprint 0 提供了更详细地解决这些问题的机会。这让你可以提出如下问题：

• 项目中所有的数据表是否都是为了同一目的而收集的？项目的目的是否适合所有这些表？

• 收集的所有数据表是否都在同一法律管辖区？来自或受特定管辖区的影响是否排除了某些数据？

• 表中是否有任何应被排除或因安全和隐私目的而不同对待的特殊数据主体？

• 你能否在项目基础设施上实施适当的数据处理流程（匿名化、聚合、加密）？

• 如果你的团队和应用程序可以访问所有数据源，他们应该这样做吗？

使用这些问题的答案验证并记录你对拟议系统企业社会责任（CSR）、隐私、安全和伦理方面的发现。项目前期活动应已确定了客户组织中的相关专家和当局，因此请利用这些接触点来开启讨论。

4.7 项目路线图

项目路线图开发工单：设置 6

• 构建并共享项目路线图。

项目路线图是推动项目的高层次计划。本质上，它是你在销售前创建的项目假设和估计的镜像。路线图告诉你（以及团队）何时执行哪些任务，以及需要解决哪些依赖关系来解锁和开启工作的不同阶段。现在制定路线图是有用的，因为：

• 你现在拥有了关于项目交付背景的新信息。这是关于客户组织和数据存储的信息，之前并未可用。

• 你已经知道了团队结构以及团队何时能够开始处理项目的各个元素。

路线图必须遵循本书其余部分展示的一般结构：

• 数据获取和项目基础设施构建：第五章和第六章中描述的 Sprint 1。

• 模型构建、评估和选择：第七章和第八章中描述的 Sprint 2。

• 系统集成和生产化：第九章中描述的 Sprint 3。

然而，根据你的情况，这个一般模式的不同组件可以被提前或推迟。重要的是，你需要与客户利益相关者就路线变更达成一致，这样他们才能理解为什么你（或没有）按照计划使用他们的资金。

例如，在冲刺 1（第五章）中，我们提出了开始工作于系统的用户体验（UX）特性。在所有条件相同的情况下，这是一件明智的事情，因为它更好地确立了模型的非功能性需求。这在评估和选择模型时非常重要，因此，可以通过快速开始 UX 工作来满足这种依赖性。此外，构建 UX 设计使项目变得生动，并吸引客户。

然而，如果你对数据的完整性或对建模团队有效处理数据的可能性有严重怀疑，那么在客户模型上浪费时间是不明智的，这将是一项完全多余的工作。同样，采取“快速且粗糙”的方法来构建数据基础设施可能是一个明智的决定，最初快速原型化一些模型。这可能会将所有技术风险从项目中排除出去，但代价是需要在以后进行大量重工作和可能的延迟。

随着你获得更多经验，这类决策变得更为明显和直接。最重要的提示是，完成这个过程应该与你的客户合作：共同理解为什么需要特定的关注点。就如何处理这些问题并克服它们达成一致。

现在构建项目路线图也为你提供了交叉检查项目估算和假设的机会。根据你对技术基础设施和可用于建模的数据的了解，对你的估算保持现实态度。标记可能在此阶段出现的复杂性和困难，并决定如何减轻它们（可能通过缩减项目范围、增加预算或重新考虑整个项目）可能会很痛苦。然而，这比希望一切顺利而最终导致项目失败要痛苦少得多。

4.8 冲刺 0 检查清单

你可以与交付团队一起完成表 4.2 中的检查清单，以确保在项目开始之前将冲刺 0 的元素到位。冲刺 0 的目标是确保团队能够有效且高效地工作。在检查清单会议中参与的每个人都应该投入确保每个项目都得到有用覆盖。

表 4.2 冲刺 0 检查清单

项目	备注及示例
数据描述	是否存在数据资源充足的生命周期描述？这是对数据是什么的描述性描述（领域、来源系统、规模、时间范围等）。概述看起来是否一致且充分？数据描述是否经过任何数据实验或其他方法的验证？
提供的数据表和其他数据源清单	表的名称和内容描述（例如，客户主表，客户类型层次结构）。其他数据源（例如，传感器，聚合传感器平台）的名称和描述以及连接细节。
局限性或问题	描述已知的数据问题。记录数据起源中的任何未解释或不清晰的步骤。
业务用途	到目前为止已知的数据业务用途概述（客户当前如何使用它）。
文档计划	确保为所有强制性的文档定义交付日期，并且这些文档的创建和按时交付是可行的。确保为文档的交付分配了资源。
项目路线图	提供一个高级概述，说明如何实现项目的最终成果。
沟通计划	确保与项目利益相关者（内部和外部）建立足够的接触点。
基础设施计划	资源和时间已到位，以提供所需的工作环境和开发基础设施。
团队设计	已确定交付资源，并可供项目在预算内成功执行。
项目脉搏	列出项目期间计划召开的会议，包括每次会议的目的（冲刺计划，回顾）；包括每日站立会议的日程和出席名单。

4.9 自行车店：项目设置

自行车店项目已定义并向客户销售，交付五个挑战：

• 挑战 1: 项目将验证使用自行车店的 opdis2 数据库和其他资产构建客户流失预测系统是否可行，并将测量该系统的性能，以预测的召回率和精确率来衡量。

• 挑战 2: 项目将验证使用自行车店的 opdis2 数据库和其他资产构建需求预测系统是否可行，并将测量该系统的性能，以预测的召回率和精确率来衡量。

• 挑战 3: 你将调查一个使用从 opdis2 迁移到新云平台的数据和数据流实现的实施，以向制造和零售服务用户提供及时、可操作的信息。这使他们能够优化与库存、供应和客户互动相关的业务决策。

• 挑战 4: 如果 1-3 挑战得到客户满意，你将实施并交付一个提供所需功能的系统。

• 挑战 5: 我们将验证 2-5 年前的数据在创建收入和流失模型时是否足够质量，并将量化这些数据质量对从可用数据中提取的模型排名和有用性的影响。

你已经和投标团队一起庆祝了胜利，每个人都期待着你能够使项目启动。你的组织将你分配到这个项目，并分配了一笔资源预算。你被告知要与资源经理合作，组建一个合适的交付团队。

你首先做的事情是打电话给罗布，确认他是否仍然可以参与这个项目。你松了一口气，因为他没有被抢走，并立即将他的名字标记为自行车商店资源系统。罗布推荐了一名数据工程师凯特，她有空闲时间参与设置冲刺。然后你打电话给凯特，邀请她喝咖啡讨论参与项目的事情。在会议中，你向凯特概述了预期的任务：支持罗布，建立基础设施，并开始对自行车商店的数据进行调查。凯特渴望参与主要项目，你决定她非常适合。

你将凯特标记为必需人员，她的经理告诉你她现在开始为你的项目计费。罗布发信息告诉你，他稍后会与凯特见面，让她开始处理系统访问请求。

你需要找到另外三个人来组成团队。你和罗布安排了一次会议，一起审查了工作计划。你们俩决定，在项目的最后四周之前，你们需要两名机器学习工程师和一名数据科学家。在项目的最后四周，你们需要一名用户体验工程师和一名应用开发者，但会保留一名机器学习工程师，当然还有凯特和罗布。你联系了相关的资源经理，询问谁适合你分配的任务。

虽然任务都是短期性的，但资源经理们非常积极，因为他们认为这种项目可以激励他们的报告人。很快，一份名单就来了。你审查了所有的简历，并与你和罗布认为合格的候选人安排了认识彼此的聊天。

应聘者证明非常优秀，你要求丹尼尔（一名数据科学家）、詹妮（一名机器学习工程师）和山姆（也是一名机器学习工程师）加入你的团队，为期四周，以及克拉拉（一名用户体验工程师）和米格尔（一名应用/数据工程师）在最后四周加入。

你知道系统将采取的形式对用户来说将非常重要。在高层达成一致，你需要一套仪表板（用于库存的仪表板包含更多细节，用于客户流失的仪表板），重点是易用性。你决定让克拉拉在项目初期花一周时间确定这一点。碰巧的是，克拉拉和她的资源经理对这个想法持开放态度，因为克拉拉想在第六周和第七周去度假。

这种好运促使你检查团队的休假卡，你发现罗布在第四周预订了一周的休假，而你为第七周和第八周预订了两周的休假。这很不方便，也很打乱计划，但片刻的反思告诉你，包括你在内的人们都需要休息时间。这些新的空缺让你有机会为项目的最后四周预订山姆。表 4.3 显示了迄今为止的资源计划。

你与你的组织运营团队的一名成员一起计算提议的资源计划的成本，你很高兴地发现它远远低于项目的目标成本。事实上，你还有一些备用金，可能用于在第七周和第八周保留丹尼尔，考虑到所需的工作量，这可能是个好事。

表 4.3 识别资源后项目的粗略资源计划

资源	W1 (0)	W2 (0)	W3 (1)	W4 (1)	W5 (2)	W6 (2)	W7 (2)	W8 (2)	W9 (3)	W10 (3)
你
罗布
凯特
丹尼尔
山姆
詹妮
克拉拉
米格尔

你坐在椅子上，思考你、罗布和凯特在接下来的大约八个工作日内需要做什么。你已经尽可能地快了，但时间在流逝，你还有很多事情要做。不过，有两件事你可以迅速解决：文档计划和沟通计划。

你根据标准模板工作，并决定卡拉玛非常适合担任客户的产品负责人，因此你给她发消息询问她是否愿意在项目中承担这个角色。你还问她谁可以在《自行车店》这边作为你的日常问题解决者，以促进交付。

幸运的是，卡拉玛愿意成为项目的产品负责人，她认识一个很棒的人，尼雷什，她是她组织中的交付经理，可以成为日常技术联系人。尼雷什对《自行车店》的系统了如指掌，卡拉玛完全有信心，如果问题可以解决，尼雷什会解决它。你写了两份草案，并将沟通计划和文档计划发送给卡拉玛和尼雷什，并请他们提出意见。

使用项目前的组织结构图，你让 Niresh 介绍你认识 The Bike Shop 的数据保护官（DPO）和负责批准此项目的安全架构师。在与他们见面之前，你、Rob 和 Kate 聚在一起，讨论可能的隐私、安全和伦理问题。这些问题包括项目合同中确定的数据权限问题，以及不要使系统排除特定客户的需求。当你与数据保护官（DPO）和安全架构师（SA）会面时，你向他们简要介绍了项目和计划。会议后，你与 DPO 和 SA 分享了简报幻灯片，以及你获得的行为和笔记（通常，这些是为了获取更多信息，这些信息将在项目后期出现）。

Rob 和 Kate 现在对将要使用的基础设施有了清晰的理解，你对将要获取的数据以及如何处理和利用这些数据有了强烈的想法。下一步是让 Kate 和 Rob 设置项目基础设施。这里有两部分工作要做：

• Rob 需要设计将要使用的 dev/test/prod 堆栈。Rob 可以利用他在客户基础设施中可以访问的组件来完成设计。然后他和 Kate 可以请求访问权限。

• Kate 需要设计和设置一个工作基础设施。同样，为了做到这一点，需要必要的权限。

为了完成工作，Rob 和 Kate 获得了必要的权限，并开始设置各自的环境。一个复杂因素是，The Bike Factory 项目作为更广泛迁移的一部分被出售。整体概念是公司的数据资产需要迁移到云端，新的数据资产将能够部署新的应用程序，例如客户流失管理和库存预测（你将负责开发）。数据迁移完成的日期是第 7 周（表 4.3 中的 W7）。在此之前，数据将不会在新生产环境中可用。

这一发现的含义是，在云容器中部署用于 The Bike Shop 的生产数据库可用之前，需要找到一个解决方案来使团队能够有效地工作。Rob 与迁移项目的技术架构师讨论了这个问题，并一致认为制作 opdis2 数据资产的一次性副本是最可行的方法。

这避免了管理数据馈送和依赖关系的所有复杂性，这些是迁移项目工作中核心的部分，并为你的团队提供了所需的资产。Niresh 和安全架构师被联系，并同意了该计划。结果是图 4.2 中的设计。迁移提供了生产（prod）环境，然后使用该环境来提供测试环境，其中包含适当的生产环境子集。同时，一次性副本将支持开发（dev）。

图 4.2 数据注入到 dev/test/prod 环境

一旦 Rob 了解了数据的提供方式，他就能确定每个环境中所需的服务集合。他的下一个任务是弄清楚如何在 dev 环境中产生的资产被纳入 test 和 prod 环境中。需要一个脚本系统来定义 test 和 prod 环境。然后，这些信息将由新 The Bike Shop 云中的解释器读取并部署，无需人工干预。

Rob 将 dev 环境定义为需要两个高性能开发实例，建模团队将使用这些实例，以及一个 ML 工程团队将使用它来创建和验证所选模型的测试实例。

对于 prod 环境的策略是使用云环境的集群管理技术按需实例化和运行模型实例。这些实例将在毫秒内启动，并且可以在需求下降之前用于推理阶段，届时它们将被自动退役。Rob 推崇这种方法，认为它既经济又稳健。实例的需求将由新 prod 数据库中表刷新事件触发的流程创建。然后可以使用仪表板来审查由模型更新的数据表。这听起来相当复杂，但 Rob 向你保证这是现代的做法。

现在 Rob 完成了基础设施设计，Kate 可以查看系统访问权限，所以你用你的资源配置计划 ping 她。这将让她知道在 dev 机器上需要获取访问权限的人。Kate 还负责在客户的基礎设施上设置文档存储区域，并获取客户的工作票务系统访问权限。源代码控制将使用行业标准工具完成，Rob 指定了一个模型/实验管理工具和数据版本控制系统。

你和 Rob 让 Kate 处理她的任务，并开始创建数据故事的过程。这涉及到与数据架构师和系统用户进行几场会议。通过处理理解 opdis2 系统元素的人员名单，一个清晰的画面出现了。

数据仓库本身是由聚合三个操作数据库创建的。这些代表了由 Manufacture 管理的三个操作区域：欧洲、美洲和亚洲，以及 ROW（世界其他地区）。尽管数据没有标记为来自这些资产中的任何一个，但数据被标记为与特定国家相关；每条记录都有一个国家字段。图 4.3 显示了这一流程。

总体而言，团队可以预期大约有 4000 万行数据，这些数据是从数据仓库中的三个表中提取的。在 opdis2 中被识别为可能有用的三个表是：

• 主要 BW 表，其中包含交易列表（已完成的销售）。

• 产品层次结构/SKU 表。

• 货币表。

图 4.3 创建 opdis2 中表所使用的三个操作数据库

数据所有者已确定产品层次结构和货币表是必须的，以便在交易列表中聚合和标准化信息。产品层次结构/SKU 信息很重要，因为它允许对零件、赛车自行车、实用自行车等物品进行合理的分组。这种安排允许对在层次结构中共享共同节点的物品进行预测。物品可能单独出售，但很少，更频繁的是作为一种类型出售，因此理解这些聚合对于向企业提供有用信息至关重要。货币表被确定为重要，因为这允许销售价值的标准化。

主要关注的是弄清楚在项目发现阶段提到的数据质量项目期间发生了什么，在该项目中发现这项工作是在当前项目之前 18 个月完成的。这意味着比这更早的数据可能在特征上有所不同，可能更嘈杂。与尼雷什交谈揭示，在数据质量项目期间，opdis2 中的主 BW 表进行了大量更改和删除，他认为尽管该项目被视为成功，但很难确定对整体数据的实际改进。更有可能的是事情被整理好了，但在练习前后似乎没有应用任何指标来衡量数据的状态。这加强了团队在获得资产访问权限时尝试量化并描述变化前后差异的需求。

这些信息构成了你编写的文档数据故事的基础。你与凯特和罗布进行审查，经过一些评论和改进后，你将其存档在凯特的新仓库中。你注意到她已经在那里为你存档了沟通和文档计划，所以你给她写了一封感谢信。

你与卡拉玛、尼雷什、罗布和凯特安排了一次会议，讨论项目应该如何运行。你描述的路线图很容易得到参与者的同意。需要进行一些前期 UX 工作，同时，还需要大量关注理解数据质量项目中作为一部分完成的数据改进的影响。你走过了预计的下一个三个迭代，参与者点头表示同意。然后你来到工作实践，描述你提出的项目脉搏：

• 每日站立会议

• 每周利益相关者会议

• 迭代评审展示和讲述（每两周一次）

• 迭代评审结束（每两周一次）

• 迭代规划会议（每两周一次）

尼雷什和卡拉玛有些惊讶；他们没有预料到会对项目投入如此多的时间。您指出，这一切都将是持续审查的对象，如果他们认为这是浪费时间，一些会议可以不邀请他们参加。然而，您要求他们在最初的几周内尝试您的日程安排。如果很明显会议日程和节奏是不必要的，那么之后可以进行更改。在项目开始时，确保每个人都清楚地沟通，当团队处于“激荡和形成”阶段时这一点尤为重要。

凯特和罗布非常喜欢对数据故事的审查。他们渴望继续练习，并且他们也想要小心地创建工单并记录他们的工作。凯特写了一份简短的团队宣言并将其存档在文档库中：

• 每个工作项都会创建一个工单。

• 每个工单都会产生一些具体的内容，并由团队保留。

• 只有在经过审查后，工作才会完成。

在冲刺 0 的第 10 天下午，您可以坐下来休息。一切都已经完成，您有时间填写时间表并处理您一直忽略的电子邮件。周一，丹尼尔、山姆、珍妮和克拉拉加入了团队。罗布刚刚演示了开发基础设施，并为团队成员提供了周一早上首先使用的凭证。看起来您和团队都准备好大干一场了！

摘要

• 管理流程需要在需要使用系统或进入建筑的人开始向项目计费之前尽早启动。实际上，确定需要请求什么的工作是一个很好的第一步，请求所有这些是一个很好的第二步。

• 您需要确保客户理解将要交付的内容，以及如何以及何时交付。

• 确保沟通渠道畅通，每个人都清楚他们应该如何分享和获取信息。

• 您的团队需要对如何完成工作进行共同理解。

• 确认您需要的开发环境可以设置并对所有团队成员都是可操作的。

• 确保有一个明确的路径通往生产。

• 深入了解您团队将要使用的数据的生平故事。

5 深入问题

本章涵盖：

• 获取和验证数据访问权限

• 回顾、验证和细化业务理解

• 开发用户体验和模型利用概念

• 建立和运行版本控制和管道系统

• 建立初始管道以向团队交付数据集

• 开始构建数据测试以使你的管道健壮

在第一轮冲刺中，团队建立并开始使用支持交付项目的基础设施，然后他们打开将支撑机器学习项目的数据。为了打开数据，他们将使用他们构建的基础设施（特别是管道和测试系统）。

5.1 第一轮冲刺待办事项

第一轮冲刺的待办事项包括本章（S1.1 - S1.4）和第六章（S1.5 - S1.7）中描述的任务。通过第一轮冲刺，你将准备核心机器学习活动，即使用机器学习算法创建和评估有用的模型。这项工作是要深入挖掘数据资源，并发展团队使用这些资源进行建模的专业技能和能力。你还需要建立支持性基础设施，将数据从其静止状态转移到你需要的地方。

表 5.1 第一轮冲刺待办事项

任务编号	项目
S1.1	执行数据调查；扫描和检查适当的表以检查完整性、覆盖范围和质量。进行数据测试以解决偏差、中毒、质量、覆盖范围和标签准确性问题。编写并审查数据调查。
S1.2	制定业务应用描述。开发应用程序用户故事待办事项（S2.1，S3.1）。与用户验证应用程序描述和用户故事待办事项。识别并验证机器学习模型性能要求。创建用户体验设计。
S1.3	将相关数据聚合和融合成一个综合图。实施和管理数据管道。设计和实施数据测试。
S1.4	委派并采用模型存储库。识别并记录所有用于机器学习管道的工件。
S1.5	规划和设计数据探索分析（EDA）。编写并分享 EDA 报告。
S1.6	根据新的理解检查伦理问题。
S1.7	定义并实施模型基线。

完成这个冲刺的第一步是加深你对数据（以及团队）的理解。我们将在下一节中介绍这一点。

5.2 理解数据

你的团队已经准备好，资金到位，可以开始解决客户的问题。在冲刺 0 中，你获得了这项工作所需的数据资源的概述。现在，手头的任务是进行快速但系统的现有数据资源评估。

在本书中，这项任务被称为数据调查，但也可以称为检查或概述。这是一项快速、结构化的调查，可以产生你可以记录、讨论和分享的结果，以建立理解和洞察。最重要的是，这为数据中的明显问题创建了一个检查点。

数据调查票据：S1.1

• 执行数据调查；扫描和检查适当的表以检查完整性、覆盖率和质量。

• 进行数据测试以解决偏差、中毒、质量、覆盖率和标签的准确性问题。

• 编写并审查数据调查。

因为你在冲刺 0 阶段构建了关于数据的故事，所以团队有一个可以工作的地图，即使它被标记为“这里可能有龙！”但，正如他们所说，地图不是领土。现在，你需要结合你的数据故事和精心组建的数据忍者团队来寻找更多的龙。

可能你还没有组建团队、获取访问权限或建立基础设施来开始处理核心问题，比如处理数据、阐述对问题的理解或创建支持解决这些问题的基础设施。如果你缺乏必要的权限和访问权限，你将陷入困境；团队无法工作，也无法进步。可能有一些范围可以工作在用户体验（UX）上，但现实中，团队在这些问题解决之前几乎无法做出什么贡献。

5.2.1 数据调查

这本书推荐的数据调查有三个步骤。我们已经在第四章中完成了第一步，即数据故事。数据故事会激发并记录关于可用数据资源的建议和信息。现在，我们需要进行数据调查，这验证了数据故事，并提供了更多关于数据资产的非功能性和系统属性的信息。稍后，当我们把数据放在正确的位置时，探索性数据分析（EDA）将研究数据的统计特性。通过 EDA，我们可以找出数据真正能做什么。

数据调查的目的是减少对数据资源内容的疑虑。数据故事将充满关于数据源中包含的内容及其来源的假设和断言。现在，我们需要检查数据故事中做出的假设是否合理。

结构化和系统化调查的驱动因素是什么？首先，从时间和努力的角度来看，它相对便宜。为此需要编写的查询对任何数据工程师来说都足够简单，并且所有查询都应该运行得很快。这可能不适用于后续的 EDA 练习，几乎肯定不适用于建模阶段。那个阶段的工程可能需要很多思考，查询可能需要一段时间才能运行、测试和调试。现在在数据调查上投入的相对较低的努力可以避免以后的昂贵错误。

调查的第二个优点是，因为它简单、快捷且成本低，所以可以全面进行。相比之下，EDA 可以在有趣的数据集中揭示大量调查途径。团队可能无法全部完成；事实上，他们可能只有时间对数据集的相对较小部分进行适当的探索。

狭义的调查意味着潜在的致命问题可能潜伏未被发现，可能在项目结束时突然出现，破坏一切，并让每个人都感到尴尬。广泛的但浅显的调查让您和团队能够就集中精力进行深入且耗时的 EDA 工作做出合理的决定。至于调查本身，以下对数据的检查是一个良好的开始：

• 是否可以在客户的系统中识别和定位数据故事中描述的所有组件元素？如果最坏的情况下无法访问系统，是否可以使用技术支持人员或数据目录来提供确定数据存在的代理？

• 你能否获取今天或上周或上一个时期的记录数，以及能否获取数据资产的字节大小（Tb、Gb、Mb、Kb）？每个识别出的数据资源的尺寸和结构都应与数据生命周期相符的预期值相匹配。有时，在运营基础设施上无法执行表扫描以确定所有必需的记录是否存在。然而，较小的查询通常可以在不破坏数据系统的情况下进行。

• 根据客户的描述，数据中最老和最新的记录是否如预期的那样？

• 关键列中的最大和最小值，基本聚合（平均值、中位数）以及数据的范围是多少？

• 在数据集历史中重大事件（迁移、重新平台化、数据质量计划、联邦和集成事件）之前和之后的记录中，是否存在规模、格式或类型的更改？

要探索数据调查的想法，想象一个管理智能建筑的有说明性的项目。其中一个表可能包含来自大量传感器的温度数据，你和团队希望将其与阳光、建筑使用和气候数据集成，以创建建筑节能控制系统。如果团队可以访问良好的数据管理系统或数据目录，那么他们应该会发现所需的数据库和表已经就位，并且具有预期的记录数和存储大小。即便如此，交叉检查记录显示的内容也是值得的，以防元数据与实际数据存储不同步。

在接下来的几段中，我们将看到一个例子，说明通过简单的即席查询调查数据表中实际内容是多么有用。调查表明，数据与 DBMS 中报告的一致，并且可用于查询。我们将使用一些 SQL 片段来展示，但如果您无法阅读代码，请不要担心，文本解释了正在发生的事情。

这些调查就像一股意识流，当你发现异常并检查你对数据的理解时。重要的是要确保这四个要点被探测到：所有内容都在那里，大小合适，记录看起来像你预期的样子，并且任何重大问题都被揭露。你将需要使用以下三种类型的数据：

• 数值字段: 表示测量量，如尺寸、重量、密度、频率、波长、时间、浓度或温度。

• 分类字段: 表示应用于颜色、属、种、纹理或产品标识符等事物的标签。

• 非结构化字段: 表示图像、文本或声音。非结构化数据的例子包括产品描述、示例图像、序列或时间序列、社交媒体消息、客户支持电子邮件、交易员之间的对话或事件记录。

下一个部分提供了如何在数据调查练习中处理这些字段的示例。开始调查的一种常见方式是获取所有不同客户数据库中存在的所有数据表的列表。不幸的是，不同的数据库使用不同的工具和命令来执行调查。例如，我们可以使用以下命令访问 Oracle 数据库中的表：

select table_name from all_tables;
>TABLE_NAME | OWNER |TABLESPACE_NAME
TEMPERATURE_READINGS | SYS | SYSTEM
INCIDENTS | SYS |SYSTEM

此命令显示有两个可用的表：temperature_readings 和 incidents。Temperature_readings 包含数值数据，因此我们将使用这个作为调查中第一个提到的表。

5.2.2 调查数值数据

对于智能建筑，首先检查 temperature_readings 表中是否有正确数量的记录是有意义的。这是通过使用select count(*)语句来完成的。

select count(*) from temperature_readings
>262944000

结果是否有意义？我们正在查看大约五年的传感器记录，所以其中会有一个闰年。那么计数就是 5 * 365 + 1 = 1,826 天，所以 262,944,000 / 1,826 = 144,000。这是一个很好的整数。如果你想起了 1,440（24 * 60），那么几乎就像 100 个传感器在五年中每分钟都无故障地报告，完美地过了 24 小时！如果你稍微思考一下，这有点奇怪，但正因为如此，表中大约有正确数量的数据。

但还有更多需要检查的。让我们确保记录实际上是有效的。而不是使用select count (*)，我们将在下面的代码片段中使用select *，这意味着“获取一切”。当然，获取一切会非常繁琐，因为读取数千条记录可能会很痛苦。因此，我们将添加一个limit 1子句到语句中，这意味着“开始获取一切，但一旦你有一个就停止”：

select * from temperature_readings limit 1
>(21,2021,September,17,00:00:10,04.3,tx,op)

至少有一条记录是有用的。通常，与其设置limit 1，不如扫描一些记录（可能是 10 或 20 条）来检查数据。我们可以通过更改limit数字来实现（但你知道这一点！）。也许使用where子句来探测不同年份的记录也是明智的。希望数据模式是可用的并且被理解，如果不是，那么为什么不检查它并记录结果呢？

在温度读数查询结果中，21 是传感器编号，后面是年份、月份、日期和读数时间：21,2021,September,17,00:00:10。在示例中，结果末尾的op是什么（任何人都不清楚）；这在数据项目中并不罕见。然而，你发现的问题应该作为调查项添加到项目待办事项中。可能op代表超出参数，表明传感器损坏。或者，op可能代表操作中，表明传感器正常工作。关键是有人需要尽快检查这一点。

在数据库中已经确认存在有用的记录后，接下来需要检查的是其中是否有有意义的信息。这里的因变量是温度。在之前的记录中显示为 04.3。一个合理的检查是查看因变量是否真的记录在数据中。例如：

select count(*) from temperature_readings as tr where tr.temperature!="null"
>262583041

嗯，这意味着数据集中有 360,959（262944000 – 262583041）个 null 温度读数——大约 0.13%。这并不多，但这是团队需要知道的事情。

此外，有多少温度读数是 0 或者不是 0？记录的温度确实可能是 0.0°C，但在许多数据系统中，（不太）聪明的程序员会用 0 替换“坏”读数，以使他们的数据管道顺利工作。对 0.0 值的计数是值得做的：

select count(*) from temperature_readings as tr where tr.temperature==0.0
>1890030

再次强调，这个数字并不算不合理，总体来说，360959 + 1890030 = 2250989，所以不到 0.86%的数据可能是垃圾数据（然而，0.0 值可能是真实的！）。即使这些缺失值产生了病态的噪声集中，但它们的总体稀少意味着建模的结果不太可能完全无效。显然，某些场景可能会使这些问题更加紧迫。例如，当温度超过某个特定值时，可能只有 null 值出现（例如，传感器故障）。

根据表格的重要性以及构建调查所需的时间，可能你只需使用这样的简单查询就能达到目标，任务就完成了。也许项目依赖于许多具有许多因变量的表格，但并没有什么复杂的问题跳出来。如果是这种情况，那么从高层次上了解表格和数据库的质量可能是正确的努力分配。

另一方面，如果工作的规模更易于管理，你有足够的时间，或者如果数据质量的故事中有关数据质量的谨慎程度更高，那么深入挖掘会更明智。在这种情况下，你可能考虑以下行动（基于智能建筑场景）：

• 检查跨越 0 的范围是否按预期工作。有多少个负温度读数？是否应该有？

• 检查现实世界属性（如温度）的限制。有多少次读数超过 60°或低于-35°？

• 确定实体计数。例如，有多少条记录来自传感器 21？记录了多少个传感器？有多少条记录有“op”，以及该代码字段中有哪些不同的值？

此外，在你编译数据故事的工作中，你可能已经发现了数据中的一些已知问题。现在是时候关注这些问题并深入挖掘。再次看看智能建筑示例，让我们假设在第一年运营后，传感器设计发生了已知的变化。问题是，这个变化是否对现有的数据有任何影响？我们看到了数据集中有 360,959 个空值。它们按年份的分布如下：

select count(*),year from temperature_readings as tr where tr.temperature!="null" group_by year
>(0,0,0,0, 360959)

第一年的数据中有大约 0.5%是空的，而第一年是传感器更换的那一年。这是需要进一步调查并考虑建模时的事项。可能那年的数据应该完全忽略。数据调查的工作是找出需要进一步审查的数据问题，并告知团队他们可以期待的数据资源。调查显示他们所期待的是否存在。

之前的例子处理的是数值。当然，数值数据不会是你唯一需要使用的数据，那么在调查分类或非结构化数据时，你应该采取什么行动？

5.2.3 调查分类数据

对于分类数据，了解记录在各个类别中的分布通常很重要。在智能建筑示例中，有一个传感器类型代码，我们在运行查询时看到了它：

select * from temperature_readings limit 1
>(21,2021,September,17,00:00:10,04.3,tx,op)

未知的是 op，但 tx 是一种传感器类型。有多少种传感器类型？关于传感器类型的数据是分类的（制造商 ID），因此要了解它需要稍微复杂一些的查询，首先从 temperature_readings 表中获取所有不同的传感器类型，然后进行计数：

SELECT Count(*) FROM (SELECT DISTINCT sensor_type FROM temperature_readings);
>7

数字 7 足够低，值得列举它们：

select distinct sensor_type from temperature_readings as sensors;
>Sensors
A1
A2
Tp
Tn
Tx
Xr
UNKNOWN

UNKNOWN 的出现是我们需要调查的问题，包括不同类型的传感器。然而，此时我们可以停止这条调查线，因为 EDA 练习可能会投入大量资源进行进一步挖掘。记住，数据调查是关于建立需要进一步审查的数据的重要或困难之处，而不一定是现在就进行审查。

如果确定传感器类型很重要，那么在 EDA 练习中，我们应该查看每种类型的数量，每种类型产生多少不同的读数，不同质量的传感器对数据的影响，每个传感器的读数范围，每个类型产生的异常值，每个传感器记录的温度粒度等等。数据调查的目的是确定这些问题是什么，这是我们目前所做的事情。当调查被审查时，问题和问题可以被优先排序，以便 EDA 团队跟进。

5.2.4 调查非结构化数据

在调查中处理非结构化数据是不同的。深入研究一组非结构化项目的属性需要深度机器学习技术。我们将在第六章的 EDA 练习部分更详细地介绍调查非结构化数据，但这些方法通常过于复杂且耗时，不适合数据调查。在调查中，我们需要描绘出数据中可能潜伏的问题和问题。其中一些可能与团队开发的模型以及使用它们的应用程序无关。重要的是要知道它们在哪里，以便它们可以被调查和解决，或者被避免。

对于非结构化数据，重要的是要确定哪些有用的非结构化数据资源可用，并评估它们的质量。在智能建筑数据库中，有一个需要包含在调查中的事件表：

select count(*) from incidents;
>1781

select * from incidents limit 1;
>23-05-2021, CRITICAL, 360, "HVAC failure…", "affinity engineer..")

查询显示文本字段是事件描述和解决方案。让我们评估这些字段的质量：

select incident_description from incidents limit 5;
>"HVAC failure meant loss of cold air for floor 12 to 25",
"HVAC intermittent for several hours, users complaining",
"HVAC reported as making rattling sound",
"Loss of cold air on 5th floor, seems isolated",
"Users reporting excessive heat on 5th floor"

这些片段中似乎有潜在的有用信息。可能很难将其转换为数据，因为解析出问题发生在哪一层可能具有挑战性。另一方面，将这些事件与奇怪的传感器读数联系起来可能很容易。

通常，你会对更多的记录进行此类检查，因为很容易滚动浏览数十条或数百条记录，以查看它们是否（或没有）包含看起来丰富的信息。对于进行调查的分析师来说，检查有多少条记录为空或包含单词NULL也是正常的。快速检查也可能显示其他无用记录的指标（例如“。”或“n/a”），这些指标被用来掩盖其管理应用程序中的必填字段。

类似的方法也可以用于其他类型的非结构化数据。熟练的分析师可以快速从数据库中提取和渲染数百张图片，并扫描它们以查找问题。例如，100 张图片的选择中可能有 90 张只是蓝色的天空。这可能是正常和预期的，并且仍然表明有用的数据，或者它可能是一个问题。

快速在非结构化数据中找出规律性、模式和异常，可以让你提出更多问题，并更深入地挖掘数据。也许 90 张蓝天图像出现在分析师的查询中，因为数据库中存在某种怪癖，使它们随机出现在选择中。EDA 团队可以深入了解这个问题，并提供你需要向赞助商展示的证明，以表明是否存在问题。关键是，你将在投入大量时间和资源进行建模和评估活动之前完成所有这些工作。

5.2.5 报告和使用调查

在可以使用之前，数据调查需要被记录和审查。表 5.2 建议在调查报告中记录的项目。通常，会有许多页不感兴趣的结果，报告了具有正确记录数和良好完整性的表格的存在，例如，因此附上带有关键变化的封面页对调查很有用。这会让每个人都注意到在记录中发现的主要缺点。

表 5.2 数据调查报告内容

项目	备注（示例）
数据描述	对数据是什么的描述（领域、源系统、规模、时间范围等）。
提供的列表表格	表格名称和属性列表。
对于每个表格：
已知问题	将已知问题的描述与数据相关联。
实体数	如果可以实时计数记录，则从数据目录中获取。
样本实体	从表格中取出的新鲜样本。
具有 nulls 的记录数	可能关注感兴趣的属性。
具有零值的记录数	可能关注感兴趣的属性。
调查已知或已揭示的数据完整性问题的特定查询	查询 1``结果``查询 2``结果

调查报告对团队很有用；他们必须自己找到这些信息才能使用数据，因此可以节省重复工作。它还创造了关于数据属性的话题点。此外，随着时间的推移，随着不同的人对数据提出怀疑和好主意，将添加更多查询以调查数据的完整性。逐渐地，数据资源成为项目的一个描述良好的实体。

然而，调查最重要的用途是允许团队确定在 EDA 练习期间在哪里投入精力。调查提供了一张地图，显示了在构建模型之前需要解决哪些基础设施问题。调查文档也成为开始数据测试的便捷方式。（数据测试对于支持建模和随后的生产活动中的数据管道的实施是必要的。）最后，调查可能已经发现了危及项目的数据问题。如果是这样，那么将它们列入风险登记册，并让客户了解这些问题。

5.3 商业问题细化、用户体验和应用程序设计

从数据调查过渡到冲刺 1 的下一步是更深入地理解商业问题。记录和理解商业问题提供了信息，使团队在项目和数据基础设施上的工作变得高效、有方向和有目的。

商业问题细化票据：S1.2

• 开发商业应用程序描述。

• 开发应用程序用户故事待办事项（S2.1，S3.1）。

• 与用户验证应用程序描述和用户故事待办事项。

• 确定和验证机器学习模型性能要求。

• 创建用户体验设计。

正确理解业务是一个艰巨的挑战，可能需要数月或数年。技术团队通常只能逐渐发展对业务需求和约束的深刻理解，并且他们需要很长时间才能真正看到最重要问题的核心。然而，确定团队正在解决的商业问题必须完成，并且团队必须对此形成观点，以便取得成功。为了加速收集和记录核心商业问题，有必要采用一些策略和技巧。

在项目前期，你构建了项目假设，在冲刺 0 阶段，你将其转化为项目路线图。这些明确了你团队交付工作的授权，并且客户也进行了审查。此外，在构建项目假设的过程中，你创建了用户和模型故事。这些输出对于开始创建有效的应用程序设计的工作是有帮助的，但还有更多的工作要做！

为了取得进展，团队需要利用他们目前拥有的信息与下一层的专家和用户交谈。敏捷实践者说：“故事卡是进行对话的承诺” [3]。在项目前期阶段编制的用户故事可以进一步发展和正式化为故事卡。故事卡概述了应用程序的概念、受其影响的人以及如何影响，以及故事对组织的作用。表 5.3 显示了典型故事卡的内容。

表 5.3 机器学习项目故事卡的内容。注意最后的五行，它们确定了如何创建此内容。

项目	备注（例如）
概念	对项目解决的最高级别区域的简单解释；例如，客户服务或库存管理。
利益相关者列表	乔·博客斯（IT），山姆·史密斯（采购），亚瑟·阿斯克（物流）
商业优先事项	商业关注的重点领域列表：客户服务提升、收入、成本降低、增长、多元化、资本效率、现金流、竞争、社会责任等。
商业影响声明	解决方案如何创造价值；它为客户解决了什么问题。例如，这项分析为初级产品部门提供了有价值的见解。
对商业优先级的影响	陈述影响声明与公司商业优先级之间的联系。例如，这些见解指导采购和制造如何更好地推动收入和改善资本效率。
数据资源	识别系统将用于训练和生产的数据资源。描述数据如何在生产中到达模型。
模型概念	描述将要使用的模型，它做什么，以及为什么预期它将有效。
功能/非功能需求	说明模型在其工作中必须有多好。模型需要多少吞吐量、延迟和可用性？提供服务需要多少成本？
如何使用	解释效果将如何作为一项商业活动实现。将如何处理模型的信息或系统的决策？还通过可视化仪表板为决策者提供信息。
问题与挑战	记录可能导致系统实施失败或使其无用的因素。

记录此类组织方面的内容提供了背景并解释了故事的目的。此外，记录模型的数据以及为什么认为模型将有效或可以工作，表明将要进行的工作是有目的的。团队看到了一种可行的方式来应用机器学习（ML）以实现所期望的商业价值。

故事卡的最后三个组成部分描述了模型的约束。功能和非功能需求明确指出模型需要达到的性能，以便对客户有用：

• 功能需求典型地代表了模型产生有价值分类或预测的能力。

• 非功能需求明确指出模型需要快速、经济和稳健地执行。

卡片的下一部分要求记录有关如何使用模型的信息。这是现在必须明确的事情。如果业务流程中没有点可以创建、获取和使用模型输出，那么即使模型完美，也将毫无用处。最后，应考虑并记录问题与挑战。是否存在任何否定模型在业务流程中价值的因素？例如，如果模型为用户提供了一些建议，但当用户最需要这些信息时，他们通常很忙，那么就需要工作来使模型输出有效可消费。

收集填充故事卡所需信息的流程可能既耗时又具有挑战性，因此优先排序很重要。因为你正在从事一个机器学习项目，你需要特别强调故事卡的一些元素。例如，卡片的数据资源部分是关键，因此将讨论中提到的内容与数据故事和调查中已知的内容联系起来是有用的。在开发这些卡片时确定的问题可以有效地输入到调查文档中，并进一步用于澄清的 EDA。

除了强调故事中的数据方面，模型的功能性和非功能性性能要求对我们将在第七章中开发的设计有重要影响。这包括：

• 所需的延迟和响应性: 模型需要多快才能从数据中产生预测，以便它是有用的？

• 模型预期的吞吐量: 每秒或每天可以处理多少案例？

• 预期的使用模式: 它将以批量模式运行（例如，在夜间更新数据库中的数百万条记录）还是在线运行（例如，响应网站上的用户）？

• 所需的鲁棒性: 模型的失败可以容忍多频繁？

• 模型的准确性: 不同利益相关者认为一个有用的模型应该有多准确？

  模型准确性是一个复杂的概念，为了正确评估和衡量它有很多工作要做（参见第八章，其中对这一问题的长篇讨论）。现在，了解团队面临的挑战的深度很重要。

• 错误数量: 不同用户可以容忍哪些类型的错误？哪些错误会侵蚀对模型的信心？错误分类的误判成本与误报成本相比如何？（例如，如果模型在样本中错过了一种疾病的病例，那么与模型错误检测疾病相比，成本是多少？这些错误将产生什么后果？

• 性能标准: 系统的性能与业务价值有何关联？在什么情况下，系统的性能（或缺乏性能）会破坏价值？是否存在任何阈值，当边际效益递减时开始发挥作用？何时性能改进不再重要？

对于每个创建和收集的故事，你需要考虑两件事：验证和交互。首先，故事卡需要经过验证。你需要与受影响的人一起运行它，并确保它反映了他们的现实概念。此外，问问自己，这些是应该花钱的故事吗？严格优先排序和修剪故事，以了解创造价值的最低集合。

对开发出的模型的需求也很重要。对模型提出挑战性要求的故事可能会很昂贵。如果可能的话，消除它们可以使项目更具可行性。问题是，“这是否重要且有价值，足以证明将项目集中在特定故事的要求数据上？”

其次，你们团队的用户体验专家需要提出关于用户如何与系统交互的想法，以及最终将如何与支撑它的模型交互的想法。在项目这个阶段，团队应该有一个良好、尽管仍然必要模糊的想法，即最终产品应该是什么样子。现在开发用户体验概念的好处是，通过制作线框图和模拟屏幕，你开始将概念为消费者以及团队带来生命力。这创造了参与感，并建立了一个共同的理解，即可能实现什么，它将做什么，以及它将看起来如何。（第九章对可以使用机器学习的应用程序的风格和结构进行了广泛的讨论。）

这些发现可以写成应用程序描述，并与项目利益相关者进行审查。这创建并记录了关于应用程序可能看起来如何以及可能如何表现的一致意见。你在报告中提取的要求也需要与建模团队、数据科学家和数据工程师进行验证。可能地，这为风险登记册创建了红旗和风险，或者在同意团队可以交付的要求时，与用户达成绿灯和谈判点。它解释了哪些故事是包含在内的，哪些故事是排除在外的，以及模型需要做什么来交付它们。

在这一点上，适当地对敏捷性发表评论是合适的，比如“这是一个敏捷项目。”所选的故事集和预期的应用程序仍然是讨论点。由于模型尚不存在且可能永远不存在，因此它们还不能具体达成一致。相反，这是一个协议，即这是团队将构建的第一套东西；如果一切顺利，那么这些就是花费客户资金的最佳选择。如果无法从数据中提取出性能模型，那么故事卡需要重新洗牌，你需要另辟蹊径来解决客户的问题并创造商业价值。

一套清晰的描述建模价值和方法的故亊，为从项目中开发有用的输出设定了场景。为了支持这一点，还需要做更多的工作。下一个必须解决的问题是要开发第一套数据管道。该管道将原始数据转换并移动到团队将用于探索和操作以进行建模的环境。

5.4 构建数据管道

数据管道基础设施是机器学习项目的生命线。有用、干净数据的可用性以及能够快速响应变化或新结果进行数据转换和丰富的能力，具有巨大的促进作用。拥有灵活且易于管理的管道基础设施可以使团队更高效，并能更好地响应项目需求。重要的是，它有助于他们在事情出错时应对，如果方法和算法没有达到预期效果。任务 S1.3 定义了这一阶段需要完成的工作。因为这项任务将数据管道交付给团队的开发环境，所以在冲刺 1.3 中需要复制此管道或将其用于测试和生产数据流的重用。

数据管道工单：S1.3

• 将相关数据聚合和融合成一个综合的图景。

• 实施和管理数据管道。

• 设计和实施数据测试。

数据通常分布在复杂的容器、数据库、数据集市和数据仓库生态系统中，这些系统跨越内部网络、云和各个组织。管理和操作这些数据资产集合可能会迅速变得极其复杂。

在第六章中的 EDA 练习之前，团队需要建立一个基础设施，使他们能够快速方便地检查和处理数据，并且他们希望调查结果可靠且可重复。然后，这项工作可以在此基础上构建，以创建一个系统，将可用数据提炼成可以用于训练和测试模型的格式。通常，这意味着使用一系列聚合和转换来将许多（可能是数百个）数据资产减少到一个单一的表格或相对简单的记录流，以便供少数算法消费。数据需要重新平衡，以应对现有项目类型的不均匀分布，从而通过机器学习算法提取出稳健的模型。

对于非结构化数据，这通常需要将其转换为标准格式或大小，对于损坏的项目，需要过滤和扭曲。数据增强是一个使用转换和修改来创建训练示例的过程[5]。

在开发过程的后期，团队扩展管道以服务于数据科学家想要使用和评估的算法。随着模型的测试和比较，可以尝试新的操作来改进和调整结果。构建数据基础设施以适应这些新增和更改对于提高敏捷性至关重要。然而，在团队达到这一目标之前，他们需要汇集包含原始信息的表格，并以可消费的方式提供。任务是：

• 创建一个实时且可维护的资源。可以使用此资源来处理最新数据，并从特定的检查点重新生成过去的结果。

• 识别并处理源数据中的任何问题。这为项目的下一阶段奠定了坚实的基础。

• 创建一个反映其所代表领域现实情况的资产。

管道必须支持所有必要的处理阶段，以实现这三个目标并创建一个可用的训练数据资源。图 5.1 展示了支持 ML 项目数据工程所需的过程概览。图 5.1 中的过程有不同的名称，并且通常以不同的细微差别和阶段划分来呈现。最熟悉的一种框架是在数据工程背景下 ETL（提取、转换、加载）。这里呈现的过程强调了 ML 项目的特定要求。从图 5.1 中，你可以看到数据必须：

• 从其来源摄取。这些可以是来自 RabbitMQ 或 Kafka 等来源的数据流，也可以是存储为 XLXS、CSV 或 Parquet 格式的数据文件。

  一个常见的摄取要求是使用 SQL 查询从多个表和数据库中提取数据。另一个摄取要求是将来自不同基础设施的数据带入目标基础设施。通常，数据是从不同的云环境、SAS 应用程序或本地数据存储带入云基础设施的。一旦到达那里，它就可以方便地由云环境中通常按需提供的 ML 处理设施进行处理。然而，需要注意的是，与特定数据集相关的限制性安全要求可能会将数据从不同的环境驱回敏感数据所在的本地基础设施。

• 一旦数据被摄取到目标基础设施和用于处理它的数据引擎中，就必须对这些数据进行操作和布局，以便用于创建模型。有时这一步被称为集成，因为通常的要求是创建一个可以传递给 ML 算法以创建模型的单一表。然而，通常更好的做法是创建中间表和数据存储，将获取的数据以方便和可访问的形式呈现给建模团队。这种数据的操作包括清洗它并从数据的不同方面创建特征。

• 在为建模团队布局数据后，确保数据可以被团队的正确成员适当且容易地访问是很重要的。许多基础设施的 IAM 框架可以用来提供这种类型的框架，确保只有拥有正确凭证的成员才能访问资源。

  除了访问控制之外，另一个要求是设置一个服务系统来适当读取数据。这可能是一个 SQL 查询、对大型数据文件的访问，或者是一个团队用来请求训练数据、测试数据或数据流的 API。一个很好的做法是提供文档，让建模团队能够从管道创建的资源中自助服务。

图 5.1 使用开发环境数据管道基础设施提供的数据处理需求。这为第 2 个冲刺及以后的机器学习建模团队提供了数据资源。

在这个阶段如果没有避免，有两个陷阱可能会导致机器学习项目出现严重问题。首先，从各种来源构建数据集可能会造成统计问题，其次，未能以工程问题的严谨方式处理这项任务可能会造成技术债务，并在后期使团队陷入细节和困难的泥潭。下一节将讨论当将来自多个来源的数据整合以创建机器学习系统的训练集时可能出现的统计问题。

5.4.1 数据融合挑战

一种相对较新的实践是从多个数据源构建建模数据集，以构建数据图。传统上，统计学家为了特定目的使用单一过程（调查或抽样方案）收集数据。为了复制或验证先前的研究，进行了独立实验以创建和收集数据。元分析被用来结合多个现象的研究结果，以获得对结果的更大信心。尽管检索和使用他人的数据困难且昂贵，但普遍认为，在获取新的原始数据时，这种方法证明更容易且更富有成效。

数据存储和可重复使用以及重新定制的背景是新的。从 20 世纪 70 年代开始，数据集被系统地准备并存储在数字档案中，以供复制和重用，但当时没有处理它们的计算资源。尽管如此，统计学家在数据融合的名称下研究了重新组合数据的过程[1]。如今，数据被获取和重新组合以产生新的见解是常见的，但这个过程存在一些问题。

将特定人群的一部分数据与一般观察数据相结合可能会引入偏差。你可以收集数据作为实验的一部分，你使用这个实验来研究人群的某些部分以检测特定效果。例如，你可能使用测试阴性方案来确保对照组和目标组来自人群的同一部分。这些研究产生了受控、高质量的数据集，将它们与观察数据相结合来模拟某些人口层面的行为是有吸引力的。不幸的是，控制一个变量相对于一组混杂因素的偏差（干扰结果的噪声）的筛选方案可能会引入其他变量的偏差。

引入偏差的最显著方式之一是我们从不同的时间段收集数据，并将其视为单一资产的一部分。数据收集的时间通常是隐藏的特征；也许数据集是从操作快照中创建的，而这些快照本身包含来自不同时间范围的数据记录。例如，你可能会收集多年的零售数据快照，并将其存储在每年的同一日期。在初次检查时，这看起来可能是一致的，但由于快照的日期（例如，一年的 4 月 1 日可能是星期二，而下一年的星期五）会变化，主要交易日可能会从一个时期转移到另一个时期。在消耗这些数据的建模过程中的不良实践可能导致模型存在重大扭曲，并在生产中无法正常工作。

数据集中的稀有实体可能由于随机机会在样本中不成比例地出现而造成扭曲，或者由于它们缺失于数据资产中而给建模造成盲点。此外，你可以过度代表稀有实体，因为它们在数据中比普通实体更引人注目，并且对客户组织来说更重要。例如，在犯罪数据库中，重复和严重的违法者不成比例地出现，因为小违法者对警方没有兴趣。警方不太可能记录小犯罪，但这并不意味着它不常见。从警方记录中构建违法者档案并不能创建所有违法者的代表性档案，而只是警方感兴趣的违法者的档案。这可能导致使用这些数据预防犯罪的效果不佳，因为预测为成功的干预措施可能不适合大多数犯罪分子。

传感器数据集可能包含不同质量的数据。事实上，相同的数据集可能包含不同质量的数据。例如，你可能希望每分钟采样一些传感器，而每小时采样一些传感器。一些调查数据可能有 1-5 范围内的协议值，而另一些可能有 1-10 范围内的值；一些表格可能包含一个区域的平均温度，而另一些可能包含该区域内的温度样本。

在这个层面上理解数据源的语义对于决定是否将它们组合起来有意义和有用至关重要。规范化错误会对从后续融合数据集中得出的模型产生重大影响。盲目地将数据拼凑在一起可能不是一个好主意。对领域有深入的理解并思考可能导致数据集分布扭曲的问题是没有替代品的。幸运的是，你的团队已经到位，你所做的工作提供了关于这些潜在扭曲的信息和意识：你需要证明这些过程是建立在坚实的基础上并反映现实的。至少，检查以下内容是值得的：

• 数据实体是在相同的基础上收集的，无论是基于原则的选择还是一般观察。

• 没有隐藏的变量（如罪犯身份或收集时间）隐藏扭曲。

• 捕获实体行为的传感器在时间上没有数量上或质量上的变化。

有时会遇到违反这些严格规定的数据是有用的，你将能够使用这些数据开发出有价值的模型。如果是这样，那么你故意运用你的判断力并决定这是正确的，而不是依赖盲目运气是非常重要的！

5.4.2 管道丛林

现在，让我们回到在构建项目数据基础设施时可能出现的第二个挑战：没有以纪律的方式将任务 S1.3 作为一个工程问题来处理。

机器学习项目中常见的疾病是管道丛林的出现[4]。这导致了显著的技术债务，使得项目难以管理，在技术和功能上都不可靠。管道丛林出现在那些数据转换和聚合的粘合代码以临时方式构建的项目中，没有考虑到管理和维护。没有团队愿意创建管道丛林，但它们随着时间的推移逐渐出现，悄无声息地逼近团队，直到他们突然发现自己陷入复杂之中。这个过程让我想起了关于破产的著名引言：

你是如何破产的？两种方式。逐渐地，然后突然地。

——欧内斯特·海明威，《太阳照常升起》

一些常见问题可能导致管道丛林的出现。在某些情况下，团队需要处理专门的数据基础设施来应对项目中使用的数据的规模、速度或特殊属性。例如，旧有的专有数据仓库有时以晦涩的二元格式存储数据，没有其他专有导出工具的情况下，可能很难导出数据。处理这些工具的技能可能超出了你的项目团队的能力，你可能需要与客户组织的专家合作。

专业的工具可能是必要的恶行，但它们可能是唯一能够以可接受的性能特征使数据可用于建模或满足软件许可条款的方式。当使用专业或专有工具和适配器时，将它们包裹在标准管道工具中是一个好主意，确保管道被集成到通用基础设施中。因为包装和集成工作可能对团队来说是一个额外的开销，所以可能会诱使你通过一次性的过程来获取所需的数据，但请警告：那样会导致混乱。正确地做意味着你能够控制数据流动，并能够根据需要发现和解决问题。

另一个驱动因素是未能像其他代码一样记录和版本控制管道。数据管道可能成为团队将做出的最重要的代码投资之一，因此要像对待它一样。管道需要根据其工作方式来记录，但它们也需要可被发现且广为人知。如果你使用 Apache Airflow 等管道管理和调度工具，那么管道的发现和识别将为你处理。要警惕那些意外被忽略的异常或特殊情况。确保它们被控制住；例如，通过将它们包裹在一个单步管道和标准工具中。单步管道调用用于该基础设施组件的工具。然而，它将从管道基础设施中进行调用。

最后，就像其他代码管道一样，管道步骤必须被监控和测试。每个步骤和管道都应该报告其何时被调用以及是否成功。可以通过创建计时器或超时来断言失败条件，当操作或管道运行时间过长或完成速度可疑地快时，这些计时器或超时会被触发。设置这些限制可以捕捉到数据测试无法捕捉到的问题，因为有时数据测试并不像应该的那样好。然而，通常数据测试不会在过程的技术执行中捕捉到问题。例如，当满足某些条件时应该附加的数据集可能看起来通过了分布或完整性的测试，即使调用数据库检索附加数据时失败。然而，因为失败发生得非常快（因为连接很小）或经过几次超时（因为无法建立连接），这应该让团队意识到一个问题。

5.4.3 数据测试

除了构建管道测试，团队还应该在数据测试上投入。然而，数据测试也存在一个需要跨越的陷阱。数据测试可能成本高昂且运行缓慢。这并不令人惊讶，因为通常数据量很大，测试可能涉及大量的交叉比较，这些比较在计算上很昂贵。如果你负担不起过于昂贵或会导致管道停止运行的数据测试，那么它必须被战略性地部署。

数据测试的级别和目标是判断问题，但显然，对于正常软件中的测试，实施的高质量测试越多，团队对其工作和结果就越有信心。常见的数据测试类型包括：

• 重复测试: 数据管道的一个常见问题是来自遇到数据泄露问题的源的数据重放，然后被编程从头开始。重复也可能来自复制数据的代码中循环条件中的错误（例如，循环变量在循环的最后一次迭代或某些条件之后没有更新）或手动剪切和粘贴错误。请注意，你可能甚至没有意识到在数据的故事中，有人在数据库中剪切和粘贴，但这经常发生！

• 体积测试: 随着时间的推移，数据量应该是可预测的。利用这一事实来检查到达的数据和预期实现的数据。尝试确定合理范围内的界限和下限。

• 输入数据中的先决条件测试: 这种测试确定任务输入是否符合预期。此类测试的部分和不完整的列表包括测试所有预期的列都存在，测试列包含相同数量的非空数据点（例如，如果传感器 x 关闭，则读取 x 为 null），以及统计测试表明数据的分布接近预期（例如，数据的标准差在某个界限内）。

• 后置条件测试: 此测试确定产生的结果是否符合预期。至于先前的先决条件测试，你可以对数据管道的输出建立一些认识。

• 从先决条件到后置条件的约束测试: 检查这些条件之间预期的关系是否成立。例如，所有非空先决条件都有一个非空的后置条件，或者预处理和后处理数据中 0 的数量相同（如果这是预期的）。

• 性能测试: 如前所述，数据管道步骤可能具有非功能性指标：例如时间、内存、成本和调用次数。这些参数对于监控开发基础设施很有用，对于监控部署的机器学习系统中的生产基础设施也非常重要，但它们也可以用于测试。这些测试可以是绝对的（例如，任务应在少于三秒内完成），也可以是相对的（任务应在正常完成任务时间的两个标准差内完成）。在最坏的情况下，由于非功能性压力或顺序错误，管道中的步骤可能无法完成，从而造成重大损坏。

• 对极端值、空值、NaN、大数、小数和 0 行为的反应测试。

理想情况下，测试基础设施应集成到监控系统。系统级故障（如数据库不可达）的记录以及通知和警报的分发至关重要。自动警报意味着基础设施团队能够迅速响应并解决问题，以免机器学习团队不得不放下工具去打乒乓球。

5.5 模型存储库和模型版本控制

任务 S1.4 要求团队构建模型管理和版本控制基础设施。这允许敏捷且受控地开发和部署在冲刺 2 中开发的机器学习模型。

模型版本控制工单：S1.4

• 授权并采用模型存储库。

• 识别并记录所有工件以用于机器学习管道。

在系统开发过程中，预计每个模型都需要进行大量迭代以找到适当的训练过程、超参数、算法、架构等组合。为了管理典型迭代建模过程产生的实验，您需要实现模型存储库。存储库记录了特定迭代或实验期间创建的特定模型，参数（数据、特征）、超参数、算法、架构以及其他模型组件，以及此迭代的评估指标。

模型选择及其决策背后的信息演变是决定模型未来行为以及开发系统可管理性的重要因素。记录模型的演变可以告知对系统未来稳定性、故障和盲点的调查。通过维护这些信息，系统变得可问责，您可以使用事实证据记录您的选择。您将使用模型存储库来记录以下内容：

• 每个模型的身份，即链接到用于测试和生产（但理想情况下，两者都使用）的二进制或声明性规范的名称。

• 在开发过程中为模型创建的评估结果。

• 在资格认证和选择模型期间为该模型创建的测试结果（如果有）。

• 模型使用的所有技术工件及其开发中使用的工件列表（例如，基础模型或特征）。

• 数据管道的状态（运行或不运行）以及用于提供训练、验证和测试集的数据管道标识符。

• 在使用管道构建训练、验证和测试集时创建的测试结果和监控信息。

除了实现模型存储库之外，团队必须承诺使用它。建模的核心任务尚未开始，但早期实验、非正式测试和基线开发都是应该捕获的信息，因为这为项目的其余部分设定了背景。

5.5.1 特征、基础模型和训练方案

提供一个模型版本控制系统非常重要，因为它为团队在生产中构建、评估和集成模型时提供了控制和自动化。如前所述，团队在项目中可能会使用其他工件。处理这些工件的基础设施对于项目的顺利交付也同样重要。

你应该明确记录和跟踪团队使用的所有工具和组件。编辑器、解释器、编译器、库和虚拟机都需要被记录并经客户批准。许多客户都有针对软件项目库和工具的验证和选择架构合规政策；这些政策几乎总是有例外流程，以便在必要时采用新工具。你不能规避这些流程，所以利用它们来确保你的工具集符合规范，或者正式将其注册为例外。

可重用基础模型的开发创造了一种新的工件类别，这对于机器学习项目至关重要。检查许可条件并确保客户知道所使用的模型是好的，而且它必须在他们的存储库和目录中注册。同样重要的是确保你在所有流程和管道中使用正确的基础模型版本。使用一个模型生成嵌入，然后尝试使用不同的模型进行匹配通常会产生较差的结果。使用 MD5 [2]之类的哈希函数为模型创建一个唯一的标识符，并将其嵌入到模型服务代码中的加载检查，可以保证在生产、开发和测试环境中都使用正确的模型。

当然，团队将使用特定的库和工具来提供从数据中提取模型的算法。版本控制再次显得非常重要。注意团队是否采用夜间构建或无视（或无知）公司政策下载构建版本等异常情况。预期构建版本在生产前会被安全团队明确检查，并理解一个恶意构建不仅可能导致公司对你进行处罚（或你的总结性解雇），还可能导致依赖性问题，从而阻止部署。

另一个可能出现的陷阱是测试构建以避免与许可成本相关的问题或弥补测试中特定硬件的缺乏。例如，用于测试的虚拟机可能省略浮点计算，以便快速完成集成或系统测试。这对于部署和平台团队来说是一个正常的事情，但如果有测试虚拟机或库意外地进入生产构建，那么生产系统将无法工作。

5.5.2 版本控制概述

机器学习是一个快速发展的领域，支持机器学习系统的新组件正在迅速出现，因此不可能列出所有需要版本化的项目来构建一个坚实的生产系统。然而，在项目中实施一些系统性的测试和流程来控制版本化是有帮助的。您可以使用以下测试来建立对系统版本化的信心：

• 使用校验和来确认工件中存在正确的信息。

• 使用签名二进制文件来确认正在使用正确的所有者和来源的工件，并且它可以被信任。

• 从二进制中采样已知值，然后检查它们是否正确。

在许多项目和环境中，采取这些步骤来识别、注册、保护和验证项目的依赖项可能看起来有些过度。但请放心，这确实是值得的！这使问题能够被追踪、及早发现并迅速解决。它还将允许顺利实施快速有效的生产所需的 CI/CD 流程。像 Jenkins、GCP Cloud Build 和 AWS Code Build 这样的构建管理系统需要用所有组件的正确版本进行填充，以便将正确的系统配置部署到生产中。对组件版本的良好的控制允许快速更新和交付配置。如果您手动完成这项工作，那么请预期进度会非常缓慢。

在数据管道、数据测试、模型和特征存储被团队采用并启动后，团队现在可以深入挖掘数据。一旦团队可以轻松地操作现有数据，他们就可以真正地感受到他们为建模所拥有的数据。现在，一切准备就绪，可以开始进行 EDA 工作，然后是模型开发。

本章涵盖了团队在交付项目之前需要做的工作，以应对他们将要面临的真实技术问题。我们讨论了绘制数据资源图、理解需要进一步探索和检查的问题、建立对可解决业务问题的洞察、建立支持数据资产探索及其在建模中使用的数据管道，以及启动模型版本化基础设施。在第六章中，我们将回顾 1 号冲刺的其余部分，包括深化团队对数据集统计特性的洞察的 EDA 过程以及第一个基线机器学习模型的开发。在第六章的结尾，您将找到涵盖 1 号冲刺所有工作的《自行车店》叙述。

摘要

• 数据调查确定预期的数据资源存在，并且具有允许团队有意义地工作的完整性水平。

• 通过开发故事卡和 UX 原型，您将更深入地理解并就项目的方向以及项目假设核心的机器学习建模活动的需求达成一致。

• 需要建立、委托和采用（开启并使用）项目开发所需的所有工件（模型）的存储库和版本控制基础设施。

• 系统性地构建数据管道基础设施，以支持项目后期建模的敏捷开发。该管道必须提供支持数据摄取、转换以供使用以及为建模团队提供访问的功能。

• 仔细记录项目使用的数据资源的数据收集动机和方法。

• 建立数据测试和数据管道测试的基础设施，以确保在模型开发和生产过程中，团队使用的是正确的数据。

6 EDA、伦理和基线评估

本章涵盖：

• 执行 EDA 以发现数据的统计特性

• 使用基础模型探索非结构化数据属性

• 检查项目的伦理、隐私和安全方面

• 构建基线模型以获取关于成功潜力的反馈

• 为估计更复杂模型的性能提供支持

在第五章中，我们学习了获取团队可以用于建模的数据资源所需的工作。现在，团队可以深入数据，了解其特征，并判断可以用它做什么，不能做什么。为此，团队需要以结构化的方式工作，探索数据，使用各种工具进行调查，并记录和分享学到的见解。

这项工作的重要部分是让团队重新审视项目周围的伦理问题。这是至关重要的，因为伦理问题可能会关闭调查和开发路线。在浪费客户在永远不会被使用或开发的开发上的钱之前，确定这是否会发生是很重要的。

最后，团队和你将开发基线模型，这些模型展示了性能底线，你可以通过现成和快速实施的方法来创建这些模型。这样做是为了评估更多耗时和复杂的方法的可能性，并确保这些方法能够提供证明其使用的价值。

6.1 探索性数据分析 (EDA)

一切都准备就绪，你可以开始处理你的待办事项中的 S1.5 票据。

EDA 票据：S1.5

• 规划和设计 EDA。

• 编写并分享 EDA 报告。

到目前为止，我们已经构建了一个关于团队将使用的数据的叙述，并且团队已经确认了它的存在，并且看起来符合预期。我们已经获得了系统访问权限并设置了数据管道基础设施。现在可以使用有关数据集和访问它们的凭证，将数据带入可以进行分析的地方（或者如果事情很困难，多个地方）。如果数据处于适合分析的状态，下一步就是使用分析方法系统地了解我们所拥有的以及我们可以用它做什么。

这个过程通常被称为探索性数据分析 (EDA)。这种实践是在 20 世纪 70 年代（数据时代的黎明）发展起来的，由约翰·图基 [12] 推广。最初，EDA 的重点是使从业者能够从全面端到端的研究工作转变为使用“发现”的数据。如今，我们以各种方式使用 EDA，这里作为机器学习建模练习的前奏。

6.1.1 EDA 目标

随着团队准备查看数据的统计特性，可能会出现关于可能被机器学习算法消费的信息的理解。EDA 的核心是一些简单的问题：

• 单个数据示例是否有意义？是否真的存在与客户数据集中最极端示例相似的客户？客户可能每周有数百笔交易，或者可能大多数客户交易次数很少，甚至连续几周没有交易。如果你找到了典型客户，那么这位客户的收入和交易数量看起来是否合适？

• 实体的分布情况如何？这个问题建立在理解数据中的典型实体和最极端示例的基础上，然后使用这些信息来决定数据整体是否合理。数据范围内是否存在无法解释的空白或死点？是否存在应该存在但具有令人惊讶值的空白？典型的例子是假日季节和周末出现在数据集中。如果零售商报告圣诞节当天的客流量很高，那么需要解释为什么；至少，值得检查业务利益相关者是否认为这合理。

• 数据项的汇总统计数据是否有意义，并且与数据背景相关吗？例如，交易表中的总交易额是否等于公司的总收入？每个日历期间的总交易数量看起来是否合适？

• 数据内部的关系是否符合预期？例如，在人口统计数据集中，是否存在比父母年龄还要大的孩子？在一家增长中的公司中，过去是否有某个时期的收入比当前交易期还要多？

EDA（探索性数据分析）的哲学是让数据自己说话，但不幸的是，时间正在流逝。如果你有时间，对数据进行开放式探索是一个强有力的方法，但在紧张的时间表上很难做到。相反，利用从数据故事和数据调查中提出的大量问题，你和你的团队可以规划一个结构化的练习，以发展你们所需的理解。

将你想要进行的特定 EDA 活动列出，包括活动、方法和你这样查看数据的原因，这是一个好主意。然后，记下你期望找到的内容。通过这样做，你创建了一个记录，显示了所采取的专业方法。与团队一起工作，你还将能够有效地优先排序和控制需要完成的工作，确保你将资源和时间集中在高优先级的调查上。

除了发展对数据的总体理解外，EDA 练习还能使团队能够有效地回顾数据管道的设计。你们在第五章中构建了这些管道，为团队提供工作数据。首次使用这些管道，团队将获得一些关于他们表现如何的反馈。随后，团队将使用这些管道来创建用于建模的测试、训练和验证数据集，正如第五章所述，它们对于建模练习的成功至关重要。

根据团队在生成数据的第一印象后提供的反馈，可能需要调整管道的性能和行为。EDA 练习本身也会对管道的结构产生影响。例如，如果用于确定模型训练性能的验证集不能代表目标领域，那么很可能训练过程没有明确模型应该表示的内容 [4]。

数据集关键属性的方差决定了验证集需要有多大。关键变量或数据集属性的方差分布，在确定训练过程中数据的顺序时也有帮助 [9]。团队可以采用以下三种类型的工具来处理数据：

• 总结统计量： 将数据减少到几个易于比较的属性的计算，如平均值或中位数值（尽管可以计算很多值！）。

• 可视化： 以视觉地图的形式表示数据，目的是展示其整体特征。

• 基于模型： 使用基础模型将数据映射到总结或可视化领域，以了解其属性。当你和团队处理非结构化数据，如图像或文本时，则需要一个模型将现实世界中的特征，如图像，减少到人类可以解释的格式。

6.1.2 数据的总结和描述

总结统计量是一个单一的数字，可以描绘一组数字的概貌。例如，一系列数字如 {1,2,3,4,5} 可以描述为具有平均值为 3 和中位数为 3。尽管描述这个集合的平均值为 3 会丢失大量信息，但在某些情况下，这是关于序列中所有数字的重要信息。作为另一个例子，仓库货架上的一袋袋面粉可能有各种精确的重量，但它们的平均重量为 1.5 KG 提供了买家确定托盘价格所需的所有几乎信息。

在现代计算环境中，我们可以通过使用基于数据框的处理（适用于可以存储和处理在单个机器上的相对较小数据集）或使用 SQL 或其他结构化查询语言来总结数值数据。数据框工具的例子包括 Python 的 pandas、R 中的 dplyr 或 Julia 中的 DataFrames.jl。这些工具提供了强大的数据操作和汇总机制，可以快速提供关于数据实例和聚合的统计洞察。这些工具通常被数据科学家和工程师所青睐，因为它们提供了比原始 SQL 更方便和强大的编程约定和结构。这些工具通常提供了一个describe()函数，您可以使用它来创建数值数据特征的标准化初始报告。要了解更多信息，请查看以下资源：

• 要了解 Python 的 pandas 的使用信息，请尝试 Reuven Lerner 的书籍《Pandas Workout》[6]或 Boris Paskhave 的书籍《Pandas in Action》[7]。

• 要详细了解使用 dplyr 进行 EDA 的方法，请参阅 Ryu 的《Cran-R EDA》小节[8]或 Hadley Wickham 在其书籍[13]中提供的更广泛的概述。

• SQL 提供了一些数据框类型系统的功能，但它是数据库引擎的上下文中。在某些情况下，将数据移动到使用 pandas 或其他数据框系统的机器内存中是不方便的，有时，数据的规模使得这样做不切实际。现代数据库引擎通常可以在存储在其中的数据上运行高度优化和并行化的 SQL 查询。这意味着，即使是大型数据集，对数据执行聚合和汇总操作也是实用的。SQL 通常被认为比数据框语言更底层或更复杂。相反，有许多工程师在 SQL 方面拥有深厚的技能，他们可能更愿意使用它而不是数据框。

选择最能描述特定数据集的统计量可能会令人望而却步。在开始调查之前，不清楚什么将变得重要，而且有众多不同的方式来计算不同类型数据的特性。幸运的是，有自动化的方法来覆盖所有这些领域。《Cran-R EDA》小节[8]描述了eda_report函数，该函数可以自动生成涵盖单变量、分布和基于目标（特性）分析的报告。

虽然创建总结报告是获取数据集方向和概览的好方法，但基于团队对数据的知识和他们对数据的需求提出的问题可能更加启发人心。让我们回顾一下智能建筑示例。查看 temperature_readings 表的团队成员可能会编写以下查询：

select count(*), year from temperature_readings group_by year 

>(52560000, 52560000, 52560000, 525704000, 52560000)

传感器读数在年份间均匀分布，尽管有一个(**525704000**)的读数比其他年份多 14 万个。这并不可疑，因为所讨论的年份是闰年，所以有额外的一天。然而：

Select count (*), month from temperature_readings group_by month 

>(0,0,0,0,0,0,0,0,0,0,0,26944000)

哎呀！所有的读数都被标记为在十二月进行的，这并不好。这时，你意识到数据存在一个全局问题。也许可视化正在发生的事情将澄清它真正的情况？

6.1.3 图表和可视化

虽然使用查询创建汇总统计可以回答特定问题并给出关于数据集的一般信息，但使用例如散点图或脊线图（在时间序列或其他序列的情况下）可视化其元素是非常强大的。无论汇总统计构建得多么好，都可能具有欺骗性，因此构建数据集的视觉描述是获得对其属性清晰理解的有用方式。

使用可视化和图表的一种方式是分解汇总统计。作为一个说明为什么这可能是 EDA 过程中的一个重要步骤的例子，了解安斯康姆四重奏（见图 6.1）是值得的。虽然四个图表中的每个数据集都有不同的联合属性，但它们共享一些相同的汇总值：x[n]的均值为 9，y[n]的均值为 7.5，x[n]和y[n]的皮尔逊相关系数为 0.816。其他汇总统计也相同。虽然对数据集的每个属性进行详细统计调查可能会发现现实与信念之间的差距，就像安斯康姆四重奏可以创造的那样，但通常通过绘制所有内容并查看数据点如何相互关联来发现这一点更容易。

图 6.1 安斯康姆四重奏。Anscombe.svg：Schutz（使用下标标记）：大道，CC BY-SA 3.0 (creativecommons.org/licenses/by-sa/3.0)，via Wikimedia Commons

另一种方法是查看包含欺骗性协变行为的数据。图 6.2 显示了餐厅小费金额与账单金额之间的关系（图片来自维基百科，原始作品[3]）。人们可能会预期账单会围绕对角线拟合聚集，表示线性关系。随着账单的增加，小费比例也应相应增加。然而，中等账单和较差的小费以及较大账单的小费存在显著的扩散。

在 EDA 练习的背景下，如图 6.2 所示的图表向团队展示了在设计用于建模的数据集时，他们需要仔细考虑范围两端之间的扩散差异。仅仅随机采样可能无法提供算法创建有效模型所需的信息。

图 6.2 来自维基百科 EDA 页面的餐厅小费与账单（支票）对比图。由 Visnut 创作，CC BY-SA 3.0，commons.wikimedia.org/w/index.php?curid=25703576

在智能建筑示例中，我们注意到温度数据的月份字段没有意义。让我们绘制一天中温度读数的数量。我们可以通过以下查询从数据中获取这些信息：

select count(*), day from temperature_readings group_by day 

>1.00000000e+00 7.21986000e+06 7.21985800e+06 7.21984900e+06
 7.21985200e+06 7.21985300e+06 7.21985200e+06 7.21984600e+06
 7.21986200e+06 7.21985500e+06 7.21986300e+06 7.21984800e+06
 7.21986100e+06 7.21986300e+06 7.21985600e+06 7.21986400e+06
 7.21985300e+06 7.21985600e+06 7.21984600e+06 7.21985200e+06
 7.21986200e+06 7.21985200e+06 7.21986000e+06 7.21985900e+06
 7.21986400e+06 7.21985400e+06 7.21986200e+06 7.21985900e+06
 7.21986200e+06 7.21986200e+06….

结果是一个大数组，包含大量整数，所以要做的事情是用 Python 函数重写调用，并将其传递给您最喜欢的绘图库（在这种情况下，matplotlib）。图 6.3 显示了从 0 到 7 的范围，但一开始看起来有点奇怪。你很快就会看到 Python 绘图工具决定将 y 轴缩放为 10⁶，因此它显示有 350 多个日值，有超过 700 万的读数，最右边的一个看起来大约有 180 万读数。几秒钟的思考会带来一些好消息。日属性是年日，第 366 天是 2 月 29 日，因为它是传感器网络生命周期中只发生一次的，所以它只占其他值的四分之一左右。

![图片

图 6.3 一年内传感器读数的分布

很明显，每年的每一天都有（大约）与传感器数据按天记录且忽略月份字段时预期的温度数据量。我们还可以看到，数据在年份间的分布是正确的，所以看起来我们收集数据集期间每天都有数据。

另一个明显的探索途径是查看已记录温度的统计数据。尽管我们有大量的读数，但通过从整个总体中随机抽取相对较小的样本，你可以得到代表性的统计数据。

SQL、pandas 和 dplyr 都与强大的绘图和可视化引擎（如 matplotlib 和 ggplot）很好地集成。在实际操作中，尤其是在 EDA 和大型数据集的情况下，应该使用数据的小子集进行可视化探索。绘制数百万个点将会在任何高分辨率屏幕上造成混乱，但它也可能挑战更强大的现代处理器和 GPU。

高效的处理和分箱技术可以帮助，同时通过绘制概率密度而不是单个点。虽然采样可能会误导和有问题，但它也很简单，在用于可视化绘制样本和绘制数据集的一部分的上下文中，它可能是一种有用的方法。尽管如此，一些调查确实需要整个数据。例如，寻找异常或寻找完整性问题可能会失败，因为一个小子集没有捕获任何候选的“坏家伙”。

6.1.4 非结构化数据

如果你的项目消耗非结构化数据，如照片、视频或文本，会怎样？机器学习算法在这里也很有用，因为它们可以将非结构化数据独特地处理成有用的抽象模型。将统计思维应用于非结构化数据是没有意义的。一组照片中的中位数照片不容易定义，而且如果你定义了它并挑选出来，它可能不会像人口中的中位数实体（例如客户记录）那样告诉你其他照片的特性。尽管如此，探索非结构化数据资源中的信息质量是有用且可能的。

使用预先准备或快速构建的机器学习（ML）来探索新的非结构化数据资源可能会有所帮助，但也可以以系统化的方式利用人类感知。考虑一个预先标记的图像数据集的例子。可能感兴趣的特性包括：

• 对应每个标签的图像数量：类别是否平衡？是否有任何标签严重代表性不足？

• 标记项的方向：在 Torralba 和 Efros [11]的研究中，图像被采样并显示，特定侧面和展示厅的展示占主导地位。此外，咖啡杯通常以把手朝右的方向展示（你自己尝试在网上搜索一下）。

• 图像定位：在[11]中，这被称为捕获偏差。标记项在图像的哪些部分出现频率较高？

• 环境：是否有某些背景被重复使用，并与某些图像相关联？关于模型的故事很多，这些模型被构建来搜索坦克，用显示坦克在雪中和拖拉机在阳光下的图像进行训练。结果，声称该模型将雪中的所有事物都标记为坦克，阳光下的所有事物都标记为拖拉机。

• 覆盖范围：标签集是否完整地涵盖了数据集中的图像？是否有未标记的图像？是否有在多个图像中显示但未标记的项目？是否有（令人惊讶的）缺失的标签？比如说，图像是家用工具；你可能会有螺丝刀、锤子和扳手，但有没有锯子或桩？

这些调查是通过将人类眼睛应用于对想象数据集中标签的查询结果来进行的。然而，如果没有标签，更重要的是，在我们使用机器学习（ML）来解决业务问题之前，是否有使用机器学习（ML）来帮助进行探索数据（EDA）的方法？好消息是，你可以使用预构建的基础模型来将数据转换成可以探索的形式。

Facebook、Google 和其他公司使用机器学习来创建通用领域的模型，如英语文本和日常图像（来自日常生活而非望远镜、显微镜和卫星的场景）。这些模型可能存在问题，在使用时需要谨慎，但对于 EDA 练习来说，明智地使用它们风险较低，并且在非结构化数据上，这些模型可以提供其他来源无法获得的见解。

使用适当的基础模型来获取有关数据集的一些概述信息是直接的。我们可以使用许多基础模型来生成浮点数向量（大型、有序数组），社区称之为“嵌入”。这些表示模型确定非结构化数据项在概念空间中的位置。

如果你正在处理一个照片数据集，那么选择一个基础模型，如 EfficientNet [10]，或者对于文本，使用 BERT 衍生模型之一，如 all-MiniLM-L12-v2。从存储和分发这些模型的许多开源存储库之一下载这些模型，并使用它们为所有或合理的数据子集生成嵌入。嵌入通常是 768 或甚至 1,024 个浮点数。它们代表高维空间。直接理解或消费嵌入没有用，但团队可以通过间接方式从它们中获得一些信息。

一种直接的方法是使用降维机制，如 T 分布式随机邻近嵌入（t-SNE）或主成分分析（PCA），来可视化嵌入空间中数据项的分布。这有时可能很有信息量，但降维程度和信息损失可能很大。或者，可以使用 FAISS（Facebook AI 相似性搜索）[5]或 Annoy [2]这样的系统对嵌入进行索引，然后你可以使用最近邻查询功能从语料库中提取一些结构。

莎士比亚戏剧的文本是公开可获取的，因此使用这些文本来展示我们如何使用这种基础模型/索引系统来支持非结构化数据的探索很简单。如果将戏剧提供给解析器并分割成句子，这些句子可以被输入到 all-MiniLM-L12-v2 这样的模型中，你为每个句子提供一个嵌入：

array( 8.19933936e-02,  9.97491628e-02,  6.05560839e-02,  6.95289299e-02,
        4.54569124e-02, -5.78593016e-02,  2.58211885e-02, -5.37960902e-02,
        1.54499486e-02,  1.98997390e-02,  3.31314690e-02,  4.48754244e-02,
       -1.08558014e-02,  2.36593257e-03, -1.36038102e-03,  5.81134520e-02,
        4.76119894e-04,....

= Indeed, there is Fortune too hard for Nature, when
     Fortune makes Nature’s natural the cutter-off of
     Nature’s wit. 

当这些被索引时，我们使用 FAISS 在另一部戏剧中找到最近邻：

Nature and Fortune join’d to make thee great:
     Of Nature’s gifts thou mayst with lilies boast,
     And with the half-blown rose
                       (King John) 

通过遍历索引中的所有项目，我们可以创建一个矩阵，显示所有戏剧之间链接的强度（邻近性）。这可以像图 6.4 中那样以热图的形式可视化。

![图片图 6.4 使用 all-MiniLM-L12-v2 对所有莎士比亚戏剧中的最近邻连接的热图热图可能或可能不会为非结构化数据提供一些洞察。当然，《错误的喜剧》看起来与其他戏剧相距甚远，而《李尔王》和《奥赛罗》似乎联系紧密。尽管如此，我们还可以应用其他过滤器来处理邻里关系数据。例如，我们可以运行一个过滤器，仅提取那些与平均链接值相差 2 或 3 个标准差的连接。在这种情况下，可以渲染出如图 6.5 所示的图形，它显示了《空冠》戏剧在左侧的聚类和《温莎的风流寡妇》在右侧的奇特之处。

图 6.5 在戏剧之间找到显著的（0.05%）链接

6.2 伦理检查点

EDA 工单：S1.6

• 根据新兴的理解检查伦理问题。

到目前为止，适当地部署近年来开发的某些伦理评估工具，以系统地检查可能出现的各种问题是很合适的。目前，IEEE、Ada Lovelace 研究所和微软都有工具和系统来评估和跟踪 AI 和 ML 系统中的伦理问题。

我们在第二章讨论了这类工具，当时建议使用影响评估来理解考虑部署的系统可能带来的伦理影响。当时，你和团队对所提出的系统只有最基本的理解。从那时起，你已经检查了数据，并对业务需求有了更深入的了解。现在，你在审查项目周围的伦理、隐私和安全问题方面处于更有力的位置。

在最近的一项关于伦理影响分析工具的调查中，Ayling 和 Chapman [1] 指出，这些工具在项目应用阶段和它们解决的 ML 伦理方面存在广泛的差异。Ayling 和 Chapman 还发现了缺陷和差距，这以及可用的工具众多，使得进一步发展和在这一领域的方法统一变得不可避免。当一种明确且相对完整的方法被用于理解和记录 ML 系统的伦理影响时，你应该采用它。然而，在撰写本文时，对影响评估有一些明确的要求：

• 涉及所有项目利益相关者，包括用户和受影响的人。

• 理解对受影响者的影响成本与收益。

• 关注项目和要开发系统的生命周期。

• 了解系统的影响如何随着其演变而被衡量和理解。

• 检查将用于治理系统的机制是否充分。

在一定程度上，这些要求（以及来自未来发达的伦理评估系统的其他要求）目前掌握在项目中的你和团队手中。你仍然控制着系统将变成什么样子，因此你仍然可以影响和开发那些定义系统结果的因素。

对于那些接触到系统的人来说，系统的成本可能会超过其好处。如果是这种情况，那么需要在项目的风险登记册中提出，并在可能的情况下进行缓解。同样，系统的治理方面可能不足（考虑到你对客户组织和系统商业方面的了解）。再次，你可以使用风险登记册和项目待办事项来解决这个问题。

开发系统的最终成功和价值由其伦理影响定义。不道德的系统不仅可能毫无价值，还可能成为完全的负担。没有人应该故意开发不道德的系统！利用这个机会，采取深思熟虑的步骤，防止你和你的团队卷入意外。

6.3 基线模型和性能

在孤立于其应用和领域的情况下展示性能评估是很常见的。例如，一个团队可能开发出一个准确率达到 99%的分类器，这很好，但如果没有上下文，谁知道它是否有用或有趣呢？测试集中的大多数类可能占 99%，因此分类器可能总是预测这个类别。

在估计性能时，有许多方法可以绕过这类陷阱（将在未来的章节中详细讨论）。重要的是要迅速确定模型性能相对于其需要为业务完成的工作所处的位置。了解性能与预测多数类的简单模型相比也很重要。如果你的模型没有做得更好，那么你就是在浪费时间。

EDA 工单：S1.7

• 定义并实现模型基线。

可以在相对较小的数据样本上快速开发基线模型（实现快速迭代），使用简单的建模技术，如决策树学习或低维感知器。简单模型往往可能过度拟合（记住数据）或可能严重欠指定（没有模拟数据的复杂性），但在这一阶段，这是可以接受的！我们正在寻找挑战的迹象，并希望为系统的性能设定底线。

从业务分析中来的非技术路线是基线：一个昂贵的复杂模型需要比一个手工制作的分类器表现更好，该分类器查看客户合同到期月份、估计的家庭收入或月支出。好多少？我们可以用另一个问题来回答，模型需要提高多少才能提供支付项目所需的回报率？

采取比无智能、简单系统略好一点的位置的项目在开发中可能看起来很棒。然而，在通往生产的路上，它们几乎肯定会落空。

6.4 如果有问题怎么办？

第 6.1 节中描述的 EDA 练习通常被称为“晴天故事”。然而，结论却忽略了我们在项目中通常会遇到的问题、偏离和死胡同。如果在获取和探索客户数据的过程中，复杂性和问题不止一次地让团队陷入困境，那将令人惊讶。例如，尝试 SQL 端点是很常见的，结果却发现它们根本不存在。有时它们位于无法重新配置的防火墙后面。或者，团队可能会惊讶地发现他们所获得的凭证无效，而管理员因生病或年假而无法联系。这是可以预料的，如果团队和项目有适当的客户赞助和支持，这个问题可以很容易地克服。

一个更严重的问题是，在项目开始时，数据资源在性质和内容上与客户所描述的截然不同。在这种情况下，有三种“雨天路径”可以选择：

1. 选择通往灾难的道路。

2. 重新协商项目的目标。

3. 停止项目。

第一条路径是通往灾难的道路。你继续按照预期数据的方式推进项目，并使用它来构建模型和回答支撑项目的相关问题。也许会有所发现，数据资源得以恢复和恢复，一切都会好起来。经验表明，这种情况不会发生，项目将直接失败。

第二条路径是与客户重新协商项目的目标，基于你现在认为可以（或不能）完成的事情。关键在于你和你的团队能够就迄今为止的参与中理解到的真实担忧和价值进行沟通。这样做可以使你根据可用的数据规划出一条新的成功路线。这个新项目可能成本更高，雄心更小，或者它可能同样紧凑和雄心勃勃，但有所不同。在两种情况下，客户都必须加入并接受方向和结果的变化。关于数据和系统的任务说明中包含的假设在此时至关重要，因为它提供了重新协商的机会。这为第三条路径打开了大门。

从对数据资源的不愉快发现中，第三条路径就是简单地停止项目。同样，工作说明中的假设是使这一机制得以实现的因素。尽管你在合同上能够选择这条路径，但做出这样的商业和专业上的痛苦决定仍然可能。尽管在这个超紧凑、超压缩的项目结构中，你已经完成了三个冲刺中的 1.5 个，这些将得到支付，但如此拼命和快速推进的目的就是为了以更有利可图和更有趣的方式开发这个项目，并在成功后赢得更多业务。现在这不可能发生，而为了找到这一点所付出的努力本可以用于其他更好的机会。

假设你进行的道德评估揭示了无法克服的问题。在没有对之前未识别的利益相关者造成不可接受伤害的情况下，可能无法构建所需类型的系统。在这种情况下，项目继续进行是不可能的。你的工作是识别这些问题。你已经尽可能快地排除了风险，事情并不理想，但就是这样。现在退出可能是对你、团队和客户唯一明智的选择。

该方法论和本书的其余部分专注于更令人愉快的预期：你在没有重大问题的前提下完成了 EDA。你希望得到的数据是可用的，团队理解并能够使用它。你已经建立了并记录了数据约束，理解了业务约束和机会，除了客户系统施加的约束之外。

收集了这些约束之后，现在我们必须解决它们，以找到适合客户的正确解决方案。正是在这一点上，系统核心的模型需要被设计和开发。团队有工具可以工作，对模型的约束和要求有理解，以及能够开发数据和基础模型资产。将这些事情整合在一起并加以利用是项目的下一步，也是第二个冲刺的任务，建模团队开始工作。

6.5 建模前的检查清单

在解决了第一个冲刺的工作项之后，团队应该暂停并运行这个预开发检查清单。这样做是为了确保在开始建模工作之前做好了充分的准备，必要的资源已经到位，每个人都已经消费并理解了在本冲刺中创建的相关信息，并且解决了任何悬而未决的问题。

表 6.1 第一个冲刺的预建模（PM）检查清单

任务编号	项目
PM 1	获得了训练和验证数据的访问权限。
PM 2	已进行数据调查，并检查数据是否符合预期且可使用。
PM 3	数据管道已实施并版本化。
PM 4	已实施适当的数据测试。
PM 5	已创建适当的存储库和版本控制基础设施，以支持记录和管理所有工件。
PM 6	已进行 EDA 并记录结果。
PM 7	基线模型已创建。
PM 8	已进行道德评估。

6.6 The Bike Shop：预建模

The Bike Shop 项目的数据资源位于传统的 SAP 实例中，这些实例在 The Bike Shop 的防火墙后由公司内部网络管理。团队需要一个使用专有数据服务桥接的 SAP 接口，以便在迁移项目之前提前将数据传输到云数据仓库。The Bike Shop 拥有并管理其云着陆区上的云数据仓库。为了使用云着陆区，团队需要获得作为 The Bike Shop 承包商的凭证。访问 The Bike Shop 数据的步骤如下：

1. 为数据服务桥接获取许可证。

2. 获取团队成员的承包商 ID。

3. 使用他们的 ID，团队成员必须参加公司入职培训，并确认他们接受 The Bike Shop 的所有数据政策。

4. 获取并安装双因素认证和 VPN 客户端。

5. 在云着陆区实现数据服务桥接。

6. 配置云着陆区防火墙以允许流量流向 SAP 服务器。

7. 配置公司防火墙以允许来自云着陆区的流量。

8. 配置 SAP 服务器以接受来自云着陆区的连接。

9. 执行商定的单次复制操作。

10. 将数据仓库中的数据导入适当的模式并进行格式化。

虽然这是一项相当多的工作，但这些任务的完成时间更长。它们依赖于服务的配置、交付组件的物理过程以及团队成员在培训课程和安全合规性简报中花费的时间。此外，由于公司内部互联的成本，数据传输可能需要时间。（通常，由于流量管理和企业对其网络提供商提出的服务质量责任和要求，这些连接的速度比消费者连接慢一个数量级。）尽管存在这些瓶颈，团队仍会与在您的组织中负责 The Bike Shop 合同的迁移经理确认，确保此过程在冲刺开始时前置，并且数据在第 2 天到达云数据仓库。

6.6.1 调查之后

The Bike Shop 的数据调查对源数据提出了重大问题。尽管数据涵盖了适当的时间跨度（五年），并且每年和每月的适当记录数量如预期分布，但团队发现了一个问题。数据仓库表中存在大量重复记录，并且三个原始数据表中的记录数与汇总表之间存在重大不匹配。他们记录了这些问题以供进一步调查和解决。

在调查过程中，还注意到几乎所有记录都来自每个月的第 4 周。你要求产品经理检查这是为什么。结果发现，这并不是一个未使用属性的问题（就像传感器数据那样）。实际上，这是一项商业活动。财务团队处理记录以满足每月的截止日期，并在每月结束时完成他们的工作。进行交叉检查以计算记录的分布与来源国家之间的分布。这验证了每个国家的销售记录分布与每个国家在业务中的相对重要性相一致。你准备了数据仓库中的数据报告，并通过文档库（按照项目的沟通计划）发送通知给客户和团队。

同时，团队在 Bike Shop 的着陆区启动了开发、测试和生产环境（按照基础设施计划）。使用基础设施即代码（IaC）快速实例化骨干团队为项目交付所需的所有组件和服务。在这种情况下，没有定制的基础设施，也没有会延迟构建的规模问题。通过简单的检查验证构建，并准备、归档和传达基础设施报告（按照政策协议）。举行了一次与业务利益相关者的研讨会，以确定他们将如何消费和使用该系统。研讨会的议程如下：

• 提出解决方案的概述（包括模拟用户界面），以了解将要构建的内容。

• 审查销售前阶段开发的故事。

• 审查工作说明（SOW）中的项目挑战。

• 推动项目前进的问题：

  • 应为哪些实体做出预测？国家？地区？产品线？单个产品？

  • 需要哪些配置选项？

  • 应为用户提供哪些控制，以便他们可以操作和实验模型？

证明这次研讨会具有挑战性；有几个必要的利益相关者未能出席，现在很明显，项目的赞助权在 CIO 和团队手中。这意味着在项目方向上可能会缺乏业务输入，这最终会降低其对组织的价值。

这种共同经历是由运营经理在评估和掌握其业务创新举措方面的困难所驱动的。拥有利润和损失（P&L）线并对其成功负责的运营经理通常会被激励去实现渐进的性能改进，并将战略变化或组织重点的变化（如投资不同的产品线或投资不同的市场）视为对其业务的威胁。因此，他们不太可能投资这类举措。

在《自行车店》的案例中，创新通常是由制造总监控制下的机械工程开发团队发现的。这个团队拥有一个由公司管理层划定的创新预算，以使业务保持其产品线的竞争力。不幸的是，这个团队对支持 IT 创新不感兴趣。随着公司和经济的数字化，新的结构激励业务利益相关者参与 IT，创新项目变得越来越重要。但是，对于《自行车店》项目来说，那个时间还在未来，团队必须应对业务脱节的现实。

为了克服这个问题，团队与产品负责人合作，接触组织的基层，并与能够提供关于系统见解和验证的人安排会议。这些中层管理者可以通过 CIO 团队进行动员，因为他们参与了日常业务实施和升级计划，因此有动力与 CIO 团队保持良好关系。他们拥有操作专业知识，而且比最初确定的高级利益相关者年轻，对技术的兴趣更大，因此他们是信息的好来源。另一方面，这些专家无法对支持的特性和概念进行签字确认。一系列会议产生了一套稳定的用户故事，并就最终实施应提供的机制和输出达成一致。

在就用户故事、挑战和特性达成一致后，团队开发和验证了待办任务 S2.1 和 S3.1。同时，现在有信息可以做出关于可以使用哪些开源数据来补充来自 SAP 的销售和库存数据的决定。从 Reddit 获取的经济指标和国家特定新闻故事被选中。与主题专家的讨论验证了团队关于 SAP 数据仓库中聚合数据表的发现。

此外，数据仓库中使用的聚合过程似乎存在问题，这意味着原始表中的大量记录可能不在聚合表中。在与 CIO 团队讨论后，决定导入三个区域表并从这些表中创建模型是唯一能够以任何程度的完整性创建结果的方法。这些决策使团队能够设计和开发管道，将源数据移动和转换成连贯的数据，适合进行 EDA 和建模。

图 6.6 显示了团队开发的数据摄取管道。管道中有五个步骤，这些步骤被分解为工作流程元素。首先，启动管道（a），所以首先要做的是通知那些负责管道的团队成员，并记录管道正在运行。步骤（b）从三个 SAP 实例中提取数据到云端的临时存储中。

下一步（c）运行 SQL 查询，为 The Bike Shop 选择的全球货币中的每一笔交易生成一个标准化值。（它可能是美元$、英镑£或欧元€，但在 1991 年使用了英镑，并作为相对值以及与现代货币篮子的即时值进行了调整。）这一步创建了一个包含所有原始记录以及额外列的三个新表。

步骤（d）将这些标准化表连接起来，并从中选择唯一的行。这是因为，在与 The Bike Shop 的主题专家初步讨论中提到，不同地区经常重复记录特定的销售。由于正在开发的应用程序不是旨在确定本地补偿，这是重复发生的原因，而是旨在衡量潜在的业务绩效，因此这些重复必须被移除。

步骤（e）对生成的源表进行一些简单的检查。记录了创建的行数与标准化和源表中的行数之间的差异，以及步骤（b）和（c）中日志中出现的任何异常。根据这些检查确定摄取是成功还是失败，并通知处理订阅者，同时更新项目元数据存储。

图 6.6 The Bike Shop 数据摄取管道包含四个原子步骤

丹尼尔和罗布就建模需求进行了讨论，并重新审视了将开源数据引入 The Bike Shop 数据库以补充信息的想法。决定使用天气预报数据来开发需求模型，其想法是在预测之前某个时间点的预报可以产生关于客户是否想要骑自行车或是否打算在公交车上避雨的见解。

在另一个方向上，团队希望将新闻源数据作为一般客户情绪的来源，然后利用这些数据来预测销售。他们在版本控制系统中确定了这些数据源，并确定需要一个语言模型来支持情绪提取。团队设计了一个选择练习并将其添加到待办事项中。然后，一位数据科学家运行了这个练习。选择了一个模型，数据科学家记录并报告了选择及其原因给团队。这也在版本控制系统中被识别。

6.6.2 EDA 实现

团队准备进行 EDA（探索性数据分析）以了解实际可用的数据。如 4.7.1 节所述，EDA 活动侧重于确保 source_table 具有高完整性，并且 source_table 中的数据有足够的信息来使建模可行且有价值。他们还希望对数据及其特征有一个良好的理解，以便可以与团队共享。确定了两个具体的完整性检查：

• 数据集中的销售数据是否合理，并且与客户向市场报告的收入一致？

• 货币转换和归一化是否合理？

在建模方面，问题变成了是否在相关市场和产品中存在全面覆盖？如果数据从市场到市场或产品线与业务部门之间存在某些偏差，那么这些效应在派生模型中可能比在基础驱动因素以及业务绩效与实践中存在的差异中更重要。此外，团队还需要了解区域之间和产品组之间的活动分布

确定这些目标后，团队将 EDA 活动放入待办事项列表。两位数据科学家承担了涵盖每个活动的几个子任务，并开始单独工作以关闭这些任务。团队还包括一个子任务，将结果汇总成报告。EDA 完整性检查显示，尽管源数据表中的数据显示了预测的问题，但去重和新连接过程似乎很有效。图 6.7 显示了未去重提取的数据中的总销售额，其中使用了简单的归一化。

图 6.7 简单归一化和去重销售数据

在去重和适当的归一化之后，情况变得更加合理（图 6.8）。与已发布的收入数字进行交叉检查显示最小差异（大约 0.1%）。

图 6.8 使用精心设计的货币归一化过程处理重复数据的相同数据

团队调查了最新期间观察到的负收入以及项目开始前最近期间的微不足道的收入，并确定这是由于取消订单（销售团队以负收入的形式输入）造成的。订单被确认为已确认销售的提前期很长，这导致了系统性的扭曲。自行车店采用这些做法以防止企业收入被高估，因此它们是数据的一个必要特征。团队引入了调整因素来补偿管道滞后并处理当前期间的负收入。

简单的数据投影被用于回答关于在待办事项中创建的数据的其他问题。然后，团队成员基于所有团队成员进行的子调查结果创建一个 EDA 报告。该报告将根据沟通计划进行审查、归档和分发。

安排了一次审查会议，以进一步解决项目周围的数据隐私和伦理问题。在这个阶段，团队没有识别出任何数据隐私问题，因为在使用的任何数据源中都没有识别出个人数据。现在，团队熟悉了项目以及《自行车店》的目标，他们可以使用 IEEE 用例矩阵来了解可能与此应用相关的关键伦理关注点（见图 6.9）

图 6.9 基于 IEEE 用例矩阵的《自行车店》伦理评估矩阵

团队将提议的应用视为与运营效率相关。尽管应用中没有个人数据，但团队认为数据治理问题非常重要。如果应用中的数据管理不善，结果可能会误导。矩阵还确定了人类代理和监督为关键关注点。团队注意到这一点，并决定在冲刺 2 中解决这些关注点，确保建模技术能够适应洞察力和与预测分析的交互工具。此外，他们计划使用允许在系统中禁用预测分析并使用仅趋势或稳态预测的控制措施。准备了一份伦理报告，归档并传达给团队。

现在数据集已经到手，团队可以进行一些简单的建模工作，以创建支持对将要生成的模型进行评估的基线信息，并为团队提供关于前方挑战的反馈。Danish 迅速为库存需求和客户流失率实施了一个回归模型。这提供了一个基线性能指标。该模型的结果显示，即使在有限的丹麦使用的数据集和样本中，也有一些强烈的信号。在快速测试中，模型的预测与观察到的波动相关性良好。Danish 之所以能快速产生这个模型，是因为他正在使用团队构建的第一个版本的模型 CI/CD 管道。他还对数据做出了许多假设，因此每个人都清楚问题远未解决。

准备了一份关于数据调查、应用定义、EDA 和伦理报告结果的显著要素的笔记，并在冲刺回顾会议上进行展示。它被用作请求客户对冲刺 1 进行签字的基础。开发并达成共识的冲刺 2 待办事项因此启动，我们将在下一章中讨论。

摘要

• 通过进行数据探索性分析（EDA），可以深入了解开发满足项目要求的模型的可能性。

• 我们可以在数据集可用于分析时，系统地探索非结构化数据。

• 使用图形（图表和图表）来探索和展示数据特征。视觉方法具有揭示性，对于未来参与项目的人来说，传达所发现的内容非常重要。

• 简单的方法（计数、大小、标签等）为非结构化数据提供了一些见解。现代方法（嵌入、映射等）进一步描述了这些数据集。探索当前最先进技术所能实现的可能性。

• 当数据来源和类型变得清晰时，明确地处理伦理考量。记住，未能考虑这个项目方面可能会浪费大量资金，同时也可能在伦理上损害团队。

• 构建简单的基线模型可以验证建模的潜力，并作为一种衡量进展的方式。

7 使用机器学习创建有用模型

本章节涵盖：

• 对数据进行转换以进行处理

• 通过特征工程注入信息

• 设计模型的架构

• 运行模型开发过程

• 决定保留哪些模型和拒绝哪些模型

第二轮冲刺是我们一直努力的方向；终于，我们将要进行一些机器学习！这个阶段项目的成功或失败是其他一切的关键点。尽管我们在预售、冲刺 0 和冲刺 1 的工作中创造了成功的条件，但如果我们不能实施有用的模型，所有这些工作都将付诸东流。如果你已经完成了获取和准备数据的艰难部分，创建一个模型是很容易的。一个简单的模型可能只需要写一行代码或在用户界面上按一个按钮。然而，创建一个有用的模型要困难得多。

什么使得使用机器学习创建的模型有用或无用？机器学习的传统观点认为，一个有用的模型是能够很好地泛化的模型：该模型可以有效地处理它未训练过的数据，并应对未见过的情况。但实际上，还有许多其他特性使得模型有用，或者如果没有这些特性，模型就无用。

表 7.1 列出了有用模型与无用模型的特性对比。为了交付一个有用的模型，团队需要从数据中生成许多特征，创建大量候选模型，正确评估它们，选择最有效的模型，并向受模型影响的人、监管者或审计员解释所有这些。这个过程必须得到专业执行和管理。此外，如果没有严格的评估过程，你的模型可能在生产中证明是脆弱的，或者你可能面临困难，无法说服你的利益相关者你对模型的选择是负责任和适当的。

表 7.1 条目背后的三个驱动因素是：进行与系统内所有利益相关者需求一致的建模工作，建立在坚实的基础之上，并确保结果是稳固的。一个稳固的结果不仅仅是一个优秀的模型，而且是一个其他人可以验证为优秀的模型。现在，团队需要生成允许这种验证发生的资产。

表 7.1 什么使得模型有用或无用？

有用	无用	评论
从一个理解透彻且准备充分的数据库基础设施中创建。	从缺乏控制或对质量考虑不周的临时数据资源中开发。	如果你没有确保质量的过程，你将不知道你正在处理的数据是否良好。
响应已充分理解的需求而创建并满足该需求。	因为可以创建而创建；不清楚是否满足任何需求。	如果你没有为模型支持的情况建立明确的赞助，那么获得赞助所需的工作可能是难以承受的。你可能没有足够的洞察力来质疑利益相关者对商业价值的看法，并证明你是正确的。
考虑到伦理因素而创建。	没有考虑伦理影响或对受影响的人的尊重而创建。	存在伦理问题的模型最终会被业务所淘汰。越接近生产阶段，它们造成的损害就越大。
高质量的特征工程创造强大的性能。	低质量或没有特征工程。	低质量或没有特征工程意味着模型在测试中的性能可能与用户或现实世界的期望和要求脱节。
有意设计。	任意设计。	如果设计是任意的，那么模型很可能是脆弱的。
严格评估。	评估不佳。	当模型评估不佳时，没有人知道它是否有效。
模型选择过程是有目的和透明的。	模型选择是任意的。	随意的选择，谁知道你是否得到了正确的结果，以及你为什么选择它呢？
定义了使用的建模过程。	建模过程是任意的。	一个明确的建模过程允许对模型选择进行问责。
文档齐全。	没有文档。	因为文档促进了透明度，它还使得问题能够被识别和修复。

7.1 Sprint 2 待办事项

在 Sprint 2 中，团队实施系统和专业的建模和评估流程。通过使用有组织和记录的方法，团队避免了产生低质量模型的一些陷阱和常见问题。至少，这是我们所希望的！在我们深入了解细节之前，让我们先看看 Sprint 2 的那些任务。

表 7.2 Sprint 2 待办事项：建模和评估

任务编号	项目
S2.1	创建特征工程计划，然后与团队分享并审查它。实现特征工程管道。设计和添加数据增强。
S2.2	创建模型的设计并对其进行文档记录。考虑作用于模型设计的力量。决定任务的分解以创建整体设计。根据数据中给出的所需归纳偏差选择组件部分。开发融合模型输出的组合方案。
S2.3	就建模过程达成一致并建立：  ▪ 委派并使用实验跟踪器。  ▪ 委派并使用模型存储库。  ▪ 识别并拒绝明显较差的模型。
S2.4	实施并委派测试环境。
S2.5	开发一套测试来确定模型的性能功能。确定在测试场景中要使用的度量标准。
S2.6	测试非功能性特征。
S2.7	使用评估数据来确定要使用的模型。采用显式机制使用模型测试/评估数据来选择生产中使用的模型。考虑如何在设计中组合组件模型。考虑非功能性需求。考虑模型的定性方面。
S2.8	编写模型交付报告。
S2.9	确定并记录模型选择。
S2.10	审查并获得客户对模型选择的批准。

7.2 特征工程和数据增强

特征工程工单：S2.1

• 制定一个特征工程计划，然后与团队分享并审查。

• 实施一个特征工程流程。

• 设计并添加数据增强。

特征工程和选择是机器学习流程的核心部分。未经某些预处理以创建一致、有用和有信息量的特征，原始数据可能对机器学习算法来说意义不大。在建模开始之前，数据集需要得到丰富和转换，以便为算法提供适当的特征。

可用系统化的特征选择和工程方法。例如，在他们的书籍《特征工程与选择：预测模型的实用方法》中，Kuhn 和 Johnson [7] 提供了识别、创建和选择特征的解析视角。在这个框架中，他们使用数学和技术考虑因素来重构数据，使其更适合机器学习算法的消耗。系统化的特征工程方法有助于识别和解决数据的技术问题。特别是：

• 识别和消除数据集中多个字段相同信息产生的偏差。

• 解决由分布偏差和尺度差异产生的偏差。

• 处理层次数据及其在层次结构中的信息分布。

除了解决数据呈现给算法的方式中的技术问题外，我们还可以使用特征工程来编码机器的洞察力和常识。例如，对于在格里高利历中成长的人来说，常识是 12 月之后是 1 月，似乎有理由假设 12 月由数字 12 表示，1 月由数字 1 表示。但考虑到有三天，12/30、12/31 和 1/1 的信息，机器如何能够推断出 1 月的第一天紧随 12 月的最后一天？

另一个例子处理包含方向或方向的数据，通常表示为 0°到 360°之间的标量值，有时表示为罗盘方向或不同点之间的关系。如果我们将这些数据视为线性量，那么方位为 359°和 1°的项目将出现在刻度尺的两端。实际上，它们很接近，两者几乎正好在正北（0°±1°）。如果我们重新构架数据以考虑这种循环性，我们会得到更好的结果。

特征工程是将数据转换成对机器学习算法（例如，1/1 在 12/31 之前，359°在 0°旁边的信息作为机器的知识）有意义的过程。特征工程师不是将知识作为某种额外的推理规则嵌入，而是重新编写数据，使其成为机器学习系统处理的信息的一部分。

给定三天，12/30，12/31 和 1/1，我们可以通过将日期表示为从某一点的距离来解决这个问题的不规则性。如果我们以仲夏日和新年（1/1）为基准，新年（1/1）代表值为 182（通常是），年底的最后一天（12/31）是 181，1 月 2 日（1/2）也是 181。这里的要点是，所有这些例子在数值上都很相似，因此这种转换对于相似的事物更有意义。

我们可以用智能建筑示例来展示如何通过重新编写方向来提高其有用性。正如我们在第四章中看到的，建筑传感器记录了 1-366 天的温度，其中第 366 天考虑了闰年。图 7.1 显示了每年每一天的平均温度。

图 7.1 展示了按一年中的某一天绘制的温度（数据来源于 2019 年萨福克郡沃特什姆气象站，英国政府）。

图 7.2 展示了两个新特性：一个提供候选日与仲夏日的天数距离，另一个提供该日的平均温度，并将其除以从仲夏日的距离，如果存在闰年，则从 0.0（仲夏日）归一化到 1.0（冬至日）。这是 183 天，所以仲夏后的那天值为 0.0054。

图 7.2 按仲夏距离绘制的温度（缩放 0.0 – 1.0）

我们还可以通过使用预训练的基础模型来为一些非结构化数据源创建特征。在第四章中，我们使用基础模型来探索莎士比亚剧本中的非结构化数据。我们可以使用相同的方法从非结构化数据中创建特征，然后我们可以将这些特征输入到机器学习中。这与直接在某个非结构化信号上执行机器学习的方法不同，在基础模型的训练中，基础模型中创建了规律和模式。然后我们使用这些结果以更易于消费的形式表示数据，以便于建模过程。在莎士比亚的剧本中，我们使用了 all-MiniLM-L12-v2 句子转换器来创建新颖性和差异的概念。然后我们提取了一个概念图来关联相似的主题。

我们可以使用类似的方法（以及其他更直接的基础模型应用）来创建有用的特征，并融合来自非结构化和结构化数据源的信息。例如，莎士比亚的例子展示了如何在非结构化文档的空间（即剧本）中找到相似性。让我们考虑一个新的涉及文本数据的问题。

在这种情况下，一封接受新客户的电子邮件被传递到审批流程中。在后来的阶段发现，这封电子邮件被发送给了错误的人，应该以不同的方式处理，浪费了大量的时间和精力。你的团队告诉你，他们认为文本分类器在处理新或奇怪框架的电子邮件时可能表现不佳。

这种类型的边缘情况最终可能会消耗最终过程中不成比例的成本，并且可能会糟糕到破坏用户对分级系统的信心。在 EDA 过程之后，团队认为确定训练集中异常值的功能在清理方面很有用，并希望构建一个高质量的分类器，以确定适当的话题。他们构建了一个简单的特征，为系统提供一个新的奇怪/不新的正常信号。与之前一样，数据使用基础模型的嵌入进行索引。通过获取索引中第二接近的电子邮件（忽略身份匹配）并使用相似度距离来评估这封电子邮件与它的接近程度，来对电子邮件的新颖性进行评级，如下面的伪代码所示：

results_array = array [length(emails)]
for email in emails : 
    match = index.search (email) 
    results_array[email.id]=match.D ❶❷

❶ email.id 是这封电子邮件的索引。

❷ match.D 是索引返回的距离。

结果数组包含每个电子邮件在索引中最近匹配的距离。如果你找到这个数组的标准差，并将阈值设置为两倍标准差加上平均值，那么你可以过滤掉训练中最奇怪的 5% 的电子邮件。如果你将这个特征用于主题分类器本身，那么你可以创建一个“其他”标签，剩余主题的分类将更加强烈。

为一个领域开发高质量的特征可能既耗时又困难。要获得良好的结果，需要大量的经验和领域洞察，这也是为什么特征存储库是有价值的资产。如果之前的某个项目开发了一种表达建筑物中传感器位置的方法，这提供了洞察和信息，那么这将是一个巨大的成功。此外，在组织中创建一致的数据使用方式，有助于确保机器学习算法的行为一致且易于理解。如果你的项目是开拓性的，那么你开发并留下的特征存储库可能将成为客户的一个持久资产。

7.2.1 数据增强

有一个关于早期机器学习系统的传说经常被讲述，据说这个系统是为了在照片中识别坦克而开发的（它被开发的确切应用总是模糊不清）。故事的笑点是，机器学习系统不是学会识别坦克，而是学会识别雪地，因为坦克的照片都是在雪中拍摄的。这个故事几乎肯定是一个虚构的故事，但有一个要点：如果一个机器学习算法只有有限的数据集来学习，那么它能学到的内容是有限的。尽管它可能能够从接收到的信息中学习到一个鲁棒的分类器，但它也很可能陷入陷阱，学会利用数据中的巧合来做出分类。然而，如果有不同的示例，那么误导性的巧合可能会变得非常罕见。

为了解决这个问题，Shorten 和 Khoshgoftaar [13] 开发了数据增强技术。数据增强是一个通过变换和修改来创建额外训练示例的过程。我们可以使用这种技术来使机器学习模型在原始训练集中只有少量示例可用时更加鲁棒。

图 7.3 展示了一系列图像增强。原始图像示例（a）按照（b）、（c）和（d）进行了旋转，尽管我们可以生成更多的旋转。此外，还可以根据（e）和（f）向图像中添加额外的对象，以及其他类型的噪声（g）、反转（h）、缩放（i）和框架或场景内的重新定位（j）。在（k）中，图像被镜像，为机器学习算法提供了另一个猫的示例。

图 7.3 通过简单操作增强猫的图像（维基百科公共领域，commons.wikimedia.org/wiki/File:Black_and_White_Cat_Sketch.svg)。

我们使用如图 7.3 所示的增加过程来构建更稳健和通用的模型。其理念是，如果一个模型专注于偶然的特征，那么在训练数据中存在更广泛的信号时，它被机器学习过程选中的可能性会更小。我们还可以将类似的增加过程应用于其他形式的无结构数据。例如，我们可能想要向文本样本中添加拼写错误，用同义词替换非停用词（不被视为停用词/可由 NLP 解析器丢弃的词），或者通过自动翻译系统传递句子以改变其措辞。对于图像识别系统，我们可能想要使用对比度和亮度的交替，以及许多引入噪声和失真的方案。

无论需要什么，我们都可以在建模过程中迭代地应用新特性和数据增强方法，随着团队的调查进行和新信息关于算法行为的出现。关于迭代建模过程如何管理将在第 7.4 节中讨论。一旦实现了第一组特征，团队的下一步就是创建模型的设计。

7.3 模型设计

模型设计票据：S2.2

• 创建模型的设计并对其进行文档化

• 考虑作用于模型设计的力量。

• 决定任务的分解以创建你的整体设计。

• 根据你的数据所要求的归纳偏差选择组件部分。

• 开发融合模型输出的组合方案。

在机器学习算法构建模型之前，它们必须由团队中的数据科学家和机器学习工程师设计。作为一个类比，值得记住的是，火箭发动机的设计是为了利用可用的技术和燃料来产生所需的结果。如果你的火箭工程团队能够访问到稀有金属和高品质燃料，他们的方法将比拥有大量钛和合成化学品的方法更加务实和受限。同样，机器学习模型的设计是为了在给定可用的数据和它们将运行的生成环境中，实现功能性和非功能性。

7.3.1 设计力量

在冲刺 0 和冲刺 1 中，你明确并阐明了你正在开发的商业应用中机器学习建模的需求和约束。在你的用户故事中应该已经明确了一系列力量，这些力量将作用于支撑你团队提供解决方案的方法的模型设计。以下是一些这些力量的例子：

• 定量性能: 一些定性性能指标包括良好的 F1 分数、精确率和召回率，或者敏感性和特异性。（如果这是你第一次遇到这些指标，第八章对这些不同的性能测量有详细的讨论。）在特定指标上需要谨慎，但本质上，你可以通过分类器完成其工作的有效性来衡量其定量性能。

• 解释/透明度: 给出最佳数值评估的分类器可能无法提供足够的解释来支持其决策，或者在其工作方式上不够透明，无法在特定上下文或应用中使用。

• 延迟: 分类器的延迟应适合应用。例如，对于交互式应用，你可能需要在数据可用后的一瞬间执行分类器。另一方面，你可以在夜间批量作业中转录电影的对白以创建字幕。

• 成本: 如果你需要执行数百万次分类器，你用来运行它的基础设施的成本可能会变得难以承受。

• 数据隐私/安全性: 从分类器行为中得出的推论可能会泄露秘密或机密数据。

• 重用和数据稀疏性: 可能没有足够的数据来训练某些类型的分类器，因此可能存在可以下载并使用而不需要训练的预建分类器，以执行项目中数据不足的部分。

• 项目风险/开发时间: 从头开始训练分类器可能很困难且风险很高，意外的行为可能意味着它们无法使用。下载预训练组件或使用简单模型可以在一定程度上降低项目风险，但会牺牲整体性能。

• 生产中的鲁棒性: 高度优化的解决方案在现实世界中可能很脆弱。

今天的机器学习从业者有一系列算法可供处理现代应用的复杂功能和非功能需求。鉴于这些丰富的资源，你能否从工具箱中挑选出一个解决方案来解决项目中特定的力量？遗憾的是，世界并不总是这样运作，事情要复杂得多。

7.3.2 总体设计

选择适合数据和当前问题的正确算法非常重要，并且有大量的文献可供参考以支持你的选择。例如，凯文·墨菲在他的著作《概率机器学习：导论》概率机器学习：导论 [10] 中提供了大量算法的详细深入解释。然而，通常并不是简单地从所有候选算法中挑选最佳选项，因为：

• 没有最佳选项。相反，你面临的是权衡。

• 没有任何东西完全适合应用，你至少必须选择一个糟糕的选项。

• 最好的选择可能不适合你的模型环境。你的团队不理解它，你没有时间去实施它，硬件平台不支持它，或者（常见的是）在生产中需要太多的关注和干预，而你的用户不会提供这种关注。

我们能做些什么来克服这些日常挑战呢？对这些挑战的一个实用回应是实施一个复合模型，将几种技术结合起来，以处理数据的不同部分，这是单个模型无法做到的（在时间限制的项目中快速且可靠地）。例如，你可能需要一个自动翻译机器人将几种潜在语言中的一种语言说出的句子翻译成英语。在技术上，可以将这个模型实现为一个单一的深度网络，单个网络的性能可能优于专门的单语言网络。将问题分解成部分并使用更成熟和经过测试的解决方案可能风险更低、更容易、更快。

当需要开发几个不相连的模型，这些模型在不同的业务流程部分独立工作时，就会产生不同的问题。例如，在客户服务流程中，可能你的系统需要识别客户所说的语言，然后根据他们面临的挑战提供正确的支持信息。面对这些挑战，你可以做出一些架构选择，将问题分解成各个部分，并使用算法来解决每一部分。然而，这些选择是如何做出的呢？

7.3.3 选择组件模型

数据科学家利用他们的专业知识和经验来选择合适的机器学习算法，以产生针对当前问题的正确模型。经验和对洞察力的理解是无法替代的，但在这一过程中有一些有用的启发式方法，值得考虑。尽管这些经验法则和一般原则可能不对应于最佳技术方法，但在管理建模过程中的项目风险方面可能是有用的。

模型的两个最基本的决定因素是算法消耗和使用的类型数据以及模型产生的输出类型。如果模型需要从 0.0 到 1.0 产生一个渐变的控制信号，而它只能产生开或关的二进制信号，那么这个模型就是无用的。如果机器学习算法不能“看到”颜色，那么它产生的模型将是黑白色的。从根本上讲，问题是，算法能否有效地模拟输出分布？这是一种花哨的说法，即模型是否有什么输出它在技术上无法产生？它原则上能否产生正确的输出比例？如果不能，那么你需要停止团队的工作，并让他们使用能够做到这一点的方案。

既然你选择的算法（原则上）能够创建出你想要的分布模型，那么在可能的情况下，应优先选择已知的算法，而不是新颖的算法。一个新算法可能是最先进的，可能比大家一直用来解决这类问题的旧方法表现得更好。此外，一个新算法可能还没有经过充分的测试，也不被充分理解。至少，一个已知的算法应该与建模团队倡导的最新和最闪亮的方案进行基准测试。如果他们的新“哇塞”机器学习魔法比老的和更知名的架构和方案表现更好，那么太好了！如果它没有，那么老的方法将给你带来极大的安慰。

通常情况下，如果你可以用它有效地解决建模问题，最好使用一个简单的算法。然而，复杂的深度网络架构可以做其他算法做不到的事情。尽管有这个禁令，你可能会发现团队别无选择，只能跳入新的水域，尤其是在处理图像、声音和自然语言等领域时。

深度网络可以为复杂的不规则数据创建模型，但这些通常被认为是不透明或不可解释的。有一些机制使用深度网络，因为它们的性能功能很好。这些机制可以有效地向人类解释，但这些机制总是比更直接、透明的模型（如关联规则或决策树）低效。如果透明性是设计力量，你可能必须仔细权衡它与系统的功能性能。

深度网络在训练和在生产系统中使用时可能会很昂贵。记住，当团队运行一个数据中心价值的一周 GPU 来创建一个可以用来提高建筑能源效率的模型时，他们会燃烧大量的二氧化碳。这可能不是你告诉赞助商的好事情。

这些一般原则只是良好的常识性设计启发式方法。我们选择模型是因为它们可以从输入产生所需输出。这种可能性被称为归纳偏差。

7.3.4 归纳偏差

我们可以使用不同的算法和方法来创建机器学习模型，但每种方法都会在过程中引入一些偏差。以智能建筑示例中的传感器为例。传感器具有以下属性来描述每个传感器：年龄、制造商和安装。安装有两个值，内部/外部；年龄是从 0（新）到传感器安装的天数的标量。有五种不同的制造商，我们数据中有一半的传感器失败了。因此，我们希望创建一个决策树，预测哪些传感器可能会失败。

我们需要在如何构建树方面做出一些选择。我们应该首先测试哪个属性？我们应该对哪个属性应用哪些测试？在这种情况下，一个合理的起点可能是安装属性。这个传感器是内部还是外部的？在某些情况下，我们可能会看到 80%的外部传感器失败，而内部传感器的失败率不到 20%。图 7.4 说明了分割对某些具有安装属性的数据的影响。

图 7.4 使用安装属性分割训练数据。外部传感器（右侧）比内部传感器更频繁地失败。

尽管我们的选择符合常识，但在某些方面是任意的。图 7.5 显示了使用年龄属性进行的替代分割，它创建了数据的一个干净分割。现在我们看到，所有安装时间超过 100 天的传感器总是失败的。使用测试年龄 > 100 的分割创建了一个只包含失败传感器的左节点。

图 7.5 使用年龄属性分割数据，在左分支上产生一个纯节点。在这个树上不需要进行进一步测试。

已经开发出更复杂的选择，这些选择背后有经过深思熟虑的理由，说明为什么它们是合适的或不合适的。这些论点几乎总是归结为奥卡姆剃刀的变体，它告诉我们应该选择那些倾向于产生最简单决策树的分割集，而不是其他无限多的确定类别成员的方式。一个在决策树的节点处使用一个标准来分割目标集的算法，例如使用信息论度量如 J 度量[9]，可能更有可能发现数据中的特定规律，而不是使用另一个标准，如统计显著性或简单计数[2]。

通常，我们使用 XGBoost [1]、其他提升算法和随机森林在表格数据上创建有效且鲁棒的模式。不幸的是，它们创建了复杂且难以理解的分类器。这可能会使得在基于模型的应用中使用它们变得困难，在这些应用中，基于模型的决策应该是透明的并且可以轻松解释。

如果一个 XGBoost 模型过于详细和复杂，无法直接使用，它可以作为一个降噪器，筛选出混淆简单模型的噪声。为此，我们需要训练一个 XGBoost 模型，然后将输出作为使用简单决策树或关联规则发现算法建模的目标变量。或者，您可以将 XGBoost 作为基线来衡量选择简单可解释模型在模型有效性方面所付出的代价。

对于如图像和文本这样的非结构化数据，XGBoost 不太成功且不太适用。为深度网络开发各种层次架构意味着在选择特定架构时可以创建一系列偏差。选择正确的偏差意味着我们有时可以从更少的数据中获得更低的损失，同时以更低的训练和推理计算负担为代价。

图 7.6 显示了五种不同的深度网络。这些是如多层感知器这样的层次排列，为计算机视觉任务设计的网格网络，为语音和基于文本的任务设计的循环网络[5]，图网络[4]，以及基于注意力的网络，如变换器[11]。

图 7.6 机器学习算法中的归纳偏差（改编自 Jumper, Evans 等[6]。序列（a）至（e）是根据这些偏差在机器学习社区中获得流行程度的顺序确定的。箭头表示信号在网络或图中的传播。

图 7.6 中的网络结构是为了响应处理不同类型数据的需求而开发的。例如，图 7.7 显示了一个使用层次结构的感知器型网络。它一次处理一个图像像素的数据，但由于像素的上下文与其内容一样重要，感知器表现不佳。图像中的信息主要存储在像素之间的关系中，而感知器无法捕捉到这一点。

图 7.7 对于一个层次排列的网络（右侧），左侧像素化的图像看起来是什么样子。图像的顺序丢失，并且通过将像素n输入到网络的右侧最输入端，远离上面的像素或与其对角相邻，这使系统识别对象的任务变得困难。

另一方面，我们可以构建卷积网络[8]。如图 7.6 中的（b）所示）来考虑局部性。卷积是在网络中局部传播信息的过程，在局部级别提供激活的正常化和过滤。一个学习到的过滤器在网络的滑动窗口中传递，确定信号应如何从像素传播到像素，并在层之间汇总信息。在有了足够强大的计算引擎来处理这些训练挑战上的图像，并且有大规模的训练集之后，卷积网络成为了图像识别问题的首选架构。

7.3.5 多个不连续模型

许多项目需要构建多个模型来支持人工智能应用的各个部分。这些模型的结果不会相互输入，而是由人类或作为决策系统的单独输入来消费。例如，一个信用风险模型可能由几个不连续的模型组成，代表不同类型或风险驱动因素。一个模型可能模拟欺诈，另一个模型模拟使申请人有风险的依赖关系，而第三个模型可能模拟经济趋势。这些模型的输出可以组合在一起创建一个单一分数，或者可以单独显示给信用控制器。

如果你的团队正在开发一个集成系统，不同模型的分歧需求将对所需系统的复杂性（在推理和数据层方面）和系统的性能（在定量和非功能性性能方面）产生重大影响。我们需要平衡对每个模型的资源分配，以确保系统的整体价值最大化。

记住，资源包括分配给生产模型的时问和处理器功率，以及开发期间团队的努力。一个团队容易陷入的陷阱是花费数周时间打磨一个模型，而忽略了其他模型，这些模型只需稍作努力就能带来更大的收益。

7.3.6 模型组合

另一种设置是使用模型按顺序执行整体推理过程。有时，我们将模型串联起来，因为我们需要捕捉进一步的干预或结果。例如，必须就某个过程中某些试剂的流量控制做出决定，在做出关于加热溶液的另一个决定之前，必须观察混合的结果。这种情况被称为模型组合，其设计过程比两个独立的模型更复杂。

或者，我们可能可以将单个任务合理地分解成一系列依赖模型，尽管在某些情况下，单个模型可能是最佳选择。通常，通过将问题分解成多个步骤并分别学习每个步骤来创建模型的推理链，可以快速且可靠地解决问题。

例如，考虑将句子翻译成英语的挑战。第一步是识别源语言。下一步是确定句子的含义或意图，然后最后一步是以最优雅的方式将那种含义或意图表达成英语。可以想象一个包含所有三个任务的单个网络，这些任务在元任务中被称为翻译（实际上，这些确实存在，并且具有明显的优势）。然而，可能更容易构建三个不同的网络，每个网络执行这些步骤之一，并用适当的粘合剂和管理逻辑将它们连接起来。这种方法有以下优点：

• 我们可以更密切地管理每个子项目在构建组件模型时的技术风险，而不是管理大型且具有挑战性的端到端（End 2 End）网络的风险。

• 可重复使用的元素，如预训练的现成网络或数据集，可能适用于子组件，因为这些可能代表比端到端解决方案更通用的任务。

• 我们可以在隔离状态下测试单个组件，这有助于更容易地进行故障排除和调试。

• 我们可以并行构建单个组件，这可能会缩短开发时间（尽管这假设构建更好的单个网络的成本高于集成成本）。

• 我们可以将部分解决方案工程化到提供商业价值的整体系统中。

如果在开发这些组件中取得了一些成功，并且如果这些组件可以集成到业务流程中并用于支持其决策者，我们可以交付一个成功的项目。然而，权衡的是也存在一些不利因素：

• 组合模型可能不如单个定制模型表现得好。

• 管理大量模型的量产可能很困难且成本高昂，尤其是在文档和流程方面。

• 模型链可能会引入延迟和吞吐量问题以及瓶颈（舰队以最慢船只的速度航行）。

• 理解和维护复杂设计是困难的。

当你已经开发了一个模型设计，并且集成策略已达成一致并传达给团队后，下一步就是团队实现它。

7.4 使用机器学习构建模型

模型流程支持工单：S2.3

• 就建模过程达成一致，并设置它。

• 启用并使用实验跟踪器。

• 启用并使用模型存储库。

• 识别并拒绝明显较差的模型。

实际创建机器学习模型可能像设计一个复杂的深度学习网络（具有专业层和反馈回路）一样复杂，或者像在用户界面上按下“Go”按钮一样简单。当模型创建复杂且涉及多个方面时，创建模型所需的专长是显而易见的，而需要使用专家团队来完成工作的需求是由非专家无法创建支持应用的模型这一事实驱动的。如果你使用低代码或工具驱动的方法来生成模型，有时可能会觉得不需要专业知识，因为即使没有专家参与，似乎也能得到有价值的结果。

事实上，即使模型可以通过一键创建，也需要洞察力和纪律。模型制作者从按下按钮的那一刻起，以及按钮按下后模型所发生的一切，都会创造价值，或者造成损害。正因为如此，定义和管理你用于模型化的过程非常重要。

7.4.1 模型化过程

开发模型的实际过程是好奇心驱动的和实验性的；它既是艺术也是科学。对数据和领域有深入理解，并为模型创造有意的结构是必要的，但不足以成功。为了得到好的模型，团队需要通过实验、内省和调查找到可行的方法。

这听起来像是一种临时和非结构化的活动，从某种意义上说，确实如此。尽管科学家可能会有灵光一闪，尝试一些疯狂的事情，但所有这些都是在管理框架内完成的。对于科学家来说，实验细节会提前在实验记录簿中写出来。

数据科学家需要使用相同的管理框架来实现类似的目标，即严谨性和可重复性。很容易出错，丢失模型设计的一些细节，这意味着模型无法重建或存在未记录的元素。此外，调查需要组织，并保留记录，以便不重复工作，不重复进行本应第一次就完成的工作。不仅反复重做做得不好或记录不充分的工 作会浪费时间和金钱，还会浪费宝贵的资源。实际使用的过程可以防止浪费时间，并且它还旨在防止团队对自己所构建的模型质量产生错误的认识。

在建模活动中，一个常见的问题通常被称为数据泄露，这是指在模型评估过程中，由于意外地将测试信息泄露到训练过程中，导致评估过程的腐败。本质上，数据泄露意味着算法在应该之前偷看测试数据。一个典型的数据泄露场景是这样的：由于某个模型恰好对验证数据表现良好，建模团队往往会专注于类似的模型，并为验证问题找出更多的性能优化。遗憾的是，这并没有转化为现实世界的性能，模型令人大失所望。这可能是因为团队的行为导致了对验证数据中的怪癖和伪影的无意识优化。

作为旁注，另一个常见的错误是训练和验证数据的选取。这在时间序列预测问题中尤为常见，其中来自未来的案例为模型提供了信号，模型随后将其复制到测试数据中。例如，我们使用验证集中的炎热夏季数据来为我们的智能建筑建模。因为测试数据集也是从同一个炎热夏季抽取的，模型在测试性能上作弊，而这种作弊方式在生产环境中是不会复制的。

这些问题阻碍了模型得到适当的探索。此外，本可以用来检查其他有希望的设计选项的时间，都花在了追逐一个有希望的一次性性能的幽灵上。怎么办？

1. 规划如何分配可用时间来实现和探索模型设计性能。

2. 对于设计的每个部分，确定一组实验来创建和验证该组件的行为。每个实验都是建模和测试的一个阶段。写下从这个过程中期望得到的内容。

3. 按计划进行建模和测试，并记录结果。

4. 要理解结果，请使用适当的工具检查结果。

5. 在每个阶段结束后，回顾并决定对计划进行哪些更改，以及是否需要新的功能或数据管道的更改。

6. 从待办事项中选取另一个阶段，并对其执行相同的操作。

这样做的目的是通过规范流程、记录和审查所做的工作，可以识别并停止任何过度优化的过程（可能存在信息泄露）。如果事情出错，至少可以确定需要获取更多的验证数据，并检查模型是否足够好，足以支持进一步的开发。不这样做会导致数据科学家在黑暗中摸索，试图看看他们是否真的有效。通过质询结果、理解它们，并在每次迭代中回顾所学到的知识，开发过程获得了方向和动力。当然，这只是理论上的；正如实验室实验是一条艰难的道路，数据科学实验也同样难以进行。

在决定在模型开发过程中以计划化和系统化的方式进行工作时，你们和团队应该考虑另一组驱动因素。在传统科学中，精心维护的实验记录本允许实验可以被复制，并且实践可以检查其安全性和专业性。同样，仔细记录 ML 过程允许有潜力的模型可以被复制和审计。随着 ML 系统在我们的社会中越来越普遍地被使用和频繁地受到质疑，这一点将变得越来越重要。以专业的方式并保持良好的记录使得你的模型可审计和可检查，这使它们更有用和更有价值。接下来，我们将讨论如何记录建模活动以及如何管理和跟踪结果。

7.4.2 实验跟踪和模型存储库

你所选定的并作为项目基础设施一部分实施的模式存储库存储了团队构建的模型实例。关于这些模型的某些元数据也应该存储在那里。例如，它应该包含创建模型所使用的算法版本，用于算法的超参数，以及链接到为算法提供数据的训练集或训练管道版本。

表 7.3 展示了在多次运行中记录的一些统计数据的样本。在这个图中，我们使用了一个简单的线性模型来进行预测。性能的变化是由于测试集大小的不同，实验的性能是通过 AUC（曲线下面积指标）来估计的。请注意，当数据科学家在上午 10:38 注意到性能存在一些差异，并且测试集的大小没有被记录下来以解释这些差异时，添加了testSize参数。同时请注意，当尝试大测试时，ML 包（Elastic_net）选择的惩罚函数发生了变化。

表 7.3 实验跟踪系统可能记录的统计数据示例

开始时间	持续时间	l1_ratio	惩罚	testSize	auc_test
2022 年 2 月 15 日 10:43	1.9 秒	0.5	Elastic net	0.5	0.93916314
2022 年 2 月 15 日 10:42	2.1 秒	0.5	l2	0.1	0.94286043
2022 年 2 月 15 日 10:38	2.1 秒	0.5	l2	0.1	0.94286043
2022 年 2 月 15 日 10:34	2.4 秒	0.5	l2		0.94286043
2022 年 2 月 15 日 10:00	2.0 秒	0.1	l2		0.94286043
2022 年 2 月 15 日 09:59	1.9 秒	0.5	Elastic net		0.93916314
2022 年 2 月 15 日 09:58	2.3 秒	0.1	l2		0.94505654

记录这些信息既繁琐又容易出错，尽管如此，我们还是使用一个名为 MLflow（但还有许多其他类似工具可供选择）的包（工具）在表中记录了数据。我们从与 ML 算法（在这种情况下，是一个简单的回归）相同的 Python 运行时运行了这个工具。MLflow 有一个 API，我们用它来记录实验的详细信息。我们从建模代码的调用中输入统计数据和参数到 MLflow 数据库中。每次我们运行实验时，都会推送有关参数和性能的数据，我们可以从 GUI 或简单的命令行调用中检索它。

表 7.2 中没有显示的是将二进制文件、资产（如迁移模型、测试、训练和验证数据集）以及构建它们所使用的公式与我们在开发过程中看到的成果和结果联系起来的唯一标识符。这种联系就是模型仓库介入的地方。

由 ML 算法发现的模型被存储为二进制文件，编码了所有发现的参数设置和权重，这些参数和权重指定了从数据中提取的特定模型。这些文件保存在文件系统或数据库中。在 MLflow 的情况下，我们可以使用存储实验详细信息的 API 在文件系统中存储文件。

图 7.8 显示了存储在创建表 7.2 条目中的运行模型的文件。你可以看到，这些工件包括创建模型所使用的所有 Python 包的 Conda 代码以及编码实际模型的 pickle (.pkl)文件。这些工件足以按需重新构建和运行模型，因为所有使它工作的依赖项和需求都存储在仓库中。其他目录包含定义模型及其在实验中表现如何的元数据。

图 7.8 存储在模型仓库中的文件，我们可以用它来了解哪个模型被存储，它是如何制作的，它与实验跟踪信息有何关联，以及如何再次启动并运行它。

在冲刺 1 中开发的数据管道和在本冲刺开始时构建的特征也支持数据科学家的工作。这就是为什么开发这些管道和特征的原因！此外，这项工作是在团队对数据的理解、业务问题和项目的伦理挑战的背景下进行的。我们可以更进一步，使项目的 ML 部分变得更加容易。你和团队可以通过将模型的设计和创建过程外包给机器来节省大量的麻烦。

7.4.3 自动机器学习和模型搜索

一种流行的现代做法是使用自动搜索系统迭代创建模型。搜索通过选择算法参数的变体，并创建和测试具有不同结构和偏差的模型来实现。这种做法的出现是因为深度学习系统可以表达的可能模型空间非常庞大，无法检查所有可以手工构建的结构。尽管，可以说这种过程是由于深度学习系统的发展而产生的，但自那时起，这种做法通常也应用于调整受统计启发的机器学习算法的性能。由于其遗产，这种技术也被称为神经架构搜索（NAS）和有时称为元学习。

AutoML 的伟大之处在于，你可以通过一行代码或轻触按钮来复制勤奋数据科学家的工作。否认通过使用 AutoML 快速提高模型性能所带来的收益是不切实际且愚蠢的。通过这些过程已经获得了稳健的先进结果[3]，这种方法自动化了可能繁琐且易出错的劳动。然而，也有一些问题需要注意。

模型搜索系统是优化系统，因此可以产生在保留数据上表现极好但在测试数据（或生产中）失败的脆弱模型。模型搜索最终会发现一些模型在特定测试上表现良好，这纯粹是运气，某种东西恰好适合。我们将在第八章讨论维护用于评估模型测试系统完整性的问题，但在此阶段，只需指出这可能会成为一个问题。

同样难以证明或解释模型搜索系统发现的架构或参数设置。如果最优（在验证意义上）架构被丢弃（可能是因为脆弱性）而选择替代方案，则尤其如此。现在，到达这个目标的过程已经受到一个差距的损害。第二好的结果是从哪里来的？为什么选择了这条路线或树？团队决定使用自动搜索，然后又忽略了它；这是合理的，但对外部的人来说可能看起来很奇怪。

另一个显著问题是，AutoML 在计算资源方面可能成本高昂。尽管这可能是一项值得的投资，但平衡学习过程成本与通过模型优化获得的收益非常重要，尤其是如果模型是通过人为驱动的故意过程快速发现的。

对于这个应用来说，百分比改善的微小部分在所有所需金钱和资源中值多少钱？更严谨的计算是在花费昂贵的数据科学家推动过程的时间和 AutoML 过程在金钱和能源消耗上的成本之间进行平衡。

尽管如此，AutoML 在某些情况下是有用的。在建模初期使用 AutoML 或模型搜索过程来确定数据集可能达到的性能，可以是一种为更系统化和有目的的建模过程生成基准的有用方法。如果一个系统导出的模型接近 AutoML 模型的最终性能，那么你可以知道停止；它已经足够好了。

相反，如果 AutoML 失败了，那么这通常是一个很好的迹象，表明从数据中无法导出好的模型。可能需要更多数据或更好的特征工程。在这种情况下，你与客户有一个有用的讨论点。这并不一定意味着团队缺乏完成项目所需的 ML 技能，或者你运气不佳。可能是因为 AutoML 的失败表明，项目本身在当前状态下并不适合 ML 技术。

AutoML 的另一个用途是尝试优化一个已经开发的模型，以评估还有多少机会可以进一步改进它。同时，观察优化后的模型在哪里比手头的开发模型表现更好。

7.5 有味道、脏、不好、有味道的模型

模型“味道”——这就像软件工程师在源代码中谈论的“坏味道”。在第六章中，我们详细讨论了建模过程的另一半。在我们深入探讨为什么你应该选择一个模型而不是另一个模型的硬核统计数据和直截了当的解释之前，讨论模型“味道”是很有益的。

表现可疑好或可疑差的模型会变得意外地大或小，它们有味道，很脏。正确的方法是深入调查原因。然后，弄清楚原因后，你需要把模型拖出来，用棍子打它，直到它停止抽搐。然后将其丢弃（通常把模型扔进当地的池塘是个好主意，但这里没有提到这一点）。

问题在于一个糟糕的模型可能伴随着一些令人满意的表现统计数据，这就是为什么保持警惕如此重要的原因。一个模型为什么会“有味道”？

• 在验证数据上的评估过程中，有“味道”的模型表现不稳定和不可靠。对它们参数的微小改变会导致它们性能的巨大变化。这并不是我们希望看到的好行为，这表明有问题。

• 模型有“味道”，可能是因为它们比预期的表现更好，或者尽管你知道它们有问题，但它们仍然可以工作。

• 当模型在表现上与其他类似模型明显不同，或者对某些超参数的微小调整在性能上产生巨大差异时，模型就有“味道”。

有时，生成具有前述列表中一些特性的可疑模型可能指向领域中的某些意外规律。这可能是推动新的系统建模调查的刺激。这是可以的；它遵循了事先记录实验并记录结果的原则，如果最终发现模型确实异常，它可以安全地被丢弃。更有可能的是，模型气味是由管道中的错误引起的，因为库或工具包的实现有问题，或者因为你犯了配置错误。

最常见的情况是，你使用训练集的验证数据进行的所有评估根本不是你所想的。存在数据泄露，或者在训练集或验证集中时间旅行了。或者，模型过度拟合，只是简单地记忆了数据。一旦模型被用于未见过的数据集，它就会失败，因为没有泛化。

这就是为什么保持对模型气味的警觉如此重要的原因。因为这种模型看起来工作得很好，它的外观似乎可以让你和团队从失败的机器学习项目的黑洞中解脱出来。抓住这个臭气熏天的模型产生的美妙结果并转向生产化是非常容易的。这种完全可以理解的行为是灾难性的。如果你能及早发现模型的问题，那么你可以用它来找到需要修复的管道中的错误。由于你和团队在项目的基础设施和流程上投入了精力和努力，一旦这些问题得到解决，重新运行你的实验和调查应该简单快捷。有很大可能性，经过几次迭代后，你的模型将开始变得稳健。臭味将消失！

在本章中，我们解释了建模活动的设置，概述了模型设计的力量和过程。然后我们介绍了建模活动的实际过程以及完成这些所需的架构。在第八章中，我们将覆盖建模故事的另一半：评估和选择我们认为将为我们工作的模型。你还将了解到 The Bike Shop 团队在建模挑战中的表现。

摘要

• 在建模阶段为机器学习算法创建信息性特征。

• 通过数据增强创建额外的训练数据以支持更稳健的模型。

• 理解模型设计中的设计力。

• 对你想要开发的模型组件做出有目的和有效的选择。

• 理解并使用归纳偏差来指导你的建模方法。考虑使用分层、基于网格、循环、基于图或基于注意力的结构。

• 确定何时使用复合模型以及如何有效地构建它们以解决当前问题。

• 结构化和管理一个受控且目的明确的建模过程。

• 使用自动化工具跟踪和管理模型的演变。

• 根据其行为或结构检测和确定应立即拒绝的模型。

8 测试和选择

本章涵盖：

• 结构化测试环境，然后将代码和工件迁移到其中

• 测量模型的属性

• 理解如何离线和在线测试机器学习发现的模型

• 理解如何使用测试结果来选择模型

• 使用定性评估和选择以及定量措施

• 避免在评估模型时陷入欺骗陷阱

到目前为止，在第二阶段冲刺中，团队根据他们对数据的理解、客户的挑战和背景以及他们期望构建的应用，设计了要开发的模型。他们使用了一个结构化的流程来开发模型，并使用实验跟踪器和模型存储库跟踪他们的进度。他们还运用了他们的常识和经验来寻找和拒绝可疑或存在问题的模型。现在，理解模型的成果并正确评估竞争对手的模型，以做出关于将投入生产和应用开发的模型的良好选择，是非常重要的。

测试是一个系统化和离散的模型评估过程。这个过程提供了可理解的数据和证据，团队可以使用这些数据来在下一步的选择中做出更好的决策，即选择。选择是消耗数据和证据并利用它们来做出明确和清晰的决策的过程，这些决策可以向最终用户证明，向利益相关者解释，并接受监管机构的审计。你需要了解测试和选择的适当流程，以及为什么团队需要使用它们。有了这些知识，你就可以与团队一起做出一些关于项目这一阶段应该做什么的良好选择。让我们深入探讨吧！

8.1 为什么需要测试和选择？

你可能会问，既然开发团队的数据科学家已经确定了他们认为最适合实施的模型，为什么还需要一个单独的测试和选择流程？本章中阐述的过程的目的是什么？

对即将部署的模型进行严格的评估对于建立对其性能的信心至关重要，但真正评估一个模型并与其他模型有意义地比较是耗时且昂贵的。这意味着，当可能需要 30 代模型在完成一次全面评估的时间内构思和开发时，将评估嵌入到数据科学家的工作流程中往往是不 productive 的。提出好的候选模型在时间和精力上通常是经济的，但正确评估模型是缓慢且昂贵的。

一个好的评估需要新鲜、未见过的数据，或者在某些情况下，评估必须使用模型应用的实时部分进行。有时，你可能会用完这类数据。其他时候，你可能会在可能伤害他们或使公司因失去或不满的客户而蒙受经济损失的方式上对人类进行实验。没有比这更昂贵的事情了！重点是，如果你正在进行实时测试，不能在团队产生的第一个模型或所有后续模型上运行它。你对于失败的容忍度是有限的，因此评估必须选择性地、明智地进行。

请记住，为了对更广泛的数据集进行评估（该环境具有适当的安保和访问控制），可能需要在测试环境中发布。管理这一发布过程既缓慢又昂贵，即使是速度最快的 DevOps 团队也是如此。通常，一个表现优异的 DevOps 项目每天运行一到两个发布，而一个拥有快速算法甚至更快机器的数据科学家可能在一小时内就能迭代四到五个模型。如果模型需要计算量大的训练，这个等式可能会有所不同。在这种情况下，团队可能进行的实验范围会更加有限，需要处理的模型也会更少。

本章展示了完成一个 ML 项目适当评估所需付出的努力。为了做到这一点，有必要描述你的团队通常需要应用的不同测试实践和流程。重要的是强调，你不需要在每个项目中应用所有这些测试。你将完全使用离线流程（第 8.2 节）测试一些项目，而其他项目将严重依赖在线测试（第 8.2.3 节）。对于某些项目，模型选择过程（第 8.3 节）可能非常简单。定性选择（8.3.3）和校准（8.3.4）可能根本不会在许多你团队必须交付的项目中发挥作用。

重要的是，你对可能进行的测试类型以及哪些人可以与团队中专注于将其视为技术问题的成员一起工作有一个概念。同样重要的是，测试和流程要有良好的文档记录，并且可以重现。这可以确定需要投入多少努力，并有助于做出选择测试流程的决定。第一步是了解对项目有用的测试流程，这正是下一节要介绍的内容。

8.2 测试流程

本节描述了测试机器学习模型的不同方法。总的来说，这些方法的要点是测试自动化和结构化流程将为您的模型带来信心和责任。您以系统化方式生成的证据，如果模型在下游出现问题时，将保护您和团队，并能够创建满足生产工程团队、运营团队、最终用户和监管机构等利益相关者的文档。

让我们重新熟悉一下测试我们模型的三个第二阶段任务。

测试设计票据：S2.4

• 实施并启用测试环境。

• 确定测试模型功能的过程，包括您将如何创建测试数据以及您将如何管理避免数据泄露。

测试设计票据：S2.5

• 制定一套测试来评估模型的性能。

• 确定在测试场景中要使用的度量标准。

• 设计和构建一个合适的测试环境以支持敏捷和可重复的测试。

测试设计票据：S2.6

• 测试非功能性特性。

8.2.1 离线测试

离线测试使用专门收集并保留用于此过程的模型和数据运行。项目可用的数据分为训练集和测试集。这些分割取决于团队可用的数据量及其质量。例如，您可能能够使用 70%的数据进行训练，30%的数据进行测试。训练数据进一步分为训练集（用于向算法展示并用于学习模型）和验证集或保留集。

到目前为止，建模团队的数据科学家已经使用训练集或训练流中的保留数据来估计性能，这些数据是为开发环境创建的。在项目的测试阶段，使用在建模过程中团队无法获得的数据来测试模型非常重要。这可以避免该数据的信息泄露到建模过程中。团队在模型开发迭代过程中的决策可能导致他们从新数据中优化模型的性能。因为他们想要获得最佳测试性能，所以他们应该选择最适合该测试数据的算法和流程。然而，这并不能排除在最终测试时出现误导性结果，这意味着当模型投入生产时，其表现不佳。通过确保测试过程中的数据完全未见过，您可以避免这种无意识的优化问题。

交叉验证是简单测试/训练分割的替代方法。在这个过程中，整个数据集被分成几个不相交的测试/训练集。对于 10 折交叉验证，数据集被分成 10 个集合，其中 9 个用于训练，1 个用于测试。例如，表 8.1 使用的数据集被分成 8 个集合。集合 1 有测试集 P1 和训练集 P2 到 P8。集合 2 使用 P2 作为测试集，其他分区（包括 P1 但不包括 P2）作为训练集。

表 8.1 生成交叉验证集

	P1	P2	P3	P4	P5	P6	P7	P8
集合 1	测试	训练	训练	训练	训练	训练	训练	训练
集合 2	训练	测试	训练	训练	训练	训练	训练	训练
集合 3	训练	训练	测试	训练	训练	训练	训练	训练
集合 4	训练	训练	训练	测试	训练	训练	训练	训练
集合 5	训练	训练	训练	训练	测试	训练	训练	训练
集合 6	训练	训练	训练	训练	训练	测试	训练	训练
集合 7	训练	训练	训练	训练	训练	训练	测试	训练
集合 8	训练	训练	训练	训练	训练	训练	训练	测试

对于每个分区，您将使用训练管道使用训练集（这意味着集合 1 的 P2、P3、...、P8）创建一个模型，并使用相关的测试集（集合 1 的 P1，集合 2 的 P2，依此类推）进行测试。每个生成的模型的性能被汇总并用于创建交叉验证分数。

在极端情况下，测试集可以是整体集中的一个示例，其余示例用于训练模型。对于一个有 1,000 个示例的数据集，您将训练和评估 1,000 个模型。这被称为留一法交叉验证或n-折交叉验证。

交叉验证是在处理简单模型和小数据集时的一种合适方法。当训练数据稀疏时，它可以估计使用所有可用资源创建的模型性能。然而，当处理复杂模型和大数据集（或两者兼具）时，计算成本很高。

来自机器学习社区之外的一些人反对使用交叉验证，有时他们认为这是没有根据和不合原则的。这是一个公正的批评，但就像统计学中相当一部分实践（例如，将值p为 0.05 宣布为具有显著性）也是没有根据和不合原则的。如果您使用交叉验证来提供评估指标，并且清楚地了解您正在做什么，那么您只是在展示选择过程中的一个特定结果的事实。这样做并没有什么不妥。

将可用于测试的数据分区只是生成可重复和可靠的离线环境测试结果所需的过程之一。然而，手动实施这些过程会变得繁琐且容易出错。今天的机器学习项目可能需要评估大量模型，而糟糕的环境可能会迅速变得难以承受。如果是这种情况，投资于自动化和健壮的测试系统是值得的。

8.2.2 离线测试环境

在前面的章节中，我们完成了对测试环境设施的规划工作，确定了创建它所需的工作范围，并决定了需要使用的方案。现在，确保这些元素处于服务状态并利用它们推进项目是关键。所需采取的行动包括：

1. 获取对测试环境的访问权限；获取所需的凭证和权限。

2. 将测试基础设施部署到测试环境中。这包括：

   • 数据管道。

   • 测试工具/模拟应用程序。

   • 用于测试的选定模型和相关工件。

   • 数据收集和反馈收集。

3. 确保所有必需的组件都处于功能状态（例如，校准/烟雾测试）。

4. 运行管道以使用数据和其它所需组件（例如，初始化权重/迁移模型）来激活环境。

5. 执行测试并收集结果。

这是一个相当复杂的过程，在执行这些步骤时可能会出现很多问题。很容易犯愚蠢的错误，无法正确运行烟雾测试，或者管道元素运行顺序错误。如果发生这种情况，测试的完整性就会受损，并会产生怀疑。正因为如此，现在通常会将整个过程脚本化或自动化。让我们看看实现这一目标的一些方法。

你可以使用简单的 shell 脚本来复制文件并在将要运行进程的机器上调用命令。然而，由于现代测试和生产环境的复杂性以及管理复杂脚本过程所带来的挑战，这意味着使用共享的脚本引擎是更可取的。你通常可以在与客户的不同项目中共享这个引擎，并成为客户架构团队管理部署到测试和生产环境的单一已知点。

你选择的引擎可以是 Airflow 或用于实现数据管道 DAGs（有向无环图）的系统之一。通常，这些系统运行任意脚本命令以调用基础设施即代码（IaC）或函数执行来复制文件和启动可执行文件。由于 CI/CD（持续集成/持续交付）实践已经独立发展，因此有几个有效且流行的工具可以作为替代方案。这个领域正在迅速发展，但目前，GitHub Actions 和 Jenkins 都是潜在的选择。实际上，客户的组织可能强制要求使用其中之一作为将构建推送到测试环境，然后推送到生产环境的机制。

在大多数软件工程环境中，测试和 QA 环境与开发和生产环境是隔离的。这是因为软件构建的更改可以由 QA 团队控制，以正确记录和管理软件元素。在机器学习项目中，考虑对个人保密或商业敏感的数据和模型的可访问性也很重要。扩展团队可能不需要访问医疗记录或图像来测试他们的代码，或者至少他们可能只需要有限的部分。在最坏的情况下，扩展团队可能会将真实的医疗图像发布到社交媒体上，导致你们所有人都会入狱。这些限制意味着使用分区测试环境可能很方便，或者可能有必要使用该测试环境，因为这是唯一可以获取敏感数据的地方。

基于此，测试管道实现有三种场景。图 8.1 说明了这些场景。首先，在场景（a）中，我们在整个团队之间共享测试管道，并使用模型的最新版本作为标准集成测试的一部分（就像 CI/CD 管道中的任何组件一样）。

第二，在场景（b）中，我们维护一个独立的测试管道，以便系统工程团队能够测试和发布模型的版本进行集成测试。这个管道需要人工数据和模拟生产模型行为的虚拟模型。在这种情况下，我们在适当的网络安全区域内部维护一个包含保密数据和敏感模型的集成测试管道。UI 和其他支持代码与模型交互，向其提供参数，并从其输出中恢复结果以向用户展示。

第三，场景（c）将系统测试和集成测试从非保密环境推进到保密测试环境。这比我们的第二个场景，选项（b）要好得多，因为它允许在发布到生产之前进行更多的集成测试。

图 8.1 三种不同的生产流程。选项(a)提供了一个单一的安全环境，其中工件从开发到测试，然后到生产。在(b)中，有一个独立的机密流程，无法从某些其他环境中访问，并且组件从受保护的环境和机密环境中提升到生产。更理想的情况是(c)，其中我们在组件提升到机密环境后进行集成测试。

8.2.3 在线测试

在线测试是在真实世界事件上对系统进行的一次实际运行。在医学领域，这是评估药物或程序性能的黄金标准方法。在临床试验中，患者接受治疗以观察其是否有效。在某些应用中，这种测试是可取的，因为应用领域可以发展得非常快，以至于离线测试活动会在过程中引入过多的延迟，导致有效的模型无法收集和部署。此外，正如在医学领域一样，有些领域不适合进行离线测试，社区不会接受任何在野外未收集到的结果。让我们来看看你和你团队可能想要考虑的三个常用的在线测试流程。

8.2.4 现场试验

对于模型来说，最简单但也是最难的在线测试是在现场试验中使用。现场试验是对一小群用户进行模型的有管理部署。例如，模型可能被试验用于一个办公室或部门，可能是一个小部门，或者是一个友好且技术熟练的团队。通常，考虑在模型成功可能性最高且灾难发生可能性最低的地方进行试验。

预计团队将密切监控模型及其轨迹的行为。在某些情况下，他们需要检查和验证所使用的模型每一个示例，以确保不会发生任何危险的事情。显然，这个版本的模型需要扩大到生产部署，但现场试验的目的有两个：

• 为了建立对模型行为的信心

• 为了收集关于其行为和性能的详细信息

对于团队来说，审查模型的行为并与用户一起讨论，以及采访用户群体以收集他们对模型性能的反馈，也是非常重要的。现场试验的优势在于它提供了关于模型效用信息，但也有一些缺点。

设计和实施产生令人信服结果的现场试验很困难。选择试验中一小部分受控受试者的必要性意味着结果可能无法推广到生产中需要的其他应用领域。然而，现场试验最重要的缺点是它们开发成本高且实施缓慢。现场试验可能为项目的时间表增加数月。对于高价值项目来说，这很好，成功现场试验提供的保证和信心正是你所需要的。幸运的是，即使你负担不起进行全面现场试验的费用和时间，你还可以使用其他在线测试来衡量模型的表现。

8.2.5 A/B 测试

A/B 测试将模型置于比我们看到的现场试验更为受限的生产场景中。一小部分受控的真实案例被呈现给模型，模型产生的决策实际上被用于这些案例；这是 A 组。然后，将 A 组中看到的成果和进展与 B 组进行比较。B 组是所有尚未使用此模型处理的案例。这就像验证临床试验所使用的流程，其中盲组不接受任何治疗，或接受旧的治疗，而新治疗的结果被用来评估它是否有效。

A/B 测试的一个巨大优势是它是一个现实世界的实验。数据是在领域内的新抽取，评估标准是控制。这样的实验提供了强大的因果信息，因为由于巧合、优化或数据泄露导致的性能提升被排除在外。结果与模型的实际特征紧密相关。

然而，A/B 测试在多个方面存在问题。最明显的问题，可能难以克服，是业务流程中通常没有基础设施来允许进行干预和实施所需的测试设置和运行。创建第 8.2 节中概述的测试环境在技术上或商业上是不可能的。这可能是因为技术限制或政策限制，例如安全要求，或者可能是因为某些物理、法律或伦理障碍阻止根据测试协议选择受试者。

即使假设可以实施 A/B 测试，它也会将商业机会或交易暴露于不良待遇之下（例如，如果新模型是最好的，而对照组却受到了不公平的对待，或者如果新模型很糟糕，那么暴露组也受到了不公平的对待）。在医学领域，通过考虑在可能无限的未来中未能收集到关于治疗性能的适当知识这一伦理考量，来克服这一挑战。基本上，实验中一半的人为了其他人的利益而牺牲，没有这种牺牲，就不会有任何进步。这可能是有理有据且符合伦理的，但说服一个企业主允许 AI 团队对其客户进行实验可能会很具挑战性。

考虑到 A/B 测试是可行的，并且企业主已经相信其价值，这种策略仍然面临着挑战，即它可能是一个缓慢收集模型信息的方式。使用 A/B 测试创建的模型评估数据非常有说服力。它具有高度的统计完整性，并且通常很容易向利益相关者传达 A/B 测试的结果。然而，设置 A/B 测试既昂贵又具有挑战性，并且需要时间在业务流程中的流量上运行测试。有时，A/B 测试可能需要在商业周期内持续进行，例如交易日或运营季度，以便模型能够接触到代表性的示例和条件。多臂老丨虎丨机是一种替代方法，旨在克服这些挑战之一。

8.2.6 多臂老丨虎丨机（MABs）

多臂老丨虎丨机（MAB）[5]旨在比 A/B 测试更高效和成本效益。其基本思想是只有在测试可能从中学习到有用信息的情况下才进行测试。这意味着你可以利用这个机会与你的用户互动，构建比进行表现不佳的 A/B 测试时可能构建的更有效的模型。一个 MAB 应该能够快速检测到模型毫无希望，并限制其在实际过程中的有用性。

想象一个场景，你拥有三个流程，并想知道它们是否会返回奖励。其中一个是经常给予奖励，另一个有时给予奖励，而另一个则从不给予奖励。图 8.2 展示了三个机器以及当你尝试它们时它们给出的支付。

图 8.2 展示了三个单臂老丨虎丨机及其支付记录，其中每个方块代表一次拉动。浅色记录表示零奖励，深色记录表示正奖励。机器 A 经常支付，机器 B 偶尔支付，机器 C 从不支付。

注意，机器 C 只有两条支付记录。这是因为 A 和 B 在第二次拉动时都产生了奖励。我们知道只有一台机器是坏的，而且我们知道 A 和 B 是支付奖励的，那么我们为什么还想往 C 里投入更多钱呢？

第二次拉动之后的问题是，哪台机器，A 还是 B，支付得最好？在图中，第四次拉动时，机器 B 未能支付，第五次拉动时，机器 A 也未能支付。到第六次拉动时，我们从机器 B 那里有 4/6 次失败，从机器 A 那里有 2/6 次失败，因此我们决定停止向机器 B 投入资金。我们的决定得到了证实，因为机器 A 一直在支付。

很容易看出，如果你正在向不同的单臂老丨虎丨机投入资金，总会有一个点，投入资金到一台机器去查看支付结果就不再合理。这是一个平衡探索与利用的问题：哪台机器支付，我们能从中获得多少？

我们可以利用这个理论来评估在生产环境中或在受控测试中使用的机器学习模型。关于模型性能的信息可以通过两种方式收集：显式和隐式。

显式反馈的一个例子是客户购买推荐商品的频率。如果客户更频繁地选择一个模型推荐的商品，那么这是一个很好的信号，表明这个模型更有效。推荐系统的明确目标是创造销售，我们可以或多或少直接地衡量结果。

相比之下，隐式机制（有时称为代理测量）类似于用户在网站上花费的时间量。关于在网站上花费时间的阅读是，用户正在享受他们所参与的内容的消费。或者，也可能用户感到沮丧，找不到他们需要的内容。在这种情况下，可用的反馈提供了关于模型成功与否的指示，但并不直接测量它。

一旦性能测量的机制变得清晰，那么你需要一种方法来利用它。大量的系统文献提供了算法，这些算法关于何时放弃特定模型（或老丨虎丨机）做出最优选择[3]。ε家族的简单近似方法是一种简单而有效的方法来实现老丨虎丨机风格的在线评估系统[4]。

最简单的ε基本算法跟踪所有机器的性能，90%的时间选择表现最好的机器（90% / 0.9 是ε，ε），然后 10%的时间选择一个不同的机器作为探索性测试（1 − ε）。这可以通过在ε设置为 1 之前指定几个试验来细化，或者通过指定一个衰减因子来调整每次试验中的ε（例如，ε^(‘)= 0.99 * ε）。这种策略和更复杂的ε策略的优势在于它们直观、易于计算，并且以相对较低的成本（不是很多与不良模型进行的实验）产生低错误概率（选择错误模型）的结果。

作为模型评估者，使用多臂老丨虎丨机（MABs）进行的测试与在新鲜测试集或 A/B 测试上进行的老式评估之间存在很大差异。为测试机器学习（ML）算法设置 MAB 系统提供了强有力的证据，表明正在测试的算法之一比其他算法更成功，但它不会提供关于这种优势多少的有用量化。

多臂老丨虎丨机（MABs）可以被视为机器学习算法，因为它们学习哪个机器（或预言者）最好，并且可以以这种方式制定，以便随着领域的变化动态选择模型。尽管 MABs 不会为模型选择团队提供统计数据，但它们确实具有很高的完整性。基于 MAB 的测试不易受到信息泄露的影响，并且团队很难在面对模型性能、默认或经过充分测试的现有解决方案时欺骗自己关于模型的力量。要么创新模型获胜并在系统中占据主导地位，要么它将被令人失望但有效的传统替代方案所取代。

8.2.7 非功能性测试

模型的非功能性特性是明显的测试目标，这些测试的结果可以极大地影响模型选择。那些在功能测试中表现良好的高度功能性模型（即表现良好的模型）如果未能满足客户非功能性需求，可能会被废弃。在机器学习系统中，非功能性需求值得关注，因为机器学习模型通常运行数百万或数千万次，并且经常与用户界面中时间敏感的过程一起调用。昂贵的机器学习模型可能会迅速消耗你的资源，而缓慢的机器学习模型可能会让所有用户感到烦恼。

研究这一主题的一个例子突出了一些有用的非功能性特性进行测试[2]。测试性、数据访问、灵活性和完整性是论文中发现的几个要求。Habibullah 和 Horkoff 指出[2]：

...表明工程师和客户在机器学习非功能性需求（NFRs）方面缺乏知识和专业知识。缺乏文档、方法和基准来定义和衡量机器学习软件的非功能性需求。

在项目/预售阶段，你和团队收集了非功能性需求。非功能性需求包括：

• 延迟：模型实例运行并返回结果所需的时间。

• 吞吐量：在特定时间段内在可用硬件上可以运行多少个模型执行场景。这不同于延迟期，原因有几个：

• • 可能是模型在第一次执行时启动较慢。

  • 可能存在高度并行的硬件来运行模型，因此即使单个模型每秒只能执行一个场景，十个并行运行的模型也能达到大约九个的吞吐量。

• 内存足迹: 现代机器学习模型可能很大，并且可能需要昂贵的快速内存来运行。确定模型的大小对于确定它们是否可以实际部署很重要。

• 成本: 需要使用许可子组件的模型可能很昂贵。

• 碳足迹: 运行某些模型会产生很大的碳足迹。

在列出的非功能性度量中，内存足迹和成本最容易评估。创建组件及其规模的清单应该没有困难。延迟和吞吐量度量仅在反映生产条件的测试工具中才是准确的。

您的模型的相对性能可能足以影响您的决策。然而，您和客户必须意识到，这种方法存在重大风险。模型在新硬件上可能会以意想不到的方式表现，因此请警惕不要依赖于线性扩展并行性。在模型服务系统中，下游瓶颈很常见，这可能导致扩展系统停滞。即使是像电源限制或服务器机架过热等平凡问题也可能导致高性能受限。因此，在现实硬件上进行持续测试是确保您的系统按您所需的方式运行的唯一方法。

碳足迹的测试和测量甚至更困难。您可以使用代码和系统的仪器机制来达到这个目的 (codecarbon.io/)。不幸的是，生产中的机器学习模型通常有很多组件，如数据库、网络接口和加速器，这些可能不会被特定类型的仪器覆盖。这可能导致病态情况，团队通过将处理卸载到效率更低但不在仪器内部的子系统来优化代码以降低碳强度。

在模型离线或在线测试中创建和获得的功能性度量以及本节讨论的非功能性度量提供了关于您应该选择和使用哪些模型的信息。尽管如此，仍需使用这些信息做出决定，而做出这个决定是下一节的主题。

8.3 模型选择

模型选择票：S2.10

• 使用模型评估数据来确定要使用的模型。

• 使用显式机制来使用模型测试/评估数据来选择要在生产中使用的模型。

• 考虑模型在您的决策中将如何结合。

• 考虑非功能性需求。

• 考虑模型的质量方面。

模型选择票：S2.11

• 确定并记录模型选择。

模型选择票：S2.12

• 审查并获得客户对模型选择的批准。

测试和评估为模型性能提供了信息；然而，这些信息需要用来确定要使用哪个模型。在过去的美好时光里，选择一个单一模型，在理解良好的环境中使用，是直截了当的；结果最好的模型就赢了！现在，机器学习模型通常被应用于复杂的系统和配置中，仅基于单一测试的结果来选择模型很少是合适的。相反，必须生成、收集关于模型性能的所有信息，并将其综合成一个决策。部署系统的利益相关者需要了解你为什么选择这些组件，因此你需要记录为什么做出的选择是合适的以及如何做出这些选择。而本章的前几部分讨论了如何生成和收集测试结果，本节将探讨如何将这些信息综合成一个决策。

现在我们有三种类型的信息。首先，我们从测试事件中积累了一系列结果，其次，我们有关于测试机制和实践的信息。最后，我们有关于我们系统需求的信息。有了这些信息，我们可以根据测试结果确定模型的质量，决定这些结果的质量和信息量，然后判断每个结果的重要性。将这些信息综合成一个关于使用（或不使用）哪个模型的决策或建议可以通过多种不同的工具来实现。有两种基本方法：

• 我们可以定量地汇总信息，以满足某种关于哪个模型最优的观念。

• 我们可以使用行政/定性过程来从一组模型中筛选出适合使用的模型。

非常可能你需要同时使用这两种过程。定量数据可以被用来产生适合定性选择的候选者。重要的是，用于选择的资料和过程必须仔细汇编并记录——你和团队决定的项目中适当的方案必须明确文档化并用于做出决策。这样，你将能够透明地解释模型在生产中的行为，因为你将有一个高完整性的答案来回答为什么你放置那个模型去执行那个任务？

8.3.1 定量选择

定量选择是将不同测试事件中的测量结果结合起来创建一个单一、汇总的度量，然后根据该度量选择要使用的模型的过程。在本节中，我们将探讨基于已开发的评估模型测试的三种不同场景来做出选择。

8.3.2 基于可比测试的选择

当使用几个可比较的测试来评估模型时，你可以使用简单的聚合来组合测试结果并做出选择。让我们以一个要向许多国家的人提供报价或推荐的建议模型为例。在这种情况下，感兴趣的消费者是 18-25 岁的年轻人。你可以查询 40 个国家来创建一个包含数百个测试案例的样本组，构建两个包含 40 个数据点的数据集。每个数据点是模型在特定国家的成功情况。每个国家对客户来说都同等重要。这里有一个困境：模型 A 在部分数据点上表现良好，模型 B 也是如此。哪个应该被选为全球使用？

如果，像在这个例子中，选择是在由仅两个模型生成的两个结果群体之间进行，那么决定使用哪个模型可能很简单。找到平均性能和标准偏差，然后根据期望计算模型在测试中的性能差异。

如果对模型能够以相同水平表现有低期望，那么这是一个明确的指标，表明存在真正的性能差异，并且为选择一个而不是另一个建立了良好的基础，特别是如果期望是双向的。如果模型 A 的平均性能与模型 B 的平均性能相差几个标准偏差，并且 B 的结果也远离 B 的平均性能，那么 A 和 B 都在产生明显区分的结果。整体表现最好的模型是合理的选择。另一方面，如果模型 A 的平均得分更高，但模型 B 的结果的标准偏差包括模型 A 的平均值，那么显然可能不存在 A 和 B 之间的真正差异。

这些决策也可以用贝叶斯术语来表述：看看模型 A 的性能样本和模型 B 的性能样本是否来自同一分布。如果期望是模型 B 的平均性能很少由模型 A 的结果子集实现，那么模型 B 可能优于模型 A。相反，如果模型 A 的结果有共同排列，可以达到与模型 B 相同的性能，那么测试可能没有结论。

你需要多少惊喜程度才能确信模型 A 和模型 B 确实不同，这是一个由你决定的问题。一般来说，人们会选择相信，如果 95%的时间里从模型 A 和模型 B 的分布中抽取的样本是不同的，那么这意味着我们应该相信模型 A 和模型 B 有不同的分布，因此，模型有不同的行为。

然而，使用这个用例时，也存在问题。每个国家的群体可能不同，以及每个国家的经济和人口分布。有时，可以使用归一化来处理这个问题。在多国比较的情况下，这可能对于像电子商务这样的东西是可接受的。然而，在比较像流行病流行率或不同疫苗的性能时，可能很难自信地说归一化和直接比较是处理这些数据并做出推论的安全方式。如果是这样，或者如果测试更明显地不同且不可比较，那么我们需要不同的方法来将测试信息汇总到决策中。

8.3.3 使用多个测试进行选择

多次测量的汇总方式可能会影响所做的选择。你提出的测试计划产生不同的性能指标是自然而然的（也可能是必然的）。例如，如果你为硬而重要的例子创建一个单独的测试集，然后简单地汇总模型的性能，那么在普通数据上的性能就会使最初做这件事的意义化为乌有。

这个问题在许多领域都得到了广泛研究，被称为多标准决策制定 [6]。你可以使用许多方法来汇总不同且不可比较的测试结果。没有哪一种方法可以肯定是“正确”的选择，但每种方法都有不同的优势，可能在每种情况下都是最佳选择。一种方法是用加权函数来优先考虑并偏袒测试结果向量中的特定成员。简单来说，决定一个模型的总体分数中，一定比例来自一个测试，另一部分来自第二个测试，依此类推，直到 100%的指标被分配。

在硬而重要（hbi）项目与普通数据（rotm）的例子中，选择可能是 50/50。假设测试集中使用了 200 个精心挑选的 hbi 和 200,000 个 rotm，但我们把每个 hbi 的重要性视为 rotm 的 1,000 倍，对于模型选择来说。然而，这种方法存在一些问题。选定的权重是任意的，事后难以解释。hbi 性能的微小变化会超过 rotm 的较大变化，这是有意为之。另一方面，一旦超过两三个指标，就很难辨别模型性能比较中的来源。

更复杂的分配权重方法可以帮助。例如，我们可以定义一个函数，根据某些最优分配在更严格的基础上分配权重，或者根据对平衡如何工作的语言描述提供权重。有时这些方法可以提供良好的结果或清晰的解释，但通常它们会在过程中增加另一层神秘感。

一种流行的替代方案是将性能排名而不是原始结果结合起来。回到简单的 hbi 和 rotm 场景，让我们用这个视角比较五个模型。表 8.2 显示了这次比较的结果。

表 8.2 比较五个模型的综合排名

模型	hbi（原始）	hbi（排名）	rotm（原始）	rotm（排名）	综合得分	排名
A	171/200	3	175342/200000	2	5	3
B	167/200	4	172811/200000	4	8	4
C	132/200	5	135241/200000	5	10	5
D	173/200	2	181122/200000	1	3	1
E	190/200	1	175301/200000	3	4	2

观察结果，模型 D 是赢家！它在 hbi 测试中排名第二，在 rotm 测试中排名第一，而模型 E 在 hbi 测试中排名第一，但在 rotm 测试中排名第三。对模型 E 使用 50/50 的权重，得到 365,301 与模型 D 的 354,122 相比，所以我们会选择方法 E。排名综合并不是本质上更好，但它产生的结果是利益相关者可以直观理解的，并且当你必须组合更多独立测试时，它通常更有用。

作为表 8.2 中综合排名的替代方案，有时可以使用帕累托最优性的概念来做出模型选择的决策。一组帕累托有效的模型是包含所有在一个度量下具有最佳结果的模型的集合。在有平局（在某个测试下几个模型具有相同或广泛相似的性能）的情况下，选择在其他维度上表现最好的模型。

在图 8.3 中，我们可以看到使用 hbi 和 rotm 测试集评估的想象模型的一些结果。虚线内部包含模型的帕累托前沿。这个区域内的所有模型在 hbi 和 rotm 之间的权衡都是我们找到的最佳权衡之一。请注意，模型 F 在帕累托集中，但模型 G 不在，因为它在 hbi 或 rotm 方面都不如模型 F 好。这种双重打击使其无法被考虑。

图 8.3 从硬而重要（hbi）和普通（rotm）数据集评估的模型的帕累托前沿

我们可以使用帕累托集和帕累托前沿来创建与许多不同测试的帕累托最优候选集，而不仅仅是两个，但帕累托集仍然为更多的决策留下了空间。创建帕累托集缩小了候选范围，但它仍然经常需要在集合成员之间做出选择。

8.3.4 定性选择措施

在本章的引言中，确定了一些来自文献的定性指标。这些包括：

• 模型安全性: 模型是否可以被欺骗或智能攻击？对其工作方式的知识是否会被滥用？一个很好的例子是，图像中微小的变化，人类肉眼无法察觉，却可以使模型自信地错误地标记它。这会对滥用交通标志来欺骗自动驾驶汽车或更改护照照片以允许图像在检查员看来与持证人匹配，而在机器中输入时与另一个人匹配造成影响。

• 隐私: 模型是否会泄露信息？如果给它提供提示，是否可以从模型中提取个人信息？例如，让我们想象一个语言模型是在医疗案例上训练的，以提供有用的聊天机器人（这是一个坏主意，但也是一个例子，所以请耐心）。在这种情况下，如果我提供一个提示，比如西蒙·G·汤普森医生的病历，出生日期 xxx...，会发生什么？模型是否会通过重复一些私人信息来完成提示？尽管这在我的情况下可能很无聊，但在其他情况下可能会造成伤害，甚至可能造成重大伤害。这也会在许多地方严重违反数据保护法。

• 公平性: 模型是否包含来自数据的有害或被常识或更广泛领域知识驳斥的偏见？著名的是，一些语言模型假设所有医生都是男性，而护士是女性。这种刻板印象可能会对求职者造成重大伤害。

• 可解释性: 模型是否可以被人类检查或解释？解释是否与模型的实际工作原理相符？是否可以用它来确定模型的操作是建立在坚实基础上的，而不是仅仅由于任意数据规律？

我们在用户故事和与利益相关者的开发活动中明确提到了一些这些要求。其中一些要求，如安全性、隐私性和公平性是底线；如果你的模型不符合这些要求，那么它们就不能被使用。模型的可解释性并不是那么明确，不同的模型可能以不同的方式高效且可解释。可能的情况是，你在项目早期阶段组装的要求不能一次性全部满足。再次强调，在某些情况下，这可能是项目的硬性停止点，但可能有一个不那么可解释的模型可以满足非功能性性能要求。有时，为了非功能性性能而牺牲可解释性可能是合适的。

在本章关于多标准决策制定的讨论以及关于适当使用排名方法和加权数据集等的纠结之后，这种讨论令人沮丧地不精确。基于纯粹美学考虑选择模型的原因甚至更加模糊。

有些人可能认为这种立场相当不合理；当然应该优先选择在数量上获胜的模型？但是，自大约 1200 年以来，西方科学一直使用奥卡姆剃刀的理念来偏好更简单的模型，在所有事物大致相等的情况下。在寻求好的理论时，美丽和优雅是数学家的驱动力。在机器学习模型方面，这转化为对低尺寸和高压缩率的偏好，相对于训练集而言，或者简单地说，是优化了等效或近似等效性能的参数数量更少。当有疑问时，简单和甜美总是胜出。

8.4 模型后检查清单

Sprint 2 几乎完成。最后的任务是运行表 8.3 中的检查清单，确保每个人都同意一切已适当完成。如果是这样，那么你可以有信心，你的团队已经创建了一套坚实的模型，并且有一套良好的文档记录的候选集用于应用集成。

表 8.3 Sprint 2 检查清单

Ticket #	项目	备注
S2.1	实现了特征工程。	记录了特征和设计信息。
S2.2	明确要使用的模型已设计。	模型设计已记录。
S2.3	执行了建模过程并开发了模型。	使用了模型存储库；识别并捕获了模型以及所有用于复制的详细信息。
S2.4	团队对开发中的模型性能进行了适当的评估，并记录了实验结果。	实验结果可供检查。
S2.5	在开发中发现的模型问题已记录。	缺陷通常会在开发过程中被发现；请检查这些是否已记录，并且文档是可用的。
S2.6	测试环境已投入使用。	测试环境已搭建，并提供了测试所需的数据源。
S2.7	设计了适当的测试。	确定模型是否适合目的的测试已达成一致并记录在案。
S2.8	已收集测试数据。	在测试环境中运行测试，收集结果并可供评估。
S2.9	模型选择已记录。	模型选择方法已记录，使用它们时所做的决策以及测试数据已记录。决策中的定性因素应记录并达成一致。

再次强调，如果在应用程序集成过程中发现新的问题或限制，可能需要重新审视测试过程。有可能，甚至很可能，团队需要回到冲刺 1 的活动中进行重新调查数据。可能，他们需要引入新的数据来源，或者他们需要纠正和清理新的数据来源的错误。冲刺 1 和冲刺 2 中使用的流程和基础设施为团队提供了良好的框架来完成这项工作。你已经做出了投资，使你的团队能够灵活应对问题，不要害怕利用它！

然而，跳过记录正在发生的事情并不是一个好的想法或可接受的做法。迭代和适应是不可避免的，但请确保团队对此保持透明，并且他们在重建管道和流程、重新运行测试以及保持文档更新方面是专业的。

8.5 Bike Shop：冲刺 2

模型团队面临两个核心挑战：构建客户流失预测系统和构建需求预测系统。冲刺 1 的工作表明，这些模型应该具有地理和产品类型粒度。模型应该构建成能够在不同的地区和不同的产品类型和平台上工作。此外，还有一个挑战是验证可用数据是否足够用于建模。团队知道他们必须通过非功能信息来深化这些要求，以便能够选择合适的建模技术。团队确定了以下：

• 在 Bike Shop 应用程序中，效率和吞吐量不太可能成为问题。只有少数用户会期望正常的 Web 应用程序延迟（大约 2 秒）。

• 推理成本不太可能成为问题。Bike Shop 应用程序将由成百上千的用户使用，而不是可能引起担忧的数万人。用户将以业务分析的速度操作，因此每分钟可以期望有二到三次模型更新。

• 安全性将遵循正常的公司标准。因为只有有权访问原始数据（来自销售记录的财务和业务绩效）的用户才能访问模型和模型输出，因此无需担心可以得出的推断。

• 模型需要提供置信区间，系统需要参数化模型，以便用户可以反事实地使用它们。这使用户能够尝试“如果”场景，并允许系统向用户展示一系列预构建的场景，以帮助他们做出决策。

• 系统应提供性能监控。这允许自行车商店跟踪其表现如何，并让用户对系统的性能提供反馈。用户可以表明他们认为模型正在做出严重的预测。如果这成为一个问题，可以引入一个专业团队进行维护。

在审查了由 EDA 练习创建的商业领域专家收集的信息后，团队现在认为他们已经理解了建模的期望。现在可以将这种理解结合起来，以创建整体模型的设计。

在预售过程中，确定了将开源新闻和经济数据与自行车商店数据相结合的机会。此外，团队在冲刺 1 中识别并选择了一个语言模型，并将其作为项目资产锁定。鉴于这一点，团队决定创建模型，以提取新闻的当前情绪、其异常性（作为风险的代理），以及相关销售区域经济数据的销售历史模式。决定在每个地区使用相同的模型设计进行需求预测。将每个地区的数据与新闻源和经济数据相结合，团队创建了一个个体实例化的模型。团队决定他们将使用标准技术来预测不确定性范围，本质上是在每个步骤上乘以不确定性。图 8.4 展示了这种设计。

图 8.4 预测自行车商店需求的顶级模型设计

由于新闻数据集的限制，决定创建将独立输入到应用所需推理中的信号。实际上，每个区域预测系统都需要以下三个组件模型。图 8.5 说明了训练模型的设计：

• 一个新闻情绪指标，用于从可用的新闻源中提取当前的情绪。

• 一个新闻异常检测器，用于确定新闻源中是否检测到令人震惊或非常不寻常的事件。

• 一个销售给定经济模型，该模型学习经济状态下的销售模式。

图 8.5 自行车商店需求预测系统的模型训练设计

团队进行原型设计活动，以开发每个模型中使用的特征集（图 8.4 和 8.5）。由于美国拥有丰富的数据并且对 The Bike Shop 的业务具有重要意义，因此将其选为代表性区域。团队认为，如果无法为该区域创建良好的模型，那么在其他区域的工作可能不会成功。相反，如果他们为美国区域创建了一个良好的模型，那么即使其他区域无法建模，系统仍然具有一定的实用性。表 8.4 显示了在原型设计和迭代实验中使用可用训练数据子集以及几种模型类型后开发的特征列表。情感强度是通过使用新闻文章情感强度数据集[1]对 BERT 模型进行微调来确定的。异常检测是通过测量每篇文章相对于自动编码器（该自动编码器是在该区域的历史新闻文章上学习得到的）的重构误差来完成的。

表 8.4 从销售数据生成的特征

Feature	描述
Aggregation	聚合到每月；按客户和产品二级分组。
频率	销售频率。
月和年	月度和年度特征。
公共数据丰富化	例如，“national_income”（国家收入），“agriculture_value”（农业价值），“unemployment”（失业率），“GDP”（国内生产总值）。
标准差指标	每个客户、每月以及收入、体积和销售频率变化的标准差是多少？
Look_back	将过去 n 笔交易的数据作为特征。
last_trade	每个客户的最后交易。
ema	指数移动平均。
sma	简单移动平均。
Bollinger Band	标记案例，向上或向下超过两个标准差点。
rci	变化率指标。
rsi	相对强弱指标 .
diff	当前值与最后 n 个值的差异。

现在团队已经确定了特征集，并选择了模型类型和设计，他们可以构建一个训练流程来为每个区域创建模型。为此，他们从源表（source_table）中提取每个区域、产品平台和产品类型的数据，计算特征，并将生成的训练集传递给机器学习算法（图 8.6）。

图 8.6 The Bike Shop 的训练数据流程。

图 8.6 展示了数据准备流程。请注意，步骤 a 和 d 确保相关团队成员被通知训练数据的变更，并且新的训练数据版本被记录。在这个流程中，在发生任何其他事情之前，最后一批训练集会被存档。这支持了可重复性，并在流程中出现问题或错误引入特征噪声时，为团队提供了回滚的选项。步骤 b 生成从单个国家单个产品的销售到该地区所有销售的分组聚合，该地区特定产品平台的物品销售，以及特定产品平台在全球范围内的所有销售。

在步骤 c 中，使用 Python 代码在数据仓库中运行各种过程，以创建表 8.4 中指定的聚合特征。在某些情况下，在分组步骤之前计算这些项对于每一行来说更容易。这也可能有些尴尬，因为数据仓库可能不支持向旧表添加新列。团队进行了大量工作，以了解数据仓库和脚本系统之间最佳劳动分工。现在，训练数据已准备好供团队用于创建模型。

图 8.7 自行车店模型训练流程

图 8.7 展示了模型训练的流程。与其他流程一样，一个关键特性是流程不是静默运行的；所有步骤都在执行时被记录。步骤 c 指定执行训练集的训练和验证拟合，而在步骤 d 中，这些数据被记录在管理系统。团队创建了一个仪表板，显示模型集的训练和验证性能，以了解他们解决问题的整体方法。他们还创建了一个模型 delta 和改进列表，并开始处理这些问题。

丹麦人作为团队中的专家数据科学家带头，但 Sam 对建模工作感兴趣，所以他和 Rob 组队来处理团队生成的一些票据。他们追踪建模假设，努力获得更好的结果。Danish 和 Jenn 合作处理另一组票据，而 Kate 则处理训练管道和监控基础设施中出现的问题。在组织好自己之后，团队逐渐形成了稳定的模式。一开始有很多挫折。团队乐观地认为，更复杂的方法会迅速超越 Danish 在冲刺 1 结束时通过快速简单的基准测试获得的结果，但事情并没有像他们希望的那样顺利。

经济数据似乎对时间序列预测的质量没有贡献，新闻情感或新闻异常流也是如此。团队部分调查了模型，发现经济数据中有确切的信号，应该提供预测信息。Danish 创建了一些可视化，展示了经济影响模型输出与销售变化的相关性。

情感模型和异常模型表现出类似的行为。当 Kate 审计模型训练和执行管道时，她解决了这个谜题。她发现团队认为将为增强模型创建训练输入的模型并没有生成正在使用的特征。由于有人未能更新代码，旧的占位符代码仍然被调用。

犯罪者感到非常糟糕，但团队的其他成员也承担责任，因为代码通过了他们的审查；他们都盯着它看了三天，没有注意到错误。当代码被修复并且与基准模型相比性能显著提升时，每个人都感到无比兴奋。在这个时候，团队决定他们应该正确评估模型组合。

自行车店 IT 团队维护一个测试环境，用于在将新系统发布到生产环境之前对其进行评估。该团队在这个环境中进行测试需要少量这些设施，因此 Rob 采用了在冲刺 1 中开发的测试环境设计，并与 IT 团队合作确保其得到实施。为了确保测试得到正确执行，Rob 编写了脚本将数据管道部署到测试环境。每个被选用于评估的模型都有元数据定义了创建它们的训练管道的结构和参数化。这被用来配置测试数据管道。然而，有一些重要的变化。

团队举行会议讨论模型的性能，根据之前的讨论，他们得出结论，销售模型并没有过度预测需求。Karima 明确表示，过多的库存是利润和亏损边缘对企业真正的杀手。在库存上的过度支出意味着没有现金来支持其他活动，这意味着与此相关的成本很高。订购不足也会带来惩罚。企业无法销售它没有的东西，但如果现金未使用且可用，那么它可以采取缓解措施。Danish 和 Rob 通过数据确定哪些特征定义了订购过多的案例。他们与 Sam 合作构建了一些查询，生成由 Danish 在 EDA 中创建的基准分类器创建的测试集。

同时，Jenn 建立了一个测试集，其中包含她所说的代表性分布的干净数据。你进一步探究她所说的含义，结果发现她创建了一个包含来自三个最大国家（欧洲、亚洲和世界其他地区）的数据的测试。她选择这一选择的理由是这些是重要的市场。经过一番讨论，Jenn 同意建立一个涵盖所有领土的测试集，包括最小的国家。总的来说，这意味着模型将在以下方面进行测试：

• 数据集 1: 基准模型在预测销售期间的销售额表现

• 数据集 2: 大国的性能

• 数据集 3: 所有国家的性能

• 数据集 4: 小国的性能

Kate 构建了在测试环境中提供有效测试工具所需的剩余代码，然后 Jenn 和 Kate 在团队标记为选择候选人的模型设计上运行测试。结果很有趣。团队认为可用的所有模型在数据集 3 上的表现都大致相同。没有人感到惊讶。模型之间的相对性能与它们在开发中的相对性能相似，尽管有所降低。

在数据集 4 中，性能差异很大。结果证明，新闻成分在大国比在小国更具预测性。经过一番思考和白盒测试，原因变得清晰：大国是资金充足和资源丰富的媒体的焦点。更多的调查表明，媒体自由与新闻来源的预测能力之间也存在关系。这些见解使团队能够根据每个国家的适当性选择两个不同的模型。他们建立了一个模型到国家的映射表，并通过在 Jenn 的数据集上重新测试来展示其有效性。

在这个时候，Rob 在事情上扔了一个飞轮，指出他们在测试过程中泄露了相当多的信息。但有好消息。Jenn 可以选择三个新的小国和三个新的大国。基于这个选择，她建立了数据集 5 和数据集 6，并在这两个数据集上测试了新的复合模型。令人高兴的是，对于每个人来说，新数据集上的结果与数据集 2 和数据集 4 上的结果相匹配。然而，这一次结果有所改善。Jenn 解释说，她选择了三个强势媒体和三个弱势媒体来构建数据集 2 和数据集 4。团队继续进行第三轮冲刺。

摘要

• 你的测试环境需要满足你处理的数据的安全性和隐私要求，允许团队中合适的人访问测试机制。

• 您必须故意决定关于您模型性能的重要衡量标准。就像有时汽车的燃油经济性比其加速度更重要一样，对于不同情境下的模型，可能需要评估不同的性能测试。

• 模型准确性是理解模型性能的一个较差的方法。从模型的精确度和召回率性能或其 F1 分数来考虑模型。更好的是，考虑一系列性能指标，以获得对模型在特定测试中性能的整体看法。

• 非功能性也需要被测试和考虑，这样您就可以将这些结果与功能性性能进行比较。

• 当数据难以获取时，您可以使用交叉验证来衡量模型性能。模型可以通过 A/B 测试或多臂老丨虎丨机在实时案例上进行测试。您必须意识到测试的成本和权衡，这涉及到您在收集数据或让人们接触到实验模型的行为时所面临的限制。

• 模型选择既包括定量（使用您的测试结果）也包括定性（基于更广泛的考虑和模型美学）。

• 定量选择可能需要您比较和权衡在不同基础上进行的测试。不同的方法包括排名、多标准决策制定（MCDM）和帕累托前沿。您使用哪种方法取决于您的项目。

• 您可以通过测试模型的各个部分来揭示它们是如何失败的。您可以将模型的行为的因果理论作为您决策的一部分。

• 在选择模型和模型组件时，您通常会做出判断。重要的是您的决策基础是透明的，决策过程被记录和文档化。如果决策归结为选择 A 或 B，并且没有明确的方法让您确定哪个，请记录这一点并选择您认为最好的一个。

9 Sprint 3：系统构建和生产

本章涵盖了：

• 将你的模型嵌入到你将要构建的系统

• 处理非功能性影响

• 为生产构建数据和模型服务基础设施

• 确保用户界面是适当的

• 确保日志记录、监控和警报元素在生产中得到适当的治理和管理

在 Sprint 2 中，团队构建、测试并选择了支持 Sprint 1 中开发的故事的模型。没有更多的努力，这些模型无法用来产生价值；本质上，它们只是静止在仓库中的代码行。为了成为有用的 AI，模型需要被实施在支持客户业务流程和客户交付的 IT 架构中。

机器学习系统有两个特点，这是 Sprint 3 工作的重点，也是本章的主题。我们必须实施支持生产平台的数据基础设施，以确保模型在它们被训练的数据环境中运行。此外，我们需要检索和运行从 Sprint 2 创建的 ML 模型，以便系统可以工作。

在本章中，我们将讨论决定生产系统中需要哪些组件以及它们如何协同工作的过程。在后续章节中，我们将处理驱动数据层、模型服务基础设施和界面元素选择和交付的权衡和决策。首先，你和团队需要确定你们将要构建的机器学习系统的类型，这正是下一节要涵盖的内容。

9.1 Sprint 3 待办事项列表

表 9.1 总结了本章我们将探讨的任务。这些任务必须在项目进入生产并开始为用户创造价值之前完成。

表 9.1 Sprint 3 待办事项列表

任务编号	项目
S3.1	确定用于嵌入模型的系统类型。
S3.2	确定你正在构建的系统的功能和非功能影响。
S3.3	构建生产数据流，使模型能够进行推理。
S3.4	构建模型服务器和推理系统。
S3.5	确定系统所需的适当接口组件。
S3.6	选择一个符合接口开发方法，以便交付接口需求。
S3.7	为系统构建日志记录、监控和警报组件。
S3.8	确保模型治理和交接安排达成一致。
S3.9	制作维护和支持文档。
S3.10	制定预发布测试计划。
S3.11	推送到生产。创建发布后测试计划。
S3.12	提供发布后的认可和感谢。

图 9.1 展示了从使系统在生产中功能化的需求角度出发的机器学习系统。在顶部，有一个数据基础设施为系统提供输入。这可能包括来自用户界面的点击流或其他交互，但本质上，这些是模型进行推断所消费的信号。

图 9.1 中展示的架构使用推断服务根据数据流中的事件调用模型。此服务可能以批量模式运行，处理数据文件并为数据集中的每个实体生成注释。它也可能基于应用程序中的事件进行响应式运行。模型的输出被某些应用程序代码用于决定应该调用哪个服务。这可能只是向用户展示某些内容并据此做出另一个决定，或者将输出输入到机器的控制系统中。

图 9.1 展示了本章讨论的机器学习系统的抽象层和关注点

在图 9.1 的堆栈底层是曝光接口。除了通过发布模型推断与用户交互外，该系统还必须在这一层提供日志和管理数据（例如，在意外行为的情况下发出警报）以及为其他系统（例如编排信号）的集成信息。为了实现这一层的功能，以下是一些建议：

• 您可以使用 Big Table、Redshift、SQL Server、Oracle、Kafka 或 SPARK（以及其他许多）作为支持数据基础设施组件不同需求的数据引擎。

• 您可以使用 Kubeflow、Kubernetes、OpenShift、Flask、Tomcat 或其他引擎部署应用程序代码。无服务器组件，如 AWS Lambda、Azure 无服务器和 GCP 的云函数，提供了一种替代的托管和运行模型的方法。

• 您可以使用 Splunk 和 Grafana 等系统，以及 Angular.js 等用户界面开发框架作为曝光层。

9.2 机器学习实现类型

生产系统分析票据：S3.1

• 确定将用于嵌入模型的系统类型（辅助型、委托型、自主型）。

生产系统分析票据：S3.2

• 确定您正在构建的系统的功能和非功能影响。

为了使系统有用，您需要决定如何使用您创建的模型。在开发过程的早期，这已被考虑并进行了工作，但现在模型已经构建并选择了最佳模型用于使用。广泛地说，我们可以识别您开发的模型的三种设置类型：

• 辅助型模型：创建直接由人类消费的输出。在仪表板上总结的大量数据是一个辅助型模型。例如，如果您使用一组复杂的传感器读数来创建推荐，那么这是一个辅助型模型。

• 委托模型：创建一个独立于人类输入的控制信号，但在直接的人类监督和管理下。无论它们是否智能，由人类控制器监控的化学工厂运行系统、飞机制导系统和自动驾驶仪都是这类系统的例子。

• 自主模型：嵌入到没有人类控制或监控的系统，无论是长时间还是通过系统演化的转型。许多机器人系统和无人机是自主的，同样，在人类管理之外运行的自动高频交易系统也是自主的。

这些不同类型的系统位于自主性和人类控制的一个连续谱上。一个由机器学习驱动的系统越自主，人类控制和干预的机会就越少，但这也有其后果。用于驱动该系统的模型可靠性必须得到更高的保证，并且嵌入模型的系统工程必须更加鲁棒，并提供更高的保证。随着自主性的增加，三种设计力量作用得更强。

首先，随着系统变得更加自主，它们解释其决策的需求就越大。人类直接控制且人类对决策有代理和责任感的系统中的机器学习组件不需要像自主系统那样透明。我们可能能够理解人类控制系统中机器学习组件，但人类因素始终是模糊的。

其次，用于记录和记录系统开发过程的机制必须随着系统的自主性增加而变得更加鲁棒。部署自主系统的组织必须对其决策负责，而它只能通过有方法解释其开发过程才能做到这一点。

第三，自主系统需要更好的非功能性性能和更强的鲁棒性。如果系统突然停止或开始出现异常行为，没有人类可以介入接管。通常情况下，自主系统的用户在非功能性故障发生时，身体上无法介入或自救。

在查看第 3 个冲刺的生产系统分析票据后，你现在应该能够进行下一项任务。在本节下一部分，我们将更深入地探讨在构建使用机器学习的辅助、委托和自主系统时，你和团队必须处理的含义。

9.2.1 辅助系统：推荐器和仪表板

辅助系统旨在直接由人类使用。它们的价值由它们提供的人类检查的透明度驱动。辅助系统向人类提供建议，但它们不控制基于该信息和指导所做的决策。

辅助系统总结信息，提供预测，并使人类能够高效地消费这些信息以进行决策和创造洞察。通过使原本难以理解的信息用于创造价值，辅助人工智能系统在创造经济和科学价值方面发挥了作用，这些价值在其他情况下可能无法获得。

大型强子对撞机，一种高能粒子对撞机，是这种类型系统的良好例子。那里的实验利用了由挑战竞赛产生的机器学习技术，在庞大的数据集中寻找突破性的物理结果[2]。如果没有机器学习的这种辅助，物理界可能无法利用他们最强大的实验工具。

典型的辅助界面是仪表板。仪表板是一组可视化图表，总结了与特定业务问题相关的信息，使得快速检查成为可能。现在有各种各样的工具，包括专有工具（如 Looker、Power BI、Qlik 和 Tableau）和开源工具（如 Shiny 和 Dash），您可以使用它们来创建仪表板。

图 9.2 展示了左侧的标准仪表板与右侧的智能仪表板的对比，后者集成了由机器学习模型得出的输出。在标准仪表板中，数据通过聚合函数和选择过滤器进行转换和显示。在智能仪表板中，由于模型在信息上创建了过滤器（例如，用于去除异常值或噪声），因此会显示额外的信息，以便使用这些信息进行预测。例如，我们可以部署一个客户流失模型，该模型根据用户选择的值生成输出，以确定竞争对手的活动和销售投资。

这种预测为决策者提供了潜在或可能结果的指示。如果分布或预测中出现不希望的结果，那么客户可以通过找到使积极结果可能而消极结果不可能的参数设置来采取行动，改变方向。在客户流失的例子中，仪表板用户可能会发现，即使竞争对手的活动水平如何，增加销售投资也能创造出低客户流失率的结果。

图 9.2 左侧是一个简单的仪表板，右侧是一个智能模型驱动的仪表板

尽管图 9.2 中展示的智能仪表板集成了由机器学习模型得出的输出，但这并不是唯一可用的辅助系统类型。许多互联网服务使用辅助智能来增强他们提供的用户体验。服务和可用优惠的多样性和规模常常让消费者感到困惑，有时在没有支持的情况下几乎无法导航。我们可以使用机器学习来提供推荐和选择，从用户界面中过滤掉不相关的结果，并将用户的注意力引导到更具吸引力的选择上。

例如，你可以通过使用共现矩阵来实现一个推荐系统。你会将项目分类成组以控制矩阵的大小，然后在用户做出选择时增加共现的值。当用户在未来选择一个类似的项目时，你可以使用最高值的共现来生成一个能够激发用户兴趣的推荐。

假设西蒙观看了星球大战，然后是较新的星际迷航电影。较新的星际迷航电影被归类为科幻重启。当其他人观看异形等电影时，你可以向他们展示包含星际迷航、沙丘、猿人星球黎明、疯狂的麦克斯：狂暴之路等电影的科幻重启列表。表 9.2 展示了这种表示方式以及经过一次更新后，在众多设计假设下的样子。类别是预先选择的（任意选择），不允许自我相似。因为表格不记录同一类别的选择，所以算法总是推荐一个不同的列表。此外，没有提及如果处理的是自然类别的选择时应该怎么做。你是提供随机列表供选择，还是不提供列表？

表 9.2：观看星球大战后对电影的共现表更新，并偏好科幻重启电影。

类别	旧科幻	自然	…	科幻重启
旧科幻	X	0	0	1
自然	0	X	0	0
…	0	0	X	0
科幻重启	1	0	0	X

现在，让我们进一步探讨这个系统。如果我们随机从推荐列表中选择一个项目，然后展示给用户作为他们下一部电影，那么我们可以说用户已经将选择权委托给了系统。系统变成了委托系统，这在下一节中会讨论。

9.2.2 委托系统

我们使用委托系统代表用户在无法直接逐个案例进行控制时做出决策。这可能是因为决策需要使用大量的数据，或者因为决策必须比人类能做出的决策更快。重要的是，委托系统提供了人类审查和纠正决策的机制，或者在自动化决策者失败时，可以介入并纠正系统的行为。

坚持不懈号漫游车 [1] 是一个典型的委托式人工智能系统的华丽例子。坚持不懈号是一个半自主机器人，它在 2021 年初登陆火星。它的任务是调查数十亿年前在一个大型撞击坑的洪水区域形成的岩石。它从一个岩石形成地移动到另一个岩石形成地，以发现和采样不同类型的岩石，从而有助于对该地区地质的了解。地球上的科学家和地质学家确定了漫游车的目标，操作采样和测试仪器和工具，并对它的系统和功能进行高级控制。图 9.3 展示了坚持不懈号如何独立行动，使用其传感器在其前方地形的一部分构建一个前进的预定路径。在将路径发送到任务控制中心进行批准后，漫游车将准备命令过程以驱动路径。一旦获得批准，漫游车将自行执行计划。

图 9.3 委托式遥控漫游车的控制流程 [1]

选择委托式系统模型用于坚持不懈号，因为它平衡了由与火星通信延迟带来的物理约束和最先进的人工智能方法创造的价值与风险。手动控制系统意味着漫游车的移动速度太慢，无法实现其科学目标。这是因为每次行驶迭代至少需要八分钟来完成（由于信号往返火星所需的时间）。一个完全自主的系统会将数十亿美元的投资暴露在太多的风险中，这是 NASA 无法接受的。这里描述的周期性控制是许多可用于管理委托式人工智能实现中系统自主性的机制之一。

另一种策略是将系统划分为独立的子系统，每个子系统在出现故障时不会造成系统性的或不可接受的损害。在子系统故障可以容忍的时间内或所需的资金内，您可以单独管理每个分区。

移动电话网络是这类系统的例子，我们可以使用分区策略来提供委托控制。网络中的每个小区都独立工作，为其分配区域内所有用户提供服务。例如，一个小区可能会因为其用户数据库失败或天线转向策略没有分配足够的功率来启用用户使用服务而出现故障。这种局部且有限的故障随后会被国家运营中心报告或检测到。他们根据通信监管机构对运营商施加的服务级别协议采取补救措施。如果网络提供紧急服务（例如警察、消防、救护车或海岸警卫队），那么可能已经实施了故障转移和复制措施来提供所需的覆盖范围。或者，系统可能设计了一个 24/7/365 的服务和维修团队，以便快速解决问题。

这种分区和快速恢复策略适用于许多应用。因为故障是系统固有的，它变成了一个负担，我们不能设计需要持续普遍可用性和服务的应用程序来依赖这种机制。生命维持系统可能有一种分区策略，其中一些元素在面临其他故障的情况下继续工作，但系统还必须包括一个合格的人员（比如护士）来操作故障元件，在它们损坏时。总的来说，系统（机器+护士）足够稳健，可以接受。

在设计委托系统时，团队可能会犯的一个错误是实施针对人工操作员的虚假控制。如果系统在修复错误为时已晚时将控制权交还给人工操作员，那不是委托，那只是简单的失败。在生命维持系统的例子中，想象一下如果护士只有在病人出现心脏骤停时才意识到机器的故障，那就太晚了；损害已经造成了。在现实生活中的例子中，飞机被控制系统置于失速状态，但在无法避免坠机的情况下才让人类飞行员介入[5]。悲剧的是，数百人因此丧生。显然，真正的飞行员（或护士）必须足够早地介入并拥有足够的权力来处理正在展开的情况，并且这个人必须有权做出避免灾难的决定。

由于人类和组织错误，可能会构建出这种类型的虚假委托系统。它们也作为避免实施真正自主系统约束和挑战的一种方式而被构建。不幸的是，通过假装存在一种可以介入并防止系统杀人或使人们破产的安全措施，可以规避创建足够信心部署真正自主系统并满足“我将把我的生命托付给它”或“我将把我的事业托付给它”的标准的证据。最终，这种方法会导致那些被欺骗而信任这种系统的人被杀害或破产。我们将在下一节讨论自主系统的额外要求以及强加在道德上和功能上成功的自主系统开发上的严格标准。

9.2.3 自主系统

自主系统被允许在没有人类干预的情况下独立运行和运行很长时间。我们将 Perseverance 漫游车描述为一种委托系统，因为控制过程被划分为元素，这些元素可以由人类审查和批准。如果 Perseverance 驶入沙坑（就像一些以前的漫游车所做的那样），那将不是因为机器学习和人工智能规划者失败了，而是因为操作不当。更准确地说，那是因为尽管团队尽了最大努力，但仍然出现了故障。机器学习团队在系统中构建了适当的控制措施，这些措施是适当的，因为团队平衡了系统的局限性和要求。

另一方面，自动驾驶汽车是一个完全自主的系统。如果你乘坐自动驾驶汽车并要求它带你去一个特定的目的地，你不需要对汽车在途中发生的任何事故负责。开发汽车并将其作为自动驾驶汽车卖给你的团队（在道德和伦理上，如果不是法律上）负责。自动驾驶汽车（至少就这次讨论而言）是一个操作上自主的设备。车辆执行从家到目的地的整个旅程管理过程；用户控制去哪里的战略选择，并且可能通过改变一些操作指令（例如，“走后路”或“慢点，我感觉不舒服”）来施加战术控制。

提供一个完全自主的系统对团队的要求远比提供一个辅助系统要严格。自动驾驶系统的开发证明了这一点。自 2007 年以来，自动驾驶技术已在城市环境中部署，如 Xei 等人所述[12]，但 15 年后，它仍未得到广泛应用。这是由于在现实世界中部署和运营自动驾驶车辆的复杂性和失败尝试。相反，自主机器学习系统被部署来管理和创建互联网上最受欢迎的社会网络和内容推荐系统的用户体验。

大型社交网络使用推荐系统算法来选择在订阅者时间轴上显示的帖子和信息。对于单个用户来说，这看起来可能是一个辅助系统的例子；他们能够在信息海洋中看到一条连贯的内容线索。然而，用户对于他们看到的内容或更重要的是，他们看不到的内容，没有选择权。社交网络是一个自主系统，智能地将其服务器上的内容定向发送给其订阅者。

自动驾驶汽车揭示了自主系统的一面；社交网络揭示了另一面。自动驾驶应用管理汽车的动能。社交网络没有局部化的动能，但它们具有全球和社会规模。没有人工智能，大型社交网络平台这样的应用是不可能的。自从这些系统开发以来，它们已经为它们的创造者创造了数千亿美元的收益。由于自主系统具有如此高的价值，创建人类无法处理的应用，管理超出人类能力范围的系统，而这些系统显然是危险的，它们本身是否本质上就是危险的。这并不是说它们不应该被构建和使用！

自主系统的力量和承诺使它们成为解决我们今天面临问题的理想候选者。你的任务是找到限制和管理它们开发和部署至今所揭示的基本危险和陷阱的机制。

目前，系统的意图和结构，以及应用的力量和重要性，驱动着这类项目中许多设计决策。随着实施阶段的进行，团队必须考虑所有这些决策与所有需要执行以交付最终系统步骤和活动之间的关系。

其中之一是建立一个生产数据基础设施，为应用提供其运行所需的数据。

9.3 非功能性审查

团队现在已经花费了几周时间与数据、基础设施和用户一起工作，他们应该对成功交付所需的内容有一个更为详细的了解。此外，你手中还有机器学习生成的模型，以及创建模型所需特征和输入所需的数据移动和转换模式现在已经定义良好。将这些事情结合起来，可以在处理时间、不同生产系统组件以及客户为每个元素提供动力所需资金和环境资源方面形成一个有意义的系统需求集。

处理时间需要从延迟（响应服务请求的时间）和吞吐量（在给定时间内可以完成多少个服务请求）两个方面来考虑。表 9.3 显示了在审查重新实现和迁移的训练管道时，你和团队必须考虑的一些要求的长列表。

表 9.3 机器学习系统中的非功能性需求

Requirement	Description	Notes
$Cost	执行系统的成本。	需要考虑长期使用但成本较低的基础设施与短期使用但成本较高的基础设施之间的权衡。
Environmental cost	每次使用服务所能接受的环保损害量。	应当考虑环境影响，包括温室气体排放以及空调和冷却系统中使用的有害化学物质。应意识到金属（如稀土和金）的消耗，这些金属可能在某些领域部署你的服务时涉及。
Latency/wall clock	从服务请求到结果交付所经过的时间。	在某些应用中，这被视为一个平直的要求，例如小于 0.5 秒；或者，可以作为一个关于分布或结果范围的期望来呈现。
Throughput	在给定时间内可以处理的服务请求数量。	这定义了系统可以同时支持多少客户使用服务。
Queue policy	对处理超额请求的优先级。	如果请求数量超过了系统吞吐量所能支持的数量，或者请求无法在所需的时钟时间内得到处理，系统应该采取什么行为？是否应该强制执行严格的先进先出/后进先出行为？是否有其他要求来优先处理某些请求？
Failure policy	当请求无法在不违反非功能性需求的情况下得到处理时，应该发生什么？	一些系统应该静默失败，一些系统应该提供异常/失败响应和消息，而一些系统应该在非功能性要求之外处理请求。在某些情况下，在失败后关闭系统甚至可能是适当的。
Durability	服务在无故障状态下运行的时间长度。	一些系统随着时间的推移会变得不可靠。确定模型必须在服务中工作多长时间，这决定了需要采取哪些措施来减轻这种情况。
Reliability	系统可以容忍多少次故障（非功能性需求违反）。	应当考虑所有故障来源，同时也要逐一审视它们。

模型和管道，以及系统的设置，现在都已掌握。这些是您的团队将集成到系统中的组件部分（无论系统如何构建）。现在您可以确定 E2E（端到端）的性能预期。然后您可以确定是否能够达到您所追求的目标。

9.4 实施生产系统

本节旨在帮助您实施生产系统。作为提醒，让我们看看与该任务相关的冲刺 3 票据。

系统实施票据：S3.3

• 构建生产数据流，以使模型能够进行推理。

系统实施票据：S3.4

• 构建模型服务器和推理系统。

系统实施票据：S3.5

• 确定系统所需的适当接口组件。

系统实施票据：S3.6

• 选择符合接口开发方法，以便交付接口要求。

9.4.1 生产数据基础设施

您的模型将进入生产环境，将集成到应用程序中，并且它们必须有效运行。生产基础设施有两个关键组件：将应用程序数据导入模型的管道，包括创建特征的过程，以及将调用并执行模型以产生结果的模型服务基础设施。数据来自许多不同的来源。例如，如果用户点击购物车，有来自点击的数据（哪个按钮，自上次点击以来有多久等），来自购物车（存储先前选择的数据存储），以及来自用户数据存储和商业环境。

图 9.4 展示了这一实现模式的高级视图。数据从存储和操作活动（如用户界面点击或传感器数据）流入。处理这些数据将其转换为模型期望的特征和格式。（此步骤复制了训练和测试管道中使用的流程。）然后，一种机制将这个数据实体传递给模型的运行实例。

图 9.4 生产机器学习实现的抽象视图。数据被拉入并收集在特征创建过程中，然后提交给运行实例的模型（用于生成推理和输出）。

在冲刺 1 中，您创建了训练数据管道，并使用这些管道管理训练数据。在冲刺 2 中，您实现了测试环境的管道，复制了训练环境中的数据交付管道到测试环境。现在您和团队需要构建生产管道，将数据输入选定的模型。在生产环境中执行此操作的可用的硬件和系统通常与开发中提供的不同。

表 9.4 描述了您和团队可能现在面临的一些选项。您构建的数据管道原本是为了从预定义资源中为模型提供示例，现在必须在生产基础设施上运行。不幸的是（对所有人来说都是如此，尤其是对机器学习工程师来说），数据技术已经经历了许多代的发展。您和团队可能会遇到其中任何一代。在最坏的情况下，您可能会同时遇到所有这些。表 9.4 提供了生产环境中可以预期的数据源和数据引擎类型的概述。感谢您的幸运之星，您不需要用 COBOL 来拉取管道的数据。

表 9.4 数据引擎及其在生产服务中的应用

数据引擎类型	特点	用例/备注
内存存储（Redis, Memcached）	极高的速度，但不持久或数据安全。可能成本高昂。	需要高速/低延迟的推理结果，且数据转换和处理相对简单。
数据湖（HDFS, S3）加处理器（Hadoop, EMR, Dataproc, Databricks）	使用灵活的文件系统和大规模处理进行存储。	需要大型的离线且成本较低的数据转换；通常与更快的存储配合使用以支持推理服务。
数据仓库（BigQuery, Redshift, Oracle Exadata 等）	用于训练数据的托管数据存储（通常是默认选项）。	提供通用引擎的灵活分析数据基础设施，用于服务于模型。
RDBMS 事务服务器（Oracle, MySQL, Postgres, Spanner）	如果设计得当并优化良好，具有良好的应用性能。在极限情况下可能会遇到困难或变得昂贵。	提供直接重实现层，以最小的技术更改加速管道。
文档存储/NSQL (Mongo, CouchDB, Cassandra, Big Table)	高速；擅长处理大型对象。	需要检索大型非结构化对象并服务于推理服务。
---	---	---

现代的方法是在生产环境中通过一个访问层抽象数据源。在这种情况下，团队无法访问或查询他们将从其中获取数据的实际数据库。相反，他们将被提供一个 API 地址，该地址会自动调用查询。这种模式有很多优点。主要优点是通过引入抽象层，系统与其依赖的源的实施细节解耦。

如果在生产架构中您没有采用这种方法，那么自己实现它可能是个好主意，这样您就可以应对未来的架构演变。如果系统中的所有调用和交互都通过一个控制良好且文档齐全的 API 进行管理，那么处理数据库升级会容易得多。

无论使用哪种基础设施，关键挑战都是复制在冲刺 2 中开发的实际数据管道，该管道支持向模型展示的示例构建。您将能够重用大部分已开发的代码，但这一转变通常需要您进行更改。这可能导致一种情况，即尽管生产中使用的模型是团队开发并测试的模型（所有创建和使用的工件都经过仔细保存），但由于数据管道将新的偏差引入其中，其行为可能不同。控制这种行为的办法是回退到在冲刺 1 中开发的测试数据系统，以确保为模型构建生成了正确的数据。

测试和验证数据管道的实际和预期行为是保证模型精确性的关键保证。下一节将探讨另一个方面。生产系统需要考虑的第二个方面是模型服务机制。

9.4.2 模型服务器和推理服务

推理服务是一种提供优化和高效计算和存储以执行您的模型的机制。它是一种满足本项目对延迟、规模（请求数量）和成本（总体而言，考虑到预期的请求数量）要求的执行机制。推理服务是您用来应对在生产环境中运行大型和复杂模型挑战的设计和实现模式以及包。

一个大规模或普遍的机器学习系统在其生命周期中可能会调用数十亿次支持其运行的模型。如果仅对优化进行 1%的改进，那么这相当于数千万次的模型调用。像 Google Translate 或 Facebook 推荐系统这样的系统支持一个庞大且持续的收益流，因此一个专业团队负责实施和支持机器学习计算组件的生产服务。这个团队能够磨练和优化执行框架，以支持这些系统的所需规模和性能。

在许多其他场景中，尽管可以提出一个业务案例，表明它们是一个具有成本效益的投资，但一个专门的团队（或多个团队）在组织上可能不可行。组织常常在现金流或战略需求上挣扎，这些需求将投资从具有成本效益的活动中撤出，以减轻竞争或监管的生存风险。尽管一些地方有运行良好的机器学习机器在生产中嗡嗡作响，但世界上的其他地方必须尽力而为。

除了使用定制实现的昂贵（且风险高）方法之外，还有两种方法。第一种是使用主流执行引擎，并对其进行最小化定制以支持您的机器学习函数。表 9.5 列出了各种执行引擎。

表 9.5 使用通用执行引擎为机器学习模型

引擎	备注
在数据库中：BigQuery ML, Redshift ML, Oracle OCI, Vertica PMML	在数据库函数中执行意味着接受对应用程序运行方式的限制，但这是一种模块化和解耦的方法。
应用服务器：NGINX, Apache Tomcat, Flask, Appserver	用于通用低规模和宽容的延迟/成本用例。考虑到技能和设置要求的低门槛，可以考虑使用。
类似 SPARK 的解决方案：Apache SPARK, Databricks, Dataproc	在宽容的成本和延迟要求下，提供良好的批处理和流处理支持。
Kubernetes, Kubeflow	提供对交互式应用的支持，具有灵活可扩展性和宽容的成本要求。
无服务器：Lambda, Cloud Functions, Azure Functions, Cloud Run	一种灵活、模块化和解耦的方法，在某些应用中成本效益高且性能出色，但可能以不可预测的方式变得昂贵。

所有这些选项都有其权衡和好处。在许多应用中，在数据库中运行机器学习是合理的，但这样做会影响数据库的行为，并且可能成本高昂。此外，数据库执行必然缺乏灵活性；数据库引擎的更新和维护是基于其作为数据库引擎的性能，而不是作为机器学习引擎的能力。最新的机器学习技术不会出现在你使用的数据库中，至少不会出现在与软件堆栈的其他核心关注点联系不那么紧密的引擎中。

我们使用应用服务器从网页和应用程序中调用执行。手机或浏览器的前端调用应用服务器进行一些离设备的服务器端处理，应用服务器提供响应。这些系统通常是大规模并行和可扩展的，并提供了最先进的负载均衡和错误管理。毕竟，它们是处理数十亿用户请求的系统，这些请求是我们每天使用的许多互联网服务的一部分。

类似 SPARK 的解决方案提供了多种管理内存中并行性的方法，并支持访问包含运行模型所需数据的文件系统。SPARK 是一种主流编程方法，因此许多开发者都具备这项技能。SPARK 与 Python 和 R 的模型实现交互良好，因此其成本通常较低。SPARK 对于按需应用来说可能成本高昂，而且不适合极低延迟的应用。

Kubernetes (K8s) 提供了一个可扩展的持久处理系统。在云环境中，你可以将其用作托管服务，这特别吸引人。然而，对于突发工作负载，Kubernetes 可能成本高昂。

最后，无服务器系统在提供对突发工作负载的极大规模按需处理方面表现出色，但与像 K8s 这样的持久、始终在线的方法相比，它们的启动延迟相对较高。在无服务器方法背后的定价模型方面，我们必须谨慎。如果云服务提供商决定改变无服务器引擎的定价方法在商业上是合适的，那么这可能会对使用它的任何机器学习系统造成破坏。确保您有一个退出策略。

第二种方法是使用从底层设计来支持机器学习调用的引擎。然而，这种方法的兴趣在机器学习社区中起伏不定。在人工智能的古老历史中，像 Withington [11] 描述的 Lisp 机器这样的专用计算平台被开发出来，但被像 Intel 8086、Dec Alpha、Sun Spark 和 Motorola 68000 这样的主流处理器所取代。也许机器学习服务器引擎也会发生这种情况，但也许不会。像 OpenVINO [7] 和 TensorFlow Serving [4]（Google 2021）这样的引擎被优化来管理模型的执行，这些模型实际上是由浮点数操作创建的数百万或数十亿的正则化激活。此外，预构建的引擎还提供了针对处理器指令集的优化优势，例如 Google TPU 或 Intel 处理器指令。

确定您数据流的生产实现、用于使模型活化的处理以及执行它们的处理表面非常重要。然而，如果用户看不到正在发生的事情，或者他们没有足够的控制来以他们需要的方式操作它，那么这一切都是徒劳的。鉴于良好用户体验的重要性，我们将在下一节中讨论这个问题。

9.4.3 用户界面设计

许多人会认为，任何系统的起点都应该是它对其支持的人产生的影响。 “设计思维”的倡导者可能会支持需要结构化流程来揭示可用性约束和需求。Liedtka 的 HBR 文章 [6] 中的一个好例子是不合适的医院预约系统。它的用户是老年人，不擅长使用电脑，以及由于导致他们使用系统的疾病而感到不适和迷失方向。从这个角度来看，在了解它将如何被使用之前构建一个聪明的自动化预约系统是金钱和时间的浪费。

另一个由于不适当的界面导致的失败例子是波音 737 MAX 飞机及其 MCAS 系统。该系统旨在使飞行员飞行变得容易，提供在飞机失速时支持飞行员的控制。理论上，这将避免可能导致飞机坠毁的危险事件。该系统的激活灯是驾驶舱配置中的一个昂贵的可选额外设备，因此一些航空公司选择不在他们购买的系统中包含它。不幸的是，这意味着飞行员在系统激活时并不知情，如果它只在失速条件下打开，这可能没问题。然而，在某些情况下，损坏的传感器意味着系统在飞机正常飞行时激活，导致飞机向地面俯冲，并以飞行员不理解甚至不知道如何应对的方式行事[8]。显然，隐藏模型的工作原理导致了数百人的死亡，因此，737 MAX 被停用并进行了返修，造成了数十亿美元的商誉损失。

Saleema Amershi [3]于 2019 年发布了一套开发 AI 系统的指南，总结在表 9.6 中。尽管 Amershi 谈论的是 AI，但很明显，这些指南（编号为 G1 至 G18）主要关注包含 ML 模型的系统，因此与你的项目相关。你会注意到表 9.6 中标注了一些星号。这些星号表示对 ML 项目中的 UI 设计师特别重要的指南。虽然本章中提出的所有指南对系统价值和成功都具有重要意义，但 G1、G2、G4、G5、G6、G8、G10、G14、G15、G17 和 G18 这些指南尤为重要，因为这些可以防止灾难性失败。这些指南侧重于防止 ML 系统犯下越权之罪，即一个表现不佳的系统比让用户自行决定更糟糕。

表 9.6 AI 设计指南（改编自 Amershi [3]）

何时使用	数字	设计指南
初始时	G1*	清楚地说明系统能做什么和不能做什么。
G2*	除了描述系统的功能外，还要阐明系统工作得有多好。
在交互过程中	G3	考虑到用户的当前任务和环境进行主动交互的时间。
G4*	显示与用户当前上下文相关的信息。
G5*	以用户能够反思其社会和文化背景的方式提供信息。
G6	确保信息和说明不反映不公平的社会、性别或种族偏见。
当出错时	G7	支持高效的调用，使系统工作变得容易。
G8*	即使在失败后也要使系统易于关闭。
G9	通过使系统输出和动作的更正和编辑变得容易来支持高效的更正。
G10*	在不确定的情况下确定服务范围。如果系统不确定，则从用户那里获取更多信息，或者在不确定用户目标时优雅地降低服务。
G11	使用户能够访问有关系统行为的解释。
Over time	G12	记住最近的交互，并在内存中保持这些交互，以便用户可以使用这些记忆来获得服务。
G13	从用户行为中学习；根据用户个性化系统。
G14*	谨慎适应。限制对系统行为的破坏性和意外变化，特别是在用户基于其期望有需求的地方。
G15*	鼓励细致的反馈。使用户能够提供有关性能的有意义的信息，并确保有机制可以实现这一点。
G16	当用户的输入改变系统的行为时，通知用户。
G17*	允许用户监控和控制系统的行为。
G18*	通知用户关于变更的信息。当 AI 的能力更新或增强时，通知用户以便他们可以修改他们的期望。

这些指南可以帮助创建一个特定系统所需的仪器和控制列表。书中之前讨论的智能建筑示例可以作为我们深入了解指南细节的例子：

• G1: 建筑中的每个人都应该意识到环境是由 AI 系统管理的。我们可以创建标牌让人们知道，建筑网站也可以在页面上添加关于系统的说明。|

• G2: 应共享现场测试和验证期间的性能信息，并解释结果。关注碳减排，解释这可能意味着在非工作时间，建筑的一些部分比正常情况下更凉爽。|

• G3: 确保系统在核心业务时间不进行温度和照明的激进调整。|

• G4: 确保特定建筑区域的环保和能耗信息可用。|

• G5: 在展示环境和能源信息时，考虑原始数字对用户的相关性。将信息与先前数据相比较，并解释差异。将好处与用户可以理解和同情的项目相关联；例如，对于碳减排，“砍伐的树木数量”或“抵消所需的森林公顷数”。|

• G6: 在系统的性能中考虑诸如生物学等因素。例如，人们常说女性比男性更容易感到寒冷。确保这一点在系统的行为中得到考虑。同时，确保任何用户测试小组中男女比例均衡，并询问他们各自对系统性能的看法。|

• G7: 提供投诉和管理流程。建筑的用户应该联系谁，以及如何联系？|

• G8: 考虑系统可能会失败，可能需要关闭。确保建筑管理者知道如何这样做，并且用户知道如何联系建筑管理者。

• G9: 提供控制选项，让建筑管理者能够以有意义的方式控制系统。如果用户抱怨建筑太热或太冷，提供修改系统行为的方法，使其保持使用状态，即使不是最优的。

• G10: 确保建筑有一个安全选项，在传感器网络和控制器产生模型没有强烈响应的输入时，将其恢复到稳定温度。

• G11: 记录系统正在做什么，并以友好的方式提供对该日志的访问，以便用户可以检查决策过程，以在长时间内调节或增加能源使用。

随着时间的推移，根据 G1-G11 指南开发的界面为用户提供了一种反馈机制，并确保公司管理者能够收到反馈。因此，提供一个反馈页面，您可以在此记录管理者采取的行动，然后将其发布，让用户可以看到他们的反馈是如何被处理的。为 G11 提供的便利避免了困难的一点：解释模型所做的事情可能具有挑战性。Rudin 将其详细描述为在重要应用中采用和使用 AI 系统的障碍[10]。

在选择模型时，应该考虑预期应用中的透明度要求。这是一个强烈的需求，也是第八章决策的一部分。然而，有时根据项目中的所有需求和挑战选择的最佳模型可能是不透明的。例如，支撑蛋白质结构预测的 AI，AlphaFold 2，是一组极其庞大且晦涩的深度网络。这些网络是不可解释的，但如果它们是可解释的，那就太好了，这样生物学家就可以了解 AlphaFold 2 是如何以及为什么这样做。AlphaFold 通过渲染它创建的结构，显示它们与先前假设的结构有何不同，以及它们是如何工作的，提供了一些折衷的能力。这允许科学家评估和直观 AlphaFold 做出的黑盒预测的有效性和价值。

对于用户和您的团队来说，最好的做法可能是使用事后解释机制。为深度网络如 AlphaFold 2 提供推理解释的一种流行方法是提供激活图，显示哪些处理过的图像的部分在网络上引起了最高级别的活动。支持这种解释风格的流行软件包是 LIME [9]。

提供事后解释的艺术一直在提高，但在鲁丁[10]中对此有强烈的批评。你必须做出的判断是，提供关于系统行为的误导性解释可能造成的伤害是否超过了忽视不透明系统可能为用户提供的价值所造成的伤害。明确说明解释是指示性的，可能不准确，这可以稍微减轻这种潜在伤害，但用户实际上是在你的手中。这是你的责任；请谨慎行事。

9.5 日志记录、监控、管理、反馈和文档

支持和管理组件：S3.7

• 为系统构建日志记录、监控和警报组件。

支持和管理组件：S3.8

• 确保模型治理和交接安排已达成一致。

支持和管理组件：S3.9

• 制作维护和支持文档。

如果你正在将系统交付到生产环境中，那么实施一套允许技术支持团队操作的管理和行政接口是必要的。ML 系统也不例外。系统需要生成有信息量的日志信息，以便你可以了解它是否按预期运行，并在出现问题的情况下追踪发生了什么。它还需要在失败之前生成警报，最好是失败之前。

对于正常的软件系统，性能监控是非功能性的。从功能的角度来看，我们可以期望软件在没有错误的情况下正常工作。ML 系统在生产中也可能出现功能故障，因为世界在变化，在冲刺 2 中用 ML 算法提取的模式和行为可能不再相关。这可能是因为产生 ML 预测需求和行动的实体发生了变化。也许其中一些已经变老并死亡；也许其他压力，如经济变化或新技术的引入，已经从根本上改变了该领域的动态。例如，一个基于流媒体普及之前的数据提供良好音乐销售预测的模型可能会在今天失败。因此，这意味着我们必须记录和警报功能系统行为以及非功能行为，以解码这种功能故障可能发生的时间、地点和原因。

我们需要在系统日志中记录和捕获与其操作相关的所有事件，例如数据库连接、用户登录、数据更新和模型决策。日志记录的频率和密度由应用程序决定，日志本身的保留期也是如此。显然，计算性能指标对系统造成的负载以及存储日志数据都有成本。这通过你在开发系统时建立的应用程序需求来平衡。

日志的密度是由需求和性能考虑驱动的。警报系统的性能受限于人类如何有效地与之互动。支持小组经常抱怨警报风暴，每 10 分钟就会让他们的板上所有灯都变红，并向所有设备发送消息。这些警报通常被忽视，几乎可以忽略不计。这种警报行为的糟糕副作用是，有意义的警报在垃圾信息中丢失，也被忽视了。

除了日志记录和警报之外，系统还必须具备您可以使用来控制和管理的执行器。管理功能可以简单到请求重启以清除队列满或内存分配失败等问题。尽管希望交付的系统无错误且完美，但基于这种假设的计划是不明智的。提供重启按钮可能是一种既经济又有效的解决方案，以应对意外问题。这也可能足以让一个宝贵的系统在现场运行数年，而不会出现其他情况。

在生产环境中使系统可支持的一种强大方法是让用户能够提供反馈。这在部署的早期阶段尤其有用，因为开发组仍然可以实施任何所需的修复。提供反馈机制是基本要求；你必须这样做。然而，更重要的是要让用户使用它。一种好的方法是直接询问他们对系统的看法。

例如，考虑实施一个支持在互联网上监控客户投诉的系统（例如，在 Twitter 或 Facebook 上）。系统的用户可以被视为在客户组织中无权力的呼叫中心操作员，由于社会和文化原因，他们无法反对公司的系统。假设当提供了一种关于系统性能的反馈机制时，他们会发布许多投诉。一个投诉是系统响应时间过长，他们有时会超时。起初，这似乎很荒谬，但当调查后端数据库的查询时间时，团队发现一些查询运行了数分钟。这使得系统既慢又令人沮丧，也破坏了 ML 系统旨在创造的所有好处。

在我们的例子中，生产中系统的问题出现是因为生产数据库没有按照预期的方式进行配置和索引。团队不知道这一点，因为没有任何测试显示这一点。通过给数据库团队打一个电话，问题就得到了解决。这个轶事的要点是，尽管进行了测试、日志记录和监控，但开发团队可能对生产中的问题视而不见。向用户询问很少会伤害到他们，并且（正如这个案例所示）可能非常有价值。

机器学习系统的一个特定特征是，随着时间的推移，系统的输入价值可以随着世界的发展和前进而改变。监控系统输入以检测这些变化是日志和监控支持机器学习系统治理的一种方式。这一点将在下一节中更深入地讨论。

9.5.1 模型治理

在某些应用中，第一天运营中实施到系统中的模型被成功使用，直到技术状态或应用需求的变化使它们过时，然后它们被从服务中撤回。在其他应用中，领域的变化，可能是由时尚的波动、通货膨胀、社会结构或人口统计引起的，意味着模型变得过时，其性能开始下降。使用机器学习的组织可以部署数百或数千个模型和系统，但除非这些模型在系统性的管理和治理框架内交付，否则将陷入混乱。

一个基本的治理结构要求支撑系统和模型的负责人在客户组织内部进行注册。模型必须由某人拥有。我们还必须提供访问和理解模型所需的所有材料和信息，以便所有者可以随着其发展来处理它。治理系统至少应允许识别系统所有者（负责并有权就系统做出决策的人），并将所有使系统能够被审计、管理、维护和支持的工件链接起来，以便于发现和访问。此外，治理系统要求记录和读取生产系统的历史：

• 系统是在何时实施、更改和审查的？

• 系统问题何时被检测和记录，以及采取了哪些措施来处理这些问题？

• 如果系统被停用，它是在何时被撤回的，以及它和其授权及操作的相关记录将在何时被删除？

在官僚主义的繁琐中消失的一个核心要求是，模型所有者必须能够判断模型何时出错，并且必须能够将其关闭、修复或替换为其他东西。一个关键步骤是知道模型已经出错。在生产环境中进行一些简单的检查可以揭示这一点；例如，计算模型做出的分类类型，并在发现太多某一类型时发出警报。然而，一个更复杂的方法是将断言构建到模型服务器中，并在这些断言被违反时进行记录和警报（Kang 等人，2020 年）。

你还必须为意外情况做好准备。这就像任何业务连续性计划一样；基本的前提是，如果总部因地震、恶劣风暴或其他不可预见的事故关闭一周或一个月，企业不会破产。每个企业都应该有应急计划来应对这种可能性。对于模型也是如此！如果模型停止工作，无论是什么奇怪的原因，使用这些模型的企业不应该被遗弃。例如：

• 聚合行为或多数类预测（附带适当的警告）能否为模型提供一个更低价值的替代品？

• 你能提供一些工作效果不那么好但可能更稳健的旧模型吗？

• 你能关闭模型，让用户在没有它的情况下管理一段时间吗？这个时间是多长？在这么短的时间内调试、重新测试和修复模型是现实的吗？

在下一章中，这些问题将变得非常重要，因为它们将影响你未来的工作。在转向生产之前，通过制定实际的发布后安排，你可以避免很多痛苦和麻烦。

9.5.2 文档

在项目期间，你应该已经产生并归档了大量文档。所有这些都是极其有用和宝贵的，但为了交付一个可维护的系统，团队需要准备一些额外的文档来支持系统的运行。这些文档包括：

• 一个生产团队组织结构图

• 运行手册

• 技术概述

• 故障排除指南

你可以使用生产团队组织结构图来回答谁负责系统，如何联系他们，以及他们需要哪些凭证、知识和培训来完成工作？同时，确保生产团队的设置和结构考虑到了假期、疾病和继任问题。人们积极地说，人们最好覆盖他们被叫去处理的事情，这是可以的。但万一有人辞职，或者更糟，他们去世了？那么，你就陷入了困境，所有的姿态和吹嘘都只是个笑话。

运行手册允许一线和二线支持在系统因其他系统或其支持硬件中的故障或问题产生错误时进行故障排除。其他支持团队可能会修复这些错误的根本原因，但相关的“请修复此问题”的工单需要提出，并且你需要告诉用户发生了什么以及正在采取什么措施。运行手册应提供日志和监控系统可能产生的每个错误状态的信息。其中一些可能只是简单地说“数据错误：升级至技术团队”，但许多也会提供简单的修复方法，例如“使用 app_server_restart.exe 脚本重启应用程序服务器。”

技术概述为新工程师提供简报，使他们能够快速了解核心组件和概念。这个概述通常链接到团队生成的文档存档，因此应被视为系统的高级地图，而不是详细的深入研究。本质上，团队应该想象他们被提供了代码库和开发文档。他们需要什么才能快速开始？至少，文档应包括一个显示系统主要组件及其处理分配的图表，还应显示系统中的数据流视图：数据来自哪里，在哪里被访问、存储和处理。

为了设置故障排除指南，要求团队发挥想象力。系统可能存在哪些错误？他们会如何修复它？

确保团队特别注意系统中 ML 组件和模型的文档。开发文档涵盖了建模的技术架构和方法，但文档必须详细说明：

• 如何独立调用模型（要运行的文件，如何向其中传递数据等）。

• 如何保留模型（再次，要运行什么，如何运行，以及环境先决条件）。

• 如何评估模型的行为（参考项目文档，但明确说明模型如何向用户交付价值的重要性）。

开发这些文档所需的努力相当大，并且显然与您正在开发的系统的复杂性成正比。这样做的好处是巨大的；一套良好的生产文档与一个丰富的开发档案相结合，为系统的后续开发和维护提供了一个极好的资源。

9.6 预发布测试

测试票据：S3.10

• 制定预发布测试计划。

团队可能认为在冲刺 2 中已经做了足够的测试，但残酷的现实是，部署生产系统还有更多工作要做。大多数组织都有测试标准（有时称为 VV&T，即验证、验证和测试）。你和团队将需要制定并完成一个测试计划，然后由客户的 IT 部门签署为完成。通常，测试计划要求你进行单元测试、系统测试、集成测试和验收测试：

• 单元测试: 开发者用来证明其代码工作的本地化测试。

• 系统测试: 展示代码按预期执行；例如，测试模型和测试非功能性元素都是系统测试。

• 集成测试: 展示不同的系统模型按预期协同工作；例如，生产数据库与执行特征提取的代码一起工作。

• 验收测试: 展示系统满足使其对业务目的或用户目的有用的标准。

在系统开发过程中，团队进行了大量的单元测试（例如，在冲刺 1 中描述的数据测试）和系统测试（如冲刺 2 末期的广泛工作）。验收测试应由在冲刺 2 开始的 UX 工作来促进。然而，现在需要创建单元和系统测试的某些方面，并且需要通过集成测试来测试数据基础设施、UX 和模型服务基础设施。任何与 ML 系统集成的其他应用程序元素也需要集成测试。现在要完成的工作是：

• 收集和整理到目前为止进行的单元和系统测试。

• 将 UX 工作中的验收测试正式化和组织化。

• 确保生产组件有适当的单元和系统测试。

• 设计并执行集成测试，以确保实施的整体系统运行正确。

• 确保测试计划得到认可，是一个合适的计划。

• 将你的预生产测试集成到自动化测试系统中，并成功运行测试。

最后，获得必要的批准，表明团队成功执行了接受的测试计划，并且 VV&T 小组同意该系统可以投入生产。将一个有用的 ML 系统交付所需的测试与更标准化的软件所需的测试之间存在显著差异。其核心是从数据中提取的模型的表现和行为。

在撰写本文时，大多数组织对测试其模型所要求的标准远低于我们在第八章中详细说明的标准。希望这会改变。在此之前，你和团队是专业人士和专家。测试标准和质量要求是后盾和提醒，表明你需要证明你为什么被支付来做你所做的事情。你的测试计划表明，你已经完成了你所期望的一切，以创建一个健壮且可靠的工件，交付给你的客户和用户。

9.7 伦理审查

检查伦理方面的所有事项是否按计划进行是否太晚了？当然不是！在这个阶段，团队需要确保没有出现他们在之前的练习中没有考虑到的新问题，并且他们需要整理好为所有伦理评估准备的文档。这项工作是在项目开始前、EDA 之后以及模型选择决策过程中完成的。

现在系统整体已了解，你和团队需要审查其部署的伦理后果。如前所述，有许多持续的努力去理解 ML 系统的伦理影响和许可；系统的上下文决定了团队将采用哪些，如果有的话。此外，预计这个领域将迅速发展，你和团队有责任采用最佳实践来确保你构建的系统是符合伦理的。为此，检查以下内容：

• 负责该系统的人是否清楚地理解了系统的管理方式？

• 是否有一个适当的治理流程在位，可以随着时间的推移管理系统的行为和影响，即使现在执行它的人已经离开？

• 系统的性能是否通过它对其用户和其他在其操作环境中的影响来理解和衡量？团队能够证明这一点吗？

• 系统的界面是否提供了足够的信息，使用户能够理解它在做什么？

  • 管理系统行为的现有控制措施是否有效且适当？

  • 用户能否有效地利用控制措施，以便他们可以合理地对其系统的行为负责？

• 你已经咨询过系统用户和受其使用影响的人了吗？

  • 团队评估了系统对那些人的影响了吗？

  • 你的团队能否完全理解系统可能造成的任何伤害，并且这种伤害是否明显被系统的效用所抵消？

关于最后一点，在伤害的情况下，确保有一个负责任的人或者有权威和能力的某人可以就系统的效用做出判断。

9.8 提升至生产

将你的系统投入生产的工单：S3.11

• 提升至生产。

• 创建发布后测试计划。

那个伟大的日子到来了！一切都已经签字批准，系统既不危险也不恶意，它运行正常，并且具有价值。每个人都喜欢它，那么接下来会发生什么？你安排发布的时间/日期。在 DevOps 环境中，这可能就是系统达到首次发布标准的那一天。在更加僵化的企业环境中，可能会有每周发布日或者（更可能的是）每季度发布日，并且确实预期在圣诞节、新年和财务报告季节这样的里程碑日期会有冻结。一些企业在对交易或安全至关重要的时期也会有较长时间的发布冻结。

一旦所有人都同意了日期和时间，在现代项目中，你将运行一个批处理文件（可能通过点击按钮或通过执行命令行指令），将所有必需的系统工件转移到生产环境中，并使其可供调用。通常，我们会运行发布后测试来证明系统已经完全且正确地转移，并且它确实正在运行。这意味着团队有四项工作要做：

1. 开发将所有文件提升到生产环境的 CI/CD 流程。

   希望这是通过标准开发管道工具（例如，Jenkins）完成的。有时，尤其是在前沿项目中，可能会有一些部署的边缘情况需要另一个解决方案。重要的是不要最终得到一堆便利贴，或者更糟糕的是，像民间传说风格的口头指示来定义部署过程。尽可能坚持自动化（以及易于使用的自动化）。为什么？因为推向生产既令人兴奋又令人紧张，而且经常出错。你可能不得不重新调整和重新设计系统。自动化是你的朋友。

2. 创建发布后的测试计划。再次自动化（就像所有你的测试一样），并确保你知道它将如何运行以及如何在生产中部署。这通常是常规推广活动的一部分。

3. 执行推广/发布任务，包括测试。

4. 运行发布后的测试并验证结果。

正如提到的，生产部署出现问题的并不少见。重要的是你要为这种意外情况做好准备。确保有关键人员可用以介入，并且他们拥有凭证和权限来完成任何最后的障碍。

9.9 你还没有完成

当你认为你已经完成时需要完成的任务：S3.12

• 提供发布后的认可和感谢。

项目已经上线并运行。这是庆祝的时刻。带团队出去吃午餐，举办派对，喝一杯。至少，在团队通话或通过电子邮件向他们发送感谢信。团队已经成功交付，他们应得到一些认可。至于你，给自己鼓掌；你做得非常出色。然后，关注自己的利益，放松一下，思考发生了什么。你所经历的经验是宝贵的，你需要认可并保留它。

就在这个时候，你可能会意识到项目之外还有生活。有时当你回来时，你可以休息一下，转而做一些新的事情，但现实是，这是你的项目，你和所有与之相关的人可能会被召集来跟进出现的任何机会和发展。在下一章中，我们将回顾项目后的工作。为了支持和维护一个在生产中的系统，有很多事情要做，而且还有很多事情要做，从发生的事情中学习，以改进你为下一个项目以及之后的项目的实践。

9.10 自行车店冲刺 3

第二个冲刺的结束与你的假期巧合，你充分利用了假期。你相信罗布在你外出时能完成任务，当你回到工作时，你首先审查他的冲刺报告，并感到自己得到了证明。当卡里玛在你回到工作的第一天早上给你打电话时，你心情很好。但这并没有持续太久。

卡里玛觉得到目前为止项目活动很多，但她看不到任何具体成果。她用“全是烟雾，没有光亮”这个短语来形容。这可不是什么好事。卡里玛显然对项目的进展和价值有了改变看法；问题是为什么？你可以猜到，有人问她投资成果在哪里？凭借所有高级商业利益相关者都有的生存本能，卡里玛无疑通过概述她对这个项目怀疑未被考虑的原因来回应。然后她解释了到目前为止她如何尽力而为，但不应为发生的事情承担责任。不难想象，如果项目确实证明不了，卡里玛认为应该受到责备的人是谁。

你迅速思考。也许，你提出，正确的做法是召开一个审查会议，将到目前为止的进展和结果展示给卡里玛以及她希望邀请的其他人，讨论项目的方向，但你在这里有一个很好的备用计划。虽然建模团队一直在进行高调的工作，但克拉拉一直在幕后努力，研究系统的前端。她正在构建用户体验组件，并测试它们。你上周晚些时候与她简短地聊过，你确信，考虑到人们进行审查所需的时间，团队将能够联合起来进行一个概念演示，说服那些在卡里玛耳边嗡嗡作响的人，一切都很顺利。

你靠在椅背上，心理上对自己进行了一番责备。你应该早就看到这一点了，但你之前在项目早期更关注的是目标应用。然而，你知道，如果你把重点放在展示应用可能带来的价值上，而不是确保它能够工作，那么你可能会因为浪费客户的金钱在一个只是幻想的系统上而陷入麻烦。项目后置风险太大。然而，在阅读了罗布的报告后，你确信项目会成功，但危险在于在你证明它之前，项目可能会被取消。你看着你的咖啡，想知道是否可以喝得更浓一些，然后疲惫地摇了摇头。周末似乎还很遥远，而现在才上午 10:30。

尽管如此，现在处理这类问题正是时候。你首先做的事情是安排明天一早召开团队会议。接下来，你给克拉拉和罗布发信息。谢天谢地，他们今天都在工作，所以你安排了午饭后进行三方通话。你利用午餐前的这段时间来回顾 1 和 2 个冲刺阶段产生的材料。

在聊天中，你让罗布和克拉拉知道，是时候让团队概述模型可能的适用性如何最好地满足客户的需求了。令人高兴的是，你们三个人都认为，模型的最佳实现方式是将它们放在智能仪表盘后面。这是与客户讨论的初始概念。你考虑了项目偏离轨道的地方。如果在冲刺 2 中，克拉拉曾指出模型从用户体验的角度无法工作，或者建模团队发现了可能阻碍实施的问题，那么你就可以和卡拉玛和 Niresh 讨论改变方向的问题。具有讽刺意味的是，这可能会让他们对团队与客户需求的参与有更强烈的认识。不过，好消息是，项目正在顺利进行，以满足客户的需求和克拉拉认为用户需要的。

Niresh 随后给你发消息说，三天后有一个项目检查点的空位，但他没有提供任何进一步的细节。在这个项目里，三天的时间相当长，看到克拉拉和罗布与你讨论的情况，你对这个灵活性感到很欣慰。罗布的看法也很让人安心。他认为，到检查点的时候，团队将有一些相当令人印象深刻的计划可以展示。

早上，你和罗布向团队介绍了情况，并为接下来的三天制定了目标。第一个目标是处理分析任务 3.1 和 3.2。（如果你需要提醒这些任务的目的，请参阅第 9.1 节。）鉴于团队目前的位置和项目的成熟度，你决定 3.1 可以在团队会议上处理。团队也同意了。显然，合适的做法是开发智能仪表盘作为辅助应用程序。确定这一举措的非功能性影响稍微复杂一些，但丹尼尔和凯特愿意接手 3.2，并将在明天早上提供反馈。

罗布建议最好的做法是，对任务 3.3 和 3.4 进行一些说明，并组装一个应用程序的开发环境原型。在三天内完成这个目标是一个雄心勃勃的目标，但团队似乎出奇地自信。他们之前的调查和罗布在冲刺 1 中的工作发现了一个克拉拉和米格尔都熟悉的仪表盘工具。所需的数据流可以轻松地从新的生产数据库中绘制出来，云环境中的外部数据源可以将转换和特征创建步骤部署到无服务器处理器。克拉拉和米格尔开始实施用户界面，凯特和罗布专注于模型服务器的实现设计，詹妮和山姆查看数据管道。所有人都同意在明天的审查会议上进行展示。

在随后的几天里，你忙于回答团队关于可用组件的架构问题。其中一些你可以自己回答，但你发现自己经常和 Niresh 聊天以获取额外的答案。当那个星期四的检查点会议来临时，Karima 带着一个自称是 Alan 的人出现，他是财务人员。你认出他是 Alan Williams，The Bike Shop 的首席财务官。显然，他对他的钱花在哪里很感兴趣。Karima 似乎有些分心，不确定自己，而 Niresh 像老鼠一样安静。Alan 在 The Bike Shop 有很强的声誉——他不会轻易或根本不忍受傻瓜。

你已经仔细地向团队介绍了计划。你将首先介绍项目和工作价值，然后 Rob 将展示原型。他转向 Clara，Clara 将谈论用户体验工作和她接触到的用户的反馈。Miguel 将接着介绍 UI 的功能，重点是让机器学习系统为用户工作。剩下的时间里，Jenn 和 Kate 将回顾生产设计。

这种安排证明是一个非常好的选择。Alan 听了你关于好处的概述，直视 Karima。他说，“这正是我所说的。”Karima 脸色一变，你感到一阵冷意从脊背传下来，但他接着说，“但这不是空谈，对吧？你有什么可以给我看的？”

Rob 开始了演示，Karima 立刻放松下来。30 秒后，Niresh 对着你微笑（当然是在 Alan 的视线之外）。当 Clara 谈论用户反馈时，Alan 点头，当 Jenn 描述数据设计时，他转向 Niresh 问道，“你有什么看法？”Niresh 说，“我和用户讨论过了。我们可以在明天将这个方案提交给合规委员会，并尽快投入使用。”

Alan 站起来，没有注意到你，他转向 Karima 说，“去做吧。我会和 Pete 谈谈。”Alan 转向团队说，“很高兴见到你们所有人”然后走了出去。你感到有点被忽视，但毕竟，你是一个咨询公司的西装革履的人。Karima 明确表示她对演示和演示很满意。她问团队是否自信能够在你概述的时间表内准备好实施测试。

然而，在完成 S3.3 和 S3.4 任务之前，待办事项中有很多审查和响应子任务。看起来还需要额外几天时间来完成这些任务。团队继续处理冲刺待办事项中的票据；站立会议简短而直接。团队所有人都知道自己在做什么，并且正在努力完成。Clara 已经开始查看 S3.5，并在本周末之前开始处理 3.6。

凯特知道 The Bike Shop 的日志环境是 Splunk，她迅速提供了适当的日志和监控设置，与模型服务器和数据子系统的日志进行接口。你和罗布完全忙于与 The Bike Shop 的支持团队合作，安排他们接手系统。卡拉玛走过了治理流程。山姆和詹妮负责测试。计划得到了签署，测试工具链被构建，很快所有方面都一切顺利。

米格尔构建了发布逻辑，将系统提升到生产环境，双方商定了时间和日期，在你还没反应过来的时候，你正盯着 The Bike Shop 内部网络上的仪表板。卡拉玛拥抱了你。尼雷什高兴地微笑着。第二天你草拟了一封感谢团队的电子邮件。就在你准备发送时，一个警报弹了出来。是你的老板。你和团队被 The Bike Shop 留下了。他们想要更多，而且愿意为此付费！

摘要

• 在你和你团队构建的机器学习系统类型上做出深思熟虑的选择。它是辅助性的、委托性的还是自主性的？

• 承担这一选择带来的影响！不同类型的机器学习驱动系统的非功能性需求和功能性需求是不同的。

• 你需要构建生产数据流和合适的模型服务基础设施，以支持你已确定的需求。

• 机器学习系统的用户界面需求与普通系统不同。你需要确保系统得到适当的配置，并且用户可以访问相关控制功能。

• 确保提供正确的日志记录、监控和警报基础设施，否则生产支持团队无法将其投入使用。

• 确保你的系统经过测试并获得生产就绪的批准。

• 为预发布用户和集成测试预留时间和精力。

• 在开发系统发布候选版本时进行道德审查是必不可少的。这通常是利益相关者意识到已经实施的内容及其影响的时候。这可能很痛苦，但在这个最后的障碍中捕捉到问题，远比将问题发布到野外要好得多。

• 准备好将系统投入生产所带来的持续工作。当用户接触到你的工作时，你的工作还没有结束。事实上，可能才刚刚开始。

10 项目后（sprint Ω）

本章涵盖：

• 机器学习系统进入生产后的维护

• 处理生产故障

• 从项目中学习并改进实践

模型被集成到应用程序中，应用程序被交付到生产环境中。现在有人必须负责它了！除了处理旧的机器学习系统和照顾新的系统外，本章还讨论了项目完成后团队会发生什么。你和你团队如何从中学习，以及为了使下一个项目更好应该做些什么？

10.1 Sprint Ω待办事项列表

表 10.1 中的待办事项列表概述了在将系统交付到生产环境后，团队需要完成的工作。

表 10.1 Sprint Ω待办事项列表

任务编号	项目项
SΩ.1	识别机器学习特有的技术债务来源。  ▪ 验证模型性能（如适当）  ▪ 监控模型漂移  ▪ 检查模型过时
SΩ.2	识别和解决一般性的技术债务。
SΩ.3	进行项目后审查，以确定团队可以从你的项目中学习什么。
SΩ.4	寻找开发机器学习系统的新实践方法。
SΩ.5	识别团队可以使用的新技术以取得更大的成功。
SΩ.6	编写关于项目的案例研究，以记录和分享你的经验。

10.2 离开你的手，进入生产？

在第九章中，我们讨论了将机器学习模型集成到系统和生产中的过程。这个过程的主要活动包括构建监控、日志记录和警报系统，并就系统的治理流程达成一致。这个设置应该为你提供一个框架，以便在需要时支持系统。

目前，机器学习团队在生产中管理项目的趋势正在增加。这被称为左移，因为在流程图中，开发团队被视为左侧，将产品传递给右侧的支持团队。这个想法是，开发团队应该做更多支持团队的传统工作。这是因为小型公司现在支持软件开发，因为可用于生产团队的资本较少。此外，转向云意味着内部支持团队的许多担忧已经消失。没有服务器农场需要照料和浇水，这使得仅仅通过关闭它们就能实现巨大的节省。

当然，也有反论。为什么让机器学习团队负责生产中的系统，而不是让他们构建其他机器学习系统呢？一个答案是，有时机器学习系统需要专业技能来维持生产。另一个观点是，从与野外系统合作中可以学到宝贵的经验。经常维护生产项目的团队对未来开发过程中什么重要往往有不同的看法。还值得考虑的是，随着时间的推移，支持项目的团队自然会发生变化，初级员工可以作为一线支持为旧部署积累经验。

尽管有这些论点，当项目处于生产阶段时提供支持通常是机器学习项目的先决条件。当面对一个项目提案时，精明的首席信息官可以预见一个孤儿项目的形成。考虑到这一点以及你的组织可能只是将此视为你的日常工作，本章将讨论支持野外机器学习系统可能带来的挑战。

10.2.1 掌握要领

通常，团队会随着时间的推移逐渐积累对生产中模型的职责，而且经常没有人确切知道谁负责什么。一个团队很容易认为，尽管他们帮助修复和部署了一堆东西，但这些事情实际上是由其他人负责的。这意味着他们可以花时间做各种其他有趣的事情，而且，生活将会很美好。不幸的是，当这种模糊的观点被全面系统故障考验时，结果却是每个人都认为你应该对此负责。当这种情况发生时，生活立刻变得不再美好。

如果你花时间并投入资源来管理你的团队负责的机器学习系统，你会发现失败是罕见的，而且如果发生了，处理起来也容易得多。最重要的是，当你解释发生了什么以及如何处理它时，你会发现你看起来并不无能、缺乏组织，并且一般缺乏常识。因此，第一步是控制你的团队负责的系统。

你最终负责哪些系统？如果有任何疑问，请制作一个包含四列的列表（如表 10.2 所示），并将你的团队接触过或认为可能对它们有任何责任的系统全部放入其中。在表 10.2 中，有一个所有者列，这是系统的业务所有者，他声称该系统足够有价值以保留在生产中。在出现故障的情况下，那个人将是打电话给你的那个人。还有一个谁管理的列。这个表格的目的是让所有者同意在谁管理中列出的人是负责项目的责任人。

表 10.2 创建并维护一份您的责任清单，确保您的经理或主管可以访问它，并与他们一起检查以确保他们同意这是准确的。

系统名称	所有者	谁负责	备注
库存管理员	Karima	您	审查并良好 03/22
需求预测	Karima	您	审查并良好 03/33
建筑管理员	Alan	David	David 对此不确定
自动回复	Alan	您	没有治理
检查	Josep	David	David 同意
实体匹配器	Alan	您	没有治理
自动审查	Alan	您	上次审查 01/20

您的起始假设可能是您对这些系统负责，但如果可能的话，努力找到其他人来接管它们。与您的经理讨论这个过程。他们可能会证明他们很乐意在“谁负责”这一栏中填写替代人选。

在这个过程结束时，您将有一个关于您和团队责任的明确看法。虽然这可能令人畏惧，但比您开始时的位置要强得多。现在，您已经明确授权管理这些系统，您需要为每个系统组织审查：

• 是否有治理措施？如果没有，首先解决这个问题，并确保它得到适当的同意。

• 支持组织是否仍然是最新的和相关的？所有的人是否仍在生产后团队工作或在合同下提供支持？

• 文档是否仍然可用？这很容易检查。确定文档有意义的且有用的相对容易，但这可能需要一些专注的时间。

• 相关工具是否仍然可用？特别是，是否需要任何授权工具或专业硬件平台来处理系统数据（可能因为专有格式）或训练模型？

• 系统是否已经审查了生命终结问题？如果没有，那么进行审查。

• 系统的基础设施是否有即将到来的变化（如重新平台化）需要计划？如果是这样，那么制定一个计划。

• 如果系统失败，是否有明确的看法？修复它的方法是什么？

审查需要定期重复，因此如果组织还没有建立标准时间，那么这是一个好的做法。一个好的起点是一年。请注意，上一个列表中没有提到的一个问题是影响所有软件系统的问题，即技术债务的积累。机器学习系统尤其容易受到这个问题的影响，这个问题将在下文中详细讨论。

10.2.2 机器学习技术债务和模型漂移

技术债务描述了系统可能达到的最佳性能与其实际性能之间的差距。这个差距是系统积累的债务，以用户或其他系统额外工作的形式产生成本。

技术债务这一术语是由 Cunningham [1] 提出的，用以描述为了将早期敏捷项目投入生产所必需的妥协。自从 Cunningham 提出这个想法以来，它也用来描述随着时间的推移，围绕生产中的计算机系统积累的问题和问题的累积。软件是静态的；它不会随时间改变，然而，周围的世界却在变化。通常，当我们改变接口时会出现问题，导致不完整或失败的交互和数据流。Scully 及其合作者指出，机器学习系统尤其容易受到技术债务的影响 [2]，我们需要解决这里的一些具体形式的技术债务。

在遗留的机器学习系统中，缺乏有用的日志和监控系统是一种常见的技术债务形式。我们的优先事项需要包括检查记录系统活动的日志是否存在，是否有理解系统性能的机制，以及当系统失败时是否有向支持小组发出警报的系统。第九章包含了一些设置此系统的建议。这应该是一个优先事项，因为日志是任何故障排除练习的基础，对系统失败的早期预警可以大大减少修复它所涉及的压力。

在撰写本文时（2022 年），机器学习研究在算法设计方面正创造着相当多的创新。这在计算机科学和软件工程的其余部分发生得较慢。事实上，机器学习社区研究和开发的速度之快，导致旧方法被最新技术所超越，从而产生了技术债务。在承担机器学习系统的维护工作时，将其性能与新技术进行基准测试是值得的。几年后，将会有更稳健和高效的技术可用。从脆弱且易变的老模型转向稳健可靠的新模型的机会识别，可以为您和团队节省大量的痛苦。然而，最新和最优秀的技术可能只是时尚问题，而运行在生产环境中的旧模型可能确实有坚实的理由。正如我们在第八章中讨论的那样，使用稳健的评估和模型选择方法可以帮助证实这一点，无论是一方面还是另一方面。

通常，模型漂移是发现模型并不像之前认为的那样好。糟糕的测试和选择实践可能导致模型不足。如果你承担起一个机器学习系统的责任，审查它是如何被测试的是一个好主意。希望你会找到一些反映第七章和第八章中描述过程的优秀测试文档。在最佳情况下，可能不会有什么额外的事情让你感到惊讶。然而，如果你找不到适当测试的证据或证据不足，那么重新进行这项工作可以帮助你识别模型的弱点，并实施修复和改造计划。

随着模型周围的世界不断发展和变化，过去提取的模型可能越来越不适用，即使这些模型包含稳固的因果关系。当这些关系失败时，模型也会失败。这通常被称为概念漂移。例如，如果客户同时购买智能裤子和衬衫，然后全球大流行意味着他们需要在家工作，那么他们对智能裤子的需求一夜之间就会消失！推荐牛仔裤或慢跑裤可能更有效，但模型可能没有在没有干预的情况下适应的能力，因此其性能受损。当数据流到模型中的噪声水平和噪声类型发生变化时，比突然的因果关系变化更常见的是，这可能导致模型犯更多以前不重要的错误。

除了领域生成的变化之外，当模型所依赖的技术接口和基础设施更新时，模型性能通常会漂移。新的 API 看起来可能功能上与旧的一样，但它在什么和如何输入到模型中的微妙变化可能会逐渐改变其行为。有时这种行为被称为特征漂移。通过监控模型并对其行为建立断言，可以检测这种漂移。

相反，模型在没有引起任何人注意的情况下严重漂移是很常见的情况，直到事件突然迫使每个人都意识到发生了什么。这种偶然的发现并不好，因为它让与模型相关联的每个人都显得很糟糕，它破坏了对模型的更广泛的信任，并造成恐慌和混乱，这会消耗时间并破坏更广泛的工作计划。重新测试模型并监控输入给它的特征以确定是否存在变化或漂移是一个好主意。

10.2.3 重新训练

如果模型失败或者在你发现它失败之前检测到漂移，你将想要对此采取行动。这就是重新训练的用武之地。重新训练是指训练一个新模型以解决当前生产中模型的现有问题。为此需要以下四个组件：

• 新的（或旧的）建模方法: 通常，这是建模团队为创建出错的生成模型而开发的方法。然而，由于它出错可能表明需要不同的方法或算法。

• 新的训练集: 这涵盖了概念或特征集中漂移的部分，并充分捕捉了其余领域的其余部分。

• 测试数据或测试制度（可能是在线的）: 这捕捉了模型的行为——什么改变了，什么没有改变。

• 模型所有者或利益相关者的支持: 显然，必须构建、测试和部署一个新的模型。

需要强调的一个关键点是获取足够的训练和测试集的难度。团队可能会在拥有足够的数据来正确描述这种变化或训练一个新模型来捕捉它之前，就看到模型输入的显著变化。因此，早期检测模型漂移至关重要，这允许团队尽快采取行动，开发适当的测试并收集训练和测试所需的数据。

列表中的最后一项也很关键。重建和重新训练模型是一个重大的风险。对于依赖该模型的业务来说，移动的时间可能很重要，因此确保每个人都了解正在发生的事情、变化的影响以及模型何时将实施至关重要。再次强调，早期检测问题对于给你和团队时间收集足够的证据以接近利益相关者非常重要。这也让你能够管理不可避免的会议、电子邮件和电话会议的顺序，这些会议是必要的，以便就重新训练模型以使一切恢复正常的工作达成一致并启动。

10.2.4 在紧急情况下

虽然有很多审查和结构化的模型管理流程是非常好和令人放心的，但如果你早上 7 点接到电话怎么办？在电话中，你听到第四线支持无法修复系统，他们已经重启了四次，但系统仍然无法工作。此外，由于这个问题，业务无法交易。你的所有监控解决方案都没有检测到变化，而且你没有时间重建训练集或重新训练一个新模型来解决问题。

如果你从第九章准备的文档是充分的，并且支持团队同意了模型治理协议，那么一切应该都很顺利。有权有能且知道如何以系统化方式工作的人将能够有效地处理出现的问题。然而，情况并不总是如此。

有时，你可能会在早上与一个惊慌失措的 CIO 通话，因为这不是可用的。如果你发现自己处于这种困境中，那么你能做的最好的事情就是即兴发挥：

• 谁能帮忙？（召集一个工作组。）

• 你可以创建什么流程来推动这一进程？（建立监控通话并创建报告节奏。）

• 修复这个问题首先要做什么？

• 我们如何完成这项工作？（确保你立即采取行动来确定和消除任何问题。）

• 处理这种情况的其他选项有哪些？

跟踪寻找可以帮助的人，参与其中（尽管这可能需要成本），并整理事情。寻找备用计划，以防第一、最好的处理问题的方法失败。定期（可能是每小时）记录和报告活动。典型的做法是创建一个电子表格，记录所有建议的应对紧急情况的方法、由此产生的所有问题、任何超出修复的缓解措施以及已采取的行动。不要陷入连续失败的局面。相反，创建一系列的解决方案和修复方案，并在执行和消除这些方案时发送进度报告。

最后，不要因为系统似乎已修复而停止你的灾难管理活动。当然，当某种解决方案允许业务流程再次运转时，压力会立即缓解，但往往，另一个突然的失败就在转角处。将你已组建的工作组从关注解决当前问题转移到理解发生了什么以及需要做什么来防止其再次发生。

准备好答案，确保你不会在一周后的早上 7 点再次接到电话，这对你的健康和幸福至关重要。这还将帮助你导航接下来可能出现的审查中的问题。

10.2.5 复习中的问题

在代码红色、一级优先（P1）、消防演习或你组织赋予的全面、停止业务的生产失败之后，应该有一个 PIR（问题审查）流程。这是一个正式的活动，旨在调查发生了什么以及为什么。

暗示有时也涉及责任，但很可能在事情引起 CIO/CEO 注意后的五到六秒内就已经分配了。如果你被指责，我的建议是组织你的论点，专注于你在构建和照顾机器学习系统时所展现的过程和专业性：

• 不要让它变成一场对抗：要勤奋地保持专业。避免设定议程和安排会议。这不是法庭，但如果你把它变成法庭，你可能不会喜欢结果。

• 将会议引导回事实调查任务：阻止任何他/她说/她说的背后诽谤和责任分配。

• 仔细准备：确保你有清晰的日程安排，并且确切知道出了什么问题。

• 明确采取的行动以解决该问题：提供证据证明问题已得到解决。

• 反思从事件中学到的经验：如果你能，在会议之前通过实施对机器学习系统管理方式的改变来利用这些经验。

总结来说，如果你在开发系统后负责该系统，或者如果你被要求负责你组织中的其他系统，那么明智的做法是努力防止它们失败。你可以采用许多策略来做这件事，但了解你的系统运行得如何，并在事情严重出错之前对任何出现的问题发出早期警告是很重要的。

有时失败是不可避免的，事故确实会发生。如果你是事故的受害者，那么在应对时要有条理，并尽可能从组织其他成员那里获得支持。当你处于这种情况下时，事情会很艰难。很难记住你将走出困境；只要你向前看，并以条理清晰的专业方法来管理分配责任和解决问题，一切都会好起来的。

10.3 团队项目后评审

在项目交付并得到客户签字认可后，最简单且最重要的步骤可能是进行团队项目后评审。在评审之前，有必要收集每个团队成员的反馈并与团队其他成员分享。团队文化决定了这是否应该匿名进行或公开进行。在少数高级贡献者和更多初级贡献者组成的团队中，通常希望有一个匿名的过程，让初级人员能够发声。但一般来说，团队领导或经理是判断获取开放、尊重和建设性反馈的正确方法的最佳位置。

获取反馈的一种结构化方法是使用一个项目后评审模板，该模板针对项目管理和发展的几个方面。一个例子在表 10.3 中展示。团队中的每个成员都应该填写表格。

在一个运作良好且表现优异的团队中，获得有用和全面的反馈应该没有问题。在某些情况下，团队成员可能会自我审查，因为团队动态困难而不愿提出自己的意见。如果你认为这种情况正在发生，那么可以通过私下与每个团队成员单独交流，要求他们直接向你提供反馈来解决。不过，匿名直接进行这个过程并不是一个好主意，因为这可能会为破坏性和腐蚀性的贡献提供平台。尽管如此，这种方法给了那些感到边缘化的人发声的机会，这是好事。

表 10.3 团队项目后评审示例表格。评分从 1 到 5，其中 1 表示强烈不同意，5 表示强烈同意。

问题	评分（1-5）	备注
当我开始着手这个项目时，项目的目的和方向对我来说是清晰的。
资源是充足的。
时间表是现实的。
我们作为团队合作得很好。
我们与客户合作得很好。
项目的成果非常出色。
项目中最好的技术元素是什么？
什么没有奏效？
我们可以做得更好吗？
你会做出哪一项改变？

收集到团队的反馈后，你应该对其进行审查并汇编成一份演示文稿，你可以用它向团队展示。或者，让一个初级团队成员（在你的支持下）汇编并展示反馈，这可以为他们提供一个强大的发展机会。很多时候，如果初级成员展示反馈，资深工程师会感到更有资格参与并讨论项目中遇到的挑战的解决方案。一种展示过程价值并鼓励团队更多开放性和自我反思的好方法是在反馈演示文稿中从上一次项目审查中确定的问题列表开始，并说明在本项目周期中采取的解决这些问题的步骤。

重要的是要使团队能够对反馈做出反应，并相互讨论以评估所报告内容的重大性和有效性。一条评论可能引发一场具有挑战性和重要性的讨论，揭示关键问题。另一方面，团队的讨论可能揭示出在反馈中看似重要的事情只是任何人都可能想到要说的事情，对他们来说并不那么重要。这个过程的价值在于共同识别和拥有问题，认识到它们的存在，并承认应该采取行动，以及团队采取的行动来解决这些问题。

一旦获得并讨论了团队的反馈，你就可以构建一份关于项目的最终报告。即使这最终变成了一份非常简短的文档，它也是一件非常值得做的事情。如果有关于项目的后续事项，这份项目报告在建立背景方面可以极为有价值。为此，所需的任务是：

1. 使用最适合团队的方法收集反馈。建议使用如表 10.3 所示的表格形式的结构化表格。

2. 审查所有冲刺审查中 sad-mad-glad 过程的成果，并审查在此过程中收到的反馈。

3. 审查以前项目审查中纳入你在此项目实践中解决的问题和行动。

4. 创建一个涵盖步骤 1-3 的演示文稿。

5. 提前提供演示文稿和议程副本，与团队召开会议。议程中应包括讨论环节和下一步行动项，你可以在此处就团队确定采取行动的问题和解决这些问题的步骤达成一致。

10.4 改进实践

团队的评审和由此产生的行动将使你的实践得到发展，从而能够更一致地应用解决客户问题的方法。除了回顾项目中所发生的事情外，团队保持开放的心态，从世界其他地方汲取知识也同样重要。人工智能和信息系统的开发都是快速发展的领域，具有技术实践、变化和创新的经验周期。例如，我们在

• 1960 年代: 大型机、COBOL、FORTRAN 和 LISP。

• 1970 年代: 关系数据库管理系统（RDBMS）或 SQL、小型计算机（PDP-11、VAX）和 Prolog。

• 1980 年代: 工作站、个人计算机、微型计算机、精简指令集（RISC）、瀑布模型和第一代神经网络。

• 1990 年代: 局域网、广域网、面向对象设计（OOD）和统计机器学习（ML）。

• 2000 年代: 网络服务、万维网（World Wide Web）、社交网络、搜索、敏捷和多代理系统。

• 2010 年代: 大数据、移动计算（iPhone、Android）、DevOps 和深度学习/第二代神经网络。

为了应对客户挑战并创造支付账单的价值，团队培养持续学习的文化至关重要。作为团队经理，重要的是你要采取措施鼓励并使团队能够做到这一点。诱惑是将人员从项目转移到项目，并在开发项目时保持 100%的人员。这样做的结果是，你将会有强劲的收入数字，直到你如此努力驱动的资源离开。替换一个技术资源可能需要长达三到六个月或短至几周（有时甚至立即）。实际上，有技能和价值的资源往往很快就会离开团队。作为团队领导和经理，阻止这种情况发生符合你的利益。

你可以采用的一个核心策略是确保你的团队能够获得专业发展和培训的机会。当由于你无法控制的因素导致内部项目出现停顿和延迟时，这是理想的时间。培训不仅有助于防止你的团队离开，而且当你确保你的团队接受了培训并参与了其他发展活动时，这也是使他们更吸引客户的一种方式。使用新颖的技术方法、快速采用改进的工作实践以及详细了解和参与客户的业务领域，对所有支付你参与费用的人来说都具有商业价值。如果你看到机会在团队参与项目时提供一些培训，这是一个重要的要点。就像休假时间一样，如果需要，培训时间在参与期间是完全合法的。为了支持培训和开发，你应该在项目结束后使用这段时间来确保：

• 团队所有成员都有发展计划。

• 所有成员都有比项目交付范围更大的个人目标。

提供支持，鼓励团队参与外部团体和活动（聚会、圆桌会议、特殊兴趣小组等）。请注意，外部团体的联系人可能会试图招募你的团队成员。如果你的团队管理得当，你也在做好你的工作，他们很可能会失败！相反，你的团队（和你）在这些论坛中建立的联系人可能会为你提供未来的招募对象。确定团队成员的培训需求和差距，并与他们以及其他经理（如果需要）合作，确保确定适当的培训活动，并在可能的情况下安排。

10.5 新技术采用

如果团队需要新技术来交付客户项目，你必须将其纳入你的工作实践，但要注意。由个别团队成员引入的技术可能会成为重大问题。它们可能代表一个单点故障，在长期项目中管理它们，尤其是当最具创新精神的团队成员可能离开时，是具有挑战性的。此外，作为团队经理，你很难找到一个位置来向客户证明和解释这些选择。一个正式的程序可以帮助减轻这些问题。

此过程旨在阐述为什么需要新的方法，具体说明为什么选择这种方法，展示并发展对该方法（超越种子实现）的熟练度，并将知识传播到团队中（至少在某种程度上到团队经理那里）。为此：

1. 确定项目问题。同意需要创新。

2. 编制差距分析。这项技术试图实现什么？

3. 分析竞争对手。存在哪些其他方法可以使用？为什么这个方法更可取？

4. 提供一个概念验证或演示。你可能倾向于直接将应用应用于客户的问题，但通过首先实施和记录玩具版本，可以快速学到宝贵的经验。

5. 与同行审查技术。向团队展示并解释解决方案。

此过程通常在项目进行中发生，但有时问题会在项目回顾期间显现。如果当时有预算进行概念验证研究，那么就进行吧。采用新技术是项目在支付其执行咨询费用之外增加价值的良好迹象，这也为进一步的工作提供了很好的案例。

10.6 案例研究

成功且具有创新性的项目可以创造额外的价值，因为团队可以从他们的执行中提取可重用的工件（前提是存在适当的知识产权协议）。这使得随后的类似项目可以更快、更高质量、更低成本或更高利润地完成。

在某些情况下，一个项目可以成为典型案例研究的灵感来源。希望客户愿意被用作案例研究中的参考，并且通常合同会提供这种可能性。但如果之前没有达成协议，那么你必须去除项目的识别细节，并且可能需要将演示场景从客户的业务领域改变为具有共同内在挑战的不同背景。

在任何情况下，都需要努力将项目的焦点从实际实施的详细特征转移到解决问题的更广泛意义。这种从解决方案到案例研究的焦点转移使潜在客户能够看到在实施过程中创造了多少价值，而不是确定交付了多少价值，这往往非常具体于实施背景和细节。

10.7 再见，祝你好运

刀道是日本版的剑术，使用木棍和护甲来安全地模拟剑斗。一些刀道流派（通常是那些最残酷和最困难的流派）的一个信条是，只有从真正的战斗中归来，你才能教授新的技巧或改变教授技巧的方式。正因为如此，一些刀道流派的实践忠实保留了那些真正战斗过的人的学习成果。其中没有任何东西发生变化，刀道士们只是尽力相互学习。没有创新。很少有人想要真正的剑斗，而那些想要真正剑斗的人中，很少有人能够或愿意教授下一代这种技巧。

然而，机器学习（ML）则不同。它全是创新，但到目前为止，你和你的团队已经经历了一场真正的战斗。你们已经完成了一个项目，无论成功与否，你们都从自己的行动中学到了这本书无法教给你们的教训。尽管如此，你可以教授他人。不要害怕这样做；这是你能做的最好的事情之一。特别是，不要害羞地教我东西。伸出你的手，让我知道你的想法和你的创新。我需要像其他人一样听到它们。

摘要

• 很可能，团队会被要求支持他们开发的系统。随着时间的推移，这种需求可能会减少，其他人将承担剩余的任务。有时这些人是你们团队中的初级成员。

• 明确你负责支持的系统。记住，照顾它们的资源在组织中的某个地方已经分配，并且根据所有权利，它们应该流向责任所在的地方。

• 掌握你负责的系统。确保有适当的治理和支持安排，并且如果它们出错，有一个应对计划。定期审查所有系统。

• 识别并处理技术债务。特别是确保所有系统都得到适当的监控，以便你知道它们的行为方式，并在出现故障时可以获取信息进行故障排除。

• 如果系统出现故障，那么立即组织起来。召集一个团队来支持你，并尽可能快地修复它。

• 进行项目评审，以从发生的事情中学习，并支持团队的发展。

• 确保你的团队能够在项目发生的情况下获得学习和发展的机会。

• 对本书所涵盖的问题形成自己的观点，然后与我以及其他需要你洞察力以在未来取得成功的人分享。

参考文献

第一章

[1] LeCun, Yann, Yoshua Bengio, and Geoffrey Hinton. “深度学习。”自然 521, no. 7553 (2015): 436-444.

[2] Carpenter, Bob, Andrew Gelman, Matthew D. Hoffman, Daniel Lee, Ben Goodrich, Michael Betancourt, Marcus Brubaker, Jiqiang Guo, Peter Li, and Allen Riddell. “Stan：一种概率编程语言。”统计软件杂志第 76 卷，第 1 期（2017 年）。

[3] Gartner (2018)。www.gartner.com/en/newsroom/press-releases/2018-02-13-gartner-says-nearly-half-of-cios-are-planning-to-deploy-artificial-intelligence.

[4] Paleyes, Andrei, Raoul-Gabriel Urma, and Neil D. Lawrence. “部署机器学习中的挑战：案例研究综述。”ACM 计算评论 (CSUR) (2020)。

[5] Bender, Emily, Timnit Gebru, Angelina McMillan-Major, and Mitchell Margaret (2021)。 “关于随机鹦鹉的危险：语言模型可以太大吗？” FAccT’21，公平、问责和透明度 ACM 会议。加拿大虚拟活动：ACM 会议。610-623。dl.acm.org/doi/pdf/10.1145/3442188.3445922.

[6] Brown, T.B. 2020. “语言模型是少样本学习者。”ArXiv。5 月。访问日期：2021 年 1 月 29 日。arxiv.org/pdf/2005.14165.pdf.

[7] Jumper, J. Evans, R. et al. 2020. “Alphafold 2 演示。”预测中心。12. 访问日期：2021 年 1 月 29 日。predictioncenter.org/casp14/doc/presentations/2020_12_01_TS_predictor_AlphaFold2.pdf.

[8] Schrittwieser, J., Antonoglou, I., Hubert, T., et al. 2020. “通过学习模型进行规划以掌握 Atari、围棋、国际象棋和将棋。”ArXiv。2 月。访问日期：2021 年 1 月 29 日。arxiv.org/pdf/1911.08265.pdf.

[9] DALL-E (2022) huggingface.co/spaces/dalle-mini/dalle-mini.

[10] Marcus, Gary。 “深度学习：批判性评估。”ArXiv 预印本 ArXiv:1801.00631 (2018)。

[11] Kearns, M., and A. Roth (2019). 《社会意识算法设计的科学：道德算法》。牛津：牛津大学出版社。

[12] Wynants, Laure, Ben Van Calster, et al (2020)。 “用于诊断和预后新冠状病毒肺炎的预测模型：系统综述和批判性评估。”BMJ 369:m1328。

[13] Hawkins, Andrew J. (2021). “Elon Musk 刚刚意识到自动驾驶汽车是一个难题.” The Verge. 2021 年 7 月 5 日. www.theverge.com/2021/7/5/22563751/tesla-elon-musk-full-self-driving-admission-autopilot-crash.

[14] Wixom, B., Someh, I., and Gregory, R. (2020). “人工智能对齐：一种新的管理范式.” MIT 信息系统研究中心简报. 11 月. 访问于 2021 年 1 月 28 日. cisr.mit.edu/publication/2020_1101_AI-Alignment_WixomSomehGregory.

[15] Lu, Shen. “中国的新人工智能法律.” Protocol. 2022 年 3 月. www.protocol.com/bulletins/china-algorithm-rules-effective.

[16] Gaumond, Eve. 人工智能法案：欧洲对人工智能的应对方式是什么？ Lawfare, 2021 年 6 月.

[17] Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time. Penguin Books (2015).

[18] Huyen, C. (2020). 机器学习系统设计. 访问于 2020 年 10 月 1 日. github.com/chiphuyen/machine-learning-systems-design.

[19] Burkov, Andriy. 2020. 机器学习工程. www.mlebook.com/wiki/doku.php: 自出版.

[20] Claxton, Robert, Janki Vora, Franco Luka, H. Varvello, Humanshu Sharma, S.G. Thompson, and Emmanuel Otchere (2019). “IG1184 人工智能服务管理标准 R18. 1.” 访问于 2020 年 8 月 24 日. www.researchgate.net/publication/336364834_IG1184_Service_Management_Standards_for_AI_R18.

第二章

[1] Ada Lovelace 研究所. “审视黑盒.” Ada Lovelace 研究所. 2020 年 4 月. (于 2021 年 10 月访问).

[2] AI 事件数据库 (2020). incidentdatabase.ai/discover/index.html?s= (于 2021 年 1 月 27 日访问).

[3] 计算机协会 (ACM). AAAI/ACM 人工智能、伦理与社会会议. 2021 年 5 月. www.aies-conference.com/2021/ (会议宣传于 2021 年 1 月 28 日访问).

[4] Bender, Emily, Timnit Gebru, Angelina McMillan-Major, and Mitchell Margaret. “关于随机鹦鹉的危险：语言模型可以太大吗？” FAccT’21, ACM 公平、问责和透明度会议. 加拿大：ACM 会议 (2021). 610-623. dl.acm.org/doi/pdf/10.1145/3442188.3445922.

[5] 加拿大政府. 算法影响评估工具 (2020). www.canada.ca/en/government/system/digital-government/digital-government-innovations/responsible-use-ai/algorithmic-impact-assessment.html。

[6] Guus Schreiber, Hans Akkermans, Ango Anjewierden, Robert de Hoog, Nigel Shadbolt, Walter Van de Velde, 和 Bob Wielinga. 知识工程与管理. CommonKADS 方法论. 马萨诸塞州剑桥：麻省理工学院出版社（布拉德福德图书）(2000)。

[7] Hendrycks, Dan, Nicholas Carlini, John Schulman, 和 Jacob Steinhardt. 机器学习安全未解决的问题. 2021 年 9 月。 arxiv.org/pdf/2109.13916.pdf。

[8] ICO 英国. 关于人工智能审计框架的指南。咨询草案指南. ico.org.uk/media/about-the-ico/consultations/2617219/guidance-on-the-ai-auditing-framework-draft-for-consultation.pdf：英国信息专员办公室 (2020)。

[9] Kearns, M. 和 A. Roth. 伦理算法：社会意识算法设计的科学. 牛津：牛津大学出版社 (2019)。

[10] Sale, L. “美国的新卢德主义者。” 网络档案馆. 1997 年 2 月。 web.archive.org/web/20020630215254/http://mondediplo.com/1997/02/20luddites (访问日期：2021 年 1 月 28 日)。

[11] Springer Verlag. 人工智能伦理杂志. 2020 年 12 月。 www.springer.com/journal/43681 (访问日期：2021 年 1 月 28 日)。

[12] Verheyen, Gunther. “固定价格投标。 (2012)。 guntherverheyen.com/2012/10/07/fixed-price-bids-an-open-invitation-to-bribe-cajole-lie-and-cheat/ (访问日期：2020 年 4 月 8 日)。

[13] “谷歌解雇蒂姆尼特·格鲁布的真实事件。” Wired. 2021 年 6 月。 www.wired.com/story/google-timnit-gebru-ai-what-really-happened/ (访问日期：2021 年 7 月 14 日)。

第三章

[1] ICO 2016 数据保护影响评估。 ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-impact-assessments/

第四章

[1] Apache 项目 (2021)。 “Apache Airflow。” Apache.org。 访问日期：2021 年 1 月 11 日。 airflow.apache.org/。

[2] Bareinboim, Elias, and Judea Pearl (2016). “Causal inference and the data-fusion problem.” PNAS - Colloquium Paper 7345–7352.

[3] Beauchemin, M. (2017). “The Rise of the Data Engineer.” Medium.com. 20 Jan. Accessed Jan 11, 2021. medium.com/free-code-camp/the-rise-of-the-data-engineer-91be18f1e603.

[4] Beck, Ken et al. (2001). Manifesto for Agile Software Development. Accessed August 17, 2020. agilemanifesto.org.

[5] Bender, Emily, Timnit Gebru, Angelina McMillan-Major, and Mitchell Margaret (2021). “On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?” FAccT’21, ACM Conference on Fairness, Accountability and Transparency. Virtual Event, Canada: ACM Conferences. 610-623. dl.acm.org/doi/pdf/10.1145/3442188.3445922.

[6] Breck, E. Cai, S. Nielsen, E., Salib, M., Sculley, D. (2016). “The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction.” Neurips Workshop.

[7] Brown, A.W., Kaiser, K.A., & Allison, D.B. (2018). “Issues with Data and Analyses.” Proceedings of the National Academy of Sciences 115 (11): 2563-2570.

[8] Castro Fernandez, Raul, and Samuel Madden (2019). “Termite: A System for Tunneling through Heterogenous Data.” aiDM’19. Amsterdam: ACM.

[9] Farrugia, Ashley, Robert Claxton, and Simon Thompson (2016). “Towards social network analytics for understanding and managing enterprise data lakes.” IEEE/ACM International Conference on Advances in Social Networks Analysis and Mining (ASONAM) pp. 121. Davis, California: IEEE.

[10] Hynes, N., Sculley, D., & Terry, M. (2016). “The data linter: Lightweight, automated sanity checking for ml data sets.” NIPS MLSys Workshop.

[11] NASA (2020). “NASA Workmanship Standards.” March. Accessed September 18, 2020. archive.org/details/nasa-workmanship-standards.

[12] Provost, Nancy E. ElHady and Julien (2018). “A Systematic Survey on Sensor Failure Detection and Fault-Tolerance in Ambient Assisted Living.” Sensors (US National Library of Medicine (www.ncbi.nlm.nih.gov/pmc/articles/PMC6069464/)) 18 (7): 1991 (doi : 10.3390/s18071991).

[13] Robert M. Groves and Lars Lyberg (2010). “Total Survey Error. Past, Present and Future.” Public Opinion Quarterly 75 (5): 849-879.

[14] S.C. Misra, V. Kumar, U. Kumar (2009). “Identifying some important success factors in adopting agile software development practices.” Journal of Systems and Software 11 (82).

[15] Scaled Agile (2021). SAFe 5 for Lean Enterprise. www.scaledagileframework.com/.

[16] Subramaniam, Pranav, Yintong Ma, Chi Li, Ipsita Mohanty, 和 Raul Castro Fernandez (2022). “Comprehensive and Comprehensible Data Catalogs: The What, Who, Where, When, Why, and How of Metadata Management.” ArXiv. 一月. 访问时间 2022 年 1 月. arxiv.org/abs/2103.07532.

第五章

[1] Bareinboim, Elias, 和 Judea Pearl (2016). “Causal inference and the data-fusion problem.” PNAS - Colloquium Paper. 7345–7352.

[2] IETF (1992). RFC 1321. 访问时间 2022. www.ietf.org/rfc/rfc1321.txt.

[3] McDonald, Kent (2017). “What do user story conversations look like.” Agile Alliance. www.agilealliance.org/user-story-conversations/.

[4] Sculley, D., Holt, G., Golovin, E.D., Phillips, T., Edner,D., Chaudhary, V., Young, M., Crespo, J.F., & Dennison, D. (2015). “Hidden Technical Debt in Machine Learning Systems.” Neurips 2015 Workshops. papers.nips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf.

[5] Shorten, Connor, 和 Taghi M Khoshgoftaar (2019). “A survey on Image Data Augmentation for Deep Learning.” Journal of Big Data, 60.

第六章

[1] Ayling, J, 和 A Chapman. “AI & Ethics.” Putting AI ethics to work: Are the tools fit for purpose (2021). “doi.org/10.1007/s43681-021-00084-x”.

[2] Bernhardsson, Erik. “Spotify Annoy Readme.MD.” GitHub. (2020). github.com/spotify/annoy (访问时间 2022 年 3 月 9 日).

[3] Cook, D, 和 D. F. Swayne. Interactive and Dynamic Graphics for Data Analysis: With R and GGobi. Springer (2007).

[4] D’Amour, A., Katherine Heller, D. Moldovan, B. Adlam, 和 B. Alpanahi. “Underspecification presents challenges for credibility in modern machine learning.” ArXiv. 2020 年 11 月 6 日. arxiv.org/pdf/2011.03395.pdf (访问时间 2020 年 11 月 23 日).

[5] Johnson, Jeff, Douze Matthijs, 和 Jégou Hervé. “Billion-scale similarity search with gpus.” IEEE Transactions on Big Data (2019): 535-547.

[6] Lerner, Reuven. Pandas Workout. Manning (2021).

[7] Paskhaver, Boris. Pandas in Action. Manning , 2021.

[8] Ryu, C. Cran-R EDA Vignette. 2020 年 11 月 16 日. cran.r-project.org/web/packages/dlookr/vignettes/EDA.html (访问时间 2020 年 12 月 21 日).

[9] Soviany, P., R. T. Ionescu, P. Rota, 和 N. Sebe. “Cirriculum Learning: A Survey.” ArXiv (2021). arxiv.org/abs/2101.10382 (访问时间 2022 年 3 月).

[10] Tan, Mingxing, 和 Le Quoc. “Efficientnet: Rethinking model scaling for convolutional neural networks.” International Conference on Machine Learning (2019): 6105-6114.

[9] Mallen, J.I. 和 Bramer, M.A. (1994). “CUPID - 一个迭代知识发现框架。” 专家系统研究与开发第十一卷。

[7] Kuhn, M. 和 Johnson, K. (2019)。 特征工程与选择：预测模型的实际方法。 Chapman & Hall。

第十三章

[11] Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A.N., Kaiser, L. 和 Polosukhin, I.，. (2017)。 “ArXiv。” 注意力即所需 ArXiv. 预印本 ArXiv:1706.03762。 2021 年 3 月 22 日访问。arxiv.org/pdf/1706.03762.pdf。

[1] 陈天奇，郭宇。 “Xgboost：一个可扩展的树提升系统。” 在第 22 届 ACM SIGKDD 国际知识发现和数据挖掘会议论文集中，第 785-794 页，(2016)。

[2] Dua, D. 和 Graff, C. (2019). UCI 机器学习数据库, archive.ics.uci.edu/ml. 加利福尼亚大学，信息与计算机科学学院。欧文，加利福尼亚州*。

[10] Murphy, K.P. (2021). 概率机器学习：导论。 麻省理工学院出版社，马萨诸塞州，剑桥。

[4] Franco Scarselli, Marco Gori, Ah Chung Tsoi, Markus Hagenbuchner, Gabriele Monfardini。 (2009)。 “图神经网络模型。” 伍伦贡大学研究在线。 2021 年 3 月 22 日访问。persagen.com/files/misc/scarselli2009graph.pdf。

[12] Tukey, J.W. 探索性数据分析。 威斯利出版公司，伦敦 (1977)。

第八章

第七章

[8] LeCun, Yann, Leon Bottou, Genevieve Muller, B Orr, 和 Klaus Robert. (1998). “高效反向传播。” 在 G. Orr 和 K. Müller 编著的 神经网络：技巧与贸易 中。Springer。

[6] Jumper, J. Evans, R. 等。 (2020). “Alphafold 2 演示。” 预测中心。 第 12 页。2021 年 1 月 29 日访问。predictioncenter.org/casp14/doc/presentations/2020_12_01_TS_predictor_AlphaFold2.pdf。

[11] Torralba, Antonio, 和 Alexei Efros. “数据集偏差的无偏视角。” CVPR (2011)。1521-1528。

[5] H. Sepp, J. Schmidhuber. (1997)。 “长短期记忆。” 神经计算 9 (8) 1735-1780。

[12] Yan LeCun, Josh Bengio. (1995). “用于图像、语音和时间序列的卷积网络。” 在 M.A Arbib 编著的 大脑理论与神经网络手册 中，第 276-278 页。麻省理工学院出版社，马萨诸塞州，剑桥。

[13] Shorten, Connor, 和 Taghi M. Khoshgoftaar. “深度学习中图像数据增强综述。” 大数据杂志 6, 第 1 期 (2019): 1-48。

[3] Elsken, T., Metzen, J.H., Hutter, F. (2019)。 “神经架构搜索：综述。” 机器学习研究杂志 20 (1-21)。

[1] Aker, A., Grevenkamp, H., Mayer, S.J., Hamacher, M., Smets, A., Nti, A., Erdmann, J., Serong, J., Welpinhus, A., and Marchi, F. “Corpus of news articles annotated with article level sentiment.” Proceedings of theNewsIR’19 Workshop at SIGIR. Aker, A., Albakour, D. Barron-Cedeno, A., Dori-Hacohen, S., Martinez, M., Stray, J., Tipperman, S. (eds). Paris, France: SIGIR (2019). ceur-ws.org/Vol-2411/paper6.pdf.

[2] Habibullah, Mohammad Khan, and Jennifer Horkoff. “Non-functional requirements for machine learning: understanding current use and challenges in industry.” 021 IEEE 29th International Requirements Engineering Conference (RE). IEEE (2021): 13-21.

[3] Russo, D.J., et al. “A Tutorial on Thompson Sampling.” Foundations and Trends in Machine Learning (2018): 1-96.

[4] Slivkins, A. “Introduction to Multi-Armed Bandits.” ArXiv. September 2019. arxiv.org/pdf/1904.07272.pdf (accessed May 18th, 2021).

[5] Thompson, W. “On the Likelihood that one unknown probability exceeds another in the view of the evidence from two samples.” Biometrika (1933): 285-294.

[6] Velasquez, Mark, and Patrick Hester. “An analysis of multi-criteria decision making method.” International Journal of Operational Research (2013): 56-66.

第九章

[1] Ackerman, Evan. “Everything You Need to Know About NASA’s Perseverance Rover Landing on Mars.” IEE Spectrum. February 2021. spectrum.ieee.org/automaton/aerospace/robotic-exploration/nasa-perseverance-rover-landing-on-mars-overview (accessed March 25th, 2021).

[2] Adam-Bourdario, C., Cowan, G., Germain, C. Guyon, I., Rousseau, D. “The Higgs boson machine learning challenge.” JMLR: Workshop and Conference Proceedings HEPML 2014. JMLR, (2014). 42:19-55.

[3] Amershi, Saleema. “Guidelines for Human-AI Interaction.” CHI conference on human factors in computing systems. CHI, (2019). 1-13.

[4] Google. Tensorflow Serving. (2021). www.tensorflow.org/tfx/guide/serving.

[5] Hawkins, Andrew J. The Verge. Sept 18, 2020. www.theverge.com/2020/9/18/21445168/tesla-driver-sleeping-police-charged-canada-autopilot (accessed October 16, 2021).

[6] Liedtka, Jeanne. “Why Design Thinking Works.” Harvard Business Review, (2018): September-October.

[7] OpenVINO. OpenVINO 文档. (2022). docs.openvino.ai/latest/index.html.

[8]  Ostrower, John. 空气流。2019 年 3 月。 theaircurrent.com/aviation-safety/the-world-pulls-the-andon-cord-on-the-737-max/。

[9]  Ribeiro, Marco Tulio Correia. LIME。 (2021)。 github.com/marcotcr/lime。

[10]  Rudin, Cynthia. 停止解释高风险决策中的黑盒机器学习模型，转而使用可解释模型。 (2018)。 arxiv.org/abs/1811.10154 (访问日期：2021 年 10 月)。

[11]  Withington, Peter. Lisp 机。 (1991)。 pt.withy.org/publications/LispM.html。

[12]  Xei, M., Chen, H., Zhang, X.F., Guo, X. & Yu, Z.P. “Development of navigation system for autonomous vehicle to meet the DARPA urban grand challenge.” IEEE Intelligent Transport Systems. IEEE, (2007)。767-772。

第十章

[1]  Cunningham, W. “The WyCash Portfolio Management System,” Proc. OOPSLA, ACM, 1992; c2.com/doc/oopsla92.html。

[2]  Sculley, D., et al. “Machine Learning: The High-Interest Credit Card of Technical Debt.” Neurips workshop. (2014)。 static.googleusercontent.com/media/research.google.com/en//pubs/archive/43146.pdf。