4. 数据闭环与自动迭代概述
自动驾驶模型的能力上限，很大程度上取决于它见过的场景是否足够多、足够难、足够新。传统“离线数据集训练一次、上车长期不变”的模式，无法应对长尾场景的持续涌现。数据闭环（Data Loop / Data Flywheel）正是为解决这一问题而生的工程体系：它把车端产生的真实驾驶数据，经过回传、筛选、标注、训练、评测，再以模型或规则的形式部署回车端，形成“数据驱动模型、模型驱动数据”的自我强化循环。
一、完整链路：从车端到车端的八段式闭环
一个成熟的数据闭环通常包含八个环节：数据采集、数据回传、数据筛选与挖掘、数据标注、模型训练、模型评测、模型部署、车端验证与再采集。这八段首尾相接，构成一个不断旋转的飞轮。下面这张图展示了车端与云端协同的完整链路与数据流向。
二、车端-云端协同的关键机制
车端与云端不是简单的“上传下载”关系，而是分工明确的协同系统。车端负责感知、触发、筛选和轻量处理，云端负责重计算、标注、训练和评测。这种分工的核心原因是带宽与算力成本：一辆车每天产生的原始数据可达数 TB，全量回传既不经济也不必要。
- 触发式采集：只有当发生接管、急刹、AEB 触发、规划抖动或影子模式发现模型与人类驾驶不一致时，才把对应时间窗的数据切片上传。
- 优先级队列：车端按场景稀有度、置信度低、风险等级打分，高优先级数据优先回传。
- 脱敏与合规：人脸、车牌在车端或接入层完成模糊化，满足数据合规要求后再进入训练流程。
- 影子模式：新模型在车端“只看不控”，与线上模型对比输出差异，差异样本自动回流，是低成本发现模型短板的关键手段。
三、各环节职责与典型工具
| 环节 | 主要职责 | 典型工具 / 技术 | 关键指标 |
|---|---|---|---|
| 数据采集 | 传感器同步、时间戳对齐、触发打标 | ROS/自研采集框架、硬件同步 | 触发召回率、时间同步误差 |
| 数据回传 | 压缩、断点续传、优先级调度 | 对象存储、CDN、消息队列 | 回传成功率、日均回传量 |
| 标注 | 人工标注、自动预标注、质检 | 标注平台、大模型预标注 | 标注一致性、单帧成本 |
| 训练 | 数据版本管理、分布式训练、增量训练 | PyTorch、Kubernetes、MLOps | 训练时长、GPU 利用率 |
| 评测 | 回归测试、场景集评测、指标门禁 | 仿真平台、回放评测 | 关键指标通过率、回归数 |
| 部署 | 模型转换、量化、灰度发布、回滚 | TensorRT、OTA 平台 | 发布成功率、回滚率 |
四、典型场景：一次接管如何变成一次模型升级
假设某城市道路上一辆车在无保护左转时被安全员接管。这个事件会触发以下链路：车端记录接管前后各 30 秒的多传感器数据并打上“无保护左转-接管”标签；数据按高优先级回传云端；挖掘系统发现该场景在训练集中占比极低，自动加入标注队列；标注完成后进入训练集，触发一次增量训练；新模型在包含该场景的回归集上评测，若左转通过率提升且其他指标不退化，则通过门禁；随后通过 OTA 灰度发布到小批量车辆，影子模式验证无异常后全量推送。整个过程从数天到数周不等，成熟团队可压缩到 24 小时内。
# 一次闭环迭代的简化流水线示意
collect --trigger="takeover" --window=30s
upload --priority=high --compress=h265
mine --rare-scene="unprotected_left_turn"
label --auto-prelabel --human-review
train --incremental --base=model_v12
evaluate --regression-set=city_v3 --gate=pass
deploy --ota --canary=5% --shadow=true
五、常见误区与复盘
- 误区一：追求全量回传。带宽和存储成本会迅速失控，且大量冗余数据对模型提升有限。应按价值筛选。
- 误区二：只关注训练，不关注评测门禁。没有严格回归评测，新模型可能修复一个场景却破坏十个场景。
- 误区三：闭环没有度量。应跟踪“从事件发生到模型上车”的端到端周期、单次迭代成本、场景覆盖率等指标。
- 误区四：忽略数据版本与可追溯。模型出问题时无法定位是数据、标注还是训练配置导致，复盘将无从下手。
理解数据闭环的完整链路，是后续学习数据采集策略、自动标注、持续训练与 OTA 部署等具体工程环节的基础。只有把车端、云端、标注、训练、评测、部署串成一条可度量、可追溯、可自动化的流水线，自动驾驶模型才能真正实现“越开越聪明”。