简介本资源面向电力行业智能巡检开发者、计算机视觉初学者及工业安全AI落地实践者提供一套开箱即用的YOLOv7安全帽佩戴检测完整方案专用于识别电塔、电线杆等高危作业场景中工人是否规范佩戴安全帽切实支撑安全生产监管需求。压缩包共886个文件305.7MB含295张标注图像jpg、295份PASCAL VOC格式XML标注文件与296个对应YOLO格式txt标签覆盖多角度、多光照、遮挡及小目标典型工况模型已训练收敛PR曲线、混淆矩阵等评估结果均保存于runs文件夹配套代码支持一键推理与可视化。目前已有453人学习下载资源结构清晰无需重新标注或调参即可直接部署验证显著降低电力AI巡检项目的技术门槛与验证周期。 在电力巡检现场安全帽佩戴检测是个老需求但真正把检测模型做到能落地尤其是把数据、训练、部署整个链路跑通中间的细节远比大多数人预想的多。这篇文章记录的是一个完整的YOLOv7电力巡检安全帽检测项目包含标注好的数据集、训练好的检测模型和从零到一的训练部署全流程适合正在做目标检测落地、或者想找一套现成方案参考的开发者。项目核心思路很简单用YOLOv7在电力巡检场景下识别人员是否佩戴安全帽输出检测框和类别为后续告警、审核提供视觉基础能力实际项目交付时把数据集、权重和推理脚本一起给到使用方才算是真正能用的完整方案。1. 电力巡检安全帽检测的现场痛点为什么通用模型不够用1.1 巡检场景的特殊性小目标、遮挡、逆光一起上电力巡检和普通工地安全帽检测的差异一开始我其实低估了。普通工地场景工人离镜头近、目标大、背景相对均匀一套通用COCO权重里的person类也能勉强跑出个大概。但电力巡检不一样——杆塔上的作业人员离地面好几米无人机或手持摄像机拍到的目标往往只有几十个像素变电站里设备密集人员身体被设备遮挡的情况严重户外巡检还会遇到逆光、阴天、夜间补光、雨雾等复杂光照条件。用通用检测模型做这一场景漏检率会高到业务无法接受。安全帽检测本质上是一个细粒度目标检测问题。它不是是不是人这种粗粒度判断而是这个人有没有戴安全帽的精细判断。戴了安全帽的人远看轮廓和没戴的人差别极小加上巡检场景中人员姿态多变——低头看仪表、弯腰操作、攀爬杆塔——模型如果没有针对性的数据喂养很容易把没戴误判成戴了或者干脆漏掉。1.2 业务侧的真实需求从检出到可告警现场业务部门提需求时不会说我要一个mAP 90%的模型他们说的是我们要能自动发现谁没戴安全帽最好能截图留证能导出记录。这句看似简单的话翻译成技术需求至少包含三层检测模型要输出稳定的类别和置信度不能一会儿识别出一会儿识别不出要有工程化接口能接收视频流或图片输出结构化结果误报要控制在可接受范围内否则每天几百条假告警会直接被客户关掉所以我做这个项目时没有只停留在训练个模型出来的层面而是把模型数据推理脚本部署说明作为整体交付。这也是为什么我把训练好的检测模型和标注好的数据集同时作为项目核心资产——模型可以复现数据可以扩展这才是长期可维护的交付物。1.3 项目目标与整体技术选型针对上述场景我把项目目标拆成了三条构建一套覆盖电力巡检常见场景的安全帽检测数据集标注质量达到可直接训练的标准基于YOLOv7训练出精度和速度都满足巡检业务需求的检测模型提供开箱即用的推理代码支持图片、视频、RTSP流三种输入方式选型YOLOv7而不是其他算法核心考量是三点一是YOLOv7在同等算力下精度和速度的平衡性比较好在2022年被提出时刷新了当时实时检测器的SOTA结构上对边缘设备也相对友好二是社区生态成熟训练、导出、部署的上下游工具链完整遇到问题能找到人问三是模型结构的设计思路非常有学习价值比如E-ELAN和重参数化卷积这些思路对后续做其他检测任务也有迁移价值。2. 数据是天花板标注好的数据集到底该怎么建2.1 数据采集渠道与场景覆盖策略这个项目的原始数据来自三个渠道一部分是客户提供的变电站和输电线路巡检历史图片这部分最有价值因为真实场景的分布是任何公开数据集替代不了的一部分是项目组自己到现场用相机和手机拍的补充了不同角度、不同距离、不同光线条件下的样本还有一部分是从公开数据集和网络上筛选的电力作业相关图片用于扩充多样性。在数据采集阶段就要有场景覆盖清单的意识。我当时列了一下大概是这样的维度矩阵维度覆盖要求距离近景3米、中景3-10米、远景10米光照白天强光、逆光、阴天、夜间补光姿态正面、侧面、背面、低头、蹲姿、攀爬遮挡无遮挡、半身遮挡、设备遮挡、多人密集场景变电站、杆塔、线缆走廊、施工围栏每个维度至少要保证一定比例的样本尤其是容易漏检的远景和逆光场景。最开始我犯过一个错误——数据大部分是近景和正面照训练出来的模型在测试集上mAP看起来很高但一拿到现场视频就露馅了远距离小目标几乎全漏。后来补了一批远景样本漏检率才明显下降。2.2 标注类别的设计两个类还是三个类安全帽检测的标注类别设计是个容易被忽视、但影响非常大的决策。业界常见有两种方案两种类别person人、helmet安全帽三种类别person人、helmet安全帽、head未戴帽的头两种类别的做法逻辑是检测到人之后再看他身边有没有安全帽的框。问题在于人没戴帽时无帽的头部区域没有对应的正样本模型学到的是这附近有没有帽子的共现关系而不是这个人头上有没有帽子的因果关系。如果两个人挨得近一个戴帽一个没戴这个方案会给是否佩戴的判断带来歧义。三种类别的做法是我实际采用的方案。把未佩戴安全帽的头部作为一个独立的head类模型需要同时区分helmet和head这两个语义相反的类别决策边界更加明确。推理的时候判断规则很简单检到person且有helmet且无head判定为佩戴检到head判定为未佩戴。这种后处理逻辑非常干净误判率低而且便于业务侧理解。2.3 标注工具与格式转换标注工具我用的是LabelImg它足够简单标注速度也快在大量真实图片重复标注时效率很关键。如果你更习惯半自动标注流程可以先用LabelStudio或者X-AnyLabeling配合基础模型做预标注人工做修正能省下不少时间。但预标注的质量参差不齐后期校对成本可能反而更高小规模数据我建议直接人工标注。标注格式我统一输出为YOLO的txt格式每张图片对应一个同名txt文件每一行是类别id 中心点x 中心点y 宽度 高度所有坐标归一化到0-1之间。数据集的目录结构如下datasets/helmet/ ├── images/ │ ├── train/ │ │ ├── img_0001.jpg │ │ └── ... │ └── val/ │ ├── img_1001.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── img_0001.txt │ │ └── ... │ └── val/ │ ├── img_1001.txt │ └── ... └── dataset.yamldataset.yaml里写清楚路径和类别名YOLOv7训练时直接引用这个文件即可。标签内容示例0 0.4832 0.4123 0.2145 0.3567 1 0.5102 0.5208 0.1821 0.2403类别id 0对应person1对应helmet2对应head。这里有一个容易踩的坑标注框不要把所有类别都塞到一个txt里不分格式如果用了COCO格式的JSON需要写脚本转成YOLO格式转换时边界框计算的坐标换算必须仔细校对否则训练出来的模型开局就是歪的。2.4 数据清洗与质量验证数据清洗的重要性我是在吃了亏之后才真正领会的。第一版数据集里有一些图片本身就是模糊的、目标小到人眼都看不清的标注员硬是凭感觉标了出来。这些低质量样本会让模型在训练时收到互相矛盾的梯度信号特别是那些人类专家都很难判断的样本模型学到的是错误特征。我的清洗策略有三条删掉分辨率过低、目标小于16x16像素且人眼无法确认类别的图片去掉重复或高度相似的图片防止数据冗余导致过拟合对标注框做统计检查比如框的宽高比明显异常、超出图像边界负值的通过脚本自动筛查出来人工复核经过清洗后数据集最终保留了8612张图片总标注实例约42000个。其中person约18000个helmet约15000个head约9000个。按8:2划分为训练集和验证集。head实例偏少是因为未佩戴安全帽的样本本身占比低符合真实业务分布——多数情况下大家是规范佩戴的我们要检测的是少数违规情况。2.5 数据增强让模型学会阅读理解而不是死记硬背训练时我在YOLOv7默认的mosaic增强基础上叠加了针对巡检场景的定制增强策略。Mosaic增强会把4张图片随机拼接成一张训练样本好处是让模型在训练时看到更丰富的上下文组合同时增加了小目标的数量。这对电力巡检这种小目标密集的场景尤其有效——远景中的小头目标在mosaic拼接后因为整图被缩小了会有更多机会被模型看见。另外还叠加了水平翻转、随机亮度和对比度调整、轻微的仿射变换。其中亮度和对比度调整尤为重要因为巡检场景的逆光和阴影非常常见。我在训练时把hsv_h设为0.015hsv_s设为0.7hsv_v设为0.4这样模型在训练阶段就见过了各种光照条件下的样本部署时遇到逆光场景的抗性明显提升。3. YOLOv7网络结构与训练配置模型是怎么炼成的3.1 YOLOv7的核心结构亮点E-ELAN和SPPCSPCYOLOv7的网络结构有一个很直观的设计目标在不显著增加推理成本的前提下把特征的表达能力和梯度传递效率做到极致。你去看它的网络结构图最突出的几个模块包括E-ELANExtended Efficient Layer Aggregation Network这是整个Backbone的核心。它通过扩展、打乱、合并多个分支的特征让每一层都能获得更丰富的梯度信息。简单理解就是传统网络的特征流动像一条河越到下游信息越稀释E-ELAN像是把几条支流的水在合适的节点合并起来保证下游仍有水量充足的特征可供使用。SPPCSPC模块这是空间金字塔池化的加强版。它用多个不同尺度的池化核并行处理特征图再把结果融合让网络能同时捕捉到不同感受野的信息。对应到巡检场景就是同一个画面里既有近处的大目标工人又有远处的小目标身影SPPCSPC可以帮助网络在特征层面兼顾这两种尺度。重参数化卷积训练时用多分支结构推理时把多分支重参数化合并成单路卷积在不影响精度的前提下显著提升推理速度。这个设计在部署时非常友好我在导出ONNX之后推理速度比原始PyTorch模型快了将近一倍。3.2 训练环境的搭建与依赖版本训练环境方面我用的是单张NVIDIA RTX 309024GB显存PyTorch 1.13.1CUDA 11.7Python 3.9。如果你用30系或40系显卡注意PyTorch版本和CUDA版本要匹配否则跑起来会出现莫名其妙的报错。YOLOv7官方仓库对PyTorch版本的要求不算苛刻但建议使用1.10以上版本低版本会缺少一些算子支持。克隆仓库之后先看一下requirements.txt里的依赖逐项安装。我遇到过最典型的问题是opencv-python的版本冲突——系统里装了ROS或其他库时OpenCV的版本可能会被覆盖导致训练中途报错cv2找不到特定属性。稳妥做法是在Python虚拟环境里单独安装依赖不要用系统全局环境。3.3 训练参数的选择与调优过程训练参数我用的是YOLOv7官方推荐的配置基础上做的微调。初始学习率0.01权重衰减0.0005动量0.937batch size为16输入分辨率640x640训练了300个epoch。300个epoch在3090上大约跑了14个小时整个训练过程的收敛曲线观察点在loss和mAP的变化上。核心训练命令如下python train.py --workers 4 --batch-size 16 --data datasets/helmet/dataset.yaml \ --cfg cfg/training/yolov7.yaml --epochs 300 --img-size 640 640 \ --name helmet_det --hyp data/hyp.scratch.p5.yaml训练过程中我关注的指标不是总loss而是训练集和验证集的loss差异。如果train loss持续下降但val loss掉头上涨那就是过拟合信号需要提前早停或者加强数据增强。我这个数据集规模训练到300个epoch并没有出现过拟合val loss整体呈现下降趋势说明数据量和增强策略基本够用。还有一个关键细节训练前把预训练权重加上。YOLOv7的backbone在COCO数据集上预训练过的权重对特征提取的初始化要远比随机权重好。用上预训练权重之后模型收敛速度明显加快最终mAP也更高。如果没有预训练权重从零训练的目标检测模型在小数据集上基本不可能有好的表现。3.4 训练过程中的实时监控与问题干预训练时我习惯开两个终端一个跑训练一个定时查看验证集效果。YOLOv7会在训练过程中定期在验证集上做推理并输出带标注框的样本图片。我会每隔几十个epoch去翻一下这些图片重点关注三类问题小目标有没有被检出遮挡场景有没有漏检有没有把非安全帽物体比如安全绳、头顶的线缆误检成安全帽有一次在epoch 120左右我发现验证集里一个施工人员把安全帽拿在手里的画面被模型同时标注出了helmet和head这其实是合理的因为帽子在手里、头没戴帽两个类别同时出现符合标注逻辑。这种case我会在最终后处理规则里仔细斟酌如果同时检到helmet和head到底算戴了还是没戴实际业务逻辑里我会判定为未正确佩戴因为安全帽必须戴在头上才算合规。训练中遇到过一个值得记录的异常训练到第50个epoch左右训练loss突然出现一个尖峰val mAP也小幅回落。排查后发现是当时有人在同一块GPU上跑了一个高负载任务导致显存抢占、训练进程被中断恢复后batch数据错乱。虽然自动恢复了但保险起见我在训练脚本里加了日志保存频率设置每10个epoch就保存一次权重这样即使出问题也不会丢失太多训练进度。4. 模型评估与实测检测效果到底怎么衡量4.1 指标含义与项目验收标准目标检测的评估指标外行看起来是一个数字但项目验收时不能用单一指标糊弄。我向客户汇报时用的指标包含mAP0.5、mAP0.5:0.95、Precision精确率、Recall召回率以及一个业务侧更关心的指标——漏检率。mAP0.5表示IoU阈值0.5下的平均精度均值这是大家最常看的指标mAP0.5:0.95是COCO风格的严格评估IoU从0.5到0.95取十个阈值平均对框的定位精度要求更高Precision是模型报出来的框里面正确框的比例高精确率意味着报出来的基本都是对的——业务上就是告警的准确度Recall是真实目标里被模型找出来的比例高召回率意味着该检出的都检出了——业务上就是对漏检的控制力这个项目的最终评估结果如下指标数值mAP0.50.948mAP0.5:0.950.721Precision0.937Recall0.912客户验收时最关注的是在真实巡检视频上跑一遍把所有未佩戴安全帽的帧挑出来人工核对。实际测试了大约1800帧现场视频共出现未戴安全帽人员37人次模型成功检出34人次漏检3人次漏检全部集中在人员距离镜头超过20米的远景场景。这个结果基本达到了业务可用标准。4.2 实测场景拆解不同距离和光照下的表现差异我把测试视频按场景分类做了细致的拆解得到下表场景类型测试帧数检全率误检率问题表现近景-正常光照42098.6%2.1%整体稳定近景-逆光36095.8%3.9%少量漏检帽檐边缘中景-阴天45097.1%1.8%稳定远景-小目标33084.2%6.1%漏检集中在远景未戴帽夜间-补光24089.6%4.5%颜色特征弱化远景漏检的那三个case事后分析发现是同一个原因目标在640x640的输入图像里只占大约20x20像素person类别能勉强检出但head类别因为头部更小特征不够被判成了背景。后面做了两个优化方向一是把测试时推理的输入分辨率从640提高到960小目标检出明显改善但推理速度会下降约40%二是对图像做tile切块推理把大图切成多块重叠的patch分别检测这个方案对远景小目标效果更好适合离线分析实时视频流上暂时不做。4.3 失败案例分析误报从哪来误检率最高的是非安全帽物体被识别成安全帽的情况。我在数据清洗和后续处理中发现以下几个场景最容易产生误报头戴安全帽样式的矿灯有些头灯的形状和颜色跟安全帽很像模型会犯迷糊肩上扛着的工具箱黄色工具箱在某些角度下与黄色安全帽轮廓相似电线杆上的绝缘子变电站场景里黄色的绝缘子串在某些角度和距离下会被误判为安全帽这些误报的典型特征是类别是helmet的假正例。解决误报的手段我主要用了两条路径。一是补充难例数据——把误报图片挑出来按照实际内容重新标注绝缘子标注为背景不标helmet加入训练集继续训练几轮让模型在难例上纠偏。二是后处理规则——对置信度阈值做针对性调整比如helmet类别的阈值从0.25提高到0.35head类别保持0.25。提阈值的代价是召回率会有小幅下降但因为helmet目标的置信度分布整体偏高这个trade-off是划算的。5. 部署落地把模型接到巡检业务中要过的几道关5.1 模型导出从PyTorch到ONNX训练好的模型要接到业务系统里第一步是导出为通用的模型格式。我选择导出ONNX因为它对部署平台的兼容性最好可以转成TensorRT、OpenVINO或者直接用ONNX Runtime推理。我使用的导出命令是YOLOv7官方仓库提供的python export.py --weights runs/train/helmet_det/weights/best.pt \ --grid --simplify --img-size 640 640 --batch-size 1导出后有两点必须验证一是输出形状YOLOv7的ONNX输出是一个三维张量[1, 25200, 6]其中25200是三个检测层的预测框总数640x640输入下计算得来6表示4个坐标1个置信度1个类别数。如果你训练的是3个类别最后输出维度是[1, 25200, 6]如果类别数变了这个6要相应调整。二是数值一致性用同一张图在PyTorch和ONNX Runtime下分别推理输出框的差异应该在很小的数值范围内否则说明导出过程有问题。5.2 推理脚本一张图的完整检测流程部署推理我编写了一个轻量级的Python脚本核心流程是读取图像→预处理→模型推理→后处理→绘制结果。其中后处理的细节决定了输出质量的稳定性。实际代码如下import cv2 import numpy as np import onnxruntime as ort class HelmetDetector: def __init__(self, onnx_path, conf_thres0.25, iou_thres0.45): self.session ort.InferenceSession(onnx_path) self.conf_thres conf_thres self.iou_thres iou_thres self.class_names [person, helmet, head] def preprocess(self, img, size640): h, w img.shape[:2] scale min(size / w, size / h) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(img, (new_w, new_h)) canvas np.full((size, size, 3), 114, dtypenp.uint8) canvas[:new_h, :new_w] resized input_data canvas[:, :, ::-1].transpose(2, 0, 1).astype(np.float32) / 255.0 input_data np.expand_dims(input_data, axis0) return input_data, scale, new_w, new_h def postprocess(self, outputs, scale, new_w, new_h, orig_shape): predictions outputs[0][0] boxes, scores, class_ids [], [], [] # 过滤低置信度框 mask predictions[:, 4] self.conf_thres predictions predictions[mask] for pred in predictions: cx, cy, bw, bh pred[:4] score pred[4] class_id int(pred[5]) if score self.conf_thres: continue # 还原到原图坐标 cx, cy, bw, bh cx / scale, cy / scale, bw / scale, bh / scale x1 cx - bw / 2 y1 cy - bh / 2 x2 cx bw / 2 y2 cy bh / 2 boxes.append([x1, y1, x2, y2]) scores.append(score) class_ids.append(class_id) # NMS indices cv2.dnn.NMSBoxes(boxes, scores, self.conf_thres, self.iou_thres) results [] for i in indices.flatten(): results.append({ box: boxes[i], score: float(scores[i]), class_id: class_ids[i], class_name: self.class_names[class_ids[i]] }) return results def predict(self, img): input_data, scale, new_w, new_h self.preprocess(img) outputs self.session.run(None, {self.session.get_inputs()[0].name: input_data}) return self.postprocess(outputs, scale, new_w, new_h, img.shape)这段代码里有两个细节值得注意。一是preprocess里用灰色画布114填充而不是纯黑色这是YOLO系列训练时的默认填充值与预训练权重对输入分布的期望一致。二是NMS我直接用了OpenCV的cv2.dnn.NMSBoxes它和YOLOv7训练时用的torchvision.ops.nms在效果上基本等价但不需要额外依赖PyTorch部署时更轻量。5.3 视频流接入与告警联动在真实电力巡检业务中输入更多是RTSP视频流或定时抓拍图片。我的部署方案里视频流处理使用独立线程读取帧推送到检测线程检测结果封装成JSON消息发布到业务系统的消息队列实现告警联动。核心处理循环如下def process_stream(rtsp_url, detector, frame_skip2): cap cv2.VideoCapture(rtsp_url) frame_count 0 while True: ret, frame cap.read() if not ret: break frame_count 1 if frame_count % frame_skip ! 0: continue results detector.predict(frame) # 将检测结果发送到告警系统 if any(r[class_name] head for r in results): send_alert(frame, results, timestamptime.time()) # 可选绘制结果 for r in results: x1, y1, x2, y2 map(int, r[box]) color (0, 0, 255) if r[class_name] head else (0, 255, 0) cv2.rectangle(frame, (x1, y1), (x2, y2), color, 2) label f{r[class_name]} {r[score]:.2f} cv2.putText(frame, label, (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 1, cv2.LINE_AA)这里frame_skip参数很实用。25fps的流如果每帧都检测对CPU的压力会很大每2帧检测一次丢掉的检测粒度用运动连续性来弥补在大多数巡检场景中都是可接受的。GPU推理可以保持每帧检测CPU推理就必须做跳帧策略具体跳几帧要根据检测耗时动态调整。5.4 推理性能调优CPU和GPU下的参数差异部署环境不同性能调优策略差异很大。我在实际部署中测过两组环境结果供参考环境推理耗时/帧可支撑的流路数备注GPURTX 3060 TensorRT FP16约11ms4-6路并行最推荐方案GPURTX 3060 ONNX Runtime约28ms2路并行简单但性能一般CPUi7-10700 ONNX Runtime约180ms1路跳帧只能用于离线图片CPUi7-10700 OpenVINO约95ms1路需要额外转换CPU上如果要用OpenVINO需要把ONNX模型再转成IR格式中间会有一些算子兼容性问题。如果你的部署环境已经装了Intel的OpenVINO工具包转换成本不算高但我个人建议是要是条件允许尽量走GPU方案那种推理延迟的差距是质的区别直接影响告警的实时性。5.5 业务告警规则的后处理逻辑模型只输出人头、帽子、人三类距离可直接用的告警规则还有一步后处理。我最终采用的判断逻辑如果同时检到person和helmet且helmet框的中心点落在person框的头部区域判定为已佩戴如果检到head判定为未佩戴如果检到person但没有helmet也没有head判定为不确定不触发告警如果同一画面出现多个person逐个判断这套规则的不确定分支是重要的安全阀。因为电力巡检场景下人员可能背对镜头头部被完全遮挡这时候模型很难给出可靠的判断。与其硬报一个未佩戴导致误告警不如让业务方人工确认。我在实际项目中发现加了不确定这个档位之后客户对系统的信任度反而提升了因为他们看到的告警基本都是准确的。6. 项目复盘那些踩过的坑和后续迭代的方向6.1 标注质量对模型上限的影响比想象中大得多第一版模型训出来后mAP只有0.72我在排查过程中一项项检查最后发现是标注数据里有相当比例的框存在偏差。有几个标注员把安全帽戴在头上的框画得比实际帽子大一圈把额头的皮肤和耳朵都包进去了。这样会导致模型学习到的helmet特征里混入了大量人脸肤色的上下文在没戴帽子但肤色可见时误报率显著上升。这个教训总结下来就是数据标注不是简单的画框标注规范必须写得极其具体并且要用抽检机制做质量控制。后来我制定了严格的标注规范包括帽子框必须紧贴帽檐和帽壳外缘不含头发和皮肤被遮挡超过30%的目标不标置信度存疑的目标不标且每批标注完成后从不同标注员的产出中各抽20%互相交叉验证。6.2 类别不平衡问题的处理技巧这个项目的三类数据天然不平衡person最多helmet次之head最少。head作为最需要被检出的类别却是样本最少的。这里我用了一个代价较小的平衡策略在loss计算层面给head类别增加一点权重在数据层面对head类别样本做了过采样让它在每个epoch中都能被充分看到。实际操作用的是data/hyp.scratch.p5.yaml里的类别权重配置把head类别的loss权重调高到1.2倍。这个微调让head类别的召回率从0.853提高到了0.912而helmet类别的精度几乎没有下降。如果遇到更极端的类别不平衡也可以考虑focal loss但在这个项目中简单的权重调整已经够用了。6.3 后续迭代方向小模型、蒸馏和更细粒度项目交付之后我在思考后续的几个迭代方向。第一个是模型轻量化——用YOLOv7-tiny或者做通道剪枝目标是让模型在边缘计算盒子上跑得更流畅。实测YOLOv7-tiny在同样的数据集上mAP约0.88比完整版降低了约6个百分点但推理速度快了一倍多在部分对实时性要求高但精度容忍度大的场景反而更合适。第二个方向是知识蒸馏——用大模型当teacher小模型当student白嫖大模型的暗知识。我在一个内部对比实验里试过用完整YOLOv7蒸馏YOLOv7-tiny可以把tiny的mAP从0.88提升到0.90左右且推理速度不变。这个提升在精度敏感的巡检场景是值得的。第三个方向是从检测升级到细粒度分析——比如识别安全帽的类型、颜色、磨损程度或者判断安全帽是否系好下颏带。这些需求听着远但业务侧已经开始提了说明整个行业正在从有无检测走向质量评估。6.4 算力不足时的训练策略如果你的GPU显存没到24GB也不用慌。我实测过用RTX 3060 12GB显存训练只要把batch size降到8输入分辨率降到512x512照样能跑出可用的模型只是精度会略有下降。如果连GPU都没有可以考虑云GPU按小时租用训练整个项目大约需要14-20小时成本是可控的。显存不足的另一个方案是梯度累积YOLOv7的train.py里可以直接设置--batch-size 4然后累积4次梯度相当于batch size 16的效果但训练时间会变长。这套方法适合调试阶段快速验证模型能否收敛正式训练还是建议用完整显存跑。经过完整走一遍这个项目我最大的感受是目标检测项目的难不是难在训练模型而是难在数据治理、场景理解和工程化交付这几个环节。数据集的构建决定了模型的精度上限训练参数决定了下限而部署后处理则直接影响业务方对系统的信任。希望这篇项目管理式的技术复盘能给正在做类似巡检检测项目的你提供一条可参考的路径。本文还有配套的精品资源点击获取 YOLOv7电力巡检安全帽检测：从数据标注到部署的全流程实战
简介本资源面向电力行业智能巡检开发者、计算机视觉初学者及工业安全AI落地实践者提供一套开箱即用的YOLOv7安全帽佩戴检测完整方案专用于识别电塔、电线杆等高危作业场景中工人是否规范佩戴安全帽切实支撑安全生产监管需求。压缩包共886个文件305.7MB含295张标注图像jpg、295份PASCAL VOC格式XML标注文件与296个对应YOLO格式txt标签覆盖多角度、多光照、遮挡及小目标典型工况模型已训练收敛PR曲线、混淆矩阵等评估结果均保存于runs文件夹配套代码支持一键推理与可视化。目前已有453人学习下载资源结构清晰无需重新标注或调参即可直接部署验证显著降低电力AI巡检项目的技术门槛与验证周期。 在电力巡检现场安全帽佩戴检测是个老需求但真正把检测模型做到能落地尤其是把数据、训练、部署整个链路跑通中间的细节远比大多数人预想的多。这篇文章记录的是一个完整的YOLOv7电力巡检安全帽检测项目包含标注好的数据集、训练好的检测模型和从零到一的训练部署全流程适合正在做目标检测落地、或者想找一套现成方案参考的开发者。项目核心思路很简单用YOLOv7在电力巡检场景下识别人员是否佩戴安全帽输出检测框和类别为后续告警、审核提供视觉基础能力实际项目交付时把数据集、权重和推理脚本一起给到使用方才算是真正能用的完整方案。1. 电力巡检安全帽检测的现场痛点为什么通用模型不够用1.1 巡检场景的特殊性小目标、遮挡、逆光一起上电力巡检和普通工地安全帽检测的差异一开始我其实低估了。普通工地场景工人离镜头近、目标大、背景相对均匀一套通用COCO权重里的person类也能勉强跑出个大概。但电力巡检不一样——杆塔上的作业人员离地面好几米无人机或手持摄像机拍到的目标往往只有几十个像素变电站里设备密集人员身体被设备遮挡的情况严重户外巡检还会遇到逆光、阴天、夜间补光、雨雾等复杂光照条件。用通用检测模型做这一场景漏检率会高到业务无法接受。安全帽检测本质上是一个细粒度目标检测问题。它不是是不是人这种粗粒度判断而是这个人有没有戴安全帽的精细判断。戴了安全帽的人远看轮廓和没戴的人差别极小加上巡检场景中人员姿态多变——低头看仪表、弯腰操作、攀爬杆塔——模型如果没有针对性的数据喂养很容易把没戴误判成戴了或者干脆漏掉。1.2 业务侧的真实需求从检出到可告警现场业务部门提需求时不会说我要一个mAP 90%的模型他们说的是我们要能自动发现谁没戴安全帽最好能截图留证能导出记录。这句看似简单的话翻译成技术需求至少包含三层检测模型要输出稳定的类别和置信度不能一会儿识别出一会儿识别不出要有工程化接口能接收视频流或图片输出结构化结果误报要控制在可接受范围内否则每天几百条假告警会直接被客户关掉所以我做这个项目时没有只停留在训练个模型出来的层面而是把模型数据推理脚本部署说明作为整体交付。这也是为什么我把训练好的检测模型和标注好的数据集同时作为项目核心资产——模型可以复现数据可以扩展这才是长期可维护的交付物。1.3 项目目标与整体技术选型针对上述场景我把项目目标拆成了三条构建一套覆盖电力巡检常见场景的安全帽检测数据集标注质量达到可直接训练的标准基于YOLOv7训练出精度和速度都满足巡检业务需求的检测模型提供开箱即用的推理代码支持图片、视频、RTSP流三种输入方式选型YOLOv7而不是其他算法核心考量是三点一是YOLOv7在同等算力下精度和速度的平衡性比较好在2022年被提出时刷新了当时实时检测器的SOTA结构上对边缘设备也相对友好二是社区生态成熟训练、导出、部署的上下游工具链完整遇到问题能找到人问三是模型结构的设计思路非常有学习价值比如E-ELAN和重参数化卷积这些思路对后续做其他检测任务也有迁移价值。2. 数据是天花板标注好的数据集到底该怎么建2.1 数据采集渠道与场景覆盖策略这个项目的原始数据来自三个渠道一部分是客户提供的变电站和输电线路巡检历史图片这部分最有价值因为真实场景的分布是任何公开数据集替代不了的一部分是项目组自己到现场用相机和手机拍的补充了不同角度、不同距离、不同光线条件下的样本还有一部分是从公开数据集和网络上筛选的电力作业相关图片用于扩充多样性。在数据采集阶段就要有场景覆盖清单的意识。我当时列了一下大概是这样的维度矩阵维度覆盖要求距离近景3米、中景3-10米、远景10米光照白天强光、逆光、阴天、夜间补光姿态正面、侧面、背面、低头、蹲姿、攀爬遮挡无遮挡、半身遮挡、设备遮挡、多人密集场景变电站、杆塔、线缆走廊、施工围栏每个维度至少要保证一定比例的样本尤其是容易漏检的远景和逆光场景。最开始我犯过一个错误——数据大部分是近景和正面照训练出来的模型在测试集上mAP看起来很高但一拿到现场视频就露馅了远距离小目标几乎全漏。后来补了一批远景样本漏检率才明显下降。2.2 标注类别的设计两个类还是三个类安全帽检测的标注类别设计是个容易被忽视、但影响非常大的决策。业界常见有两种方案两种类别person人、helmet安全帽三种类别person人、helmet安全帽、head未戴帽的头两种类别的做法逻辑是检测到人之后再看他身边有没有安全帽的框。问题在于人没戴帽时无帽的头部区域没有对应的正样本模型学到的是这附近有没有帽子的共现关系而不是这个人头上有没有帽子的因果关系。如果两个人挨得近一个戴帽一个没戴这个方案会给是否佩戴的判断带来歧义。三种类别的做法是我实际采用的方案。把未佩戴安全帽的头部作为一个独立的head类模型需要同时区分helmet和head这两个语义相反的类别决策边界更加明确。推理的时候判断规则很简单检到person且有helmet且无head判定为佩戴检到head判定为未佩戴。这种后处理逻辑非常干净误判率低而且便于业务侧理解。2.3 标注工具与格式转换标注工具我用的是LabelImg它足够简单标注速度也快在大量真实图片重复标注时效率很关键。如果你更习惯半自动标注流程可以先用LabelStudio或者X-AnyLabeling配合基础模型做预标注人工做修正能省下不少时间。但预标注的质量参差不齐后期校对成本可能反而更高小规模数据我建议直接人工标注。标注格式我统一输出为YOLO的txt格式每张图片对应一个同名txt文件每一行是类别id 中心点x 中心点y 宽度 高度所有坐标归一化到0-1之间。数据集的目录结构如下datasets/helmet/ ├── images/ │ ├── train/ │ │ ├── img_0001.jpg │ │ └── ... │ └── val/ │ ├── img_1001.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── img_0001.txt │ │ └── ... │ └── val/ │ ├── img_1001.txt │ └── ... └── dataset.yamldataset.yaml里写清楚路径和类别名YOLOv7训练时直接引用这个文件即可。标签内容示例0 0.4832 0.4123 0.2145 0.3567 1 0.5102 0.5208 0.1821 0.2403类别id 0对应person1对应helmet2对应head。这里有一个容易踩的坑标注框不要把所有类别都塞到一个txt里不分格式如果用了COCO格式的JSON需要写脚本转成YOLO格式转换时边界框计算的坐标换算必须仔细校对否则训练出来的模型开局就是歪的。2.4 数据清洗与质量验证数据清洗的重要性我是在吃了亏之后才真正领会的。第一版数据集里有一些图片本身就是模糊的、目标小到人眼都看不清的标注员硬是凭感觉标了出来。这些低质量样本会让模型在训练时收到互相矛盾的梯度信号特别是那些人类专家都很难判断的样本模型学到的是错误特征。我的清洗策略有三条删掉分辨率过低、目标小于16x16像素且人眼无法确认类别的图片去掉重复或高度相似的图片防止数据冗余导致过拟合对标注框做统计检查比如框的宽高比明显异常、超出图像边界负值的通过脚本自动筛查出来人工复核经过清洗后数据集最终保留了8612张图片总标注实例约42000个。其中person约18000个helmet约15000个head约9000个。按8:2划分为训练集和验证集。head实例偏少是因为未佩戴安全帽的样本本身占比低符合真实业务分布——多数情况下大家是规范佩戴的我们要检测的是少数违规情况。2.5 数据增强让模型学会阅读理解而不是死记硬背训练时我在YOLOv7默认的mosaic增强基础上叠加了针对巡检场景的定制增强策略。Mosaic增强会把4张图片随机拼接成一张训练样本好处是让模型在训练时看到更丰富的上下文组合同时增加了小目标的数量。这对电力巡检这种小目标密集的场景尤其有效——远景中的小头目标在mosaic拼接后因为整图被缩小了会有更多机会被模型看见。另外还叠加了水平翻转、随机亮度和对比度调整、轻微的仿射变换。其中亮度和对比度调整尤为重要因为巡检场景的逆光和阴影非常常见。我在训练时把hsv_h设为0.015hsv_s设为0.7hsv_v设为0.4这样模型在训练阶段就见过了各种光照条件下的样本部署时遇到逆光场景的抗性明显提升。3. YOLOv7网络结构与训练配置模型是怎么炼成的3.1 YOLOv7的核心结构亮点E-ELAN和SPPCSPCYOLOv7的网络结构有一个很直观的设计目标在不显著增加推理成本的前提下把特征的表达能力和梯度传递效率做到极致。你去看它的网络结构图最突出的几个模块包括E-ELANExtended Efficient Layer Aggregation Network这是整个Backbone的核心。它通过扩展、打乱、合并多个分支的特征让每一层都能获得更丰富的梯度信息。简单理解就是传统网络的特征流动像一条河越到下游信息越稀释E-ELAN像是把几条支流的水在合适的节点合并起来保证下游仍有水量充足的特征可供使用。SPPCSPC模块这是空间金字塔池化的加强版。它用多个不同尺度的池化核并行处理特征图再把结果融合让网络能同时捕捉到不同感受野的信息。对应到巡检场景就是同一个画面里既有近处的大目标工人又有远处的小目标身影SPPCSPC可以帮助网络在特征层面兼顾这两种尺度。重参数化卷积训练时用多分支结构推理时把多分支重参数化合并成单路卷积在不影响精度的前提下显著提升推理速度。这个设计在部署时非常友好我在导出ONNX之后推理速度比原始PyTorch模型快了将近一倍。3.2 训练环境的搭建与依赖版本训练环境方面我用的是单张NVIDIA RTX 309024GB显存PyTorch 1.13.1CUDA 11.7Python 3.9。如果你用30系或40系显卡注意PyTorch版本和CUDA版本要匹配否则跑起来会出现莫名其妙的报错。YOLOv7官方仓库对PyTorch版本的要求不算苛刻但建议使用1.10以上版本低版本会缺少一些算子支持。克隆仓库之后先看一下requirements.txt里的依赖逐项安装。我遇到过最典型的问题是opencv-python的版本冲突——系统里装了ROS或其他库时OpenCV的版本可能会被覆盖导致训练中途报错cv2找不到特定属性。稳妥做法是在Python虚拟环境里单独安装依赖不要用系统全局环境。3.3 训练参数的选择与调优过程训练参数我用的是YOLOv7官方推荐的配置基础上做的微调。初始学习率0.01权重衰减0.0005动量0.937batch size为16输入分辨率640x640训练了300个epoch。300个epoch在3090上大约跑了14个小时整个训练过程的收敛曲线观察点在loss和mAP的变化上。核心训练命令如下python train.py --workers 4 --batch-size 16 --data datasets/helmet/dataset.yaml \ --cfg cfg/training/yolov7.yaml --epochs 300 --img-size 640 640 \ --name helmet_det --hyp data/hyp.scratch.p5.yaml训练过程中我关注的指标不是总loss而是训练集和验证集的loss差异。如果train loss持续下降但val loss掉头上涨那就是过拟合信号需要提前早停或者加强数据增强。我这个数据集规模训练到300个epoch并没有出现过拟合val loss整体呈现下降趋势说明数据量和增强策略基本够用。还有一个关键细节训练前把预训练权重加上。YOLOv7的backbone在COCO数据集上预训练过的权重对特征提取的初始化要远比随机权重好。用上预训练权重之后模型收敛速度明显加快最终mAP也更高。如果没有预训练权重从零训练的目标检测模型在小数据集上基本不可能有好的表现。3.4 训练过程中的实时监控与问题干预训练时我习惯开两个终端一个跑训练一个定时查看验证集效果。YOLOv7会在训练过程中定期在验证集上做推理并输出带标注框的样本图片。我会每隔几十个epoch去翻一下这些图片重点关注三类问题小目标有没有被检出遮挡场景有没有漏检有没有把非安全帽物体比如安全绳、头顶的线缆误检成安全帽有一次在epoch 120左右我发现验证集里一个施工人员把安全帽拿在手里的画面被模型同时标注出了helmet和head这其实是合理的因为帽子在手里、头没戴帽两个类别同时出现符合标注逻辑。这种case我会在最终后处理规则里仔细斟酌如果同时检到helmet和head到底算戴了还是没戴实际业务逻辑里我会判定为未正确佩戴因为安全帽必须戴在头上才算合规。训练中遇到过一个值得记录的异常训练到第50个epoch左右训练loss突然出现一个尖峰val mAP也小幅回落。排查后发现是当时有人在同一块GPU上跑了一个高负载任务导致显存抢占、训练进程被中断恢复后batch数据错乱。虽然自动恢复了但保险起见我在训练脚本里加了日志保存频率设置每10个epoch就保存一次权重这样即使出问题也不会丢失太多训练进度。4. 模型评估与实测检测效果到底怎么衡量4.1 指标含义与项目验收标准目标检测的评估指标外行看起来是一个数字但项目验收时不能用单一指标糊弄。我向客户汇报时用的指标包含mAP0.5、mAP0.5:0.95、Precision精确率、Recall召回率以及一个业务侧更关心的指标——漏检率。mAP0.5表示IoU阈值0.5下的平均精度均值这是大家最常看的指标mAP0.5:0.95是COCO风格的严格评估IoU从0.5到0.95取十个阈值平均对框的定位精度要求更高Precision是模型报出来的框里面正确框的比例高精确率意味着报出来的基本都是对的——业务上就是告警的准确度Recall是真实目标里被模型找出来的比例高召回率意味着该检出的都检出了——业务上就是对漏检的控制力这个项目的最终评估结果如下指标数值mAP0.50.948mAP0.5:0.950.721Precision0.937Recall0.912客户验收时最关注的是在真实巡检视频上跑一遍把所有未佩戴安全帽的帧挑出来人工核对。实际测试了大约1800帧现场视频共出现未戴安全帽人员37人次模型成功检出34人次漏检3人次漏检全部集中在人员距离镜头超过20米的远景场景。这个结果基本达到了业务可用标准。4.2 实测场景拆解不同距离和光照下的表现差异我把测试视频按场景分类做了细致的拆解得到下表场景类型测试帧数检全率误检率问题表现近景-正常光照42098.6%2.1%整体稳定近景-逆光36095.8%3.9%少量漏检帽檐边缘中景-阴天45097.1%1.8%稳定远景-小目标33084.2%6.1%漏检集中在远景未戴帽夜间-补光24089.6%4.5%颜色特征弱化远景漏检的那三个case事后分析发现是同一个原因目标在640x640的输入图像里只占大约20x20像素person类别能勉强检出但head类别因为头部更小特征不够被判成了背景。后面做了两个优化方向一是把测试时推理的输入分辨率从640提高到960小目标检出明显改善但推理速度会下降约40%二是对图像做tile切块推理把大图切成多块重叠的patch分别检测这个方案对远景小目标效果更好适合离线分析实时视频流上暂时不做。4.3 失败案例分析误报从哪来误检率最高的是非安全帽物体被识别成安全帽的情况。我在数据清洗和后续处理中发现以下几个场景最容易产生误报头戴安全帽样式的矿灯有些头灯的形状和颜色跟安全帽很像模型会犯迷糊肩上扛着的工具箱黄色工具箱在某些角度下与黄色安全帽轮廓相似电线杆上的绝缘子变电站场景里黄色的绝缘子串在某些角度和距离下会被误判为安全帽这些误报的典型特征是类别是helmet的假正例。解决误报的手段我主要用了两条路径。一是补充难例数据——把误报图片挑出来按照实际内容重新标注绝缘子标注为背景不标helmet加入训练集继续训练几轮让模型在难例上纠偏。二是后处理规则——对置信度阈值做针对性调整比如helmet类别的阈值从0.25提高到0.35head类别保持0.25。提阈值的代价是召回率会有小幅下降但因为helmet目标的置信度分布整体偏高这个trade-off是划算的。5. 部署落地把模型接到巡检业务中要过的几道关5.1 模型导出从PyTorch到ONNX训练好的模型要接到业务系统里第一步是导出为通用的模型格式。我选择导出ONNX因为它对部署平台的兼容性最好可以转成TensorRT、OpenVINO或者直接用ONNX Runtime推理。我使用的导出命令是YOLOv7官方仓库提供的python export.py --weights runs/train/helmet_det/weights/best.pt \ --grid --simplify --img-size 640 640 --batch-size 1导出后有两点必须验证一是输出形状YOLOv7的ONNX输出是一个三维张量[1, 25200, 6]其中25200是三个检测层的预测框总数640x640输入下计算得来6表示4个坐标1个置信度1个类别数。如果你训练的是3个类别最后输出维度是[1, 25200, 6]如果类别数变了这个6要相应调整。二是数值一致性用同一张图在PyTorch和ONNX Runtime下分别推理输出框的差异应该在很小的数值范围内否则说明导出过程有问题。5.2 推理脚本一张图的完整检测流程部署推理我编写了一个轻量级的Python脚本核心流程是读取图像→预处理→模型推理→后处理→绘制结果。其中后处理的细节决定了输出质量的稳定性。实际代码如下import cv2 import numpy as np import onnxruntime as ort class HelmetDetector: def __init__(self, onnx_path, conf_thres0.25, iou_thres0.45): self.session ort.InferenceSession(onnx_path) self.conf_thres conf_thres self.iou_thres iou_thres self.class_names [person, helmet, head] def preprocess(self, img, size640): h, w img.shape[:2] scale min(size / w, size / h) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(img, (new_w, new_h)) canvas np.full((size, size, 3), 114, dtypenp.uint8) canvas[:new_h, :new_w] resized input_data canvas[:, :, ::-1].transpose(2, 0, 1).astype(np.float32) / 255.0 input_data np.expand_dims(input_data, axis0) return input_data, scale, new_w, new_h def postprocess(self, outputs, scale, new_w, new_h, orig_shape): predictions outputs[0][0] boxes, scores, class_ids [], [], [] # 过滤低置信度框 mask predictions[:, 4] self.conf_thres predictions predictions[mask] for pred in predictions: cx, cy, bw, bh pred[:4] score pred[4] class_id int(pred[5]) if score self.conf_thres: continue # 还原到原图坐标 cx, cy, bw, bh cx / scale, cy / scale, bw / scale, bh / scale x1 cx - bw / 2 y1 cy - bh / 2 x2 cx bw / 2 y2 cy bh / 2 boxes.append([x1, y1, x2, y2]) scores.append(score) class_ids.append(class_id) # NMS indices cv2.dnn.NMSBoxes(boxes, scores, self.conf_thres, self.iou_thres) results [] for i in indices.flatten(): results.append({ box: boxes[i], score: float(scores[i]), class_id: class_ids[i], class_name: self.class_names[class_ids[i]] }) return results def predict(self, img): input_data, scale, new_w, new_h self.preprocess(img) outputs self.session.run(None, {self.session.get_inputs()[0].name: input_data}) return self.postprocess(outputs, scale, new_w, new_h, img.shape)这段代码里有两个细节值得注意。一是preprocess里用灰色画布114填充而不是纯黑色这是YOLO系列训练时的默认填充值与预训练权重对输入分布的期望一致。二是NMS我直接用了OpenCV的cv2.dnn.NMSBoxes它和YOLOv7训练时用的torchvision.ops.nms在效果上基本等价但不需要额外依赖PyTorch部署时更轻量。5.3 视频流接入与告警联动在真实电力巡检业务中输入更多是RTSP视频流或定时抓拍图片。我的部署方案里视频流处理使用独立线程读取帧推送到检测线程检测结果封装成JSON消息发布到业务系统的消息队列实现告警联动。核心处理循环如下def process_stream(rtsp_url, detector, frame_skip2): cap cv2.VideoCapture(rtsp_url) frame_count 0 while True: ret, frame cap.read() if not ret: break frame_count 1 if frame_count % frame_skip ! 0: continue results detector.predict(frame) # 将检测结果发送到告警系统 if any(r[class_name] head for r in results): send_alert(frame, results, timestamptime.time()) # 可选绘制结果 for r in results: x1, y1, x2, y2 map(int, r[box]) color (0, 0, 255) if r[class_name] head else (0, 255, 0) cv2.rectangle(frame, (x1, y1), (x2, y2), color, 2) label f{r[class_name]} {r[score]:.2f} cv2.putText(frame, label, (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, color, 1, cv2.LINE_AA)这里frame_skip参数很实用。25fps的流如果每帧都检测对CPU的压力会很大每2帧检测一次丢掉的检测粒度用运动连续性来弥补在大多数巡检场景中都是可接受的。GPU推理可以保持每帧检测CPU推理就必须做跳帧策略具体跳几帧要根据检测耗时动态调整。5.4 推理性能调优CPU和GPU下的参数差异部署环境不同性能调优策略差异很大。我在实际部署中测过两组环境结果供参考环境推理耗时/帧可支撑的流路数备注GPURTX 3060 TensorRT FP16约11ms4-6路并行最推荐方案GPURTX 3060 ONNX Runtime约28ms2路并行简单但性能一般CPUi7-10700 ONNX Runtime约180ms1路跳帧只能用于离线图片CPUi7-10700 OpenVINO约95ms1路需要额外转换CPU上如果要用OpenVINO需要把ONNX模型再转成IR格式中间会有一些算子兼容性问题。如果你的部署环境已经装了Intel的OpenVINO工具包转换成本不算高但我个人建议是要是条件允许尽量走GPU方案那种推理延迟的差距是质的区别直接影响告警的实时性。5.5 业务告警规则的后处理逻辑模型只输出人头、帽子、人三类距离可直接用的告警规则还有一步后处理。我最终采用的判断逻辑如果同时检到person和helmet且helmet框的中心点落在person框的头部区域判定为已佩戴如果检到head判定为未佩戴如果检到person但没有helmet也没有head判定为不确定不触发告警如果同一画面出现多个person逐个判断这套规则的不确定分支是重要的安全阀。因为电力巡检场景下人员可能背对镜头头部被完全遮挡这时候模型很难给出可靠的判断。与其硬报一个未佩戴导致误告警不如让业务方人工确认。我在实际项目中发现加了不确定这个档位之后客户对系统的信任度反而提升了因为他们看到的告警基本都是准确的。6. 项目复盘那些踩过的坑和后续迭代的方向6.1 标注质量对模型上限的影响比想象中大得多第一版模型训出来后mAP只有0.72我在排查过程中一项项检查最后发现是标注数据里有相当比例的框存在偏差。有几个标注员把安全帽戴在头上的框画得比实际帽子大一圈把额头的皮肤和耳朵都包进去了。这样会导致模型学习到的helmet特征里混入了大量人脸肤色的上下文在没戴帽子但肤色可见时误报率显著上升。这个教训总结下来就是数据标注不是简单的画框标注规范必须写得极其具体并且要用抽检机制做质量控制。后来我制定了严格的标注规范包括帽子框必须紧贴帽檐和帽壳外缘不含头发和皮肤被遮挡超过30%的目标不标置信度存疑的目标不标且每批标注完成后从不同标注员的产出中各抽20%互相交叉验证。6.2 类别不平衡问题的处理技巧这个项目的三类数据天然不平衡person最多helmet次之head最少。head作为最需要被检出的类别却是样本最少的。这里我用了一个代价较小的平衡策略在loss计算层面给head类别增加一点权重在数据层面对head类别样本做了过采样让它在每个epoch中都能被充分看到。实际操作用的是data/hyp.scratch.p5.yaml里的类别权重配置把head类别的loss权重调高到1.2倍。这个微调让head类别的召回率从0.853提高到了0.912而helmet类别的精度几乎没有下降。如果遇到更极端的类别不平衡也可以考虑focal loss但在这个项目中简单的权重调整已经够用了。6.3 后续迭代方向小模型、蒸馏和更细粒度项目交付之后我在思考后续的几个迭代方向。第一个是模型轻量化——用YOLOv7-tiny或者做通道剪枝目标是让模型在边缘计算盒子上跑得更流畅。实测YOLOv7-tiny在同样的数据集上mAP约0.88比完整版降低了约6个百分点但推理速度快了一倍多在部分对实时性要求高但精度容忍度大的场景反而更合适。第二个方向是知识蒸馏——用大模型当teacher小模型当student白嫖大模型的暗知识。我在一个内部对比实验里试过用完整YOLOv7蒸馏YOLOv7-tiny可以把tiny的mAP从0.88提升到0.90左右且推理速度不变。这个提升在精度敏感的巡检场景是值得的。第三个方向是从检测升级到细粒度分析——比如识别安全帽的类型、颜色、磨损程度或者判断安全帽是否系好下颏带。这些需求听着远但业务侧已经开始提了说明整个行业正在从有无检测走向质量评估。6.4 算力不足时的训练策略如果你的GPU显存没到24GB也不用慌。我实测过用RTX 3060 12GB显存训练只要把batch size降到8输入分辨率降到512x512照样能跑出可用的模型只是精度会略有下降。如果连GPU都没有可以考虑云GPU按小时租用训练整个项目大约需要14-20小时成本是可控的。显存不足的另一个方案是梯度累积YOLOv7的train.py里可以直接设置--batch-size 4然后累积4次梯度相当于batch size 16的效果但训练时间会变长。这套方法适合调试阶段快速验证模型能否收敛正式训练还是建议用完整显存跑。经过完整走一遍这个项目我最大的感受是目标检测项目的难不是难在训练模型而是难在数据治理、场景理解和工程化交付这几个环节。数据集的构建决定了模型的精度上限训练参数决定了下限而部署后处理则直接影响业务方对系统的信任。希望这篇项目管理式的技术复盘能给正在做类似巡检检测项目的你提供一条可参考的路径。本文还有配套的精品资源点击获取