1.1.1 深度学习产品开发周期的阶段

深度学习开发周期通常始于业务机会，并由产品计划及其管理来推动。在此之后，周期通常经历四个阶段：数据探索、原型设计、产品化（部署到生产环境）和产品集成。让我们逐一介绍这些阶段，然后我们将看看其所涉及的各个角色（在图1.1中用人物图标表示）。

注意 后续每小节旁边括号中的数字与图1.1中的相同。

1.产品启动（1）

首先，业务利益相关者（产品负责人或项目经理）分析业务，并确定可以使用机器学习解决的潜在业务机会或问题。

2.数据探索（2）

在数据科学家对业务需求有清楚的了解后，就会开始与数据工程师合作，尽可能收集数据、进行标记，并构建数据集。数据收集可以包括搜索公开的可用数据和探索内部来源。还可能进行数据清洗。数据标注可以外包，也可以内部执行。

与后续阶段相比，数据探索的早期阶段是非结构化的，通常也是随意进行的。可能是一个Python脚本或Shell脚本，甚至是手动复制数据。数据科学家通常使用基于Web的数据分析应用程序，比如用Jupyter Notebook（开源；https://jupyter.org）、Amazon SageMaker Data Wrangler（https://aws.amazon.com/sagemaker/data-wrangler）和Databricks（www.databricks.com）来分析数据，不需要构建正式的数据收集流水线。

数据探索不仅重要，而且还是深度学习项目成功的关键因素。可用的相关数据越多，建立有效且高效的深度学习模型的可能性就越大。

3.研究和原型设计（3，4）

原型设计的目标是通过给定的数据找到最可行的算法或方法来满足业务需求（业务需求来自产品所有者）。在这个阶段，数据科学家可以与AI研究人员合作，使用之前数据探索阶段构建的数据集来提出和评估不同的训练算法。在这个阶段，数据科学家通常会试验多个想法，并建立概念验证（POC）模型来评估它们。

虽然新发布的算法通常会被考虑，但大多数算法都不会被采用。算法的准确性不是唯一需要考虑的因素，在评估算法时，还必须考虑计算资源需求、数据量和实现算法的代价。通常情况下，最实用的方法才会被最终采用。

需要注意的是，由于资源限制，研究人员并不总是会参与原型设计。通常情况下，数据科学家既进行研究工作，又建立概念验证。

你可能还注意到，在图1.1中，大的开发周期中有一个内循环（循环A）：产品启动>数据探索>深度学习研究>原型设计>模型>产品启动。这个循环的目的是通过构建概念验证模型，在早期阶段获得产品反馈。我们可能会多次进行这个循环，直到所有利益相关者（数据科学家、产品所有者）在用于满足业务需求的算法和数据上达成共识。

多次的惨痛教训告诉我们，在启动昂贵的生产过程（构建生产数据和训练流程以及托管模型）之前，必须先与产品团队或客户（与客户沟通更好）验证解决方案。深度学习项目的目标与任何其他软件开发项目没有区别，即解决业务需求。在早期阶段与产品团队审核方法可以避免后期出现的昂贵且令人沮丧的重做过程。

4.产品化（5）

产品化，也被称为“上线生产”，是使产品达到生产标准并准备被用户使用的过程。生产标准通常被定义为产品能够满足客户请求、承受一定级别的请求负载，并优雅地处理异常情况，如格式输入错误和请求超载。生产标准还包括一些后期工作，例如，持续的模型指标监控和评估、收集反馈和重新训练模型。

产品化是开发周期中工程化程度最高的部分，因为我们将在此时把原型实验转变为严肃的生产流程。产品化的待办事项列表可能包括：

● 构建数据流水线，重复地从不同数据源提取数据并使数据集保持版本化和持续更新。

● 构建数据预处理流水线，比如数据增强或丰富，并与外部标注工具集成。

● 对原型代码进行重构和Docker化，使其成为具备生产质量的模型训练代码。

● 通过版本控制和跟踪输入与输出，使训练和服务代码的结果可复现。例如，可以使训练代码报告训练元数据（训练日期和时间、持续时间、超参数）和模型元数据（性能指标、使用的数据和代码），以确保每个模型训练运行的全面可追溯性。

● 建立持续集成（Jenkins、GitLab CI）和持续部署，以自动化代码构建、验证和部署。

● 构建持续模型训练和评估流水线，使模型训练能够以可重复、可审计和可靠的方式自动使用最新的数据集生成模型。

● 构建模型部署流水线，自动发布通过质量门控的模型，使得模型服务组件可以访问它们，根据业务需求可以执行异步或实时的模型预测。模型服务组件托管模型并通过Web API提供对其的访问。

● 构建持续监控流水线，定期评估数据集、模型和模型服务性能，以检测潜在的特征漂移（数据分布变化）或模型性能下降（概念漂移），并提醒开发人员重新训练模型。

现在，产品化步骤有一个新的热门别名：MLOps（机器学习运营），这是一个模糊的概念，其定义对研究人员和专业人员来说尚不明确。我们认为MLOps的作用是弥合模型开发（实验）与生产环境中的运营（Ops）之间的鸿沟，以促进机器学习项目的产品化。例如，MLOps可以简化将机器学习模型引入生产环境并对其进行监控和维护的过程。

MLOps是一种根植于将DevOps的类似原则应用于软件开发的范例。它结合了三个学科：机器学习、软件工程（尤其是运维）和数据工程。通过MLOps的视角来看深度学习，请参见图1.2。

由于本书讨论的是如何构建支持ML运营的机器学习系统，我们不会详细介绍图1.2中所示的实践。但是，正如你所看到的，支持在生产中开发机器学习模型的工程工作是巨大的。与数据科学家在数据探索和模型原型设计阶段所做的工作相比，工具（软件）、工程标准和流程发生了巨大变化，变得更加复杂了。

现在，回到开发周期，你可能会注意到在图1.1中有另一个内部循环（循环B），从产品化（方框5）和模型到产品启动（方框1）。这是在将模型推理与AI应用程序集成之前，与产品团队进行的第二次审查。

我们的第二次审查（循环B）比较了原型设计和生产环境之间的模型和数据。我们希望确保模型的性能和可伸缩性（例如，模型服务能力）符合业务需求。

注意 推荐阅读以下两篇论文。如果你想了解更多关于MLOps的内容，它们是很好的起点：“Operationalizing Machine Learning：An Interview Study”（arXiv:2209.09125）和“Machine Learning Operations（MLOps）: Overview，Definition，and Architecture”（arXiv:2205.02302）。

5.产品集成（6）

产品开发周期的最后一步是将模型预测集成到AI应用程序中。通常的模式是将模型托管在深度学习系统的模型服务中（将在1.2.2节中讨论），并通过互联网发送模型预测请求来将业务应用逻辑与模型集成。

作为示例用户场景，聊天机器人用户通过键入或语音提出问题与聊天机器人用户界面进行交互。当聊天机器人应用程序接收到客户的输入时，它调用远程模型服务来运行模型预测，然后根据模型预测结果采取行动或回应客户。

除了将模型服务与应用程序逻辑集成在一起，这个阶段还涉及评估对产品重要的指标，例如点击率和流失率。优秀的ML特定指标（良好的精确度-召回率曲线）并不能总是保证满足业务需求。因此，在这个阶段，业务利益相关者通常会进行客户访谈和产品指标评估。