火焰烟雾检测这个场景我在工业园区、仓储物流和几处充电场站的项目里都碰过。最开始的版本用的是传统图像处理——HSV颜色阈值加运动帧差白天勉强能用一到傍晚逆光或者有红色货车经过报警声就没停过运维的兄弟直接给关了。后来切到基于深度学习的方案才算把误报率压到一个能接受的水平。这套系统说白了就三件事用YOLOv8做火焰和烟雾的目标检测用Python把训练和推理的链路串起来再用PyQt5把检测能力包成一个现场人员能直接双击运行的桌面软件。它适合刚接触目标检测想找一个完整项目练手的同学也适合手上有实际监测需求、想快速搭出原型的工程人员。我下面写的都是这套东西从零跑通时踩过的坑和验证过的做法。1. 火焰烟雾检测为什么很少有人直接套通用检测模型1.1 火焰和烟雾在像素上根本不是一个脾气先把这两类目标的物理表现拆开看因为它们决定了后面所有参数该怎么设。火焰的视觉特征很强亮度高、颜色集中在红橙黄这个区间、边缘呈不规则的齿状撕裂、位置随燃烧不断跳动。但它的问题是形态极不稳定——同样是火打火机的火苗和厂房里窜出来的火舌在图像上几乎是两个东西尺度跨度能从几十个像素到铺满半屏。烟雾则完全是另一个极端半透明、对比度低、边界模糊灰白色烟雾在阴天背景下几乎跟背景融为一体黑色烟雾在夜间的可见度也很差。更麻烦的是烟雾扩散后没有明确的物理边界你很难说清楚这块到底算不算烟。这两类目标的共性只有一个随时间变化的动态性。单帧图像上火焰可能被误判成强光源烟雾可能被误判成云或者蒸汽。传统方法依赖颜色空间阈值加运动检测加纹理特征光照一变、镜头一脏、雨雪天气一到阈值全部失效。这就是为什么这类场景必须上深度学习——模型学的是综合起来的纹理和语义模式而不是某个阈值的硬切分。1.2 传统方案、两阶段检测和 YOLOv8 的实际取舍我把当时评估过的几条路线摆在一起方便你判断自己该走哪条。方案代表做法优点真实场景下的问题传统图像处理HSV/YCbCr 阈值 帧差 LBP 纹理无需训练、算力极低夕阳、车灯、红衣服、反光全是干扰误报率高到无法使用两阶段检测Faster R-CNN FPN精度上限高小目标友好推理慢普通工控机跑不动实时视频部署链路长一阶段检测YOLO 系列、SSD速度快端到端早期版本对小烟雾目标召回不足图像分类滑窗分类网络遍历窗口实现简单窗口尺度难定框位置粗糙算力浪费严重选 YOLOv8 有几个很实在的理由。第一它是anchor-free的不需要再花时间聚类 anchor 尺寸——火焰烟雾的尺度分布太散聚出来的 anchor 也未必合理。第二它的检测头是解耦的分类和回归各走各的分支对烟雾这种分类边界模糊、定位边界也模糊的目标更友好。第三也是对我个人最关键的Ultralytics 这套工程封装把训练、验证、导出、推理全部做成了一条命令我不用再自己写 dataloader 和训练循环能把精力放在数据和后处理上。提醒一句YOLOv8 不是什么魔法。如果数据集里的烟雾标注本身前后不一致换成再新的模型也救不回来。这一点后面第 2 章会重点讲。1.3 这套系统最后要交付成什么样子一个完整的火焰烟雾检测项目拆开看是四个部分数据集、训练代码、推理引擎、图形界面。中间任何一环断了现场人员都用不起来。数据集YOLO 格式的图片加标签文件类别为 fire 和 smoke 两类训练代码包含数据配置、训练脚本、验证脚本、结果可视化推理引擎加载权重对图片、视频、摄像头流做检测输出框、类别和置信度图形界面PyQt5 做的桌面程序能选文件、能开摄像头、能调阈值、能记录报警把这四块拼起来才算一个系统只丢一个训练脚本出去那不叫交付。而绝大多数人卡住的地方不是训练是最后那块界面——因为界面涉及到多线程和图形渲染坑全在那里。2. 数据集这一关火焰烟雾样本怎么采、怎么标、怎么增强2.1 样本来源和场景覆盖的取舍数据集决定了模型的上限这句话在火焰烟雾场景里格外成立。因为真实火灾是小概率事件你不太可能像做通用检测那样从互联网上批量爬取到足够多的真实火场画面。我的做法是三路并行。一路是公开数据集网络上能搜到的火焰烟雾检测数据集不少优点是有一定规模缺点是场景单一很多是在固定摄像头下拍的模型容易过拟合到那个特定背景。二路是自己采集用手机或监控摄像头在可控条件下拍——点一小堆纸、烧一点木屑、点一支烟制造烟雾注意安全和场地许可这段素材的价值在于你能完全控制拍摄角度、光照和背景。三路是难负样本也就是长得像火或烟但其实不是的画面。第三路最容易被忽略但效果最直接。我在实际项目里收集的负样本包括傍晚的夕阳和朝霞、汽车尾灯和刹车灯、红色衣物和红色广告牌、蒸汽管道排出的水汽、清晨的雾、白云、黄色的路灯、电焊火花。这些样本不用标注直接放进训练集当背景图能显著压低误报。场景维度上要尽量铺开室内和室外、白天和夜晚、近景和远景、有遮挡和无遮挡、单目标和多目标、有风和无风。我见过一个模型在测试集上 mAP 很高拿到现场一测全是漏报原因就是训练集全是白天远景而现场摄像头是夜视红外模式。2.2 两类标签的标注规范烟雾的框该怎么画标注工具用 labelImg、X-AnyLabeling 或者 Roboflow 都行关键是输出格式要对——YOLO 格式的.txt文件每行是类别编号 中心x 中心y 宽 高全部归一化到 0 到 1 之间类别编号从 0 开始。火焰的框好画视觉边界清楚框住火体本身即可。烟雾才是真正考验人的地方。我踩过的坑是第一版数据集里有的标注员把整片稀薄烟雾都框进去了有的只框了最浓的那一团还有的干脆只框了一小部分。模型看到同一种视觉现象对应三种不同大小的框直接学懵了训练时 box_loss 怎么都降不下去。后来我们统一了一条规则写进标注手册只框视觉上能被普通人一眼认定为烟雾的主体区域忽略边缘扩散到几乎透明的部分。同时对于大面积弥漫的烟雾如果超过图像三分之一允许框到图像边缘。规则写死之后标注一致性明显改善。还有几个约定俗成的细节极小目标小于 16×16 像素的火焰或烟雾能删就删这类样本对模型是噪声被遮挡超过 70% 的目标不标因为模型学不到有效特征图像里同时有火和烟时两个框都要标不要让烟把火包含进去标注完成后一定要做一次随机抽检抽 5% 重新标一遍比对差异2.3 数据增强里最容易把模型带偏的几个操作Ultralytics 的训练配置里默认带了一整套增强参数直接用和调过之后差别很大尤其是火焰烟雾这种颜色即特征的任务。hsv_h是色调抖动默认 0.015。这个参数我建议不要调大。原因很简单火焰的核心线索之一就是颜色处于红橙黄区间如果你把色调抖动拉到 0.1一张红色的火焰可能被增强成蓝色或紫色模型就得去学一些根本不存在的模式反而削弱了颜色这个强特征。hsv_s可以适当放大到 0.7 左右模拟不同饱和度的火hsv_v放到 0.4模拟白天黑夜的亮度差。mosaic马赛克增强默认开启它把四张图拼成一张。对火焰检测有好处因为它天然制造了多尺度多目标样本。但对烟雾要小心四张图拼接时会产生明显的直线拼接缝如果训练数据里有大量这种缝模型可能把直线边缘当成烟雾的线索。我的处理是保留 mosaic但在训练最后 10 到 15 个 epoch 用close_mosaic关掉它让模型在自然图像上收敛。erasing随机擦除要慎用。它随机抠掉图像的一块区域如果正好抠在火焰或烟雾上相当于给了一个错误标注——框还在目标没了。小面积擦除问题不大面积比例别超过 0.2。还有一个实用增强是混合MixUp把两张图按比例叠在一起。它能提升模型在雾霾、低对比度场景下的鲁棒性但对火焰烟雾这种需要精确定位的任务可能导致框位置不清晰我一般把概率压得很低或者直接关掉。类别不均衡的问题几乎必然出现。真实场景里烟雾样本往往远多于火焰样本因为火灾初期先冒烟。这时候可以用copy_paste复制粘贴小目标或者在数据配置里提高火焰类别的采样权重。3. YOLOv8 训练配置与参数调试的实战记录3.1 环境搭建里最容易被版本坑到的地方环境这块版本匹配是最大的坑。我的稳定组合是 Python 3.10 PyTorch 2.x Ultralytics 8.x OpenCV 4.xCUDA 版本必须和 PyTorch 官方 wheel 对得上不然就是能 import 但一跑就报错。# 创建环境 conda create -n fire_detect python3.10 -y conda activate fire_detect # 装 PyTorch注意去官网查对应的 CUDA 版本命令 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 # 核心依赖 pip install ultralytics opencv-python PyQt5 # 验证 python -c import torch; print(torch.cuda.is_available(), torch.__version__)最后那行必须打印 True如果是 False后面训练会默认跑到 CPU 上一个 epoch 能耗你半小时。装完之后建议再跑一次yolo checks命令它会自动检查环境里各项依赖的版本兼容性比你自己一个个试快得多。另一个高频问题是cv2导入失败。绝大多数情况是 opencv-python 和 opencv-python-headless 同时装了两者冲突。解决办法是只留一个做界面项目一般留opencv-python。3.2 训练参数到底该怎么设数据配置文件data.yaml长这样path: ./datasets/fire_smoke train: images/train val: images/val test: images/test names: 0: fire 1: smoke训练命令from ultralytics import YOLO model YOLO(yolov8s.pt) model.train( datadata.yaml, epochs200, imgsz640, batch16, device0, workers8, optimizerSGD, lr00.01, lrf0.01, momentum0.937, weight_decay0.0005, warmup_epochs3, close_mosaic15, patience50, cacheTrue, )几个参数的选择理由说清楚模型规模。yolov8n 最快但小目标召回弱yolov8x 精度高但推理慢。火焰烟雾检测里烟雾经常是小目标我一般从yolov8s起步实测在普通独显上跑实时视频够用精度也比 n 版明显好。如果要用在算力受限的边缘盒子上再退回 n 版。imgsz。640 是默认值也是速度和精度的平衡点。如果场景里火焰烟雾都很远很小可以提到 960代价是显存和耗时都会涨。别盲目上 1280收益递减得很厉害。batch 和显存。这个得看你的卡。8G 显存跑 640 的 s 版batch 给 16 比较稳如果是 4G 显存降到 8 甚至 4。显存不够时最常见的报错是 CUDA out of memory除了降 batch还可以把amp打开用混合精度cache从 True 改成 False 避免把数据集全塞进内存。优化器。SGD 收敛慢但泛化好适合数据量比较大的情况。数据量小一两千张的时候我用 AdamW前期收敛快但要注意学习率别给太大lr0给 0.001 左右。patience。这是早停耐心值连续多少轮验证指标不提升就停。给 50 是个合理的数太小容易在波动中被误停。3.3 损失曲线和 mAP 曲线该怎么看训练跑起来之后runs/detect/train目录下会生成results.csv和一堆曲线图重点是这几个。box_loss反映定位精度cls_loss反映分类精度dfl_loss是分布焦点损失负责把预测的边界细化。这三条曲线要同时看训练集和验证集。训练集和验证集一起下降并趋于平缓说明学习正常训练集一直降但验证集开始上升这是过拟合要么加数据要么加增强要么减少训练轮数验证集损失震荡剧烈通常是学习率太大或者 batch 太小mAP50 是 IoU 阈值 0.5 时的平均精度mAP50-95 是 IoU 从 0.5 到 0.95 每 0.05 取一档再平均。火焰烟雾检测里由于烟雾本身边界就模糊mAP50-95 会明显低于 mAP50这是正常的别因为这个数值低就以为模型有问题。我实测下来如果 mAP50 能到 0.85 以上mAP50-95 在 0.55 左右现场效果就已经相当可用了。顺便说一句画曲线图这事。Ultralytics 自动生成的图够用但如果你要把结果放进汇报材料可以用 pandas 读results.csv自己画横轴 epoch纵轴 loss 和 mAP双 y 轴叠在一起比默认图好看得多也好解读。3.4 冻结训练在什么情况下值得用freeze参数能把主干网络的前若干层冻结只训练头部。它的价值主要在两种场景。一是小数据集微调。你的数据只有几百张从头训肯定过拟合这时候加载官方预训练权重再freeze10只让检测头学习火焰烟雾的特征收敛快且稳定。二是迁移到相近场景。比如你已经在通用火灾数据上训好了一个模型现在要适配某个特定的厂房监控画面冻结主干能防止模型把之前学到的通用特征忘掉。冻结也不是越多越好。冻结层数超过一半模型容量会明显下降遇到全新的场景类型反而不如不冻结。我的经验是freeze取 10 左右也就是冻结主干的前三分之一剩下的层还是可以微调。4. 从权重文件到能用起来导出、加速和后处理4.1 模型导出格式怎么选训练完的.pt权重直接用也能跑但推理速度不是最优。导出成其他格式能带来实打实的加速。model YOLO(runs/detect/train/weights/best.pt) # 导出 ONNX model.export(formatonnx, opset12, simplifyTrue, dynamicFalse, halfTrue) # 导出 TensorRT 引擎需要本机装好 TensorRT model.export(formatengine, halfTrue, dynamicFalse, workspace4)格式选择上我做了一张对照表帮你决策格式推理速度部署难度适用场景PyTorch .pt基准最低开发调试、Python 界面直接调用ONNX约 1.2-1.8 倍低跨平台部署Python/C 都能读TensorRT engine约 2-4 倍中有 N 卡且追求极致速度OpenVINO约 1.5-2 倍中Intel CPU 或核显平台注意halfTrue是半精度能提速省显存但极少数情况下会带来精度下降如果导出后检测结果明显变差就把这个参数关掉再试。4.2 置信度阈值和 NMS 阈值这是实际效果的分水岭后处理里两个参数直接决定你在现场能不能用。conf是置信度阈值低于它的框直接丢。默认 0.25。烟雾要调低火焰可以稍微调高。原因前面说过烟雾特征弱模型的置信度普遍偏低如果按 0.25 一刀切大量真实的烟雾框会被丢掉造成漏报。我在项目里烟雾这类一般压到 0.15 到 0.2。但代价是误报会变多尤其是薄雾、水汽这类干扰。iou是 NMS 的 IoU 阈值默认 0.7。它的作用是去掉重叠的重复框。如果同一个火焰被模型预测出三四个位置略有偏差的框阈值太高就删不干净画面上会出现一堆重叠框。这个值一般 0.45 到 0.7 之间调。我的建议是不要只靠单帧阈值硬扛做一个多帧确认机制连续 N 帧比如 5 帧在同一区域都检出目标才判定为真实报警。这个机制能把误报压下去一大截代价是报警延迟增加几百毫秒对火灾预警来说完全可接受。同时可以加一个报警面积过滤计算检出框面积占画面的比例太小的比如小于 0.1%忽略掉。远处的一个红点不该触发全楼报警。4.3 不同硬件上的实测表现和取舍我在几台机器上跑过完整的检测加界面流程大概是这么个情况。GTX 1660 Ti 这种级别的卡跑 yolov8n 在 640 分辨率下纯推理能到一百多帧算上图像预处理、画框、界面刷新完整链路大概稳定在 60 到 80 帧。换成 yolov8s完整链路大概 40 到 60 帧。yolov8m 就掉到 20 到 30 帧了。对实时监控来说25 帧以上就够用人眼看起来是流畅的。所以如果你的场景目标比较大、特征明显用 n 版完全没问题如果目标是远处的微小烟雾我建议用 s 版并把分辨率提到 960宁可帧率降到 25也不能漏。如果是往边缘设备上部署比如国产的 RK3588 这类带 NPU 的板子流程会不一样需要先用 ONNX 导出再通过官方的转换工具转成 RKNN 格式量化的时候要注意用一个有代表性的校准集别随便拿几张图凑数否则量化后精度掉得很难看。5. PyQt5 界面把检测能力变成现场人员敢用的软件5.1 界面功能拆解和布局思路一个检测软件该有哪些按钮得从现场人员怎么用出发而不是从程序员喜欢怎么写出发。我的布局是左右分栏。左边大块区域放视频显示用QLabel承载QPixmap或者用QGraphicsView以便支持缩放。右侧竖排控制区从上到下依次是数据源选择本地图片、本地视频、USB 摄像头、RTSP 视频流模型选择下拉框可以在不同权重文件之间切换置信度滑块实时调整 conf 阈值现场调试非常有用开始检测 / 停止检测按钮报警记录列表记录检出时间、类别、置信度截图保存按钮一键把当前帧存下来底部一条状态栏显示当前帧率、已处理帧数、当前置信度设置。这些看似不起眼但现场调试时能省很多沟通成本。界面整体用QMainWindow加QGridLayout控件全部设置objectName以便用 QSS 统一调样式。不要花太多时间在美化上功能能跑通、布局清晰、按钮够大够好点比一套花哨的皮肤重要得多。5.2 检测必须跑在子线程里这是我用崩溃换来的教训新手最容易犯的错误是把推理代码直接写在主线程里。写完一运行界面卡死点了停止按钮没反应强杀进程才能退出。原因很直白Qt 的主线程负责处理所有界面事件包括鼠标点击、窗口重绘。如果你的推理一帧要 30 毫秒主线程就被占住 30 毫秒界面在这段时间内完全无法响应。视频流连续跑起来主线程被持续占用界面看起来就是冻住了。正确做法是把检测逻辑放进QThread子类通过信号槽跟主线程通信。from PyQt5.QtCore import QThread, pyqtSignal import cv2 class DetectThread(QThread): frame_ready pyqtSignal(object) # 传已画好框的图像 alarm_triggered pyqtSignal(str) # 传报警信息 def __init__(self, model, source, conf): super().__init__() self.model model self.source source self.conf conf self._running True def run(self): cap cv2.VideoCapture(self.source) while self._running and cap.isOpened(): ret, frame cap.read() if not ret: break results self.model.predict(frame, confself.conf, verboseFalse) annotated results[0].plot() # 关键必须 copy否则底层缓冲区可能已被复用 self.frame_ready.emit(annotated.copy()) cap.release() def stop(self): self._running False self.wait()主线程那边接收信号并刷新def update_frame(self, frame): rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch rgb.shape qimg QImage(rgb.data, w, h, ch * w, QImage.Format_RGB888).copy() self.video_label.setPixmap(QPixmap.fromImage(qimg).scaled( self.video_label.size(), Qt.KeepAspectRatio, Qt.SmoothTransformation ))这里有两个必须记住的点。第一QImage构造函数接收的是原始内存指针如果你不.copy()那块内存被下一帧覆盖或者被回收程序就会崩溃或者显示花屏。第二线程停止时不能直接terminate()那样资源不会释放摄像头句柄会一直占着下次打开就报设备忙。要用一个标志位让run循环自然退出然后wait()等它结束。如果检测速度跟不上视频帧率可以在中间加一个Queue让读帧线程和推理线程分离队列满了就丢旧帧保证显示的永远是最新画面而不是越积越延迟的旧画面。5.3 显示环节的几个经典坑黑屏但程序没报错。这种情况在远程桌面、虚拟机或者老显卡驱动上特别常见。原因是 Qt 默认尝试用硬件 OpenGL 渲染而当前环境不支持。解决办法有两个一是设置环境变量强制走软件渲染在代码最开头、创建 QApplication 之前加上QtCore.QCoreApplication.setAttribute(Qt.AA_UseSoftwareOpenGL)二是在系统层面把 Qt 的渲染后端切成软件模式。这个问题在远程运维场景下几乎必现值得提前写好一个开关。视频画面变形。QLabel显示图像时如果不做等比缩放画面会被拉伸成和标签一样的长宽比。要用Qt.KeepAspectRatio并且让QLabel的大小随窗口变化联动在resizeEvent里重新缩放当前帧。高分辨率屏幕上界面错位。现在很多笔记本是 2K 甚至 4K 屏且带系统缩放如果不处理Qt 控件的实际像素和逻辑像素会对不上按钮变得极小或者界面被裁切。在创建 QApplication 之前设置Qt.AA_EnableHighDpiScaling属性可以解决大部分情况。颜色对调。OpenCV 读出来的是 BGR 顺序Qt 要的是 RGB忘了转换的话火焰会变成蓝色非常扎眼。转换用cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)。5.4 报警逻辑和结果留存检测出目标只是第一步系统要能把结果记下来。我在界面里做了三层。第一层是即时提示画面上的检出框标红同时在状态栏显示检测到火焰配合一个声音提示。声音用QSound或者系统的QApplication.beep()都行别用太刺耳的音效现场值班人员长时间听着会烦。第二层是记录列表每次触发报警就往QListWidget里插一条包含时间戳、类别、置信度。列表限制最多保留 500 条超了删最早的不然长时间运行内存会一直涨。第三层是落盘。报警时自动把当前帧带框版本存成图片文件名用时间戳_类别_置信度.jpg的格式存到一个按日期分的目录里。同时往一个 CSV 文件追加一行记录。这样即使软件崩溃重启历史记录也不会丢。有个细节要注意写文件的操作不要放在检测线程里同步做。磁盘 IO 偶尔会卡顿一旦卡住整个检测循环就被阻塞了画面会突然停顿。正确做法是发个信号给主线程由主线程异步写或者干脆用一个单独的写队列。6. 联调阶段集中爆发的几个问题与排查过程6.1 界面能启动但视频区域一直黑这个问题我遇到过两次排查过程几乎一样。第一次是在远程连接的服务器上部署本地测试完全正常一放到远程环境就黑屏。第一步先确认数据源有没有问题。写个独立的脚本只用 OpenCV 读摄像头并imshow能出画面说明摄像头本身没问题。第二步确认推理能不能跑单独跑model.predict看有没有结果。第三步才回到界面把update_frame里的图像直接存成文件打开看是不是有内容。那次的结论就是存下来的图是好的但界面上不显示问题锁定在 Qt 渲染环节。最终是通过强制软件渲染解决的。第二次是本地环境排查到最后发现是QLabel的尺寸被布局压缩成了 0scaled之后得到一张空图。把布局的最小尺寸设置好就正常了。这套数据源 → 推理 → 显示的分层排查法很管用能把问题快速定位到某一层不用在整条链路上瞎猜。6.2 跑几分钟之后画面越来越卡这是个典型的延迟累积问题。表现是刚启动时很流畅跑了三五分钟之后画面开始一顿一顿的最后完全不响应。根因是生产速度大于消费速度。摄像头每秒产生 30 帧但推理一帧要 50 毫秒也就是每秒只能处理 20 帧多出来的帧在缓冲区里越积越多。等你看到画面时它已经是十几秒前的了。修复方法是把读帧和推理拆成两个线程中间用一个固定长度的队列连接。队列长度设成 1 到 2每次入队前先检查队列满没满满了就把旧的那一帧丢掉。这样保证处理的永远是刚采到的帧宁可丢帧也不要延迟。if self.queue.full(): try: self.queue.get_nowait() # 丢掉最旧的一帧 except queue.Empty: pass self.queue.put(frame)丢掉的帧对监控来说不损失什么但延迟累积是致命的——值班人员看到画面时火已经烧了两分钟这就完全失去意义了。6.3 现场误报太多怎么一步步压下去模型在测试集上 mAP 很好看拿到现场还是天天误报这是最让人头疼也最有价值的一段调试。我一般按这个顺序排查先看误报的是什么场景。把误报的截图都收集起来人工看一遍。我那次统计下来误报集中在四个来源傍晚夕阳照在金属屋顶的反光、厂区里蒸汽管道排出的白雾、一辆红色货车长时间停在画面里、摄像头玻璃上有水渍形成的光斑。针对每个来源分别处理。反光和红色货车这类属于典型难负样本把它们的截图加进训练集当背景图重新微调几个 epoch效果立竿见影蒸汽白雾这类视觉上确实和烟高度相似的靠单帧模型很难彻底区分得引入时序信息——真实的烟是持续扩散并向上飘的蒸汽往往在固定位置持续喷出且形态变化规律。可以用短时序列的检测框轨迹做一个简单判断光斑这类固定位置的干扰可以直接在检测框上叠加一个静态掩膜区域落在这个区域内的可疑框不触发报警最后调阈值。前面几招做完之后再回到 conf 和 N 帧确认这两个参数上精调。我的调法是把现场录像跑一遍统计不同阈值下的误报数和漏报数画成两条曲线找平衡点。这个工作看着笨但比拍脑袋设参数靠谱得多。一个反直觉的经验宁可多留一点误报也不要为了压误报把阈值提到很高导致漏报。火灾场景里漏一次的代价远大于误报一百次。7. 实测表现和后续还能往哪些方向扩7.1 这套系统跑起来大概是什么水平把上面所有环节串起来之后我手上这套系统在室内仓库场景的实测结果大致是这样yolov8s 权重配 640 分辨率普通独显上完整链路稳定 40 到 55 帧火焰的检出率接近 99%烟雾因为本身对比度低在远距离小目标上的检出率大概 85% 到 90%。加上连续五帧确认之后一整天的运行误报控制在个位数这个水平在现场已经能被值班人员接受了。值得说的是光照条件对结果影响极大。夜间红外画面下火焰依然很好检但烟雾几乎不可见——因为红外成像不反映烟雾这种颗粒物的散射特性。如果你的场景必须覆盖夜间烟雾得配可见光加补光或者上双光谱方案这个已经超出单模型能解决的范围了。7.2 几个可以继续做的扩展第一是部署形态的多样化。目前是 Python 桌面程序往边缘设备迁移的话走 ONNX 到 RKNN 或者 TensorRT 这条路能在低功耗盒子上跑起来适合分散在多个点位的场景。第二是加入跟踪。现在每一帧都是独立检测同一个火源在连续帧里被反复报警。接一个简单的跟踪算法比如 ByteTrack给每个目标分配 ID只在首次出现时报警能大幅减少重复告警。第三是报警分级。根据检出目标的面积、数量、置信度综合给一个风险等级小面积的初期烟雾提示观察大面积高置信度的直接声光报警。这比检出就响要实用得多。第四是多路视频并行。真实项目里往往一个界面要同时看四路甚至十六路摄像头。这时候单模型的推理会成为瓶颈可以考虑批处理推理——把多路视频的当前帧拼成一个 batch 一起送进模型GPU 利用率能显著提升。代价是单帧延迟略微增加但在多路场景下总体吞吐提升明显。7.3 我个人做这个项目最大的体会回过头看这个项目最花时间的从来不是写模型代码那部分用 Ultralytics 几条命令就搭起来了。真正吃掉我大部分时间的是三件事调标注规范、找难负样本、把 PyQt5 的多线程和渲染调稳。如果让我给准备做这个方向的人一句建议别一上来就纠结用哪个版本的模型、要不要上更大的 backbone。先把数据集的质量做扎实标注规则写清楚把现场那些长得像火和烟的东西都收进来当负样本。模型层面yolov8s 加一套合理的增强足以应付绝大多数真实场景。等你发现确实是数据和场景受限而不是模型受限的时候再考虑换更大的模型或者更复杂的架构那时候的收益才对得起你的时间。还有一点界面别嫌土。现场人员要的是打开就能用、按钮大、不崩溃、有记录。我第一版界面花了三天做动画和渐变结果运维的师傅说找不到开始按钮在哪。后来换成最朴素的大按钮布局反而没人再提意见了。