检出率漏检虚警怎么验收

一、五个核心指标分别量什么

动态目标验收通常看五个量：检出率（该有的目标有没有被找到）、漏检（该找没找到的比例）、虚警（不该有的目标被报出来的比例）、测距测速精度（报出来的距离速度和真值差多少）、端到端延迟（从感知输入到决策输出用了多久）。前三个是"有没有"的问题，后两个是"准不准、快不快"的问题，五者共同构成感知能力的验收骨架。

二、检出率与漏检是一体两面

检出率等于一减漏检率，但工程上要分开看，因为两者的代价不同。漏检一个行人可能直接进 SOTIF 的高风险清单，而降低漏检往往要以牺牲一部分虚警为代价。验收时不能只看检出率一个漂亮数字，要连同漏检的工况分布一起看：远距、小目标、遮挡、恶劣天气下的漏检才是真正要盯的。

三、虚警要按成因归类

虚警不是"多报了"四个字能概括的，要拆成静止物误检、金属/井盖反射、天气噪声、标定漂移四类去统计。同一个虚警率，成因分布不同，处置路径完全不同。把虚警按成因归类，才能决定是改模型、改标定还是改触发阈值，而不是笼统地调一个置信度门槛。

四、测距测速精度怎么测

精度要真值对照，常用 RTK/IMU 组合或标定好的龙门架真值系统。测的时候要覆盖不同距离、不同相对速度，因为毫米波在远距回波弱时精度会掉、在近距离又会受分辨率限制。报告里写"精度 0.2m"必须附上距离区间，否则这个数字没有意义。

五、端到端延迟怎么量才可信

延迟不是单模块耗时相加，而是一条流水线：采集、同步、推理、关联、跟踪、决策。量延迟要在整链路上打点，而不是只测推理耗时。更关键的是抖动——一个平均 80ms 但偶尔跳到 200ms 的系统，比稳定 100ms 的系统更危险。稳定性与时延同等重要。

六、数据集与阈值决定了结果

同样一套算法，用不同数据集、不同判定阈值，出来的指标可以差很远。验收前要先固定：判定框交并比阈值、时间容忍窗口、天气与场景分布。没有统一口径的"检出率 99%"是不可比的，这也是跨方案对比时最容易踩的坑。

结论 1. 五项指标要同口径验收，单看均值会掩盖远距、遮挡、恶劣天气下的短板。 2. 漏检按风险、虚警按成因分别统计，才能决定改模型还是改标定。 3. 延迟看重稳定可预测，精度必须附距离区间才有意义。

七、验收报告怎么写才可信

一份可信的验收报告，至少要有：指标口径（交并比阈值、时间窗口）、场景与天气分布、距离区间、稳定性数据。只给均值不带分布，等于把远距与恶劣天气的短板藏起来。报告还要附上判定样例，让读报告的人能复现"为什么算检出、为什么算虚警"，否则数字无法被审计。

八、跨方案对比的陷阱

对比两家方案时，最容易被同口径缺失坑到：A 用宽松阈值，B 用严格阈值，出来的检出率差几个点其实没意义。正确的做法是固定同一数据集、同一判定口径再比。把对比做成"谁在您的场景里更稳"，而不是"谁的演示更漂亮"。

九、把验收变成回归

验收不该是一次性的，而要沉淀成可回归的场景库。每次模型改动后自动跑一遍，确认虚警漏检没有回弹。把"验收通过"变成"持续通过"，是量产守住底线的关键。临时达标很容易，难的是在后续几十次迭代里都达标。

十、真值从哪来

精度与延迟的验收离不开真值。RTK/IMU 组合、标定龙门架、或高精地图对齐，是真值的主要来源。真值方案本身也有误差，必须附上真值不确定度，否则用有误差的真值去验收，结论同样是可疑的。真值质量决定验收质量，这一环省不得。

十一、天气与时段不能省

很多方案只在晴天白天验收，一到雨夜就露馅。验收要覆盖雨天、夜间、逆光、团雾等档位，因为这些恰恰是虚警漏检高发的区间。把天气与时段写进验收矩阵，才是对用户负责的验收，而不是实验室里的漂亮数字，更不是自欺欺人的单点达标。

十二、验收是手段不是目的

最后要提醒，验收指标服务于安全，不是用来在 PPT 上比大小的。一份漂亮的检出率，如果没有真值、没有分布、没有天气覆盖，对用户毫无意义。真正负责任的验收，是把边界讲清楚：在哪些距离、哪些天气、哪些场景下指标会下降，以及下降多少。把边界摆出来，比堆高均值更诚实，也更经得起审计与事故复盘。验收的尽头是信任，而不是数字。

相关阅读

• AEB 误刹漏刹怎么归因 — 把虚警漏检落到成因
• 误报漏报分析能力 — 成因归类与闭环优化工具