1. 课程导入

自动驾驶系统并不是“训练一次、部署终身”的静态软件。车辆每天在真实道路上采集到的光照、天气、交通参与者行为、道路施工、传感器污渍与标定偏差都在持续变化,而模型只在有限的历史数据分布上完成训练。一旦运行环境偏离训练分布,感知、预测、规划模块的输出就可能悄然退化。模型监控与漂移检测的核心任务,就是在功能失效或安全事故发生之前,尽早发现“模型看到的世界已经变了”,并给出可定位、可量化、可处置的信号。

本课程的学习目标可以概括为三条主线:第一,理解自动驾驶模型监控的对象、指标与数据闭环;第二,掌握数据漂移、概念漂移、特征漂移与标签漂移的检测方法和工程实现;第三,能够把检测结果接入告警、回灌、再训练与版本发布流程,形成可持续运行的 MLOps 监控体系。

一、核心概念:监控什么,漂移指什么

在自动驾驶语境下,“模型监控”并不只是看 GPU 利用率和推理延迟,它至少覆盖四个层面:系统层(时延、丢帧、算力、内存)、数据层(传感器质量、点云/图像分布、时间同步)、模型层(置信度、检测框数量、轨迹误差、不确定性)以及业务层(接管率、急刹率、碰撞预警、ODD 越界)。漂移检测则聚焦于分布变化,常见类型如下:

  • 数据漂移(Data Drift):输入特征分布发生变化,例如夜间雨天图像占比突然升高、激光雷达点云稀疏度下降。
  • 概念漂移(Concept Drift):输入与输出之间的映射关系改变,例如某类车辆外观更新后,原本的“卡车”特征不再稳定。
  • 标签漂移(Label Drift):真值或标注规范变化,例如标注团队对“可行驶区域”的边界定义调整。
  • 模型漂移(Model Drift):模型版本、后处理参数或推理环境变化导致的输出偏移。

需要特别区分“漂移”与“异常”:漂移通常是渐进、统计意义上的分布迁移;异常可能是突发、单点或局部故障。工程上二者常共用同一套监控管道,但处置策略不同。

二、整体框架:从车端采集到闭环再训练

一个可落地的监控与漂移检测框架,通常由“采集—计算—判定—处置—验证”五段构成。车端负责触发式回传与影子模式推理;云端负责特征统计、漂移指标计算、告警分级与数据回灌;训练平台负责再训练、评估与灰度发布;最后通过影子测试和回归集验证,确认新模型没有引入新的退化。下面的 SVG 展示了这一数据流与判定关系。

自动驾驶模型监控与漂移检测闭环框架 车端采集 相机 / 激光雷达 / 毫米波 触发回传 + 影子推理 特征与指标计算 PSI / KL / KS / MMD 置信度 / 时延 / 接管率 漂移判定 阈值 + 置信区间 分级告警 P0 / P1 / P2 处置与回灌 数据回灌 / 标注 / 再训练 灰度发布 + 影子验证 闭环反馈:新模型与阈值更新回到车端与监控管道 监控对象 • 系统层:时延、丢帧、算力 • 数据层:图像/点云分布 • 模型层:置信度、不确定性 • 业务层:接管率、急刹率 • ODD:天气、道路、时段 • 版本:模型/后处理/标定 漂移类型 • 数据漂移:输入分布变化 • 概念漂移:映射关系变化 • 标签漂移:真值规范变化 • 模型漂移:版本/环境变化 • 突发异常:单点故障 • 渐进退化:长期缓慢偏移 工程价值 • 提前发现感知退化 • 降低接管与事故风险 • 缩短问题定位时间 • 驱动数据闭环与再训练 • 支撑 ODD 边界扩展 • 满足合规与审计要求

三、方法流程:从指标到告警的判定链路

漂移检测的工程实现通常遵循“基线—统计—判定—归因”的链路。首先在模型发布时固化基线分布,例如按 ODD 切片保存特征直方图、置信度分布和误差分布;然后在线上按时间窗口计算漂移指标;接着用阈值与置信区间做分级判定;最后通过特征归因定位到具体维度,例如“夜间+雨天”切片下的图像亮度均值下降 18%。常用指标包括 PSI、KL 散度、KS 检验、MMD 以及基于分类器的对抗验证。下面给出一个简化的配置示例,用于说明监控项如何参数化:

monitor:
  baseline: model_v2.3.1_2024Q2
  window: 1h
  slices:
    - weather: [clear, rain, snow]
    - time: [day, night]
    - road: [highway, urban, rural]
  metrics:
    - name: image_brightness
      type: psi
      threshold: 0.2
      level: P1
    - name: lidar_point_density
      type: ks
      threshold: 0.05
      level: P1
    - name: detection_confidence
      type: kl
      threshold: 0.15
      level: P0
    - name: takeover_rate
      type: absolute
      threshold: 0.03
      level: P0
  action:
    P0: page_oncall_and_freeze_release
    P1: create_ticket_and_collect_data
    P2: log_only

四、案例与场景:一次夜间雨天漂移的处置复盘

某城市 NOA 项目在连续降雨后收到 P1 告警:夜间雨天切片的图像亮度 PSI 达到 0.31,激光雷达点密度 KS 统计量超过阈值,同时检测置信度均值下降 12%。团队按流程执行:第一步冻结当前模型灰度发布;第二步回灌该切片 2 万帧数据并补充标注;第三步在再训练中加入雨夜增强与点云去噪;第四步通过影子模式对比新旧模型,确认接管率下降 0.8 个百分点后恢复发布。整个过程从告警到恢复用时 36 小时,避免了更大范围的体验退化。

复盘要点:漂移检测的价值不在于“报警本身”,而在于把报警与数据回灌、再训练、发布门禁串成闭环。没有处置动作的监控,只是日志。

五、常见误区与工程清单

初学者容易把漂移检测等同于“看准确率下降”,但线上往往没有实时真值,必须依赖代理指标。另一个误区是只监控全局分布,忽略 ODD 切片,导致局部退化被平均掉。还有团队把阈值设得过死,造成告警疲劳;或只做单点检测,不做趋势与置信区间判断。下表给出一个可落地的检查清单:

维度 关键问题 推荐做法
基线 是否有版本化基线分布? 每次发布固化特征直方图与切片统计
切片 是否覆盖 ODD 关键维度? 天气、时段、道路、城市、传感器状态
指标 是否只依赖单一指标? PSI + KS + 置信度 + 业务指标组合
告警 是否分级并可执行? P0/P1/P2 对应冻结、回灌、记录
闭环 告警后是否有动作? 回灌、标注、再训练、影子验证、灰度发布
注意:漂移不等于模型一定错误,环境变化也可能带来正常分布迁移。判定时必须结合业务影响与置信区间,避免把“新场景”误判为“故障”,也避免把“缓慢退化”当成“正常波动”。