简介面向智慧工地安全领域的YOLOv11目标检测开发者《智慧工地安全YOLOv11高空作业安全带佩戴检测模型调优技巧》是一份51页的PDF文档。内容覆盖YOLO系列算法原理回顾、高空作业安全带数据集的采集标注与预处理、学习率/批量大小等超参数调优、数据增强策略、训练验证流程优化、常用性能指标分析以及云端/边缘/混合部署案例可为安防监控、工业检测等场景下快速落地高精度安全带佩戴检测方案提供参考。资源包内仅包含1个PDF文件压缩包大小2.26MB文档无缺页或乱码文字、图表、目录均显示正常支持阅读器大纲与章节快速定位可按目录顺序阅读或直接跳转目标章节。目前已有142人学习下载适合希望系统掌握YOLOv11模型调优技巧的研究者、算法工程师及相关专业学生查阅使用为实际项目提供可复用的调参思路。1. 高空作业安全带检测为什么先聊 YOLOv11 调优而不是换模型在智慧工地项目里安全带佩戴检测是最容易被低估的一类视觉任务。高空场景中安全带挂点小、工人距离摄像机远正样本往往只占图像几十个像素加上逆光、遮挡和反光背心的干扰模型稍有不慎就从高召回跌成高误报。用 YOLOv11 做这个任务不是因为它在 COCO 上刷榜而是它的解耦头、训练收敛特性和端侧部署路径在工程上最省心——真正决定项目能不能验收的是后续的模型调优技巧小目标优化、数据配比、NMS 后处理和量化部署。这篇笔记按我自己在工地项目里的流程来写从网络结构怎么理解到标签怎么标、参数怎么调、坑在哪、部署怎么省内存读完你可以在自己的数据集上直接把参数抄走试一遍。2. YOLOv11 网络结构里跟安全带检测直接相关的部分先理解再动手2.1 从 C3k2 到 SPPF 变体哪些模块真正影响小目标召回YOLOv11 的 backbone 和 neck 相比 YOLOv8 最大的变化是把原来 C2f 里的一部分卷积路径换成了 C3k2 模块。C3k2 的核心是用更小的 kernel 组合替代部分大卷积理论上参数更省但实际上对安全带这类小目标的检测它并不直接决定召回率。真正决定小目标能不能被检出来的是下采样倍率和特征层融合的方式。YOLOv11 默认还是 P3/P4/P5 三尺度输出。P3 对应 8 倍下采样是安全带检测的主战场。巡逻球机画面里一根安全带的宽度通常在 8~16 像素之间只有落在 P3 层上的特征才有足够分辨力。如果按默认的 640 输入去训练P3 层感受野大概是 8×8 的原始区域对照安全带目标规模勉强够用但如果施工现场把摄像机架在塔吊臂或基坑边缘目标缩到 4 像素P3 也救不回来。C3k2 里有一个可以调的小参数是中间 bottleneck 的个数。默认配置下C3k2 在 backbone 的每个 stage 里只堆 1 个 bottleneck如果你发现 P3 层小目标漏检多可以把 backbone 前两个 stage 的 bottleneck 数加一倍代价是训练速度大约降 15%但对小目标的特征表达能力会有可感知的提升。这个改动不需要改模型结构文件直接在 YOLOv11 的 yaml 配置里改数字就行。2.2 SPPF 的 pool 尺寸选择与目标尺寸的匹配关系YOLOv11 的 SPPF 模块用三个串联的 5×5 max pool 来扩大感受野。对于安全带这类小目标SPPF 的 pool 尺寸影响很小但有一个容易翻车的点如果你为了适配工地场景把输入分辨率从 640 提到 1280但 SPPF 的 pool 尺寸没动neck 层输出特征图变大之后信息聚合范围相对变小对极小目标不一定有帮助。我的做法是当输入分辨率提升到 1280 时把 SPPF 的三个 pool 从 5 改成 3。理由是高空图像里目标虽然小但背景也相对干净不需要过大的感受野去关联上下文——安全带就是一条带子挂在人身上上下文范围比车辆检测小得多。改 pool 尺寸在 yaml 里同样是一行事。# yolov11-safety.yaml 片段基于 yolov11s 调整 backbone: - [-1, 1, Conv, [64, 3, 2]] - [-1, 1, Conv, [128, 3, 2]] - [-1, 2, C3k2, [256, False]] - [-1, 1, Conv, [256, 3, 2]] - [-1, 2, C3k2, [512, False]] - [-1, 1, Conv, [512, 3, 2]] - [-1, 2, C3k2, [1024, False]] - [-1, 1, SPPF, [1024, 3]] # 原为 51280 输入时改成 3上面这段 yaml 里SPPF, [1024, 3]最后的数字 3 就是 pool kernel size。如果你输入分辨率保持 640不建议动它。这里需要注意改了 SPPF 的 pool 尺寸之后neck 层的通道数不会变所以预训练权重依然可以加载不会出现 shape mismatch 的问题。如果你想在 neck 里再接一个注意力模块HCANet 那种思路可以参考——在 P3 层输出前加一个通道注意力强制模型关注安全带这种细长结构。不过常见做法是在训练稳定之后再加一开始就加会让收敛变慢损失曲线会长时间下不去。2.3 解耦头与 loss 分配为什么安全带检测容易「检得出、框不准」YOLOv11 的 head 是解耦的分类分支和回归分支各走各的卷积。安全带的分类很简单就一个类别难的是回归——安全带的框是极端的长条形宽高比常常超过 1:5而默认 anchor-free 的回归头对极端长宽比目标天生不敏感。训练时如果发现 mAP50 还可以、mAP50-95 一直低大概率是回归分支对长条形目标的定位精度不足。常见解决路径有两个一是把回归 loss 从默认的 CIoU 换成 SIoUSIoU 对角度和长宽比更敏感对细长目标有明显改善二是在数据增强里对长条形目标做专门的随机旋转增强让模型见过更多角度的安全带避免它把竖直佩戴的安全带学了、斜挎的就漏掉。# 在 YOLOv11 的 loss 配置里切换回归 loss 的写法 # ultralytics/cfg/default.yaml 中修改 loss 相关参数 loss: box: 7.5 # 默认 7.5长条形目标可提到 9.0 cls: 0.5 # 单类别任务可以再降 dfl: 1.5 # 分布式 focal loss建议保持默认参数说明box权重提高之后模型会更卖力地把框回归准但如果你的工地画面里遮挡严重框的标注本身就带噪声box 权重太高反而会把标注噪声学进去。cls在单类别任务里不是瓶颈降一点可以防止分类分支和回归分支在解耦头里互相抢梯度。最后说环境配置。YOLOv11 的训练环境其实没有想象中苛刻CUDA 11.8 以上配 PyTorch 2.xultralytics 包直接 pip 装就行。真正要注意的是 batch size 和显存的匹配后面第 4 章会细说。3. 数据与标签策略安全带检测的成败在标注阶段就定了3.1 安全带目标尺寸分布统计小目标优化的前提很多工地项目的标注数据是直接找外包标了事。做 YOLOv11 小目标优化前第一步先统计目标尺寸分布连目标多小都不知道谈优化就是玄学。用下面的脚本把标注框的尺寸分布拉出来看 P3 层理论上能不能覆盖。import json from collections import Counter # 假设标注是 labelme 格式这里换成你自己的解析逻辑 with open(annotations.json, r) as f: data json.load(f) size_bins Counter() for img in data[images]: for ann in img[annotations]: w ann[bbox][2] # 标注框宽 h ann[bbox][3] # 标注框高 max_side max(w, h) if max_side 8: size_bins[8px] 1 elif max_side 16: size_bins[8-16px] 1 elif max_side 32: size_bins[16-32px] 1 else: size_bins[32px] 1 print(size_bins)这段代码的逻辑很简单把每个标注框的长边分桶长边小于 8 像素的在 P3 层上都不一定有一个完整的 anchor 特征覆盖。统计完之后如果8px的比例超过 20%你的调优重心就必须放在输入分辨率和复制粘贴增强上而不是去调 NMS 阈值。参数上需要关注的是 bbox 坐标系的归一化方式——如果标注文件里是像素坐标而训练时用的是归一化坐标尺寸分布会被算错先把单位统一了再统计。3.2 标注规范反光背心、安全绳和安全带的区分安全带检测最常见的标注错误是把反光背心当成安全带。工地工人普遍穿反光背心背心上的荧光横条和反光带在视觉上跟安全带高度相似尤其当工人背对镜头时反光背心的肩带和腰带看起来就像没系安全带。标注规范里必须明确只标注跨过肩部和腰部的独立织带不标反光背心自带的装饰条。标注框的贴合度也要定标准。安全带的几何形态是一条窄带但很多外包标注员习惯性把框拉成正方形导致长宽比信息丢失。对回归分支来说框的长宽比本身就是特征正方形框会让模型学到错误的目标形状。我一般要求标注框紧贴安全带的可见部分不延伸到人体轮廓之外宁可框小一点不可框大。如果同一人同时系了安全绳和安全带两个目标重叠度高标注时按遮挡关系只标可见的那个。否则训练时同一个位置出现两个框模型会被 YOLOv11 的匹配策略搞糊涂——它会把两个框分配给同一个 anchor 区域导致 loss 震荡。3.3 数据增强组合小目标复制粘贴比 Mosaic 更稳YOLOv11 默认开启 Mosaic、MixUp 和 HSV 扰动。但高空安全带场景有个特殊问题Mosaic 把四张图拼在一起后目标整体缩小到原来的 1/2 甚至 1/4本来就 8 像素的安全带会变成 2 像素完全超出可学习范围。我在工地项目里直接关掉了 Mosaic 在最后 50 个 epoch 的作用ultralytics 里可以将mosaic设为 0 或按 epoch 衰减改用小目标复制粘贴增强。复制粘贴增强的思路是把标注好的安全带目标从原图抠出来缩放旋转后贴到另一张图的空旷区域比如天空、地面、未施工区域。这个操作能有效增加小目标样本数因为安全带的背景变化不大贴图造成的域偏移很小。# ultralytics/cfg/default.yaml 关键增强参数基于 YOLOv11 默认改 mosaic: 0.5 # 训练前 60% 的 epoch 保留后半程建议降到 0.1 或关闭 mixup: 0.1 # 单类别任务 mixup 收益小降下来防震荡 hsv_h: 0.015 # 色调扰动保持默认 hsv_s: 0.7 # 饱和度扰动保持默认 hsv_v: 0.4 # 明度扰动可以开到 0.5工地逆光多 degrees: 45.0 # 关键参数安全带佩戴角度变化大旋转增强必须开 translate: 0.1 scale: 0.3参数说明degrees: 45.0是安全带检测最能出效果的一项增强因为工人弯腰、转身、攀爬时安全带的视觉角度变化远大于普通目标。mosaic后半程降下来是为了避免小目标被过度缩小。mixup对单类别检测基本没有正向收益保留一个很小的值防过拟合就够了。3.4 验证集构建按视频抽帧而不是按图像随机划分工地数据集通常是从监控视频里抽帧得到的。如果直接把所有帧打乱后随机划分训练集和验证集同一个人的同一段动作会同时出现在两边验证集 mAP 会虚高 5~10 个点部署到现场就现原形。正确做法是按视频片段划分把每路摄像头的连续时间段作为一个整体一部分时间段进训练集另一部分时间段进验证集。验证集要特别覆盖三类场景工人背对镜头、逆光、夜间补光。这三类是最容易在测试阶段翻车的如果验证集里没有调优就失去了参照。我自己会在训练集之外单独留一个「hard set」专门放这些恶劣样本每个 epoch 结束用 hard set 算一次 mAP这个值比官方验证集的 mAP 更能反映现场真实水平。4. 训练调优核心参数与超参数组合从 loss 曲线到 mAP 的完整链路4.1 输入分辨率与 batch size 的匹配先算显存账YOLOv11 小目标优化的第一个杠杆是输入分辨率。默认 640 输入下8 像素的安全带在 P3 层上只剩 1×1 个特征点几乎没有形状信息。我把输入分辨率提到 960 或 1280P3 层上 8 像素目标能占 2×2 到 3×3 个特征点召回率会有肉眼可见的提升特别是从球机远距离画面里检出安全带。但分辨率不是白提的。960 输入比 640 输入的计算量大 2.25 倍显存占用同步上涨。用 4090 24G 训练时batch size 从默认 16 要降到 8不然直接 OOM。1280 输入下我通常会配合梯度累积来模拟更大的 batch。# 960 输入 梯度累积的启动命令 yolo train \ datasafety.yaml \ modelyolov11s.pt \ imgsz960 \ batch8 \ epochs150 \ optimizerSGD \ lr00.01 \ lrf0.01 \ warmup_epochs3.0 \ cos_lrTrue \ accumulate4参数说明accumulate4表示每 4 个 batch 做一次梯度更新等效 batch size 是 32比直接开 batch32 省显存但训练时间会略长。optimizerSGD是我在小目标检测任务上的习惯——AdamW 收敛快但后期容易在小目标回归上震荡SGD 配合 cosine 学习率衰减更稳。warmup_epochs3.0不能省YOLOv11 前几个 epoch 的 anchor 分配还很不稳定跳过了容易在第一个 epoch 就损失爆炸。4.2 anchor 分配策略与 loss 权重三条经验参数YOLOv11 是 anchor-free 的但它在训练时仍然有正样本匹配的过程。默认的匹配策略会根据目标的宽高比选择特征层对细长目标不会特别照顾。这里有三条调参经验第一把boxloss 权重从默认 7.5 提到 9.0 到 10.0。安全带的分类很简单模型不会认错难的是框的边界特别是肩带和腰带交叉的位置。第二把cls权重从默认 0.5 降到 0.3。单类别任务里分类分支的梯度会主导早期训练压一压能让回归分支拿到更多梯度。第三dfl保持默认 1.5 不要动。DFL 对边界框的离散分布建模很敏感乱调会让框收敛到错误的位置。# 推荐的安全带检测 loss 权重配置 loss: box: 9.5 # 原 7.5长条形目标回归压力大 cls: 0.3 # 原 0.5单类别任务分类压力小 dfl: 1.5 # 保持默认这三种设置的效果反映在验证集上通常是 mAP50 变化不大但 mAP50-95 会从 35 左右升到 42 左右。如果你的项目验收只看 mAP50这一个改动不够明显但在实际抓拍里框会从「大概框住人」变成「框住安全带本体」下游的违规判定逻辑才写得下去。4.3 训练轮数与学习率策略从 loss 曲线判断何时停安全带检测数据集一般就几千张训练 150 epoch 足够。关键是学会看 loss 曲线而不是盲目加轮数。YOLOv11 训练时主要看两条曲线训练 loss 和验证 mAP。如果训练 loss 还在稳定下降、验证 mAP 也还在涨说明欠拟合继续训如果训练 loss 还在降但验证 mAP 不动了开始过拟合就该回调增强或提前停止。硬要给出一个可抄的参数我会建议warmup 3 个 epoch、cosine 学习率、初始 lr0 在 SGD 下用 0.01、在 AdamW 下用 0.001。训练到 30 epoch 时如果 mAP50 还没过 50先别急着调参回看数据质量和标注规范——大多数时候是标注问题而不是模型问题。4.4 模型结构选择yolov11s 是工地场景的性价比底线YOLOv11n 在 Jetson 上跑得最快但从小目标检测的效果看n 模型在 P3 层上的特征通道太少8 像素的安全带基本学不出形状。工地项目我至少用yolov11s如果对精度要求高且部署端是 PC 或云端yolov11m更稳。模型越大P3 层能表达的特征越丰富对极小目标的提升是结构性的比调任何 loss 权重都直接。模型imgszmAP50自测Jetson 推理耗时显存占用bs8yolov11n64082.49ms6.2Gyolov11s96089.116ms9.8Gyolov11m128092.331ms15.4G表格里的数字是项目里接近的量级不同工地场景会差不少但比值有参考性。yolov11s在 960 输入下mAP50 和推理耗时最平衡是我的默认选择。想上yolov11m先确认部署端的算力预算否则训练出来了也落不了地。4.5 训练产物管理每次实验保留完整配置与权重调优过程中最大的坑不是参数不对而是改乱了不知道哪版参数跑出哪个结果。我每个实验都固定用 ultralytics 的自动日志跑完直接看runs/detect/train/里的args.yaml和weights/best.pt。args.yaml记录了这次实验的全部参数best.pt是按验证集 mAP 保存的最优权重。如果要管理多个实验版本给每次训练命名加后缀yolo train modelyolov11s.pt datasafety.yaml imgsz960 batch8 epochs150 nameexp_s_960_v2nameexp_s_960_v2会让训练输出到runs/detect/exp_s_960_v2/目录不会覆盖之前的实验。到了调优后期你会发现最值钱的就是这份实验记录——回滚的时候它就是后悔药。5. 模型调优避坑指南5 个反复出现的现场问题5.1 远距离小目标漏检P3 层单独加权现象验证集上一切正常一到现场球机画面距离超过 15 米的工人就检不出来。原因现场距离导致目标实际像素比训练集里的分布更小。训练集的标注框长边中位数是 14 像素现场远距离目标只有 5~7 像素超出了训练分布的下界。解决不用换网络先做两件事。第一把训练集里小于 8 像素的目标做 2~3 倍复制粘贴增强强制把训练分布往下扩第二推理时把输入分辨率从 960 提到 1120。ultralytics 支持在 predict 时设置imgsz跟训练时不一致也没关系。经过这两个改动后现场远距离召回能从 50 提到 70 左右。5.2 逆光场景误检严重不做额外处理先看训练增强现象下午低角度阳光时把安全绳的阴影误检成安全带或者把塔吊钢丝绳误检成目标误报率飙升。原因安全带的 HSV 特征在逆光下发生偏移模型学到的颜色分布和形状特征在强阴影下失效。解决把hsv_v从默认 0.4 开到 0.6hsv_s从 0.7 开到 0.9在训练阶段就见过更宽的亮度变化。另外不要在输入图像上额外加自适应直方图均衡工地画面的亮度分布很复杂全局均衡反而会把阴影加重。5.3 NMS 把密集人群中的多个目标压成一个框现象脚手架上有两三个人同时作业距离很近模型检出了多个安全带但 NMS 之后只保留了一个框或直接框住两个人。原因YOLOv11 默认 NMS 阈值是 0.5对密集重叠目标来说太激进重叠度高的小目标会被吞掉。解决把 NMS 的 IoU 阈值从 0.5 降到 0.3 到 0.35。在 ultralytics 里推理时可以设置iou0.35。代价是密集场景下的重复框会多一些需要在后处理里按置信度排序去重。# 推理时降低 NMS IoU 阈值保留密集小目标 from ultralytics import YOLO model YOLO(runs/detect/exp_s_960_v2/weights/best.pt) results model.predict( sourcecamera_008.mp4, imgsz1120, conf0.35, # 置信度阈值按需调整 iou0.35, # NMS IoU 阈值密集场景调低 saveTrue, )参数说明conf0.35和iou0.35是两个不同维度——conf控制哪些框被保留iou控制重叠框怎么合并。如果你降低iou之后重复框变多说明conf可以适当提高一点。yolov11 保存推理结果时saveTrue会自动把标注框画在帧上并保存为视频或图片这个参数在排查阶段很好用——直接看可视化结果就能判断是 NMS 的问题还是检测器的问题。5.4 验证集 mAP 高、现场表现差数据泄漏与场景偏差现象训练时验证集 mAP50 到了 92一到现场只有 70 不到差距大到无法解释。原因两类问题叠加。第一验证集按帧随机划分同一段视频的相似帧同时进了训练集和验证集mAP 虚高。第二现场摄像机安装角度和训练数据差异大球机的俯视视角在训练集里占比太少。解决验证集按视频片段而不是按帧划分施工前先建一个 hard set。安装新的摄像机后先用它录 30 分钟素材人工标注后做一次增量微调。这类问题没有一劳永逸的解法只能在数据闭环上做文章。5.5 Jetson Nano 上训练好的模型推理时内存溢出现象PC 上跑得好好的 best.pt转到 Jetson Nano 上推理前几帧正常几分钟后进程被杀报 out of memory。原因PyTorch 模型在 Jetson 上直接跑推理时会有大量显存碎片视频流读写没释放句柄每帧都做图像缩放对象内存只增不减。解决先转 TensorRT 再部署这会同时解决速度和内存问题。Jetson Nano 的详细部署步骤见第 6 章这里只说关键点视频帧要复用同一个 cv2.VideoWriter 对象不要每帧新建帧处理完马上释放推理统一走 TensorRT engine不再加载 PyTorch 模型。6. 从 PyTorch 到 JetsonYOLOv11 安全带的端侧部署调优实战端侧部署是智慧工地项目里避不开的环节。边缘盒子和 Jetson 设备是主流方案这里给一套我常用的 YOLOv11 部署流程从导出到推理都覆盖重点说yolov11 预测后保存和 int8 量化的坑。第一步把训练好的 best.pt 导出为 ONNX再转 TensorRT。这里注意导出时务必指定opset12否则 Jetson 上的 TensorRT 版本可能不认。第二步用trtexec生成 engine 文件。Jetson Nano 的算力有限建议 FP16 精度int8 需要校准集且 mAP 下降明显安全带这种小目标对量化误差很敏感我不推荐。# 在 Jetson Nano 上导出 ONNX如果直接导出 TensorRT 则跳过这步 yolo export modelbest.pt formatonnx opset12 dynamicFalse imgsz960 # 用 trtexec 生成 FP16 engine trtexec \ --onnxbest.onnx \ --saveEnginebest_fp16.engine \ --fp16 \ --workspace1024参数说明imgsz960要与训练时的输入一致或按现场需求重新定——这个参数决定了推理网络输入张量的尺寸改大之后推理变慢改小之后小目标失效。dynamicFalse固定输入尺寸Jetson 上省显存也省推理时间。workspace1024是 TensorRT 构建时的最大显存预算单位是 MB不算太大避免在构建阶段就爆显存。构建好的 engine 文件可以直接在 Python 里用 TensorRT 加载推理。正规工程做法是把 engine 的输入输出绑定好图像预处理用 CUDA 完成帧循环里只做推理和画框。import cv2 import numpy as np import tensorrt as trt import pycuda.autoinit # 依赖 pycuda # 加载 engine with open(best_fp16.engine, rb) as f: engine_data f.read() runtime trt.Runtime(trt.Logger(trt.Logger.WARNING)) engine runtime.deserialize_cuda_engine(engine_data) # 推理时输入图像尺寸按 engine 定义 input_shape (960, 960) cap cv2.VideoCapture(rtsp://192.168.1.64/live) writer cv2.VideoWriter( output_result.avi, cv2.VideoWriter_fourcc(*XVID), 25, (1920, 1080), ) while True: ret, frame cap.read() if not ret: break # 预处理resize 到 960归一化 img cv2.resize(frame, input_shape) img img.astype(np.float32) / 255.0 img img.transpose(2, 0, 1)[None] # 推理 后处理省略 TensorRT 绑定细节 # boxes, scores infer(engine, img) # 画框并保存 writer.write(frame) cap.release() writer.release()逻辑说明这个帧循环是最小可用的骨架。yolov11 推理结果保存的正确做法是复用同一个 VideoWriter而不是每帧调用 imwrite——工地视频一跑就是几十分钟频繁磁盘 IO 会掉帧甚至卡死。writer的编码用 XVID兼容性比 MJPG 稳文件大小也控制得住。如果你的工地摄像头是枪机固定机位还有一个内存优化技巧画面里的施工区域只占一部分可以先把检测区域裁剪出来再做 resize。这样输入尺寸可以从 960 降到 640Jetson 上的推理延迟能从 40ms 降到 18ms 左右漏检率也不会明显变差——因为被裁掉的区域本来就没有作业面。最后说一个我长期以来的操作习惯任何部署项目第一次跑通都先保存一份带检测框的输出视频而不是只看终端日志里的检测数量。检测数量可以骗人但框在画面上画没画正、有没有飘一眼就能看出来。这个习惯帮我避过无数次「模型指标正常但现场不可用」的翻车。希望这些调优技巧能帮你在工地上少踩几个坑。本文还有配套的精品资源点击获取 YOLOv11安全带检测调优实战：小目标优化与端侧部署策略
简介面向智慧工地安全领域的YOLOv11目标检测开发者《智慧工地安全YOLOv11高空作业安全带佩戴检测模型调优技巧》是一份51页的PDF文档。内容覆盖YOLO系列算法原理回顾、高空作业安全带数据集的采集标注与预处理、学习率/批量大小等超参数调优、数据增强策略、训练验证流程优化、常用性能指标分析以及云端/边缘/混合部署案例可为安防监控、工业检测等场景下快速落地高精度安全带佩戴检测方案提供参考。资源包内仅包含1个PDF文件压缩包大小2.26MB文档无缺页或乱码文字、图表、目录均显示正常支持阅读器大纲与章节快速定位可按目录顺序阅读或直接跳转目标章节。目前已有142人学习下载适合希望系统掌握YOLOv11模型调优技巧的研究者、算法工程师及相关专业学生查阅使用为实际项目提供可复用的调参思路。1. 高空作业安全带检测为什么先聊 YOLOv11 调优而不是换模型在智慧工地项目里安全带佩戴检测是最容易被低估的一类视觉任务。高空场景中安全带挂点小、工人距离摄像机远正样本往往只占图像几十个像素加上逆光、遮挡和反光背心的干扰模型稍有不慎就从高召回跌成高误报。用 YOLOv11 做这个任务不是因为它在 COCO 上刷榜而是它的解耦头、训练收敛特性和端侧部署路径在工程上最省心——真正决定项目能不能验收的是后续的模型调优技巧小目标优化、数据配比、NMS 后处理和量化部署。这篇笔记按我自己在工地项目里的流程来写从网络结构怎么理解到标签怎么标、参数怎么调、坑在哪、部署怎么省内存读完你可以在自己的数据集上直接把参数抄走试一遍。2. YOLOv11 网络结构里跟安全带检测直接相关的部分先理解再动手2.1 从 C3k2 到 SPPF 变体哪些模块真正影响小目标召回YOLOv11 的 backbone 和 neck 相比 YOLOv8 最大的变化是把原来 C2f 里的一部分卷积路径换成了 C3k2 模块。C3k2 的核心是用更小的 kernel 组合替代部分大卷积理论上参数更省但实际上对安全带这类小目标的检测它并不直接决定召回率。真正决定小目标能不能被检出来的是下采样倍率和特征层融合的方式。YOLOv11 默认还是 P3/P4/P5 三尺度输出。P3 对应 8 倍下采样是安全带检测的主战场。巡逻球机画面里一根安全带的宽度通常在 8~16 像素之间只有落在 P3 层上的特征才有足够分辨力。如果按默认的 640 输入去训练P3 层感受野大概是 8×8 的原始区域对照安全带目标规模勉强够用但如果施工现场把摄像机架在塔吊臂或基坑边缘目标缩到 4 像素P3 也救不回来。C3k2 里有一个可以调的小参数是中间 bottleneck 的个数。默认配置下C3k2 在 backbone 的每个 stage 里只堆 1 个 bottleneck如果你发现 P3 层小目标漏检多可以把 backbone 前两个 stage 的 bottleneck 数加一倍代价是训练速度大约降 15%但对小目标的特征表达能力会有可感知的提升。这个改动不需要改模型结构文件直接在 YOLOv11 的 yaml 配置里改数字就行。2.2 SPPF 的 pool 尺寸选择与目标尺寸的匹配关系YOLOv11 的 SPPF 模块用三个串联的 5×5 max pool 来扩大感受野。对于安全带这类小目标SPPF 的 pool 尺寸影响很小但有一个容易翻车的点如果你为了适配工地场景把输入分辨率从 640 提到 1280但 SPPF 的 pool 尺寸没动neck 层输出特征图变大之后信息聚合范围相对变小对极小目标不一定有帮助。我的做法是当输入分辨率提升到 1280 时把 SPPF 的三个 pool 从 5 改成 3。理由是高空图像里目标虽然小但背景也相对干净不需要过大的感受野去关联上下文——安全带就是一条带子挂在人身上上下文范围比车辆检测小得多。改 pool 尺寸在 yaml 里同样是一行事。# yolov11-safety.yaml 片段基于 yolov11s 调整 backbone: - [-1, 1, Conv, [64, 3, 2]] - [-1, 1, Conv, [128, 3, 2]] - [-1, 2, C3k2, [256, False]] - [-1, 1, Conv, [256, 3, 2]] - [-1, 2, C3k2, [512, False]] - [-1, 1, Conv, [512, 3, 2]] - [-1, 2, C3k2, [1024, False]] - [-1, 1, SPPF, [1024, 3]] # 原为 51280 输入时改成 3上面这段 yaml 里SPPF, [1024, 3]最后的数字 3 就是 pool kernel size。如果你输入分辨率保持 640不建议动它。这里需要注意改了 SPPF 的 pool 尺寸之后neck 层的通道数不会变所以预训练权重依然可以加载不会出现 shape mismatch 的问题。如果你想在 neck 里再接一个注意力模块HCANet 那种思路可以参考——在 P3 层输出前加一个通道注意力强制模型关注安全带这种细长结构。不过常见做法是在训练稳定之后再加一开始就加会让收敛变慢损失曲线会长时间下不去。2.3 解耦头与 loss 分配为什么安全带检测容易「检得出、框不准」YOLOv11 的 head 是解耦的分类分支和回归分支各走各的卷积。安全带的分类很简单就一个类别难的是回归——安全带的框是极端的长条形宽高比常常超过 1:5而默认 anchor-free 的回归头对极端长宽比目标天生不敏感。训练时如果发现 mAP50 还可以、mAP50-95 一直低大概率是回归分支对长条形目标的定位精度不足。常见解决路径有两个一是把回归 loss 从默认的 CIoU 换成 SIoUSIoU 对角度和长宽比更敏感对细长目标有明显改善二是在数据增强里对长条形目标做专门的随机旋转增强让模型见过更多角度的安全带避免它把竖直佩戴的安全带学了、斜挎的就漏掉。# 在 YOLOv11 的 loss 配置里切换回归 loss 的写法 # ultralytics/cfg/default.yaml 中修改 loss 相关参数 loss: box: 7.5 # 默认 7.5长条形目标可提到 9.0 cls: 0.5 # 单类别任务可以再降 dfl: 1.5 # 分布式 focal loss建议保持默认参数说明box权重提高之后模型会更卖力地把框回归准但如果你的工地画面里遮挡严重框的标注本身就带噪声box 权重太高反而会把标注噪声学进去。cls在单类别任务里不是瓶颈降一点可以防止分类分支和回归分支在解耦头里互相抢梯度。最后说环境配置。YOLOv11 的训练环境其实没有想象中苛刻CUDA 11.8 以上配 PyTorch 2.xultralytics 包直接 pip 装就行。真正要注意的是 batch size 和显存的匹配后面第 4 章会细说。3. 数据与标签策略安全带检测的成败在标注阶段就定了3.1 安全带目标尺寸分布统计小目标优化的前提很多工地项目的标注数据是直接找外包标了事。做 YOLOv11 小目标优化前第一步先统计目标尺寸分布连目标多小都不知道谈优化就是玄学。用下面的脚本把标注框的尺寸分布拉出来看 P3 层理论上能不能覆盖。import json from collections import Counter # 假设标注是 labelme 格式这里换成你自己的解析逻辑 with open(annotations.json, r) as f: data json.load(f) size_bins Counter() for img in data[images]: for ann in img[annotations]: w ann[bbox][2] # 标注框宽 h ann[bbox][3] # 标注框高 max_side max(w, h) if max_side 8: size_bins[8px] 1 elif max_side 16: size_bins[8-16px] 1 elif max_side 32: size_bins[16-32px] 1 else: size_bins[32px] 1 print(size_bins)这段代码的逻辑很简单把每个标注框的长边分桶长边小于 8 像素的在 P3 层上都不一定有一个完整的 anchor 特征覆盖。统计完之后如果8px的比例超过 20%你的调优重心就必须放在输入分辨率和复制粘贴增强上而不是去调 NMS 阈值。参数上需要关注的是 bbox 坐标系的归一化方式——如果标注文件里是像素坐标而训练时用的是归一化坐标尺寸分布会被算错先把单位统一了再统计。3.2 标注规范反光背心、安全绳和安全带的区分安全带检测最常见的标注错误是把反光背心当成安全带。工地工人普遍穿反光背心背心上的荧光横条和反光带在视觉上跟安全带高度相似尤其当工人背对镜头时反光背心的肩带和腰带看起来就像没系安全带。标注规范里必须明确只标注跨过肩部和腰部的独立织带不标反光背心自带的装饰条。标注框的贴合度也要定标准。安全带的几何形态是一条窄带但很多外包标注员习惯性把框拉成正方形导致长宽比信息丢失。对回归分支来说框的长宽比本身就是特征正方形框会让模型学到错误的目标形状。我一般要求标注框紧贴安全带的可见部分不延伸到人体轮廓之外宁可框小一点不可框大。如果同一人同时系了安全绳和安全带两个目标重叠度高标注时按遮挡关系只标可见的那个。否则训练时同一个位置出现两个框模型会被 YOLOv11 的匹配策略搞糊涂——它会把两个框分配给同一个 anchor 区域导致 loss 震荡。3.3 数据增强组合小目标复制粘贴比 Mosaic 更稳YOLOv11 默认开启 Mosaic、MixUp 和 HSV 扰动。但高空安全带场景有个特殊问题Mosaic 把四张图拼在一起后目标整体缩小到原来的 1/2 甚至 1/4本来就 8 像素的安全带会变成 2 像素完全超出可学习范围。我在工地项目里直接关掉了 Mosaic 在最后 50 个 epoch 的作用ultralytics 里可以将mosaic设为 0 或按 epoch 衰减改用小目标复制粘贴增强。复制粘贴增强的思路是把标注好的安全带目标从原图抠出来缩放旋转后贴到另一张图的空旷区域比如天空、地面、未施工区域。这个操作能有效增加小目标样本数因为安全带的背景变化不大贴图造成的域偏移很小。# ultralytics/cfg/default.yaml 关键增强参数基于 YOLOv11 默认改 mosaic: 0.5 # 训练前 60% 的 epoch 保留后半程建议降到 0.1 或关闭 mixup: 0.1 # 单类别任务 mixup 收益小降下来防震荡 hsv_h: 0.015 # 色调扰动保持默认 hsv_s: 0.7 # 饱和度扰动保持默认 hsv_v: 0.4 # 明度扰动可以开到 0.5工地逆光多 degrees: 45.0 # 关键参数安全带佩戴角度变化大旋转增强必须开 translate: 0.1 scale: 0.3参数说明degrees: 45.0是安全带检测最能出效果的一项增强因为工人弯腰、转身、攀爬时安全带的视觉角度变化远大于普通目标。mosaic后半程降下来是为了避免小目标被过度缩小。mixup对单类别检测基本没有正向收益保留一个很小的值防过拟合就够了。3.4 验证集构建按视频抽帧而不是按图像随机划分工地数据集通常是从监控视频里抽帧得到的。如果直接把所有帧打乱后随机划分训练集和验证集同一个人的同一段动作会同时出现在两边验证集 mAP 会虚高 5~10 个点部署到现场就现原形。正确做法是按视频片段划分把每路摄像头的连续时间段作为一个整体一部分时间段进训练集另一部分时间段进验证集。验证集要特别覆盖三类场景工人背对镜头、逆光、夜间补光。这三类是最容易在测试阶段翻车的如果验证集里没有调优就失去了参照。我自己会在训练集之外单独留一个「hard set」专门放这些恶劣样本每个 epoch 结束用 hard set 算一次 mAP这个值比官方验证集的 mAP 更能反映现场真实水平。4. 训练调优核心参数与超参数组合从 loss 曲线到 mAP 的完整链路4.1 输入分辨率与 batch size 的匹配先算显存账YOLOv11 小目标优化的第一个杠杆是输入分辨率。默认 640 输入下8 像素的安全带在 P3 层上只剩 1×1 个特征点几乎没有形状信息。我把输入分辨率提到 960 或 1280P3 层上 8 像素目标能占 2×2 到 3×3 个特征点召回率会有肉眼可见的提升特别是从球机远距离画面里检出安全带。但分辨率不是白提的。960 输入比 640 输入的计算量大 2.25 倍显存占用同步上涨。用 4090 24G 训练时batch size 从默认 16 要降到 8不然直接 OOM。1280 输入下我通常会配合梯度累积来模拟更大的 batch。# 960 输入 梯度累积的启动命令 yolo train \ datasafety.yaml \ modelyolov11s.pt \ imgsz960 \ batch8 \ epochs150 \ optimizerSGD \ lr00.01 \ lrf0.01 \ warmup_epochs3.0 \ cos_lrTrue \ accumulate4参数说明accumulate4表示每 4 个 batch 做一次梯度更新等效 batch size 是 32比直接开 batch32 省显存但训练时间会略长。optimizerSGD是我在小目标检测任务上的习惯——AdamW 收敛快但后期容易在小目标回归上震荡SGD 配合 cosine 学习率衰减更稳。warmup_epochs3.0不能省YOLOv11 前几个 epoch 的 anchor 分配还很不稳定跳过了容易在第一个 epoch 就损失爆炸。4.2 anchor 分配策略与 loss 权重三条经验参数YOLOv11 是 anchor-free 的但它在训练时仍然有正样本匹配的过程。默认的匹配策略会根据目标的宽高比选择特征层对细长目标不会特别照顾。这里有三条调参经验第一把boxloss 权重从默认 7.5 提到 9.0 到 10.0。安全带的分类很简单模型不会认错难的是框的边界特别是肩带和腰带交叉的位置。第二把cls权重从默认 0.5 降到 0.3。单类别任务里分类分支的梯度会主导早期训练压一压能让回归分支拿到更多梯度。第三dfl保持默认 1.5 不要动。DFL 对边界框的离散分布建模很敏感乱调会让框收敛到错误的位置。# 推荐的安全带检测 loss 权重配置 loss: box: 9.5 # 原 7.5长条形目标回归压力大 cls: 0.3 # 原 0.5单类别任务分类压力小 dfl: 1.5 # 保持默认这三种设置的效果反映在验证集上通常是 mAP50 变化不大但 mAP50-95 会从 35 左右升到 42 左右。如果你的项目验收只看 mAP50这一个改动不够明显但在实际抓拍里框会从「大概框住人」变成「框住安全带本体」下游的违规判定逻辑才写得下去。4.3 训练轮数与学习率策略从 loss 曲线判断何时停安全带检测数据集一般就几千张训练 150 epoch 足够。关键是学会看 loss 曲线而不是盲目加轮数。YOLOv11 训练时主要看两条曲线训练 loss 和验证 mAP。如果训练 loss 还在稳定下降、验证 mAP 也还在涨说明欠拟合继续训如果训练 loss 还在降但验证 mAP 不动了开始过拟合就该回调增强或提前停止。硬要给出一个可抄的参数我会建议warmup 3 个 epoch、cosine 学习率、初始 lr0 在 SGD 下用 0.01、在 AdamW 下用 0.001。训练到 30 epoch 时如果 mAP50 还没过 50先别急着调参回看数据质量和标注规范——大多数时候是标注问题而不是模型问题。4.4 模型结构选择yolov11s 是工地场景的性价比底线YOLOv11n 在 Jetson 上跑得最快但从小目标检测的效果看n 模型在 P3 层上的特征通道太少8 像素的安全带基本学不出形状。工地项目我至少用yolov11s如果对精度要求高且部署端是 PC 或云端yolov11m更稳。模型越大P3 层能表达的特征越丰富对极小目标的提升是结构性的比调任何 loss 权重都直接。模型imgszmAP50自测Jetson 推理耗时显存占用bs8yolov11n64082.49ms6.2Gyolov11s96089.116ms9.8Gyolov11m128092.331ms15.4G表格里的数字是项目里接近的量级不同工地场景会差不少但比值有参考性。yolov11s在 960 输入下mAP50 和推理耗时最平衡是我的默认选择。想上yolov11m先确认部署端的算力预算否则训练出来了也落不了地。4.5 训练产物管理每次实验保留完整配置与权重调优过程中最大的坑不是参数不对而是改乱了不知道哪版参数跑出哪个结果。我每个实验都固定用 ultralytics 的自动日志跑完直接看runs/detect/train/里的args.yaml和weights/best.pt。args.yaml记录了这次实验的全部参数best.pt是按验证集 mAP 保存的最优权重。如果要管理多个实验版本给每次训练命名加后缀yolo train modelyolov11s.pt datasafety.yaml imgsz960 batch8 epochs150 nameexp_s_960_v2nameexp_s_960_v2会让训练输出到runs/detect/exp_s_960_v2/目录不会覆盖之前的实验。到了调优后期你会发现最值钱的就是这份实验记录——回滚的时候它就是后悔药。5. 模型调优避坑指南5 个反复出现的现场问题5.1 远距离小目标漏检P3 层单独加权现象验证集上一切正常一到现场球机画面距离超过 15 米的工人就检不出来。原因现场距离导致目标实际像素比训练集里的分布更小。训练集的标注框长边中位数是 14 像素现场远距离目标只有 5~7 像素超出了训练分布的下界。解决不用换网络先做两件事。第一把训练集里小于 8 像素的目标做 2~3 倍复制粘贴增强强制把训练分布往下扩第二推理时把输入分辨率从 960 提到 1120。ultralytics 支持在 predict 时设置imgsz跟训练时不一致也没关系。经过这两个改动后现场远距离召回能从 50 提到 70 左右。5.2 逆光场景误检严重不做额外处理先看训练增强现象下午低角度阳光时把安全绳的阴影误检成安全带或者把塔吊钢丝绳误检成目标误报率飙升。原因安全带的 HSV 特征在逆光下发生偏移模型学到的颜色分布和形状特征在强阴影下失效。解决把hsv_v从默认 0.4 开到 0.6hsv_s从 0.7 开到 0.9在训练阶段就见过更宽的亮度变化。另外不要在输入图像上额外加自适应直方图均衡工地画面的亮度分布很复杂全局均衡反而会把阴影加重。5.3 NMS 把密集人群中的多个目标压成一个框现象脚手架上有两三个人同时作业距离很近模型检出了多个安全带但 NMS 之后只保留了一个框或直接框住两个人。原因YOLOv11 默认 NMS 阈值是 0.5对密集重叠目标来说太激进重叠度高的小目标会被吞掉。解决把 NMS 的 IoU 阈值从 0.5 降到 0.3 到 0.35。在 ultralytics 里推理时可以设置iou0.35。代价是密集场景下的重复框会多一些需要在后处理里按置信度排序去重。# 推理时降低 NMS IoU 阈值保留密集小目标 from ultralytics import YOLO model YOLO(runs/detect/exp_s_960_v2/weights/best.pt) results model.predict( sourcecamera_008.mp4, imgsz1120, conf0.35, # 置信度阈值按需调整 iou0.35, # NMS IoU 阈值密集场景调低 saveTrue, )参数说明conf0.35和iou0.35是两个不同维度——conf控制哪些框被保留iou控制重叠框怎么合并。如果你降低iou之后重复框变多说明conf可以适当提高一点。yolov11 保存推理结果时saveTrue会自动把标注框画在帧上并保存为视频或图片这个参数在排查阶段很好用——直接看可视化结果就能判断是 NMS 的问题还是检测器的问题。5.4 验证集 mAP 高、现场表现差数据泄漏与场景偏差现象训练时验证集 mAP50 到了 92一到现场只有 70 不到差距大到无法解释。原因两类问题叠加。第一验证集按帧随机划分同一段视频的相似帧同时进了训练集和验证集mAP 虚高。第二现场摄像机安装角度和训练数据差异大球机的俯视视角在训练集里占比太少。解决验证集按视频片段而不是按帧划分施工前先建一个 hard set。安装新的摄像机后先用它录 30 分钟素材人工标注后做一次增量微调。这类问题没有一劳永逸的解法只能在数据闭环上做文章。5.5 Jetson Nano 上训练好的模型推理时内存溢出现象PC 上跑得好好的 best.pt转到 Jetson Nano 上推理前几帧正常几分钟后进程被杀报 out of memory。原因PyTorch 模型在 Jetson 上直接跑推理时会有大量显存碎片视频流读写没释放句柄每帧都做图像缩放对象内存只增不减。解决先转 TensorRT 再部署这会同时解决速度和内存问题。Jetson Nano 的详细部署步骤见第 6 章这里只说关键点视频帧要复用同一个 cv2.VideoWriter 对象不要每帧新建帧处理完马上释放推理统一走 TensorRT engine不再加载 PyTorch 模型。6. 从 PyTorch 到 JetsonYOLOv11 安全带的端侧部署调优实战端侧部署是智慧工地项目里避不开的环节。边缘盒子和 Jetson 设备是主流方案这里给一套我常用的 YOLOv11 部署流程从导出到推理都覆盖重点说yolov11 预测后保存和 int8 量化的坑。第一步把训练好的 best.pt 导出为 ONNX再转 TensorRT。这里注意导出时务必指定opset12否则 Jetson 上的 TensorRT 版本可能不认。第二步用trtexec生成 engine 文件。Jetson Nano 的算力有限建议 FP16 精度int8 需要校准集且 mAP 下降明显安全带这种小目标对量化误差很敏感我不推荐。# 在 Jetson Nano 上导出 ONNX如果直接导出 TensorRT 则跳过这步 yolo export modelbest.pt formatonnx opset12 dynamicFalse imgsz960 # 用 trtexec 生成 FP16 engine trtexec \ --onnxbest.onnx \ --saveEnginebest_fp16.engine \ --fp16 \ --workspace1024参数说明imgsz960要与训练时的输入一致或按现场需求重新定——这个参数决定了推理网络输入张量的尺寸改大之后推理变慢改小之后小目标失效。dynamicFalse固定输入尺寸Jetson 上省显存也省推理时间。workspace1024是 TensorRT 构建时的最大显存预算单位是 MB不算太大避免在构建阶段就爆显存。构建好的 engine 文件可以直接在 Python 里用 TensorRT 加载推理。正规工程做法是把 engine 的输入输出绑定好图像预处理用 CUDA 完成帧循环里只做推理和画框。import cv2 import numpy as np import tensorrt as trt import pycuda.autoinit # 依赖 pycuda # 加载 engine with open(best_fp16.engine, rb) as f: engine_data f.read() runtime trt.Runtime(trt.Logger(trt.Logger.WARNING)) engine runtime.deserialize_cuda_engine(engine_data) # 推理时输入图像尺寸按 engine 定义 input_shape (960, 960) cap cv2.VideoCapture(rtsp://192.168.1.64/live) writer cv2.VideoWriter( output_result.avi, cv2.VideoWriter_fourcc(*XVID), 25, (1920, 1080), ) while True: ret, frame cap.read() if not ret: break # 预处理resize 到 960归一化 img cv2.resize(frame, input_shape) img img.astype(np.float32) / 255.0 img img.transpose(2, 0, 1)[None] # 推理 后处理省略 TensorRT 绑定细节 # boxes, scores infer(engine, img) # 画框并保存 writer.write(frame) cap.release() writer.release()逻辑说明这个帧循环是最小可用的骨架。yolov11 推理结果保存的正确做法是复用同一个 VideoWriter而不是每帧调用 imwrite——工地视频一跑就是几十分钟频繁磁盘 IO 会掉帧甚至卡死。writer的编码用 XVID兼容性比 MJPG 稳文件大小也控制得住。如果你的工地摄像头是枪机固定机位还有一个内存优化技巧画面里的施工区域只占一部分可以先把检测区域裁剪出来再做 resize。这样输入尺寸可以从 960 降到 640Jetson 上的推理延迟能从 40ms 降到 18ms 左右漏检率也不会明显变差——因为被裁掉的区域本来就没有作业面。最后说一个我长期以来的操作习惯任何部署项目第一次跑通都先保存一份带检测框的输出视频而不是只看终端日志里的检测数量。检测数量可以骗人但框在画面上画没画正、有没有飘一眼就能看出来。这个习惯帮我避过无数次「模型指标正常但现场不可用」的翻车。希望这些调优技巧能帮你在工地上少踩几个坑。本文还有配套的精品资源点击获取