一句话理解模型评估与回归检测

模型回归检测 = 每次版本迭代时，有系统、有量化地确保新模型"不比旧模型差"，而不是靠发版前跑几个case看看效果

低级做法：训练完看一眼loss曲线，找几个场景跑一下可视化，“看起来没问题"就发版

专业做法：构建离线评估Pipeline + 精心设计的回归测试集 + 统计显著性分析 + CI/CD门禁自动化

“回归”(Regression)在模型迭代中的含义与软件工程一致——新版本不应该破坏已有的能力。一个模型可能在nuScenes验证集上mAP涨了2个点，但在某些关键场景（如夜晚雨天）上反而变差了。没有系统的回归检测，这种退化很容易被淹没在平均指标的大海里。

第一部分：评估Pipeline搭建

一个生产级别的模型评估Pipeline至少由三个维度的评估组成：开环感知、闭环规划和计算延迟。这三个维度分别回答三个不同的问题：“模型看得准不准”、“模型开得好不好”、“模型跑得快不快”。

开环感知评估

开环感知评估是在离线数据集上评估模型感知模块的精度。这是最常见也最容易搭建的评估环节。

典型指标矩阵：

感知任务评估覆盖以下维度：

感知任务核心指标辅助指标
3D目标检测mAP@IoU=0.5/0.7, NDSmATE, mASE, mAOE
BEV语义分割mIoU单类别IoU, boundary IoU
在线地图mAP for lane/dividerChamfer distance
运动预测minADE(1/5/10), minFDEmiss rate, overlap rate

Pipeline中的关键陷阱：

陷阱1：数据集泄露(Data Leakage)。训练集和测试集不能包含来自同一段路测序列的数据。这在自动驾驶中尤其重要，因为连续帧之间存在高度相关性。标准做法是：按"场景”(Scene)来划分数据，同一段路测中连续几十秒的数据要么全部在训练集，要么全部在测试集。

陷阱2：指标与最终性能的gap。开环感知指标提升并不总是带来闭环驾驶性能提升。例如，mAP涨了2个点，但在同一个模拟场景中开一圈，接管率可能反而增加了。这是因为感知指标无法捕捉到"哪些错误真正会影响驾驶决策"。

Waymo在实际运营中报告过这样一个案例：某个模型在夜间检测的mAP提升了5%，但在夜间道路上的实际接管率反而上升了3%。根因分析发现，mAP提升主要来自对远处静止车辆的检测精度提高，但这些车辆与驾驶决策无关；而近处动态车辆的召回率实际上略有下降。这个案例说明：指标体系必须与最终驾驶性能对齐，不能只看通用感知指标。

闭环规划评估

闭环评估是在仿真环境中，用新模型替换规划模块，评估完整驾驶循环的性能。这是比开环评估更接近最终产品体验的评估方式。

常见闭环指标：

  • 驾驶得分(Driving Score)：所有场景的平均分，加权考虑安全和任务完成度
  • 接管率(Intervention Rate)：每百公里需要人工接管的次数——这是最"接地气"的指标
  • 碰撞率(Collision Rate)：每千公里发生碰撞的频率
  • 任务完成率(Task Success Rate)：在规定时间内完成指定驾驶任务的概率
  • 舒适性评分(Comfort Score)：基于加速度、加加速度的客观量度

开环vs闭环的内在张力：

开环评估和闭环评估之间存在天然的错配。开环评估要求模型在给定完整历史轨迹的条件下做出精确的预测/规划，而闭环评估中模型只能看到已执行的部分轨迹。这导致一个有趣的现象：存在一些"开环好、闭环差"的模型——它们在正确的历史输入下能做出精确预测，但一旦自己的预测被用于闭环执行，预测误差累积后会迅速偏离正确轨迹。

业界解决这个问题的方法是"开环+闭环双轨评估"：

  1. 开环评估作为"第一道门"——筛选掉感知精度不达标的模型版本
  2. 闭环评估作为"第二道门"——在仿真环境中验证规划决策质量
  3. 只有双轨都通过，才允许模型进入路测验证阶段

计算延迟评估

计算延迟是模型评估中最容易被忽视的环节。一个感知精度顶尖但推理速度达不到10Hz的模型，在车上和废纸没什么区别。

延迟评估的核心维度：

  1. 端到端延迟 (End-to-End Latency)：从传感器数据到达计算平台到输出控制指令的时间。L4系统通常要求<150ms。
  2. 模块级延迟：感知、预测、规划每个模块的独立延迟。需要分析pipeline中哪个模块是瓶颈。
  3. P99延迟：不是平均延迟，而是99分位的延迟，用于评估在计算负载波动时的稳定性。

工程实践中的量化经验：

模块目标延迟警告延迟门禁阈值
感知(含BEV编码器)<50ms50-80ms>100ms
运动预测<20ms20-40ms>50ms
规划决策<30ms30-50ms>60ms
端到端pipeline<100ms100-150ms>150ms

一个容易被忽略的细节：GPU计算时间不是评估的全部。CPU上的后处理逻辑（如NMS、轨迹平滑）在复杂场景中可能占总延迟的40%以上。必须对CPU和GPU的计算时间分别打点统计。

第二部分：回归测试集设计

回归测试集与一般的验证集不同。验证集的目标是"评估模型的泛化能力"，而回归测试集的目标是**“捕捉新版本可能退化的特定场景”**。

设计原则

原则1：场景覆盖的完整性

回归测试集需要覆盖所有已知的"关键场景类别"。以Waymo的回归测试集为例，其场景分类维度包括：

  • 道路类型：高速路、城市道路、乡村公路、环岛、停车场的出入口
  • 光照条件：白天、黄昏、夜晚
  • 天气：晴天、小雨、大雨、雪天
  • 交互类型：无交互（自由行驶）、单车交互（如换道）、多车交互（如无保护左转）、行人交互
  • 异常情况：施工区域、交通事故现场、逆行车辆、动物穿行

每个维度组合至少需要5-10个场景实例。按照这个设计，即使只考虑3种道路类型×3种光照×3种天气×5种交互类型×3种异常情况，也需要超过400个测试场景。实际中，业界公司的回归测试集规模通常在2000-10000个场景之间。

原则2：难度层级梯度

不是所有场景都有相同的难度。回归测试集需要包含不同难度层级的场景：

  • P0层（必备通过）：最基本的交通场景。城市道路直行、正常跟车、遇到红灯停车。这些场景如果通过不了，模型根本不具备上路资格。P0场景应该100%通过。
  • P1层（核心能力）：常规交互场景。换道、合流、转弯让行。这些是L4的核心能力。P1场景通过率目标>95%。
  • P2层（进阶能力）：复杂交互场景。无保护左转、环岛通行、多车道换道。P2场景通过率目标>85%。
  • P3层（边缘场景）：罕见/极端场景。动物穿行、临时交通管制、路面大坑。P3场景不要求高通过率，但需要监控趋势——新版本不能比旧版本退步。

原则3：对抗样本纳入

回归测试集必须包含人为构造的"对抗样本"——即在场景中引入微小的扰动，测试模型的鲁棒性。典型的对抗注入方式包括：

  1. 光照扰动：在验证场景的特定帧中随机改变亮度(-20%至+20%)或添加光照斑块
  2. 遮挡注入：在摄像头视野的部分区域添加遮蔽物，模拟前方大车遮挡
  3. 传感器噪声：在LiDAR点云中随机删除5-15%的反射点，模拟灰尘/雨滴遮挡
  4. 交互偏离：让NPC车辆以"不太合理但有可能"的方式行动（如略微延迟反应时间）

测试集维护

回归测试集需要持续更新，不是一次建好就永久使用。维护实践包括：

  1. 新增场景：每当路测中发现新的关键场景（如新的失败模式），将其加入回归测试集
  2. 场景去重：定期做场景聚类，剔除过于相似的场景，控制测试集规模的持续膨胀
  3. 版本迭代标注：为每个场景标注"创建日期"和"初始版本通过状态"，方便追踪场景是否被"遗忘"

第三部分：指标一致性分析

评估中最隐蔽的陷阱是：两次评估结果之间的差异到底是真实的模型能力变化，还是来自数据抽样/随机种子/仿真实例的波动？

Confidence Interval

评估指标永远是一个统计量，不应该只看一个数字。对于每次评估，需要报告置信区间。

常用的置信区间计算方法：

  • Bootstrap法：对测试集的N个样本做B次有放回抽样（B通常取1000-10000），每次计算指标值，得到指标的分布。取2.5%和97.5%分位点作为95%置信区间。
  • 解析法：对于服从特定分布的指标（如成功率为二项分布），可以用正态近似法。例如，碰撞率的置信区间为：
$$ \hat{p} \pm z_{\alpha/2} \sqrt{\frac{\hat{p}(1-\hat{p})}{n}} $$

工程实践中的经验规则：

  • 如果新旧版本的置信区间完全不重叠，可以认为有"强证据"表明模型发生了变化
  • 如果置信区间存在部分重叠，则需要更进一步的统计检验来判断变化是否显著
  • 置信区间的宽度与测试集规模相关：测试集越小，区间越宽，判断力越弱

假设当前版本的碰撞率为0.5%（1000公里中发生5次碰撞），测试规模为10000公里，95%置信区间约为[0.36%, 0.64%]。如果新版本的碰撞率落在[0.36%, 0.64%]区间内，需要更仔细的分析才能下结论。

Statistical Significance

统计显著性检验用于回答：“观测到的差异有多大可能性只是随机波动？”

最常用的方法是双样本假设检验。对于连续指标（如mAP、ADE），使用Welch’s t-test：

$$ t = \frac{\bar{x}_1 - \bar{x}_2}{\sqrt{\frac{s_1^2}{n_1} + \frac{s_2^2}{n_2}}} $$

对于比率指标（如碰撞率、接管率），使用比例检验或卡方检验。

工程中的p-value阈值设定：

使用场景p-value阈值含义
研发阶段的A/B测试0.05标准显著性水平
发布门禁 (Release Gate)0.01更严格，降低误升级风险
安全关键指标退化检测0.001极度保守，尽量不放行有风险的新版本

需要注意的是：当回归测试集中包含大量独立指标时（比如30个场景类别×5个指标=150次检验），需要进行多重假设检验校正。常用的方法包括Bonferroni校正（将阈值除以检验次数）和FDR(False Discovery Rate)控制。

Effect Size

统计显著性回答的是"差异是否真实"，而效应量回答的是"差异有多大"。一个差异可能在统计上显著（p<0.01），但效应量极小，对实际驾驶体验没有影响。

常用的效应量指标：

  • Cohen’s d：两组均值差异除以合并标准差
$$ d = \frac{\bar{x}_1 - \bar{x}_2}{s_{pooled}}, \quad s_{pooled} = \sqrt{\frac{(n_1-1)s_1^2 + (n_2-1)s_2^2}{n_1 + n_2 - 2}} $$
  • Cohen’s d的经验解释：d=0.2为"小效应"，d=0.5为"中效应"，d=0.8为"大效应"

工程实践建议：

  1. 对待"统计显著但效应量小"的退化：可以放行，但需记录到模型的"已知退化清单"中
  2. 对待"统计不显著但效应量大"的退化：警惕，增加测试数据量以降低随机波动
  3. 对待"统计显著且效应量大"的退化：无论是否理解根因，都应停止发布

第四部分：CI/CD流水线中的自动化门禁

回归检测的终极目标是"自动化"——当工程师提交一个模型版本后，系统自动运行评估，自动判断是否通过，自动决定是否进入下一阶段。

门禁机制设计

一个典型的自动驾驶模型CI/CD流水线包含多道门禁：

Gate 0：编译与格式检查

  • 代码/模型格式检查通过
  • 模型导出格式正确（如ONNX/TensorRT）
  • 无未处理的安全警告

Gate 1：单元测试与开环评估

  • 感知相关指标退化检测（如mAP下降不超过1个点）
  • 统计显著性检验（p<0.01且Cohen’s d>0.2时标记为退化）
  • 计算延迟评估（P99延迟不超过阈值的110%）

Gate 2：闭环评估

  • 在回归测试集上运行闭环仿真
  • 碰撞率不超过基线的1.5倍（需统计检验确认）
  • 接管率不超过基线的1.3倍
  • 任务完成率不低于基线的95%

Gate 3：路测对比(Shadow Mode)

  • 新版本以Shadow模式部署到测试车队（不实际控制车辆，但与线上版本并行推理）
  • 连续运行至少10000公里
  • 决策与线上版本的一致性分析，识别高风险差异

Regression Gate的实现

Regression Gate是门禁体系的核心——它不是一个简单的阈值比较，而是一个有状态的统计判断过程。

实现伪代码逻辑：

defrvf#hieeeioifllgor门gisrl禁hlfeeambdcciei决_err:rsteaeiiflf策sneleesitsl__se(tettioretnbceivhunuuonilaeaoi:isev}eir(rrnsciwsnss_fi)rgnvnn_,n=ef__rfoihig=e=irreelt_"o""an_n=geegca""""ysRlNPt[evec.ggrttmdeseEaEAe]wawocirre_ieefe=vJtES(_l_moseessotlfveEiDSnvvpm_sssinrtee[rCoS"ea=auphssizsiacrviTn_,wlltuiiioe.c"tit"sR_betgoona":_tfy,)E[mia-_ehnn:=p:syo)V]ensc_epdi"rh>Itebicr==cemez:>iErnla(i_onelevg0Wieisn(bccmdtt""0h:"cwneebeiip(ra:hi:_,s_elwat__u{i,ins,m_i_stnntcegevemnveeeee,fhvvibteealrww_f"ieoart_li[..ceorlsirv,nmulociliaeciaeepohtfattlsclc_tpwe_tyii.sovreenseioni[nairrsifonetmflc_zfns_eei,]<>deesmmtg:(,cesr.cccdtit(isoiie_fr)can__lsi:]mfbbticpiaaaz.slgss,es,e.eee_s..c>vcsaluoeoimopn0rnzpwpf.ifeleei5ti)errgyg_.e)ssl=:i#ts=zdee完[")全m"h不eli重tog叠rwh且i""更c]差])

人工Review的时机

全自动门禁不是目标，“合适的自动+人工review比例"才是。以下场景应触发人工review：

  1. 不明原因退化：统计显著但自动化分析无法解释根因的退化
  2. 跨模块退化：感知精度提升但规划指标退化的案例（可能意味着pipeline中存在需要手动分析的隐式依赖）
  3. 对抗样本退化：在人工构造的对抗样本上出现退化，需要安全专家评估风险
  4. 少量高置信度退化：只有极少数场景（如1-2个）出现严重退化，其他场景不变或改善——需要人工判断这些场景是否重要

CI/CD工程的现实挑战

挑战1：评估时间过长。一个完整的回归测试（开环+闭环+延迟）在大规模测试集上可能需要数小时到数十小时。为缩短从提交到反馈的循环周期，常用的策略包括：

  • 分层运行：先跑小规模快速筛选集（100-200场景，15分钟内出结果），通过后再跑完整集
  • 并行加速：将场景分布到GPU集群上同时运行
  • 缓存复用：如果只更新了规划模块，缓存感知模块的评估结果

挑战2：基线漂移。随着时间推移，回归测试集的场景也在扩展，旧基线可能过时。实践上采用"滑动基线"策略：总是与最近3次已发布的版本进行比较，取中位数作为参考基线。

挑战3：仿真与现实的不一致性。闭环评估中的仿真环境与现实世界存在差距。一个模型在仿真中表现良好但在路测中表现不佳的情况经常发生。这是CI/CD流水线难以彻底解决的问题——只能通过不断校准仿真场景参数来缩小这个gap。

第五部分：常见工程陷阱与经验

陷阱1：只看平均指标，忽视长尾退化

最经典的例子：两个模型版本的NuScenes驾驶得分(DS)都是87.5分，看起来没有退化。但细看发现，新版本在有行人的场景中DS从85降到了72，只是在无行人的简单场景中从88提升到了90，才拉平了平均分。

对策：在回归检测中，不仅要看整体指标的退化，还要预设多个细分维度（交互类型、道路复杂度、天气等），对每个维度独立进行统计检验。

陷阱2：过度关注开环指标

开环指标（如mAP、ADE）比闭环指标（如接管率）更容易计算，导致一些团队过度依赖开环指标做回归检测。但开环指标的提升并不能保证闭环性能的改善。

真实案例：某团队将BEV检测的mAP从62.1%提升到65.8%，开环评估通过所有门禁。但Shadow模式路测发现，接管率从每百公里1.2次上升到1.8次。根因分析发现，mAP的提升主要来自对远处大目标的检测改善，但新模型对近处小目标的召回率有所下降。而近处小目标直接关系驾驶决策安全。

对策：开环指标的门禁阈值需要更加严格（如mAP退化不超过0.5个点），同时必须搭配闭环评估。

陷阱3：测试集被"记住”

回归测试集一旦被长期使用，模型可能在实际的过拟合——不是过拟合训练集，而是过拟合测试集。这在基于学习的模型中尤其常见：当模型反复在一个固定的场景集上测试后，工程师会有意无意地针对测试集中的场景进行优化。

对策：保留一个"黄金测试集"（Golden Test Set），这个集合是非公开的，只在最终发布前使用一次。定期轮换回归测试集中的场景。

关键论文与延伸阅读

  1. Waymo评估体系：S. Dafrý et al., “Closed-loop Evaluation Method for Autonomous Driving”, ICRA 2023 Workshop. — 业界开环+闭环双轨评估的实践案例
  2. 统计显著性与回归检测：A. Karpathy, “MLE2: Engineering ML Systems”, Stanford CS329A Lecture. — 从软件工程角度讲解ML回归检测
  3. NuScenes评估指标：H. Caesar et al., “nuScenes: A Multimodal Dataset for Autonomous Driving”, CVPR 2020. — 包含NDS/DS等自动驾驶综合指标的原始论文
  4. Confidence Interval in ML: T. Hastie et al., “The Elements of Statistical Learning”, Chapter 7. — 模型评估中置信区间的经典参考
  5. 仿真与真实gap分析：W. Zhou et al., “Exploring Sim2Real Gap in Autonomous Driving”, CoRL 2023. — 仿真评估与现实部署差异的系统分析

模型回归检测不是"跑一下测试看看结果"的简单工作，而是一套完整的工程体系。它最核心的哲学是：不要相信任何单一的评估结果——相信多维度交叉验证的声音。一个指标提升，不是庆祝的理由；多个指标同时退化，才是停止发版的信号。