1. 课程导入

自动驾驶系统不是“训练出一个模型就结束”的软件项目。它更像一条持续运转的工业流水线：数据从车端回传，经过清洗、标注、训练、评测、封装、灰度发布，最终以可追溯、可回滚、可审计的方式进入量产车辆。任何一个环节失控，都可能把“实验室里表现良好”的模型，变成道路上的安全风险。因此，本课程关注的不是单点算法技巧，而是模型从产生到退役的全生命周期治理，以及发布过程中的工程控制。

一、核心概念：生命周期与发布治理

模型生命周期指一个模型从需求定义、数据准备、训练、验证、封装、部署、监控到退役的完整过程。它强调“每个阶段都有输入、输出和准入条件”，而不是把训练脚本当作全部。对自动驾驶而言，生命周期中最关键的特征是闭环：车端数据驱动模型迭代，模型又通过发布影响车端行为，行为结果再产生新数据。

发布治理则是生命周期中“从内部资产到外部风险”的闸门。它回答四个问题：发布什么版本？依据什么评测？以多大范围、多快速度放量？出现问题如何回滚和追责？在自动驾驶领域，发布治理不是运维附属品，而是安全体系的一部分。它通常包括版本管理、评测基线、灰度策略、监控告警、回滚预案和审计记录。

可以用一个简化的关系来理解：生命周期解决“模型怎么造出来”，发布治理解决“模型怎么安全地交出去”。两者共同构成模型工程的主干。

二、方法流程：一条可执行的发布链路

把上述概念落到工程上，一条典型的自动驾驶模型发布链路可以拆成七步。每一步都必须有明确的“准入”和“准出”条件，否则发布就会退化为“谁着急谁先上”。

1. 需求与风险定义：明确本次模型要解决什么场景问题，涉及哪些安全等级，哪些指标不允许退化。
2. 数据与标注冻结：确定训练集、验证集、回归集版本，避免“数据悄悄变了，模型结果无法复现”。
3. 训练与实验记录：记录代码版本、超参、随机种子、硬件环境，保证实验可追溯。
4. 离线评测与回归：不仅看平均精度，还要看长尾场景、极端天气、遮挡、夜间等子集表现。
5. 封装与制品入库：生成模型文件、配置、依赖清单和签名，形成不可变制品。
6. 灰度发布：按车队、区域、时段逐步放量，设置观察窗口和自动熔断条件。
7. 监控、回滚与复盘：线上指标异常时快速回退，并沉淀为新的评测用例和治理规则。

三、案例/场景：一次“指标很好”的发布为何被拦下

某团队训练了一版感知模型，在离线评测中整体 mAP 提升 2.1%，团队认为可以直接全量推送。但发布治理流程要求先过“场景门禁”。评测发现：该模型在夜间无路灯 + 逆光子集上，行人召回率下降了 4.7%；在施工区域锥桶场景中，误检率上升。虽然整体指标更好，但这两个子集直接关联安全风险。

治理系统因此将该版本标记为“有条件通过”：只允许在白天、非施工区域的小范围车队灰度，并强制开启更密集的监控。灰度第三天，系统检测到某区域夜间误制动告警上升，自动触发回滚。事后复盘发现，训练集中夜间逆光样本占比不足 3%，而整体指标被大量白天简单样本“拉高”了。

这个案例说明：发布治理不是阻碍迭代，而是把“整体指标”翻译成“场景风险”。没有场景维度的评测，模型很容易在平均值上获胜，却在关键角落失败。

四、误区与复盘：常见治理陷阱

五、行业背景：为什么现在必须谈治理

过去，自动驾驶模型迭代更多依赖“算法突破”；今天，随着车队规模扩大、法规趋严、用户对安全预期提高，行业竞争的重心正在转向工程化与治理能力。一方面，监管要求可解释、可追溯、可审计；另一方面，模型数量、版本数量和数据规模都在指数增长，靠人工表格管理已经不可行。

因此，模型生命周期与发布治理工程逐渐成为自动驾驶团队的基础设施：它连接数据平台、训练平台、评测平台、车端 OTA 和监控系统，把“算法能力”转化为“可交付、可运营、可问责的产品能力”。

典型治理元数据示例：
model_name: perception_fusion
model_version: 2.7.3-rc1
dataset_version: ds_2025_03_freeze
eval_suite: night_rain_construction_v4
gate_status: conditional_pass
gray_scope: city_A / daytime / 50 vehicles
rollback_target: 2.7.2
owner: perception-team

本课程后续将围绕这条主线展开：从数据与版本管理，到训练与评测门禁，再到灰度发布、监控回滚和审计复盘。你不需要一开始就记住所有工具，但需要先建立一张全局地图——知道每个阶段在解决什么问题、产出什么证据、由谁负责、何时必须停下。这张地图，就是自动驾驶模型从“能跑”走向“敢上车”的底层秩序。