我在做某消防预警项目时一开始用的传统烟雾传感器方案误报率和漏报率都让人头疼厨房水蒸气会误报、阴燃初期没有明显颗粒物又会漏报。后来把方案整个换成视觉检测基于深度学习的YOLOPySide6做了一套火灾火焰检测识别系统用YOLOv8、YOLOv5分别训练了火灾烟雾火焰数据集再配合SQLite做事件记录整体可靠性一下子提升了不少。这篇就把这套系统的完整搭建过程、踩坑记录和调优经验拆开来讲给正在做类似项目的朋友一个可以直接参考的路径。1. 为什么火焰检测系统要用YOLO PySide6这种组合很多人提起火灾检测第一反应是用红外温度传感器或者烟雾探测器但实际部署过就会明白传感器方案在开阔空间、户外场景、大厂房里部署密度要求高而且反应链路过长。视觉方案的思路完全不同用摄像头采集画面让深度学习模型直接识别画面里的火焰和烟雾特征响应速度快还能保留现场图像作为证据。1.1 目标检测模型为什么选YOLO火灾火焰检测本质上是一个目标检测任务需要在画面里框出火焰或烟雾的位置。目前主流的目标检测框架有YOLO、SSD、Faster R-CNN等我最终选了YOLO系列核心原因有三点。第一是速度。火焰检测场景很多时候需要接入多路摄像头实时分析每路视频都要保持实时推理速度Faster R-CNN这类两阶段检测器精度虽然好但单张图片推理速度在CPU/低端GPU上很难达到实时。而YOLO作为单阶段检测器把目标检测当成回归问题一步到位在GPU上处理640x640输入通常能做到几十毫秒级别。第二是工程生态。YOLOv5和YOLOv8都有非常成熟的代码仓库训练、验证、导出、部署的链路是完整的对新手很友好。更重要的是模型导出方便可以导出成ONNX格式再通过OpenCV或者ONNX Runtime加载不依赖原始训练框架也能跑推理这个特性在做桌面应用时特别关键。第三是火焰检测本身的需求。火焰的特征是颜色、纹理、形状在变化没有固定姿态但胜在边缘和颜色特征相对明显。YOLO这种基于CNN的特征提取方式对这类非刚性目标的学习能力足够用。做个对比就清楚了对比项YOLO系列SSDFaster R-CNN推理速度快实时较快慢精度上限中上够用中高工程生态极成熟一般一般部署便捷度高ONNX/TensorRT中低适合场景实时视频分析移动端轻量离线高精度从实际项目角度看YOLO是最稳的选择。1.2 PySide6和SQLite在系统里承担的角色选型模型只是眼睛整套系统还需要手脚要有一个界面让人去看实时画面和检测结果要把报警记录存下来备查。PySide6和SQLite就是干这个的。PySide6是Qt的Python绑定版本做桌面视觉应用比Tkinter、PyQt5更合适。它自带OpenCV视频帧显示用的QImage转换接口绘图事件系统也能用来画检测框还有QThread线程机制解决视频采集卡UI这个经典问题。用PySide6做视觉应用界面代码写起来比纯OpenCV HighGUI优雅得多也比Electron那一套轻量太多。SQLite在这里不是主角但作用不可替代。检测系统跑起来之后每次报警、每帧检测结果、每个截图都需要落盘存储。如果用MySQL这类独立数据库部署时要多装一个数据库服务对桌面工具型项目来说太重了。SQLite是嵌入式数据库整个数据库就是单个文件Python标准库sqlite3直接操作做单机版视觉检测系统的数据层非常合适。所以这个组合的核心思想是YOLO负责看PySide6负责呈现与交互SQLite负责记忆三者各司其职。2. 火灾烟雾火焰数据集准备、清理与标注的经验标题里提到深度学习框架训练火灾烟雾火焰数据集这话说起来轻巧做起来最费时间。一个检测系统的上限其实在数据层面就决定了模型结构再强喂进去的数据脏训练出来就是近视眼。我前前后后整理了大约一万两千张图过程分三步。2.1 数据来源与初筛策略首先肯定不能只靠一类数据源。我主要从三个渠道收集公开的火灾检测数据集、视频截帧、自行拍摄的模拟场景。公开数据集方面网上有几个常见的火灾检测数据集但质量参差不齐有的分辨率极低有的标注框画得歪歪扭扭。使用前我建议把每一张图过一遍重点筛掉三类问题完全不清晰的缩略图、标注框明显偏离目标的图、以及负样本里藏着没标注的火焰的图。第一遍筛选我花了大约两天筛掉了近两成低质量数据说不心疼是假的但这一步直接决定了后面训练是否浪费算力。视频截帧是个效率很高的扩展数据方式。找一些火灾现场视频、消防演习视频用OpenCV脚本每隔几帧抽一张图。视频截帧有个好处是能拿到连续的中间态——火焰从燃起到蔓延的各个阶段这对模型学习火势变化很有帮助。坏处是相邻帧画面高度相似会造成数据冗余所以抽帧间隔不能太短我一般每隔15到20帧抽一张。自行拍摄模拟场景也很必要。我们找空旷场地用铁桶烧了几次可控的小型火源把不同光线条件白天强光、黄昏、夜间下的火焰拍下来再配合干冰机模拟烟雾效果。这部分数据占比不高大概一千多张但都是真实环境下的画面对模型泛化能力帮助很大。2.2 标注策略火焰和烟雾分开还是合并标注环节是决策点最多的地方。火焰和烟雾这两类目标分开标注还是统一标成fire/smoke一个类不同项目有不同做法。我用的是四个类fire、smoke然后把小规模初期火焰单独分一个类别避免和常规火焰混淆。有人觉得类越多越难训但我的实测结果是初期火焰单独一类能让模型在预警阶段更敏感这对消防场景意义重大——大部分火灾在初期发现才有扑救价值。标注工具用的LabelImg和X-AnyLabeling两种。LabelImg是老牌工具但画起来效率一般。X-AnyLabeling支持交互式标注还带SAM模型辅助分割再转矩形框效率提高不少。标注的时候有几个经验火焰的框要稍微包含一点周围的空气失真区域不需要紧紧贴着火焰边缘。因为火焰边缘本身模糊框太紧了模型反而学不到边界信息。烟雾的框要覆盖完整的烟雾主体特别是浓烟和背景融为一体时宁可框大一点也不要漏掉边缘部分。烟雾是半透明的视觉特征不像火焰那么强烈标注面积太小模型很难学到全貌。遮挡严重的火焰、远距离的小火焰不要漏标这类难样本正是模型泛化能力的来源。如果所有标注都是大而清晰的火焰模型一到真实场景遇到小目标就会漏检。2.3 数据增强与类别平衡处理火灾场景有个天然特点负样本没有火焰的正常画面数量远大于正样本。训练时如果直接丢进去模型会严重偏向什么都不检出。我的处理方式对火焰、烟雾的图片做上下反转、左右翻转、随机旋转90度步进、HSV色彩抖动。使用Mosaic-4增强扩充正样本把四张图拼接到一起训练模拟多目标场景。对负样本进行欠采样把正常画面控制在总样本量的30%左右。类别平衡方面标注完成后统计各类别目标框数量我从两万多个框中看到常规火焰最多烟雾次之初期火焰最少。针对初期火焰少的短板我在增强时对它做了额外复制增强让每个batch里初期火焰的出现频次保持稳定不然模型很容易把这个类学丢了。提示数据准备阶段一定要做一次全局可视化检查代码把所有标注框画到图上并拼接成长图人眼快速扫一遍。这一步能查出不少标注错位和漏标问题。不要跳过虽然丑但比训练完再debug高效得多。3. YOLOv5与YOLOv8的训练差异参数、曲线与踩坑实录既然是标题里同时提到了YOLOv8和YOLOv5这两个版本我确实都完整训练过。v5是通用的靶场体验v8是最终部署版本。两边从训练到调参都有各自的脾气把差异和踩坑放在一起说更直观。3.1 YOLOv5训练稳定可靠适合先验证baselineYOLOv5的仓库基于yolov5代码库部署流程很成熟。我先用v5ssmall版本做了一套baseline训练输入分辨率640batch size 16预训练权重用的COCO预训练模型训练了200轮优化器AdamW配合余弦退火调度。v5给我的整体感觉是稳定、少坑。训练过程中比较舒服的一点是日志清晰每一轮的box loss、cls loss、obj loss都打印得很完整mAP曲线也直观。一个需要注意的细节v5默认的anchor配置是针对COCO通用物体设计的火焰和烟雾的宽高比分布跟常规物体差异很大——火焰常呈现竖向细长的框烟雾多是大面积横向分布。训练前建议先跑一下聚类重新生成锚框不然后期收敛会慢一些。v5训练初期的典型问题前20轮loss下降很快但到80轮之后mAP提升变缓。这时候不要急着提前停因为火焰目标的边界模糊需要更多轮次来稳定检测框回归。我在200轮基础上又加了50轮mAP50提升了将近2个百分点。3.2 YOLOv8训练C2f结构带来的精度提升和代价YOLOv8相对v5最主要的结构变化是Backbone从C3模块换成了C2f模块C2f把梯度流做了更细的分支融合网络能提取到更丰富的特征。改进还体现在Anchor-Free的检测头设计不再依赖预设锚框省去了聚类锚框这一步。用同一套数据训练后v8的精度显著优于v5尤其是在小目标火焰检测这一项mAP50从v5的0.71提高到0.79。不过v8也不是完全没代价。首先它的显存占用比v5高训练时同样的batch size 16v5大概要7GB显存v8要接近10GB。其次v8对数据噪音更敏感——C2f模块的特征融合能力强同时也意味着对标注偏差的容忍度更低。我试过同一批数据不做边界微调直接训v8的置信度分布普遍偏低排查后发现是烟雾类目标框偏大导致的。把烟雾框重新收紧之后置信度整体回升。3.3 训练过程中的经典踩坑场景夜间与暗光样本的漏检这是本项目花时间最长的一个问题。第一次完整训练结束后模型在白天场景表现不错但一到晚间和暗光环境火焰漏检率飙升。检测框要么抖动、要么干脆消失。我当时第一反应是模型问题重新调参、加大数据增强都没用。一步步排查下来根因渐渐浮出水面。训练集里夜间和暗光场景的图片占比只有百分之十五左右而且夜间图片里火焰特征与白天差异太大——白天火焰高亮且周围环境明亮夜间火焰高亮但周围环境很暗模型学到的特征模式基本失灵。排查链路总结如下统计训练集中不同光照条件的图片数量确认夜晚样本严重不足。用模型在夜间测试集上跑一遍输出检测框置信度发现夜间火焰置信度普遍低于0.3阈值一卡就全部漏掉。补充收集夜间火灾图片600余张包括城市火灾、森林火灾、野外篝火等不同夜间环境。对夜间样本做额外增强亮度随机降低、对比度提高、加入高斯噪声模拟低光摄像机成像效果。重新混合数据训练夜间检测准确率明显回升。这个坑给我的教训是视觉检测系统在真实环境里的失败绝大多数不是模型结构不够好而是训练数据没有覆盖目标场景的分布。数据层面的补齐永远比调参有效。3.4 模型选型结论到底该用v5还是v8最终系统的部署模型选择是YOLOv8s综合精度和速度考量得出v8推理速度比v5大概慢10%到15%但在现代GPU上仍然是毫秒级响应完全满足实时性要求而精度提升带来的安全收益远大于这点速度损失。v5不会闲置做对比验证和快速迭代时还会用。我的结论建议如果训练硬件允许直接上v8如果只有低端显卡或者需要CPU推理v5s/t是更稳妥的选择。4. PySide6桌面端的模型推理架构与界面设计模型训练完毕真正的工程量体现在PySide6桌面应用这一层。从零搭一套能加载模型、处理实时视频、展示结果、记录事件的桌面应用踩坑点不少。4.1 整体架构三线程模型防止界面卡死PySide6写视觉应用最大的坑是直接在UI线程里做视频帧读取和模型推理。视频帧读取是I/O密集操作模型推理是CPU/GPU密集操作两者如果都塞在主线程界面会疯狂无响应拖动窗口都卡。我的架构拆成三个线程主线程PySide6的QApplication主循环处理界面刷新和用户交互。采集线程单独QThread用OpenCV的VideoCapture读取本地视频或RTSP流通过信号把帧传给推理线程。推理线程独立QThread对收到的帧做预处理、模型推理、后处理结果通过信号传回主线程更新界面。线程之间的数据我用队列传递核心代码如下import queue import threading import cv2 import numpy as np from PySide6.QtCore import QThread, Signal class CaptureThread(QThread): frame_ready Signal(object) def __init__(self, source0): super().__init__() self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) while self.running: ret, frame cap.read() if not ret: break self.frame_ready.emit(frame) # 控制采集帧率避免无限堆积 self.msleep(30) cap.release()推理线程拿着frame_ready发来的帧调用和模型推理相关的方法完成推理把结果通过另一个信号传回主线程。实际操作中两个关键点一是帧队列一定要有上限否则采集端和推理端速度不匹配会导致内存暴涨二是界面刷新不需要每一帧都做推理结果合并成每100毫秒刷新一次即可人眼看起来足够流畅CPU占用还低。4.2 YOLOv8模型在PySide6里的加载与推理封装模型加载方式上我比较过两条路一是直接用ultralytics包一行代码YOLO(best.pt)加载权重推理也简单二是把模型导出成ONNX再用ONNX Runtime加载。两者在桌面应用里都有适用场景ultralytics方案开发速度快但打包发布时体积大首次加载也慢ONNX方案多写一些预处理代码但推理性能好、依赖少。我的最终选择是ONNX Runtime。核心步骤用ultralytics的export接口把训练好的best.pt导出成best.onnx。yolo export modelbest.pt formatonnx dynamicFalse imgsz640 opset12 simplifyTrue在PySide6应用里封装一个推理类负责输入预处理、推理、后处理。预处理和YOLO训练保持一致resize到640x640归一化到0到1之间RGB三通道顺序最后加一个batch维度。后处理稍微复杂些需要从输出张量里解析出边界框、类别、置信度再做NMS。ONNX模型输出shape是1x84x8400其中84代表4个框坐标加80个类别概率8400是不同尺度下的候选框数量。但项目里类别只有4类此时需要推断输出张量的维度需要根据实际导出情况确认import onnxruntime as ort import cv2 import numpy as np class YOLOv8ONNX: def __init__(self, onnx_path, conf_thres0.35, iou_thres0.45): self.session ort.InferenceSession(onnx_path, providers[CPUExecutionProvider]) self.conf_thres conf_thres self.iou_thres iou_thres self.input_name self.session.get_inputs()[0].name self.input_shape self.session.get_inputs()[0].shape def preprocess(self, frame): img cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) img cv2.resize(img, (640, 640), interpolationcv2.INTER_LINEAR) img img.astype(np.float32) / 255.0 img np.transpose(img, (2, 0, 1)) return np.expand_dims(img, axis0) def postprocess(self, output, orig_shape, confidence_threshold0.35): # 根据实际导出的输出格式解析候选框 predictions np.squeeze(output[0]).T boxes, scores, class_ids [], [], [] for prediction in predictions: score prediction[4:] class_id np.argmax(score) confidence score[class_id] if confidence self.conf_thres: continue x, y, w, h prediction[:4] x1 max(0, int((x - w / 2) * orig_shape[1] / 640)) y1 max(0, int((y - h / 2) * orig_shape[0] / 640)) x2 min(orig_shape[1], int((x w / 2) * orig_shape[1] / 640)) y2 min(orig_shape[0], int((y h / 2) * orig_shape[0] / 640)) boxes.append([x1, y1, x2, y2]) scores.append(confidence) class_ids.append(class_id) indices cv2.dnn.NMSBoxes(boxes, scores, self.conf_thres, self.iou_thres) results [] if len(indices) 0: for i in indices.flatten(): results.append((boxes[i], scores[i], int(class_ids[i]))) return results实际调试中发现ONNX Runtime的NMS和ultralytics内部的NMS结果略有差异主要在于iou阈值相同的重叠框谁先保留。为了让推理结果和训练时的验证结果保持一致有时需要在后处理里自己写NMS逻辑。这里我用的是OpenCV的NMSBoxes兼容性更好。4.3 界面布局设计与OpenCV画面显示PySide6界面设计遵循实时监控优先的原则主窗口布局主要分三块顶部工具栏视频源选择、开始/停止检测、模型置信度滑块、报警状态指示。中央视频显示区实时显示检测画面检测框叠加在帧上一侧留出检测信息栏显示当前帧各类别数量和置信度。底部事件表格关联SQLite数据显示最近报警记录。OpenCV的BGR帧转PySide6需要的QPixmap是很多人第一次写会遇到的知识盲区。核心是用QImage构造函数把数据格式对齐from PySide6.QtGui import QImage, QPixmap def cv2_to_qpixmap(frame): rgb_image cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch rgb_image.shape bytes_per_line ch * w q_img QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888) return QPixmap.fromImage(q_img)这个代码看起来简单但有极容易忽略的点QImage对象的data必须保持引用不能把numpy数组释放掉否则显示出来就是花屏。所以在把QPixmap传给QLabel之前最好把frame的引用保留到本次刷新周期结束或者直接复制一份安全的QImage数据。画检测框时使用QLabel的paintEvent或者直接生成带框的QImage都行。我用的是在paintEvent里画矩形的方式主要因为这样对实时帧的独立性保持得更好刷新延迟低。4.4 RTSP流接入容易出现的延迟问题项目后期接入网络摄像头用的是RTSP协议。第一个版本接上之后画面花了一两秒才显示操作延迟大到没法接受。排查后的原因主要有两个一是OpenCV的VideoCapture默认会用UDP传输RTSP在网络条件一般时丢包严重导致画面花屏和卡顿。解决办法是强制用TCP传输。可以通过调用cv2.VideoCapture.set(cv2.CAP_PROP_POSITION_MSEC, ...)的方式设置缓冲区延迟或者更常见的做法是用FFmpeg的OpenCV后端参数显式指定传输协议。二是OpenCV的缓冲队列默认会把最近几帧缓存住导致显示的永远是延迟几帧的画面。加上cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)能有效降低延迟同时配合一边读帧一边丢旧帧的策略只保留最新帧用于推理延迟就能降到可以接受的范围。5. SQLite在检测系统里的角色事件记录与数据闭环很多做视觉检测的人会忽视数据存储这一层觉得模型能出框就完事了。实际到工程现场没有事件记录的检测系统等于没有记忆火灾报警之后要调取当时画面、查看历史记录、分析报警趋势全都依赖数据库里落了哪些数据。5.1 数据表设计与写入策略数据库设计遵循简单够用原则核心就三张表detection_records每次检测到火焰或烟雾的记录存时间戳、类别、置信度、截图路径。alarm_events超过连续确认阈值后触发的报警事件存开始时间、结束时间、持续时长、处理状态。system_config系统的各类配置参数比如置信度阈值、是否启用声音报警。建表语句大致如下CREATE TABLE detection_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, source TEXT, class_name TEXT, confidence REAL, screenshot_path TEXT, frame_width INTEGER, frame_height INTEGER ); CREATE TABLE alarm_events ( id INTEGER PRIMARY KEY AUTOINCREMENT, start_time TEXT, end_time TEXT, duration_seconds INTEGER, max_confidence REAL, handle_status TEXT DEFAULT pending );写入策略上有个实际取舍。检测记录是高频写入模型每帧都可能输出结果如果把每一帧都写进SQLite数据库很快膨胀。我的做法是只记录有效的检测帧并且同一目标连续多帧出现时合并成一条只在首次出现、置信度峰值、消失时各写一条。这样既保留了完整的事件轨迹又不会让数据量失控。5.2 报警判定逻辑从单帧检出到持续确认纯单帧检测结果直接触发报警会产生大量误报特别是烟雾类目标因光影变化和背景纹理误检的情况并不少见。我的报警逻辑采用持续确认机制连续N帧内至少有M帧检出同类别目标且置信度超过设置阈值才触发报警。这套逻辑用Python实现很有意思class AlarmManager: def __init__(self, min_frames5, confirm_frames3): self.min_frames min_frames self.confirm_frames confirm_frames self.window [] self.alarm False def update(self, detected): self.window.append(detected) if len(self.window) self.min_frames: self.window.pop(0) confirmed sum(self.window) self.confirm_frames if confirmed and not self.alarm: self.alarm True elif not confirmed: self.alarm False return self.alarm这套逻辑看起来简单但实际救了很多次场。场景里有类似火焰颜色的闪烁灯光、汽车尾灯、烟囱水蒸气单帧检测分分钟误报加上持续确认之后误报率大幅下降。5.3 截图存证与历史回溯每次触发报警时系统会自动把当前帧保存成JPEG图片路径写入数据库。后续要回溯事件直接在PySide6界面的历史记录表格里右键点击记录打开对应的本地图片查看。截图存档有一点需要注意图片文件命名中必须包含时间戳和来源标识例如20250120_153045_cam01.jpg。不要只把数据存数据库而不存证据文件否则时间久了数据库还在截图文件全丢了记录就成了空壳。6. 自测与改进检测系统上线前的加固手段模型训练完成、桌面应用搭好之后项目并没有结束。从能跑到稳定可靠地跑中间还隔着一整个调试加固阶段。6.1 自建测试集与分场景评估我建了一套独立于训练集的小型测试集专门用来验收模型包含白天的正常场景、夜晚场景、强光逆光场景、室内和室外等分类。分场景评估才能真正暴露模型的短板。整体mAP看起来不错但把夜间单独拉出来测就发现明显下降。测试时不光看mAP还要统计漏检率和误检率这两个指标对消防场景更有参考价值。6.2 阈值调参与置信度校准部署阶段置信度阈值的选择是个平衡问题阈值调低了漏检少但误报多阈值调高了误报少但漏检风险上升。我用测试集跑一遍不同阈值下的系统表现画出漏检率与误报率曲线再结合现场容忍度选阈值。对于火灾检测宁可误报也不要漏报。具体到本模型的阈值最终日常运行设置是火焰类0.35烟雾类0.40。烟雾特征是半透明的置信度天然偏低因此烟雾的阈值要比火焰稍低一些就这么个微小差别对实际报警比率的影响相当可观。6.3 帧间抖动抑制与报警噪音过滤最后一个工程问题模型检测框在连续帧里会抖动同一团火焰框的位置可能在两三帧内上下晃动画在视频上看起来很不专业。解决办法是使用EMA平滑对检测框中心坐标做指数移动平均实测抖动明显改善。如果对检测框平滑有更高要求还可以引入卡尔曼滤波不过对一般的桌面监控应用EMA就够了。报警噪音过滤方面除了前面提到的持续确认还有一个实用技巧对同一目标做简单的IoU追踪判断当前帧的检测框是否和上一帧是同一目标。如果是就累加该目标的持续检出帧数如果目标消失了就清空帧数。这样能进一步过滤那些闪烁出现的虚假检测。6.4 CPU推理时的性能优化手段不是所有部署环境都有独立显卡。在纯CPU环境跑YOLOv8s模型单帧推理要几百毫秒达不到实时要求。针对这种情况我的优化方案按优先级排列把输入分辨率从640降到480或416精度损失有限速度提升明显。模型导出时启用INT8量化ONNX Runtime的CPU推理速度能提升两到三倍。可以只保留火焰检测需求把模型换成更小的YOLOv8n。用OpenVINO后端替代ONNX RuntimeIntel CPU上提速最明显。实测下来在普通笔记本CPU上YOLOv8n配合INT8量化后推理速度能跑到15到20FPS配合降低分辨率基本能支撑单路实时监控。做完整套系统最大的体会是火灾火焰检测这类安全领域目标检测项目瓶颈往往不在算法本身而在于工程化细节——数据分布是否覆盖目标场景、报警逻辑是否可靠、事件记录是否完整。模型精度99%和95%看起来差距不大但落在真实火灾场景里就是及时发现和酿成灾祸的区别。这套基于YOLOPySide6SQLite的方案整体思路适合复制到其他视觉安全检测场景按这个框架把数据集换成你自己的场景数据一套可用系统很快就能跑起来。如果后面有时间我打算在这个系统里加入行为分析分支把火焰的蔓延速度、烟雾的扩散方向也提取出来尝试做更早期的火势趋势判断。对这套系统实现过程有什么疑问或者你在做同类型项目遇到了具体问题可以聊聊一起少走弯路。