📚 课程目录第3章应用场景

3. 应用场景

自动驾驶系统由感知、预测、规划、控制四大核心模块串联而成，每个模块对模型监控与热更新的诉求并不相同。感知模块关注“看得准不准”，预测模块关注“猜得稳不稳”，规划模块关注“决策是否安全且平滑”，控制模块关注“执行是否实时且确定”。如果工程团队用同一套监控阈值和热更新策略覆盖所有模块，往往会在安全、时延和资源之间顾此失彼。本节从典型场景出发，梳理各模块的监控对象、热更新需求差异，并给出可落地的工程判断依据。

一、核心原理：模块差异决定监控与更新策略

模型监控的本质是持续采集模型输入、输出、内部状态和系统资源指标，判断模型是否发生性能退化、分布漂移或异常行为。热更新的本质是在不中断系统运行的前提下，将新模型或新参数安全地替换到推理链路中。两者在不同模块中的关键差异，主要来自三个方面：

安全等级不同：感知误检可能造成误刹或漏检，规划误判可能直接导致碰撞风险，控制异常则可能引发车辆失稳。越靠近执行端，安全约束越硬。
实时性要求不同：感知通常要求 30～60 FPS，预测和规划多在 10～20 Hz，控制环路则常要求 100 Hz 以上且抖动极小。
模型形态不同：感知多为大参数量 CNN/Transformer，预测常用序列模型，规划包含优化求解与规则逻辑，控制则常是轻量网络或 PID/MPC 混合结构。

  监控与热更新的设计原则：感知重“分布与精度”，预测重“时序一致性”，规划重“约束与可解释”，控制重“确定性与低抖动”。热更新必须与模块的安全等级匹配，不能一刀切。

二、典型场景与需求差异

下面通过一个对比表，直观呈现四个模块在监控指标、热更新频率、回滚要求和资源约束上的差异。

模块	核心监控指标	热更新典型频率	回滚要求	资源与实时约束
感知	mAP、漏检率、误检率、输入分布漂移、置信度分布	天级～周级	秒级回滚，允许短暂降级	GPU/NPU 算力高，允许较大模型
预测	轨迹 ADE/FDE、多模态覆盖率、时序抖动	周级～月级	分钟级回滚，需保持时序连续	中等算力，依赖历史帧缓存
规划	约束满足率、碰撞风险、舒适度、求解耗时	月级～季度级	需双版本并行，人工确认后切换	CPU 为主，强实时与安全校验
控制	跟踪误差、超调量、执行器饱和、环路抖动	季度级～年级	必须硬件在环验证，禁止在线热更	MCU 级算力，确定性时延要求极高

从表中可以看出，感知模块最适合较早引入在线监控与热更新，因为其模型迭代快、数据驱动强、安全兜底可由后端的规划控制完成。预测模块次之，但必须注意时序一致性，避免新旧模型切换导致轨迹跳变。规划模块的热更新应非常谨慎，通常采用影子模式并行运行，确认新模型在真实场景中不产生危险行为后再切换。控制模块则基本不采用在线热更新，更多依赖 OTA 整车升级和硬件在环验证。

三、方法流程：从监控到热更新的闭环

无论哪个模块，监控与热更新都应形成闭环。典型流程如下：

数据采集：采集模型输入、输出、中间特征、时延和资源占用。
指标计算：在线计算精度、漂移、异常分数和时序一致性指标。
告警与决策：根据阈值和趋势判断是否触发降级、回滚或热更新。
热更新执行：加载新模型，进行一致性校验和灰度切换。
效果验证：对比新旧模型在真实数据上的表现，确认无回归后全量。

以感知模块为例，一个简化的监控配置可以写成如下形式：

monitor:
  module: perception
  metrics:
    - name: detection_miss_rate
      threshold: 0.02
      window: 300s
    - name: input_distribution_shift
      method: kl_divergence
      threshold: 0.15
  action:
    on_breach: rollback
    rollback_timeout: 5s
hot_update:
  strategy: canary
  traffic_ratio: 0.1
  validation: shadow_mode

对于规划模块，热更新配置则需要增加安全校验和双版本并行：

hot_update:
  module: planning
  strategy: shadow_then_switch
  shadow_duration: 3600s
  safety_check:
    - collision_free: true
    - comfort_score: >= 0.8
  rollback:
    trigger: manual_confirm
    max_switch_time: 200ms

四、案例与误区复盘

某量产项目在感知模块上线了新的障碍物检测模型，监控显示 mAP 提升明显，但一周后收到多起“幽灵刹车”反馈。复盘发现，新模型在雨天场景下对路面反光的误检率上升，而监控只关注了整体 mAP，没有分场景监控。这说明感知模块的监控必须细分到天气、光照、道路类型等维度，否则整体指标会掩盖局部退化。

另一个案例发生在预测模块。团队热更新了轨迹预测模型，但新旧模型输出的轨迹坐标系定义存在细微差异，导致规划模块收到的轨迹出现跳变，车辆在路口出现犹豫。复盘结论是：预测模块热更新必须包含时序一致性和接口契约校验，不能只验证单帧精度。

常见误区：
1. 用同一套阈值监控所有模块，忽视安全等级差异。
2. 热更新只验证模型精度，不验证接口、坐标系和时序一致性。
3. 控制模块尝试在线热更新，导致环路抖动或执行器异常。
4. 缺少回滚预案，一旦新模型异常只能停车或降级到人工接管。

综合来看，感知、预测、规划、控制四个模块的监控与热更新需求呈现明显的梯度：越靠近感知端，越适合高频监控和快速热更新；越靠近控制端，越需要保守、确定和硬件在环验证。工程团队应建立分模块的监控指标体系和热更新策略，把安全兜底放在规划与控制层，把快速迭代放在感知与预测层，从而在迭代效率与行车安全之间取得平衡。