3. 模型生命周期总览

自动驾驶模型不是一次训练完成就固定不变的“静态产物”，而是一个持续演进、受控发布、可追溯、可回滚的工程对象。理解模型生命周期，核心不是记住七个阶段名称，而是看清每个阶段的输入、输出、准入门槛和治理责任。只有把阶段边界定义清楚，后续的版本管理、数据闭环、发布审批和退役决策才有统一语言。

一、核心原理：生命周期是一条受控流水线，而非线性步骤

从工程视角看，模型生命周期可以划分为七个主阶段：需求定义、数据采集、标注、训练、验证、部署、监控与退役。它们并非简单串行，而是存在多条反馈回路：验证不通过会回流到训练或标注；监控发现长尾失效会触发新一轮数据采集；退役决策又会反向影响需求定义中的能力边界。

每个阶段都应具备四个治理要素：阶段产物（如需求规格、数据集版本、模型权重、验证报告、发布包、监控指标）、准入条件（进入下一阶段必须满足的硬性标准）、责任人（谁签字放行）、可追溯标识（版本号、哈希、数据血缘）。缺少任一要素，生命周期就会退化为“口头流程”。

二、方法流程：七阶段的关键动作与准入门槛

需求定义阶段要产出可量化的能力边界，包括 ODD（运行设计域）、性能指标、安全约束和验收标准。例如“城市快速路白天晴天场景下，前车切入识别召回率不低于 99.5%”。没有量化指标，后续验证就失去判据。

数据采集阶段围绕 ODD 设计场景矩阵，覆盖常规、边缘和对抗场景，并记录传感器标定、时间同步和采集元数据。标注阶段则要建立标注规范、一致性校验和质检抽样机制，标注版本必须与采集批次绑定。

训练阶段输出模型权重、训练配置和指标曲线，必须固定随机种子、数据版本和代码提交号，保证可复现。验证阶段分为离线指标验证、仿真回放验证和实车封闭场地验证，三者通过后才允许进入部署。

部署阶段采用灰度发布和影子模式，先在小范围车队运行并对比新旧模型差异。监控与退役阶段持续跟踪线上指标漂移、失效场景和接管率，当模型被新版本替代或不再满足 ODD 要求时，执行受控退役并归档全部血缘信息。

三、案例场景：一次“验证回流”的真实治理过程

某项目在验证阶段发现，新模型在雨天夜间场景下的行人检测召回率从 98.7% 下降到 96.2%，未达到准入阈值。治理流程并未直接放行，而是触发回流：验证报告标注失效场景 → 数据团队补充雨天夜间采集批次 → 标注团队按新规范重标 → 训练团队重新训练并生成新权重 → 再次验证通过后才进入部署。

阶段流转记录（示例）
需求版本: REQ-2024-018   ODD: 城市快速路 + 雨天夜间
数据批次: DATA-2024-112  场景: 雨天夜间行人横穿
标注版本: LAB-2024-112   质检通过率: 99.1%
训练版本: TRN-2024-077   代码提交: a3f9c21
验证版本: VAL-2024-077   行人召回率: 99.3%  → 通过
部署版本: DEP-2024-077   灰度车队: 20 台
监控版本: MON-2024-077   接管率: 0.12 次/千公里

这个案例说明：生命周期治理的价值不在于“流程好看”，而在于当指标不达标时，系统能自动定位到具体阶段并触发正确的回流路径，而不是靠人工拍脑袋决定。

四、阶段职责与产物对照清单

五、常见误区与复盘要点

• 误区一：把生命周期当成线性流程。实际上验证、监控都会触发回流，必须显式设计反馈路径。
• 误区二：只管理模型权重，不管理数据版本。数据血缘断裂会导致问题无法复现，也无法追责。
• 误区三：部署即终点。没有监控和退役机制，模型会悄悄漂移，风险在线上累积。
• 误区四：准入门槛靠人工判断。门槛必须写成可执行的指标和检查项，才能自动化卡点。

综上，模型生命周期总览的价值在于建立一套共同语言：需求定义决定“做什么”，数据与标注决定“学什么”，训练与验证决定“能不能用”，部署与监控决定“用得安不安全”，退役决定“何时退出”。七个阶段环环相扣，任何一环缺少治理要素，整条流水线都会失去可控性。