📚 课程目录第2章基础概念

2、基础概念：模型迭代、样本采集、重训和版本更新的定义及其在自动驾驶系统中的角色

无人车量产落地后，其感知、预测、规划等模块并非“一次训练、终身使用”。真实道路场景的开放性和长尾分布决定了模型必须持续进化。本章围绕四个核心概念——模型迭代、样本采集、重训、版本更新——展开，厘清它们在自动驾驶系统工程中的定义、边界与协作关系。理解这些基础概念，是后续掌握数据闭环、影子模式、A/B测试和OTA升级等进阶内容的前提。

2.1 模型迭代：自动驾驶系统的进化引擎

核心原理

模型迭代（Model Iteration）是指自动驾驶系统中的感知、预测、规划等算法模型，在数据驱动下不断调整参数、优化结构、更新知识的过程。与传统软件迭代不同，模型迭代的核心驱动力是数据分布的变化——新城市、新天气、新交通参与者行为模式，都会导致模型在特定场景下的性能衰减。迭代的本质是让模型持续逼近真实世界无限复杂的驾驶环境。

从系统工程角度看，模型迭代不是单一的训练动作，而是一个包含问题定义、数据准备、训练调优、离线评估、在线验证的完整周期。每个周期通常持续1~4周，具体时长取决于场景复杂度、数据规模与算力资源。迭代的目标函数并非单一精度指标，而是综合考量安全（如碰撞率）、体验（如舒适度）、可用性（如接管率）等多维指标。

迭代的触发条件

触发类型	典型信号	响应级别
性能衰减	某场景准确率下降超过5%	紧急迭代（1周内）
新场景出现	新城市开通，出现未见过交通标识	计划迭代（2~4周）
安全事件	发生接管或碰撞，触发根因分析	紧急修复（3~7天）
定期升级	每季度例行性能提升	常规迭代（4周）

经验提醒：模型迭代并非越频繁越好。过于频繁的迭代会导致评估不充分、回归风险累积，同时消耗大量标注和算力资源。建议建立“紧急通道”和“常规通道”双轨机制，紧急通道用于安全事件修复，常规通道用于计划性性能提升。

2.2 样本采集：数据闭环的起点

定义与采集策略

样本采集（Data Collection）是指从量产车队或测试车队中，按照特定策略获取原始传感器数据（图像、点云、毫米波雷达回波等）及对应的车辆状态信息（速度、转向角、GPS轨迹等）的过程。采集不是简单的“全量录制”，而是有目的、有筛选的难例挖掘过程。

当前主流采集策略包括：

影子模式（Shadow Mode）：系统在后台运行算法，但不干预驾驶。当模型预测结果与驾驶员实际操作产生显著偏差时，自动触发数据截取。这是最经济的难例发现方式。
场景触发采集：基于预设规则（如急刹车、变道、恶劣天气、施工区域）触发数据录制，确保关键场景的覆盖率。
随机采样：按固定比例（如1%）随机采集正常行驶数据，用于维持模型对常规场景的记忆，防止灾难性遗忘。
主动学习（Active Learning）：利用模型的不确定性估计，优先采集模型“最不确定”的样本，提高标注效率。

采集数据的关键属性

一份合格的训练样本需要包含以下元信息：

{
  "sample_id": "20250614_SH_001234",
  "timestamp": "2025-06-14T15:23:45.123Z",
  "location": {"lat": 31.2304, "lon": 121.4737},
  "weather": "rainy",
  "light_condition": "daytime",
  "trigger_type": "shadow_mode_disagreement",
  "sensor_data": {
    "camera_front": "s3://bucket/.../cam_front.jpg",
    "lidar": "s3://bucket/.../lidar.pcd",
    "radar": "s3://bucket/.../radar.bin"
  },
  "vehicle_state": {"speed": 12.5, "steering_angle": -0.3, "brake": 0},
  "annotation_status": "pending"
}

风险提示：样本采集必须严格遵守数据合规要求。涉及人脸、车牌等个人隐私信息时，需在采集端完成匿名化处理。此外，采集数据的存储和传输需要加密，防止数据泄露。

2.3 模型重训：从数据到能力的转化

重训的三种模式

模型重训（Retraining）是将经过筛选和标注的新数据，与历史数据按一定比例混合，重新训练模型的过程。根据数据规模与训练目标，重训分为三种模式：

模式	数据规模	训练方式	适用场景
全量重训	全部历史数据 + 新数据	从随机初始化开始训练	模型架构变更、数据分布发生根本性变化
增量训练	新数据 + 部分代表性旧数据	基于旧模型权重继续训练	常规迭代，效率优先
微调（Fine-tuning）	仅新场景数据	冻结大部分层，只训练顶层	新城市适配、特定场景能力增强

重训流程与关键控制点

数据版本管理：每次重训前，需要锁定训练数据集版本，确保实验可复现。推荐使用DVC（Data Version Control）或类似工具管理数据版本。
训练配置：记录学习率、batch size、epoch数、数据增强策略等超参数。建议使用W&B或MLflow进行实验追踪。
离线评估：在固定测试集（包含历史回归集和新场景集）上评估模型性能。重点关注：新场景精度提升幅度、历史场景精度是否回退（回归测试）。
模型签名：对模型文件计算哈希值，确保部署的模型与评估通过的模型完全一致。

  核心原则：重训的目标不是“在新数据上表现最好”，而是“在所有已知场景上整体最优”。因此，训练集通常采用“新数据过采样 + 旧数据欠采样”的策略，控制新旧数据比例在1:3到1:5之间，防止模型对近期数据过拟合。

2.4 版本更新：安全部署的最后一公里

版本更新的定义与挑战

版本更新（Version Deployment）是指将通过评估的新模型，以受控方式部署到量产车队的过程。与普通App更新不同，自动驾驶模型更新直接影响车辆控制，任何未发现的缺陷都可能导致安全事故。因此，版本更新必须遵循渐进式灰度发布原则。

典型的灰度发布路径：

仿真环境验证：在仿真平台上运行新模型，覆盖数千个标准场景和对抗场景，确认无致命缺陷。
封闭场地测试：在测试场进行实车验证，重点测试模型在极端工况下的表现。
小规模车队（10~50辆）：选择特定区域、特定天气条件下的车队进行内测，持续监控接管率和安全指标。
区域扩展（100~500辆）：逐步扩大至更多城市和道路类型，收集更多反馈。
全量推送：在灰度期间未发现重大问题后，分批次推送至全部车队。

版本回滚机制

即使经过严格测试，仍可能出现在特定场景下新模型表现劣化的情况。因此，版本更新必须配套完善的回滚机制：

# 回滚策略示例
rollback_policy:
  trigger_conditions:
    - metric: "接管率"
      threshold: "> 0.5次/千公里"
      duration: "持续2小时"
    - metric: "安全事件"
      threshold: "> 0"
      duration: "立即"
  action: "自动回滚至上一稳定版本"
  notification: "通知算法团队和运维团队"

关键提醒：版本更新不仅是技术问题，更是运营问题。每次更新前需要准备详细的发布说明，包括：更新内容、影响范围、预期收益、风险评估、回滚预案。同时，需要建立监控看板，实时展示新版本在车队中的运行状态。

2.5 案例拆解：某Robotaxi公司“雨天场景”模型迭代全流程

为帮助理解上述概念如何在实际工程中协同运作，以下以一个典型的长尾场景迭代案例进行拆解。

背景与约束：某Robotaxi公司运营车队在梅雨季节到来后，发现雨天场景下的感知准确率从92%下降至84%，尤其是“雨天夜间”工况下，对行人的漏检率上升了3倍。公司需要在4周内完成模型迭代，赶在雨季高峰期前部署修复版本。

初始现象与目标：监控系统显示，近两周雨天场景的感知置信度普遍偏低，且影子模式触发的“模型预测 vs 驾驶员行为”不一致事件中，雨天场景占比从15%上升至38%。目标是将雨天场景感知准确率恢复至90%以上，且不降低晴天场景性能。

关键输入数据：

采集阶段：通过影子模式在雨天自动触发采集，2周内收集了12,000帧雨天图像、8,000帧雨天点云，覆盖城市快速路、老城区窄路、隧道出入口等场景。
标注阶段：筛选出6,500帧有效难例，标注了雨滴遮挡、积水反光、行人打伞等细粒度属性。
训练阶段：采用增量训练方式，将新数据与历史数据按1:4比例混合，训练了80个epoch，学习率从1e-4衰减至1e-6。

分析判断过程：团队首先对雨天漏检样本进行错误分析，发现主要问题集中在：①雨滴在镜头上的附着导致局部模糊；②积水路面的反光造成语义分割错误；③行人穿着深色雨衣，与背景对比度低。针对这三个根因，团队在数据增强中加入了模拟雨滴噪声、随机亮度扰动和对比度调整，并调整了损失函数中难例样本的权重。

实际操作步骤：

第1周：完成数据采集与清洗，建立雨天专用验证集（2,000帧）。
第2周：完成标注与质检，标注一致性达到95%以上。
第3周：进行3轮训练实验，对比不同数据增强策略和损失函数配置，选择在验证集上最优的配置。
第4周：完成离线评估（雨天验证集准确率91.2%，晴天回归集准确率92.5%，下降仅0.3%），进入灰度发布。

结果对比：灰度发布至50辆车运行3天后，雨天场景接管率从0.8次/千公里下降至0.3次/千公里，感知准确率恢复至91%。全量推送后，整体运营指标保持稳定，未出现回退。

风险与代价：本次迭代消耗了约200 GPU·天的训练算力，标注成本约8万元。由于时间紧迫，未能在发布前完成所有极端雨天场景的仿真验证，依赖灰度发布期间的实时监控来兜底。

复盘经验：①影子模式是长尾场景数据采集的最有效手段，应持续优化触发逻辑；②增量训练配合数据增强，可以在4周内完成从问题发现到部署的闭环；③灰度发布期间的监控指标需要提前定义，并设置自动回滚阈值。

2.6 常见误区与总结复盘

常见误区

误区一：样本采集越多越好。实际上，大量重复的常规数据不仅浪费存储和标注资源，还可能稀释难例样本的权重。应通过难例挖掘和主动学习提高数据效率。
误区二：重训就是“跑一次训练脚本”。重训前的数据版本管理、实验追踪、评估集设计同样重要。缺少这些环节，训练结果无法复现，问题难以定位。
误区三：版本更新可以跳过灰度发布。即使离线评估指标优秀，真实道路的开放性和不可预测性仍可能导致意外。灰度发布是安全底线，不可省略。
误区四：只关注新场景性能，忽视历史场景回归。模型迭代最常见的失败模式就是“顾此失彼”——新场景提升了，但老场景崩了。必须建立回归测试集并设定硬性阈值。

总结复盘

模型迭代、样本采集、重训和版本更新构成了自动驾驶系统持续进化的完整链路。四者关系可以概括为：样本采集提供燃料，模型重训完成转化，版本更新实现交付，模型迭代统领全局。在实际工程中，这四个环节不是串行执行，而是并行运转、持续反馈的闭环系统。团队需要建立清晰的角色分工、数据规范和发布流程，才能让模型在真实道路上越开越好。

  核心记忆点：自动驾驶模型迭代的本质是“数据飞轮”——每一轮迭代产生的模型，通过影子模式采集更多难例，再驱动下一轮迭代。飞轮转速取决于数据采集效率、标注质量、训练速度和部署安全性的综合平衡。