收益：
- 能够认识到与代码-数据-模型三重奏相关的机器学习的特殊挑战，并根据业务需求在线或批量打包和呈现模型。
- 能够实现渐进和回滚部署模式（影子、金丝雀、A/B、回滚）并向每个部署添加经过测试的回滚计划
- 通过评估阈值控制的 CI/CD 和模型注册，能够保持投入生产的模型的数据-代码-度量链接可追溯
让模型在笔记本中达到 95% 的准确率只是故事的一半。另一半（通常是困难的部分）是以可靠、可扩展和可维护的方式将该模型提供给真实用户。 MLOps（机器学习操作：将 ML 模型投入生产的学科）将软件工程的 DevOps 实践与 ML 的独特挑战结合起来。在本单元中，我们将介绍将模型投入生产的步骤以及人工智能如何在此过程中提供帮助。
为什么机器学习与常规软件不同？
在普通软件中，行为是在代码中；如果代码不改变，行为也不会改变。在机器学习中，行为取决于代码、数据和模型。这三个维度给 MLOps 带来了额外的挑战：
- 数据漂移：随着时间的推移，生产中的数据会偏离训练中的数据；该模型已过时。
- 您需要对三件事进行版本控制：代码、数据和模型——三者皆有。
- 无声失败：模型可能会失败，但不会崩溃，不会给出错误，只需产生错误的预测。发现这一点需要监控。
这就是为什么“工作模型”和“生产就绪模型”之间存在很大差异。
模型包装与呈现
将模型投入生产的第一步是将其打包：模型文件、必要的库、预处理代码和版本信息作为一个可重现的整体。容器化（例如 Docker：将应用程序及其所有依赖项放在一个隔离的盒子中）是这里的标准；它消除了“它在我的机器上运行”的问题。
服务模型的两种基本模式：
- 在线/实时（在线）：该模型位于 API 后面，为每个传入请求返回即时预测。低延迟至关重要。
- 批量：模型定期处理大型数据集（例如，在晚上为所有客户生成分数）。延迟并不重要，效率很重要。
哪一种是正确的取决于业务需求：在线即时推荐、每月批量风险评分。
提示：“实时”是一种成本，而不是默认值。如果结果将在数小时内使用，则批处理会更便宜且更简单。您真的需要即时答复吗？先问一下。
安全分发策略
直接向所有流量开放新模式是有风险的；如果错了，每个人都会受到影响。安全分发模式：
- 影子部署：新模型接收生产流量，但其预测不会向用户显示，仅记录下来。与旧模型进行比较，看看在真实数据中是否安全。
- 金丝雀部署：新模型首先向一小部分流量（例如 5%）推出；如果没有问题的话，就逐渐增加。
- A/B 测试：将两个模型并行呈现给真实用户，并比较业务指标（转化、点击）。
- 回滚：如果新模型出现问题，能够快速恢复到旧版本。每个部署都应该有一个回滚计划。
注意：没有回滚计划的部署是不完整的。当新模型在生产中出现意外行为时，能够在几分钟内恢复到旧版本可以保护用户。在部署之前对此进行测试。
弱方法/强方法
弱者：“该模型在测试中表现良好，我们上线了，并向所有人开放。”
Güçlü：“我们将模型容器化，将其标记为版本。首先，我们在生产流量的影子模式下运行它 3 天，将预测与旧模型进行比较 - 偏差是可以接受的。然后我们用 5% 金丝雀打开它，监控吞吐量指标和延迟。当没有问题时，我们逐渐将其增加到 100%。我们事先测试了回滚命令。”
不同之处在于：强方法是渐进的、有节制的、可逆的。每一步的风险都是有限的。
CI/CD 和自动化
ML中的CI/CD（持续集成/持续部署：自动测试和发布代码更改的管道）不仅涵盖代码，还涵盖数据和模型步骤。良好的 ML CI/CD 管道：在代码更改时运行测试、执行数据验证、重新训练模型（如有必要）、检查评估阈值，并且仅在阈值成立时才推进部署。 “训练是自动的，部署是基于阈值的”原则可以防止不良模型悄悄泄漏到生产中。
AI 在设置这些管道时非常有帮助：编写配置文件 (YAML) 草稿、测试用例、部署脚本。但您可以确定分配阈值（无论什么指标超过发布的值）和回滚策略；这些是商业风险决策。
再现性基础设施
为了在生产中重现模型的行为，模型注册表：保存哪个模型使用哪些数据和代码进行训练以及接收到哪些指标的记录。对于每个生产模型，以下内容应该是可跟踪的：训练数据版本、代码版本（git 提交）、超参数、评估分数和部署日期。当出现问题时，您应该能够回答“哪个模型使用哪些数据产生此预测？”的问题。几分钟之内。我们将在第 11 单元中加深这一点。
三个迷你箱子
案例 1 - 影子分布捕获的问题。推荐模型在测试中击败了旧模型。我们发现在影子模式下使用生产流量运行它会为特定用户群体（新用户）产生非常差的推荐 - 测试数据不足以代表该群体。该模型已被修复，但从未向用户显示过。如果直接打开的话，新的用户体验就会被打乱。
情况 2 - 不可撤销的分配。一个团队针对所有流量推出了新的定价模型，并且没有回滚计划。该模型出乎意料地将某些产品的定价非常便宜。由于流程尚未准备好，恢复到旧版本需要几个小时。收入遭受严重损失。此后，每个部署都添加了强制回滚测试。
案例 3 - 无声数据漂移。欺诈模式出现了几个月，没有出现任何错误。但欺诈者的策略发生了变化（数据漂移），模型的召回率悄然下降。没有人注意到，因为没有监控。一旦建立了预测分布监测小组，漂移现象就很早就显现出来了。我们将在第 8 单元介绍监控。
可复制模板
为此模型编写部署计划草案。模型：[它的作用]，用法：[在线还是批量？] 应包括：1) 打包（容器、版本控制）2) 增量部署策略（影子/金丝雀/A-B）及其原因3) 跟踪指标（业务+技术+延迟）4) 回滚计划以及如何测试5) 部署阈值（哪个指标应超过什么值）
检查此 ML CI/CD 管道：1) 数据验证是否在线？2) 部署是否可以在不保持评估阈值的情况下继续进行（不应该）？3) 回滚是否自动？4) 模型注册表中是否跟踪数据+代码+指标？线配置：[config]
帮助我决定在线演示还是批量演示是否适合此模型。结果将使用多长时间：[即时/分钟/小时/天]预期请求量：[数量]是否有延迟限制：[毫秒]就成本和复杂性而言，您会推荐哪一个？为什么？
为此模型编写回滚过程。- 哪些指标/阈值会触发性能不佳？- 回滚步骤是什么？- 回滚需要多长时间（目标）？- 在生产之前如何测试此过程？
演示模式表
标准
在线（实时）
批次
延迟
严重（毫秒）
微不足道的
用途
需要即时响应
周期分数
成本
高
低
复杂性
高
低
例子
直播推荐，诈骗
每月风险评分
常见错误
- 在没有检索计划的情况下分发。错误的模型会影响整个用户。
- 直接开放至100%流量。通过交错分布来限制风险。
- 不建立监控。该模型默默地产生错误，没有错误。
- 冗余实时演示。虽然批处理就足够了，但成本和复杂性却会增加。
- 不链接模型数据代码版本。您无法重现该问题。
- 自动发布，无分发门槛。坏模型悄然潜入。
综上所述
将模型转移到生产环境是一项不同的工程任务，而且通常比训练模型更困难。 ML 需要额外的纪律，因为它取决于代码-数据-模型三重奏：打包和版本控制、适合业务需求的交付模式（在线/批量）、渐进和可逆的部署、阈值控制的 CI/CD 和模型注册。人工智能是生成该基础设施的代码和配置的强大帮助；但分配门槛、回拨政策和风险决策由您决定。没有回滚计划的分发是不完整的。
应用任务
将模型容器化 (Docker) 并为其版本添加标签。根据您的业务需求决定是在线提供还是批量提供，并写下您的理由。记录分阶段部署计划（影子或金丝雀）和经过测试的回滚过程。确保在模型注册表中记录数据版本、代码提交和评估分数。
清单
- [ ] 模型已打包并版本化（容器+标签）。
- [ ] 根据业务需要选择呈现模式（在线/批量）。
- [ ] 实施分阶段部署策略（影子/金丝雀）。
- [ ] 回滚过程已编写并测试。
- [ ] CI/CD 在达到评估阈值之前不会提前部署。
- [ ] 模型注册表保存数据+代码+指标链接。