2. 自动驾驶数据闭环
自动驾驶系统的能力提升，本质上不是“一次训练出一个大模型”就结束，而是依赖一条持续运转的数据闭环：车辆在真实道路上遇到问题，数据被采集并回传，经过清洗与标注形成训练样本，模型迭代后在仿真中验证，再部署到车端，新的问题又产生新的数据。这个循环每转一圈，系统对长尾场景的覆盖就更完整一层。MLOps 平台的核心价值，正是把这条闭环从“人工接力”变成“可观测、可复现、可度量”的工程流水线。
核心原理：闭环的六个环节与两次反馈
数据闭环可以拆解为六个环节：采集、回传、标注、训练、仿真、部署。其中存在两次关键反馈：第一次是“数据反馈”，即车端发现模型不确定或失效的场景，触发数据回传；第二次是“模型反馈”，即新模型部署后，通过影子模式或在线指标回传真实表现，决定是否继续迭代。没有这两次反馈，流程只是单向的“数据到模型”，而不是闭环。
判断一个场景是否值得进入闭环，通常看三个信号：模型置信度低、规划控制出现接管、以及感知与真值不一致。工程上常用触发式采集，而不是全量上传，否则带宽和存储成本会迅速失控。
方法流程：从车端触发到模型上车的工程链路
一条可落地的闭环流水线，通常按以下顺序推进：
- 触发采集：车端根据置信度阈值、接管事件、AEB 触发等条件，将关键片段写入本地缓存。
- 回传与入库：通过 4G/5G 或路侧 Wi-Fi 回传，平台按车辆、时间、场景标签建立索引。
- 清洗与预标注：去重、去模糊、时间对齐，再用已有模型做自动预标，人工只做修正。
- 训练与评估：数据集版本与模型版本绑定，训练完成后在固定验证集上评估。
- 仿真门禁：把新模型放入场景库回放，检查碰撞、急刹、压线等指标是否退化。
- 灰度部署与回传：先在小批量车辆 OTA，观察在线指标，再全量推送。
下面是一个典型的触发采集配置片段，用于说明“什么数据值得回传”：
trigger:
name: low_confidence_and_takeover
conditions:
- perception.min_confidence < 0.55
- planning.takeover_flag == true
- speed > 30 km/h
clip:
before_sec: 8
after_sec: 4
upload:
priority: high
max_size_mb: 200
desensitize: true案例场景：一次“鬼探头”问题的闭环复盘
某城市道路场景中，车辆在路口右转时遇到被遮挡的行人突然横穿，系统触发接管。车端按上述规则回传了 12 秒片段，平台自动打上“遮挡行人 + 右转 + 低置信度”标签。标注团队在预标基础上修正了行人轨迹，训练团队将其加入长尾数据集，仿真团队用同一场景回放验证新模型，确认制动响应提前了 0.3 秒。随后模型灰度部署到 200 辆车，一周内该场景接管率下降 62%。这就是一次完整的闭环：问题被捕获、被标注、被训练、被验证、被部署，并再次被监控。
常见误区与复盘要点
误区一：只追求数据量，不追求数据质量。大量重复的直行场景对模型提升有限，真正有价值的是长尾和失败样本。
误区二：标注与训练脱节。标注规范不统一，会导致同一场景在不同批次中标签不一致，模型学到矛盾信号。
误区三：仿真通过就全量推送。仿真无法完全覆盖真实世界的传感器噪声和天气变化，必须保留灰度与回滚机制。
复盘建议：每次闭环迭代后，记录“触发原因—数据量—标注耗时—训练收益—仿真结果—线上变化”六个字段，形成可追溯的迭代档案。这样当模型出现退化时，可以快速定位是数据、标注还是部署环节出了问题。
闭环各环节的职责与产出对照
| 环节 | 主要职责 | 关键产出 | 常用指标 |
|---|---|---|---|
| 数据采集 | 按触发条件捕获关键片段 | 原始数据包、场景标签 | 触发准确率、片段完整率 |
| 数据回传 | 脱敏、压缩、断点续传 | 可检索的数据集索引 | 回传时效、丢包率 |
| 数据标注 | 预标注 + 人工复核 | 带真值的训练样本 | 一次通过率、标注周期 |
| 模型训练 | 版本化训练与评估 | 候选模型、评估报告 | mAP、召回率、训练耗时 |
| 仿真验证 | 场景回放与指标门禁 | 仿真报告、放行结论 | 回归通过率、碰撞率 |
| 车端部署 | 灰度 OTA 与在线监控 | 线上模型版本、监控看板 | 接管率、回滚时长 |
把这条闭环跑通，关键不在于某一个环节做到极致，而在于环节之间的衔接是否自动化、数据是否可追溯、失败是否可回滚。当采集、标注、训练、仿真、部署和回传形成稳定节奏，自动驾驶系统才能从“能开”逐步走向“越开越稳”。