基于YOLO系列与SpringBoot的森林火灾烟雾检测系统实战

1. 项目缘起森林防火监测的痛点与烟的隐性问题先聊点背景。森林防火这块行业内最怕的不是明火而是烟——等到人眼看着火苗冒起来往往已经烧了不小面积。传统的高清视频巡检靠值班员盯多路屏幕半小时轮一遍人眼疲劳之后漏报率非常高尤其是在午后逆光、林间雾气、远处炊烟这些场景误报一次就够呛。实际上我们当时接手的需求很简单能不能在不改造现有前端摄像头的前提下用主流目标检测框架搭一套烟雾识别系统检测到疑似烟情后自动告警并且把告警信息结构化推送到Web端让防火值班人员可以随时随地看到现场截图、置信度和定位信息。这个项目最终落地成了基于YOLOv8/YOLOv10/YOLOv11/YOLOv12与SpringBoot的森林火灾烟雾检测系统前后端分离带Web交互界面搭了一层大模型智能分析模块做告警研判。整套系统的核心价值不在于某单个模型多强而在于打通了摄像头画面→YOLO检测→大模型研判→Web告警推送这条完整链路。对于想了解YOLO系列版本实际对比、SpringBoot后端集成、大模型辅助分析这种组合玩法的人来说这篇博文应该可以给你一套比较完整的参考。说句实在话烟雾检测和普通的目标检测不太一样。人、车、猫狗这些目标有轮廓、有纹理、有稳定的高宽比但烟是半透明的、形状随气流不断变化而且在远距离小目标场景下基本就是一小团灰度渐变。所以从数据到模型选型再到后处理每一步都踩了不少坑这些经验我会在后面按实际开发顺序展开讲能帮你少走很多弯路。2. 技术选型YOLO系列四个版本在烟雾检测上的取舍2.1 为什么把四个版本放在一起对比很多人看到标题里写了四个YOLO版本第一反应是噱头。但实际做工程选型的时候这个对比是被现实逼出来的不同前端摄像头算力不一样有的机房只有纯CPU推理环境有的配了老款GPU有的能上最新的加速卡。单一的模型版本没法覆盖所有部署场景所以我把YOLOv8、YOLOv10、YOLOv11、YOLOv12都跑了一遍基线实验最后按部署环境分别选了合适的版本。这里要先说清楚各版本的核心差异。YOLOv8是绝对稳定的基线条线生态最成熟网上资料多遇到问题好排查YOLOv10主打无NMS设计把推理后处理的时间省掉一大截在同等模型尺寸下帧率有明显提升YOLOv11是后端架构进一步优化的版本在轻量化和精度之间平衡得最好训练收敛也快YOLOv12则引入了区域级注意力机制对远距离小目标的特征提取理论上更有优势适合烟雾这种缺乏清晰纹理的目标。2.2 实验对比结论没有万能模型只有合适场景我拿同一套烟雾数据集大概1.6万张标注图后面细说分别训练了n/s/m三个量级的模型对比维度包括mAP50、mAP50-95、推理耗时、模型体积、漏报率。大致结果可以浓缩成下面这张表模型版本参数量mAP50mAP50-95推理耗时(ms, GPU)适用场景YOLOv8n3.2M87.452.12.1CPU/低算力设备YOLOv8s11.2M90.257.83.4常规视频监控YOLOv10n2.3M86.951.51.6高并发抽帧检测YOLOv11s9.4M91.159.33.1均衡型主力部署YOLOv12s11.8M91.661.23.9远距离小目标场景单看mAPYOLOv12确实有一点优势尤其在验证集里那些占画面不到1%的远景烟雾样本上它的召回率比YOLOv8高出三个多点。但代价是推理慢了大约15%而且训练显存占用也比v8高。所以最后的方案是常规场景主力用YOLOv11s边缘低算力盒子用YOLOv10n远山哨塔摄像头用YOLOv12sYOLOv8s作为兜底回退版本留在镜像里。这也算是对标题里四个版本都出现的一个解释——不是炫技是部署现实。2.3 选型时容易忽略的三个细节第一个坑是ONNX导出兼容性。YOLOv10和YOLOv12在没有NMS或自定义注意力算子的结构上转ONNX再转TensorRT时容易出算子不兼容问题。YOLOv12的注意力模块在部分老显卡上会报unsupported op错误必须用官方更新后的导出脚本配合特定版本TensorRT才能跑通。第二个坑是前处理不一样。YOLOv10和YOLOv12的预处理对图像缩放方式有细微差别用同一个Python脚本切换模型跑推理时最好把预处理函数也按版本分开封装否则精度会白丢一截。第三个坑是部署形态如果是走SDK集成做视频流分析我建议选支持非极大值抑制后处理导出的构建方式否则在应用层自己实现NMS徒增难度。3. 数据准备烟雾样本比想象中更难凑3.1 数据来源公开集、自采与合成扩充三管齐下训练烟雾检测模型最难的不是算力是数据。烟雾这个东西在不同光照、不同背景下长得完全不一样蓝天背景的烟和阴天森林里冒出来的烟特征差异大到离谱。我第一版模型只用了公开的火灾烟雾数据集和少量自采画面结果一到实际监控场景漏报惨不忍睹后来硬着头皮把数据重新梳理了三轮。第一轮是公开数据集收集了几个公开的烟火检测类数据集类别重标为smoke清洗掉重复样本大概得到7000多张。第二轮是自采数据我们找了一段有摄像头的林区主要是铁塔监控和闸口杆塔摄像头连续采集了一周不同时段的视频按关键帧抽了4000多张涵盖清晨、正午、傍晚、夜晚四种光照其中夜间的烟因为有红外补光特征和白天很不一样。第三轮是合成数据用软件抠出烟的实拍素材贴到不同的背景图上配合透明度、缩放、透视变换做了一轮增强得到5000多张。3.2 标注细节不要只画一个外接框不少新手做烟雾标注时习惯把整片烟区画一个框这在实际训练中会带来大问题。烟雾是弥散的边缘没有明确边界如果你一个框把高浓度烟心和淡薄的烟尾巴全包进来模型学到的边界就是一团浆糊。我的做法是只框浓度最高、肉眼能明确判断为烟的核心区域烟尾巴和极淡区域宁可不框。这样做的原因是在工程部署阶段我们本来就不需要检测出所有淡烟只需要对确定性的烟情做出可靠告警宁可漏掉模糊的淡烟也不能被误报煎熬。还有个细节值得单独说数据集中一定要有烟状干扰物的负样本。雾气、云层、炊烟、水蒸气、扬尘这些在视觉上和烟极其接近如果用它们在正样本里做标注模型会疯掉。我的方案是把这些统一收集到一个distractor目录训练时不参与正类别但做验证和压测时专门拿它们测误报率。这个习惯直接决定了系统上线后值班员信不信你的告警。3.3 数据集划分和平衡策略数据划分上要注意按场景划分而不是按图像划分。同一段视频抽取的连续帧如果一部分进训练集一部分进测试集性能会被严重高估。我按视频片段ID做group划分保证同源帧全部落在同一集合。类别平衡方面小目标样本本身占比高所以没有刻意做类别重采样但我在每个epoch里对夜间样本做了额外的Mosaic增强因为夜间烟在整体样本里只占8%左右不增强的话基本学不到。最终数据集规模是训练集1.1万张验证集3000张测试集2000张另有800张纯干扰物负样本集。标注使用常见的YOLO格式类别ID统一为0表示smoke坐标归一化。有了这批数据后面四个YOLO版本的训练才有可比性。4. 模型训练与评估从漏报大户到高召回4.1 训练参数怎么定我最终采用的配置烟雾检测任务的特殊性在于烟的形状高级抽象且尺度变化剧烈所以Mosaic增强几乎不能关。我最终采用的统一训练配置如下输入尺寸640×640兼顾小目标和显存局部实验试过768×768mAP提升不到1个点但训练时间增加30%性价比低优化器SGD初始学习率0.01使用余弦退火策略Batch sizeGPU显存限制在32配合梯度累积训练轮数YOLOv8/v11训练160轮YOLOv10因为收敛快训练120轮YOLOv12训练180轮注意力层需要更长收敛时间数据增强Mosaic1.0MixUp0.2HSV扰动偏小因为烟的颜色信息很弱过度增色会导致背景误判损失权重默认配置但对cls_loss做了一点上调用于缓解因为烟雾正样本小目标多导致的分类置信度不足这里想专门说一句学习率的事。烟雾数据集噪声比普通目标检测数据集大学习率高了容易震荡低了收敛慢。我试过从0.001到0.02的几组最终0.01配余弦退火效果最好前10轮warmup很重要否则模型一开始就会陷入对背景纹理的过拟合。4.2 评估指标为什么对烟雾系统要盯着召回率看通用目标检测论文看mAP但工程上烟雾告警系统不能只看mAP。因为mAP兼顾了精度和召回而防火场景里漏报的代价远高于误报——一次漏报可能意味着火情延报十几分钟一次误报顶多让值班员多点几下鼠标。所以我定义了两个核心指标召回率Recall at Confidence0.25在低置信度阈值下真实烟雾样本被检测出来的比例误报率False Alarm per Hour在连续视频流场景下每小时每路摄像头产生误告警的次数实测下来YOLOv11s在验证集上Recall可以达到89.6%但接入视频流之后因为画面里有飞鸟、云影、车辆扬尘误报率大概每小时每路0.8次正好还能接受。YOLOv12s在小目标场景下Recall进一步到92.1%但是误报率略高所以我额外加了一层置信度延迟确认机制同一个位置连续3帧都检测到烟才推告警。这个策略直接把误报率砍掉了60%。4.3 多版本横向对比的实战结论用同一份验证集测试YOLOv10n的Recall最低大约85.2%但它的推理速度几乎是v8n的两倍适合在十几个摄像头并发抽帧的盒子上跑。YOLOv8s相对均衡胜在稳定出问题好排查。YOLOv11s综合表现最好无论是训练收敛速度还是最终精度都是直接拿来部署的最优选。YOLOv12s在小目标上有增益但要注意它需要更多的训练轮数和显存如果设备不支持还是别硬上。对于想快速验证自己数据集效果的同学我的建议是先用YOLOv11s跑一个标准训练流程把数据问题和标注问题暴露出来再根据部署环境切换到其他版本。而不是一上来就四个模型全训那样只会浪费时间。5. SpringBoot后端与Web交互界面前后端分离怎么落地5.1 系统整体架构三道闸门一条链路整个系统的后端用SpringBoot搭服务前端Vue做界面数据用MySQL存告警记录Redis缓存实时的检测帧和状态信息。核心链路是这样摄像头视频流先经过一个独立抽帧服务Python实现把RTSP流转成JPEG帧以一定频率发送给YOLO推理模块推理模块拿到帧后跑模型产生检测结果结果被封装成自定义协议通过HTTP回调推送到SpringBoot后端后端再落库、推送WebSocket给前端展示。这里有一个关键设计抽帧服务和SpringBoot后端完全解耦。抽帧服务在边缘端SpringBoot在中心机房两者通过消息协议对接。这样摄像头分布在不同网络区域时不需要全链路打通只需要边缘服务能访问到中心接口即可。实际上我们最开始试图把YOLO推理直接嵌进SpringBoot的Java进程里通过ONNX Runtime跑模型确实也能跑但是模型更新需要重启服务并发抽帧还会占用Tomcat线程池后来就把推理拆成独立服务了。5.2 告警链路的SpringBoot实现要点SpringBoot端主要暴露了这几个能力告警记录落库、告警快照保存、WebSocket实时推送、历史回查接口、配置管理接口。告警记录表设计时有几个字段值得注意camera_code摄像头编号、frame_urlJPEG快照存储地址、detect_conf置信度、smoke_box归一化坐标、ai_verdict大模型研判结论、alarm_status待确认/确认/误报。其中smoke_box我直接用JSON字符串存查询时不参与索引展示时前端直接解析。服务端处理告警的逻辑要尽量轻。我实际写了一个简单的告警汇聚服务为避免同一持续冒烟场景狂刷告警对同一个camera_code 相同位置重叠度超过50%的检测框做了5分钟窗口内的去重合并只保留置信度最高的一条推送并附带这5分钟内的检测帧数。这样前端不会出现告警风暴值班员也不用对着三十条重复告警挨个点确认。5.3 前端界面地图、视频预览与告警列表三块核心前端界面分三块。第一块是总览地图页把摄像头点位铺在底图上有告警的摄像头红点闪烁点击可以弹出该摄像头实时画面和最近告警截图。第二块是视频预览页接入WebSocket推送的实时检测帧画面上用Canvas动态绘制检测框实时显示当前帧中的烟雾区域和置信度。第三块是告警列表页展示历史告警的筛选表格支持按照摄像头编号、时间段、状态筛选点击某条记录能看到原图和检测框叠加后的对比效果。要说一下实时推帧的实现。直接推视频流实时性是够了但占用带宽太大。我的做法是抽帧服务检测到烟雾时以每秒2帧的速率推送现场帧没有告警时只推心跳。这样既满足了值班员在告警时查看实况的需求也避免了所有摄像头画面无脑全推造成的服务压力。前端收到推送帧后会先播放一小段缓存的动图让值班员能直观看到烟的扩散趋势。5.4 视频流接入与抽帧策略这块看着简单坑不少。RTSP流在某些网络环境下不稳定经常断流重连抽帧服务需要做好自动重连和重试逻辑我用的策略是连续3次拉流失败后休眠10秒再重试同时记录断流日志。抽帧频率不要盲目调高一般每路摄像头每秒抽1帧足够因为烟的变化是缓慢过程1帧/秒能够覆盖从冒烟到明显成烟的整个过程同时把CPU开销控制在可接受范围。抽帧时的分辨率也要处理。很多摄像头主码流是1080p甚至4K直接送进模型推理GPU显存和耗时都很吓人。我的做法是先把主码流抽帧然后缩放到960×540再到模型预处理缩放640×640这样在保留小目标信息的同时推理速度比直接把1080p缩放进模型快很多。实测对比直接用1080p缩放和经过960中间步两者在mAP上几乎无差异但前者在GPU上的吞吐量高40%。6. DeepSeek智能分析让告警从有图到有判断6.1 为什么要加一层大模型分析YOLO模型本质上只解决是不是烟的问题但值班员真正关心的是这个烟要不要处理。同样一张冒烟图可能是林区烧荒、秸秆燃烧、生活区炊烟也可能确实是山火前兆。在真实场景里如果对每种烟都拉响最高级别告警持续几次误判之后整个系统的可信度就崩塌了。所以我在告警链路上加了一层大模型智能分析。做法是每次YOLO检测到烟雾后除了保存检测框和置信度还把当前帧的局部截图检测框区域和摄像头所在位置的上下文信息比如镜头朝向、所处地形、历史告警记录一起组装成提示词调用大模型接口让它给出一个结构化风险研判是真实山火风险、疑似人类活动烟源还是大概率误报并附上一句具体分析理由。6.2 提示词工程与多层级调度策略这里我没有一开始就玩复杂的多智能体框架而是先做了一个经典的prompt模板把输入压缩成固定句式输出约束成JSON。模板大致思路是提供给模型的图片信息包括检测框区域截图自动用Vision能力读取上下文包括场景类别山林/林缘/农地/道路、天气条件晴/阴/雾/风、检测置信度、连续检测帧数。让模型输出三个字段risk_levelhigh/medium/low、source_probability对烟源类型的判断概率分布、description一句话描述。多层级调度主要是为了省钱。不是每次告警都调用大模型而是分三级置信度低于0.6且只在单帧出现的检测不调用模型接口直接进入疑似待观察状态置信度0.6到0.85之间调用模型初步研判置信度高于0.85且连续多帧确认的调用完整版研判同时推送最高级别告警。实测下来每天每路摄像头调用大模型接口的次数能控制在一百次以内成本完全可控。6.3 接入后实测效果与注意点接入大模型分析后最直观的变化是告警的分类准确率提升明显。YOLO单独判定的高置信度告警中有约15%被大模型降级为疑似人类活动烟源而没有触发最高级别预警。这个比例对值班场景来说很关键等于帮值班员把15%的无效紧张过滤掉了。另一方面大模型对云层雾气的误报识别也比纯视觉模型强因为它能结合位置、场景描述做判断而不只是看像素。但大模型分析也不是银弹。我遇到最多的问题是远端小目标截图分辨率太低Vision能力识别不清楚给它看一个20x20像素的灰团它也编不出什么靠谱理由。所以我在调用大模型之前会在告警链路里插入一个可不可以使用此分析判断如果检测框面积小于整帧的0.5%直接跳过智能分析只给一个低级别提示避免大模型瞎猜误导值班员。7. 调试排障与回忆最容易踩的坑和后续优化方向7.1 开发过程中踩过的几个大坑第一个坑是模型精度很高但视频流里一直检测不到。折腾了很久发现是抽帧服务和推理服务之间的图像格式没对齐。抽帧服务输出的是BGR排列的JPEG字节流而推理服务里加载图像用的接口默认按RGB读等于把红蓝通道直接对换了。视觉上看起来颜色偏一点人眼可能还不太注意但对模型来说特征分布变了检测效果直接崩了。最后在推理服务入口处强制做一次BGR到RGB转换问题立刻消失。第二个坑是不同版本YOLO模型权重混用。因为我在同一个推理服务里需要切换四个模型最初把几个版本的ONNX导出配置搞混了导致YOLOv12的模型被当成YOLOv8的输入预处理方式执行mAP跌到40%以下。后来我把模型加载和预处理封装成独立的version dispatch层按照模型文件名后缀自动选择预处理函数和输出解析方式才彻底解决。第三个坑和视频流有关。RTSP拉流在公网环境特别容易卡顿一开始把所有抽帧服务放在中心服务器结果带宽不够延迟飙到十几秒。后来改成把抽帧服务部署到靠近摄像头的边缘节点只把JPEG帧和检测结果回传中心延迟一下子降到两秒内。这个教训很直接不要把视频裸流传到中心再做检测边缘抽帧边缘推理才是远程监控系统的正解。7.2 后续可以做的优化方向如果再有时间我会往这几个方向深入一是小目标检测增强烟雾在远距离下经常只有十几个像素可以考虑增加P2检测头或者切图检测策略把大面积画面切成四块分别推理再合并能显著提升远山烟情召回率但需要处理好重叠区域的去重逻辑。二是多摄像头联动分析同一片林区多个摄像头视角重叠时可以结合相机标定信息做多目交叉验证两个摄像头都检测到同一区域烟雾时告警置信度大幅提升。三是告警知识库积累把大模型的历史研判结论和最终确认结果沉淀下来形成一个迭代闭环让系统越用越贴近特定林区的烟雾特征。做这套系统最大的体会是模型训练只是整条链路的一环真正耗时间的是数据治理、系统集成和按场景调优。标题里那四个YOLO版本如果单独看每个都是很成熟的工具但放到一个真实防火项目里你需要操心的是预处理一致性、推理服务稳定性、告警去重、大模型成本控制这些听起来很不性感的细节。恰恰是这些细节决定了这套系统是在演示环境里跑Demo还是能真正在值班室被每天用起来。如果让我重新做一遍我会在一开始就按边缘抽帧中心研判延长告警确认窗口的架构来做而不是先跑通单路Demo再补各种工程化改造。如果你正准备做类似的项目建议先把你手上的摄像头画面拉出来看两天把所有烟状干扰物样本都提前收集好再决定买哪张显卡。数据的问题没想清楚后面每一步都会很难受。