📚 课程目录第3章实验管理基础

3. 实验管理基础

在自动驾驶研发中，一次“实验”远不止跑一次训练脚本。它通常包含数据版本、代码提交、超参配置、硬件环境、模型权重、评测指标与结论记录等一整套可追溯信息。实验管理基础要解决的核心问题是：让每一次模型迭代都能被定义、被追踪、被比较、被复现。本节围绕实验定义、实验生命周期、实验元数据、实验追踪与实验看板五个核心概念展开，帮助建立可复现训练工程的“账本”意识。

一、实验定义：把一次训练变成可管理的对象

实验定义（Experiment Definition）是对一次训练或评测任务的完整声明。它不是简单的“跑一个脚本”，而是把目标、输入、配置、执行方式、输出与判定标准固定下来。一个规范的实验定义至少应回答：这次实验要验证什么假设？使用哪一版数据与代码？采用什么超参和硬件？产出什么模型与指标？

在工程实践中，实验定义通常以声明式配置表达，例如 YAML 或 JSON。下面是一个自动驾驶感知模型训练实验的简化定义：

experiment:
  name: "bev_detector_lr_sweep_v3"
  hypothesis: "降低初始学习率可提升小目标召回率"
  dataset:
    name: "city_road_3d"
    version: "2024.11.03"
    split: "train/val"
  code:
    repo: "perception/bev_detector"
    commit: "a1b2c3d"
  params:
    lr: 0.0005
    batch_size: 32
    epochs: 60
    backbone: "resnet50"
  hardware:
    gpu: "8 x A100"
  metrics:
    primary: "mAP_3d"
    guardrail: "latency_ms"
  output:
    checkpoint: "s3://models/bev_detector/v3/"

实验定义的价值在于：它把“人脑记忆”变成“机器可读记录”。当实验数量从几十增长到几千时，没有统一实验定义的团队会迅速陷入“这个结果是谁跑的、用的哪版数据”的混乱。

二、实验生命周期：从创建到归档的状态流转

实验生命周期描述一次实验从创建到归档所经历的状态变化。典型状态包括：草稿（Draft）、排队（Queued）、运行中（Running）、成功（Succeeded）、失败（Failed）、已归档（Archived）。状态流转必须由系统自动记录，而不是靠人工填写。

生命周期管理的意义在于：它让实验具备“可中断、可恢复、可审计”的能力。例如，当训练任务因节点故障失败时，系统应保留失败状态、日志与中间检查点，支持从最近检查点恢复，而不是从头重跑。对于自动驾驶这种训练成本极高的场景，生命周期管理直接决定算力利用率。

建议为每个状态定义明确的进入条件与退出条件，例如“Running”必须绑定实际启动的容器 ID 与开始时间，“Succeeded”必须关联最终评测报告，避免状态成为无意义的标签。

三、实验元数据：让结果可解释、可检索

实验元数据（Metadata）是描述实验的“数据的数据”。它分为三类：标识元数据（实验 ID、名称、创建人、时间）、环境元数据（代码提交、镜像版本、CUDA 驱动、GPU 型号）、结果元数据（指标、权重路径、日志路径、耗时、成本）。

元数据设计的关键是“可检索”与“可比较”。如果元数据只是散落在日志里，就无法支持“找出所有 mAP 大于 0.6 且延迟低于 50ms 的实验”这类查询。因此，元数据应写入结构化存储（如数据库或实验追踪系统），并建立索引。

元数据类别	典型字段	作用
标识元数据	experiment_id、name、owner、created_at	唯一识别与责任归属
环境元数据	git_commit、docker_image、cuda、gpu_type	保证环境可复现
参数元数据	lr、batch_size、epochs、augmentation	支持超参对比与消融
结果元数据	mAP_3d、recall、latency_ms、checkpoint_uri	支撑指标比较与模型选择
运行元数据	start_time、end_time、duration、cost	评估效率与资源成本

四、实验追踪与实验看板：从记录到决策

实验追踪（Experiment Tracking）是指在实验运行过程中自动采集参数、指标、日志与产物，并关联到实验 ID 的过程。它强调“自动”与“实时”：自动采集避免人工遗漏，实时更新支持早期发现异常。常见做法是在训练脚本中集成追踪 SDK，在关键节点上报指标。

from tracker import ExperimentTracker

tracker = ExperimentTracker(experiment_id="bev_detector_lr_sweep_v3")
tracker.log_params({"lr": 0.0005, "batch_size": 32})
for epoch in range(60):
    metrics = train_one_epoch()
    tracker.log_metrics(metrics, step=epoch)
tracker.log_artifact("s3://models/bev_detector/v3/best.pt")

实验看板（Experiment Dashboard）则是追踪数据的可视化层。它把分散的实验聚合为可比较的视图，通常包括：指标趋势曲线、超参平行坐标图、实验对比表格、资源消耗热力图。看板的价值不是“好看”，而是缩短从数据到决策的路径：让工程师在几分钟内判断哪组超参更优、哪次失败值得复盘。

五、案例与场景：一次超参扫描实验的完整闭环

假设团队要验证“学习率对 BEV 检测模型小目标召回率的影响”。首先，创建实验定义，声明数据集版本、代码提交、学习率扫描范围与评测指标。随后，系统按生命周期将任务排队并调度到 8 卡 A100 节点。训练过程中，追踪 SDK 自动上报每个 epoch 的 mAP_3d、recall 与 latency_ms。实验结束后，看板自动生成学习率与召回率的趋势曲线，并标记出最优配置。最后，该实验的元数据被归档，供后续复现与审计。

这个闭环中，任何一环缺失都会导致问题：没有实验定义，结果无法解释；没有生命周期，失败任务无法恢复；没有元数据，无法检索历史；没有追踪，指标靠人工记录易错；没有看板，决策依赖直觉。

六、常见误区与复盘

误区一：把实验管理等同于“记日志”。日志是非结构化文本，无法支持高效检索与对比。实验管理要求结构化元数据与统一 ID。
误区二：只记录成功实验。失败实验同样有价值，它记录了“此路不通”的边界条件，应保留失败状态与日志。
误区三：元数据字段随意增减。字段不统一会导致看板无法聚合。建议先定义最小元数据规范，再逐步扩展。
误区四：看板只给管理者看。看板首先应服务于一线工程师的日常对比与排障，其次才是汇报。

实验管理的落地难点不在工具，而在纪律：每次实验都必须通过统一入口创建，禁止“手工跑脚本、结果存本地”。否则再好的追踪系统也会被绕过。

总结来看，实验定义是起点，实验生命周期是骨架，实验元数据是血液，实验追踪是神经，实验看板是眼睛。五者协同，才能让自动驾驶训练从“一次性尝试”走向“可复现、可比较、可积累”的工程体系。