4. 大规模批量验证需求分析

当 CARLA 从“单场景调试”走向“大规模批量验证”,需求分析的重点不再是“能不能跑通一个场景”,而是“如何用可度量的方式证明自动驾驶系统在成千上万次运行中足够可靠”。本节把批量验证需求拆成六个相互约束的维度:验证目标、覆盖度指标、回归测试、性能基准、安全关键场景与工程化挑战,并给出可落地的指标定义与工程约束。

一、验证目标:从“通过率”到“风险可解释”

批量验证的第一需求是明确目标层级。常见目标包括:功能正确性(是否完成预期驾驶行为)、安全性(是否发生碰撞、越界、闯红灯)、舒适性(加速度、 jerk、横向偏移)、合规性(是否满足交通规则)以及鲁棒性(在扰动、传感器噪声、天气变化下是否稳定)。目标必须可量化,否则批量运行只会产生“大量日志”而非“验证结论”。

验证目标应写成可判定的断言,例如:
• 安全:碰撞率 = 0,且最小 TTC > 1.5 s;
• 功能:变道成功率 ≥ 99.5%,且变道完成时间 ≤ 6 s;
• 舒适:纵向加速度 |a| ≤ 3 m/s²,jerk ≤ 5 m/s³;
• 合规:红灯越线次数 = 0,限速超速 ≤ 5 km/h。

二、覆盖度指标:让“跑得多”变成“跑得全”

覆盖度是批量验证的核心度量。仅统计场景数量没有意义,必须按维度切分:场景类型(跟车、变道、交叉口、环岛、行人横穿)、道路拓扑(直道、弯道、匝道、无保护左转)、环境条件(晴天、雨天、夜间、雾天)、交通密度(低、中、高)、动态参与者(车辆、行人、骑行者)以及 ODD 边界(施工区、临时管制)。常用指标包括场景覆盖率、参数空间覆盖率、代码路径覆盖率和风险覆盖度。

覆盖维度示例取值度量方式目标建议
场景类型跟车/变道/交叉口/行人横穿已覆盖类型数 / 总类型数≥ 95%
环境条件晴/雨/夜/雾组合覆盖矩阵关键组合 100%
交通密度低/中/高每档运行次数每档 ≥ 200 次
参数空间车速、间距、切入角拉丁超立方采样覆盖率≥ 90%
风险等级低/中/高/极高高风险场景占比≥ 30%

三、回归测试:批量验证的“防退化”机制

回归测试要求每次算法迭代后,对历史关键场景集重新运行并对比结果。批量验证中的回归不是简单重跑,而是建立“基线—候选”对比:基线为上一稳定版本,候选为当前提交。对比指标包括通过率变化、碰撞事件增减、平均接管次数、最小 TTC 分布偏移等。若候选版本在任一安全关键场景上出现退化,应直接阻断合并。

# 回归对比示例(伪命令)
carla-batch run --suite regression_v3 --baseline v1.8.0 --candidate v1.9.0 \
  --metrics collision,ttc,comfort,completion \
  --report diff_report.json

# 输出摘要
baseline_pass_rate: 0.982
candidate_pass_rate: 0.976
regressions: 7 scenarios (3 safety-critical)
action: BLOCK_MERGE

四、性能基准:仿真吞吐与实时性约束

大规模批量验证必须回答“单位时间能验证多少场景”。性能基准包括:单场景仿真耗时、每秒推进步数、并行 worker 数量、GPU 利用率、内存峰值、场景加载时间与结果落盘延迟。CARLA 中常见的瓶颈是渲染与传感器数据回传,因此需要区分“同步模式”与“异步模式”的吞吐差异,并设定可接受的实时因子(sim time / wall time)。

建议基准:单 worker 在 20 Hz 同步模式下,实时因子 ≥ 0.8;8 worker 并行时总吞吐 ≥ 5 倍单 worker;单场景平均耗时 ≤ 90 s;结果落盘延迟 ≤ 2 s。若低于该基准,应优先优化传感器频率、关闭非必要相机或改用批量 API。

五、安全关键场景:批量验证的价值高地

安全关键场景是批量验证中最需要被“反复跑、重点跑”的部分,包括:前车急刹、cut-in、行人突然横穿、无保护左转、鬼探头、施工区锥桶改道、雨天低附着制动等。这些场景数量少但风险高,必须单独建立场景库并提高运行次数。批量验证中常用“重要性采样”与“对抗生成”提升高风险场景命中率,而不是均匀随机撒点。

CARLA 大规模批量验证需求六维关系 批量验证 需求分析核心 验证目标 安全/功能/舒适/合规 覆盖度指标 场景/参数/风险覆盖 回归测试 基线对比/防退化 性能基准 吞吐/实时因子/资源 安全关键场景 急刹/横穿/无保护左转 工程化挑战 并行/调度/数据治理 目标定义指标,指标驱动覆盖,覆盖支撑回归,回归依赖性能,安全场景决定优先级,工程化决定可扩展性

六、工程化挑战:从脚本到流水线

批量验证的工程化挑战集中在四方面:并行调度(多 worker 争抢 GPU、端口与场景资源)、数据治理(日志、回放、指标、视频的存储与索引)、可复现性(随机种子、CARLA 版本、地图、天气、传感器配置必须锁定)、结果可信(避免因超时、崩溃、丢帧导致的假通过)。实践中应把批量验证做成 CI 流水线的一环:提交触发、场景分片、并行执行、指标聚合、门禁判定、报告归档。

常见误区:
1. 只统计“跑了多少场景”,不统计“覆盖了哪些风险”;
2. 回归只比通过率,忽略 TTC 分布与接管次数的退化;
3. 并行时未隔离随机种子,导致结果不可复现;
4. 把超时或崩溃当作“未通过”而非“无效运行”,污染统计;
5. 安全关键场景与普通场景混跑,导致高风险场景被稀释。

综上,大规模批量验证的需求分析应形成闭环:以验证目标定义断言,以覆盖度指标约束场景集,以回归测试防止退化,以性能基准保障吞吐,以安全关键场景聚焦风险,以工程化能力支撑可扩展与可复现。只有这六个维度同时被量化并纳入流水线,CARLA 批量验证才能从“跑得多”升级为“验证得准”。