今年年初我们内部复盘一套感知模型时出了一个特别典型的状况离线评测的 mAP 比上一版提升了 3 个点所有人都觉得稳了结果上了实车路测雨夜场景连续漏检安全员一脚急刹差点出事。后来查了半天问题不在模型在评测数据本身——测试集里恰好缺少夜间雨天的大车样本模型不是变强了是被“偏科”的数据骗了。这件事让我更确定一个判断智能驾驶感知模块的测试评估方法本质上不是“多跑几公里看会不会出事”而是一套围绕指标、数据、流程三个维度建立的系统工程。如果你是感知算法工程师、测试开发、实验室负责人或者刚转行做自动驾驶验证这篇会比较对口。它会先讲感知模块测试的整体设计思路再拆解数据采集与真值标注、核心评估指标的计算与解读方式以及落地时最容易踩的坑。考虑到内容量不小下一篇再单独讲场景库建设、仿真回灌和自动化回归流水线。1. 感知模块测的是什么先把测试对象定义清楚1.1 感知模块的组成与输出类型很多人一说“感知测试”第一反应就是测摄像头识别准不准。但实际做起来感知模块的边界远没有这么简单。一套完整的感知系统至少包含几种不同的传感器前视摄像头、环视摄像头、激光雷达、毫米波雷达可能还有超声波雷达再往下是前融合或后融合算法。不同传感器组合输出的目标类型也不一样。拿输出层来说感知模块通常要给出动态目标车辆、行人、骑行者、锥桶、动物等输出 2D 框或 3D 框、速度、朝向。道路结构车道线、路沿、可行驶区域、停车位。交通设施红绿灯、交通标志用状态机和时间序列判断。静态障碍物栏杆、护栏、施工区域、地面凸起物。纯几何结果占用栅格Occupancy Grid、点云分割结果。这里有个关键点测试评估方法必须跟着输出类型走不能用一套近景 2D 检测指标去衡量 3D 目标识别和可行驶区域分割。比如摄像头做 2D 检测时一个小的目标在图像里只有十几像素人眼看都费劲但 2D mAP 可能不但不低还拉高了整体指标而同一套模型去做 3D 检测距离估计误差可能直接导致制动决策失误。这就是为什么我接到评估任务时第一步永远是先问清楚被测对象的输入是什么、输出是什么、接口定义是什么。没有这一层后面所有指标都可能是鸡同鸭讲。1.2 测试评估的基本框架从需求到回归的闭环我刚带测试团队的时候习惯把整个测试工作想象成一个漏斗。最底层是数据回灌和离线评测这层跑的量最大成本最低一晚上能跑完几十万帧往上一层是场景库测试把典型场景和边角案例从海量数据里提取出来固定成可重复执行的用例再往上是封闭场地测试和开放道路测试成本直线上升但能校验很多离线环境发现不了的系统集成问题。这个结构背后是有逻辑的。感知模块跑在开放环境下输入的组合状态几乎是无限的白天、黑夜、逆光、雨雪、隧道出入口、城市路口、高速匝道……你不可能靠真实路测穷尽所有情况但只要把大量数据离线切好、标注好就能用很低的成本做覆盖。所以一个相对靠谱的评估闭环是需求覆盖矩阵 → 数据集建设 → 评估指标定义 → 离线评测 → 场景复测 → 问题反馈 → 回归验证需求覆盖矩阵非常重要它把“用户想要什么”翻译成“测试要覆盖什么”。比如产品要求“100 米内能检测到前方静止车辆”那测试数据里就必须有 100 米左右距离的静止车辆样本还得有不同高度、颜色的车辆。如果需求写了“雨量中雨以上不能漏检”那数据里就得有中雨和大雨的标注样本。没有需求矩阵数据采集就会变成“有什么采什么”最后指标一大堆但真正回答不了产品问题。这里还要强调“冻结”的理念。测试集一旦建立必须冻结下来不能今天加一帧、明天删一帧。我见过不少团队因为测试集频繁变动导致前后两个模型版本之间的对比完全失真。测试集冻结不是不让扩充而是要经过正式的版本变更流程记录清楚每一版变化了什么否则你做的不是回归是在测数据集本身。2. 数据是测试的唯一原料采集、标定与真值管理2.1 传感器配置与标定先让数据“对齐”感知模块测试的第一步永远是保证传感器数据和真值数据在时间和空间上严格对齐。这里最常见的问题就是时间戳不同步。拿激光雷达和摄像头的融合测试来说激光雷达每帧扫描需要几十毫秒而摄像头是严格的逐帧曝光如果两者时间戳不校准一个 60km/h 速度下的目标时间差 50 毫秒就可能产生接近 1 米的位移误差。这个误差到了测距精度评估里会直接被算成感知模块的性能损失但实际上根本不是算法的锅。我一般建议数据采集系统里必须做一体化授时用 GPS 时间作为统一基准所有传感器日志都打上同一个时钟源的时间戳。同步之后要做传感器标定内参标定、外参标定、摄像头与激光雷达联合标定。标定质量直接影响评估结果的真实性。如果外参标定有偏差一个真实坐标为 (50, 1.5, 0) 的目标在点云投影到图像时可能会偏移好几个像素最后导致 3D 框与图像框匹配失败。在项目起步时配置采集车的 SensorConfig 也值得固化。我的做法是把传感器型号、安装位置、角度、焦距、帧率、分辨率全部写进一个配置文件每次出车采集之前都检查一遍。如果前后两次采集用的传感器安装位置不一致那么模型在不同数据集上的表现差异会混杂进传感器差异你根本说不清楚性能变好还是变坏是算法引起还是传感器引起。2.2 真值标注最容易被低估的工作量数据有了还差真值。真值标注的工作量我在早期严重低估过。一套完整的感知验证数据集不只是画几个 2D 框那么简单还包括目标 3D 尺寸、朝向角、遮挡状态、截断状态、目标轨迹 ID、车道线语义、可行驶区域边界等等。不同的感知模块输出对应不同的标注类型。真值标注的关键不是“画得对”而是“画得一致”。比如雷达点云中一个 30 米外的行人标注员 A 可能画一个刚好包住点云的密集框标注员 B 可能按行人的实际物理轮廓画一个更大的框。两个框的 IoU 差别可能很大直接导致计算 mAP 时出现显著波动。解决这个问题需要一本把所有边界情况写清楚的标注手册Labeling Guide并经过多轮试标、判标、双人一致性复核。标注一致性验证是很多团队容易跳过的步骤。你可以把同一段数据分别给两个标注组画两遍然后计算它们之间的 IoU如果平均 IoU 低于某个阈值比如 2D 框低于 0.83D 框低于 0.7就说明标注规范还不够清晰或者标注员培训没到位。这时候千万别急着把数据送到下游因为用不一致的标注做评估结果就是噪声。如果项目有激光雷达和高精定位可以走“自动标注 人工复核”的路线。激光雷达在近距离范围内测量精度很高叠加高精地图和 SLAM 定位结果很多静态目标杆子、路沿、车道线可以自动生成真值动态目标则可以用多帧融合算法半自动跟踪生成轨迹。这套流程能大幅提升标注效率但前提是保留人工复核环节而且对动态遮挡物的处理要非常谨慎。2.3 场景覆盖与数据分布测试集不是越大越好在测试数据建设上我见过两种极端。一种是数据量焦虑拼命采数据觉得“越多越准”结果数据集里 90% 都是高速空旷场景城市复杂路口、雨天、逆光、夜间占比少得可怜另一种是“拍脑袋加数据”今天看到某个场景漏检了明天就加几千帧这类场景结果测试集分布严重倾斜评估结果变成单点场景的重复验证。正确的做法是用场景标签体系去约束分布。我常用的标签维度包括光照白天、夜晚、黄昏、隧道、逆光。天气晴天、阴天、小雨、中雨、大雨、雾、雪。道路类型高速、城市快速路、城区道路、园区道路、乡村窄路。目标类型轿车、SUV、公交车、货车、行人、骑行者、锥桶、施工机械。目标状态静止、低速、高速、变道、横穿、遮挡、截断。相对位置正前方、斜前方、侧向、后方、近距离、中距离、远距离。每次搭建评测数据集我都会按这些维度做统计先看看目标数量在“天气 × 距离 × 目标类型”交叉维度下有没有明显空洞。比如你发现 60 米以上的夜间轿车样本太少那这个位置上的漏检率指标可信度就非常低。同时数据集至少要分成训练集、验证集、测试集和盲测集四个池子。感知模型研发一般会在训练集上训验证集上调参测试集上做版本对比盲测集是预留的、完全不参与研发过程中任何决策的数据只在发版前做最终抽查。核心原则是任何数据都不能既当训练参考又当评估依据否则很容易出现过拟合到测试集的情况指标虚高上路就出问题。3. 把感知能力变成数字核心评估指标详解3.1 目标检测指标mAP、精确率、召回率怎么算、怎么用目标检测指标是感知评估里最常出现的但很多人对它的理解停留在“越高越好”。要真正用好它得知道它背后的计算逻辑。先看匹配规则。检测算法输出的框要和真值框匹配一般靠 IoU 阈值。2D 检测通常取 IoU 0.5 或 0.753D 检测常用 0.5、0.3 甚至更低的阈值因为 3D 框的角度和尺寸误差会被放大。在智能驾驶场景里我建议至少同时统计 3 个阈值下的指标不要只报一个点的结果这样才能看出框的质量。精确率Precision的含义是“预测出的目标里面有多少是真的目标”召回率Recall是“真实目标里面有多少被找出来了”。两者天然有矛盾。阈值设得宽松召回率高但误检变多精确率下降阈值设得严格精确率提高但漏检变多召回率下降。AP 曲线就是通过改变判定阈值画出 Precision-Recall 曲线后计算曲线下面积。mAP 是把所有类别的 AP 取平均。但在智能驾驶里只看整体 mAP 很容易掩盖问题。比如某车型在小目标类别上的召回率很低但因为轿车类别的样本量太大mAP 被拉高了。所以我在看目标检测结果时从来不看单一 mAP而是至少拆成三个维度看按距离拆0-30 米、30-60 米、60 米以上。按目标尺寸拆微小目标像素面积或点云点数少于阈值、中等目标、大型目标。按遮挡程度拆无遮挡、部分遮挡、严重遮挡。用一个具体的例子说明某版本模型总 mAP 从 0.78 提升到 0.82看起来不错但如果拆开后发现 60 米以上行人召回率从 0.65 掉到 0.55那就必须当成一个关键风险项来对待。高速巡航场景里一个 80 米外的行人可能只有 3 秒钟反应时间这个指标的下降直接影响安全性不能只看总 mAP。对于风险评估我还常用一个自定义指标每万帧的严重漏检次数。严重漏检的定义是“理应被检测到但没有输出的高危害目标”比如近距离行人、骑行者、前方静止车辆。这类指标比 mAP 更贴合产品安全视角。它是计数型指标能直观反映“开一万帧可能会漏几次”很多安全评审委员会也更容易接受这种口径。3.2 测距测速与跟踪指标移动的目标更考验能力感知模块不只输出目标框还要输出距离和速度。车企法规测试和功能安全评估里测距、测速误差是硬指标。距离误差最常用的是平均绝对距离误差MADE和均方根误差RMSE。MADE 好解释“平均下来差多少米”RMSE 对离群点更敏感只要有一个目标的距离估计偏了 20 米RMSE 就会显著变大。我的建议是两个都看。比如 MADE 只有 0.8 米但 RMSE 达到 3.5 米说明大多数目标测距比较准但存在少量非常大的测距错误这类错误在 AEB 决策中可能直接导致制动时机错误。速度估计同理重点看相对误差而不是绝对误差因为低速场景下绝对误差 1km/h 和高速场景下绝对误差 1km/h 的意义完全不同。跟踪评估里最常用的是 MOTA 和 IDSW。MOTA 综合了漏检、误检、ID 切换三种错误但它的值对参数设置很敏感。IDSW同一目标 ID 被切换的次数又直接关系到下游轨迹预测和规划模块的稳定性。如果一个目标在交互场景里被频繁换 ID那后续预测模块很难输出平滑轨迹。这里提醒一句跟踪指标非常容易被评测代码的匹配阈值影响。我曾经排查过一个问题同一模型版本在同一数据集上MOTA 差了 6 个点最后发现是评测代码里帧间匹配 IoU 阈值一个用的是 0.3一个用的是 0.5。所以在评估环境里配置文件必须锁定评测代码必须走版本管理不能随手改参数。3.3 指标要分层看按场景、按对象、按风险等级我在团队里反复强调一个观念智能驾驶的感知评估不要只做算术平均要做业务加权。业务加权的核心是从“感知模块输出质量”转到“感知模块对整车安全的影响质量”。我实际使用过的一个思路是按危害等级给目标加权高危目标近距离行人、骑行者和前方静止车辆权重最高。中危目标中距离动态车辆、路口横穿目标。低危目标远距离目标、路边静态设施、可忽略误检。在这个框架下我会分别统计每个等级下的漏检率和误检率然后形成一张“风险矩阵表”。比如漏检一个 20 米外的行人比漏检一个 100 米外的路牌严重得多但误检一个路牌带来的影响可能只是虚减速而漏检一个路牌可能不会影响决策。这就是为什么不能把所有目标一视同仁。同时指标报告必须结合场景维度。同一份测试结果我会用不同维度切片输出晴天 vs 雨天、白天 vs 夜间、高速 vs 城区。这样既能看出模型哪个维度退化严重也能直接和需求覆盖矩阵对应上。如果产品需求里重点要求“夜间城区十字路口行人横穿”那报告里就必须有这一个切片的单独数据而不是只给整包指标。4. 测试落地时常见的坑与排查思路4.1 离线指标高一上路就露馅的典型原因“离线指标高但路测崩”是感知测试里最常见的现象。原因不外乎几类第一类是数据泄漏。训练集或验证集里混入了和测试集相同车次、相同路线的数据模型在测试集上表现自然好。这类问题隐蔽性很强尤其当数据都来自同一辆采集车、同一条固定路线时你根本分不清模型是学会了识别目标还是记住了这条路。解决办法是按“路段 ID 时间窗口”做数据分离确保同一路段在同一时间附近的数据不会被同时分进训练集和测试集。第二类是分布偏移。模型在训练阶段见过的数据大多数是晴天白天和高速路段测试集却各种复杂场景都有结果指标自然下滑。这不是测试方法错了而是训练数据和测试数据本身分布不一致。但我们需要在评测报告里明确指出“性能下降主要发生哪些场景”否则决策层容易得出“模型退化”的错误结论。第三类是标注缺陷被模型“学习”了。比如标注标准里行人一般被画成紧密框模型学到的就是框内像素非常集中测试集里一旦出现被截断一半的行人模型就以为不是行人。这类问题要通过增加截断、遮挡样本同时检查标注边界来规避。排查这类问题我一般会对“高分开局路测崩盘”的情况做一套固定动作先抽测测试集里的一部分数据人工看模型输出和真值是否合理再用场景拆分的指标找退化点最后还要检查评测代码里是不是存在使用了测试集先验信息的逻辑。比如有人在做预筛选时用了整段数据的平均帧信息这就相当于给检测器“透题”了。4.2 同一场景评测结果忽高忽低有一段时间我们同一版本模型在同一份测试集上连续跑了两遍得到两个不同的 mAP。排查了很久发现原因非常“低级”推理框架里 GPU 算子在不同线程下浮点累加顺序不同导致结果有微小数值差异再加上后处理里非极大值抑制对同等分数目标的顺序敏感有些目标被保留、有些被丢弃。感知评估的可复现性不是一个摆设它直接影响版本对比的置信度。我现在对评测环境有几点硬性要求固定随机种子包括初始化种子和数据加载种子。固定模型部署环境用容器或固定依赖版本。评测代码与算法的后处理版本一起打包记录。对重复运行结果做一次偏差检查两次结果差异超过一个很小阈值比如 AP 差 0.005时自动标记评测不可信。这类问题在引入暗光增强、超分等图像预处理模块后更容易出现因为这些模块通常有更强的随机性。处理方法是把预处理结果缓存下来对同一测试集只计算一次特征后再评估。4.3 指标之间互相矛盾怎么办真实项目里你经常会遇到“这个版本 mAP 提高了但 MOTA 掉了”或者“精度上去了召回率下来了”。很多新人会觉得指标算错了其实这大概率不是 bug而是指标本质就在度量不同的事情。举一个真实例子。某个模型为了压制误检把置信度阈值整体抬高结果测试集上的 Precision 提升、Recall 下降。这个“矛盾”其实是后处理阈值变化带来的它不反映模型特征提取能力的变化。要判断模型本身是否真的变好需要对比 PR 曲线而不是只对比某一个置信度阈值下的 Precision 或 Recall 点。我一般要求每次版本对比都输出 PR 曲线叠图同时对比“最优平衡点”附近的表现再看“低误检区”和“高召回区”各自的变化趋势。我还吃过一个亏只看整体 MOTA 提升没注意某个类别的 IDSW 暴增。后来复盘发现模型为了更准确地区分相邻车辆会把目标框切得更细于是轨迹关联时经常把 ID 打断。这个“指标矛盾”被藏在汇总数据里只有按类别拆分才看得到。所以评估报告至少要按类别和距离段各拆一版并在指标变化时记录版本间的配置差异否则很难定位问题来源。这里我可以给一份自己在用的问题排查速查表现象可能原因排查步骤离线指标高实路表现差训练/测试数据泄漏、分布偏移、标注习惯不同按路段ID做数据分离场景拆分对比人工抽检模型输出同版本同数据评测结果波动随机种子、GPU浮点差异、后处理顺序不固定固定随机种子和依赖环境结果缓存重复评测对比mAP提升但MOTA下降检测框分裂、ID匹配问题、不同度量关注不同维度按类别分析IDSW检测框稳定性分析PR曲线对比精度提升但召回下降置信度阈值调整模型未变查看PR曲线整体形态避免单点对比雨天指标退化严重数据集中雨天样本不足或模型未做过数据增强场景标签拆分补充雨天数据针对性评测4.4 一份可落地的评估报告应该包含什么评估报告是测试评估方法的最终产出物。一份能说服研发、产品、安全团队的评估报告我一般至少包含下面几个部分被测对象与版本信息模型版本、传感器配置、代码 commitID、评测环境镜像。数据集说明数据来源、场景分布、标注规范版本、测试集是否冻结。总体指标结果按检测、跟踪、测距测速分类汇总。场景拆分结果按天气、光照、道路类型、距离、目标类型的多维切片。风险分层结果高危目标漏检率、误检率以及典型失败案例截图。与上一版本的对比结论哪些维度提升、哪些维度退化、是否存在异常波动。已知问题与后续建议哪些是数据问题哪些是算法问题哪些需要补充采集。写报告时我还会附上几个典型的难例图像和对应的模型输出包括失败分析。那些“一眼看不出问题但指标就是低”的情况往往需要人工去翻例子才能发现规律。抛开工具和框架不谈测试评估终究是在回答两个问题感知模块到底能不能用以及它在哪些条件下最好或最差。前一个靠指标后一个靠场景拆分和数据覆盖。指标是结果数据是源头流程是保障。做这一行这么久我最大的体会是测感知模块千万不要指望一套指标走天下也不要迷信某一版离线评测得出的美好数字。每一次评估结论上线之前先问自己一句——如果这个结论是错的最可能错在数据采集、标注质量、指标计算还是评测流程哪一层想清楚了再把它交到决策者手里。这篇先梳理到这里下一篇我会重点写场景库怎么建、仿真回灌怎么和实车数据互补以及自动化评估流水线怎么搭。那句话怎么说来着测试的本事一半在测另一半在怎么让下一次测试更可信。