本章内容概述：
- 什么是机器学习（ML）系统设计，为什么它如此难以定义，以及你可能在何时第一次接触到它。
- 我们认为谁将从阅读本书中受益，我们将提供哪些信息，以及本书的结构安排。
- 机器学习系统设计中有哪些有用的原则，以及最适合应用这些原则的时机。
机器学习（ML）系统设计是一个相对较新的术语，经常让行业从业者感到困惑。许多人发现很难为这个术语定义一个明确的职责范围，更不用说为相应的角色或职位起一个恰当的名称了。根据角色的不同，这项工作可能由机器学习工程师、软件工程师，甚至数据科学家完成，工作效率也可能有所不同。
虽然这些职位都是有效的，但我们认为，要成为机器学习系统设计的资深专家，必须整合来自各个背景的专业知识。请注意，尽管本书中讨论的一些内容是机器学习系统特有的，其他内容对于已经构建过非机器学习软件系统的读者来说也会很熟悉（你会在第2章、第13章和第16章找到这些信息）。这是因为，尽管机器学习系统设计是一个新的现象，它仍然基于经典的软件开发基础。
但首先，我们需要全面了解什么是机器学习系统设计。在本章开篇，我们将提出我们对机器学习系统设计的定义，并通过我们自己及同事的个人经验来加以说明；我们将描述这一职位的理想角色，并分享我们亲身经历的案例，解释为什么一致且连贯的机器学习系统设计方法能节省大量时间，并有助于实现短期的商业成功，这对于在早期阶段赢得同事对这种新工作方法的信任至关重要。
1.1 机器学习系统设计：你是什么？
如果你曾尝试在深度科技公司或大科技公司（“深度科技”通常指的是初创公司或大企业内部从事前沿技术研究和开发的研发单位，而“大科技公司”指的是全球最大、最具主导地位的科技公司，这些公司以其高标准的人才招聘和先进的工程文化闻名）申请机器学习工程师或经理职位，那么你可能会对“机器学习系统设计”这一术语感到熟悉。我们两位都有丰富的深度科技经验，因此在计划写这本书时，我们曾确信这个定义对每个人来说已经足够清晰，也没有理由在此做过多的阐述。
然而，在与不同的人交流并征求他们对大纲的意见后，我们发现这个术语本身引发了意见和解释上的分歧。或许这是因为，行业中一直以来都有一套明确的职位列表，这使得候选人可以相对清晰地理解他们申请的职位所涉及的职能和责任。软件工程师、研究工程师、机器学习工程师等职位，各自有一套经典的职能，在教科书中有详细阐述，并且在职位描述中表述得十分清楚。
那么，是否有一个与“机器学习系统设计”直接相关的职位名称呢？目前，尚不存在一个完全与我们在本书中描述的范围相关的职位，但如果你遇到一个担任这一职能的人，他们的职位很可能是数据科学家。
为了理解这种关系的本质，我们联系了多位在数据科学家岗位上工作的人，最终意识到这个角色意味着一个相当广泛和模糊的职责清单。确实，你可以找到10个不同的人在10个不同的公司担任数据科学家，询问他们的工作内容，最后你会听到10种完全不同的回答：
- 在Excel中创建数据透视表。
- 搭建一个10 PB的分布式集群。
- 构建一个实时计算机视觉系统。
- 部署多个聊天机器人。
- 在Tableau/Metabase/Looker/PowerBI中可视化数据。
- 编写SQL脚本。
- 运行A/B测试。
- 创建推荐系统。
- 与利益相关者进行沟通。
- 回答高层管理的提问。
正如你所见，一个简短且清晰的职位名称，背后却包含着一套五花八门的职能，已经发展成了一个“万金油”式的统一术语，用来描述那些超出数据工程师、机器学习工程师和研究工程师常见职能范围的工作。
在思考这一点时，我们发现，在机器学习系统设计（或者后来被称为机器学习系统设计）领域，情况恰恰相反：这里存在一个没有统一名称但有明确职能和责任的现象，所需要做的是组织这些职能，并将它们构建成一个有条理的、互相关联的职能结构。
在接下来的章节中，我们将提供我们对机器学习系统设计的理解，甚至提出一些非常规的观点和解决方案。但在深入之前，我们想提出我们自己的定义：
机器学习系统设计是一个复杂的、多步骤的过程，涉及设计、实现和维护基于机器学习的系统。它需要结合来自多个领域和角色的技术和技能，包括机器学习、软件工程、项目管理、产品管理和领导力。
图1.1展示了这一定义。
我们将“维护”一词用斜体突出显示，是因为我们认为机器学习系统设计并不在发布机器学习系统时结束。除了提供准确的预测并确保高效的决策制定外，您的系统还必须具有足够的可扩展性和灵活性，以便能够轻松适应不断变化的商业环境或其他内部和外部因素。因此，在系统上线之后，维护和微调您的机器学习系统将确保其长期的效率，这一点尤为重要，特别是在预算或容量限制严格的情况下。
然而，不仅仅是机器学习系统设计这个术语本身被那些阅读过本书概要或浏览过目录的人提出了疑问。我们收到了关于书中各个方面的大量问题，以下是我们认为最值得注意的一些问题：
- “数据科学家、机器学习工程师和软件工程师是不同的角色；为什么你们把它们融合在一起？”
- “我有点困惑，为什么一本关于机器学习系统的书会涉及数据收集和报告内容，这正是经典机器学习与数据科学的区别所在。”
- “我很惊讶大纲中没有提到MLOps，这是业界对你们所描述的许多组件（可重现性、测试、管道等）常用的术语。”
对我们而言，这些问题成了机器学习与数据科学之间、以及机器学习工程师与数据科学家之间混淆的另一个指示。我们有自己对这些问题的看法，但首先，让我们尝试澄清我们的陈述。
来自深度科技公司的我们，习惯称从事机器学习的人为机器学习工程师，但机器学习工程师与软件工程师之间的区别正变得越来越小，特别是有一些著名人士称机器学习为“软件2.0”（mng.bz/yoNe）。同时，数据科学家这个职位名称通常与从事产品分析、与指标、洞察等工作的人相关。（请注意，我们在这里讨论的是我们在深度科技公司中的经验，由于这些公司雇佣了成千上万的高素质专业人士，并逐渐为整个行业设定了标准，我们倾向于将这种做法视为标杆。）]()
当人们面试机器学习工程师职位时，他们通常会经历软件工程师的招聘流程，并加上一些附加部分，其中机器学习系统设计是最重要的内容之一。它用于挖掘候选人的专业知识、成熟度和概括复杂系统的能力，并将其分解成互相关联的任务模块。这并不是一个容易的练习，因为候选人只有40到45分钟的时间来展示他们如何设计一个面试官随机挑选的系统。
现代AI作家和哲学家Eliezer Yudkowsky曾写道：“学校里教的最危险的思维习惯是，即使你并不真正理解某事，也应该照搬别人说的。”（mng.bz/r1Zy）。这在一些公司的技术面试流程中非常适用：面试官提供一个难题，并期待候选人照着给出特定答案。面试者被录用后，成为自己的面试官，这种不良做法得到了进一步强化，公司继续雇佣那些能完美背诵来自各个领域知识片段的人。这些人是否真正理解全局，并没有得到保证，这是我们在自己进行面试时所遇到的情况。]()
我们面试并聘用了多家公司的机器学习工程师。有些人刚刚进入职业生涯，有些是经验丰富的专家，还有一些是从软件工程转行做机器学习的工程师。然而，在那些未能通过面试的人中，有一个共同的特点：在机器学习系统设计部分，他们过于关注细节，始终没有能够抓住更大的全局。
对我们来说，这些失败表明存在期望不匹配；作为年轻的招聘经理，我们曾确信一个懂得所有算法、工具和模式的人默认会是这个职位的好人选。但后来我们发现，有时人们根本无法将自己所掌握的知识片段组合成一个整合的视野。
此外，在真实环境中构建系统与在面试中讨论它们有着截然不同的难度。一个人可以学习数十个流行的机器学习系统设计问题（例如：“你会如何设计一个类似LinkedIn网站的职位推荐系统？”），但当类似的问题在实际工作中出现时，他却感到困惑。
但让我们暂时忽略面试部分。机器学习专家被雇佣是有原因的：公司需要他们来构建、维护、运营和改进系统——不仅仅是为了写一些代码或关闭Jira任务。企业需要可靠的机器学习系统来实现目标并解决问题。
构建机器学习系统需要广泛的技能组合。简而言之，负责人必须能够回答三个问题：
- 我们在构建什么？
- 系统的目标是什么？
- 我们应该如何构建它？
在实践中，这需要多个角色技能的结合：作为产品经理来理解主要目标并将其传达给同事和利益相关者，作为机器学习研究员来赋能系统，当然，还需要坚实的软件工程背景，使产品具有可用性、可维护性和可靠性。机器学习系统设计专家应该能够在全局思考的同时，也能深入到具体的局部问题中。
很少有人能够将所有这些技能以恰当的水平结合起来。然而，如今有很多机器学习系统正在被构建，总得有人来设计它们。根据我们的经验，机器学习系统的设计通常是由一位优秀的机器学习专家（因为这是机器学习）或一位经验丰富的软件工程师（因为这是一个系统）来完成的。他们能够完成工作，但往往在自己不擅长的领域遇到困难。
总的来说，关于机器学习系统设计的混乱，更多地出现在那些专业知识较少的候选人身上，以及那些希望找到“多面手”的招聘经理或招聘人员之间。然而，如果我们从高层管理人员或专家的角度来看，情况则要广阔得多。他们知道，你雇佣这些专业人才来构建、维护和改进机器学习系统，而他们在机器学习系统上的最终表现将成为其职业成长的最终衡量标准。
我们认为，机器学习系统设计专家的关键在于将数据科学家和软件工程师与具有学术机器学习经验的人结合起来。最终负责设计机器学习系统的人可能来自不同的背景——软件、实际机器学习、学术机器学习、数据研究等——我们希望通过我们的实践经验，辅以一些理论，帮助他们弥补知识的空白，将自己熟悉的领域系统化，并在缺乏宝贵经验的领域中变得更加自信。
1.1.1 为什么机器学习系统设计如此重要
虽然你可以使用MLOps作为构建和维护机器学习系统的工具集，但可以将机器学习系统设计视为一种蓝图，它可以在任何时候作为你可靠的参考，为系统提供可扩展性和灵活性（对构建模块及其相互连接的正确理解有助于识别瓶颈并流畅地解决其他问题）。最重要的是，它提供了一个框架，将你的整个系统紧密地结合在一起。
一些项目足够简单，不需要如此详细的方法。以建筑为例，你可能可以在没有初步蓝图的情况下建造一个小棚子。但当你的目标提高到建造房屋或摩天大楼时，你就不能不使用事先安排好的详细计划。机器学习系统设计是一种工程化方法，结合了来自多家公司的数百位专家的经验，涉及到许多项目，帮助你设计机器学习系统。
1.1.2 机器学习系统设计的根源
构建复杂的软件系统一直是一个挑战，组织不得不以某种方式将这个过程凝练出来。人们使用了通过抽象来管理复杂性的通用原则：构建低层次的模块，并将复杂性封装其中，把它们当作魔法黑盒，利用这些模块构建更高层次的模块，依此类推。
这个过程是有效的，但它有一个弱点：必须有人来决定所有这些模块的结构（哪些是最高层次的组件，它们的内部结构是什么，以及一直到最低层次的实现）。最负责任的决策通常由软件架构师做出——这些是有经验的工程师，他们与许多系统打过交道。
这种方法通常与瀑布模型（Waterfall methodology）和“前期设计大” （Big Design Upfront）范式相关联。换句话说，它假设软件项目在开始时比较缓慢，并且在编写实际系统代码之前会进行深入的分析和文档化。这种方法在过去是可靠的，但也具有惯性和官僚主义特征。在快速变化的世界中，项目可能在完成前就失去了原本的意义。
反对这种缓慢但稳定方法的人，往往是提倡所谓敏捷软件开发范式的人。敏捷软件开发宣言的作者（agilemanifesto.org/）提出了四个主要价值观：
- 个体与互动高于过程与工具
- 可工作的软件高于详尽的文档
- 客户协作高于合同谈判
- 响应变化高于遵循计划
换句话说，这些人公正地指出，许多软件系统在试图规划和文档化一切时，可能无法有效运作。当然，有时这种官僚主义是有意义的——例如，构建控制医疗设备或飞机的软件。但大多数软件工程师工作在其他类型的应用中——办公软件、娱乐软件、网站和移动应用。因此，软件架构师的角色就被视为缓慢且过时的——与迅速改变世界的黑客文化背道而驰，他们不需要整个架构师、经理和其他专家层级批准的规范文档。这种敏捷方法受到了硅谷黑客文化和成千上万成功创业公司的推广。即使是像Meta这样的大公司，也在努力保持这种文化——他们的内部座右铭是“快速行动，打破常规”。
让我们总结一下这个小小的历史概述：在某个时刻，行业面对了从由软件架构师主导的高度规范化的软件工程过程，到“打破层级”的混乱、无政府主义的黑客方式的整个谱系。正如常见的情况那样，这些东西发生了混合。更传统的公司趋向于变得更加敏捷，而大多数无政府主义的初创公司逐渐成熟，开始引入流程和分工角色。
这种混合导致了如今主导技术公司的一种共识：我们不再将所有决策都委托给像软件架构师这样专门的人员，而是让普通的软件工程师既设计系统又编写这些系统的代码。但这种自由并没有消除对决策的初始需求：仍然需要有人在结构安排上做出最终决定。有人必须负责系统设计。每个工程师可能在某些方面有参与，但看到整体的画面至关重要。
实现设计系统低层次部分的技能与设计正确系统的技能并不相同。这就是为什么深度技术公司往往有单独的面试环节来检查候选人在编写高效代码（也就是算法部分）和设计系统方面的技能：期望工程师能担任这两种角色。这两者之间的划分可能不同：通常，初级工程师是设计文档的静默阅读者，而高级工程师则是作者或积极的贡献者。
简而言之，达成了一种共识：一个扎实的软件工程师应该能够在不同的抽象层次上工作，从低层次的实现到高层次的架构决策。
到目前为止，我们所说的关于系统设计的定义适用于任何软件——我们没有提到与机器学习相关的内容。然而，并不是每个能够成功设计软件系统的人都能成功设计机器学习系统——这是一类非常特定的系统。在设计机器学习系统时，负责人应考虑许多与常规软件无关的方面。本书将重点讨论这些方面；对更一般的系统设计问题感兴趣的读者可以参考其他文献。
1.2 本书结构
尽管有几本书涉及系统设计，但关于机器学习系统设计的文献却很少。我们决定为这一领域做出贡献，弥合供需之间的差距。我们的目标是分享我们的知识和经验，帮助你将所知道的许多内容转化为一个整体系统。
本书的结构是一本全面的实用指南，旨在指导如何在各个领域构建复杂且正常运作的机器学习系统，无论你所在的公司规模如何。该指南包括：
- 总体框架，概述了一般的结构原则和构成这些系统的所有组件，并指出你可能会陷入的陷阱。
- 每个步骤可能需要的工具的低级检查表，并简要提醒这些工具的重要性。
- 本书的结构类似于检查表或手册，融入了我们自己经验中的一些故事。你可以一次性阅读，也可以在工作中遇到具体问题时随时查阅。
每一章都是每个机器学习系统必不可少的高层次检查表。请注意，虽然不是所有项目都必须完全满足其中的条目，但每个条目都必须记住并考虑到。
此外，每章还回答了给定条目为什么重要以及何时重要的问题。它还包括了框架的描述（适用于该条目的技术和工具）。这些描述是系统化的（而不仅仅是100个流行词的列表），尽管不一定详尽无遗，因为我们认为，经验丰富的读者能够将示例案例与他们自己的背景对比，从中得出结论。与此同时，我们尽量避免让本书变成一本典型的教材或经典的机器学习或深度学习课程。
我们来自不同（而且非常互补的）背景：我们俩都参与过机器学习项目，拥有超过20年的“经验”，在不同的角色、公司和环境中——从种子期初创公司到数十亿美元的大型跨国公司。有时我们作为独立贡献者长时间工作，其他时候我们的工作主要涉及快速团队扩展和指导有才华的年轻工程师。我们见证过，也参与过许多成功与失败、大规模收购和大规模裁员。我们也与朋友们讨论过许多机器学习项目的成功与失败。
但不管我们的背景如何不同，有一件事我们非常一致：机器学习项目几乎从未因为参与者不能正确使用算法而失败。失败可能有很多原因：任务方向错误或完全不必要、数据处理草率、无扩展性且没有增长潜力的解决方案——这个清单可以继续列下去。
有一个模式非常流行，以至于我们必须在书中的不同部分重复一些故事：一个深度专家集中精力在自己擅长的领域——可能会涉猎一些相关领域，但仍然看不到全局。结果，一些重要的细节被遗漏，导致项目失败、错过截止日期和预算超支。
虽然机器学习的书籍通常会提供“正确”的答案，但我们的主要目标恰恰相反。我们希望做的是教会你如何提出正确的问题。这些问题可能是你问自己、问队友、问用户、问利益相关者——你说了算。作为技术行业的专业人士，我们每个人都积累了大量有价值的信息，但并不总能将这些信息串联起来。这时，及时的提问能帮助我们将所有知识有序地整理起来。
我们将全书分为四个主要部分，使其结构与任何系统的生命周期相符——研究、创建、改进和维护。
前两部分基于机器学习系统设计的早期阶段。在第1部分中，我们将重点关注对系统需要解决的问题的总体认知和理解，并定义系统开发开始之前所需的步骤。这个阶段通常不涉及写代码，更多的是集中在小规模原型或概念验证上。第2部分深入探讨早期工作中的技术细节。这个阶段需要大量阅读和沟通，这对于理解问题、定义可能的解决方案框架和与其他项目参与者对齐期望至关重要。如果我们将机器学习系统比作人体，它类似于形成骨架的过程。
第三部分专注于中期步骤。在系统生命周期的这一阶段，负责工程师的工作安排通常发生变化。研究和沟通的时间大大减少，更多的是动手工作，实施和改进系统。在这里，我们将重点讨论如何在多个维度上增强系统的能力：坚固、准确、可靠。继续使用人体的比喻，系统在此时开始增长肌肉。
最后一部分专注于集成与增长。对于一个没有经验的观察者来说，系统似乎已经准备就绪，但这种印象是有误导性的。在系统成功上线之前，仍然有许多（主要是工程方面的）问题需要考虑。在软件世界中，系统失败通常不像土木工程中的灾难那样严重，但它仍然是一个不想看到的情况。所以，在这个阶段，你将学到如何使系统可靠、易维护并具备未来-proof性。如果你不厌倦人体的比喻，那么这里可以说，系统拥有了“大脑”和“智慧”，因为没有控制的力量只会带来麻烦。
总体来说，开头几章将包含更多的一般性信息，这些信息对于框定问题和为构建一个高效的机器学习系统奠定核心基础至关重要。不过，随着你深入阅读，本书的内容将变得更加复杂和深入，提供实际的示例和练习。从下一章开始，我们将介绍两个完全不同的虚构案例，这两个案例将在全书中贯穿始终。它们都需要机器学习系统来解决各自的问题，且随着你继续探索，两个案例将不断发展。
在本书的每一部分，我们始终倾向于直觉而非详尽无遗。构建机器学习系统有很多方面，每一个都值得单独成书。然而，我们不打算写一本关于数据收集与准备的书，另一本关于特征工程的书，再另一本关于指标的书。相反，我们描述的是冰山一角，并审视整体结构，同时通过引用重要的论文来支持我们的观点，以便读者可以熟悉顶层示例，并将自己的具体知识融入到提供的框架中。我们也不打算解释与特定库或引擎相关的细节。在某些章节中，我们会提到一些典型的示例，但它们仅用于说明高层次抽象的目的。
实际系统总是比我们在博客文章、会议演讲，当然也包括面试中看到的例子更复杂。对于所有这些场景，人们谈论的是高层次的抽象，但实际上，问题的复杂性常常隐藏在细节中。这就是为什么我们认为对问题解决有一定直觉是如此重要：成功的机器学习系统设计师不仅能识别食谱并复制它，还能根据公司特定的细节进行调整，毕竟这些细节有时会让一切发生翻转。
我们希望本书对以下人群有帮助：
- 准备面试机器学习工程师/经理职位的人
- 正在与现有复杂系统一起工作的软件工程师、工程经理和机器学习从业者，他们希望理解或改进这些系统
- 计划设计自己的机器学习系统或已经设计过一个系统并希望确认自己是否遗漏了关键部分的人
基于我们在此描述的哲学，本书不适合初学者阅读。我们期望读者已经熟悉机器学习基础（例如，能够理解本科生的机器学习教材）并精通应用编程（例如，遇到过一些真实的编程挑战，而不是在学习沙箱中）。如果没有这些基础，最好先学习相关基础资料再阅读本书。
1.3 机器学习系统设计原则何时能发挥作用
正如我们之前所说，应用这些原则对于构建足够复杂的系统至关重要，以应对多种失败模式。如果忽视这些原则，系统很可能会“脚踩泥潭”——它现在可能能正常工作，但不足以在现实环境的动态挑战下生存下来。这些挑战可能是纯技术性的（如果我们面对10倍的数据量怎么办？）、产品相关的（我们如何适应用户场景的变化？）、商业驱动的（如果收购后系统需要被纳入第三方软件栈怎么办？）、法律方面的（如果政府提出新的个人数据管理法规怎么办？）或其他任何方面。近年来的经验只证明了我们无法预见每一个潜在的风险。
提升系统的能力更加重要。正如我们将在接下来的章节中详细描述的那样，从零开始构建系统是一件相对罕见的事情。行业外的人可能认为软件工程师大部分时间都在写代码，但实际上，正如我们所知，大部分时间都在阅读代码。系统也是如此：通常，花费更多时间的是改善和维护现有系统（这需要对系统内部结构有深入的理解），而不是从头开始构建系统。
“改进”和“维护”之间的界限有些模糊。为了明确起见，在这里我们将“改进”定义为添加新功能或大幅修改现有功能，而“维护”则定义为在不断变化的环境中（新客户、新数据集、基础设施演变等）保持现有功能的正常运作。
本书中包含的一些原则主要集中在机器学习系统的改进上。它们帮助识别系统的弱点和增长点，有时甚至是新的应用场景。
最后，有些原则更多地面向机器学习系统的维护。一个令人遗憾的事实是，系统维护通常由未参与系统建设的团队进行。因此，这是一把双刃剑：建设团队应牢记一些原则，以简化后续团队的工作，而维护团队则应理解这些原则，以便及时理解整个系统逻辑，并找到合适的解决办法，以确保系统能够长期运作。
可以肯定地说，几乎所有没有良好设计文档的机器学习项目都失败了，而那些经过充分规划的系统则大多成功。尽管设计文档不一定需要复杂且篇幅庞大，通常几页简明的信息就足够了，但在这种情况下，设计文档起到了两个主要作用。它不仅能够在项目中设定正确的优先级，还能够帮助你判断是否真的需要这个项目，并把你的注意力从核心想法上移开（你可能过于专注于项目本身），从而看清全局。有关详情，请参见第4章。
通过为多家企业工作，我们可以坚定地说，一旦有了描述系统功能各个方面的结构化文档，任何活动，从新员工入职到应用核心更改，都能迅速实施。你不再需要寻找那位掌握所有知识的“知识大师”（即便他可能无法保证准确性），而是可以直接查阅图书馆中的某个文档。
来自阿尔谢尼的篝火故事
很久以前，我曾为一家打车服务公司工作。该公司有一个雄心勃勃的项目——构建一个打车费用估算系统。传统的定价模型与老式出租车收费方式完全相同：费用 = X * 时间 + Y * 距离。公司需要在实际行程开始前估算出费用，以便同时通知司机和乘客。
这个项目从一开始就看起来简单明了。我们所需要做的就是拟合一个简单的模型，利用地图服务中的地理特征，并将其包装成一个微服务。看起来如此简单，以至于我甚至没想到要写设计文档。
系统最初在阿尔谢尼脑海中的样子：一个简单的逐步算法
实际上，系统中存在多个陷阱（我们将在接下来的章节中分别讨论大部分问题）：
- 地理特征不足以提供精确的估算，更多复杂的特征需要先进的基础设施（即特征存储，尽管在那个时候，这并不是一个流行的术语或模式）。这一点将在第11章讨论。
- 随着模型变得更加复杂，其预测结果的可靠性降低（某些结果会变成异常值——即那些过大或过小的数值）。
- 错误并不是均匀分布的，因此模型存在偏差。我们将在第9章涉及这个话题。
- 高管有时希望通过一些促销活动或基于启发式的捷径来覆盖打车费用估算。这个问题将在第13章讨论。
- 花费过多时间构建一个并没有解决实际问题的模型。我们将在第2章讨论这一点。
- 整个问题容易受到分布漂移的影响，因此需要智能监控。我们将在第14章深入探讨这一话题。
- 基础设施并未为该场景做好准备，导致高峰时段存在不可接受的延迟。这个问题将在第15章讨论。
- 一些其他团队并未意识到该系统正在开发中，这导致了API的不匹配。这个问题将在第16章讨论。
系统经历几次迭代后的样子
最终，系统并未上线——在所有问题得到解决之前，市场情况发生了重大变化，最初的系统需求也逐渐消失。虽然最初的系统构思很不错（一些竞争对手使用了类似的想法），但我和我的同事未能以正确的方式实现它：一些关键方面，既有技术的，也有产品相关的，完全被忽视，并且直到项目的后期才被发现，此时变更的成本已经飙升。同时，如果在早期阶段就考虑到这些方面，解决起来将会非常简单。如果我、我的老板或我的队友曾经读过这样一本书，我们本可以避免这个失败。
然而，每几个失败的故事背后，总会有一个成功的故事。接下来的故事没有那么戏剧化，可能看起来有些乏味，但为了保持平衡，还是值得分享的。曾经，Valeriy 在俄罗斯科技巨头 Yandex 工作，当时 Yandex 收购了一家提供实时推荐的初创公司。当这种合并发生时，通常需要时间来微调现有单位与新单位之间的合作，培训新员工，同步业务流程等。然而，在这个案例中，他惊讶于新业务是如何如此顺利和无缝地融入到这家庞大的公司中的。背后的原因是，一份精心编写的设计文档使得这一过渡成为可能。
总的来说，我们坚信，安排一份设计文档，并在此之前提出正确的业务问题、设定适当的目标，是成功设计 ML 系统的关键——或者在项目的最早阶段取消项目，这也是一种积极的结果，因为通过放弃不必要的活动，你可以节省大量的时间、精力和金钱。我们将为这个阶段的工作专门撰写至少三章内容，因为这是你需要应对的最关键部分。
总结
尽管“ML 系统设计”是一个相对较新的术语，但它基于经典的软件开发基础，融合了相关学科的现有知识。在本书中，我们将试图将这些知识基础重组为一套可行的算法。
尽管 MLOps 可以被视为构建和维护 ML 系统的一组工具，但 ML 系统设计可以看作是一个框架，它将整个系统有机地连接在一起。
要成功设计 ML 系统，至关重要的是要在 ML、软件工程、项目管理、产品管理和领导力等多个学科中都有经验。
在设计 ML 系统之前，你需要知道你在构建什么，这个系统的目的是什么，以及它应该如何构建。
成功设计 ML 系统的支柱是：一致的方式、良好规划的路线图以及一份初步行动清单，这将组织你的工作并节省长期时间。
