RK3588 AI 视觉报警为什么总误报 防误报引擎

AI 视觉报警为什么总误报？工业级防误报引擎的三级档位设计

越微智能（Yuewell）工业边缘 AI 工程实践系列 · 第 4 篇
关键词：防误报、三级档位、LIVE 蓄力、CRON 投票、动态面积阈值、置信度解耦

一、客户最痛的问题：报警太灵被骚扰，太钝又漏报

做工业 AI 视觉的团队，几乎都被客户问过同一个问题：

“你们这个报警能不能调一下？现在太灵敏了，一天报几十次，很多都是误报，我们都麻木了。但调迟钝了又怕漏报，真出事了没发现怎么办？”

这是 AI 视觉产品落地中最核心的矛盾之一：

• 灵敏度太高→ 误报多，客户被骚扰到麻木，真正的报警也被忽略
• 灵敏度太低→ 漏报多，客户觉得"装了等于没装"，产品价值无法体现
• 不同场景需求不同→ 工地安全帽检测希望灵敏一点（安全第一），垃圾乱堆检测希望迟钝一点（避免临时堆放误报）
• 同一客户不同时期需求不同→ 刚上线时希望迟钝一点（减少误报建立信任），稳定运行后希望灵敏一点（不放过任何异常）

很多团队的解决方案是：给客户一堆参数——置信度阈值、连续帧数、报警间隔、ROI 区域……让客户自己调。结果呢？客户根本不会调，要么全用默认值，要么调得更乱。

我们在早期项目中就踩过这个坑：一个垃圾转运站项目，客户反馈"垃圾桶满溢检测一天报 20 多次，很多是垃圾车正在倾倒时的临时状态"。我们让客户调"连续判断帧数"，客户调了半天，要么调太大导致真满了也不报，要么调太小还是误报。最后我们上门，花了半天时间才调好。

从那以后，我们意识到：防误报不能让客户调一堆底层参数，必须产品化、傻瓜化。这就是 Yuewell-Debounce 防误报引擎的由来。

二、三级档位设计：一键切换，底层自动映射

2.1 产品化的核心思想

防误报的产品化核心思想是：用户只需要选一个档位，底层自动映射到 5+ 个工程参数。

我们设计了三个档位：

用户在界面上只看到这三个选项，选一个就完事了。底层自动映射到：

• LIVE 模式的蓄力时间 T（秒）
• CRON 模式的投票次数 N/M（N 次中 M 次命中）
• 动态面积阈值（像素）
• 边缘折减系数
• 丢失容错时间（秒）

2.2 为什么是三档，不是五档或十档

我们一开始设计了五档（极灵敏/灵敏/标准/稳健/极稳健），但用户测试发现：

• 五档之间的差异太小，用户选了之后感觉"没区别"
• 档位太多反而增加了选择成本，用户不知道该选哪个
• 三档（灵敏/标准/稳健）的认知成本最低，用户一看就懂

最终我们确定了三档设计，并且把"标准"作为所有新任务的默认值。如果客户有特殊需求，可以通过"高级定制"模式手动调整底层参数，但 90% 的运维人员只需要在三档之间切换。

三、LIVE 模式的防误报：蓄力时间状态机

LIVE（实时检测）模式下，视频流是连续的，防误报的核心机制是蓄力时间 T——目标在 ROI 内持续存在 T 秒才确认报警。

3.1 蓄力时间状态机

目标首次进入 ROI │ ▼ Start_Time = now Last_Seen_Time = now │ ▼ 每帧检测到目标在 ROI 内？ ├── 是 → 更新 Last_Seen_Time = now │ │ │ ▼ │ Last_Seen - Start >= T ? │ ├── 是 → ✅ CONFIRMED（确认报警），重置跟踪器 │ └── 否 → 继续蓄力 │ └── 否 → now - Last_Seen > 1.5s ? ├── 是 → 🔄 TRACKER_RESET（跟踪器重置，Start_Time 清零） └── 否 → 继续等待（短暂漏检不清零）

关键设计点：

1. 蓄力时间 T：目标从首次进入 ROI 到确认报警，需要持续存在 T 秒。T 越大，误报越少，但报警延迟越大。
2. 丢失容错 1.5 秒：目标短暂离开 ROI（比如被遮挡、检测漏检一帧），只要在 1.5 秒内重新出现，蓄力计时不重置。这避免了"因为一帧漏检导致蓄力清零"的问题。
3. 确认后重置：确认报警后，跟踪器重置，下次目标再次进入 ROI 时重新开始蓄力。
4. 推送冷却独立：蓄力时间 T 和报警推送间隔push_interval_sec是两个独立参数。蓄力控制"什么时候确认报警"，推送间隔控制"确认后多久推送一次"，避免重复推送骚扰。

3.2 三级档位的蓄力时间映射

不同算法的蓄力时间不同，三级档位的映射是per-algo × per-mode的：

为什么不同算法的蓄力时间差异这么大？

• 人员入侵、安全帽等安全类算法：目标是移动的，5 秒蓄力足够过滤短暂误检，又不会导致报警延迟太大
• 垃圾桶满溢：垃圾车倾倒时垃圾桶会短暂"满溢"，需要 30 秒蓄力才能过滤这种临时状态
• 非机动车违停：车辆临时停靠上下客很常见，需要 60 秒蓄力才能区分"临时停靠"和"违停"
• 无人值岗：岗位上偶尔没人是正常的（去厕所、喝水），需要 15 分钟蓄力才能判断"真的脱岗"

这些 per-algo 的蓄力时间默认值，是我们在大量现场项目中反复调优后确定的经验值。客户只需要选档位，不需要知道底层的 T 是多少。

四、CRON 模式的防误报：跨周期 N/M 投票

CRON（抽帧巡检）模式下，系统每隔 N 分钟才抽一帧做检测，没有连续的视频流，防误报的核心机制是跨周期 N/M 投票——连续 N 个抽帧周期中，有 M 次命中才确认报警。

4.1 空间锚定 + 跨周期投票

CRON 模式的投票不是简单的"N 次中 M 次命中"，而是空间锚定 + 跨周期投票：

周期 1：抽帧 → 检测到目标在 ROI 内 → 记录目标位置（anchor）→ streak = 1/3 周期 2：抽帧 → 检测到目标 → 与上一周期的 anchor 做 IoU 匹配 ├── 同一目标（IoU > 0.3）→ streak = 2/3 └── 不同目标 → 新建 anchor，streak = 1/3 周期 3：抽帧 → 检测到目标 → 与 anchor 匹配 ├── 同一目标 → streak = 3/3 → ✅ CONFIRMED（确认报警） └── 不同目标 → streak = 1/3 周期 X：抽帧 → 未检测到目标 → 🔄 RESET（streak 清零，anchor 清除）

关键设计点：

1. 空间锚定（anchor）：每个周期检测到的目标，通过 IoU（交并比）与上一周期的目标位置匹配。只有同一个目标在连续周期内持续存在，才累加 streak。不同位置的误检不会累加成确认。
2. N/M 投票：N 是窗口大小（最多看几个周期），M 是命中阈值（需要命中几次）。三级档位映射为 1/1（灵敏）、3/2（标准）、5/3（稳健）。
3. 中途漏检重置：如果某个周期没有检测到目标，streak 清零，需要重新开始累计。
4. anchor 融合阈值：如果目标离开后在 2 个周期内新位置出现，且与旧 anchor 邻近，会做 ANCHOR_FUSE（锚点融合），避免目标小范围移动导致 streak 重置。

4.2 三级档位的 N/M 映射

anchor_iou_min = 0.30和anchor_fuse_threshold = 2三档保持不变，这些是工程微调参数，不暴露给用户。

五、动态面积阈值：小目标蹭线不算

除了时间维度的防误报（蓄力/投票），还有空间维度的防误报：动态面积阈值。

5.1 为什么需要面积阈值

AI 模型的检测框有时候会出现"小目标误检"——比如远处的一个影子、一个杂物，被模型误检成了目标。这些误检的共同特征是：检测框面积很小。

面积阈值的核心思想是：检测框面积小于阈值的，认为是误检，直接过滤掉。

5.2 三级档位的面积阈值映射

不同算法的标准档面积阈值不同：

• 人员入侵：8000 像素
• 安全帽检测：6000 像素
• 抽烟检测：1500 像素（烟头本身很小）
• 烟火检测：3000 像素
• 未戴口罩：5000 像素

5.3 边缘折减机制

ROI 区域的边缘是误检高发区——检测框只有一小部分在 ROI 内，大部分在外面。这种情况通常是"蹭线"，不是真正的目标进入 ROI。

边缘折减机制：

• 检测框与 ROI 的重叠面积占比 < 60% → 认为是蹭线，不报警
• 检测框中心或足部锚点在 ROI 外 → 不报警
• 边缘折减系数 0.70：边缘条带内的检测框，面积阈值乘以 0.70（更严格）

三级档位只调整面积阈值的缩放比例，边缘折减开关和系数保持不变（工程微调参数）。

六、置信度与防误报等级解耦

一个常见的设计误区是：把"置信度阈值"和"防误报等级"混为一谈。

6.1 为什么要解耦

置信度（sensitivity）：模型输出的检测框置信度，控制"模型认为这是目标的概率"。置信度阈值越高，过滤掉的低置信度检测框越多。

防误报等级（debounce_level）：时间/空间维度的防抖机制，控制"目标持续存在多久/多大才算确认"。

这两个维度是正交的：

• 置信度高但持续时间短 → 可能是误检（模型很自信但只出现一帧）
• 置信度低但持续时间长 → 可能是真实目标（模型不太自信但持续存在）

如果把两者混为一谈，用户调"防误报等级"时，置信度也跟着变，会导致不可预期的行为。

6.2 我们的解耦设计

用户切换防误报等级时，只有时间/空间维度的防抖参数自动映射，置信度、推送间隔、分析节拍等参数保持不变。用户可以独立调整置信度，不会触发防误报等级的变更。

这个解耦设计让用户的操作可预期：调防误报等级就是调"多久/多大才算确认"，调置信度就是调"模型多自信才算目标"，两者互不干扰。

七、UI/UX 设计：90% 运维只调基础参数

7.1 固定控件集设计

算法任务参数界面采用固定控件集设计，所有算法的界面布局一致，只改单位和校验范围：

A. 分析模式 CRON | LIVE（单选） B. 基础参数 ├── 启用开关 ├── 分析节拍（CRON: 分钟/帧，LIVE: 帧/秒） ├── 置信度（0-100%） ├── 防误报等级（灵敏 | 标准 | 稳健，单选） ├── 工作时间（时间段选择） └── 上报间隔（分钟，0=不冷却） C. 特殊参数 仅部分算法显示（如叉车越线方向） D. 开启高级定制 默认关，打开后暴露 N/M 等工程项

7.2 工程项不进界面

以下参数永远不进基础界面，只有"开启高级定制"后才暴露（且仅暴露部分）：

• anchor_iou_min（空间锚定 IoU 阈值）
• loss_tolerance_ms（丢失容错时间）
• active_ratio（时间槽活跃比例）
• cron_edge_area_relief_*（边缘折减参数）
• min_box_area_ratio（最小框面积比）
• deep_tune内的所有工程注入参数

这些参数沉入schedule_json.deep_tune，由工程人员在需要时手动注入，普通运维人员永远看不到。

设计哲学：90% 的运维人员只需要调基础参数（模式、节拍、置信度、防误报等级、工作时间、上报间隔），就能满足 90% 的场景需求。工程项是为剩下 10% 的特殊场景准备的，不应该让普通运维人员看到，避免越调越乱。

八、特殊算法的差异化防误报

不是所有算法都能套用通用的防误报机制。一些特殊算法有自己的差异化设计：

这些特殊算法的防误报参数，同样映射到三级档位，但映射规则和通用算法不同。用户不需要知道这些差异，只需要选档位即可。

十、写在最后

AI 视觉报警的防误报，本质上是在回答一个问题：“什么样的异常才是真正需要关注的异常？”

这个问题没有标准答案——不同场景、不同客户、不同时期的答案都不一样。但产品化的关键是：把复杂的工程参数藏在底层，给用户一个简单、可预期、可操作的界面。

如果你也在做 AI 视觉产品的防误报产品化，欢迎交流。

关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。