森林防火监控中心的屏幕上几十路视频画面轮流切换值班人员要在火焰刚冒头、烟雾刚飘起的最初几分钟内发现异常并上报——这个场景我在多个项目现场见过太多次了。人工盯屏的疲劳度问题、山区复杂光照下的误报问题、不同季节植被颜色变化带来的漏检问题每一项都在逼着防火系统往智能化方向走。这篇文章记录的就是我基于YOLOv8/v10/v11/v12/26五个版本的YOLO模型配合Spring Boot Vue Flask DeepSeek 千问大模型搭建的一套森林野外火灾火焰烟雾检测系统完整实现过程。从模型训练对比、后端服务编排、前端可视化到告警联动我把整个项目的设计思路、踩坑记录和实测数据都整理出来了。这套系统解决的并不是一个模糊的“我要AI检测火灾”的需求而是拆成了几个很具体的问题能不能在复杂山区背景下快速识别火焰和烟雾不同代际的YOLO模型在同一批数据上到底差多少模型训练出来后怎么稳定地嵌入业务系统大模型在这个链路里到底能干什么、不能干什么文章主要面向两类读者一类是做目标检测算法落地、需要一套完整工程参考的开发者另一类是正在选型森林防火平台、想了解AI检测能力边界的产品和技术负责人。1. 为什么森林火灾检测要叠这么多技术栈——项目起因与目标拆解1.1 森林火灾场景的特殊性火焰烟雾检测到底难在哪很多人以为火焰烟雾检测就是把通用目标检测数据集里的类别换一下实际完全不是一回事。我在项目启动前花了两周时间专门研究这个场景的特点其中几个难点直接决定了后续的技术选型。第一是目标形态极不稳定。火焰没有固定轮廓随风摆动颜色从亮白、橙黄到暗红跨越很大而且火焰区域经常和背景中的阳光反光、红色岩石、晚霞高度相似。烟雾更麻烦透明度高、边缘模糊白色烟雾和雾气、云朵在视觉上几乎无法区分。这意味着传统的颜色阈值分割方案HSV空间提取火焰色在实验室环境还能跑一上真实山区视频就全线崩溃。第二是检测距离和分辨率之间的矛盾。森林防火摄像机通常架设在制高点或铁塔上拍摄的是几百米到几公里的广域画面。火焰可能在画面里只占几十个像素烟雾可能从一小缕慢慢扩散到覆盖大半个画面。模型要在不同尺度下都能捕捉到目标对多尺度特征提取能力要求极高。第三是误报成本不对称。漏报一次火情可能造成灾难性损失但误报太多又会导致值班人员狼来了效应逐渐不信任系统。我见过一套纯传统视觉方案的防火系统晴天下午误报率高达30%以上最后被完全停用。AI模型的引入能大幅改善这个问题但不可能完全消除所以系统设计上必须有人工复核环节。1.2 三个端到端的价值链条从相机画面到管理决策这个项目的价值链条分为三段前端是摄像机或无人机传回的视频流中端是部署了YOLO模型的推理服务对每一帧画面做检测后端是面向防火管理人员的业务系统负责告警展示、火情定位、处置流程跟踪。模型检测是核心环节。摄像头把RTSP视频流推送到服务端服务端抽帧送入YOLO模型模型输出火焰和烟雾的边界框、置信度。置信度超过阈值就触发告警并将告警截图、视频片段传给业务系统。这个链路在技术上有无数细节要处理抽帧频率怎么定、多路视频如何并发推理、检测结果如何与摄像机云台联动等等。大模型的加入则把单次的检测结果升级为语义化的事件描述。检测到火焰后系统推送检测坐标和置信度给千问大模型本地部署或API让它生成一段自然语言的火情描述“监测到疑似火焰区域位于林区东侧火势较小周围无居民点建议调度无人机进行确认。”这样的描述对一线指挥人员来说比一串坐标和置信度数字直观得多。1.3 项目目标与边界哪些场景先不做技术方案最怕一开始就贪大求全。这个项目我明确圈定了几个暂时不做的范围一是不做火焰蔓延趋势预测因为那需要气象数据、地形数据、可燃物分布等多源数据融合复杂度远超检测本身二是不做多目标跟踪因为我用的摄像机机位相对固定火焰烟雾检测主要依赖单帧识别加上帧间差分确认暂时不需要DeepSort级别的跟踪三是不做端侧部署所有推理集中在服务器上边缘设备只负责采集和推流。这样做的好处是开发节奏可控能在三个月内跑通一个完整的Demo并逐步完善。实际项目中如果你要覆盖边缘计算、无人机吊舱检测、卫星热点发现等场景技术栈会完全不同。2. 系统架构设计与技术选型逻辑2.1 整体架构四个模块各司其职系统的整体架构分成四层设备接入层、AI推理层、业务服务层、前端展示层。设备接入层负责对接IPC摄像头、NVR、无人机图传等视频源统一转换成RTSP流。这里我用了一个独立的接入服务做协议适配避免多种厂商SDK直接污染核心业务代码。AI推理层是Flask应用加载YOLO模型权重接收视频帧或图片返回检测结果。选择Flask而不是Spring Boot的原因非常实际YOLO模型的生态在Python侧PyTorch、Ultralytics、OpenCV这些库都是Python原生的用Flask拉起一个轻量服务暴露HTTP接口是最短路径。如果强行把模型推理塞进Spring Boot要在Java里搞ONNX Runtime或者PyTorch Java API开发效率和排查问题的便利性都差很多。业务服务层用Spring Boot实现负责用户认证、摄像机管理、检测任务调度、告警记录持久化、消息推送。为什么这个角色不用Flask而选Spring Boot因为业务系统需要的权限体系、数据库ORM、定时任务、消息队列集成在Java生态里更成熟。我见过一些团队用Flask硬写业务系统写到后面用户管理、角色权限、操作日志这些模块越写越乱最后还是回到Spring Boot。前端展示层用Vue 3 Element Plus搭建实时展示检测画面、告警列表、模型状态并通过WebSocket接收检测结果的实时推送。前端还承担了一个重要功能视频流的播放。这里直接用WebRTC或WebSocket推帧实现避免在浏览器里依赖Flash或特殊插件。Vue对这块的支持很成熟无论是通过WebSocket接收JPEG帧流展示还是集成播放器播放HLS或WebRTC流都有现成方案。系统调用链路示例 IPC摄像头 - RTSP拉流服务Java- 视频帧转发WebSocket/消息队列- Flask推理服务 - 检测结果回传 - Spring Boot业务服务 - 告警入库 推送 - Vue前端展示2.2 模型服务为什么要独立部署而不是和业务服务合并我在项目初期犯过错误想把YOLO推理直接塞进Spring Boot进程里。当时觉得省一个服务的部署成本结果碰到两个问题。第一模型推理需要GPU资源而业务服务通常跑在CPU机器上混在一起导致GPU利用率低、业务响应变慢第二模型的更新迭代频率远高于业务代码每次升级模型都重新构建Java服务发布流程沉重。后来把模型推理独立成Flask服务后两个服务各自演进互不干扰。Flask服务配GPU实例启动时加载模型权重到显存调用时只做推理通过HTTP接口对外输出。Spring Boot服务通过RestTemplate或OpenFeign调用Flask接口两个服务之间用JSON传递数据团队协作边界非常清晰。这里有一个架构上的关键决策检测结果不回传整张图片而是回传裁剪后的目标区域图片加坐标信息。例如检测到一个火焰区域Flask服务把原图按边界框裁剪成小块和检测框坐标、置信度一起放入JSON。这样Spring Boot侧在处理告警时不需要额外调用OpenCV去做图片处理也减少了网络传输的数据量。2.3 前端视频流方案WebSocket推帧和HLS播放的选择Vue前端在视频展示上有一个绕不开的选择用WebSocket推帧还是用HLS播放。两套方案各有优劣我的最终选择是同时支持两种按场景切换。对于实时检测画面优先使用WebSocket推帧。服务端把视频流的每一帧压缩成JPEG通过WebSocket实时推送给浏览器前端用img标签或Canvas渲染。这种方案的延迟能控制在0.5秒以内而且每一帧都经过模型检测检测框可以直接叠加在图上无缝联动。缺点是带宽占用大如果同时打开多个视频窗口网络压力明显。对于历史回放使用HLS播放方案。后端把视频切片成TS文件通过M3U8索引文件供前端播放器加载。Vue生态里vue-video-player等组件对HLS支持很成熟一句话配置就能起播。缺点是HLS切片会造成5到10秒的延迟不适合实时检测画面的展示。提示如果你打算用WebSocket推帧后端抽帧发送的编码质量一定要单独压测。JPEG压缩质量参数从80调到50每帧数据量可能从50KB降到15KB在10路视频同时播放时差距非常明显。我最后把质量参数调到了60肉眼几乎无差别带宽压力小了一半。3. YOLOv8/v10/v11/v12/26五个版本的模型对比不只是看mAP3.1 各版本核心机制速览v8到v26到底改了什么YOLO系列的版本迭代速度这几年非常快从v8到v26几乎每年都有新版本发布。选型的时候如果不理解每个版本的差异光看排行榜上的mAP数字很容易被误导。我先把各版本的核心机制梳理了一遍。YOLOv8是Ultralytics团队在2023年推出的锚框无关anchor-free检测器在之前YOLOv5的基础上做了多项改进。主干网络引入C2f模块Cross Stage Partial with 2 convolutions能在保持轻量化的同时提升特征提取能力。解耦检测头将分类和回归任务分开处理加快了收敛速度。v8是当前应用最广泛、生态最成熟的版本社区教程多、部署方案丰富适合作为项目的基线模型。YOLOv10的核心创新是去掉了非极大值抑制NMS。模型直接通过双标签分配策略输出无冗余的检测框推理速度大幅提升。在相同精度条件下v10的推理延迟比v8低特别适合对实时性要求高的边缘场景。但缺点也很明显去NMS的设计对训练数据的质量要求更高标注框稍微不规范就可能导致输出检测框不稳。YOLOv11是Ultralytics继v8之后推出的升级版主干网络替换为C3k2模块在设计上更强调“骨架更轻、颈部更高效”。相比v8v11在保持精度的前提下进一步降低了参数量和计算量是一个均衡性很好的版本。如果你训练的硬件资源有限v11通常能在较少迭代次数内达到不错的效果。YOLOv12引入了区域注意力机制Area Attention使得网络在保持全局感受野的同时关注更关键的区域。v12的主要优势体现在小目标检测上火灾场景里远处的小火焰正好是典型的小目标所以这个特性对防火项目很有吸引力。代价是注意力机制带来更高的计算开销对GPU显存的要求也更大。关于v26这是YOLO系列在轻量化方向上更进一步的探索版本。它的核心思路是在保证基础检测能力的前提下进一步压低模型体积和计算量让模型更容易部署在边缘设备上。实际工程中如果你的算力资源不够跑v12v26可以作为低计算量场景的备选方案。3.2 我在同一数据集上的实测结果为了搞清楚五个版本的实际差距我在项目自建的森林火灾数据集上做了完整的训练和对比实验。数据集包含野外真实火灾视频截帧、公开的火灾图像数据集如FLAME数据集以及部分白天和夜间场景火焰和烟雾两类目标总共约12000张图像。训练统一采用输入分辨率640×640批大小16初始学习率0.01训练轮次100轮其他参数保持Ultralytics默认配置。测试集是独立的2000张图像没有参与训练。指标统计如下模型版本参数量(M)平均精度mAP50平均精度mAP50-95GPU推理延迟(ms)模型大小(MB)YOLOv8s11.287.661.35.222.5YOLOv10s8.086.959.84.119.7YOLOv11s9.488.162.04.620.8YOLOv12s14.588.763.56.828.3YOLOv26n3.282.453.12.98.1需要说明的是这些数据是基于我的数据集和硬件环境NVIDIA RTX 3090测出来的换一批数据结果可能会有浮动但大趋势是可信的v8到v12在精度上逐步提升其中v12的小目标检测能力确实更强v10的推理速度优势明显v26在计算资源紧张时是兜底方案。从mAP数值来看v12比v8的提升约为1.1个百分点看起来不算大但在火灾检测这个场景这一个点往往就决定了小火焰能不能被识别到。我特别测了远距离小火苗的检测率v12比v8高出约5个百分点这在实测中的意义远超mAP数字本身。3.3 模型选型结论与替换策略根据上面的实测数据我对五个版本的应用定位做了明确划分YOLOv8s基线方案生态最成熟出现问题最容易找到资料适合快速验证流程。YOLOv10s适合对推理速度要求极高的多路视频并发场景但需要更严格的标注质量保证。YOLOv11s均衡型选手如果资源有限又不想牺牲太多精度选它。YOLOv12s项目最终选用的方案因为森林火灾场景中小目标检测至关重要推理慢1.5毫秒的代价完全可以接受。YOLOv26n边缘盒子、低算力设备上的选择先保证检测能力存在精度不足再考虑蒸馏或剪枝。这里有一个重要的替换策略我在Flask推理服务里封装了一个模型版本切换接口通过配置文件指定加载哪个模型权重不用改代码就能切换YOLO版本。这样做的价值在于当新版本模型训练好并验证通过后只需要上传权重文件并修改一行配置就可以灰度上线观察一段时间再全量切换。模型配置文件示例config.yaml model: name: yolov12s.pt device: cuda:0 img_size: 640 conf_thres: 0.45 iou_thres: 0.45 class_names: [fire, smoke]4. 数据集准备与训练流程从原始视频到可用模型4.1 公开数据集与自采数据的组合策略火灾检测领域公开数据集不多质量参差不齐这是一个客观现实。FLAME数据集是亚利桑那州立大学发布的森林火灾图像集包含视频和图片标注了火焰和烟雾区域是很好的起步资源。此外可以找一些无人机航拍火灾、城市火灾的公开图像集补充场景多样性。但仅靠公开数据训练出来的模型在实际项目中不够用原因在于摄像机的安装位置、监控视野范围和公开数据差异太大。我的做法是花了两周时间专门采集和标注自建数据一方面联系有合作关系的林业管护站获取其监控摄像头的历史录像片段按1秒1帧抽帧另一方面用无人机在安全区域模拟篝火、燃烧枯枝等场景拍摄。最终自采数据约8000张占比超过60%直接带来两个提升模型在本地场景的误报率明显下降对摄像机特有的雾气和晨昏光照条件的适应能力大幅增强。4.2 标注规范与数据增强细节标注质量是训练效果的隐形天花板。YOLO系列虽然对标注要求相对宽容但v10等无NMS版本对标注精度特别敏感。我制定了一套标注规范确保几万张图像由不同标注人员完成时风格一致火焰标注遵循“有焰心就标到焰心只有外焰就标整体轮廓”烟雾标注遵循“能识别出是烟雾形态就标透明度高但轮廓可见时也标”两者同时出现且重叠时优先保证烟雾边界完整火焰按可见部分标注。这个规范解决了大多数人做火灾检测时频频改标注的痛点。数据增强方面我除了使用Ultralytics自带的马赛克增强mosaic、随机透视、HSV色域扰动外还针对森林场景手动添加了两种增强策略一是随机调整图像亮度模拟早晚阳光变化二是随机叠加烟雾噪声图层模拟雾天能见度下降的情况。这些增强的目的是提升模型的鲁棒性避免在阴影或雾气条件下漏检。4.3 训练参数配置与调参经验训练配置直接影响最终效果以下几个参数我花了不少时间调试直接分享结论初始学习率是训练是否稳定收敛的关键。我对比了0.001、0.01、0.05三组初始学习率0.001收敛太慢100轮训练后mAP50卡在70%左右0.01表现最好收敛快且稳定0.05训练初期loss剧烈震荡需要配合warmup才能稳住。最终固定为0.01配合余弦退火调度。输入分辨率对火焰检测同样关键。640×640和1280×1280两种分辨率我都测过1280在检测小火焰时精度提升明显但训练时间和显存占用约为640的3.5倍。考虑到服务器配置和实时性要求最终选用640×640同时保留升级1280的切换开关夜间重点监控时段可以临时放大分辨率加强检测能力。一轮训练时间在单卡RTX 3090上约为3小时100轮训练大约需要12小时含验证集评测。训练过程中需要重点关注两个指标验证集loss曲线是否持续下降mAP50是否稳定提升。如果训练后期mAP50开始波动明显往往是学习率衰减策略问题或数据分布不均衡及时调整即可。YOLOv12训练命令示例 yolo train datamydataset/data.yaml modelyolov12s.pt epochs100 imgsz640 batch16 lr00.01 device05. Flask模型服务与Spring Boot业务服务的对接实践5.1 Flask端推理API的设计与实现Flask推理服务是整个AI能力的载体接口设计的合理性直接决定调用方的开发体验。我设计了几个核心接口/predict/image处理单张图片检测/predict/batch处理批量检测/health做健康检查/models查询当前加载的模型信息和推理统计。单图检测接口的完整流程是接收base64编码的图片或图片URL解码为OpenCV图像格式缩放至模型输入尺寸执行模型推理解析输出结果。解析环节有几个隐藏细节YOLO模型输出的boxes坐标是归一化格式需要乘以原图宽高还原为像素坐标每个检测框会附带类别ID和置信度需要映射为可读的“fire”或“smoke”标签检测结果还需要做一次简单的非极大值抑制如果模型本身没有去除避免同一个火焰被输出多个检测框。接口返回的JSON结构设计得尽量简洁方便Spring Boot侧处理{ code: 0, message: success, detections: [ { class: fire, confidence: 0.92, bbox: [245, 368, 412, 529], cropped_base64: data:image/jpeg;base64,... } ], inference_ms: 15.2, frame_id: 20240615093000123 }5.2 Spring Boot端如何编排任务调度、级联告警、大模型增强Spring Boot服务在这套系统里像一个“大脑”负责把Flask检测结果转换成业务动作。核心流程是接收摄像头视频流抽帧任务 - 调用Flask推理接口 - 解析检测结果 - 根据策略决定是否告警 - 记录日志 - 推送前端。任务调度用了Spring Boot自带的Scheduled注解。每个摄像头配置一个抽帧间隔默认每2秒抽一帧送入检测。如果检测到火焰且置信度超过0.45则触发告警流程。告警流程里有一个级联策略连续三帧检测到火焰才正式告警避免单帧误检造成骚扰。三帧的间隔由抽帧频率决定总共约6秒确认时间在火情发现时效上完全可以接受误报率却能降低一半以上。告警产生后Spring Boot会组装一条告警数据包括摄像机ID、检测截图、火情描述、时间戳先写入数据库再通过WebSocket推送给在线的班组成员。同时调用千问大模型的API自动生成一篇简短的处置建议报告附在告警详情页中供管理人员参考。这里需要特别注意超时控制。Flask推理如果发生卡顿或排队Spring Boot的调用线程会被阻塞。我在调用Flask时设置了3秒的连接超时和10秒的读取超时并加了线程池隔离避免模型服务出问题时拖垮整个业务系统。5.3 多路视频并发推理的调度策略真实项目中一个系统往往要接入几十路甚至上百路摄像机如果每路视频都按固定帧率送推理GPU迟早被打满。我的调度策略是分级优先对重点防火区域的高位云台摄像机保持每2秒抽帧的检测频率对一般区域的固定摄像机降低到每10到15秒抽帧一次对无人机临时接入的图传按需启动专用任务任务结束后自动释放计算资源。通过这种方式40路视频接入时GPU平均利用率可以控制在70%左右高峰期峰值也不超过95%。如果超过这个负载我会在调度层做排队并在前端展示排队积压数让运维人员能直观看到系统是否过载。Flask端的推理服务用了一个基于队列的异步请求处理模型请求进来先入队列GPU推理线程按批次从队列中取帧实现了批处理优化单次推理可同时处理多张图片GPU利用率提升显著。6. DeepSeek与千问大模型在检测链路里的真实作用6.1 大模型不是用来做检测的而是做告警语义增强的很多人在类似项目里对大模型的定位有误解觉得让大模型基于图片做识别才能体现AI含量。但实际上检测环节用YOLO已经足够大模型的价值应该在检测结果之后对检测结果进行语义化解读、生成处置建议、辅助值班人员决策。我在系统里接入了两个大模型DeepSeek和千问两者分工不同。DeepSeek作为后端分析引擎负责对一段时间的检测历史做分析比如统计某个区域在一小时内火焰检测次数是否为持续性异常生成趋势摘要千问大模型则负责火情处置建议生成和告警文本润色。两个模型都通过API方式调用接口层面做了统一封装可以在配置文件中切换避免对单一模型供应商形成依赖。举例来说当Spring Boot检测到一处火焰时会把以下信息组装成Prompt发给千问检测到的目标类别火焰/烟雾、置信度、目标在画面中的位置、所在摄像机编号、当前时间。千问根据这些信息生成一段火情描述和处置建议“系统检测到摄像机CAM-07画面东南方向出现疑似火焰置信度0.89火势初起。建议先用云台摄像机拉近确认同时调度最近巡查人员前往查看注意避开下风方向。”这样的输出对防火指挥中心的工作人员有实际帮助远胜过一条只有数字的告警通知。6.2 智能巡检报告的生成流程除了实时告警这套系统还借助大模型生成每日智能巡检报告。每天晚上10点Spring Boot定时任务汇总当天的检测结果、告警记录、误报纠偏记录、摄像机在线率等指标组装成一份数据摘要发送给Flask后端的大模型服务生成带分析结论的自然语言报告。报告内容包括当日检测到疑似火焰事件X起、其中确认为真火情Y起、误报Z起、误报主要集中在哪些摄像机或时段、连续多日无告警区域是否正常等。这个功能原本是给管理人员看的实际使用中发现它对系统自检也很有价值——通过报告中的误报分布能反向定位哪些摄像机的安装角度需要调整、哪些时段需要调低检测阈值。6.3 接入大模型时的成本与稳定性控制大模型API按Token计费在告警量大的时段调用频繁成本需要提前规划。我的做法是设置两级调用策略实时告警场景必须调用大模型生成处置建议但每次限定的输出长度控制在200个Token以内每日巡检报告属于非实时的批量任务可以在夜间调用对响应时间不敏感允许较长的输出。稳定性方面大模型API偶发超时或返回异常内容是无法完全避免的。我在调用层增加了重试机制最多重试2次间隔指数退避重试失败则返回通用的告警模板不让告警链路因为大模型不可用而中断。同时增加了敏感词过滤和输出长度截断确保大模型的内容不会影响系统运行的稳定性。7. 部署上线后的稳定性优化与避坑手册7.1 推理侧优化显存占用、批处理与缓存模型推理服务上线后的第一道坎是显存占用。YOLOv12s模型本身占用约1.2GB显存但多路并发请求时每个请求的中间张量都会临时占用显存高峰期可能出现OOM。我的解决方案是限制推理服务最大并发数超过上限的请求排队等待避免将GPU显存直接撑爆。另一个优化是推理结果缓存。对于画面基本不变的情况比如夜间无火情、摄像机固定视野连续多帧检测结果高度相似没有必要每帧都跑模型。我加了一个简单的“帧差检测”逻辑每一帧与上一帧计算平均像素差如果差小于设定阈值则直接复用上一帧的检测结果。这个逻辑让夜间场景的GPU利用率下降了约60%效果非常显著。7.2 前后端联调里最容易踩的坑联调阶段最容易出问题的有三个地方视频流播放路径、WebSocket推送格式、时间戳一致性问题。视频流播放路径的坑在于RTSP流地址格式不统一。海康、大华、宇视等厂商的RTSP地址参数差异很大华为的摄像机还带特定鉴权参数。我在设备接入层统一做了一层协议解析输出标准化的RTSP地址上层业务不再关心厂商差异。WebSocket推送格式的坑在于不同模块对检测框坐标系的约定不一致。Flask返回的bbox是基于原图像素坐标前端叠加检测框时使用的是视频画面实际显示尺寸如果视频播放时有缩放或裁剪坐标就会错位。解决方案是前端拿到bbox后根据画面的实际宽高比做一次等比映射。时间戳一致性问题容易被忽略却影响很大。检测帧的时间戳如果与业务系统当前时间不一致告警排序和回放定位就全乱了。我统一使用了毫秒级时间戳在Spring Boot入口处生成后续所有链路共用不依赖各模块自己的系统时间。7.3 模型阈值调节与误报漏报的实弹调优模型部署上线后阈值调节就成了一件需要持续关注的事。置信度阈值conf_thres设太低会引入大量误报设太高又会漏掉真实火情。我在系统中做了一个动态阈值功能白天和夜间分别使用不同的基线阈值。白天光照复杂比如树叶反光、红色车辆都可能被误判为火焰阈值设为0.48夜间画面相对干净误报源少阈值设为0.38提高对微弱火焰的敏感度。这种动态调节依赖不同时段的检测数据支撑上线初期需要每天查看误报记录并微调阈值参数。运行一个月后积累了足够数据就能确定一套相对稳定的阈值曲线。我实际项目中通过这种方式把平均误报率从每天15次降到了每天2到3次同时没有增加漏报比例。注意阈值调优依赖的是大量真实运行数据不要一上来就追求低误报率而把阈值拉高。先让系统运行一到两周拿到足够多的误报样本再调参效果最好。一上来就调高阈值看起来很干净但很可能把真实火情的置信度也压在了阈值以下模型形同虚设。项目上线跑了大半年我最深的体会是这类系统最难的不是模型训练而是让模型输出的结果真正嵌入业务流程并被用户信任。从YOLO版本选型到Flask与Spring Boot的分层协作从视频流调度到阈值动态调节每一个环节的不确定性都要靠实打实的现场数据来消除。后续如果你在这个基础上做扩展可以重点关注两条线一是把检测结果与GIS地图联动火情告警直接标注在电子地图上二是把多台摄像机的检测结果做交叉验证降低单视角检测的局限性。这两块扩展完整套森林防火检测系统才算是真正从“能看”迈向“能用”。