2. 自动驾驶数据概述

自动驾驶系统不是靠单一算法“看懂世界”，而是靠持续吸收多源数据、反复训练与验证形成的工程闭环。理解数据，是理解版本管理与可追溯工程的前提。本节从数据类型、来源、规模、挑战四个维度展开，并落到版本管理需求的本质上。

一、数据类型：从像素到语义的多层结构

自动驾驶数据可按“感知介质—标注形态—用途阶段”三个视角分类。按介质，主要包括摄像头图像/视频、激光雷达点云、毫米波雷达回波、超声波、GNSS/IMU组合导航、车辆CAN总线与底盘信号。按标注形态，可分为2D框、3D框、语义分割、实例分割、车道线、可行驶区域、关键点、轨迹序列以及自然语言描述。按用途阶段，则分为训练集、验证集、测试集与回归集。

这些数据并非孤立存在，而是通过时间戳与标定参数对齐，形成“同一时刻、同一场景”的多模态样本。例如一个典型样本可能包含：前视120°相机图像、128线激光雷达点云、4D毫米波雷达目标列表、自车速度与转向角。数据类型的多样性直接决定了版本管理不能只管理“文件”，还要管理“样本结构”和“标注语义”。

二、数据来源：车端、云端与仿真三条主线

数据来源可归纳为三类。第一类是真实路采：测试车、量产车影子模式、数据回传车队，覆盖城市、高速、泊车、雨雾雪等场景。第二类是云端挖掘与回灌：通过触发式上传、难例挖掘、场景检索，把长尾片段从海量日志中提取出来。第三类是仿真与合成：基于场景库、游戏引擎、神经渲染生成可控、可重复、带真值的样本，用于补足危险场景和极端天气。

三类来源的数据在格式、精度、分布和合规性上差异明显。真实数据贴近现实但标注成本高、长尾稀疏；仿真数据真值精确但存在域差距；云端回灌数据则依赖触发策略的质量。版本管理必须为每条数据保留“来源血缘”，否则无法判断模型提升究竟来自真实场景还是仿真过拟合。

三、数据规模：从TB到PB的工程现实

一辆高阶自动驾驶测试车每天可产生数TB原始数据，一个车队一年可积累PB级数据。以常见配置估算：8路相机、1颗激光雷达、5颗毫米波雷达，持续采集约每小时1～2TB。若按1%触发上传，仍有数十TB/天进入云端。规模带来的不是存储问题，而是“可检索、可复现、可审计”的问题。

四、核心挑战：长尾、漂移、合规与复现

第一是长尾分布：99%的里程是常规场景，真正决定安全的是1%的极端情况，而它们恰恰最少、最难标注。第二是数据漂移：传感器固件、标定参数、采集路线、天气季节变化，都会让数据分布随时间改变，旧模型在新数据上可能失效。第三是合规与隐私：人脸、车牌、地理位置需要脱敏，跨境传输受法规约束。第四是可复现性：同一个模型版本，若训练数据版本不同，指标不可比，问题无法定位。

五、版本管理需求：从“存下来”到“说得清”

面对上述挑战，版本管理需求可归纳为五条：唯一标识（每条数据、每个标注、每个数据集有稳定ID）；血缘追踪（从模型回溯到样本、从样本回溯到采集车与标定）；不可变快照（数据集一旦发布即冻结，变更产生新版本）；差异比较（能回答两个数据集之间增删改了哪些样本）；权限与审计（谁在何时基于哪个版本训练了什么模型）。

下面用一个简化的数据流与版本节点关系图，展示从车端采集到模型训练之间，版本信息应在哪些环节被记录和传递。

六、案例场景：一次“模型退化”的复盘

某团队发现新模型在夜间雨天场景的召回率下降3%。若没有版本管理，只能重新训练、反复猜测。有了版本管理后，排查路径如下：

1. 从模型版本回溯到训练数据集版本 ds-2024-11-03；
2. 对比上一版 ds-2024-10-20，发现新增样本中夜间雨天占比从8%降到3%；
3. 进一步查看采集配置，发现新批次车辆更换了相机固件，曝光策略变化；
4. 定位到标定参数版本未同步更新，导致部分样本对齐偏差；
5. 修复后重新构建数据集 ds-2024-11-05，指标恢复并超过基线。

七、方法流程：数据版本化的最小闭环

一个可落地的最小闭环包括：采集时写入配置与标定指纹；入库时计算数据指纹并登记血缘；标注时绑定标注规范版本与审核状态；构建数据集时冻结快照并生成差异报告；训练时记录数据集版本与代码版本；发布时归档模型卡与数据卡。每一步都产生可审计的元数据，而不是只保存原始文件。

dataset_version: ds-2024-11-05
parent: ds-2024-11-03
samples:
  total: 128430
  added: 5210
  removed: 340
  changed_labels: 1180
calibration: calib-cam-v3.2
collection_config: cfg-night-rain-v1
desensitization: face_plate_blur_v2
split_rule: by_route_and_weather

综上，自动驾驶数据的类型多、来源杂、规模大、挑战深，决定了版本管理不是附属功能，而是数据工程的基础设施。只有把数据当作有身份、有血缘、有快照的工程资产，后续的模型迭代、问题定位与合规审计才具备可操作性。