企业官网建设流程全解析

1. 项目概述：烟火识别为什么难，又为什么必须做

先聊点实际的。之前在某地的森林防火监控项目里，我们遇到过这样一个情况：监控屏幕上某片林区画面的远端冒出一小缕烟，值守人员盯着几十路分屏看了十分钟也没发现，等肉眼注意到的时候，火势已经起来了。这种场景，做安防和消防相关系统的人应该都不陌生。视频监控烟火识别技术，就是把“人眼盯屏”这件事交给算法来做，让摄像头自己发现画面里的火焰和烟雾，在火情初期就报警。

这个项目的核心并不是“给摄像头加个AI盒子”这么简单。烟火识别是一个典型的“小目标+动态场景+极端误报率要求”的视觉任务。火焰和烟雾在画面里往往只占几十个像素，背景又是不断变化的树林、天空、建筑物，光照条件从正午强光到夜间漆黑都有。要在这种条件下做到“少漏报、少误报、报警快”，需要从图像采集、算法选型、硬件部署到报警策略全链路一起设计。

这篇文章想写给三类人看：一是正在做安防监控系统集成、需要给平台加烟火识别能力的工程师；二是刚接触视觉算法、想找一个入门级落地项目练手的学生或开发者；三是负责园区、仓库、林场等场景安全管理，想搞清楚“这玩意儿到底靠谱不靠谱”的需求方。

我会把整个项目从算法原理讲到实际部署，包括踩过的坑、误报的排查过程、以及一些常规文档里不会写清楚的细节。不管你是准备自己训练模型，还是打算买现成的盒子，这篇文章都能让你对“烟火识别到底是怎么实现的、哪些环节容易翻车”有一个完整的认识。

2. 核心技术拆解：火焰和烟雾在画面里到底是什么样的

想做好烟火识别，第一步不是选模型，而是搞清楚“烟火”在图像传感器里到底长什么样。很多项目做不好，根子在于把烟火识别当成通用目标检测来做，结果模型训练出来了，车灯、晚霞、红色广告牌全给你报火警。

2.1 火焰的视觉特征：颜色、形态、闪烁频率

火焰在可见光画面里有几个非常稳定的特征：

• 颜色上，火焰核心区域通常是白色到亮黄色，外围是橙红色到红色。在HSV色彩空间里，火焰像素的色相（Hue）集中在一定区间，饱和度（Saturation）中等偏低，亮度（Value）偏高。这个特征在白天和夜间都相对稳定。
• 形态上，火焰是“抖动”的。它的边缘轮廓会持续变化，而且变化频率有一定规律。实际测试中，正常燃烧的火焰闪烁频率大多在几赫兹到十几赫兹的范围内，这和风吹树叶、灯光闪烁有明显区别。
• 空间位置上，火焰通常从下往上蔓延，会有一个“生长-蔓延-稳定”的过程。这和瞬间闪过的车灯、反光完全不同。

所以，传统算法做火焰识别的思路就是：先做颜色分割提取候选区域，再分析候选区域的形状变化和闪烁频率，用这些时序特征过滤掉静态红色物体。

2.2 烟雾的视觉特征：纹理模糊化、边缘扩散、颜色灰白

烟雾识别比火焰识别更难。难在三点：烟雾没有固定形状和颜色，早期烟雾很稀薄、半透明，和雾气、水蒸气、扬尘在视觉上几乎无法区分。

但烟雾也有一些可用的特征：

• 烟雾出现时，会降低背景图像的清晰度。原本清晰的树叶纹理、建筑边缘会变得模糊，专业说法叫“纹理能量下降”。这是烟雾识别最重要的线索之一。
• 烟雾颜色通常偏灰白、灰蓝，在灰度图上呈现为一块亮度变化比较平滑的区域。它的边缘是渐变的，不像火焰那样有锐利边界。
• 烟雾有运动趋势。受热气流影响，烟雾会持续向上或向侧上方扩散，形态上呈现“从一个小源点逐渐膨胀”的过程。

有些方案会引入一个经典判据：烟雾的扩散速度。不同材质的燃烧烟雾扩散速度差异很大，但相比同一画面里的云影移动、车辆行人运动，烟雾扩散在方向和速度上有统计规律。不过这条判据对算法设计要求很高，基层项目通常不会只用它。

2.3 为什么单一算法扛不住：场景复杂度的真实情况

现实场景的复杂度远超实验室测试集。我见过最离谱的误报案例：某化工厂项目接入后，白天下午西晒时厂房玻璃的反光被识别成火焰，连续报了一周的警。排查到最后发现，玻璃反光在画面里的HSV特征和火焰确实高度接近，而且反光区域随着太阳移动也在“缓慢变化”。

这就是为什么现在做烟火识别，基本都不再依赖单一算法了。主流方案是“多特征融合 + 时序判定 + 场景自适应”，也就是把颜色特征、纹理特征、运动特征、形状变化特征综合起来，再结合连续多帧的判定结果做决策，单一特征触发时不报警，多个特征互相印证才输出报警。

3. 方案选型分析：传统图像处理和深度学习怎么选

谈到烟火识别的实现路径，现在行业内基本是两条线并行：传统计算机视觉方法和基于深度学习的检测方法。二者不是简单的替代关系，更多是互补。

3.1 传统方法：颜色阈值、背景建模、光流法的适用范围

传统方法的优点很突出：计算量小，不需要GPU，一台普通工控机就能跑几十路视频流；可解释性强，每条报警都能说清楚是“颜色触发”还是“运动触发”；部署简单，不需要训练数据。

但缺点同样明显：适应性差。颜色阈值参数在晴天效果好，阴天就可能失灵；背景建模在摄像头轻微晃动时容易把整个画面都判断为“前景”，产生大量无效计算。

我经历过的某个早期项目，用的是“混合高斯背景建模 + 颜色阈值”方案，晴天林区效果尚可，一到傍晚光线变暗，整个画面的颜色分布全变了，报警准确率急剧下降。后来实在没办法，只能在傍晚切换另一套夜间参数，阈值靠人工标定，折腾了很久。

传统方法适合的场景：场景相对固定、环境光变化不大、对误报容忍度较高的室内仓库或厂房；算力受限的老旧监控系统升级；以及作为深度学习方法的前置过滤——先用传统算法快速排除掉90%以上明显无烟的帧，减少深度学习模块的调用次数。

3.2 深度学习方案：目标检测与图像分类的搭配打法

深度学习方案是目前烟火识别的主力，基本思路有两个：

• 目标检测：直接用检测模型框出火焰和烟雾的位置。常用模型包括YOLO系列、SSD、Faster R-CNN等。优势是能给出烟火的具体位置，便于联动球机进行确认或跟踪。
• 图像分类 + 滑动窗口：把画面切块送入分类模型判断“有烟/无烟”“有火/无火”。适合算力紧张、不需要精确定位的场景。

实际落地中，我推荐把两者结合：前端用检测模型做粗定位，后端用分类模型对检测框内的区域做精细判断。这样既能避免检测模型对“长得像烟”的区域盲目输出框，又能通过分类模型提高准确率。

3.3 针对烟火场景的模型选型建议

针对烟火识别这个具体任务，模型选型有几个特殊考量：

• 算力约束：消防救援场景通常不允许延迟超过几秒，而监控点数往往成百上千。因此像YOLOv7这类高精度但计算量大的模型，除非专配GPU服务器，否则很难支撑大规模并发。
• 小目标检测能力：早期烟雾在画面中往往很小。模型的输入分辨率和感受野设计需要特别关注，单纯加大输入尺寸会显著增加算力开销，需要在两者间平衡。
• 误报率控制：烟火识别属于“宁可错报不可漏报”的场景，但错报过多会导致值守人员疲于应对，最终对报警产生麻痹。因此模型输出需要带置信度阈值，还要配合后端的时序逻辑做综合判断。

我个人的落地经验：在Jetson Orin系列边缘设备或入门级GPU服务器上，YOLOv5s和YOLOv8n是性价比比较高的选择。它们在1080P画面、抽帧5FPS的条件下，单路推理耗时可以控制在20毫秒以内，精度也能够满足早期烟火检测的需求。

4. 模型训练实战：数据、标注、训练技巧一整套

选好方案和模型之后，真正的挑战在于训练数据和质量控制。烟火识别模型的训练，坑主要集中在“数据不平衡”和“标注不一致”上。

4.1 数据集构建：公开数据集、自采集、数据增强的配比

训练一个可用的烟火识别模型，需要的数据大致分三类：火焰样本、烟雾样本、负样本（干扰物）。

公开数据集方面，有几个在行业内用得比较多的烟火数据集，包含室内外火焰、森林火灾烟雾、工业场景烟雾等。但公开数据的问题在于场景单一、分辨率偏低，直接拿来训练，在真实监控画面上效果会比较差。

自采集数据是提升模型效果的关键。可以自己搭建一个小型燃烧实验场——用铁桶点燃木材、纸张、布料，用监控摄像头从不同角度、不同距离采集视频，再截帧标注。烟雾方面可以用烟饼或加湿器配合光源模拟。自采集数据的价值在于它和你实际部署场景的机位高度、视角、背景环境最接近。

数据增强在烟火任务里比其他任务更重要，也更有讲究。常规的翻转、缩放、色彩抖动肯定要做，但针对烟火场景，我还推荐两种增强：

• 小目标复制粘贴：把真实烟火小目标区域从图像中抠出来，随机粘贴到其他背景图上，并做缩放、旋转、亮度调整。这能有效缓解小目标样本不足的问题。
• 时序帧混合：把不同烟火视频的帧混合拼接，模拟多源烟火同时出现的场景。这在工厂、仓库这类多点位风险场景中特别有用。

4.2 标注规范：烟火标注不是“框住就行了”

标注是整个流程中最容易被忽视的环节。烟火标注有几个关键细节：

• 半透明烟雾的边界是模糊的，不同的标注人员框选范围差异很大。必须制定统一标准：例如烟雾标注范围为“可见烟雾核心区域”，不含边缘淡薄区域；火焰标注范围为“外焰轮廓”，不含内部暗区。
• 负样本要有足够覆盖。车灯、路灯、红色建筑、装修围挡、蒸汽、雾霾，尽量都标注为背景，否则模型训练时会把这些干扰物的特征当成“非烟火”，一旦实际场景出现类似物体，误报会非常高。
• 建议至少两人交叉检查标注结果，特别是对边界模糊的早期烟雾，标注不一致会直接拉低模型收敛效果。

4.3 训练参数：我的常用配置和调参心得

以YOLOv5s为例，说一下我常用的训练配置，供参考：

调参经验有三条：

第一，预训练权重一定要用COCO预训练的，不要从头训练。烟火特征虽然特殊，但底层纹理、边缘、颜色特征和COCO数据集中部分类别是共享的，迁移学习能显著加速收敛。

第二，关注“误报率变化曲线”。很多人只看mAP，但烟火识别项目里更重要的是假阳性率。我在训练过程中会定期用一段固定的误报测试视频跑一遍，统计每小时误报次数，以此判断模型是否过拟合到了训练集的色彩分布上。

第三，训练后期建议冻结Backbone，只微调Head。烟火检测中，Backbone提取的低级特征（边缘、颜色、纹理）已经足够，微调太高反而容易过拟合到特定燃烧场景的细节上。

5. 系统架构设计：视频接入、抽帧策略、报警联动全链路

模型训练好只是第一步。一个真正可用的视频监控烟火识别系统，要考虑视频怎么进来、算法怎么跑、报警怎么出去，以及如何保证7x24小时稳定运行。

5.1 视频流接入与解码：RTSP、GB/T 28181、厂商SDK怎么选

烟火识别系统的前端是监控摄像头，视频流的接入方式基本三种：

• RTSP（实时流传输协议）：最通用。海康、大华、宇视等主流厂商的IPC都支持RTSP拉流，格式如rtsp://admin:password@ip:554/Streaming/Channels/1。优点是标准化程度高，代码里用FFmpeg或GStreamer就能拉流解码，缺点是部分厂商的RTSP实现有兼容差异，需要逐个适配。
• GB/T 28181国标协议：公安、消防等政府项目普遍要求支持国标接入。国标的好处是设备注册、目录查询、实时流点播、云台控制全流程标准化，但实现复杂度高，需要处理SIP信令和媒体流协商，一般建议直接用成熟的国标网关组件，不要从零自己写。
• 厂商SDK：海康的NET SDK、大华的Davinci SDK等。走SDK的好处是能拿到更多设备能力，比如报警、参数调节、私有协议；坏处是各厂商SDK风格差异大，代码耦合严重，不利于后期更换设备品牌。

我的建议是：对外统一收口到RTSP或GB/T 28181，用FFmpeg统一做解码模块。这样无论前端是什么品牌的摄像头，后端算法平台面对的始终是标准视频流，前端的差异被隔离在接入层。

5.2 抽帧策略：烟火识别是慢过程，全帧率跑是浪费

烟火识别的目标事件发展速度相对慢——早期烟雾从出现到明显可见，通常有几十秒到几分钟的窗口期。因此，没有必要像人体检测那样全帧率分析。

实战中，我常用的抽帧策略是：每路视频流每秒分析1~5帧。具体取值取决于三个因素：

• 早期烟雾的扩散速度。风速大、火势发展快时，需要更高的抽帧率。
• 边缘设备算力。在Jetson设备上，我通常设定为每路每秒2帧，这在一定程度上兼顾了实时性和算力开销。
• 报警响应时间要求。延迟从“秒级”放宽到“10秒级”，处理的路数可以大幅增加。

以每路1080P、每秒2帧、YOLOv5s推理单帧20ms为例，单张GPU卡可以支撑大约20路视频的实时分析，这个数字在工程上还有优化空间，但作为规划参考，够用了。

5.3 报警联动与平台集成：怎么和传统安防平台对接

烟火识别系统的最终输出是“报警事件”。报警处理环节有几个容易忽略的细节：

• 报警延迟确认机制：单帧检测到烟火不应立即报警，而是连续多帧（比如5~10帧）都检测到同一区域存在烟火，才输出报警。这能极大减少单帧误检带来的误报。代价是报警延迟几秒，但烟火识别场景完全可接受。
• 报警信息结构化：报警记录不能只包含一张截图，应该包含：报警时间、摄像头编号、地理位置、烟火类型（火焰/烟雾）、置信度、当前帧和一段短视频（截图前后各几秒）。这对接消防和安防值守人员非常关键，他们需要看到烟火发展过程。
• 联动动作：系统输出报警后，可以联动球机（PTZ）转向报警区域进行二次确认，或者联动声光报警器。如果前端有约定的预案，还能通过接口向消防平台推送事件。这部分功能在大型园区项目中通常是验收硬指标。

6. 部署落地难点与解决方案：环境、性能、夜间作战

算法和架构之外，落地部署才是烟火识别项目真正拉开差距的地方。我从实际项目里总结了三个最棘手的问题。

6.1 环境差异：摄像头安装位置和角度决定成败

烟火识别对摄像头的安装位置极其敏感。室外山林场景，摄像头通常装在铁塔或制高点，视野大、目标远、烟火尺寸小，而且存在大面积天空背景——云、太阳光晕都会干扰算法。

室内场景则相反，视角近、目标大，但往往有灯光、反光、机械设备运动等因素。面对同样的算法，不同场景下误报类型完全不同。

工程上，我的经验是：算法适配必须在确定摄像头点位之后进行。有条件的话先做点位勘察，对每个关键点位的画面采集一段24小时的全天候视频，用这段视频做针对性测试和阈值调整。不考现场环境的项目，后期要付出的调试成本会高得多。

6.2 性能瓶颈：多路视频流并发时的优化实践

几十路视频同时分析，性能问题很快会浮现。常见瓶颈有三个：

• 解码瓶颈：FFmpeg软解码1080P视频流，一路大约要占1~2个CPU核心。解决思路是：如果推理机有N卡，优先用NVDEC硬件解码；或者前端摄像头直接输出子码流（如720P或D1分辨率）供算法分析，主码流留给平台存储。
• 预处理瓶颈：缩放、颜色转换、归一化这些操作在CPU上做也很耗时。建议在GPU上完成预处理（如通过TensorRT的预处理层），或者用异步流水线同时进行拉流和解码，避免GPU空转等待数据。
• 推理引擎选择：PyTorch直接推理在实际项目中性能不够，一般会转换为TensorRT引擎或ONNX Runtime。以YOLOv5s为例，同样是Jetson Orin NX上跑，PyTorch推理大约需要40ms一帧，TensorRT优化后可降到15~20ms。这个差距在多路并发下会被放大到极其明显。

6.3 夜间与恶劣天气：烟火识别最难的一道关

夜间是烟火识别准确率大幅下降的场景，也是很多项目验收时最容易出问题的环节。难点在于：

• 普通可见光摄像头在夜间噪点极多，颜色失真，火焰的HSV特征会漂移，传统阈值直接失效。
• 红外摄像头下，火焰和烟雾的颜色信息基本丢失，算法只能依赖形态和运动特征。
• 夜间大雾、雨雪天气下，画面整体对比度低，早期烟雾与背景几乎无法区分。

应对思路：

• 夜间切换模型或参数：白天和夜间分别训练模型，或者部署“昼夜自动切换”逻辑——根据图像整体亮度评估，动态调整检测阈值和置信度，夜间自动提高烟雾检测的敏感度。
• 双光谱融合：可见光加红外热成像双通道。热成像对火焰高温区域非常敏感，能大幅提升夜间火焰检出率。目前这类双光谱设备成本已经不低，主要用于林区和大型露天仓储等高价值场所。
• 后期帧累积：夜间检测到可疑区域后，不单帧判断，而是累积多帧做时间维度的判断，例如提取该区域的闪烁频率特征。这个方法能过滤掉很多噪点误报，但会带来额外计算量。

7. 常见问题排查与算法调优实录

这一节是实战问答，都是项目推进过程中真实遇到过的问题。每一条背后都对应过具体的调试经历，直接列出供参考。

7.1 运行一段时间后GPU显存持续增长、系统卡顿

现象：推理进程刚启动时显存占用正常，运行几个小时后显存逐渐上涨，最终导致推理失败或系统卡顿。

这类问题在视频分析系统中很常见，根因通常不是模型本身，而是视频流处理链路里的资源泄漏。排查顺序：

1. 检查是否每一帧推理结束后都正确释放了TensorRT的绑定内存和CUDA上下文。
2. 检查视频解码端是否有未释放的AVFrame对象。FFmpeg的AVFrame未释放是常见的隐性内存泄漏点。
3. 检查推流旧连接。摄像头端断开重连时，拉流会话如果没有及时关闭，会在底层积累大量无效连接。

我的经验是，先把推理链路独立跑一个纯合成视频流，排除摄像头因素，再逐步叠加真实视频流。一个晚上就能定位问题。

7.2 白天误报多，尤其是阳光强烈的时段

现象：上午10点到下午3点之间误报率明显升高，画面中经常出现红褐色区域被识别为火焰。

这类误报的主要来源是阳光照射下的红色建筑物、铁锈表面、红土路面、以及玻璃幕墙反射光。应对策略：

• 提高火焰检测的置信度阈值，从0.35调到0.5以上，误报明显下降，但漏报风险增加，所以需要辅以时序确认机制保住灵敏度。
• 引入“场景学习”机制：部署后先空跑24小时，记录没有烟火情况下各区域的频繁检测位置，标记为“已知干扰源”。后续检测到这些位置时，额外要求更高的置信度。
• 在部分场景中，可考虑在算法后端接入一个简单的色彩环境判定——如果整帧图像亮度异常高且饱和度偏低，可适当降低火焰检测灵敏度。

7.3 烟雾漏报率高，尤其背景复杂或光照不均的场景

现象：烟雾明明已经在画面中出现，但模型始终没有检测到。截图检查发现，烟雾与背景颜色过于接近，或者烟雾被树干、建筑边缘遮挡。

这里要区分是“模型没看到”还是“看清了但没认出来”。排查方法：

• 抽帧截图确认烟雾在画面中的实际大小。如果烟雾区域只有十几乘十几个像素，那属于小目标检测能力不足，可以通过提高输入分辨率或增加小目标增强样本来解决。
• 如果烟雾区域足够大但模型仍然不认，多半是训练样本中该类型烟雾覆盖不足。补充对应场景下的烟雾样本重新训练即可。
• 另外值得注意：烟雾检测的置信度通常比火焰低。可以把烟雾和火焰拆分为两个独立报警逻辑——烟雾报警阈值设置更低，但要求更多连续帧确认，确保不漏报的同时抑制误报。

7.4 摄像头轻微抖动导致频繁误报

现象：摄像头安装在铁塔或杆件上，风吹导致画面轻微晃动，原本静止的物体边缘持续产生“伪运动”，误报率飙升。

画面抖动对运动特征提取影响很大。解决办法：

• 增加视频稳像预处理：先做帧间配准，计算全局运动偏移量，再做差异分析。OpenCV的estimateAffinePartial2D配合warpAffine可以实现基础稳像。
• 或者采用“区域排除”策略：抖动场景下，画面边缘区域通常晃动最厉害，适当缩小检测区域，屏蔽画面四边的窄条。
• 从源头解决更有效：建议现场加装防晃支架或选用带陀螺仪增稳功能的重型云台。

7.5 报警延迟太高，烟火明显可见后才报警

现象：烟火已经明显发展了几十秒，报警才弹出来。经检查，模型检测本身没问题，问题出在“多帧确认”策略和抽帧率的组合上。

假设抽帧率为每秒2帧，确认帧数为10帧，则理论最短确认时间为5秒，但如果单帧检测因目标太小或者瞬时遮挡漏检了几帧，实际累积时间可能拖到十几秒。

解决方案：

• 把确认机制从“连续N帧”改为“M帧内N帧检出”，例如5秒内检出8帧即触发。这样同时降低对单帧漏检的敏感性。
• 对高危区域（如配电房、仓库）可以单独配置更高抽帧率和更低确认帧数，牺牲部分误报率换取更快响应。
• 增加“可疑状态”联动：检出第一帧后即推送预览消息给值守人员，提醒关注现场画面，但不直接触发正式警报，减轻漏报风险。

8. 从项目延伸到产品：这套系统还能怎么扩展

烟火识别在视频监控场景中不是一个孤立的功能，做好之后可以顺滑扩展出很多衍生能力。这一点在项目方案汇报和产品规划上特别有价值。

8.1 与消防通道占用检测、配电室异常检测融合

同一个监控点位，除了烟火识别，还能同时跑多种算法：消防通道占用检测、配电室冒烟检测、危险区域闯入检测等。这些算法共享同一套视频接入和推理平台，后台统一管理，能显著降低单路视频的部署成本。

我参加过的一个园区项目，就是从单纯的烟火识别扩展为“综合安全风险感知平台”，一个摄像头点位同时跑三种算法，硬件总成本只增加了不到一半，但平台价值感和项目预算空间完全不一样了。

8.2 烟火定位与地图联动

单靠监控画面，报警后不太容易快速确定火源在地图上的准确位置。如果有条件，可在项目中增加烟火空间定位能力：

• 在重点区域建立摄像头坐标映射关系，一旦某一路或几路摄像头同时报警，通过三角定位或多视角交叉验证，在地图上标出火源大致位置。
• 这个功能对森林防火指挥、化工园区应急处理非常有价值，也是项目验收时比较加分的部分。

实现上不需要非常复杂的算法，本质上是用摄像头的经纬度、朝向、距地高度等元数据，结合算法输出的画面坐标反算地面位置，误差范围在几十米内即可满足调度需求。

8.3 数据回流：报警事件库反哺模型迭代

烟火识别系统运营越久，沉淀的报警数据和误报样本越多。把这些数据定期整理、清洗、重新标注，可以持续优化模型。这是系统长期有效性保持的核心机制。

我建议在系统设计阶段就规划好数据回流通道：报警截图、视频片段、人工复核结果都结构化存储，每个月做一次增量训练，用真实场景数据不断提升模型水平。很多项目忽视了这条，导致系统上线半年后因场景变化而准确率逐步下降，而这本质上是一个比较可惜的现象——问题出在缺乏迭代闭环，而非算法本身失效。

9. 一个可以借鉴的落地案例复盘

这里想分享一个模拟项目X的复盘，项目背景是某化工园区的消防预警系统升级，覆盖园区内十二个重点生产区域，共接入约四十路高清监控。项目目标是实现烟火自动识别报警，并要求误报率控制在每天每十路不超过一次、烟火检出率不低于九成。

选型阶段，我们对比了两种方案：纯传统视觉方案（颜色阈值+背景建模）和深度学习方案。最终选定后者为主、传统算法作为前置过滤为辅的组合。硬件方面，选用了一台配备入门级GPU的服务器承载全部四十路视频流分析，单路抽帧设定为每秒2帧。

数据集构建用了约五万张图像，其中公开数据集约占六成，自采集占三成，合成数据和增强样本占一成。自采集阶段，在园区周边废弃场地点燃了三种材料（木材、纸张、油类），从不同点位角度采集了正午、黄昏、夜间三种光线条件的视频。

训练阶段踩了几个坑。第一次训练出来的模型在测试集上mAP有0.87，看起来不错，但放到园区真实画面上一小时误报了三十多次。排查发现误报源主要是园区里往返的红色货车和傍晚的落日余晖。后来针对性补充了大量“红色车辆、红色建筑、日落”负样本，重新训练后，误报率降到了每天每十路大约两三次的水平。

上线运行一周后，经历了真实火情，过程是：园区西侧一个废料堆放点出现明火，算法在明火出现的第6秒检测到火焰，系统在同一区域的连续帧确认后，在第11秒推送了报警。值守人员通过联动球机确认了现场情况。从发现到确认，整个过程不到30秒。这个速度是人工盯屏很难达到的。

项目收尾阶段，最耗时的反而不是算法调优，而是现场点位微调。有几个摄像头安装角度偏斜，导致了较多的无效检测区域覆盖，增加告警推送频率。实地调整摄像头俯仰角、避开大面积反光面之后，误报率进一步下降到可接受水平。通过这个项目，我意识到烟火识别系统的工程属性非常强，纯粹从算法层面优化很难完全解决问题。

10. 关于未来的一个扩展方向

最后分享一个我认为烟火识别后续价值比较大的延伸方向：接入更多非可见光传感器。

可见光摄像头的物理上限摆在那里，夜间、雾天、遮挡等问题是算法很难完全突破的。目前已经有团队在试验近红外、热成像与可见光的多光谱融合方案，用热成像锁定高温区域，用可见光分析烟雾形态，两种信息互补。

我自己在一些模拟场景中测试过热成像通道的价值：夜间静态火源在热成像中几乎是“无法忽略”的强信号，检测难度远低于可见光。如果未来硬件成本进一步下降，双光谱甚至三光谱融合会成为烟火识别系统的主流形态。

另外，边缘端算力持续上涨之后，在摄像头前端直接跑小模型做初步烟火过滤也会逐渐普及。前端的价值不只是降低中心端压力，更重要的是在断网、平台故障等极端情况下，单摄像头仍能本地识别并推送报警，这对森林防火、野外基站这类弱网场景意义很大。

如果你正准备启动一个烟火识别相关的项目，我的建议是：先花时间把数据采集、点位勘察和报警确认机制设计好，再追求模型精度的提升。这套系统能不能真正发挥价值，关键往往不在算法先进性，而在于工程细节是否经得起真实场景的考验。