概述
它描述了系统的持续责任，而不仅仅是完成训练运行。每个阶段都需要可以追溯到特定版本的证据。
主要要点
- 在整个生命周期中分配所有权。
- 对完整系统配置进行版本控制。
- 计划监控、回滚和退役。
深入探讨
从一个目的、负责任的所有者开始，并决定是否需要模型。定义操作条件以及导致该项目不适合的原因。这可以防止技术上有趣的实验成为没有明确用例的服务。对数据、预处理、模型、提示和评估材料进行版本控制。这些组件相互作用：改变特征计算或检索索引可以改变行为而不改变模型权重。发布记录应标识完整的配置。在可行的情况下逐步部署，与之前的版本进行比较，并保留回滚路线。测试启动、取消、超时、依赖失败以及与现有客户端的兼容性。运营准备情况包括周围的服务和对事件做出响应的人员。部署后，监视系统运行状况和任务结果。定义谁审查警报、何时重新培训或更换是合理的以及旧版本如何停用。删除模型文件不会自动删除保留的输入数据、缓存的输出或依赖服务。明确跟踪这些资产。
04工作示例
追踪无声的回归
想象一下，一个需求模型根据美元价格进行训练，而新服务则以美分价格发送价格。
模型文件未更改，但输入乘以 100。输入范围检查可以在依赖预测之前检测到不匹配。
恢复兼容的预处理版本并将事件添加为回归测试。
它显示了什么
这个假设的失败说明了为什么生命周期管理包括数据契约和依赖关系。
现实世界的实施
存储将模型链接到其功能管道和评估集的发布清单。
使用具有显式回滚阈值的分阶段部署。
付诸实践
为什么这很重要
- 更清晰的判决. 它可以帮助您将清晰的技术声明与营销语言分开。
- 成本与预算. 在花费金钱或时间之前，您可以提出更好的实施问题。
- 团队与工作流程. 具有共同理解的团队可以做出更好的产品、政策和学习决策。
留意
- 不同的团队可能会以不同的方式使用同一术语，因此请尽早定义范围。
- 基准测试可能看起来很强大，但实际性能却参差不齐。
- 忽视数据质量和评估计划通常会产生脆弱的结果。
后续步骤
- 从您需要的结果的简单语言定义开始。
- 在测试之前选择一种成功指标和一种失败条件。
- 使用代表性数据运行小型试点，而不是完善的演示集。
- 记录模型生命周期在哪些方面有帮助以及在哪些方面更简单的方法更好。
资料来源与延伸阅读
- Google ResearchML 测试分数：ML 生产准备情况和技术债务减少的评分标准
不断探索
常见问题
部署是模型开发的终点吗？
不会。监控、事件响应、数据更改和退役仍然是负责任地操作系统的一部分。