2、基础概念：告警、事件、规则引擎、去重和消息推送的定义与区别，以及它们在视频AI系统中的角色
在视频AI告警系统的设计与实现中，告警、事件、规则引擎、去重和消息推送这五个核心概念构成了系统的骨架。它们之间既有严格的职责边界，又存在紧密的上下游协作关系。理解这些概念的本质区别与交互方式，是构建一个稳定、高效、不扰民的视频AI系统的前提。本章将从定义、角色、协作流程以及工程实践中的常见误区四个维度，对这五个基础概念进行深度拆解。
上图展示了视频AI告警系统中五个核心概念的协作关系。从数据源到事件生成，再到规则引擎的过滤与决策，最终形成告警并经过去重后推送，每个环节都有明确的输入与输出。下面我们将逐一深入剖析每个概念的定义、角色定位以及它们之间的边界。
2.1 事件（Event）：AI推理的原始输出
核心原理：事件是视频AI系统中最底层的原子信号，它表示“在某个时间点、某个摄像头画面中，AI模型检测到了什么”。事件本身不具备业务决策能力，它只是对物理世界现象的数字映射。例如，一个行人检测模型在帧率为25fps的视频流中，连续30帧检测到同一区域有行人，这30帧的检测结果可以聚合为一个“行人出现”事件。
事件通常包含以下关键属性：
- 时间戳：事件发生的精确时间（毫秒级），用于后续的时间窗口去重和时序分析。
- 摄像头ID：标识事件来源，用于空间维度的去重和定位。
- 目标类型：如行人、车辆、火焰、烟雾等，由模型分类头输出。
- 置信度：模型对该检测结果的置信概率（0~1），通常低于阈值的检测会被丢弃。
- 目标框坐标：目标在画面中的位置（x, y, w, h），用于空间重叠去重。
- 附加属性：如目标速度、方向、颜色特征等，由跟踪模块或属性识别模块补充。
判断方法：在实际工程中，事件通常由推理服务（如TensorRT、OpenVINO加速的模型）产生，并写入消息队列（如Kafka、RabbitMQ）或直接调用SDK回调。事件是“事实”，无论后续是否触发告警，事件都应该被记录和存储，用于回溯分析、模型迭代和审计。
2.2 告警（Alert）：经过业务规则裁决的待办事项
核心原理：告警是事件经过规则引擎裁决后，被判定为“需要用户关注”的输出结果。告警与事件的核心区别在于：事件是客观的，告警是主观的。同一个“人员闯入”事件，在白天上班时间可能不产生告警，但在夜间布防时段则会产生高优先级告警。这种决策逻辑由规则引擎承载。
告警的典型结构包括：
- 告警ID：全局唯一标识，用于后续的确认、处理、归档。
- 关联事件ID列表：记录该告警由哪些事件触发，便于追溯。
- 告警级别：如提示（Info）、警告（Warning）、严重（Critical），不同级别对应不同的推送策略。
- 告警标题与描述：人类可读的摘要信息，如“东门区域发现人员徘徊超过5分钟”。
- 快照或短视频片段：从事件发生时的视频流中截取的证据，用于人工复核。
- 状态：待处理、处理中、已确认、已忽略、已关闭。
操作流程：告警的生命周期管理是运营的核心。一个成熟的系统应支持告警的确认（Acknowledge）、升级（Escalate）、关闭（Close）和备注（Comment）。例如，当值班人员确认某条告警并前往现场处置后，应将该告警标记为“处理中”，处置完成后关闭并填写处理结果。
2.3 规则引擎（Rule Engine）：业务逻辑的决策中枢
核心原理：规则引擎是一个将“业务判断逻辑”从代码中解耦出来的组件。它允许运维人员或业务专家通过可视化界面或配置文件，动态定义“什么情况下产生告警、产生什么级别的告警”，而无需修改底层代码。规则引擎的输入是事件流，输出是告警决策。
规则引擎的核心能力包括：
| 规则类型 | 说明 | 示例 |
|---|---|---|
| 阈值规则 | 当事件属性超过或低于设定值时触发 | 区域人数超过50人触发拥挤告警 |
| 时间窗口规则 | 在指定时间范围内的事件才有效 | 仅夜间22:00-06:00的闯入事件触发告警 |
| 频次规则 | 单位时间内事件发生次数达到阈值 | 1分钟内同一区域出现5次跌倒事件 |
| 组合规则 | 多个事件同时或按顺序发生 | 先检测到烟雾事件，随后检测到火焰事件 |
| 状态规则 | 基于设备状态或系统状态的条件 | 摄像头离线恢复后，需等待10秒再启用告警 |
判断方法：规则引擎的设计应遵循“先粗后细”的原则。初期可以只配置基础阈值规则，运行一段时间后根据误报/漏报数据逐步添加时间窗口、频次等复合规则。规则引擎的决策结果应记录日志，包括命中的规则ID、输入事件、输出告警，以便审计和调优。
2.4 去重（Deduplication）：告警质量的守门员
核心原理：去重是解决“同一事件被重复告警”问题的关键机制。在视频AI场景中，由于视频流是连续的，AI模型在相邻帧中可能反复检测到同一目标，如果不做去重，系统会在几秒内推送几十条内容几乎相同的告警。去重模块的目标是：在保证不漏报的前提下，将重复告警合并为一条，并附带事件发生的时间范围。
去重策略通常分为三个维度：
- 时间窗口去重：设定一个时间窗口（如30秒），如果同一摄像头、同一目标类型、同一目标ID（通过跟踪算法获得）的新事件落在窗口内，则不再生成新告警，而是更新原告警的“最后发生时间”。
- 空间重叠去重：当两个事件的目标框IoU（交并比）超过阈值（如0.7），且发生时间接近，则视为同一目标。此方法适用于没有目标ID跟踪的场景。
- 特征相似度去重：提取目标的外观特征（如颜色直方图、ReID特征），计算余弦相似度，超过阈值则判定为同一目标。此方法最准确但计算开销较大。
操作流程：去重模块通常位于规则引擎之后、消息推送之前。当规则引擎判定某事件需要生成告警时，先去去重缓存中查询是否存在“相似告警”。如果存在，则更新原告警的计数和最后时间；如果不存在，则创建新告警并进入推送队列。
2.5 消息推送（Notification）：告警触达的最后一公里
核心原理：消息推送是将告警信息通过多种渠道送达目标用户的执行组件。推送不仅仅是“发一条消息”，它需要解决以下问题：
- 渠道适配：不同用户可能偏好不同的接收方式，如运维人员使用企业微信，管理层使用邮件，紧急情况使用短信或电话。
- 分级推送策略：严重告警立即通过短信+电话推送，普通告警通过应用内通知或邮件汇总推送。
- 失败重试与回执：推送失败（如网络超时、手机离线）时需要重试机制，并记录推送回执状态。
- 内容模板：告警内容需要包含关键信息：时间、地点、事件类型、现场截图或短视频链接、处理建议。
判断方法：推送模块应支持“订阅-发布”模式。用户或用户组可以订阅特定摄像头、特定告警级别的通知。例如，安保主管订阅所有严重告警，而车间主任只订阅自己管辖区域的告警。推送服务应具备独立的队列，避免因推送通道阻塞而影响告警生成速度。
2.6 常见误区与总结复盘
在多个项目的实施过程中，以下误区最为常见：
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 将事件和告警混为一谈 | 系统推送大量原始事件，用户无法聚焦关键问题 | 明确事件是原始记录，告警是决策输出，中间必须有规则引擎 |
| 规则引擎过度复杂 | 规则之间互相冲突，难以排查问题 | 规则保持简单，优先使用阈值+时间窗口，定期审查规则命中率 |
| 忽略去重或去重参数不合理 | 告警风暴导致用户关闭通知 | 上线前用历史数据回放测试去重效果，调整窗口和IoU阈值 |
| 推送渠道单一 | 关键告警无法及时触达 | 按级别配置多渠道，并设置失败重试和升级机制 |
总结复盘：视频AI告警系统的设计本质上是“信息降噪”的过程。原始视频流是海量的，事件是对视频流的初步抽象，告警是对事件的业务化筛选，去重是对告警的质量控制，推送则是将最终决策高效传达。一个健康的系统，其事件量、告警量、推送量应呈明显的金字塔结构。如果某一层出现异常膨胀，应优先检查上一层的配置是否合理。例如，如果告警量突然激增，应先检查规则引擎的阈值是否被意外修改，再检查去重窗口是否失效，最后检查AI模型是否出现漂移导致误检率上升。通过这种分层排查的思路，可以快速定位并解决问题，确保系统长期稳定运行。