AEB 误刹漏刹怎么归因

更新于 2026-10-19 故障归因AEB虚警漏检

一、先分清误刹与漏刹两条线

AEB 的问题只有两类：该刹没刹（漏刹）和不该刹却刹了（误刹）。误刹对应感知的虚警，漏刹对应感知的漏检。归因的第一步是把问题归类到这两条线，否则很容易在"提高阈值"和"降低阈值"之间反复横跳——降阈值压了误刹却涨了漏刹，升阈值压了漏刹却涨了误刹，永远收敛不到根因。

二、误刹的常见成因

误刹多来自虚警，可归为四类：静止物误检（前方停车、护栏被当成目标）、金属/井盖/桥墩的强反射、恶劣天气带来的噪声、以及标定漂移导致的投影错位。其中标定漂移最隐蔽，它不会让系统报错，却会让毫米波目标被投影到错误位置，触发本不该触发的制动。所以一出现误刹，先查标定与时间同步，再查模型。

三、漏刹的常见成因

漏刹多来自漏检，成因同样清晰：遮挡导致目标进入视野前已被跟踪丢失、低反射率目标（深色车辆、行人）回波弱、远距目标信噪比不足、极端天气衰减。城市场景里，加塞与鬼探头式的突然出现，对航迹管理的考验比单纯远距更大。漏刹归因要回到"目标在哪一步丢的"——是检测没出框，还是关联没接上，还是跟踪生命周期没续上。

四、用时间同步与标定做第一道排查

排查项	偏差表现	处置
外参标定漂移	目标投影错位、误刹	重新标定、加在线自检
时间同步偏差	目标位置跳动、关联错乱	查 PTP/gPTP、补同步裕度
跨传感器不一致	同目标多框、漏关联	查坐标基准与置信度加权

很多"算法问题"其实是时空基准问题，先稳住基准再谈模型，能省掉大量无效调参。

五、数据回灌是把问题闭环的关键

定位到成因后，要把对应场景的数据回灌，确认修复有效且不引入新的虚警/漏检。这一步决定了问题是不是真被解决，而不是只在出问题的那条路上临时打补丁。回灌要覆盖同类工况的多个样本，避免"过拟合"到单个案例。

六、归因报告的写法

一份能复用的归因报告，至少要有：原始时间戳与同步状态、标定版本、目标轨迹与真值偏差、虚警/漏检判定、成因结论、修复动作与回灌结果。把它沉淀进场景库，下次同类问题就能直接对照，而不是每次从零开始。

结论 1. 误刹归虚警、漏刹归漏检，先定性再调参，避免阈值反复横跳。 2. 第一道排查永远是标定与时间同步，多数"算法问题"是基准问题。 3. 用数据回灌确认修复，并把成因沉淀进场景库形成闭环。

七、快速分流表

现场接到 AEB 投诉，先用一张分流表定位：误刹先看标定与时间同步，再看模型阈值；漏刹先看是检测没出框、关联没接上还是跟踪丢了，再看遮挡与天气。这张表能把绝大多数问题在十分钟内分到正确方向，避免工程师在错误模块里空转。

八、归因与标准的关系

误刹漏刹的归因，本质上是在填 SOTIF 的不安全场景清单。每定位一个成因，就补一条触发条件与验证证据。把每一次归因回流进 SOTIF 流程，系统的残余风险才会越收敛越低，而不是每次出问题都像第一次遇到。

九、把经验沉淀成资产

单次归因的价值有限，真正的资产是归因库的积累：同一成因在不同天气、不同车型下的表现，修复动作与回灌结果。把它结构化存储，下次同类问题直接对照，新工程师也能快速上手。这是团队从"救火"走向"防火"的分水岭。

十、数据留痕是前提

归因能做的第一前提，是系统留了足够的数据：原始传感、目标列表、时间戳、标定版本、触发日志。没留痕，出了事只能靠猜。很多团队事后才发现关键数据没记录，归因直接卡死。留痕要在设计阶段规划，而不是出事后再补，否则永远慢半拍。

十一、把个案变成规则

单次归因解决一个问题，把成因沉淀成规则才能解决一类问题。比如"井盖误检"归因为静止物反射，就沉淀成"低速近距静止物降权"的规则，下次同类自动处理。从个案到规则，是归因能力真正成熟的分水岭，也是团队经验资产化的过程。

十二、归因是为了少出事

回到原点，AEB 误刹漏刹的归因，目的不是追究谁的责任，而是让系统少出事。每一次把虚警漏检归到成因、回流进 SOTIF、闭环到修复，系统的残余风险就降一分。反之，归因只为了甩锅，报告写完就锁进抽屉，同样的问题下次还会来。把归因的产出接到改进上，才是它存在的意义，也是团队安全能力真正成长的路径。

十三、给现场的一句提醒

现场接到 AEB 投诉，先别急着改模型，按分流表从标定与时间同步查起。绝大多数"算法问题"其实是基准问题，调模型只会越调越乱。把数据留痕与归因库建好，现场从救火变防火，团队的安全能力才真正长出来。另外，归因的结果要及时回流进 SOTIF 的不安全场景清单，每定位一个成因就补一条触发条件与验证证据，系统的残余风险才会逐轮下降。

常见问题

AEB 误刹怎么归因

结论 1. 误刹归虚警、漏刹归漏检，先定性再调参，避免阈值反复横跳

融合结果不一致怎么查

2. 第一道排查永远是标定与时间同步，多数"算法问题"是基准问题

漏检目标怎么定位