·发表于 Towards Data Science ·阅读时间：23 分钟·2024 年 10 月 14 日
--
图片来源：Pavel Danilyuk： www.pexels.com/photo/a-robot-holding-a-flower-8438979/
数据科学为探索新概念并验证其可行性提供了丰富的机会，所有这些都是为了构建功能和产品背后的“智能”。然而，大多数机器学习（ML）项目都失败了！这不仅仅是因为工作的本质具有实验性。项目可能缺乏目的性，或者没有与实际问题相结合，而将机器学习整合到产品中需要致力于长期的解决问题、投资数据基础设施以及多方技术专家的参与。本文旨在帮助在规划阶段减少这些风险，快速失败，同时培养成为以产品为导向的数据科学家。
本文提供了一种规划机器学习（ML）产品的结构化方法，通过介绍产品设计文档的关键领域来进行讲解。我们将涵盖明确需求、理解数据限制以及定义成功标准等内容，这些内容决定了你构建成功机器学习产品的方式。这些文档应该具有灵活性，可以用来找出最适合你团队的方案。
我很幸运曾在初创公司工作，成为小型而灵活团队的一员，在这里，角色和责任通常是交叉的。我提到这一点是因为下面讨论的话题跨越了传统的边界，涉及项目管理、产品、UI/UX、市场营销等多个领域。我发现，那些能够跨越这些边界并以同理心进行协作的人，能够创造出优秀的产品，成为更好的同事。
为了说明这个过程，我们将通过一个假设的快递公司提出的功能请求来进行讲解：
“作为一家快递公司，我们希望提高在包裹预计延迟时，提前向用户发出警告的能力。”
本节旨在简洁地描述问题及项目动机。由于开发通常跨越数月或数年，这不仅能确保每个人从同一页面开始，尤其是在机器学习领域，它有助于你在面对挑战和实验失败时始终保持坚定。以项目启动为起点。鼓励开放合作，并努力揭示所有跨职能团队中的假设，确保从第一天起在产品战略和愿景上达成一致。
实际撰写陈述时，首先要用你自己的话重述问题。对我而言，将其写成长篇并逐渐缩减，使得聚焦于具体细节变得更容易。在我们的示例中，我们从一个功能需求开始。它提供了一些方向，但在具体要求上留有模糊空间。例如，“提高我们的能力”暗示着现有系统——我们是否能访问现有的数据集？“提前警告”虽然信息模糊，但表明如果包裹延迟，客户会收到主动提示。这些都对我们如何构建系统产生影响，并为评估项目的可行性提供了机会。
我们还需要理解项目背后的动机。虽然我们可以假设新功能将提供更好的用户体验，但商业机会在哪里？在定义问题时，始终要将其与更大的商业战略联系起来。例如，改进延迟通知不仅仅是为了构建一个更好的产品——它关系到减少客户流失和提高满意度，从而增强品牌忠诚度并降低支持成本。这才是你衡量项目成功的真正标准。
在团队中共同解决问题是所有工程师应该培养的技能——这不仅是面试过程中常常考察的内容，而且，正如之前所讨论的，它帮助设定项目和战略的期望，确保每个人自上而下都能认同。如果一开始就没有达成一致，可能会对项目造成灾难性的影响，甚至几年后仍然如此。不幸的是，这正是 Babylon 健康聊天机器人的命运。Babylon 的目标是通过使用人工智能提供准确的诊断，来彻底改革医疗保健。然而，令公司吃亏的是，它过于简化了医疗保健的复杂性，尤其是在不同地区和患者群体之间。例如，在英国，发烧症状可能意味着普通感冒，但在东南亚可能意味着更为严重的疾病。缺乏清晰性并对人工智能能力的过度承诺导致了系统实际能做的与现实世界医疗环境中所需的严重不匹配（sifted.eu/articles/the-rise-and-fall-of-babylon）。
在定义了问题及其重要性后，我们可以开始记录交付项目的需求并设定范围。这些需求通常分为两类：
-
功能性需求，即从用户的角度定义系统应做什么。这些需求直接关联到用户期望的功能和交互。
-
非功能性需求，即系统如何运行——性能、安全性、可扩展性和可用性。
如果你曾经使用过敏捷框架，你会熟悉用户故事——从用户的角度讲述功能的简短、简单的描述。我发现，作为团队共同定义这些需求是对齐的好方法，首先从记录功能性需求开始，确保从用户的角度出发。然后，将这些需求映射到用户旅程中，识别出机器学习模型能够提供价值的关键时刻。这种方法有助于在早期确立明确的边界，减少“范围蔓延”的可能性。如果你的项目没有传统的最终用户，或许你是在替代现有的流程？和一线人员交谈——无论是操作员工还是流程工程师，他们是你的领域专家。
从一组简单的故事中，我们可以构建可操作的模型需求：
用户将接收到什么信息？
作为一名等待交付的客户，我希望及时而清晰地收到关于我的包裹是否延迟或准时的通知，这样我可以相应地规划我的一天。
用户将如何收到警告？
作为一名等待交付的客户，我希望通过我偏好的通信渠道（短信或本地应用）接收关于我的包裹是否延迟的通知，这样我可以采取行动，而无需一直检查应用程序。
系统可以使用哪些用户特定的数据？
作为一名关注隐私的客户，我只希望使用诸如我的地址等必要的信息来预测我的包裹是否延迟。
如果做得对，这些需求应该能够约束你关于数据、模型和训练评估的决策。如果你发现存在冲突，可以根据用户影响和可行性进行权衡。让我们分析上面的用户故事，看看我们的机器学习策略会受到哪些约束：
用户将接收到什么信息？
- 如果仅需要延迟通知，模型可以保持简单（例如二分类）；更详细的输出需要更复杂的模型和额外的数据。
用户将如何收到警告？
- 实时警告需要低延迟的系统，这就对模型和预处理的复杂度提出了限制。
系统可以使用哪些用户特定的数据？
- 如果我们只能使用有限的用户特定信息，模型的准确性可能会受到影响。另一方面，使用更详细的用户特定数据需要获得用户同意，并增加了数据存储的复杂性，以便遵守数据隐私最佳实践和法规。
考虑用户促使我们在设计时将伦理和隐私嵌入其中，从而打造人们信任的产品。我们的训练数据是否导致包含偏见的输出，歧视某些用户群体？例如，低收入地区可能因基础设施较差而影响交付时间——这一点在数据中是否得到了公平反映？我们需要确保模型不会延续或放大现有的偏见。不幸的是，这类案例层出不穷，例如美国广泛使用的基于机器学习的再犯风险评估工具 COMPAS，它被证明高估了黑人被告的再犯风险，而低估了白人被告的风险（www.propublica.org/article/how-we-analyzed-the-compas-recidivism-algorithm）。
除了伦理，我们还需要考虑其他非功能性需求，比如性能和可解释性：
-
透明性与可解释性：我们将模型呈现为多少“黑箱”？错误预测或程序缺陷的后果是什么？这些问题并不容易回答。展示更多关于模型如何做出决策的信息需要强大的模型以及使用可解释的模型，如决策树。像 SHAP（Shapley 加性解释）和 LIME（局部可解释模型无关解释）这样的技术可以帮助解释不同特征如何影响预测，尽管这有可能让用户感到信息过载。在我们的示例中，告诉用户为什么一个包裹会被延迟是否能建立信任？通常，模型的可解释性能增加内部利益相关者的认同。
-
实时或批量处理：实时预测需要低延迟的基础设施和流式数据管道。批量预测则可以在定期的时间间隔内处理，通常对于不那么紧急的需求已经足够。选择实时预测或批量预测会影响解决方案的复杂性，并且会影响哪些模型适合部署。例如，简单的模型或优化技术可以减少延迟。稍后会详细讨论这个问题。
从营销中借来的一个技巧是创建用户画像。通常，这基于通过正式访谈和调查收集的市场研究，以了解用户的需求、行为和动机。然后根据共同的特征（如人口统计学、目标和挑战）进行细分。由此，我们可以为每个细分群体开发详细的档案，给他们起名字并赋予背景故事。在规划过程中，用户画像帮助我们理解模型预测将如何被接收，并在不同情境下引发的行动。
以莎拉为例，她是一个“忙碌的家长”角色。她优先考虑速度和简洁性。因此，她重视关于包裹延迟的及时简洁的通知。这意味着我们的模型应侧重于快速的二元预测（延迟或准时），而不是详细的输出。最后，由于莎拉更喜欢通过她的手机接收实时通知，模型需要无缝集成到低延迟的系统中，以便提供即时更新。
通过记录功能性和非功能性需求，我们定义了“我们在构建什么”以满足用户需求，并结合“为什么”这与业务目标相符。
现在是时候思考我们如何满足需求了。这从用机器学习（ML）术语来描述问题开始，记录输入类型（特征）、输出类型（预测）以及学习它们之间关系的策略。至少需要一些起点，我们知道这将是一个实验性的过程。
对于我们的例子，输入特征可能包括交通数据、天气报告或包裹详情，同时需要一个二元预测：“延迟”或“准时”。显然，我们的问题需要一个二元分类模型。对我们来说，这很简单，但对于其他产品背景，有多种方法可供选择：
监督学习模型：需要一个带标签的数据集进行训练。
-
分类模型：二元分类对于利益相关者来说容易实现和解释，非常适合最小可行产品（MVP）。但这会牺牲多类分类所提供的更细致的见解，比如我们案例中的延迟原因。然而，这通常需要更多的数据，意味着更高的成本和开发时间。
-
回归模型：如果目标是一个连续值，比如包裹延迟的准确时间（例如，“您的包裹将延迟 20 分钟”），回归模型将是合适的选择。这些输出也会受到更多不确定性的影响。
无监督学习模型：处理无标签数据。
-
聚类模型：在包裹延迟的背景下，聚类可以在探索阶段用于根据相似特征（如地区或常见交通问题）对交付进行分组。发现这些模式可以为产品改进提供信息，或指导用户细分，以便个性化功能/通知。
-
降维：对于具有大量特征空间的噪声数据集，可以使用主成分分析（PCA）或自动编码器等降维技术来减少计算成本和过拟合，通过使用较小的模型来牺牲一些特征上下文的损失。
生成模型：通过对标签数据和无标签数据的训练，生成新的数据。
-
生成对抗网络（GANs）：对于我们来说，GANs 可以有限地用于模拟一些稀有但影响深远的配送延迟场景，比如极端天气条件或突发交通事件，前提是需要容忍边缘案例。然而，这些网络因训练难度大、计算成本高而著名，并且需要确保生成的数据具有现实性。对于早期产品来说，这通常不太适用。
-
变分自编码器（VAEs）：VAEs 的使用场景与 GANs 相似，具有更高的控制能力，能更好地控制生成输出的范围。
-
大语言模型（LLMs）：如果我们想将基于文本的数据（如客户反馈或司机笔记）纳入预测，LLMs 可以帮助生成摘要或洞察。然而，实时处理是一个挑战，尤其是当计算负载很重时。
强化学习模型：这些模型通过与环境互动学习，并通过奖励或惩罚来接收反馈。对于一家配送公司，强化学习可以用于根据实际配送结果优化系统。然而，这对于最小可行产品（MVP）来说并不太适合。
在问题的初步框架设计中，随着我们从数据探索和早期模型训练中获得洞察，问题的定义会发生变化是很正常的。因此，首先从一个简单、可解释的模型开始，测试可行性。然后，通过增加更多的特征、调整超参数，逐步增加复杂性，再探索更复杂的模型，如集成方法或深度学习架构。这种方式既能保持较低的成本和开发时间，又能快速推向市场。
机器学习与传统软件开发在估算开发时间方面有显著区别，工作中的很大一部分是由实验组成的。在实验中，结果总是未知的，所需的实验次数也无法预料。这意味着你提供的任何估算都应该包括较大的预留时间，或者要有这样的期望：它会随时变化。如果产品特性不是至关重要的，我们可以通过从简单模型开始并为后续逐步改进做计划，来提供更紧凑的时间估算。
开发模型所需的时间是任何项目中的一项重大成本。根据我的经验，即使是简单模型的快速结果，在后续环节中也会带来巨大好处，允许你将工作交接给前端开发人员和运营团队。为此，我有一些建议。首先，快速失败，优先进行最少工作量、最大成功可能性的实验。然后根据你的学习成果调整计划。虽然这很明显，但人们确实很难接受失败。所以，要支持你的团队，这是过程的一部分。我的第二个建议是，做好调研！查找类似问题的例子以及它们是如何被解决的，或者没有解决的。尽管机器学习最近的火爆趋势让它变得更加流行，但这个领域已经存在很长时间了，而且十有八九已经有人至少在某种程度上解决了与你的问题相关的挑战。保持关注文献，使用像 Papers with Code、Hugging Face 的每日论文或 AlphaSignal 这样的站点，后者提供了一个很好的邮件通讯。对于数据库，可以尝试 Google Scholar、Web of Science 或 ResearchGate。令人沮丧的是，获取主要期刊的费用成为了进行全面文献回顾的一个重大障碍。Sci-Hub…
现在我们知道我们的“黑盒”会做什么，那么我们应该往里面放什么呢？是时候考虑数据了，根据我的经验，这是设计中最关键的一部分，关系到降低风险。目标是为获取足够的、相关的、高质量的数据创建一个早期的路线图。这包括训练数据、潜在的内部或外部数据源，以及评估数据的相关性、质量、完整性和覆盖范围。处理隐私问题，并规划数据的收集、存储和预处理，同时考虑应对类不平衡等限制的策略。
如果没有充分考虑项目的数据需求，你将面临预算爆炸并且永远无法完全交付的风险，特斯拉自动驾驶就是一个这样的例子。他们在数据收集方面的挑战突显了低估实际数据需求的风险。从一开始，系统就受到早期采用者车辆所捕获数据的限制，至今仍然缺乏实现真正自动驾驶所需的传感器深度（spectrum.ieee.org/tesla-autopilot-data-deluge）。
如果你正在开发的功能已经是手动过程的一部分，那么数据源的获取会变得容易得多。如果是这样，你可能已经有现有的数据集和性能基准。如果没有，可以从内部寻找。大多数组织都会收集大量的数据，可能是系统日志、CRM 数据或用户分析。然而请记住，垃圾进，垃圾出！如果数据集从一开始就没有为机器学习构建，通常会缺乏训练所需的质量。它们可能不够丰富，或无法完全代表手头的任务。
如果不成功，你需要向外部寻求帮助。从专为机器学习设计的高质量公开数据集开始，如 Kaggle、UCI ML 数据库和 Google Dataset Search。
如果特定问题的数据不可用，可以尝试更一般的公开数据集。浏览像恩隆邮件数据集（用于文本分析和自然语言处理）、政府人口普查数据（用于基于人口的研究）或商业发布的数据集，如 IMDb 电影评论数据集（用于情感分析）等数据泄漏。如果这也失败了，你可以开始从多个来源汇总数据来创建一个丰富的数据集。这可能涉及从电子表格、API，甚至是爬取网页中提取数据。无论哪种情况，挑战在于确保你的数据是干净的、一致的，并且格式适合机器学习的用途。
最坏的情况是，你从零开始，需要自己收集原始数据。特别是处理视频、图像或文本等非结构化数据时，这将非常昂贵且耗时。在某些情况下，数据收集可以通过进行调查、设置传感器或物联网设备，甚至发起众包标签挑战来实现自动化。
无论如何，手动标注几乎总是必要的。这里有许多高度推荐的现成解决方案，包括 LabelBox、Amazon SageMaker Ground Truth 和 Label Studio。它们都能加速标注过程，并帮助维持质量，即使在随机抽样的大数据集上也是如此。
如果还不清楚，随着你从内部数据源转向手动收集数据，构建适合机器学习的数据库的成本和复杂性会显著增加，项目的风险也会随之增加。虽然这不是项目的致命问题，但考虑你的时间表和预算限制是非常重要的。如果你只能收集一个小数据集，你可能只能采用较小的模型解决方案，或者对像 Hugging Face 和 Ollama 这样的基础模型进行微调。此外，确保你有一笔额外的预算来应对项目后期获取更多数据的需要。这一点很重要，因为理解项目所需的数据量只能通过解决机器学习问题来获得答案。因此，通过确保你有途径获取更多数据来提前缓解风险。常见的做法是引用“餐巾纸背面的估算”作为数据需求的合理估计。但这实际上只适用于一些非常明确的问题，如图像分类和传统的机器学习问题。
如果明显无法收集足够的数据，生成模型在产生合成训练数据方面取得了一些有限的成功。例如，美国运通公司开发的欺诈检测系统就采用了这种技术，通过模拟卡号和交易来检测与实际欺诈的差异或相似之处 (masterofcode.com/blog/generative-ai-for-fraud-detection)。
一旦建立了基础数据集，你需要了解其质量。我发现手动操作问题非常有效。它能提供关于有用特征和未来挑战的洞察，同时为模型性能设定现实的期望。在这个过程中，你还能早期发现数据质量问题和覆盖范围的漏洞。动手处理数据，积累领域知识，并注意以下几点：
-
数据的相关性：确保现有数据能反映你解决问题的努力。以我们的例子为例，交通报告和配送距离是有用的，但客户购买历史可能并不相关。识别数据的相关性有助于减少噪音，同时让较小的数据集和模型更有效。
-
数据质量：注意任何你发现的偏差、缺失数据或异常情况，这对后续构建数据预处理管道非常有用。
-
数据的完整性和覆盖面：检查数据是否充分覆盖所有相关的场景。以我们的例子为例，数据可能需要涵盖城市中心和更为偏远的地区，忽略这一点会影响模型的泛化能力。
-
类别不平衡：了解类别或目标变量的分布，以便在可能的情况下收集更多数据。希望在我们的案例中，“延迟”包裹将是一个稀有事件。在训练过程中，我们可以实施成本敏感学习来应对这一点。就个人而言，我总是通过像 SMOTE（合成少数类过采样技术）或自适应合成（ADASYN）采样等技术，在过采样少数类时获得更多成功。
-
数据的时效性：考虑数据需要多么实时才能做出准确的预测。例如，可能需要实时交通数据才能做出最准确的预测。
当涉及到更全面的质量分析时，探索性数据分析（EDA）是发现模式、识别异常以及更好理解数据分布的有效方法。我将在另外一篇文章中详细介绍 EDA，但通过可视化数据趋势、使用相关性矩阵以及理解异常值，可以揭示潜在的特征重要性或挑战。
最后，考虑不仅仅是解决眼前的问题——要考虑数据的长期价值。它是否可以用于未来的项目或扩展到其他模型？例如，交通和配送数据最终可以帮助优化整个物流链中的配送路线，从而提高效率并在长远来看降低成本。
在训练模型时，快速的性能提升往往会伴随着收益递减的阶段。这可能导致没有方向的试验和错误，同时打击士气。解决方案是什么？从一开始就定义“足够好”的训练指标，以确保达到最小的阈值，从而实现项目的业务目标。
为这些指标设定可接受的阈值需要对产品有广泛的了解，并具备沟通技术与业务观点之间差距的软技能。在敏捷方法中，我们将这些称为验收标准。这样做可以让我们快速推出最低规格的版本，然后进行迭代。
什么是业务指标？ 业务指标是衡量任何项目成功的真正标准。这些可以是降低客户支持成本或增加用户参与度，并在产品上线后进行衡量，因此也称为线上指标。在我们的例子中，如果准确率为 80%，但能减少 15%的客户服务成本，那可能是可以接受的。实际上，您应该使用单一模型和单一业务指标进行跟踪，这样可以保持项目的专注，并避免在何时成功交付的问题上产生歧义。您还需要确定如何跟踪这些指标，查找业务团队应该能够访问的内部仪表盘和分析工具，如果没有，可能就不是业务的驱动力。
平衡业务和技术指标：找到一个“足够好”的性能，首先要理解现实世界中事件的分布，然后将其与用户（因此也影响业务）的反应联系起来。以我们的快递员示例为例，我们期望延迟的包裹是一个罕见事件，因此对于我们的二分类器来说，存在类别不平衡。这使得仅使用准确度不合适，我们需要考虑用户对预测的反应：
-
假阳性（预测存在延迟但实际上没有）可能会给客户带来烦人的通知，但当包裹随后按时到达时， inconvenience 很小。避免假阳性意味着优先考虑高精度。
-
假阴性（未能预测到延迟）很可能会导致更高的客户挫败感，因为客户没有收到包裹且没有提前警告，降低了重复业务的机会，并增加了客户支持成本。避免假阴性意味着优先考虑高召回率。
对于我们的示例，业务可能更看重高召回率的模型。然而，对于准确度不足 100%的模型，仍然需要在精度和召回率之间取得平衡（我们不能通知每个客户包裹延迟）。这种权衡最适合通过 ROC 曲线来说明。对于所有分类问题，我们通过 F1 得分来衡量精度和召回率的平衡，对于不平衡的类别，我们可以扩展为加权 F1 得分。
平衡精度和召回率是一门精细的艺术，可能会对用户产生意想不到的后果。为了说明这一点，考虑像 Google 日历这样的服务，它提供公司和个人用户账户。为了减少经常收到假会议请求的企业的负担，工程师可能会优先考虑高精度的垃圾邮件过滤。这确保了大多数假会议会被正确标记为垃圾邮件，但也会以较低的召回率为代价，导致一些合法会议被错误标记为垃圾邮件。然而，对于个人账户来说，收到假会议请求的情况要少得多。随着账户使用时间的增长，由于模型召回率较低，合法会议被错误标记的风险变得显著。在这种情况下，用户对服务的负面看法会变得非常重要。
如果我们将我们的快递员示例视为回归任务，目标是预测延迟时间，那么像 MAE 和 MSE 这样的指标是合适的选择，它们对你的产品有略微不同的含义：
-
平均绝对误差（MAE）：这是一个直观的指标，用于衡量平均预测值与实际值的接近程度。因此，它是一个简单的指标，用于评估发送给用户的延迟估计的准确性。
-
均方误差（MSE）：由于差异被平方，这会更加惩罚较大的错误，因此如果延迟预测中的重大错误对用户满意度的影响更大，MSE 就显得很重要。然而，这也意味着该指标对离群值更为敏感。
如上所述，这是将模型指标转化为每个人都能理解的术语，并传达权衡的过程。这是一个协作过程，因为与用户和产品更接近的团队成员会更好地理解需要推动的业务指标。找到那个能够指引项目朝着同一方向前进的单一模型指标。
最后一点，我发现涉及机器学习的项目往往会过度承诺可以交付的内容。通常这种现象来自组织的高层，在那里产品或投资者之间会产生炒作。这对项目和你的理智都是不利的。应对这种情况的最佳方法是通过在设计中沟通现实的期望值，这些期望值与问题的复杂性相匹配。永远记住，承诺少一些，交付多一些总是更好。
到目前为止，我们已经涵盖了数据、模型和指标，并讨论了如何处理我们的功能需求。现在，是时候关注非功能需求，特别是可扩展性、性能、安全性和部署策略了。对于机器学习系统，这涉及到使用系统上下文或数据流图来记录系统架构。这些图表将关键组件表示为模块，定义了输入、转换和输出。展示系统各部分如何交互，包括数据摄取、处理管道、模型服务和用户界面。通过这种方式，确保了系统的模块化，使得团队可以在不影响整个管道的情况下，隔离并解决问题，随着数据量或用户需求的增长，从而最小化瓶颈或成本上升相关的风险。
一旦我们的模型训练完成，我们需要有一个计划，将模型部署到生产环境，使其能够被用户或下游系统访问。常见的方法是通过 REST API 暴露模型，其他服务或前端可以进行请求。对于实时应用，像 AWS Lambda 或 Google Cloud Functions 这样的无服务器平台非常适合低延迟（只需管理冷启动）。如果吞吐量是一个要求，那么可以使用批处理处理和可扩展的数据管道，如 AWS Batch 或 Apache Spark。我们可以将机器学习系统设计的考虑因素分解为以下几项：
基础设施和可扩展性：
首先，我们需要选择系统的基础设施。具体来说，我们将把系统部署在哪里：本地、云端，还是作为一种混合解决方案。云平台，如 AWS 或 Google Cloud，提供了基于需求的自动扩展，既可以垂直扩展（更大的机器），也可以水平扩展（增加更多的机器）。考虑系统如何应对 10 倍或 100 倍的数据量。Netflix 通过他们的技术博客提供了关于如何在大规模下运作的宝贵见解。例如，他们开源了他们的容器编排平台 Titus，Titus 自动化了在 AWS EC2 实例上通过自动扩展组部署成千上万的容器（netflixtechblog.com/auto-scaling-production-services-on-titus-1f3cd49f5cd7）。有时候，如果处理敏感数据，可能需要本地基础设施。这能提供更好的安全控制，但在维护和扩展时成本较高。无论如何，准备好使用基础设施即代码工具（如 Terraform 和 AWS CloudFormation）对基础设施进行版本控制，并实现自动化部署。
性能（吞吐量和延迟）：
对于实时预测，性能至关重要。有两个关键指标需要考虑：吞吐量，衡量系统每秒能够处理的请求数量（即每秒请求数）；延迟，衡量返回预测所需的时间。如果你预期使用相同的输入进行多次预测，则可以考虑为部分或整个管道添加缓存，以减少延迟。通常，水平扩展更为优先，以便在高峰时期响应流量激增并减少单点瓶颈。这强调了在系统设计过程中做出的关键决策将直接影响性能。例如，Uber 围绕 Cassandra 数据库构建了他们的核心服务，专门优化低延迟实时数据复制，确保快速访问相关数据。(www.uber.com/en-GB/blog/how-uber-optimized-cassandra-operations-at-scale/)。
安全性：
对于机器学习系统，安全性适用于用户请求的 API 认证。这通常是标准的做法，采用像 OAuth2 这样的认证方法，并通过速率限制、阻止 IP 地址列表和遵循 OWASP 标准来保护端点。此外，确保任何存储的用户数据在静态和传输过程中都经过加密，并且对于内部和外部用户都实施严格的访问控制策略。
监控与警报：
同样，考虑监控以维护系统健康至关重要。跟踪关键性能指标（KPI），如吞吐量、延迟和错误率，并设置警报，以便在这些指标低于可接受的阈值时通知工程师。这可以在服务器端（例如你的模型端点）或客户端（例如用户端）进行，以包括网络延迟。
成本考虑：
为了简化基础设施管理，基于云的系统成本可能迅速增加。首先估算处理数据、模型训练和服务所需的实例数量，并将这些与项目预算和不断增长的用户需求进行平衡。大多数云平台提供成本管理工具，帮助你跟踪支出并优化资源。
MLOps：
从一开始就要包含一个有效管理模型生命周期的计划。目标是加速模型迭代，自动化部署，并保持对指标和数据漂移的强大监控。这使你能够从简单做起，并迅速进行迭代！使用 Git 进行代码的版本控制，并使用 DVC（数据版本控制）来跟踪数据模型的变更。像 MLFlow 或 Weights & Biases 这样的工具跟踪实验，而 CI/CD 管道则自动化测试和部署。一旦部署，模型需要实时监控，使用像 Prometheus 和 Grafana 这样的工具来检测数据漂移等问题。
高级系统设计可以降低风险，确保你的团队能够适应并随着系统的成长而演化。这意味着设计一个与模型无关且能够扩展的系统，通过将系统分解为模块化组件，构建一个强大的架构，以支持快速试验与错误、可扩展的部署和有效的监控。
现在我们有了一种交付项目需求的方法，至少从机器学习的角度来看。为了完善我们的设计，我们现在可以概述一个产品原型，重点关注用户界面和体验（UI/UX）。在可能的情况下，原型应该是互动式的，验证该功能是否能为用户提供真正的价值，准备好在用户体验上进行迭代。由于我们知道机器学习是耗时且资源密集型的，你可以将模型设计和原型放在一边，而无需一个完整的机器学习组件。记录你将如何模拟这些输出，并测试端到端系统，详细描述在设计文档中原型制作所用的工具和方法。这一点非常重要，因为原型可能是你第一次收集反馈并完善设计的机会，可能会发展成 V1 版本。
为了模拟我们的机器学习，我们用一个简单的占位符替代预测并模拟输出。这可以简单地是生成随机预测或构建一个基于规则的系统。原型设计 UI/UX 涉及使用像 Figma 这样的设计工具创建原型，或者使用 Postman 和 Swagger 进行 API 原型设计。
一旦你的原型准备好，就让人们来体验它，无论你多么害羞。大公司通常有这方面的资源，但小团队也可以自己创建用户小组。我在当地大学取得了很好的成功——学生们喜欢参与新事物，亚马逊购物券也很有帮助！收集反馈，进行迭代，并开始基本的 A/B 测试。当你接近发布产品时，可以考虑更高级的方法，如多臂老虎机测试。
苹果有一篇很好的文章，作为用这种方式模拟机器学习的例子。在类似 Siri 的对话式数字助手的用户测试中，他们使用人类操作员来模拟一个原型助手，在对话风格上进行变化——如健谈、不健谈或模仿用户的风格。通过这种方式，他们展示了用户更喜欢那些模仿自己健谈程度的助手，从而提高了可信度和可爱度。所有这一切都无需投入大量的机器学习开发来测试用户体验（arxiv.org/abs/1904.01664）。
从中我们可以看出，模拟 ML 组件将重点放在结果上，使我们能够更改输出格式，测试正向和负向流程，并找到边缘情况。我们还可以衡量感知性能的限制，以及我们如何管理用户的挫败感，这对我们能够构建的模型的复杂性和基础设施成本有重要影响。所有这一切都不需要考虑模型的准确性。最后，内部分享原型有助于获得业务领导的支持，没有什么比把项目交到人们手中更能激发支持和承诺了。
当你进入开发和部署阶段时，你不可避免地会发现需求发生变化，实验会带来一些意想不到的结果。你需要进行迭代！通过版本控制记录变化，通过重新审视问题定义、重新评估数据质量和重新评估用户需求来整合反馈循环。这一过程从持续监控开始，随着产品的成熟，应用统计测试来检测预测分布的变化（数据漂移），以识别性能退化。实施在线学习来应对这一变化，或者如果可能的话，将用户反馈方法集成到 UI 中，以帮助揭示真实的偏见并建立信任，所谓的“人机协同”。首先积极寻求内部反馈，然后通过访谈和小组了解用户的反馈，了解他们如何与产品互动以及如何产生新的问题。使用 A/B 测试来比较你选择的模型版本，了解它对用户行为和相关产品/业务指标的影响。
ML 项目通过在整个模型生命周期中采用敏捷方法论能够带来好处，帮助我们管理 ML 中固有的不确定性和变化，这一切从规划过程开始。小步开始，快速测试，不要害怕快速失败。将其应用于规划和发现阶段，可以降低风险，同时交付一个不仅有效而且与用户产生共鸣的产品。