森林消防这一行最怕的就是“发现即扑救”变成“扑救即失控”。火情发现得越早处置成本越低烧掉的林子越少。但传统的人工瞭望塔和卫星遥感要么覆盖密度不够要么实时性跟不上等确认起火往往已经过火了。过去两年我一直在做一套基于深度视觉的野外火灾预警系统核心就是用YOLO系列模型做火焰和烟雾的实时识别再配合Spring Boot、Vue、Flask搭出一套能真正落地的业务平台最后接入了DeepSeek和千问大模型做报警研判和报告生成。这套系统从数据标注、模型训练到后端联调、前端展示再到模型之间的横向对比整个链路我都跑通了这篇文章把完整的实现思路和踩过的坑都整理出来希望能给正在做同类项目的朋友一些参考。这套系统适合谁如果你正在做目标检测类的毕业设计、算法岗项目、或者是森林防火应急平台的前期预研想搞清楚YOLO系列几个版本到底选哪个、双后端架构怎么拆分、大模型在检测链路里放在什么位置比较合理那这篇文章基本能覆盖你的疑问。1. 项目概述与整体架构设计1.1 检测场景的真实痛点森林野外火灾的火焰烟雾检测和平时做车辆行人检测完全是两个难度等级。室外的光线变化剧烈清晨、正午、黄昏的光照完全不同烟雾是半透明的形态时刻在变背景里的云层、雾气、炊烟都会造成误检火焰的纹理又密集又细碎远距离下尺寸小得可怜常规的目标检测框很容易漏掉。更麻烦的是野外监控点位网络传输不稳定视频画面经常出现跳帧、拖影、色彩偏移这些都会直接把模型的精度拉下来。这套系统在设计之初就明确了几个硬性指标单帧图像推理延迟必须低于150毫秒火焰烟雾的mAP0.5要能到75以上小目标32像素以下召回率不能低于60%报警信息从检测到推送到前端页面不超过2秒。这些指标决定了后面的模型选型、双后端结构和大模型编排策略。1.2 双后端架构为什么这么拆我见过不少做检测系统的同学后台一股脑全用Python写。检测服务用Python没问题但业务层如果也堆在Flask里等到要接用户权限、报警记录、大屏统计报表的时候写起来又累又难维护。这套系统我拆成了两个后端各干各的边界非常清楚。Flask这一层只负责跟模型打交道。内部启动一个常驻的推理进程对外提供三个接口单张图片检测、视频帧批量检测、模型健康检查。Spring Boot这一层负责业务编排包括用户管理、检测任务下发、报警记录落库、历史数据查询、WebSocket推送检测结果。两个后端之间通过Spring Boot的RestTemplate调用Flask的接口不做函数级的耦合Flask挂了不影响Spring Boot主流程模型迭代也不需要重启业务服务。这样的拆分还有个好处是分别扩缩容。如果检测流量猛增只要多起几个Flask推理实例横向扩展就行Spring Boot那边完全无感。1.3 大模型在检测链路里的位置很多同学拿到DeepSeek和千问第一时间想的是让大模型直接识别火焰。这个思路我不太建议大模型做图像识别不是不行但帧率、成本、精度在实时监控场景里都不划算。我在这套系统里把大模型放在了检测之后的分析决策层。具体做了三件事。第一报警研判当YOLO模型检测到可疑火焰或烟雾会把现场图像、检测置信度、地理位置一起发给DeepSeek让它结合时间、天气等信息给出火情等级判断。第二巡检报告每天自动汇总当天的检测情况和报警记录调用千问生成一份自然语言的日报。第三人机问答工作人员可以在前端对话窗口问“今天有几起烟雾报警”“最近三天火焰检测的置信度趋势怎么样”系统调用大模型接口配合数据库查询结果给出答案。这套设计把大模型用在了它最擅长的语义理解和文本生成上而不是跟专用检测模型硬碰硬。整个项目用下来我的体会是检测模型的精度决定系统的下限大模型的语义分析能力决定系统的体验上限。2. YOLO系列模型选型与横向对比分析2.1 YOLOv8/v10/v11/v12/26的核心演进YOLO系列这两年迭代速度非常快每年都有新版本。做项目之前一定要搞清楚每个版本改了什么不然选型就是拍脑袋。YOLOv8是2023年发布的把C2f模块用了起来做成了anchor-free的结构训练收敛速度快部署工具链最成熟ultralytics框架对它支持最全面社区里能查到的资料也最多。YOLOv10的核心改动是去掉了NMS非极大值抑制后处理用了一致性匹配的机制推理时少一步后处理速度有明显优势。YOLOv11在v8的基础上换了C3k2模块加了注意力机制C2PSA整体参数量和计算量控制得很好。YOLOv12更激进把Transformer-based的注意力机制引入了backbone长距离依赖建模能力更强对理解烟雾这种大面积弥散型目标有帮助。YOLOv26是当前最新的实验性版本在特征融合和结构重参数化上做了不少尝试我拿到后第一时间的感受是小目标检测头设计得比以前细但训练稳定性还在验证阶段。简单总结v8最稳v10最快v11最均衡v12擅长复杂背景下的大目标v26偏向实验性的小目标优化。具体选哪个不能光看官方榜单一定要在自己的数据集上实测。2.2 火焰烟雾场景下的实测数据我用同一份自建的野外火焰烟雾数据集里面包含了18000张标注图片覆盖了白天、黄昏、夜间、阴天、晴天几种典型光线标注类别就两类fire火焰、smoke烟雾。训练时都用相同的输入分辨率640×640、相同的批次大小和训练轮数硬件统一用一块RTX 4090最后对比的指标包括mAP0.5、mAP0.50.95、单帧推理耗时、模型权重大小、小目标召回率。从实测数据看YOLOv8在中大尺寸火焰上表现很好但32像素以下的远距离小目标召回率只有56%左右。YOLOv10推理速度确实快但精度略低于v8。YOLOv11各方面比较均衡小目标召回率提升到61%比v8强了一些。YOLOv12在烟雾检测上有一点优势可能是Transformer注意力把弥散特征抓得更准但推理耗时偏高。YOLOv26的小目标召回率做到了65%左右fire和smoke两个类别的mAP0.5综合在82.4%目前来看是最适合这个场景的版本。需要说明的是YOLOv26目前还在持续迭代训练时对数据质量要求比较高如果你的标注框稍微不干净loss会出现明显波动。2.3 最终选型的决策逻辑最终我把YOLOv26作为主检测模型YOLOv11作为备选模型。理由很简单火焰烟雾检测最怕的就是小目标漏检早发现早处置是这套系统的核心价值哪怕牺牲一点点推理速度也值得。YOLOv26在野外远距离火点上的召回率优势是我最看中的。同时我也保留了模型热切换机制。在Spring Boot管理的模型配置表里可以动态切换启用哪个版本的模型Flask推理服务读到配置变更后自动加载新的权重文件整条链路不需要重启。这样后续YOLOv26如果出现更稳定的版本我可以直接替换权重也可以回退到YOLOv11观察对比。3. 系统核心功能模块实现3.1 数据集准备与标注规范训练数据的质量直接决定模型上限。我自建数据集主要有三个来源公开的FLAME火灾数据集、欧洲森林火灾图像库、以及从野外监控视频里抽帧自己标注的图片。公开数据集的优点是量大缺点是场景和我们的监控视角偏差大很多公开图都是近距离拍摄的火焰特写不是远距离监控画面。自己标注的时候我统一用LabelImg导出YOLO格式的txt文件。这里有个容易被新手忽略的细节YOLO的标注坐标是归一化的中心点x、中心点y、宽、高需要把左上角加右下角的人工标注框换算成这种格式。如果你手头有KITTI格式的标注数据要转YOLO核心公式就两个x_center (x_min x_max) / 2 / image_width y_center (y_min y_max) / 2 / image_height box_width (x_max - x_min) / image_width box_height (y_max - y_min) / image_height转出来之后记得用脚本检查一下有没有坐标越界的标注比如框的某个顶点超出了图像边界这类脏数据会让训练loss直接飘掉。标注策略上烟雾的框比火焰更难画因为烟雾边缘模糊我要求标注团队遵循“宁可大框不能漏框”的原则把可见的烟雾主体包进去就行不需要精准贴合边缘。3.2 训练参数与损失函数设置训练配置我这个项目用了ultralytics框架YOLOv26还没有官方正式发布时我是直接在源码仓库切换分支的。如果等项目正式落地建议用固定版本号锁定依赖避免上游更新影响线上推理。关键训练参数我记录一下输入尺寸640×640batch size为16epochs为300初始学习率0.002使用SGD优化器配合余弦退火策略。预处理阶段开了Mosaic增强、随机旋转和色调偏移。火焰场景下我发现色调偏移能增强模型对不同燃烧颜色火焰的泛化能力因为森林火灾里火焰颜色有橙红、黄色甚至蓝白色的情况。损失函数是YOLO系列自带的组合损失分类损失用BCE回归损失用CIoU加DFL。训练过程中要重点盯两个指标一是总的box loss是不是稳定下降如果出现反复震荡大概率是学习率太大或者数据里有脏标注二是验证集上的小目标类召回率连续多个epoch不涨的话可以试试把输入分辨率提到736或832小目标在更大分辨率上特征保留更完整。训练完成后用导出的ONNX格式做推理加速实测单帧从GPU推理到后处理结束可以稳定在45毫秒左右完全满足实时监控的要求。3.3 Flask推理服务封装细节Flask推理服务不是简单地把模型load进来然后predict就完事。有几个关键细节模型常驻内存、预热、批处理队列、接口容错。模型常驻是所有推理服务的基本前提不然每个请求都重新加载权重延迟直接爆炸。我封装了一个ModelInference类初始化时加载ONNX模型和类别映射表提供一个detect(image)方法。输入图片用OpenCV读成BGR格式预处理时做letterbox填充到640×640然后转成RGB、归一化、加batch维度。推理完成后要解析模型的输出张量YOLO系列的输出格式一般是(batch, 4num_classes, num_anchors)需要转置后按类别过滤、置信度阈值过滤、再做NMS去重。这些细节如果手动实现容易出bug建议直接用ultralytics自带的预处理器和后处理器只把纯推理部分切到ONNX Runtime上。Flask接口层我设置了超时保护和异常捕获避免单个坏帧拖垮整个服务。3.4 视频流接入与前端实时展示野外监控点的视频流多数走RTSP协议但Vue浏览器端没法直接播放RTSP。我采用的方案是在Flask推理服务里加一个RTSP拉流线程用OpenCV的VideoCapture持续读取帧每隔200毫秒取一帧做检测然后把标注了检测框的画面编码成HLS切片输出m3u8索引文件前端用Video.js的hls插件播放。这里有个经验可以参考不要把检测结果直接用RTMP或WebRTC推流HLS在弱网环境下更加稳虽然会有一两秒的延迟但对火灾监控来说完全可接受。前端页面里有个监控画布组件加载m3u8地址渲染实时画面同时在画布上叠加WebSocket推送过来的报警框和置信度。画布上的叠加层和视频画面天然分离一个是HTML定位一个是视频流渲染互不干扰。3.5 Spring Boot业务层API设计Spring Boot这边我严格按四层架构来组织Controller层负责暴露REST接口和参数校验Service层编写业务逻辑和事务控制Mapper层用MyBatis-Plus操作数据库Entity层定义数据库表对应的实体类。不建议把逻辑堆在Controller里后续要加权限控制和接口版本管理会非常痛苦。核心表设计有用户表、监控点表、报警记录表、模型配置表。报警记录表是核心字段包括监控点ID、检测到的类别、置信度、检测帧图片的OSS地址、大模型研判结果、处理状态。Controller层提供了分页查询报警记录、下发检测任务、更新模型状态、获取统计数据等接口前端Vue通过Axios调用这些接口再有新的检测结果时通过WebSocket推送。3.6 DeepSeek与千问大模型的实际接入大模型接入我用了官方OpenAI兼容接口DeepSeek和千问都有对应的接口文档。调用流程是先整理一个预案提示词模板把检测框结果、置信度、位置信息、当天天气状况拼进去让模型判断这次报警的等级是高危、中危还是低危并给出扑救建议。实测下来DeepSeek对中文自然语言的理解和报告生成效果很好生成火灾研判报告时逻辑清楚。千问在结构化信息抽取方面稍强一些我主要用它做报警信息的关键字段提取比如从一段巡检日报里抽取时间、地点、报警次数。两个模型互补使用还能把单服务商的调用成本摊薄。这里要特别提醒提示词里一定要做安全边界约束。我设置了系统级提示词明确告诉模型只能输出与火灾预警、安全作业相关的建议不做任何超出业务范围的判断所有生成内容都要附带“仅供参考以现场确认情况为准”的免责声明。4. 前后端联调与部署实践4.1 双后端通信与数据交互Spring Boot调用Flask接口我最初用的RestTemplate简单直接后来流量上来之后换成了WebClient异步调用避免长耗时请求阻塞业务线程。两个服务之间约定了统一的JSON格式字段包括code、message、datadata里是检测框列表每个检测框包含类别、置信度、bbox坐标。联调时踩过一个坑后端Flask检测出来的坐标是原始640×640分辨率下的而前端Vue页面展示的播放器尺寸可能是1920×1080甚至更大直接拿去画框位置对不上。我加了一个坐标映射接口把检测坐标按前端展示区域的实际尺寸做等比缩放这样报警框才能准确地套在画面上。4.2 Vue前端页面与状态管理前端工程用Vue3加Vite搭建模块划分成登录页、监控大屏、报警管理、模型管理、数据报表五个路由。监控大屏是核心页面左侧是实时视频流右侧是最近报警列表底部是当日检测走势图。Vue在展示实时报警数据时我用Pinia管理了WebSocket推送过来的全局状态。WebSocket连接在App.vue里初始化收到检测数据后commit到store监控大屏页面订阅store数据自动刷新。Vue路由跳转时注意清理WebSocket监听不然会出现跨页面数据错乱的问题。环境方面Vue开发环境默认跑在8080端口后端接口在9090本地联调时需要在vite.config.js里配置代理把/api前缀的请求转发到Spring Boot不然浏览器跨域直接报错。4.3 部署拓扑与性能优化生产环境我建议部署在一台带GPU的Linux服务器上。Spring Boot、MySQL、Redis部署在CPU上Flask推理服务跑在GPU上Nginx做前端静态资源代理和反向代理同时把/api路径的请求转发到Spring Boot。性能优化我做了三件事第一Flask推理进程设置成单例内部复用ONNX Runtime session禁止每个请求重建session第二检测结果异步落库Flask检测完先把结果推送到Redis队列Spring Boot起一个监听线程消费队列写数据库避免检测链路被数据库I/O拖慢第三把监控视频的HLS切片时间控制在4秒一个既能保证播放流畅又不会因为切片太多把磁盘撑爆。5. 常见问题与排查技巧实录5.1 YOLO训练阶段的典型问题训练的时候最常见的是loss一直跳不下降。我排查过几次最后定位到基本都是数据问题要么标注框有负数坐标要么类别编号从1开始而没有从0开始要么图片里有损坏的JPEG文件。建议训练前写一个数据完整性校验脚本遍历所有图片和标注文件把打不开的图和越界的框全部过滤掉。另一个问题是烟雾和背景误检。如果模型把云层、雾气识别成烟雾可以检查数据增强里是不是开了过强的色调偏移或高斯模糊这类增强把纹理信息破坏得太严重模型就只能靠颜色正则硬猜而烟雾和云本来就是同色系自然容易混。5.2 Spring Boot与Flask联调问题联调时最磨人的是接口超时。Flask首次加载模型权重需要几秒钟Spring Boot那边默认的RestTemplate超时只有3秒第一次调用必然报错。解决方法是模型预热Flask服务启动时先跑一次空推理把模型加载进内存同时把Spring Boot侧的连接超时和读取超时分别设成5秒和30秒。坐标映射问题前面提过这里再补充一个细节RTSP视频源的分辨率有时会在运行中变化比如网络卡顿后自动降码率Flask端要每次检测时重新读取视频帧的真实宽高不能写死初始值。5.3 大模型接入异常与前端播放问题DeepSeek接口偶尔会返回超时或者限流错误我这里做了失败重试和降级策略重试一次后仍然失败就直接把原始检测结果作为报警内容数据库里标记大模型分析失败前端展示不会受影响。绝对不会因为大模型API挂掉就让整个报警链路瘫痪。前端播放m3u8时最容易遇到的问题有两个一是跨域导致视频加载不出来需要在Nginx里给m3u8和ts文件加跨域响应头二是HLS切片的目录权限不对导致切片生成后前端拿不到文件检查一下部署目录的读写权限就好。我个人在实际项目里最大的体会是模型再强也只占系统成败的三成另外七成在工程——数据脏了没人帮你标注接口挂了没有降级就会被人投诉坐标不对前端画的框全是歪的。这几个方向都磨扎实了整套系统才能真正从论文里跑进现实成为一台能24小时守着山林的机器。后续如果要把这套系统扩展成多区域联防可以在Spring Boot里加一个区域管理模块把多个监控点的检测任务放到调度中心统一分配再配合大模型做跨区域的态势分析这个方向目前看下来是既实用又有延展空间的优化思路。