去年年中我接了一个跟火焰烟雾检测相关的视觉项目需求平台方要求把检测能力做成一个可演示、可二次开发的Web系统模型部分希望覆盖YOLOv5到最新的几个版本方便后续对比选型。折腾了大概一个多月我把基于深度学习的火焰烟雾检测方案完整跑通从数据集整理、模型训练到Django Web展示全部打通。这篇文章就把这个过程拆开讲清楚包括选型逻辑、训练参数、Web部署细节和实测翻车记录给准备做类似项目的同学一份可以直接参考的实操笔记。整个系统听上去很多件套在一起——又是YOLOv12/v11/v8/v5又是Django又是Web又是数据集实际上拆开看核心就只有三件事模型能不能检测准、Web端能不能展示流畅、训练集够不够支撑场景落地。只要这三条线理清楚项目进度基本就不会卡壳。1. 火焰烟雾检测到底解决了什么问题——从真实场景说起1.1 为什么传统传感器在开阔场景下不够用很多不了解这个领域的人会问消防不是已经有烟感、温感报警器了吗为什么还要用摄像头做火焰烟雾检测这里有个很关键的实际问题——传统传感器适合密闭空间和近距离场景比如室内天花板、楼道、配电间但遇到仓库中庭、室外堆场、森林防火这类开阔场景烟感和温感就力不从心了。烟雾要飘到传感器附近才会触发报警火焰如果发生在几十米外等传感器感知到火势很可能已经蔓延了。视频火焰烟雾检测恰好补上了这个盲区。摄像头看得远、覆盖面积大、响应时间短能在火焰出现后的几秒到十几秒内就给出预警。加上现在的摄像头本来就是安防系统的标配不需要额外增加硬件成本只需要在已有的视频流上叠加一层智能分析能力。这也是我把这套系统定位成基于深度学习的火焰烟雾检测系统而不是简单做一个烧CPU的演示Demo的原因它的使用场景是真实环境中的异常预警。1.2 这个项目的目标形态和适合谁来参考我当时给项目定了三个目标。第一是模型层面要能对火焰和烟雾两类目标分别检测输出类别、置信度和边界框第二是系统层面要支持上传图片检测、上传视频检测最好还能接RTSP摄像头流做实时检测第三是演示层面要有Web界面让不懂深度学习的人也能直接打开浏览器上传一张图就看到检测结果。这套东西适合谁参考两类人最合适一类是想用YOLO系列做工业级视觉检测但还没想清楚技术路线的开发者另一类是接了安防、消防预警相关项目需要快速出演示效果的团队。如果你是学生做课程设计或者个人作品集这套方案同样合适因为模型训练和Web端展示是两条独立线路可以只选其中一条来做。我在做的时候就是先跑通模型训练再用Django把模型包起来变成可视化页面整个过程没有用到特别冷门的技术全部是日常开发就能覆盖的东西。2. YOLO系列模型选型从v5到v12为什么我最终这样搭配2.1 四个版本的真实差异和定位项目标题里提到的YOLOv5、YOLOv8、YOLOv11、YOLOv12很多人会纠结选哪个其实这四个版本不是替代关系而是思路上的迭代关系理解它们的差异比单纯看精度数字更重要。下面这个表格是我根据自己的使用体验整理的不是纯理论分析更偏实战视角版本发布时间段核心特点实战优势需要留意的点YOLOv52020年前后工程化最成熟社区资料极多环境兼容性最好部署资料多到搜不完检测头结构相对旧小目标能力一般YOLOv82023年前后C2f结构Anchor Free训练生态完善训练稳定mAP均衡导出部署格式全模型体量比v5大CPU推理稍慢YOLOv112024年前后在v8基础上做了骨干和颈部优化计算效率提升同等算力下精度更好新特性依赖较新版本环境YOLOv12最近的新版本引入了注意力机制改造潜力大在小目标和复杂背景场景值得试生态还在完善遇到问题参考资料少实际选型的时候不能只看精度榜单。YOLOv5强在稳YOLOv8强在均衡YOLOv11和v12强在新机制带来的想象空间。火焰烟雾检测这个场景有一个特点——白天和夜晚的光线差异极大烟雾是半透明目标火焰则在暗光下很亮对小目标的精度要求不低。所以我最后采用的方案不是只选一个版本跑到底而是做对比实验用同一个数据集分别在v8和v11上训练看谁的效果更适合当前场景同时用v5做一次基准测试v12用来验证新机制在烟雾检测上的表现。这样项目的结论会更有说服力也能避免只用某个版本但说不清为什么选它的尴尬。2.2 我最终确定的模型组合方案说了这么多我的实际落地组合是主训练模型用YOLOv8n和YOLOv8s一个轻量一个均衡配合YOLOv11做精度对比YOLOv5和v12作为参考模型跑同一条数据链路。这样的好处是如果演示的时候观众问为什么不用最新的YOLOv12我可以直接拿出对比数据说因为v8在当前数据集上精度接近且推理速度更稳定而不是被问住。还有一个关键点Web演示系统的模型不需要追求大。很多人觉得效果不好就上大模型实际上在火焰烟雾系统里yolov8n的模型文件大约二十兆级别在普通GPU上推理一帧只要几十毫秒在小目标检测上的表现足够应对演示需求。真正影响精度的不是模型大小而是数据集质量。这一点我在后面专门展开讲。如果你本身算力有限我的建议是先用YOLOv8n跑通全流程确认数据没问题再换大模型不要一上来就训练yolov8x浪费时间不说调参难度也大。3. 数据集准备与标注细节效果好坏的第一道分水岭3.1 数据来源与实际采集的取舍做火焰烟雾检测的第一个坑就是数据。火焰烟雾不是常规物体网络上能直接下载的公开数据质量参差不齐所以我采用公开来源自采自标两条腿走路的策略。整体数据规模最终控制在八千张左右其中大约六成来自筛选整理过的公开图片四成来自自己拍摄和视频抽帧。自采部分我是这么做的找了一块室外空地用铁桶点燃纸张、木柴分别用手机和摄像头在不同距离、不同角度、不同光照条件下拍摄火焰和烟雾烟雾部分除了燃烧产生的烟雾还单独用烟饼制造了浓烟、薄烟、白烟、灰烟等情况。这里有一个容易被忽略的知识点——火焰烟雾检测系统里面烟雾比火焰难检得多。火焰有明确的颜色和轮廓烟雾却是半透明的、边缘模糊的不同背景下的表现差异很大所以在采集数据的时候烟雾样本的多样性一定要比火焰样本更丰富。视频抽帧也是很好的数据补充方式。我从自己录制的大约四十段视频里按每秒一帧的频率抽取图像再用脚本做初步清洗删掉虚焦、过曝、目标占比过小的图片留下来的才是能进标注流程的有效数据。一段五秒钟的视频大概能抽出一百多帧去掉重复和模糊的真正能用的也就不到一半。3.2 标注规范与容易出错的细节数据集准备绕不开标注。我用的是LabelImg这类常见的矩形框标注工具虽然界面朴素但对目标检测项目够用。火焰烟雾检测在标注的时候有几个非常关键的细节我踩过坑之后总结成了规则第一火焰和烟雾同时出现在一张图中就分别标成两个框不要合并。火焰区域标fire烟雾区域标smoke。第二如果火焰被烟雾完全遮挡只标注可见的火焰部分不要凭经验框出看不到的区域。第三烟雾标注框尽量贴合肉眼可见的轮廓烟雾扩散很广的情况下宁可框得保守一点也别把大量背景框进去——背景内容太多会让模型学到的特征不纯。第四条是我的血泪教训不要小看远距离小目标。火焰在五十米外可能只有十几个像素这种小目标恰恰是监控场景最常见的形态标注的时候哪怕只有十几个像素的橙色区域也要认认真真框出来。如果嫌麻烦把这些小目标全删了模型训练出来的结果在真实场景中基本失效。标注完成之后一定要做一次遍历复查把所有框调出来过一遍看看有没有框错类别的、有没有漏框的。我在第一次标注时因为赶时间大概有几十张图的烟雾框画得太随意后来训练出来的模型对烟雾的召回率明显偏低于火焰查了两轮才发现是这个原因。3.3 数据增强策略和训练集划分数据增强我的做法比较克制没上特别复杂的方案。颜色抖动对烟雾检测有帮助因为烟雾在不同光线下的颜色变化比较大随机旋转和左右翻转可以增加样本多样性马赛克增强是YOLO系列自带的能力我保留了默认设置。没有用太多的模糊和噪声增强因为会拉低真实场景的泛化能力。划分上我按7:2:1做了训练集、验证集和测试集并且保证测试集里的场景和训练集不完全重合——比如说视频抽帧的某些连续帧我不会让相似帧分别出现在两个集合里防止看起来精度很高实际是数据泄漏。这个划分在小项目里特别容易被忽略很多人直接随机切分结果训练集和测试集有大量几乎一样的图验证指标虚高一到新场景就暴露问题。4. 模型训练与调参实战从过拟合到稳定收敛4.1 训练环境与基线参数我训练用的机器配置是单张消费级GPU显存24GPyTorch环境CUDA版本跟随PyTorch官网推荐。就这个配置来说跑YOLOv8n在两千多张图像的数据集上一个epoch大约几十秒训练一百个epoch大概一个多小时完全在可接受范围内。训练超参数的基线我是这么设置的参数设置值说明img_size640YOLO系列默认兼顾小目标和速度batch_size1624G显存下比较稳妥显存小就调到8epochs120提前开了早停没跑满optimizerAdamW火焰烟雾数据集上用AdamW收敛比SGD平稳lr00.001初始学习率避免起步发散早停耐心值20连续20轮没提升就停这里我多说一句学习率的问题。很多人喜欢上来就改学习率其实YOLO系列的默认学习率调度策略已经比较成熟除非数据集特别小或者特别大不然用默认值就够。我试过把学习率调到0.01结果前十个epoch损失一直在震荡后面老老实实调回0.001才稳定下来。如果你的训练集只有几百张图batch_size再小一点学习率也可以相应降一点这是小数据集上防止过拟合的有效手段。4.2 训练过程中我遇到的最典型问题训练过程中的第一个问题就是早期过拟合。模型在训练集上loss降得很快到验证集上却一直不降这在我第一次用纯自采数据训练的时候特别明显。原因也很直接——自采数据里大量的相似角度、相似背景模型很容易把背景当成特征来记忆。解决方法是先减少数据增强里的随机参数范围再加大验证集的数据多样性同时把早停耐心值从10提高到20给模型更多震荡收敛的机会。这里有个反直觉的点很多人以为过拟合就拼命加正则化其实先查数据多样性往往比调正则项更有效。第二个问题是烟雾类别召回率低。刚训练完的时候火焰检测的mAP已经到了0.85以上烟雾却只有0.6左右这就是我前面说的标注问题。后来我重新复查了烟雾标注框把那些框得过大、包含了太多背景的样本全部重新调整又补充了一批薄烟雾和远处小烟雾的图片再训练之后烟雾mAP拉到了接近0.8。所以说数据质量真的比模型版本更关键与其纠结用YOLOv11还是YOLOv12不如先把数据集洗干净。第三个问题比较特殊——夜间场景。白天训练的模型放在晚上测试误报率明显上升。路灯、车灯、红色广告牌都会让模型产生疑似火焰的判断。这个问题的本质是训练数据中夜间火焰和夜间干扰物的样本不够。我的处理方式是单独采集了一批夜间场景包括路灯、车灯、红色霓虹灯、篝火、燃烧的纸箱等然后在数据集中把夜间样本比例提到三成左右重新训练后夜间误报率下降了大概一半。这个经验对于做安防类检测项目基本通用——你的应用场景光线环境越复杂数据的光线多样性就要越丰富。4.3 评估指标与坏例分析训练完成后我习惯上看三样东西PR曲线、混淆矩阵、还有验证集抽样可视化结果。PR曲线能看出置信度阈值应该设在哪混淆矩阵能看出fire和smoke之间是否存在互相误判可视化结果则能直接暴露模型学到的特征有没有问题。火焰烟雾检测项目里最常见的坏例就两种一是把烟雾中透出的橙色误判成火焰二是把白色墙面反光或雾气误判成烟雾。这两种情况单看指标很难发现只有把检测结果画出来一张一张看才看得清。针对这类坏例我有两个实操建议第一训练完成后导出验证集里所有预测结果图以网格形式拼成一张大图花十分钟整体扫一遍第二把置信度阈值调低到0.25运行一次检测看看低置信度条件下模型都在关注什么。如果低置信度的检测框乱七八糟说明模型对什么是火焰/烟雾的边界学得不够清晰要么补数据要么调数据增强里的色彩扰动参数。这比盯着loss曲线猜测要直观得多。5. 用Django把模型变成Web演示系统架构与联调细节5.1 模型服务器与Web应用的分工设计模型训练好之后下一步就是让它变成能演示的系统。我用Django做后端Web框架同时把模型推理也放在Django服务里通过一个单独的推理模块来管理。这里有一个架构上值得注意的点生产环境里通常会把模型推理单独拆成一个服务Web端通过HTTP或者消息队列调用但我这边考虑到项目定位是演示系统追求的是部署简单、演示顺畅所以把推理服务直接集成进Django进程省掉一层通信开销也少一个需要维护的服务进程。如果你后续要接多个摄像头高并发检测那再拆成独立推理服务不迟先跑通最重要。接口层面我设计了四个图片检测接口、视频检测接口、摄像头流检测接口和检测记录查询接口。图片检测的逻辑最直接用户上传图片后Django接收文件调推理模块的detect方法返回带标注框的Base64图片和JSON结果。视频检测麻烦一点需要先把上传的视频保存到临时目录然后用OpenCV逐帧读取、逐帧推理、把结果帧编码成新的视频文件整个过程因为是同步的视频稍微长一点轮询等待时间就比较久。我做了一个简单的任务状态轮询上传视频后立刻返回一个任务ID前端每隔两秒查询一次任务状态完成后再拿结果地址去展示。5.2 摄像头实时检测的推流实现思路实时摄像头检测是我个人觉得这套系统最出效果的部分也是Django里最繁琐的部分。OpenCV从RTSP地址取流、逐帧推理再把帧推给前端如果直接按常规思路把每一帧都通过HTTP传给前端帧率根本上不去。我采用的方案是后端用后台线程持续抓取RTSP流推理后的帧写入一个队列同时通过Django的StreamingHttpResponse把MJPEG格式的视频流响应给前端页面前端再用img标签直接渲染这个视频流地址。这个方案的好处是浏览器不需要装任何插件原生支持MJPEG显示坏处是MJPEG的码流比较大局域网里演示基本没问题公网就需要做转码压缩。摄像头解码这块有个实用细节OpenCV在连接RTSP流的时候如果摄像头分辨率过高解码耗时非常明显。我在接入前先把rtsp传输协议切换为TCP并且把分辨率控制在1080P以内再配合推理线程和显示线程分离实测延迟大概在两到三秒之间。这个延迟对火焰烟雾预警场景来说是能接受的因为火灾预警本身不具备毫秒级竞赛的性质反应快慢主要取决于事后处置流程而不是检测算法本身。5.3 前端演示页面的交互设计演示页面的前端我做得尽量简洁核心诉求就是外行也能一眼看懂。页面主要有三个区域左侧是视频流或图片展示区右侧是实时检测结果列表底部是统计面板。检测结果列表展示每条检测到的目标框、类别、置信度和时间戳。统计面板展示当前帧总共检测到几个火焰目标、几个烟雾目标以及最近一分钟内的检测趋势。这里有一个交互细节我认为做得比较到位当模型检测到火焰或者烟雾时页面顶部会出现一个全宽横幅用红色背景显示检测到火焰/烟雾预警同时发出蜂鸣声。不要小看这个简单的设计在给别人做演示的时候这个视觉听觉同时触发的瞬间非常抓眼球比单纯画几个框在说明问题上要直观得多。如果需要在真实预警场景使用可以把横幅替换成推送通知、短信告警或者联动第三方报警平台。前端和后端通过普通的AJAX调用交互图片检测用表单上传视频检测用文件上传加轮询摄像头流直接挂在img标签上。整体技术含量不高但足够支撑一套完整演示链路。如果你前端基础比较薄弱直接用Django模板语法渲染页面也能达到同样的效果不需要额外引入前端框架。6. 系统实测表现与上线后的常见坑6.1 真实场景下的检测效果整个系统联调完成后我在室外场地做了一次比较完整的实测。测试场景分了四类白天纸张燃烧、白天木柴燃烧、夜间纸张燃烧、白天烟饼烟雾释放。检测设备是一台普通的网络摄像头检测端是带GPU的服务器。实际效果摘要如下场景火焰检测情况烟雾检测情况备注白天纸张燃烧点火后1-2秒内出框烟雾出现后2秒内出框效果最好小火焰也能捕捉白天木柴燃烧稳定检测稳定检测火焰较大后偶尔出现重复框夜间纸张燃烧检测准确但有路灯误报烟雾清晰时检测稳定距路灯较近时需调阈值白天烟饼烟雾无火焰误判薄烟雾也能检测到白墙背景下偶发误报白天的效果整体让人满意火焰在点火初期就能检测出来。夜间场景需要额外调高置信度阈值来压制车灯和路灯的误报但调高后小火焰的召回率会稍微下降这个取舍在部署前就要想清楚。烟雾检测比火焰检测更容易受到环境干扰凉爽天气里地面上的水蒸气、空调外机的白雾都可能被识别为烟雾——这个场景我用烟饼做测试时发现模型对白色半透明片状物的敏感度天然就高想彻底消除误报几乎不可能只能尽量把阈值调到对真实火灾敏感度最高的位置。6.2 联调过程中踩过的三个典型坑第一个坑是OpenCV的BGR和RGB通道顺序问题。模型训练时图像是RGB顺序输入但OpenCV读取图像默认是BGR顺序我用图片检测接口做测试时全部正常换成Django内嵌的摄像头流检测时检测结果变得非常混乱火焰的置信度大幅下降。排查了半天才发现推理前少了一步颜色空间转换。这个问题非常隐蔽尤其在系统联调阶段建议在推理模块里统一封装预处理函数把颜色转换、缩放、归一化都固定在一个函数里不要散落在不同的代码位置。第二个坑是视频检测接口的临时文件清理。最初实现视频检测时处理完的视频直接放在临时目录没有清理机制演示了一上午之后服务器磁盘就满了。后来我加了一个定时清理任务每次启动新任务时自动删除超过一小时的临时文件。别觉得这种细节不重要演示系统在会场连续跑一天之后磁盘空间耗尽导致Django直接拒绝服务可比模型误报尴尬多了。第三个坑是模型的加载时机。如果你在Django的视图函数里每次调用都加载一次模型文件图片检测还能忍视频检测和摄像头流检测的首次推理速度会慢到让人怀疑人生。我的做法是在Django应用启动时就把模型加载进内存用一个全局变量持有模型对象所有请求复用同一个实例。这个方法要注意多线程推理时模型推理可能不是线程安全的我加了锁保护实测下来虽然牺牲了一点点并发能力但换来了稳定性。6.3 置信度阈值和NMS参数的最后调优最后一个要谈的参数是置信度阈值和NMS。YOLO模型默认的置信度阈值是0.25NMS阈值是0.45在演示场景下我发现火焰和烟雾的检测结果经常出现同一个目标被重复框两次的情况——尤其是火焰较大时模型会同时输出多个小框。我用了NMS合并之后情况好了一些但火焰的重复框依然偶发后来把NMS的IoU阈值从0.45调低到0.35重复框问题基本消失。置信度阈值我在配置面板里做成可调参数方便在演示现场针对不同光线条件快速切换。白天建议0.3夜间建议0.45严格模式可以设到0.6。这样做的原因是白天光线充足目标特征清晰低阈值能提高检出率夜间干扰光多宁可牺牲部分小火焰的检出也要保证不频繁误报。把阈值做成配置项还有一个好处就是来参观的人问参数可不可以调时直接当场调给他们看展示效果远比口头解释要好。我在实际使用中最深的体会是模型训练完成那一刻只是项目的一半后面Web系统联调、阈值调优、坑问题排查花费的时间一点都不比训练少。做这类模型Web演示的项目一定要把训练和系统集成当成两条线同时推进不要等模型训练到完美才开始写Django代码。像我一开始就是先跑通一个初版模型的推理接口Django页面先能显示检测框后面再慢慢替换成更优模型整个项目节奏顺了很多。希望这篇文章能帮你把这条链路走得更顺少踩几个我已经踩平的坑。
去年年中我接了一个跟火焰烟雾检测相关的视觉项目需求平台方要求把检测能力做成一个可演示、可二次开发的Web系统模型部分希望覆盖YOLOv5到最新的几个版本方便后续对比选型。折腾了大概一个多月我把基于深度学习的火焰烟雾检测方案完整跑通从数据集整理、模型训练到Django Web展示全部打通。这篇文章就把这个过程拆开讲清楚包括选型逻辑、训练参数、Web部署细节和实测翻车记录给准备做类似项目的同学一份可以直接参考的实操笔记。整个系统听上去很多件套在一起——又是YOLOv12/v11/v8/v5又是Django又是Web又是数据集实际上拆开看核心就只有三件事模型能不能检测准、Web端能不能展示流畅、训练集够不够支撑场景落地。只要这三条线理清楚项目进度基本就不会卡壳。1. 火焰烟雾检测到底解决了什么问题——从真实场景说起1.1 为什么传统传感器在开阔场景下不够用很多不了解这个领域的人会问消防不是已经有烟感、温感报警器了吗为什么还要用摄像头做火焰烟雾检测这里有个很关键的实际问题——传统传感器适合密闭空间和近距离场景比如室内天花板、楼道、配电间但遇到仓库中庭、室外堆场、森林防火这类开阔场景烟感和温感就力不从心了。烟雾要飘到传感器附近才会触发报警火焰如果发生在几十米外等传感器感知到火势很可能已经蔓延了。视频火焰烟雾检测恰好补上了这个盲区。摄像头看得远、覆盖面积大、响应时间短能在火焰出现后的几秒到十几秒内就给出预警。加上现在的摄像头本来就是安防系统的标配不需要额外增加硬件成本只需要在已有的视频流上叠加一层智能分析能力。这也是我把这套系统定位成基于深度学习的火焰烟雾检测系统而不是简单做一个烧CPU的演示Demo的原因它的使用场景是真实环境中的异常预警。1.2 这个项目的目标形态和适合谁来参考我当时给项目定了三个目标。第一是模型层面要能对火焰和烟雾两类目标分别检测输出类别、置信度和边界框第二是系统层面要支持上传图片检测、上传视频检测最好还能接RTSP摄像头流做实时检测第三是演示层面要有Web界面让不懂深度学习的人也能直接打开浏览器上传一张图就看到检测结果。这套东西适合谁参考两类人最合适一类是想用YOLO系列做工业级视觉检测但还没想清楚技术路线的开发者另一类是接了安防、消防预警相关项目需要快速出演示效果的团队。如果你是学生做课程设计或者个人作品集这套方案同样合适因为模型训练和Web端展示是两条独立线路可以只选其中一条来做。我在做的时候就是先跑通模型训练再用Django把模型包起来变成可视化页面整个过程没有用到特别冷门的技术全部是日常开发就能覆盖的东西。2. YOLO系列模型选型从v5到v12为什么我最终这样搭配2.1 四个版本的真实差异和定位项目标题里提到的YOLOv5、YOLOv8、YOLOv11、YOLOv12很多人会纠结选哪个其实这四个版本不是替代关系而是思路上的迭代关系理解它们的差异比单纯看精度数字更重要。下面这个表格是我根据自己的使用体验整理的不是纯理论分析更偏实战视角版本发布时间段核心特点实战优势需要留意的点YOLOv52020年前后工程化最成熟社区资料极多环境兼容性最好部署资料多到搜不完检测头结构相对旧小目标能力一般YOLOv82023年前后C2f结构Anchor Free训练生态完善训练稳定mAP均衡导出部署格式全模型体量比v5大CPU推理稍慢YOLOv112024年前后在v8基础上做了骨干和颈部优化计算效率提升同等算力下精度更好新特性依赖较新版本环境YOLOv12最近的新版本引入了注意力机制改造潜力大在小目标和复杂背景场景值得试生态还在完善遇到问题参考资料少实际选型的时候不能只看精度榜单。YOLOv5强在稳YOLOv8强在均衡YOLOv11和v12强在新机制带来的想象空间。火焰烟雾检测这个场景有一个特点——白天和夜晚的光线差异极大烟雾是半透明目标火焰则在暗光下很亮对小目标的精度要求不低。所以我最后采用的方案不是只选一个版本跑到底而是做对比实验用同一个数据集分别在v8和v11上训练看谁的效果更适合当前场景同时用v5做一次基准测试v12用来验证新机制在烟雾检测上的表现。这样项目的结论会更有说服力也能避免只用某个版本但说不清为什么选它的尴尬。2.2 我最终确定的模型组合方案说了这么多我的实际落地组合是主训练模型用YOLOv8n和YOLOv8s一个轻量一个均衡配合YOLOv11做精度对比YOLOv5和v12作为参考模型跑同一条数据链路。这样的好处是如果演示的时候观众问为什么不用最新的YOLOv12我可以直接拿出对比数据说因为v8在当前数据集上精度接近且推理速度更稳定而不是被问住。还有一个关键点Web演示系统的模型不需要追求大。很多人觉得效果不好就上大模型实际上在火焰烟雾系统里yolov8n的模型文件大约二十兆级别在普通GPU上推理一帧只要几十毫秒在小目标检测上的表现足够应对演示需求。真正影响精度的不是模型大小而是数据集质量。这一点我在后面专门展开讲。如果你本身算力有限我的建议是先用YOLOv8n跑通全流程确认数据没问题再换大模型不要一上来就训练yolov8x浪费时间不说调参难度也大。3. 数据集准备与标注细节效果好坏的第一道分水岭3.1 数据来源与实际采集的取舍做火焰烟雾检测的第一个坑就是数据。火焰烟雾不是常规物体网络上能直接下载的公开数据质量参差不齐所以我采用公开来源自采自标两条腿走路的策略。整体数据规模最终控制在八千张左右其中大约六成来自筛选整理过的公开图片四成来自自己拍摄和视频抽帧。自采部分我是这么做的找了一块室外空地用铁桶点燃纸张、木柴分别用手机和摄像头在不同距离、不同角度、不同光照条件下拍摄火焰和烟雾烟雾部分除了燃烧产生的烟雾还单独用烟饼制造了浓烟、薄烟、白烟、灰烟等情况。这里有一个容易被忽略的知识点——火焰烟雾检测系统里面烟雾比火焰难检得多。火焰有明确的颜色和轮廓烟雾却是半透明的、边缘模糊的不同背景下的表现差异很大所以在采集数据的时候烟雾样本的多样性一定要比火焰样本更丰富。视频抽帧也是很好的数据补充方式。我从自己录制的大约四十段视频里按每秒一帧的频率抽取图像再用脚本做初步清洗删掉虚焦、过曝、目标占比过小的图片留下来的才是能进标注流程的有效数据。一段五秒钟的视频大概能抽出一百多帧去掉重复和模糊的真正能用的也就不到一半。3.2 标注规范与容易出错的细节数据集准备绕不开标注。我用的是LabelImg这类常见的矩形框标注工具虽然界面朴素但对目标检测项目够用。火焰烟雾检测在标注的时候有几个非常关键的细节我踩过坑之后总结成了规则第一火焰和烟雾同时出现在一张图中就分别标成两个框不要合并。火焰区域标fire烟雾区域标smoke。第二如果火焰被烟雾完全遮挡只标注可见的火焰部分不要凭经验框出看不到的区域。第三烟雾标注框尽量贴合肉眼可见的轮廓烟雾扩散很广的情况下宁可框得保守一点也别把大量背景框进去——背景内容太多会让模型学到的特征不纯。第四条是我的血泪教训不要小看远距离小目标。火焰在五十米外可能只有十几个像素这种小目标恰恰是监控场景最常见的形态标注的时候哪怕只有十几个像素的橙色区域也要认认真真框出来。如果嫌麻烦把这些小目标全删了模型训练出来的结果在真实场景中基本失效。标注完成之后一定要做一次遍历复查把所有框调出来过一遍看看有没有框错类别的、有没有漏框的。我在第一次标注时因为赶时间大概有几十张图的烟雾框画得太随意后来训练出来的模型对烟雾的召回率明显偏低于火焰查了两轮才发现是这个原因。3.3 数据增强策略和训练集划分数据增强我的做法比较克制没上特别复杂的方案。颜色抖动对烟雾检测有帮助因为烟雾在不同光线下的颜色变化比较大随机旋转和左右翻转可以增加样本多样性马赛克增强是YOLO系列自带的能力我保留了默认设置。没有用太多的模糊和噪声增强因为会拉低真实场景的泛化能力。划分上我按7:2:1做了训练集、验证集和测试集并且保证测试集里的场景和训练集不完全重合——比如说视频抽帧的某些连续帧我不会让相似帧分别出现在两个集合里防止看起来精度很高实际是数据泄漏。这个划分在小项目里特别容易被忽略很多人直接随机切分结果训练集和测试集有大量几乎一样的图验证指标虚高一到新场景就暴露问题。4. 模型训练与调参实战从过拟合到稳定收敛4.1 训练环境与基线参数我训练用的机器配置是单张消费级GPU显存24GPyTorch环境CUDA版本跟随PyTorch官网推荐。就这个配置来说跑YOLOv8n在两千多张图像的数据集上一个epoch大约几十秒训练一百个epoch大概一个多小时完全在可接受范围内。训练超参数的基线我是这么设置的参数设置值说明img_size640YOLO系列默认兼顾小目标和速度batch_size1624G显存下比较稳妥显存小就调到8epochs120提前开了早停没跑满optimizerAdamW火焰烟雾数据集上用AdamW收敛比SGD平稳lr00.001初始学习率避免起步发散早停耐心值20连续20轮没提升就停这里我多说一句学习率的问题。很多人喜欢上来就改学习率其实YOLO系列的默认学习率调度策略已经比较成熟除非数据集特别小或者特别大不然用默认值就够。我试过把学习率调到0.01结果前十个epoch损失一直在震荡后面老老实实调回0.001才稳定下来。如果你的训练集只有几百张图batch_size再小一点学习率也可以相应降一点这是小数据集上防止过拟合的有效手段。4.2 训练过程中我遇到的最典型问题训练过程中的第一个问题就是早期过拟合。模型在训练集上loss降得很快到验证集上却一直不降这在我第一次用纯自采数据训练的时候特别明显。原因也很直接——自采数据里大量的相似角度、相似背景模型很容易把背景当成特征来记忆。解决方法是先减少数据增强里的随机参数范围再加大验证集的数据多样性同时把早停耐心值从10提高到20给模型更多震荡收敛的机会。这里有个反直觉的点很多人以为过拟合就拼命加正则化其实先查数据多样性往往比调正则项更有效。第二个问题是烟雾类别召回率低。刚训练完的时候火焰检测的mAP已经到了0.85以上烟雾却只有0.6左右这就是我前面说的标注问题。后来我重新复查了烟雾标注框把那些框得过大、包含了太多背景的样本全部重新调整又补充了一批薄烟雾和远处小烟雾的图片再训练之后烟雾mAP拉到了接近0.8。所以说数据质量真的比模型版本更关键与其纠结用YOLOv11还是YOLOv12不如先把数据集洗干净。第三个问题比较特殊——夜间场景。白天训练的模型放在晚上测试误报率明显上升。路灯、车灯、红色广告牌都会让模型产生疑似火焰的判断。这个问题的本质是训练数据中夜间火焰和夜间干扰物的样本不够。我的处理方式是单独采集了一批夜间场景包括路灯、车灯、红色霓虹灯、篝火、燃烧的纸箱等然后在数据集中把夜间样本比例提到三成左右重新训练后夜间误报率下降了大概一半。这个经验对于做安防类检测项目基本通用——你的应用场景光线环境越复杂数据的光线多样性就要越丰富。4.3 评估指标与坏例分析训练完成后我习惯上看三样东西PR曲线、混淆矩阵、还有验证集抽样可视化结果。PR曲线能看出置信度阈值应该设在哪混淆矩阵能看出fire和smoke之间是否存在互相误判可视化结果则能直接暴露模型学到的特征有没有问题。火焰烟雾检测项目里最常见的坏例就两种一是把烟雾中透出的橙色误判成火焰二是把白色墙面反光或雾气误判成烟雾。这两种情况单看指标很难发现只有把检测结果画出来一张一张看才看得清。针对这类坏例我有两个实操建议第一训练完成后导出验证集里所有预测结果图以网格形式拼成一张大图花十分钟整体扫一遍第二把置信度阈值调低到0.25运行一次检测看看低置信度条件下模型都在关注什么。如果低置信度的检测框乱七八糟说明模型对什么是火焰/烟雾的边界学得不够清晰要么补数据要么调数据增强里的色彩扰动参数。这比盯着loss曲线猜测要直观得多。5. 用Django把模型变成Web演示系统架构与联调细节5.1 模型服务器与Web应用的分工设计模型训练好之后下一步就是让它变成能演示的系统。我用Django做后端Web框架同时把模型推理也放在Django服务里通过一个单独的推理模块来管理。这里有一个架构上值得注意的点生产环境里通常会把模型推理单独拆成一个服务Web端通过HTTP或者消息队列调用但我这边考虑到项目定位是演示系统追求的是部署简单、演示顺畅所以把推理服务直接集成进Django进程省掉一层通信开销也少一个需要维护的服务进程。如果你后续要接多个摄像头高并发检测那再拆成独立推理服务不迟先跑通最重要。接口层面我设计了四个图片检测接口、视频检测接口、摄像头流检测接口和检测记录查询接口。图片检测的逻辑最直接用户上传图片后Django接收文件调推理模块的detect方法返回带标注框的Base64图片和JSON结果。视频检测麻烦一点需要先把上传的视频保存到临时目录然后用OpenCV逐帧读取、逐帧推理、把结果帧编码成新的视频文件整个过程因为是同步的视频稍微长一点轮询等待时间就比较久。我做了一个简单的任务状态轮询上传视频后立刻返回一个任务ID前端每隔两秒查询一次任务状态完成后再拿结果地址去展示。5.2 摄像头实时检测的推流实现思路实时摄像头检测是我个人觉得这套系统最出效果的部分也是Django里最繁琐的部分。OpenCV从RTSP地址取流、逐帧推理再把帧推给前端如果直接按常规思路把每一帧都通过HTTP传给前端帧率根本上不去。我采用的方案是后端用后台线程持续抓取RTSP流推理后的帧写入一个队列同时通过Django的StreamingHttpResponse把MJPEG格式的视频流响应给前端页面前端再用img标签直接渲染这个视频流地址。这个方案的好处是浏览器不需要装任何插件原生支持MJPEG显示坏处是MJPEG的码流比较大局域网里演示基本没问题公网就需要做转码压缩。摄像头解码这块有个实用细节OpenCV在连接RTSP流的时候如果摄像头分辨率过高解码耗时非常明显。我在接入前先把rtsp传输协议切换为TCP并且把分辨率控制在1080P以内再配合推理线程和显示线程分离实测延迟大概在两到三秒之间。这个延迟对火焰烟雾预警场景来说是能接受的因为火灾预警本身不具备毫秒级竞赛的性质反应快慢主要取决于事后处置流程而不是检测算法本身。5.3 前端演示页面的交互设计演示页面的前端我做得尽量简洁核心诉求就是外行也能一眼看懂。页面主要有三个区域左侧是视频流或图片展示区右侧是实时检测结果列表底部是统计面板。检测结果列表展示每条检测到的目标框、类别、置信度和时间戳。统计面板展示当前帧总共检测到几个火焰目标、几个烟雾目标以及最近一分钟内的检测趋势。这里有一个交互细节我认为做得比较到位当模型检测到火焰或者烟雾时页面顶部会出现一个全宽横幅用红色背景显示检测到火焰/烟雾预警同时发出蜂鸣声。不要小看这个简单的设计在给别人做演示的时候这个视觉听觉同时触发的瞬间非常抓眼球比单纯画几个框在说明问题上要直观得多。如果需要在真实预警场景使用可以把横幅替换成推送通知、短信告警或者联动第三方报警平台。前端和后端通过普通的AJAX调用交互图片检测用表单上传视频检测用文件上传加轮询摄像头流直接挂在img标签上。整体技术含量不高但足够支撑一套完整演示链路。如果你前端基础比较薄弱直接用Django模板语法渲染页面也能达到同样的效果不需要额外引入前端框架。6. 系统实测表现与上线后的常见坑6.1 真实场景下的检测效果整个系统联调完成后我在室外场地做了一次比较完整的实测。测试场景分了四类白天纸张燃烧、白天木柴燃烧、夜间纸张燃烧、白天烟饼烟雾释放。检测设备是一台普通的网络摄像头检测端是带GPU的服务器。实际效果摘要如下场景火焰检测情况烟雾检测情况备注白天纸张燃烧点火后1-2秒内出框烟雾出现后2秒内出框效果最好小火焰也能捕捉白天木柴燃烧稳定检测稳定检测火焰较大后偶尔出现重复框夜间纸张燃烧检测准确但有路灯误报烟雾清晰时检测稳定距路灯较近时需调阈值白天烟饼烟雾无火焰误判薄烟雾也能检测到白墙背景下偶发误报白天的效果整体让人满意火焰在点火初期就能检测出来。夜间场景需要额外调高置信度阈值来压制车灯和路灯的误报但调高后小火焰的召回率会稍微下降这个取舍在部署前就要想清楚。烟雾检测比火焰检测更容易受到环境干扰凉爽天气里地面上的水蒸气、空调外机的白雾都可能被识别为烟雾——这个场景我用烟饼做测试时发现模型对白色半透明片状物的敏感度天然就高想彻底消除误报几乎不可能只能尽量把阈值调到对真实火灾敏感度最高的位置。6.2 联调过程中踩过的三个典型坑第一个坑是OpenCV的BGR和RGB通道顺序问题。模型训练时图像是RGB顺序输入但OpenCV读取图像默认是BGR顺序我用图片检测接口做测试时全部正常换成Django内嵌的摄像头流检测时检测结果变得非常混乱火焰的置信度大幅下降。排查了半天才发现推理前少了一步颜色空间转换。这个问题非常隐蔽尤其在系统联调阶段建议在推理模块里统一封装预处理函数把颜色转换、缩放、归一化都固定在一个函数里不要散落在不同的代码位置。第二个坑是视频检测接口的临时文件清理。最初实现视频检测时处理完的视频直接放在临时目录没有清理机制演示了一上午之后服务器磁盘就满了。后来我加了一个定时清理任务每次启动新任务时自动删除超过一小时的临时文件。别觉得这种细节不重要演示系统在会场连续跑一天之后磁盘空间耗尽导致Django直接拒绝服务可比模型误报尴尬多了。第三个坑是模型的加载时机。如果你在Django的视图函数里每次调用都加载一次模型文件图片检测还能忍视频检测和摄像头流检测的首次推理速度会慢到让人怀疑人生。我的做法是在Django应用启动时就把模型加载进内存用一个全局变量持有模型对象所有请求复用同一个实例。这个方法要注意多线程推理时模型推理可能不是线程安全的我加了锁保护实测下来虽然牺牲了一点点并发能力但换来了稳定性。6.3 置信度阈值和NMS参数的最后调优最后一个要谈的参数是置信度阈值和NMS。YOLO模型默认的置信度阈值是0.25NMS阈值是0.45在演示场景下我发现火焰和烟雾的检测结果经常出现同一个目标被重复框两次的情况——尤其是火焰较大时模型会同时输出多个小框。我用了NMS合并之后情况好了一些但火焰的重复框依然偶发后来把NMS的IoU阈值从0.45调低到0.35重复框问题基本消失。置信度阈值我在配置面板里做成可调参数方便在演示现场针对不同光线条件快速切换。白天建议0.3夜间建议0.45严格模式可以设到0.6。这样做的原因是白天光线充足目标特征清晰低阈值能提高检出率夜间干扰光多宁可牺牲部分小火焰的检出也要保证不频繁误报。把阈值做成配置项还有一个好处就是来参观的人问参数可不可以调时直接当场调给他们看展示效果远比口头解释要好。我在实际使用中最深的体会是模型训练完成那一刻只是项目的一半后面Web系统联调、阈值调优、坑问题排查花费的时间一点都不比训练少。做这类模型Web演示的项目一定要把训练和系统集成当成两条线同时推进不要等模型训练到完美才开始写Django代码。像我一开始就是先跑通一个初版模型的推理接口Django页面先能显示检测框后面再慢慢替换成更优模型整个项目节奏顺了很多。希望这篇文章能帮你把这条链路走得更顺少踩几个我已经踩平的坑。
