4. 可追溯性基础

在自动驾驶数据版本管理中，可追溯性不是“把日志存下来”这么简单，而是要求任何一个交付物、结论或决策，都能沿着明确的路径回溯到它的来源、变更过程与验证证据。它解决的是三个核心问题：这个模型/数据/配置从哪来？中间经历了什么？凭什么可以放行？没有可追溯性，版本管理就退化为文件备份，出现问题时只能靠人回忆和翻聊天记录。

一、追溯的定义与四个基本要素

追溯（Traceability）是指在产品生命周期中，建立并维护需求、设计、数据、代码、模型、测试、发布之间的双向关联关系，使得任一对象都能被正向追踪（从需求到实现）和反向回溯（从问题到根因）。在自动驾驶场景中，一个完整的追溯关系通常包含四个要素：

• 追溯对象：需求条目、数据集版本、标注批次、模型权重、训练配置、仿真场景、路测片段、发布包等。
• 追溯方向：正向（需求→实现→验证）与反向（缺陷→变更→影响范围）。
• 追溯粒度：追溯到哪一级，是整包、文件、样本还是字段。
• 追溯证据：哈希值、签名、评审记录、测试报告、审批流水。

二、追溯粒度：从粗到细的工程取舍

追溯粒度决定了追溯的成本与价值。粒度过粗，问题定位只能到“某个版本”，无法定位到具体样本；粒度过细，存储与维护成本急剧上升，甚至拖慢训练流水线。工程上通常按对象类型选择不同粒度：

对象类型	推荐粒度	典型标识	说明
需求	条目级	REQ-OD-0012	每条需求可独立评审与验证
数据集	版本级 + 样本级	ds-2024.06 / clip_id	版本用于发布，样本用于问题复现
标注	批次级 + 对象级	label-batch-88 / obj_id	支持标注质量回溯与返工
模型	权重文件级	sha256:9f3c…	权重哈希是唯一身份
训练配置	文件级 + 参数级	config.yaml@commit	关键超参需单独记录
发布包	包级 + 组件级	release-1.7.2 / manifest	manifest 列出所有组件版本

选择粒度的原则是：问题定位需要到哪一级，追溯就至少到哪一级。例如感知模型误检需要复现到具体 clip，那么数据集就必须保留样本级索引；如果只做整体回归，版本级即可。

三、追溯链：从需求到发布的完整路径

追溯链是把离散的追溯对象串成一条可验证的路径。在自动驾驶数据版本管理中，一条典型的追溯链如下：

需求 REQ-OD-0012
  → 数据集 ds-2024.06（含 clip_00931）
    → 标注批次 label-batch-88
      → 训练配置 config_v3.yaml
        → 模型权重 model_od_v17.pt（sha256:9f3c…）
          → 仿真场景 sim-urban-night-042
            → 测试报告 report_20240612.html
              → 发布包 release-1.7.2

这条链的价值在于：当 release-1.7.2 在夜间场景出现漏检时，可以反向逐级回溯，快速定位到是标注批次遗漏、训练配置变更，还是仿真场景覆盖不足。追溯链必须可机器读取，而不是只存在于文档中。常见做法是用 manifest 文件或图数据库记录节点与边。

四、追溯矩阵：把关系变成可检查的表

追溯矩阵（Traceability Matrix）是用二维表格表达对象之间关联关系的工具。行通常表示需求或问题，列表示实现、测试、发布等对象，交叉点标记关联状态。在自动驾驶数据版本管理中，追溯矩阵常用于检查覆盖度与一致性。

需求ID        数据集版本      模型版本       测试用例        发布包
REQ-OD-0012   ds-2024.06     model_v17      TC-NIGHT-042   release-1.7.2
REQ-OD-0013   ds-2024.06     model_v17      TC-RAIN-018    release-1.7.2
REQ-OD-0014   ds-2024.07     model_v18      TC-TUNNEL-007  release-1.8.0

矩阵的价值在于暴露“断链”：某条需求没有对应测试用例，或某个模型版本没有关联数据集版本，都会在矩阵中表现为空白。工程上可以用脚本自动生成矩阵，并在 CI 中设置门禁：存在断链则禁止发布。

五、合规要求：可追溯性为什么是硬指标

在自动驾驶领域，可追溯性不仅是工程需求，更是合规要求。ISO 26262 要求对安全相关项建立双向追溯；ISO 21448（SOTIF）要求对场景、触发条件与验证证据进行追溯；UN R155/R156 对软件更新与版本标识提出明确要求；国内《智能网联汽车道路测试与示范应用管理规范》也要求记录测试过程与版本信息。合规视角下，可追溯性通常需要满足：

• 唯一标识：每个版本、数据集、模型都有不可篡改的 ID 或哈希。
• 变更记录：谁、何时、为什么修改，修改前后差异可查。
• 审批留痕：关键节点有评审与批准记录。
• 证据可导出：审计时能导出完整追溯链与矩阵。
• 保留期限：按法规要求保留足够长时间，且防篡改。

六、常见误区与复盘

误区一：只记录版本号，不记录关系。版本号只能回答“是什么”，不能回答“从哪来、到哪去”。复盘时应检查 manifest 是否包含上下游引用。

误区二：追溯粒度一刀切。所有对象都做到样本级，成本高且难以维护；所有对象都只做版本级，问题无法复现。应按对象类型分级设计。

误区三：追溯链只存在于文档。文档会过期，机器不可读。应把追溯关系写入版本库、manifest 或图数据库，并纳入 CI 校验。

误区四：合规检查前临时补记录。追溯数据必须随研发过程自然产生，事后补录往往无法通过审计，也无法真正用于排障。

总结来说，追溯定义明确了“要建立什么关系”，追溯粒度决定了“建到多细”，追溯链把关系串成路径，追溯矩阵把路径变成可检查的表，合规要求则给出了必须满足的底线。五者共同构成自动驾驶数据版本管理中可追溯性的基础框架。