YOLO算法实战：623张仓库工人数据集训练与部署全流程

简介本资源为面向YOLO系列目标检测算法的仓库工人数据集适用于智慧仓储、掌舵安全等场景下的工人检测与安全监控任务可支撑从模型训练到验证测试的完整流程。数据集共623张图像均已标注并划分完毕兼容yolov5、yolov7、yolov8、yolov9、yolov10及yolo11等主流版本适合算法入门者与工程实践者直接上手。压缩包内共1870个文件包含623个jpg图像、623个txt标签、623个xml标签以及1个yaml配置文件整体约30.25MB其中txt为YOLO格式标注xml为VOC格式标注yaml用于定义数据集路径与类别信息两种标签格式分别存放便于按需选用。目前已有43人学习下载。读者可直接获得一份开箱即用的检测数据集省去采集与标注成本快速开展模型训练、对比实验与效果验证为仓储安全类目标检测项目提供可靠的数据基础。1. 仓库工人检测为什么值得用 YOLO 从头训一遍623 张图像、带标签、仓库工人场景——这个体量放在今天动辄几十万张的公开数据集面前看起来像是玩具级。但我实际做过好几个仓储、工地、厂区的人体检测项目后反而越来越偏爱这种小体量、单场景、标签干净的数据集。原因很直接仓库环境里工人检测的难点从来不是人长什么样而是遮挡、堆叠、光照突变、货架背景干扰这四件事通用 COCO 预训练模型在这些场景下的漏检率高得让人怀疑人生。这个标题里的关键词是yolo算法 仓库工人数据集 623张图像带标签。它对应的真实需求是你手上有一个垂直场景的小数据集想用 YOLO 系列训一个能落地的工人检测模型用于安全帽识别、危险区域闯入告警、人货混行监控这类仓储安全应用。623 张不算多但也绝不是不能训——关键在于你怎么划分、怎么增强、怎么选预训练权重、怎么判断它到底能不能上生产。适合读这篇的人有三类刚接触 YOLO 想找一个完整小数据集练手的新手手里有类似仓储数据、想知道 600 张量级到底能训出什么效果的工程师以及正在评估要不要自己标数据训模型还是直接调 API的技术负责人。我会把从数据检查到训练到验证的完整路径讲清楚包括我踩过的坑和那些参数到底为什么要那么设。2. 623 张仓库工人数据集先搞清楚你手里到底是什么2.1 数据集结构自检别急着训练先跑一遍统计脚本拿到一个带标签的图像数据集第一件事永远不是打开 YOLO 配置文件而是先搞清楚它的目录结构、标签格式、类别分布。仓库工人数据集常见的标签格式有两种YOLO txt 格式每行class x_center y_center width height归一化到 0-1和 VOC XML 格式。623 张这个量级如果标签格式不统一或者有大量空标签文件后面训练会直接翻车。我一般会先写一个统计脚本把图像尺寸、标签数量、类别分布、宽高比全部过一遍import os import glob from collections import Counter from PIL import Image img_dir images lbl_dir labels class_counter Counter() size_list [] empty_labels 0 no_label_imgs [] for img_path in glob.glob(os.path.join(img_dir, *.jpg)): base os.path.splitext(os.path.basename(img_path))[0] lbl_path os.path.join(lbl_dir, base .txt) # 图像尺寸统计 with Image.open(img_path) as im: size_list.append(im.size) if not os.path.exists(lbl_path): no_label_imgs.append(base) continue with open(lbl_path, r) as f: lines [l.strip() for l in f if l.strip()] if len(lines) 0: empty_labels 1 continue for line in lines: cls int(line.split()[0]) class_counter[cls] 1 print(图像总数:, len(size_list)) print(尺寸分布:, Counter(size_list).most_common(5)) print(类别分布:, class_counter) print(空标签文件数:, empty_labels) print(无标签图像数:, len(no_label_imgs))这段脚本输出四个关键信息图像尺寸是否统一不统一的话训练时的 letterbox 处理要留意、类别是否只有一类仓库工人检测通常就是 person 一类或者 person helmet 两类、空标签数量空标签是合法的负样本但太多说明标注质量有问题、有没有图像缺标签文件。参数说明class_counter统计的是每个类别 ID 出现的次数如果只有 0 这一类说明是纯人体检测如果有 0 和 1大概率是 person 和 helmet。size_list用 Counter 统计是为了快速看出分辨率是否一致仓库监控截图常见 1920x1080 和 1280x720 混用。2.2 623 张怎么划分才不浪费训练/验证/测试的比例与分层策略623 张图像如果按 8:1:1 划分训练集约 498 张验证集 62 张测试集 63 张。这个量级下验证集只有 60 多张mAP 的波动会非常大——同一批权重跑两次验证mAP 可能差 3 到 5 个点。我的做法是训练/验证按 9:1 划分测试集单独从原始数据里留出或者干脆用交叉验证的思路多看几轮。更重要的是分层如果数据集里既有白天仓库、又有夜间仓库既有近距离工人、又有远距离小目标随机划分很可能导致验证集里全是白天场景模型在夜间的表现就完全没法评估。我一般会按场景标签手动分层确保验证集覆盖所有子场景。import random import os import shutil random.seed(42) # 固定种子保证可复现 all_imgs sorted(glob.glob(images/*.jpg)) random.shuffle(all_imgs) val_ratio 0.1 val_count int(len(all_imgs) * val_ratio) val_imgs all_imgs[:val_count] train_imgs all_imgs[val_count:] for phase, files in [(train, train_imgs), (val, val_imgs)]: os.makedirs(fdataset/{phase}/images, exist_okTrue) os.makedirs(fdataset/{phase}/labels, exist_okTrue) for p in files: base os.path.splitext(os.path.basename(p))[0] shutil.copy(p, fdataset/{phase}/images/{base}.jpg) lbl flabels/{base}.txt if os.path.exists(lbl): shutil.copy(lbl, fdataset/{phase}/labels/{base}.txt)这里random.seed(42)是我强烈建议保留的习惯——小数据集上划分方式对结果影响很大固定种子意味着别人能复现你的实验。val_ratio0.1在 623 张上给出约 62 张验证图是我认为能接受的下限。如果你有测试集建议从原始数据里单独留 50 到 80 张不要从训练集里再切。提示如果数据集里存在同一段视频抽帧得到的连续图像随机划分会导致训练集和验证集高度相似验证 mAP 虚高。这种情况要按视频片段划分而不是按帧随机划分。3. 用 YOLOv8 在仓库工人数据集上跑通第一轮训练3.1 环境配置与预训练权重选择为什么我不用 from scratchYOLOv8 的环境配置现在已经被 ultralytics 包简化到几乎一行命令但仓库工人这种小数据集预训练权重的选择直接决定你能不能训出可用的模型。623 张图从零训练模型根本学不会人的通用特征mAP 大概率停在 0.1 以下。用 COCO 预训练的yolov8n.pt或yolov8s.pt做迁移学习才是正确路径。# 创建环境 conda create -n warehouse_yolo python3.10 -y conda activate warehouse_yolo # 安装 ultralytics会自动装 torch 等依赖 pip install ultralytics # 验证安装 yolo checksyolo checks会输出你的 CUDA 是否可用、torch 版本、GPU 型号。仓库工人检测如果只是推理CPU 也能跑但训练阶段哪怕是一张 3060 12G也比 CPU 快十几倍。如果显存只有 6G 或 8Gyolov8n是稳妥选择12G 以上可以上yolov8s甚至yolov8m。预训练权重下载后放在项目根目录YOLOv8 会自动识别。我一般会同时准备yolov8n.pt和yolov8s.pt先跑 nano 验证流程通不通再换 small 看精度能提升多少。3.2 data.yaml 的五个必填字段与常见写错的地方YOLOv8 训练依赖一个data.yaml描述数据集路径和类别。这个文件看起来简单但写错一个字段就是几小时的无效训练。path: /home/user/warehouse_dataset train: dataset/train/images val: dataset/val/images nc: 1 names: 0: person五个关键点path是数据集根目录的绝对路径train和val是相对于path的路径nc是类别数仓库工人检测如果只检人就是 1names是类别名映射顺序必须和标签文件里的 class id 一致。我见过最常见的错误是names写成列表[person]而不是字典或者nc写成了 2 但标签里只有 0 这一类训练时直接报 index out of range。注意如果你的标签里 person 的 class id 是 0但 names 里写的是0: helmet模型学到的就是人头盔推理时框出来的全是错的。训练前一定用 2.1 的脚本确认 class id 和 names 的对应关系。3.3 第一轮训练命令与关键参数epochs、imgsz、batch 怎么定yolo detect train \ datadata.yaml \ modelyolov8n.pt \ epochs150 \ imgsz640 \ batch16 \ lr00.01 \ lrf0.01 \ patience30 \ projectwarehouse_runs \ nameexp1 \ seed42逐参数说明epochs150对小数据集来说不算多623 张图一个 epoch 只有几十个 iteration150 轮大概几分钟到十几分钟就能跑完imgsz640是 YOLOv8 的默认输入尺寸仓库监控截图如果分辨率很高工人目标相对较小可以尝试imgsz960或1280但显存占用会成倍增加batch16在 8G 显存上跑 640 尺寸基本安全如果 OOM 就降到 8lr00.01是初始学习率迁移学习场景下这个值比较稳lrf0.01是最终学习率因子配合余弦退火策略patience30表示 30 轮验证 mAP 不提升就早停避免过拟合。seed42同样是为了可复现。训练完成后warehouse_runs/exp1/weights/下会有best.pt和last.ptbest.pt是验证集上表现最好的权重部署时用这个。3.4 训练过程看什么loss 曲线、mAP 和混淆矩阵的读法训练启动后终端会实时打印每个 epoch 的 box_loss、cls_loss、dfl_loss 和 mAP50、mAP50-95。我一般关注三件事第一box_loss 是否稳定下降。如果 box_loss 在前 20 轮几乎不降说明学习率太低或者数据标签有问题。第二mAP50 在第几轮开始 plateau。623 张图通常 50 到 80 轮左右 mAP50 就会接近峰值后面提升很慢。第三验证 loss 是否开始上升。如果 train loss 还在降但 val loss 上升就是过拟合信号早停会帮你截住。训练结束后warehouse_runs/exp1/下会生成confusion_matrix.png、results.png、val_batch0_pred.jpg等文件。混淆矩阵在单类别检测里主要看背景被误检为 person 的比例假阳性和person 被漏检的比例假阴性。仓库场景里货架上的衣服、堆叠的纸箱经常被误检成人这个指标能直接反映出来。4. 小数据集训练仓库工人检测的避坑清单4.1 坑一mAP 很高但实际推理全是误检现象验证集 mAP50 跑到 0.9 以上但拿真实仓库监控视频一跑货架、纸箱、反光地面全被框成人。原因623 张图的验证集只有 60 多张如果这 60 多张里负样本没有人的图极少模型根本没学会什么不是人。验证集的分布和真实场景分布不一致mAP 就是虚高的。解决在训练集和验证集里都加入一定比例的负样本图——仓库空场景、只有货架的图、只有叉车的图。负样本不需要标签文件或者用空 txt 文件。我一般会让负样本占训练集的 5% 到 10%。另外推理时把conf阈值从默认 0.25 提高到 0.4 到 0.5能过滤掉大量低置信度误检。4.2 坑二小目标工人漏检严重现象近距离工人检测没问题但画面远处、货架高处的工人全部漏检。原因仓库监控摄像头通常架得高远处工人可能只有 20 到 30 像素高。YOLOv8 默认 640 输入下P3 特征图 stride 是 830 像素的目标在特征图上只有不到 4 个像素特征几乎消失。解决三个方向。一是提高输入尺寸到imgsz960或1280让远处工人在输入图里占更多像素二是用yolov8s或更大的模型小目标的特征提取能力更强三是在数据增强里开启mosaic1.0和scale0.5让模型在训练时见到更多小尺度目标。如果还是不够可以考虑切图推理把 1920x1080 切成四块 960x540 分别检测再合并这是工业界常用的手段。4.3 坑三标签格式不统一导致训练中途报错现象训练跑了几个 epoch 后突然报IndexError: list index out of range或AssertionError: label out of range。原因623 张图里混入了 VOC XML 格式的标签或者某些 txt 文件里的坐标没有归一化写成了像素值而不是 0-1或者 class id 超出了nc的范围。解决训练前跑一遍全量校验脚本检查每个标签文件的每一行是否满足5 个字段、class id 在[0, nc-1]范围内、坐标在[0, 1]范围内、宽高大于 0。发现异常的直接打印文件名手动修或者剔除。这个检查花 5 分钟能省几小时的排查。4.4 坑四验证集 mAP 波动大不知道选哪个权重现象best.pt和last.pt的 mAP 差很多或者同一批权重在不同时间验证结果不一致。原因验证集太小60 多张统计噪声大。另外 YOLOv8 验证时的数据增强和预处理也可能引入随机性。解决不要只看best.pt的 mAP把best.pt和last.pt都拿去做一次完整的测试集评估用留出的测试集不是验证集。如果两者差距在 2 个点以内选best.pt如果差距很大说明训练不稳定考虑降低学习率或增加 epoch。另外验证时加上augmentFalse关闭测试时增强结果更稳定。4.5 坑五显存不够导致 batch 只能设很小训练极慢现象8G 显存跑imgsz640, batch16直接 OOM降到batch4后训练速度慢到无法接受。原因YOLOv8 训练时的显存占用不仅和 batch 有关还和 imgsz、模型大小、是否开启 AMP 有关。解决开启混合精度训练ampTrueYOLOv8 默认开启能省 30% 到 40% 显存。如果还不够用yolov8n代替yolov8s或者把imgsz降到 512。另一个技巧是用batch-1让 ultralytics 自动选择最大可用 batch它会自动探测显存上限。如果实在不行用梯度累积模拟大 batchYOLOv8 没有直接的梯度累积参数但可以通过nbs64名义 batch size配合小 batch 来近似。5. 从 623 张到可部署模型验证、导出与持续迭代5.1 用测试集做一次诚实的评估训练完拿到best.pt后别急着部署。先留出的测试集如果之前没留从原始数据里再切 50 张确保和训练集无重叠跑一次独立评估yolo detect val \ modelwarehouse_runs/exp1/weights/best.pt \ datadata.yaml \ splittest \ imgsz640 \ conf0.001 \ iou0.6conf0.001是为了计算完整的 PR 曲线iou0.6是 NMS 的 IoU 阈值。输出里重点看mAP50和mAP50-95以及每个类别的 precision 和 recall。仓库工人检测如果用于安全告警recall 比 precision 更重要——漏检一个闯入危险区域的工人比多框几个纸箱严重得多。这种情况下可以适当降低conf阈值来换 recall。5.2 导出 ONNX 与推理速度测试部署到边缘设备或服务端时通常会把 PyTorch 权重导出成 ONNXyolo export \ modelwarehouse_runs/exp1/weights/best.pt \ formatonnx \ imgsz640 \ halfTrue \ simplifyTruehalfTrue导出 FP16 模型体积减半GPU 推理速度提升明显simplifyTrue会做图优化去掉冗余算子。导出后用 onnxruntime 跑一次速度测试确认在你的目标硬件上能达到实时仓库监控一般要求 15 到 30 FPS。5.3 623 张不够怎么办主动学习与数据回流的实操思路623 张训出来的模型在真实仓库里一定会有漏检和误检。这时候不要急着重标几千张图而是用主动学习的思路把模型部署到实际场景跑推理收集那些置信度在 0.3 到 0.6 之间的模糊样本和漏检的帧人工确认后加入训练集。每一轮回流 50 到 100 张迭代两三轮模型在特定仓库场景下的表现会有质的提升。我自己的习惯是第一版模型不求完美先上线跑一周把误检和漏检的截图全部存下来按场景分类然后有针对性地补标。623 张是起点不是终点。真正让模型可用的是后面那几轮数据回流。希望帮到你。本文还有配套的精品资源点击获取