误报漏报分析能力

一、产品概述

误报漏报分析能力，把融合与功能逻辑暴露出来的虚警、漏检与误关联，从"多报了/漏报了"四个字，拆解成可定位、可处置、可闭环的问题。它按成因对虚警（静止物、反射、天气、标定漂移）和漏检（遮挡、低反射、远距、极端天气）分类，并提供数据回灌与场景级报表，让每一次修复都可验证、可回归。

这一能力的价值不在"统计一个率"，而在把率背后的成因摆出来：同样是 2% 的虚警，成因是井盖反射还是标定漂移，处置路径完全不同。不拆成因就调阈值，只会让误刹漏刹反复横跳，永远收敛不到根因。

二、应用场景

• AEB 误刹漏刹归因：把误刹归虚警、漏刹归漏检，结合标定与时间同步定位，给出可复现的闭环路径。
• 感知指标验收：按场景、天气、距离分布看检出率、漏检、虚警与延迟，而不是只看一个均值。
• 模型迭代回归：每次模型改动后自动回灌场景库，确认没有引入新的虚警或漏检。

三、选型建议

分析能力要先明确您的评价指标口径：判定框交并比阈值、时间容忍窗口、天气与场景分布，三者不固定，出来的指标不可比。建议优先选择支持分成因分类与数据回灌的方案，而非只出一份总表。案例库规模要按您的真实项目积累，不要轻信通用库能覆盖您的全部工况。

四、服务流程与配合事项

第一步是评价指标对齐：和您一起固定验收口径，明确哪些场景算误报、哪些算漏检。第二步是数据接入：把真实与仿真数据接入分析能力，按成因打标。第三步是归因与报表：产出场景级与系统级报表，定位虚警漏检的成因分布。第四步是闭环：把问题回到模型或标定迭代，再回灌验证，形成"问题—修复—回归"的闭环。

我们会交付归因报告与闭环记录，明确在您工况下虚警漏检的成因分布与可验收区间。需要提醒的是，分析只是手段，真正的收敛要靠上游标定、同步与关联质量的同步改善——分析能力能指出问题在哪，但补漏洞的动作要落到整链路。

五、与整链路的闭环

误报漏报分析不是孤立的统计工具，而是整链路的闭环抓手。它指出的成因，要回流到标定、同步、关联或模型去修，修完再回灌验证。没有这步闭环，分析只是出份报告；有了闭环，虚警漏检才会逐轮收敛，这也是 SOTIF 残余风险下降的路径，让每一次修复都可被验证。

六、集成中的常见坑

坑一是只出总表不分成因，调阈值时误刹漏刹反复横跳；坑二是指标口径不固定，不同版本不可比；坑三是案例库用通用库充数，覆盖不了您的工况。分析能力要能分成因、能回灌、能回归，才真正帮系统收敛，而不是只增加一个报表环节、拖延交付节奏。

七、性能的可验收区间

分析能力交付要给出在您工况下虚警漏检的成因分布与可验收区间，而不是一份总表。我们强调分成因、分场景，并附上报表样例。只有把分布摆出来，您才能判断问题有没有被真正收敛，而不是看一个好看的总率，被均值掩盖了高风险工况。

八、后续维护的说明

分析能力要随场景库一起维护，案例库需要持续积累。我们交付时会说明数据接入、打标与回归的方式，确保每次模型迭代都能快速跑闭环。把维护路径讲清，分析才不会变成一次性报表，而是持续帮系统收敛，成为长期资产。

九、分析要回到改进

误报漏报分析的价值，不在于出一份好看的报表，而在于回到改进。每一次分析指出的成因，要能回流到标定、同步、关联或模型去修，修完再回灌验证，形成闭环。我们建议在交付时把分析能力接入您的数据流水线，做到"问题—修复—回归"自动跑，而不是人工单次处理。此外，案例库要持续积累，覆盖您真实工况而非通用库。我们交付时会说明数据接入、打标与回归方式，确保分析成为长期资产。分析若是孤岛，就只是增加报表环节；分析若接回改进，才是系统持续收敛、SOTIF 残余风险下降的真正路径。

十、给数据团队的一句提醒

分析能力要接回您的数据流水线，而不是做成一次性报表。把"问题—修复—回归"跑成自动闭环，案例库随真实工况积累，分析才会越用越强。孤岛式的分析只是增加一个报表环节，接回改进的闭环才是系统持续收敛、SOTIF 残余风险下降的真正路径。我们建议在接入时就把数据格式、打标规范、回灌接口约定清楚，分析能力的 ROI 不在它多能出图，而在它帮您把虚警漏检逐轮压低。

十一、写在最后

误报漏报分析不是项目的终点，而是持续收敛的起点。把成因回流、把案例积累、把闭环跑通，系统的虚警漏检才会逐轮下降，安全冗余才真正长出来。很多团队把分析当成上线前的例行报表，做完就锁进抽屉，结果同样的问题反复来。把它当成长期资产运营，每次迭代都跑一遍闭环，才是 SOTIF 残余风险下降的正路。

相关产品

• AEB/ACC/BSD 功能逻辑参考 — 误刹漏刹的直接关联方
• 检出率漏检虚警怎么验收 — 把指标落成口径
• 目标关联参考引擎 — 误关联的成因之一