简介这套数据集面向计算机视觉开发者和安全生产管理场景专为安全帽、安全服反光背心佩戴检测任务设计已采用YOLOV9格式完成全部标注可直接用于目标检测模型的训练与评估。图片采集自固定摄像头、人员通道、现场录制片段等多样真实环境覆盖白天不同日期与设备视角包含单人、多人及不同姿态组合预处理阶段已应用自动定向并统一缩放至1280×720黑边尺寸有效降低输入差异。压缩包共2000个文件其中1955个txt为YOLO格式标签文件44个jpg为原始示例图片1个yaml为数据集配置与类别说明整体大小约193.07MB目录结构清晰便于直接划分训练集和验证集。已有855人学习下载。借助该数据集可快速搭建造价合理的施工现场安全装备检测方案适配智能巡检、视频监控、出入口闸机等应用场景省去从零采集、清洗和手动标注的繁琐过程尤其适合有一定YOLO基础、希望用真实数据提升泛化能力的算法工程师和研究人员。1. 安全帽与反光背心检测拿到 2000 多张 YOLOv9 标注图先别急着训练一个“安全帽和安全服反光背心检测-YOLOV9标记2000多张图被标记”的数据包听上去是现成的标注齐了模型框架也定好了拉下来训练就行。但我在做工业安防和工地智能化项目时踩过太多次真正的分水岭其实从拿到这批标注图才刚开始。标注的类别是否统一、反光服过曝区域的框是否画偏、小目标安全帽有没有漏标这些问题不解决后面训练出来的 mAP 会从 85% 一路掉到 65%。这篇文章把这个方向的完整路径拆开选型逻辑、格式转换、训练参数、踩坑记录和现场部署适合刚拿到数据集、准备投入 PPE 检测项目的算法工程师照着复现。2. 为什么选 YOLOv9从 PPE 检测场景反推模型选型与标注规范2.1 从场景特点反推模型选型安全帽检测和普通目标检测任务有个很大的区别工地现场视角极不稳定。有俯拍的球机、有仰拍的地面机位、有装在塔吊上的移动相机同一个安全帽在画面里可能只有 30×30 像素也可能被脚手架挡掉三分之一。再加上正午阳光直射时反光背心的过曝模型需要同时扛住小目标召回、遮挡鲁棒性和光照变化这三件事。YOLOv9 在 2024 年开源时主打的 PGI可编程梯度信息和 GELAN通用高效层聚合网络正好击中这些痛点。PGI 解决的是深层网络在反向传播时梯度信息丢失的问题说人话就是对那些特征不明显的小目标训练时能拿到更完整的梯度信号不会练着练着就“忘了”小目标。GELAN 则是把不同层级的特征融合做得更轻量参数量没涨但特征表达力更强。这两个机制在 PPE 这种目标尺度跨度大的场景里收益比在 COCO 通用场景里更明显。2000 多张标注图这个量级也恰好卡在 YOLO 系能发挥效力的区间。比这个数再少模型容易过拟合得靠大强度的数据增强硬顶比这个数再多一个量级就可以考虑移植到检测头更复杂的模型上但训练和部署成本也会跟着翻倍。我在实际项目里的经验是2000 张图配 640 分辨率YOLOv9 把 mAP50 练到 85% 以上是正常水平前提是标注别出幺蛾子。顺带说下和近邻版本的对比。YOLOv8 在 ultralytics 生态里工具链最顺适合快速验证YOLOv11 最近讨论度不低但它的优势更多体现在分类和端侧部署检测头结构反而更接近 v8 的路线。YOLOv9 的价值在于 PGI 机制对难样本的收益更明确所以我的建议是手头没有现成框架时先用 YOLOv9 官方仓库跑通一个基准再根据需要决定要不要迁到其他版本。这个顺序能帮你把数据问题和大版本迁移问题分开排查少绕弯。2.2 类别定义和标注边界标准拿到别人的标注数据第一个动作不是开训练而是做标注审计。审计前先定类别清单这是所有工作的地基。我一般按下面这个表格定义类别名含义边界说明helmet安全帽含普通安全帽、带面罩安全帽不含安全帽反光条单独出现的场景reflective_vest反光背心/反光服含马甲式、背带式、连体反光服只露一条反光条也算person人体辅助类用于学习“背心穿在人身上”的上下文关系这个清单看起来简单真正的坑在边界标准。反光背心被工作服遮住一半时框要按整件衣服画还是按可见部分画我的约定是按可见部分画但有两个前提一是只要露出反光条就归为 reflective_vest不要因为只露出一小块就跳过二是安全帽同理远处一个 20 像素的小点只要肉眼能辨认是安全帽就得标漏掉这种小目标会让模型在远距离场景里彻底瞎掉。person 类要不要包含我的答案是强烈建议包含。老版本数据集里经常只有 helmet 和 vest 两类训练出来的模型有一个通病把远处的人形阴影误检成反光背心。加了 person 类之后模型学到了“反光背心应该是穿在人体躯干上的”误检率能降一半。如果你拿到的 2000 张图里没标 person我一般会用预训练模型先跑一遍人体检测把 person 框作为补充标签加进去。这个操作在场景固定的工地上效果非常显著值得花半天时间做。2.3 标注审计用半自动方式找出漏标和错标人工标注的数据直接进训练是翻车高发区这是我在多个项目里总结出来的血泪经验。拿到 2000 张标注图的第一天我建议按下面三步做快速审计第一步用一个小型预训练权重在整批图上做推理置信度阈值调到 0.15。这个低阈值会触发大量误检但没关系我要的是那些模型检到但标注文件里不存在的框——这些大概率是漏标。第二步做一次过曝检测统计每张图里亮度高于 220 的像素占比超过 30% 的图单独捞出来人工复核重点检查反光背心的框是否完整覆盖反光条。第三步检查标签字符串一致性这一步最蠢但最容易踩坑比如 “helmet” 和 “Helmet” 在标注文件里会被当成两个类训练时 class 数量对不上模型能训完但推理时类别错乱。审计脚本不一定要多复杂核心是把人和机器的注意力放在最可能出问题的图上。我一直认为2000 张图的数据标注里真正决定模型上限的不是总数而是那 5% 标注质量差的图。把这 100 张左右的问题图找出来重新修正比再多标 500 张普通图对模型的提升都大。3. 数据格式转换从标注 XML 到 YOLOv9 能吃的数据集目录3.1 目录结构和文件对应关系大多数标注工具导出的原始格式是 VOC XML 或 COCO JSON但 YOLOv9 官方仓库只认自己的 txt 格式而且对目录结构有强约定。标准结构长这样dataset/ ├── images/ │ ├── train/ │ │ ├── site_a_0001.jpg │ │ └── site_a_0002.jpg │ └── val/ │ ├── site_b_0001.jpg │ └── site_b_0002.jpg └── labels/ ├── train/ │ ├── site_a_0001.txt │ └── site_a_0002.txt └── val/ ├── site_b_0001.txt └── site_b_0002.txtimages 和 labels 必须是镜像关系图片叫 site_a_0001.jpg标签就必须叫 site_a_0001.txt。训练脚本按图片路径自动找同名 txt找不到会静默跳过不报错。我吃过一次亏图片是 .jpg 后缀生成标签时用了 .png 的 stem结果训练时 2400 张图实际只吃到 1500 张mAP 怎么调都上不去最后一行一行对文件名才发现。每个 txt 文件的内容是归一化坐标格式如下0 0.52 0.48 0.40 0.31 1 0.71 0.82 0.21 0.45 2 0.68 0.79 0.18 0.43第一列是类别 id第二、三列是框中心点的 x 和 y第四、五列是宽和高全部除以图片宽高归一化到 0~1 之间。所有标注工具导出时都能设置这个格式但导出前一定要确认——LabelImg 默认导 VOCLabel Studio 可以配成 YOLO 格式CVAT 则需要转换插件。格式错了后期训练出来的模型会莫名其妙地输出一个偏到画面外的框这就是格式黑匣子问题排查起来很费时间。3.2 VOC XML 转 YOLO txt 的转换脚本这是我在每个项目里都会用到的转换脚本可以直接抄作业import xml.etree.ElementTree as ET from pathlib import Path # 类别映射表务必和后续训练用的 data.yaml 保持一致id 从 0 开始 CLASS_MAP { helmet: 0, reflective_vest: 1, person: 2, } def convert_voc_xml(xml_path: Path, out_dir: Path) - None: tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.findall(object): cls_name obj.find(name).text.strip() if cls_name not in CLASS_MAP: # 未知类别直接跳过避免污染标签 continue cls_id CLASS_MAP[cls_name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 归一化到 0~1并换算成中心点加宽高的格式 x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h # 防御性检查剔除异常框防止训练出 NaN if w 0 or h 0 or w 1 or h 1: continue lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}) if lines: out_file out_dir / (xml_path.stem .txt) out_file.write_text(\n.join(lines)) def convert_all(xml_dir: Path, label_out_dir: Path) - None: label_out_dir.mkdir(parentsTrue, exist_okTrue) for xml_file in xml_dir.glob(*.xml): convert_voc_xml(xml_file, label_out_dir)这段代码里有三个参数值得细说。第一个是 CLASS_MAP它的顺序决定了标签文件里的类别 id如果和 data.yaml 里的 names 顺序不一致训练不会报错但验证时 mAP 会断崖式下跌这是最隐蔽的坑。第二个是防御性检查xmax 小于 xmin 这种脏框在人工标注里偶尔会出现不剔除的话损失函数里会出现 NaN整个训练直接白跑。第三个是浮点精度归一化坐标保留 6 位小数足够写成 2 位小数会让多个框在小目标上重叠精度丢失。3.3 数据划分、类别平衡和标签统计转换完成后下一步是划分 train/val/test。常用比例是 8:1:1但对 2000 张的规模test 取 200 张就够。我这里有一个关键原则划分必须按场景分组不能按文件名随机切。比如同一个工地机位拍的 100 张图最好全部进 train 或全部进 val否则验证集里出现过训练时见过的背景模型在验证集上会“作弊”测出来的 mAP 虚高一上现场就打回原形。类别平衡这件事必须在划分后做一次统计确认。安全帽通常比反光背心多得多——这是 PPE 数据的通病。我遇到过 1800 个 helmet 框、只有 400 个 reflective_vest 框的情况训练出来模型对不确定的目标会一律倾向判成安全帽这在工地告警场景里是不可接受的。统计可以用几行简单的 Python 代码完成from pathlib import Path label_dirs [dataset/labels/train, dataset/labels/val] counter {} for d in label_dirs: for txt in Path(d).glob(*.txt): for line in txt.read_text().splitlines(): if line.strip(): cls_id line.split()[0] counter[cls_id] counter.get(cls_id, 0) 1 print(counter) # 期望输出类似 {0: 1800, 1: 420, 2: 1500}如果发现某类占比过低常见的解法有三条路。第一给训练配置里的 loss 加上类别权重让模型重点学习低频类第二对反光背心类做离线过采样把含背心的图多复制几份放进训练集第三对背心类做更强的马赛克增强。三条路我都试过最省事的是离线过采样因为类别权重的数值本身要靠反复试马赛克增强则要手动调参与参。稳妥起见先做过采样再看训练曲线决定要不要进一步优化。4. 训练配置与参数调优跑通安全帽与反光服检测的最小参数组合4.1 环境准备与最小训练命令环境准备这一步没什么玄学PyTorch CUDA 显卡就够跑 YOLOv9 官方仓库。数据准备就绪后需要先写一个 data.yaml# data.yaml path: /data/helmet_vest # 数据及根目录建议写绝对路径 train: images/train val: images/val test: images/test names: 0: helmet 1: reflective_vest 2: person这里有几个容易错的地方。path 字段是数据集的绝对路径后续所有相对路径都基于它写错了训练脚本可能拉到另一个目录的数据而不自知。names 顺序必须和 3.2 节转换脚本里的 CLASS_MAP 完全一致这是整个训练流程里最容易出错的环节我在项目里已经习惯了每次跑新数据都先核对这一项。然后启动训练python train.py \ --data data.yaml \ --img 640 \ --batch-size 16 \ --epochs 300 \ --device 0 \ --hyp hyp.scratch.yaml \ --weights yolov9-c.pt这几个参数的选型逻辑我分别说明。--img 640是速度和精度的平衡点也是业界事实标准在这个分辨率下 30 像素的小目标依然保有足够特征又不至于让推理时间涨到不可接受。--batch-size 16直接取决于显存12GB 显存跑 yolov9-c 用 16 是比较安全的8GB 就降到 8 或 4网上那些“训练显存不足”的求助帖九成是 batch 没跟着显存走。--epochs 300看起来夸张但 YOLOv9 前 100 个 epoch 基本在震荡真正收敛出现在 200 以后提前停反而拿不到最佳权重。4.2 值得优先调整的三个超参数很多人在训练一开始就调学习率、动量、权重衰减其实还有三个参数更值得先动它们的性价比高得多。第一个是阶段学习率策略。YOLOv9 默认用的是余弦退火但如果你的数据集只有 2000 张我建议把 warmup 的 epoch 数从默认的 3 提到 10让模型在前 10 个 epoch 里用很小的学习率先把数据分布“看清”再进入主学习阶段。这能有效避免开局就震荡到不收敛。第二个是--multi-scale。默认关闭时输入图固定 640开启后训练过程中会随机在 0.5~1.5 倍区间缩放输入。这对工地场景特别有用因为现场的多机位视角天然存在尺度差异。但这个开关会显著增加显存占用和训练时间8GB 显存建议先关掉跑通一个基准再考虑开。第三个是fl_gamma也就是 focal loss 的 gamma 系数。安全帽检测里小目标占比很大把 gamma 从默认 0 调到 0.5 之后模型对难分类的小目标会投入更多学习权重。这个参数在 YOLOv9 里是通过 hyp 配置文件传入的很多教程不会提到但它对小目标 mAP 的提升往往是实打实的几个点。4.3 训练过程监控判断模型是否健康训练跑起来后终端会持续输出损失和 mAP。新手最爱盯 mAP但前 50 个 epoch 的 mAP 没有任何参考意义这时候模型还在学基础特征。我更关注 box_loss 和 cls_loss 这两条曲线box_loss 从 0.1 附近稳步下到 0.02 以内cls_loss 同步下降这是健康的状态。如果 cls_loss 震荡不止优先怀疑类别不平衡回到 3.3 节处理如果 box_loss 降得很好但 mAP 不涨大概率是标注框质量问题回 2.3 节审计不要把时间浪费在调参上。训练日志里出现nan我的处理方式是直接停掉先排查学习率是不是设高了再看数据里有没有空标签文件或全是零坐标的脏标签混进去。另外强烈建议每 10 个 epoch 手动备份一次权重。这话说出来有点丢人但我确实经历过一次训练到 270 个 epoch 时进程被系统 kill当时只留了一个 final.pt一切归零。后来我养成了习惯每轮把 best.pt 复制到另一块磁盘几十 GB 的空间换一颗后悔药值。5. 避坑指南标注、训练与部署的 5 个高频问题5.1 反光背心过曝导致标注框偏小现象反光背心在阳光直射下大面积过曝人工标注时根本看不清背心边界标出来的框要么只圈住了一条反光条要么比实际衣服小一圈。训练完成后模型对过曝样本的输出置信度普遍偏低。原因反光材料的高反射特性让物体边缘和背景融为一体标注员的肉眼都分不清边界标注框自然就不完整。解决在审计阶段用图像处理把过曝图“拉回来”再重新标注。最简单的方法是压暗亮部通道import cv2 import numpy as np # 专门处理过曝样本的离线增强 def fix_overexposure(img, threshold220): hsv cv2.cvtColor(img, cv2.COLOR_BGR2HSV) v hsv[:, :, 2] # 把亮度过高的像素压到 threshold保留色相和饱和度 v[v threshold] threshold hsv[:, :, 2] v return cv2.cvtColor(hsv, cv2.COLOR_HSV2BGR)这段代码跑一遍过曝区域里的纹理和边缘会重现标注员能看清背心的实际边界。同时建议在训练增强里加入色彩扰动让模型在过曝输入下也不会直接摆烂。5.2 远距离小目标安全帽被漏检现象距离摄像头 15 米以上的安全帽只有 30×30 像素大小训练完成后这类目标几乎检不出来验证集 mAP 看着不错但实际球机拉远视角时漏检严重。原因默认 640 分辨率下一个 30 像素的目标经过多次下采样后特征图里只剩 2×2 左右的区域模型没有足够信息去匹配正样本。解决两条路并行。第一条是把输入分辨率从 640 提到 960代价是推理时间增加 30% 左右但小目标 mAP 能提升 5 到 8 个点。第二条是对训练图做切片——把含小目标的图按 2×2 切块放大单独训练一个小目标增强模型部署时用大模型检人、用小模型检安全帽。这个方法在工地场景里效果突出代价是部署时多一路推理流水线。如果预算有限先试 960 分辨率收益和成本比最高。5.3 类别不平衡导致模型偏见现象helmet 类 mAP 达到 92%reflective_vest 类只有 76%而且验证集里反光背心的漏检明显高于安全帽。原因2000 张图里 helmet 框 1800 个reflective_vest 框只有 400 个模型根本没看够背心学不到它的判别特征。解决除了 3.3 节讲的过采样还有一种我在项目里验证过效果更好的方法——合成数据。把反光背心模板从原图里抠出来随机旋转、缩放后贴到工地背景图上生成 200 张合成图加入训练。这个做法的好处不只是补充数量还引入了更丰富的姿态和遮挡情况。实测合成 200 张图的效果比把原图复制粘贴喂 5 遍还要好因为模型看到的是不同组合的上下文。5.4 训练中途显存溢出OOM现象训练在第一个 epoch 就报CUDA out of memory进程直接中断。原因多数情况是开启 multi-scale 后输入图被放大到 960×960权重和激活值占用同时暴涨batch-size 又没有相应下调。解决按顺序排查。先降 batch-size 到 8 确认基准显存能过再关掉 multi-scale 确认是它导致的最后考虑用梯度检查点技术。YOLOv9 官方仓库没有默认开启检查点我一般会改模型定义用torch.utils.checkpoint包住中间层这个改动不大但能让显存占用降 40% 左右。如果以上都做了还是爆显存那就不是显存问题而是代码里有张量泄漏检查是不是有中间 tensor 没有释放。5.5 验证集 mAP 虚高现场表现差现象训练曲线非常漂亮验证集 mAP 90% 以上但拿到工地的实时视频流上一跑漏检率直接翻倍。原因最隐蔽的坑是数据切分泄漏。同一个工地的多段视频被派到了 train 和 val 两边模型在训练时已经“背下”了那个工地的背景验证集测试时相当于开卷考试。解决严格按场景分组划分回到 3.3 节的逻辑按机位编号、拍摄日期或工地 ID 分组保证同组数据只在 train 或者 val 单侧出现。真正压测的做法是找一段新工地的视频完全不在训练集里出现用它做最终验收。这是判断模型是否过拟合场景的唯一可靠方式没有之一。6. 模型验证与现场部署从 mAP 到真实场景的最后一公里6.1 用真实视频流做鲁棒性验证单张图片的 mAP 说明不了现场表现。我的习惯是部署前找一段真实工地监控视频逐帧推理重点统计三类问题反光背心在低照度或夜间是否大面积丢失人员密集遮挡时安全帽框是否频繁跳变机位移动时检测框是否闪烁不定。视频验证时把置信度阈值调低到 0.25先找漏检再逐步提高阈值找误检最终确定一个平衡点。实测下来白天场景阈值 0.45 合适夜间场景要降到 0.3 以下这就是光照变化带来的真实差距。6.2 用 TensorRT 评估并发路数现场部署的另一半是算力评估。常见方案是在边缘卡或服务器上用 TensorRT 做 FP16 加速。我自己在 T4 上测过yolov9-c 在 640 分辨率下单路推理约 5 到 8 毫秒1080p 25 帧的视频流单卡大约能扛 10 路左右。注意这个数字只能当量级参考因为瓶颈往往不在模型推理而在视频解码和前后处理。如果实测路数远低于预期先检查预处理是不是在 CPU 上做的——把 BGR 转 RGB、resize、归一化全部搬到 GPU吞吐量经常能提升 30%。工业检测场景用单机还是云端我的做法是单机先行检测实时性对网络抖动太敏感了纯云端方案在网络有波动时会把告警延迟拉到不可接受。6.3 一个上线前的验收标准最后给一个可以带走的经验标准是我做过多个 PPE 项目之后沉淀下来的安全帽类 mAP50 不低于 90%反光背心不低于 85%在低照度视频流上人工抽查 100 帧漏检率小于 5%达到这个线再谈上线。达不到的话优先回查标注质量和类别平衡不要在超参数上死磕——那是性价比最低的一条路。这个判断标准帮我少走了很多弯路也希望帮你在数据质检、训练节奏和部署预期上有一个可对照的准绳祝你的安全帽与反光背心检测项目少踩几个坑。本文还有配套的精品资源点击获取