一眼望不到头的管廊架阀门、法兰、接头加起来上千个巡检老师傅打着手电筒一个个看、贴着耳朵听漏气声一圈下来两小时起步。很多化工厂、液压站、燃气调压站至今还靠这种纯人力的方式查漏。人工巡检的问题不只是慢关键是人的注意力总会疲倦滴漏、渗油这类缓慢变化很容易被忽略。几年前我接过一个设备泄漏检测的视觉项目当时用传统图像处理做光照一变、背景一杂算法就崩后来切到深度学习目标检测方案才真正落地。最近折腾完一整套基于YOLOv12的设备泄漏检测系统把模型训练、数据集构建、UI界面、登录注册全串了起来整份Python项目源码和训练好的模型都在手边这篇文章就把这套东西从零到一的完整思路、踩坑过程和关键实现细节都写出来。这套系统解决的核心问题是对工业现场的视频流或巡检照片做实时分析自动框出泄漏点并给出置信度。它适合正在做相关课题的学生、想给自家工厂做智能化改造的工程师以及打算把目标检测从跑通demo推进到能交付工程的开发者。和我以前写的纯目标检测教程不同这次是完整应用系统——模型只是其中一环数据标注、后端服务、前端交互、账号权限都得串起来任何一个环节掉链子系统在现场都撑不起来。1. 整体方案设计与思路拆解1.1 为什么选YOLOv12做泄漏检测设备泄漏检测是个非常典型的工业视觉场景它对算法的核心要求是快和稳。快是因为很多泄漏场景是动态的——比如压力管路接头处的喷射、滴漏你得在视频流里实时框出来不能等几秒钟才出结果那是事后诸葛。稳是因为工业现场环境极其不友好光线忽明忽暗、背景里管道交错、设备表面反光算法在这种环境里容易误检漏检模型的特征提取能力必须足够强。YOLO系列一直是工业侧落地最广的目标检测架构从v5到现在每一代都在精度和速度之间找平衡。YOLOv12这一代值得关注的点是把注意力机制以比较优雅的方式引入到了检测主干里针对全局上下文信息的建模能力明显变强。之前的YOLO版本主要靠CNN堆特征对小目标、遮挡目标、背景复杂的目标容易出现漏检而泄漏点恰恰很多是小目标而且经常藏在管道缝隙、阀门后头。v12引入的注意力机制可以让模型在特征提取时更关注那些真正可疑的区域而不是被大片管道背景带偏。除了算法层面的改进选YOLOv12还有工程上的理由。它的训练和部署方式和YOLOv8系列基本一致用Ultralytics框架可以无缝切换数据格式、回调函数、导出方式都是通用的。这意味着你不需要从零摸索一套新工具链迁移成本很低。我在实际对比过v8和v12在同等数据量下的表现后发现对细小的液体滴漏和气体冒泡这类目标v12的召回率确实高出一截尤其是当泄漏点和背景颜色接近时这个优势更明显。1.2 系统整体架构与模块划分这套系统不是训练个模型就完事的demo而是按可交付的工程标准来设计的。整体拆成四个层次数据层、模型层、服务层、应用层。数据层负责样本采集、标注和格式转换最终产出的是符合YOLO格式的训练集和验证集。模型层是训练好的YOLOv12权重它负责对传入图片或视频帧做推理输出检测框的位置、类别和置信度。服务层是后端程序负责接收前端请求、调用模型推理、返回检测结果、管理用户信息和检测记录。应用层是用户直接看到的界面包括登录注册页、检测主页面、历史记录页。为什么必须做登录注册很多同学做毕设或项目展示时觉得登录注册是多余的其实不是。工业系统的操作是强留痕的谁在什么时候对哪个区域做了检测、发现了什么问题这些都得记录在案。如果没有任何权限控制随便来个人都能操作系统出了安全事故连责任人都找不到这在工厂里是绝对不能接受的。所以登录注册不是花架子它对应的是真实工业场景里的权限管理与审计追溯需求。用户角色我分了两种普通操作员和管理员。操作员能登录系统、做检测、查看自己的检测记录管理员除了这些还能查看所有用户的操作记录、管理用户账号。这个角色划分也是从现场需求倒推出来的工厂里不可能让人人都能删改记录。1.3 技术选型背后的考虑模型部分用了Ultralytics YOLOv12理由前面已经说了。后端服务我选了Python的Flask框架原因是它轻量、和模型推理代码在同一个语言生态里加载模型、调用推理都顺畅。有些项目会把后端用Java或Go写模型单独起一个Python服务那样拆得太重了单机系统没必要搞微服务。前端界面我用了HTMLCSSJavaScript没有上Vue、React那套重型框架因为这是一个工具型系统核心诉求是功能清晰、加载快用原生前端配合后端模板渲染就足够了。数据库选的是SQLite。虽然SQLite在重负载下不如MySQL能打但这种单机版的检测系统并发量本来就不高——一个工厂里也就几个人同时用SQLite完全够用而且零配置、免维护真正部署的时候省掉一大堆麻烦。数据集中管理但规模不大用SQLite是性价比最高的选择。2. 数据集构建最容易被忽略的隐形工作量2.1 泄漏样本的来源问题做检测系统真正花时间最多的不是写代码而是搞数据。泄漏样本最大的问题是稀缺。正常运行的生产设备不可能一直在漏你很难到现场拍几千张泄漏照片。我当年做这个项目时第一批样本来自三个渠道首先是现场抓拍。和工厂安全员约好设备出现滴漏、渗油时第一时间拍照记录下来。虽然样本量不大但这是最有价值的数据因为它是真实的工况、真实的设备、真实的光线条件。其次是实验室模拟。找一段旧管道人为制造可控的泄漏——滴漏、细流、喷射用不同流量、不同液体、不同背景光线下拍视频再抽帧。第三是网络公开数据。网上有一些工业泄漏图像数据集虽然场景不一定完全对得上但可以拿来做预训练或数据增强的素材提升模型的泛化能力。如果你实在搞不到真实泄漏样本还有个变通办法先下载公开的通用目标检测数据集比如各种液体、烟雾、水渍的图片训练一个粗模型再用手头的少量现场数据做微调。这种做法虽然精度上限会低一些但至少能跑通流程后续再慢慢补充数据迭代。2.2 标注规范与工具实操数据有了就得标注。这里必须统一标注规范否则不同人标出来的框风格不一样模型会学混乱。我定义的类别有三种liquid_leak液体泄漏、gas_leak气体/蒸汽泄漏、suspected_leak疑似泄漏比如有痕迹但不确定。液体泄漏框选的是泄漏点本身而不是整个污染区域气体泄漏因为往往看不见实体主要靠背景中的蒸汽、雾气、凝结水来判断疑似泄漏是给现场复核留的选项宁可多标一些让模型在低置信度下能给出提示也不能漏掉真正的问题。标注工具我用的是LabelImg和LabelMe这两个开源工具。LabelImg适合标矩形框界面简洁操作流畅绝大多数检测项目用这个就够了。LabelMe支持多边形标注如果泄漏区域形状比较复杂比如喷射的扇形痕迹用多边形标得更准。标注时几个实操要点对每一帧画面先看整体不要漏掉角落里的细小泄漏点框要紧贴目标边缘框太大或太小都会让模型的回归头学偏对于遮挡严重的泄漏点只要能看到一部分就标出来这能让模型学会遮挡情况下的检测难分类的样本光照极暗、强烈反光、微小滴漏单独放一个文件夹后续分析错误时用标注完成后导出成YOLO格式。YOLO标注文件是txt每行代表一个目标类别id 中心点x(归一化) 中心点y(归一化) 框宽(归一化) 框高(归一化)。LabelImg可以直接保存成YOLO格式但如果用的别的工具导出的是VOC格式的XML文件就需要写个脚本转一下。转换逻辑很简单读取XML里的边界框坐标除以图片宽高归一化再按类别映射成id写入txt。2.3 数据增强与数据集划分工业现场的数据永远不够多所以增强这步不能省。我常用的增强手段包括随机旋转-15度到15度、水平翻转、亮度对比度调整、随机裁剪、加噪声、模拟雨雾效果。特别是亮度调整非常关键因为工厂里早上和晚上的光照完全不同不增强的话模型在暗光下基本就是瞎子。数据增强有现成的库可以用Ultralytics框架自带增强配置在训练参数里设置就行不需要自己额外写。但如果数据集本身分布有偏比如白天样本太多夜晚样本太少建议先手动做一轮针对性增强让类别和场景分布平衡一些再交给框架的在线增强。划分比例我习惯用8:1:1。80%训练集、10%验证集、10%测试集。测试集是绝对不能参与训练的要留到模型训完之后做最终评价。注意划分的时候要按照设备或场景来划分而不是按图片随机分。什么意思呢比如同一台泵在不同时间拍的照片如果一半进了训练集一半进了测试集那测试时模型等于是开卷考试——它已经见过这台泵的样子了分数会虚高。按场景划分才能测出真实泛化能力。3. 模型训练与调优从预训练权重到收敛3.1 环境配置与基础准备这是我每次都要重点提醒的部分。YOLOv12训练的环境配置说复杂也复杂说简单也简单关键在于把Python、PyTorch、CUDA的版本对齐。我的建议是Python用3.9以上PyTorch用和显卡驱动匹配的稳定版本CUDA版本跟着PyTorch走别贪新。跑YOLO系列框架显卡显存最低建议8GB如果只有4G显存就得把batch size调小、图像尺寸调小但训练速度和效果都会打折扣。安装Ultralytics框架一条命令就搞定pip install ultralytics。装完以后可以跑一个快速测试确认GPU能正常调用。3.2 预训练权重与大小的选择YOLOv12提供了n、s、m、l、x几个大小档位的预训练权重。选哪个不光是精度问题更关键的是部署机型的算力和显存。我个人的经验是做工业泄漏检测优先从YOLOv12s开始调s模型平衡了速度和精度对流畅的推理需求比较友好。如果你确定部署机器显卡很弱比如只有集显或低端显卡就选n如果精度优先且显存足够16G以上可以上m甚至l。还有一个经验哪怕你的数据集和公开集差得再远也强烈建议用预训练权重做初始权重而不是从头训练。预训练模型已经在大规模数据上学到了通用的纹理、边缘、形状特征你在自己的小数据集上微调相当于在一个很不错的起点上继续走。从头训练不仅收敛慢在小数据集上还容易过拟合。3.3 数据配置文件与训练参数训练前需要准备一个data.yaml文件里面指定训练集和验证集路径、类别数量、类别名称。写这个文件时有一个很容易踩的坑路径最好用相对路径或者用可以被Flask后端引用的绝对路径否则换个机器训练运行路径对不上就会报错。训练命令大概是这样的yolo train datadata.yaml modelyolov12s.pt epochs200 imgsz640 batch16 workers8这里面epochs不是越大越好。我有一次设了300轮结果150轮之后验证集mAP不再提升反而轻微下降明显过拟合了。现在习惯用早停机制就是让框架监控验证集指标连续几十轮不提升就自动停止训练节省时间也避免过拟合。图像尺寸imgsz默认是640如果检测目标普遍较小泄漏点经常是几十像素的小点可以考虑改成768甚至960。分辨率越高模型看清楚小目标的能力越强但代价是显存占用和推理耗时都会增加。这个需要根据实际效果权衡。3.4 评估指标和训练调优心得训练完成后不要只看训练损失降低就觉得成功了更关键的是看验证集上的指标。我习惯重点看这几个数mAP50-95核心综合指标越高说明模型越稳健recall泄漏检测里比precision更重要。漏检一个泄漏点可能造成安全事故误报顶多让人多看一眼所以recall是保底指标precision在recall够高的前提下再追求precision减少不必要的误报训练过程中我会一直盯着的损失曲线有三个分别对应分类损失、框回归损失和置信度损失训练日志里都有。前面几十轮损失快速下降是正常现象如果到一百轮之后某个损失反复震荡降不下去往往说明某个类别的样本太少或者标注不一致。说一个我真实踩过的坑一开始我的训练集里液体泄漏样本多、气体泄漏样本很少结果训练完发现气体泄漏的recall只有20%多根本不能用。后来我把气体类别的样本单独补了上百张做增强又调高了正样本权重才把指标拉起来。这个教训就是类别不平衡在泄漏检测里比以往很多通用场景更致命因为你的漏检往往是那个样本最少的类别。4. UI与登录注册模块让模型真正落地的关键4.1 界面技术方案与整体框架模型训得再准如果交付物是一个命令行工具现场工人根本不会用。UI这部分我选了Web方案Flask做后端路由和API前端用HTMLCSSJavaScript构建页面。为什么不用PyQt5做桌面程序因为Web方案部署灵活任何一台能开浏览器的电脑都能访问不需要装Python环境而且界面开发效率高写界面代码比写PyQt的信号槽简单太多了。整个Flask应用的文件结构大概是这样project/ ├── app.py # 后端主程序 ├── models/ # 存放训练好的模型权重 │ └── best.pt ├── datasets/ # 数据集文件夹 ├── templates/ # 前端HTML模板 │ ├── login.html │ ├── register.html │ ├── index.html # 检测主页 │ └── history.html ├── static/ # 静态资源CSS/JS ├── database.db # SQLite数据库 └── utils/ └── detector.py # 封装模型推理逻辑4.2 登录注册模块的完整实现登录注册这块核心在两点数据库用户表设计和密码安全。用户表设计非常简洁字段包括id、用户名、密码哈希、角色、创建时间。密码绝对不能明文存这是底线。我用的Flask自带的werkzeug安全库生成pbkdf2:sha256格式的哈希值注册时哈希入库登录时取出哈希再比对。这样就算数据库泄露了攻击者拿到的也不是明文密码。from werkzeug.security import generate_password_hash, check_password_hash # 注册时生成哈希 password_hash generate_password_hash(user_password) # 登录时校验 is_valid check_password_hash(stored_hash, user_password)注册页的关键逻辑用户名唯一性校验、密码强度校验至少8位且包含数字和字母、二次输入密码一致性校验。这些在前端和后端都要做前端校验是提升用户体验后端校验才是安全保证——绕过前端直接调接口的情况必须防住。登录成功后我用Session保存用户状态后续每个接口都先检查Session里有没有登录标记没有就直接跳回登录页。Session密钥要在生产环境里换成随机生成的字符串不要用默认值不然存在被伪造的风险。4.3 检测主界面的设计与交互流程检测主页是整个系统使用频率最高的页面我的设计思路是上传即所见、结果即时反馈。页面布局左半部分是上传区域和功能按钮支持上传单张图片、上传视频文件、实时摄像头采集右半部分是检测结果展示区原图左边、标注结果右边并排对比。后端检测接口的流程是这样的用户提交图片 - 后端保存图片 - 调用detector.py里的推理函数 - 模型返回所有检测框的坐标、类别和置信度 - 后端把这些信息画到图片上 - 将标注后的图片以base64编码返回前端显示。同时把检测结果原文存到数据库里包括图片名、检测到的类别、置信度、时间、操作人。摄像头实时检测做的是视频流处理。浏览器把视频流每帧传给后端不现实延迟太高。我的方案是用JavaScript在浏览器端通过Canvas捕捉视频帧然后定时比如每300毫秒把当前帧的base64数据POST到后端检测接口后端处理后返回标注帧替换显示。这样既避免了服务端转码视频流的复杂度又能实现接近实时的检测效果。4.4 检测记录与历史管理检测历史这块很容易被做成鸡肋功能但我觉得它才是系统长期价值所在。每一次检测记录都存了时间、操作人、检测到的目标数和置信度管理人员可以按时间段、按操作人筛选查看哪段时间哪类泄漏出现频率最高这对设备维护计划有直接帮助。我在历史页面加了一个简单的统计图用原生Canvas画的柱状图没有引第三方库按周统计泄漏报警数量方便巡检人员做趋势分析。5. 常见问题与排查技巧实录5.1 训练时显存溢出OOM怎么办OOM是训练阶段遇到最多的问题。解决方法按优先级排序调小batch size从16调到8甚至4、调小图像尺寸640降到512、开启梯度累积显存不够时不错的选择、换更小尺寸的模型s换n。有一点要注意batch size和图像尺寸同时影响显存如果缩小batch后还报错就是图片太大了。另外把训练进程之外占显存的东西统统关掉我之前吃过教训训练时忘记关掉另一个测试脚本白跑了一次。5.2 模型检测不到细小泄漏目标排查思路从数据找原因。先看标注框的平均大小——如果大量目标是十几像素的小框模型默认的多尺度特征可能对小目标不敏感。解决方法是检查配置文件里的imgsz别用640上到960适当的图像增强对多尺度非常有用另外确认标注的小目标框在gt里有没有被过滤掉如果训练时没看到小目标那测试时自然检测不到。5.3 Web界面推理速度慢到卡顿先分清瓶颈在哪。如果是上传图片检测慢重点优化后端加载模型时只能加载一次不要每次请求都重新加载推理时用GPU推理。如果摄像头实时预览卡顿那是帧率太高了把检测间隔从300毫秒调到500毫秒体感虽然稍微延迟但流畅度会好很多。另外标注结果图片输出时用大分辨率会导致传输太慢建议后端输出前压缩一下图片质量。5.4 现场部署后效果变差这是最现实的工程问题。在实验室测试效果很好一上现场就变差绝大多数原因是现场光线条件和训练数据不一样。工业现场常见的特殊条件包括大面积逆光、顶灯频闪、背景色和目标颜色相近。解决手段是训练时要把不同光线条件的增强做得足够充分更有效的是直接采集现场的光线样本加入训练集再保险一层部署时可以在检测前加一个预处理先做直方图均衡化再进模型。5.5 数据安全与部署注意事项这套系统里涉及的操作记录和用户数据是敏感信息部署时数据库文件要做好访问控制不要放在可以被浏览器直接访问的静态目录下。Flask自带的调试服务器只能用于开发测试正式交付时要用Waitress或Gunicorn跑生产服务监听的内网端口也要做限制只开放给需要访问的人。模型文件虽然是训练产物但它包含了设备泄漏特征的场景信息属于项目资产交付时要和源码一起做好版本管理。最后说几句实在的做完这个项目之后我个人最大的体会是训练一个模型只占了整个系统不到三成的精力剩下七成都在处理数据、接口、部署这些边角料工作。但恰恰是这些边角料决定了系统能不能在现场用起来。很多研究做得不错的算法就是栽在数据标注不规范、界面没人会操作、部署后环境不兼容这些非算法问题上。最后再分享一个小技巧验证模型效果时除了看mAP这些指标自己拿手机去现场拍一段视频回来用系统跑一遍。真实场景的表现永远比纸面指标更诚实。这套YOLOv12系统后续还可以往多路并发检测、跨设备联动的方向扩展但那都是后话了先把单机的链路走通你就已经迈过最难的那道坎了。