简介智能零售柜商品检测数据集面向新零售场景目标检测项目开发者与算法学习者。内容基于真实智能零售柜监控场景采集的5000张高质量商品图片覆盖罐装饮料、袋装零食等常见品类共标注113个商品类别适合用于零售柜商品检测模型训练及通用新零售场景数据补充。标注采用labelimg完成提供VOC(xml)、COCO(json)、YOLO(txt)三种标准格式可直接接入YOLO等主流算法训练流程。另附YOLO11一键训练脚本支持GPU(GPUs)、CPU、Mac(M芯片)多平台运行并给出博主训练结果日志供参考。资源包为单个PDF文件大小5.77MB内附数据集详细介绍及百度网盘获取方式由于原数据较大故以PDF形式托管。目前已有413人学习下载适合需要真实场景数据集进行算法验证与落地的开发者。1. 目标检测项目落地第一步5000张零售柜商品图值不值得下干过智能零售柜项目的人都懂柜子硬件装好只算一半真正卡上线的是识别。顾客拿起一罐可乐再放回去摄像头要在几百毫秒内完成目标检测、商品定位和数量变化错一个框就是一笔资损。这时候最缺的不是模型结构而是带真实柜内场景、带规范标注的数据。这份资源是智能零售柜商品检测数据集共5000张图来自真实柜内监控场景包含113个商品类别以罐装饮料、袋装零食为主。数据已经用labelimg标注好同时给出VOC(xml)、COCO(json)、YOLO(txt)三种格式标签可以直接喂给YOLO系列训练。随包还带了一份YOLO11一键训练脚本覆盖GPU(GPUs)、CPU、Mac(M芯片)三平台另附博主训练结果日志供参考。我的判断是如果你正在做零售柜商品识别、新零售场景目标检测或者只是想把YOLO训练全流程跑通这份数据值得下。原因是真实柜内监控数据自己采集标注的成本很高而模型泛化恰恰依赖这种带遮挡、反光、人手干扰的真实样本。数据能不能直接用下文从格式、脚本、日志三条线拆给你看。2. 三种标注格式与113类商品VOC/COCO/YOLO的目录结构、转换逻辑与选型拿到任何目标检测数据集我第一件事不是开训而是先把标注格式摸清楚。格式决定你能用哪套训练框架、要不要写转换脚本、出问题后能不能快速定位。这份数据最省事的地方是三种主流格式全部给齐下面拆开讲。2.1 数据构成真实柜内监控113类商品不是网图拼盘数据来源直接决定模型上线后的表现。很多公开数据集用平铺拍摄的生活照杯子、瓶子拍得干干净净一到柜内就翻车。智能零售柜的真实画面是俯拍视角层板会切掉商品底部瓶身反光顾客的手和衣袖会挡住一半包装这些在网图里几乎见不到。这份数据集来自真实柜内监控场景等于把这些脏乱差异提前暴露在训练阶段比后期再去补数据高效得多。113个商品类别对目标检测来说属于中等偏上的量级。做YOLO训练时类别数影响的不只是最后一层分类头大小还直接影响正负样本采样难度。113类意味着某些外观接近的商品会被模型反复纠结比如不同口味的罐装饮料、不同品牌的袋装零食。数据本身有113类但如果训练日志里某几类AP明显偏低优先查这几类的样本数量和遮挡比例而不是急着改loss。标注工具是labelimg这点对排查问题很重要。labelimg导出的VOC xml结构是标准的object节点里有name、bndbox、difficult等字段后续转YOLO时逻辑很直观。5000张图、113类、每张图平均多个框这个标注工作量不是小数目也是这份资源的主要价值所在。2.2 三种格式的目录约定与内容差异三种格式各有各的读取逻辑拿到手先对照下表确认你手里的文件长什么样。格式标注文件关键字段适合做的事VOCxmlfilename、size、object/name、object/bndbox人工复查标注、用labelimg二次修正COCOjsonimages、annotations、categoriesbbox为[x,y,w,h]绝对像素统一评测、跨框架对比、实例分割任务YOLOtxtclass_id、x_center、y_center、w、h全部归一化YOLO系列直接训练、快速迭代VOC格式最利于人工检查因为xml里能看到图片名、图片尺寸、每个目标的类别名和四个角点坐标排查哪张图标错了直接打开看。COCO格式更适合做模型横向对比mmdetection、detectron2这些框架默认读COCO。YOLO格式则是训练效率最高的ultralytics读txt是一行一个目标不需要解析jsonIO开销小。有一个容易忽略的点YOLO格式的txt文件里不保存图片路径它靠文件名和图片目录自动对应。所以图片是images/train/001.jpg标签必须是labels/train/001.txt文件名不一致就直接丢样本。这份数据既然给了三种格式建议训练时只用YOLO格式VOC和COCO留作备份和校验不要混着用。2.3 转换逻辑不依赖工具用脚本自己过一遍哪怕数据已经给了三种格式我仍然建议你写一次转换脚本。原因很简单转换逻辑能帮你验证标注是否干净也能在以后换数据集时直接复用。VOC转YOLO是最常遇到的需求核心就两件事类别名转ID、像素坐标转归一化中心点坐标。import xml.etree.ElementTree as ET from pathlib import Path def voc2yolo(xml_path, class_names, out_dir): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) out_lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_names: continue cls_id class_names.index(name) box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) xc (x1 x2) / 2 / img_w yc (y1 y2) / 2 / img_h w (x2 - x1) / img_w h (y2 - y1) / img_h out_lines.append(f{cls_id} {xc:.6f} {yc:.6f} {w:.6f} {h:.6f}) out_path Path(out_dir) / (Path(xml_path).stem .txt) out_path.write_text(\n.join(out_lines))逻辑说明class_names列表的顺序必须和后续data.yaml里的names完全一致否则会出现类别错位。坐标转换先取xmin、xmax计算中心点再统一除以图片宽高得到0到1之间的归一化值YOLO训练时要求就是这种格式。如果xml里的宽高和实际图片尺寸不一致转换出来的框会整体偏移这是labelimg标注时最容易埋的雷。这段脚本只做转换不做校验。我一般会紧接着写一个画框脚本拿转换后的txt在图上把矩形画出来随机抽20张人工扫一遍。框偏了、类别错了、宽高为0在这一步就能全揪出来而不是等训练完看mAP再回头猜。2.4 选型建议默认YOLOCOCO用于对比实验实际项目里训练阶段我默认只碰YOLO格式。原因有三一是ultralytics生态成熟YOLO11、参数调优、预训练权重下载都围绕这个格式展开二是训练脚本读txt比解析json快迭代实验时省时间三是YOLO格式的归一化坐标和网络输入尺寸解耦换imgsz不用重新标注。COCO格式的价值不在训练在评测。如果你想把这份数据和其它公开数据集做对比或者跑mmdetection里的Faster R-CNN、DETR这类模型COCO是通用语言。VOC格式则留给人工复查。一个常见误操作是把xml也拷贝到labels目录下YOLO训练时检测到非txt文件会报No labels found或直接忽略反而干扰排查。保持目录干净每个格式单独放训练目录里只有图片和txt标签。3. 避坑数据到手直接开训前先检查这五个地方这份数据标注质量宣称是高的但第三方数据集换到自己机器上路径、ID、划分这些问题几乎必现。以下五条不是针对这份数据的问题而是任何目标检测数据落到YOLO训练前我都会先跑一遍的检查项每一条都踩出过实际代价。3.1 类别ID从1开始第一类直接消失现象训练日志里class 0的AP一直是0precision和recall曲线没有点其它类别正常。检查class_names后发现第一个类别完全没参与训练。原因labelimg标注时class_names是按自然顺序排的有些转换脚本直接拿index(name)1当类别ID导致所有ID整体从1开始。YOLO要求类别ID从0计数一旦ID整体偏移第一个类别等于被空出来了。解决训练前用一个命令扫描所有标签txt里出现过的ID看是否从0开始且连续。我通常这样做cat labels/train/*.txt | awk {print $1} | sort -n -u如果输出从0开始、没有跳号基本安全。如果从1开始或中间缺了某个ID就把转换脚本里的编号逻辑改成从0计数重新生成全部txt不要手工改113类手工改必出错。3.2 把COCO的bbox当成YOLO读框全部错位现象训练能正常跑完loss也在降但预测框全部落在目标左上角宽高明显不对。用小图可视化时框和商品错开半个身位。原因COCO的bbox是[x, y, w, h]x和y是左上角坐标单位是像素YOLO是[class_id, x_center, y_center, w, h]中心点坐标且归一化。直接套用意味着YOLO把左上角当成了中心点又少做了除以宽高的归一化框自然全偏。解决转换时严格按两步走先算中心点再除以图片宽高。很多现成转换工具会帮忙做但你得确认它读的是annotations里的bbox字段而不是segmentation。转换完拿一张图用OpenCV画框验证不要信肉眼扫坐标画出来最直接。3.3 Windows路径、中文路径导致Linux训练直接报错现象在Windows上下载解压的数据集拿到Linux服务器上训练启动时报找不到图片或者opencv读取图片返回空训练出来的模型AP是0。日志里经常出现No such file or directory、Unable to read image。原因Windows路径分隔符是\Linux是/txt里如果存了路径字符串反斜杠会被当成转义字符。中文路径在Linux下如果locale没配好imread同样读不出来。解决把数据集目录统一改成英文路径里不要有空格。如果标注文件里有路径字段用脚本把所有\替换成/。更干净的做法是训练时不在标注里读路径让ultralytics按images和labels目录名自动对应。出现读取错误时先手动ls一下报错路径别急着调参数多半是路径问题。3.4 没有划分train/val验证指标虚高或震荡现象训练日志里val_loss低得离谱mAP0.5到了0.95以上但拿到真实柜内视频一测漏检严重。另一种情况是val_loss上下剧烈震荡每个epoch的mAP相差10个点以上。原因训练集和验证集没有按类别分布分开导致部分类别只在训练集出现验证时模型“作弊”看到了训练图。验证集太小也是一个原因几百张图的val集一个batch的误差就会让指标剧烈抖动。解决按类别分层划分常见做法是8:2或7:3。先确认val集合里每个类别都至少有5到10个实例否则该类的mAP参考价值极低。划分完检查val目录中的类别ID分布和train基本一致。这一点对113类的数据集格外重要类别多某个类只有几十张图是常事。3.5 difficult/occluded样本没处理mAP虚高现象模型在遮挡严重的商品上基本检测不到但整体mAP仍然很高上线后才发现问题集中在固定几种场景。原因VOC标注里带difficult或occluded标记的样本本意是“太难不参与评估”。转换到YOLO格式时如果没有跳过这些目标它们会被当成普通正样本模型学不到有效特征评估时又把它们算进去两头都虚。解决转换时显式判断difficult字段为1的object直接跳过不生成对应的YOLO行。如果数据集没有这个字段但存在大量遮挡样本建议单独把这类样本归入hard_set训练完用它做针对性测试。零售柜场景里手部遮挡、瓶身反光都是高频难例这部分不单独评估上线就会翻车。4. YOLO11一键训练脚本GPU多卡、CPU、Mac M芯片的启动与参数调法这份资源附赠的YOLO11一键训练脚本价值不在代码量而在把三平台启动方式封装好了。YOLO11本身是ultralytics体系核心训练命令不复杂但GPU、CPU、Mac M芯片三种环境差异很大脚本把这些差异收敛到几个可改参数上。4.1 为什么零售柜场景直接选YOLO11YOLO11是目前YOLO系列里工程落地最顺手的一代检测头、CSP模块、训练策略都是现成的预训练权重直接下载不需要从头训。对113类商品检测来说模型容量不是瓶颈数据质量和部署环境才是。零售柜大多用边缘设备算力有限YOLO11的n和s版本完全够用。选型边界要清楚YOLO11擅长速度和精度的平衡但不等于万能。如果柜内商品极小、摄像头分辨率不够再好的模型也救不回来。另一个常见误区是一上来就换大模型YOLO11x参数量翻几倍训练和推理都变慢但113类场景精度的提升可能只有零点几个点。我一般先用yolo11n跑通全流程再对比s版本决定是否升级。4.2 数据目录与data.yaml先让脚本找到图YOLO训练脚本对数据目录有固定约定不是随便指定一个图片文件夹就行。拿到这份资源后先把数据整理成下面的结构retail_dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamlimages/train放训练图images/val放验证图labels目录结构和它一一对应。data.yaml的内容类似这样path: ./retail_dataset train: images/train val: images/val names: 0: cola_can 1: juice_bottle # ... 一直列到第112个类别names的顺序必须和labels txt里的class_id一致。常见错误是path写成了绝对路径换一台机器直接失效。我一般用相对路径 scripts在数据集同级目录执行时不会出错。另外注意train:和val:要写成相对于path的路径而不是./images/train这样带前缀的写法ultralytics会自动拼接。4.3 GPU(GPUs)多卡device与batch的配套关系有N卡就优先用GPU这是YOLO11训练脚本的主场。单卡和多卡的主要区别在batch和device两个参数。脚本里的命令大致是这样# 单卡batch根据显存调整16G显存起步建议648G显存用32或16 python train.py --data data.yaml --weights yolo11n.pt --device 0 --batch 64 --epochs 100 --imgsz 640 # 多卡device写卡号batch是总batch程序按卡数切分 python train.py --data data.yaml --weights yolo11n.pt --device 0,1,2,3 --batch 128 --epochs 100 --imgsz 640参数说明device 0,1,2,3表示用第0到3号卡batch 128是四张卡的总batch每张卡实际拿到32所以batch要能被卡数整除。imgsz 640是常见训练尺寸零售柜商品属于中小目标不建议降到320条件允许可以试768但显存占用会涨不少。多卡训练有个坑验证阶段batch默认是单卡推理如果数据集较大验证会明显慢于训练。ultralytics在高版本里会自动处理但如果你用的是老版本脚本看到每个epoch后半段突然卡住多半在跑验证。另一个问题是多卡训练时BN层的行为和单卡不完全一致小batch下多卡收益会缩水总batch小于64时不如单卡省心。4.4 CPU与Mac M芯片smoke test可以正式训练别指望CPU和Mac M芯片能不能跑能但只能用来验证数据和脚本链路别指望训出一个能上线的模型。启动方式如下# CPU把device指定为cpubatch降到8或16epochs先跑5轮 python train.py --data data.yaml --weights yolo11n.pt --device cpu --batch 8 --epochs 5 --imgsz 640 # Mac M芯片PyTorch的MPS后端 python train.py --data data.yaml --weights yolo11n.pt --device mps --batch 8 --epochs 5 --imgsz 640Mac上device mps依赖PyTorch的MPS支持新版PyTorch基本可用但个别算子仍然会触发数值问题。如果loss在训练几轮后变成nan优先退回device cpu验证是否MPS的问题。CPU训练5000张图、113类、640分辨率一个epoch可能要十几分钟到半小时100轮就是几十个小时只适合做链路验证。有一点值得提醒博主提供的训练日志大概率是在GPU上跑出来的你在CPU/Mac上复现时loss曲线和mAP会明显差一截这不是脚本问题是算力差异。脚本里CPU和Mac平台的默认epochs做了调低处理我建议第一次跑5轮确认loss在降、目录结构没错再换到GPU正式训练。4.5 进阶参数resume、seed、cache、amp一键脚本除了改平台和batch有些参数值得固定下来。resume用于训练中断后接续比如跑到第80轮机器重启加上--resume能从断点继续。seed必须固定YOLO11训练有随机性不固定seed两次训练结果差异很大复现实验时对比不了。cache参数把图片加载进内存显存够的话训练会快不少但5000张图全cache会占不少内存建议先确认内存余量。amp混合精度默认开启能省显存但某些老旧GPU上可能出现loss异常如果发现训练结果不稳关掉amp再对比一轮。5. 读博主训练日志从loss到mAP判断零售柜模型能不能上线很多人训练完只看最后一行mAP这是不够的。博主提供的训练结果日志里包含每个epoch的loss、精度、召回率、mAP等指标这些数据能回答一个核心问题模型到底是真能部署还是只在测试集上好看。5.1 loss曲线train_loss与val_loss的方向才是关键YOLO11训练日志里的loss分三块box_loss定位损失、cls_loss分类损失、dfl_loss框分布损失。正常训练时这三者都随epoch下降val_loss会有波动但整体趋势向下。真正要警惕的是train和val之间的gap。具体判断方法看最后20轮的val_loss如果它在某个区间内稳定不再下降说明模型到了收敛点如果train_loss很低、val_loss反弹就是过拟合常见对策是减小epochs、增大数据增强、换更小的模型。如果train_loss和val_loss都降不下去先别折腾网络结构检查数据有没有类别ID错位、标签有没有空文件。损失曲线还有个作用判断脚本平台是否正常。CPU或MPS上训练loss下降通常更慢且抖动更大如果你看到loss在第1轮就变成负值或nan大概率是精度问题或设备算子问题不是模型问题。5.2 mAP0.5 vs mAP0.5:0.95零售柜结算该盯哪个YOLO训练结果里会同时给出两个mAP含义差别很大零售柜场景要分开看。指标计算方式零售柜场景含义mAP0.5IoU阈值0.5时各类别AP均值框大概对上就算对反映粗定位能力mAP0.5:0.95IoU从0.5到0.95取平均框要压得很准才算好反映精细定位能力零售柜结算逻辑通常要求检测框中心落在商品区域内对框和商品的贴合度要求高。mAP0.5看着高但mAP0.5:0.95低说明框边缘不稳定同一帧里框会抖。如果目标是上线两个指标都要看但最终上线前还要单独调置信度阈值mAP是训练阶段的参考不是部署阶段的直接依据。5.3 混淆矩阵与每类召回率找出“长得像”的商品训练完成后runs目录里会自动生成混淆矩阵图。零售柜场景里重点看对角线以外的格子那里是不同类别互相误判的位置。罐装可乐和罐装雪碧、不同口味的果粒橙这类外观接近的商品是最容易串的。每类召回率可以从结果日志里抽出来单独看。如果某个类别样本数不少但召回率明显低于平均大概率是标注框质量或类间相似度问题。我的处理方式是先拉出该类所有训练图看是不是遮挡严重、样本单一再决定补充数据还是合并类别。113类不是所有类都值得保留比如两个外观几乎一样的口味合并成一个类线上损失反而小。5.4 训练日志里经常出现的三个异常信号第一个是loss突然变NaN。原因可能是标签里出现负坐标或宽高为0、学习率过大、MPS后端数值问题。解决思路是检查labels txt里的数值范围把学习率降到0.0005以下Mac上退回CPU验证。第二个是某几个epoch的mAP突然跳0。原因通常是验证集太小某个batch里全是难例指标被拉崩。解决方法是增大val集、固定随机种子。这类跳变不代表模型坏了不用频繁重训。第三个是mAP0.5高但mAP0.5:0.95一直上不去。原因是预测框虽然位置命中但边界不贴合目标。常见对策是提高imgsz到768、调整box_loss权重、延长训练轮数。如果这些都试过没改善考虑标注框本身是不是画得松框不准再怎么训都提不上去。6. 训练完怎么验证导出ONNX、调阈值、真实柜内抽检模型训练完我习惯先别急着部署按下面三个步骤走一遍每一轮都筛掉过不少“看着能上线”的模型。先导出ONNX。YOLO11的best.pt是PyTorch权重部署时边缘端大多不直接吃PyTorch导出成ONNX通用性最好yolo export modelruns/detect/train/weights/best.pt formatonnx opset12opset12是我常用的保守值太新的opset在旧设备上不支持太老的又表达不了模型里的算子。导出后用onnxruntime跑通一次推理确认输出维度是[1, num_detections, 6]这类形状再送去部署。然后是置信度阈值。验证集上mAP最高点时对应的置信度阈值不一定适合线上。零售柜场景里漏检比误检更严重漏检意味着顾客拿了东西没记上直接资损。我一般会把conf阈值设在0.3到0.5之间宁可多出几个误检框让后端结合重力传感器或购物流程二次消解也不能把商品漏掉。具体数值拿验证集算P/R曲线选召回率较高、误检可接受的那个点。最后是真实场景抽检。测试集图片再标准也比不上一段真实柜内视频。拿手机或测试摄像头录一段“拿起、放回、遮挡”的连续动作把视频切成帧跑推理看检测框会不会闪烁、类别会不会跳动。这一步能发现训练数据里没有的灯光反光、玻璃指纹、标签褶皱。从那以后我每次拿到新数据集都会强制走一遍“先验格式、再跑通脚本、固定seed、导出ONNX抽检真实场景”的流程这个流程能挡住80%的返工。这份数据集的获取方式我放在文末了需要的直接取。希望帮到你。本文还有配套的精品资源点击获取 智能零售柜商品检测数据集：5000张真实场景图与YOLO11训练实战
简介智能零售柜商品检测数据集面向新零售场景目标检测项目开发者与算法学习者。内容基于真实智能零售柜监控场景采集的5000张高质量商品图片覆盖罐装饮料、袋装零食等常见品类共标注113个商品类别适合用于零售柜商品检测模型训练及通用新零售场景数据补充。标注采用labelimg完成提供VOC(xml)、COCO(json)、YOLO(txt)三种标准格式可直接接入YOLO等主流算法训练流程。另附YOLO11一键训练脚本支持GPU(GPUs)、CPU、Mac(M芯片)多平台运行并给出博主训练结果日志供参考。资源包为单个PDF文件大小5.77MB内附数据集详细介绍及百度网盘获取方式由于原数据较大故以PDF形式托管。目前已有413人学习下载适合需要真实场景数据集进行算法验证与落地的开发者。1. 目标检测项目落地第一步5000张零售柜商品图值不值得下干过智能零售柜项目的人都懂柜子硬件装好只算一半真正卡上线的是识别。顾客拿起一罐可乐再放回去摄像头要在几百毫秒内完成目标检测、商品定位和数量变化错一个框就是一笔资损。这时候最缺的不是模型结构而是带真实柜内场景、带规范标注的数据。这份资源是智能零售柜商品检测数据集共5000张图来自真实柜内监控场景包含113个商品类别以罐装饮料、袋装零食为主。数据已经用labelimg标注好同时给出VOC(xml)、COCO(json)、YOLO(txt)三种格式标签可以直接喂给YOLO系列训练。随包还带了一份YOLO11一键训练脚本覆盖GPU(GPUs)、CPU、Mac(M芯片)三平台另附博主训练结果日志供参考。我的判断是如果你正在做零售柜商品识别、新零售场景目标检测或者只是想把YOLO训练全流程跑通这份数据值得下。原因是真实柜内监控数据自己采集标注的成本很高而模型泛化恰恰依赖这种带遮挡、反光、人手干扰的真实样本。数据能不能直接用下文从格式、脚本、日志三条线拆给你看。2. 三种标注格式与113类商品VOC/COCO/YOLO的目录结构、转换逻辑与选型拿到任何目标检测数据集我第一件事不是开训而是先把标注格式摸清楚。格式决定你能用哪套训练框架、要不要写转换脚本、出问题后能不能快速定位。这份数据最省事的地方是三种主流格式全部给齐下面拆开讲。2.1 数据构成真实柜内监控113类商品不是网图拼盘数据来源直接决定模型上线后的表现。很多公开数据集用平铺拍摄的生活照杯子、瓶子拍得干干净净一到柜内就翻车。智能零售柜的真实画面是俯拍视角层板会切掉商品底部瓶身反光顾客的手和衣袖会挡住一半包装这些在网图里几乎见不到。这份数据集来自真实柜内监控场景等于把这些脏乱差异提前暴露在训练阶段比后期再去补数据高效得多。113个商品类别对目标检测来说属于中等偏上的量级。做YOLO训练时类别数影响的不只是最后一层分类头大小还直接影响正负样本采样难度。113类意味着某些外观接近的商品会被模型反复纠结比如不同口味的罐装饮料、不同品牌的袋装零食。数据本身有113类但如果训练日志里某几类AP明显偏低优先查这几类的样本数量和遮挡比例而不是急着改loss。标注工具是labelimg这点对排查问题很重要。labelimg导出的VOC xml结构是标准的object节点里有name、bndbox、difficult等字段后续转YOLO时逻辑很直观。5000张图、113类、每张图平均多个框这个标注工作量不是小数目也是这份资源的主要价值所在。2.2 三种格式的目录约定与内容差异三种格式各有各的读取逻辑拿到手先对照下表确认你手里的文件长什么样。格式标注文件关键字段适合做的事VOCxmlfilename、size、object/name、object/bndbox人工复查标注、用labelimg二次修正COCOjsonimages、annotations、categoriesbbox为[x,y,w,h]绝对像素统一评测、跨框架对比、实例分割任务YOLOtxtclass_id、x_center、y_center、w、h全部归一化YOLO系列直接训练、快速迭代VOC格式最利于人工检查因为xml里能看到图片名、图片尺寸、每个目标的类别名和四个角点坐标排查哪张图标错了直接打开看。COCO格式更适合做模型横向对比mmdetection、detectron2这些框架默认读COCO。YOLO格式则是训练效率最高的ultralytics读txt是一行一个目标不需要解析jsonIO开销小。有一个容易忽略的点YOLO格式的txt文件里不保存图片路径它靠文件名和图片目录自动对应。所以图片是images/train/001.jpg标签必须是labels/train/001.txt文件名不一致就直接丢样本。这份数据既然给了三种格式建议训练时只用YOLO格式VOC和COCO留作备份和校验不要混着用。2.3 转换逻辑不依赖工具用脚本自己过一遍哪怕数据已经给了三种格式我仍然建议你写一次转换脚本。原因很简单转换逻辑能帮你验证标注是否干净也能在以后换数据集时直接复用。VOC转YOLO是最常遇到的需求核心就两件事类别名转ID、像素坐标转归一化中心点坐标。import xml.etree.ElementTree as ET from pathlib import Path def voc2yolo(xml_path, class_names, out_dir): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) out_lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_names: continue cls_id class_names.index(name) box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) xc (x1 x2) / 2 / img_w yc (y1 y2) / 2 / img_h w (x2 - x1) / img_w h (y2 - y1) / img_h out_lines.append(f{cls_id} {xc:.6f} {yc:.6f} {w:.6f} {h:.6f}) out_path Path(out_dir) / (Path(xml_path).stem .txt) out_path.write_text(\n.join(out_lines))逻辑说明class_names列表的顺序必须和后续data.yaml里的names完全一致否则会出现类别错位。坐标转换先取xmin、xmax计算中心点再统一除以图片宽高得到0到1之间的归一化值YOLO训练时要求就是这种格式。如果xml里的宽高和实际图片尺寸不一致转换出来的框会整体偏移这是labelimg标注时最容易埋的雷。这段脚本只做转换不做校验。我一般会紧接着写一个画框脚本拿转换后的txt在图上把矩形画出来随机抽20张人工扫一遍。框偏了、类别错了、宽高为0在这一步就能全揪出来而不是等训练完看mAP再回头猜。2.4 选型建议默认YOLOCOCO用于对比实验实际项目里训练阶段我默认只碰YOLO格式。原因有三一是ultralytics生态成熟YOLO11、参数调优、预训练权重下载都围绕这个格式展开二是训练脚本读txt比解析json快迭代实验时省时间三是YOLO格式的归一化坐标和网络输入尺寸解耦换imgsz不用重新标注。COCO格式的价值不在训练在评测。如果你想把这份数据和其它公开数据集做对比或者跑mmdetection里的Faster R-CNN、DETR这类模型COCO是通用语言。VOC格式则留给人工复查。一个常见误操作是把xml也拷贝到labels目录下YOLO训练时检测到非txt文件会报No labels found或直接忽略反而干扰排查。保持目录干净每个格式单独放训练目录里只有图片和txt标签。3. 避坑数据到手直接开训前先检查这五个地方这份数据标注质量宣称是高的但第三方数据集换到自己机器上路径、ID、划分这些问题几乎必现。以下五条不是针对这份数据的问题而是任何目标检测数据落到YOLO训练前我都会先跑一遍的检查项每一条都踩出过实际代价。3.1 类别ID从1开始第一类直接消失现象训练日志里class 0的AP一直是0precision和recall曲线没有点其它类别正常。检查class_names后发现第一个类别完全没参与训练。原因labelimg标注时class_names是按自然顺序排的有些转换脚本直接拿index(name)1当类别ID导致所有ID整体从1开始。YOLO要求类别ID从0计数一旦ID整体偏移第一个类别等于被空出来了。解决训练前用一个命令扫描所有标签txt里出现过的ID看是否从0开始且连续。我通常这样做cat labels/train/*.txt | awk {print $1} | sort -n -u如果输出从0开始、没有跳号基本安全。如果从1开始或中间缺了某个ID就把转换脚本里的编号逻辑改成从0计数重新生成全部txt不要手工改113类手工改必出错。3.2 把COCO的bbox当成YOLO读框全部错位现象训练能正常跑完loss也在降但预测框全部落在目标左上角宽高明显不对。用小图可视化时框和商品错开半个身位。原因COCO的bbox是[x, y, w, h]x和y是左上角坐标单位是像素YOLO是[class_id, x_center, y_center, w, h]中心点坐标且归一化。直接套用意味着YOLO把左上角当成了中心点又少做了除以宽高的归一化框自然全偏。解决转换时严格按两步走先算中心点再除以图片宽高。很多现成转换工具会帮忙做但你得确认它读的是annotations里的bbox字段而不是segmentation。转换完拿一张图用OpenCV画框验证不要信肉眼扫坐标画出来最直接。3.3 Windows路径、中文路径导致Linux训练直接报错现象在Windows上下载解压的数据集拿到Linux服务器上训练启动时报找不到图片或者opencv读取图片返回空训练出来的模型AP是0。日志里经常出现No such file or directory、Unable to read image。原因Windows路径分隔符是\Linux是/txt里如果存了路径字符串反斜杠会被当成转义字符。中文路径在Linux下如果locale没配好imread同样读不出来。解决把数据集目录统一改成英文路径里不要有空格。如果标注文件里有路径字段用脚本把所有\替换成/。更干净的做法是训练时不在标注里读路径让ultralytics按images和labels目录名自动对应。出现读取错误时先手动ls一下报错路径别急着调参数多半是路径问题。3.4 没有划分train/val验证指标虚高或震荡现象训练日志里val_loss低得离谱mAP0.5到了0.95以上但拿到真实柜内视频一测漏检严重。另一种情况是val_loss上下剧烈震荡每个epoch的mAP相差10个点以上。原因训练集和验证集没有按类别分布分开导致部分类别只在训练集出现验证时模型“作弊”看到了训练图。验证集太小也是一个原因几百张图的val集一个batch的误差就会让指标剧烈抖动。解决按类别分层划分常见做法是8:2或7:3。先确认val集合里每个类别都至少有5到10个实例否则该类的mAP参考价值极低。划分完检查val目录中的类别ID分布和train基本一致。这一点对113类的数据集格外重要类别多某个类只有几十张图是常事。3.5 difficult/occluded样本没处理mAP虚高现象模型在遮挡严重的商品上基本检测不到但整体mAP仍然很高上线后才发现问题集中在固定几种场景。原因VOC标注里带difficult或occluded标记的样本本意是“太难不参与评估”。转换到YOLO格式时如果没有跳过这些目标它们会被当成普通正样本模型学不到有效特征评估时又把它们算进去两头都虚。解决转换时显式判断difficult字段为1的object直接跳过不生成对应的YOLO行。如果数据集没有这个字段但存在大量遮挡样本建议单独把这类样本归入hard_set训练完用它做针对性测试。零售柜场景里手部遮挡、瓶身反光都是高频难例这部分不单独评估上线就会翻车。4. YOLO11一键训练脚本GPU多卡、CPU、Mac M芯片的启动与参数调法这份资源附赠的YOLO11一键训练脚本价值不在代码量而在把三平台启动方式封装好了。YOLO11本身是ultralytics体系核心训练命令不复杂但GPU、CPU、Mac M芯片三种环境差异很大脚本把这些差异收敛到几个可改参数上。4.1 为什么零售柜场景直接选YOLO11YOLO11是目前YOLO系列里工程落地最顺手的一代检测头、CSP模块、训练策略都是现成的预训练权重直接下载不需要从头训。对113类商品检测来说模型容量不是瓶颈数据质量和部署环境才是。零售柜大多用边缘设备算力有限YOLO11的n和s版本完全够用。选型边界要清楚YOLO11擅长速度和精度的平衡但不等于万能。如果柜内商品极小、摄像头分辨率不够再好的模型也救不回来。另一个常见误区是一上来就换大模型YOLO11x参数量翻几倍训练和推理都变慢但113类场景精度的提升可能只有零点几个点。我一般先用yolo11n跑通全流程再对比s版本决定是否升级。4.2 数据目录与data.yaml先让脚本找到图YOLO训练脚本对数据目录有固定约定不是随便指定一个图片文件夹就行。拿到这份资源后先把数据整理成下面的结构retail_dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamlimages/train放训练图images/val放验证图labels目录结构和它一一对应。data.yaml的内容类似这样path: ./retail_dataset train: images/train val: images/val names: 0: cola_can 1: juice_bottle # ... 一直列到第112个类别names的顺序必须和labels txt里的class_id一致。常见错误是path写成了绝对路径换一台机器直接失效。我一般用相对路径 scripts在数据集同级目录执行时不会出错。另外注意train:和val:要写成相对于path的路径而不是./images/train这样带前缀的写法ultralytics会自动拼接。4.3 GPU(GPUs)多卡device与batch的配套关系有N卡就优先用GPU这是YOLO11训练脚本的主场。单卡和多卡的主要区别在batch和device两个参数。脚本里的命令大致是这样# 单卡batch根据显存调整16G显存起步建议648G显存用32或16 python train.py --data data.yaml --weights yolo11n.pt --device 0 --batch 64 --epochs 100 --imgsz 640 # 多卡device写卡号batch是总batch程序按卡数切分 python train.py --data data.yaml --weights yolo11n.pt --device 0,1,2,3 --batch 128 --epochs 100 --imgsz 640参数说明device 0,1,2,3表示用第0到3号卡batch 128是四张卡的总batch每张卡实际拿到32所以batch要能被卡数整除。imgsz 640是常见训练尺寸零售柜商品属于中小目标不建议降到320条件允许可以试768但显存占用会涨不少。多卡训练有个坑验证阶段batch默认是单卡推理如果数据集较大验证会明显慢于训练。ultralytics在高版本里会自动处理但如果你用的是老版本脚本看到每个epoch后半段突然卡住多半在跑验证。另一个问题是多卡训练时BN层的行为和单卡不完全一致小batch下多卡收益会缩水总batch小于64时不如单卡省心。4.4 CPU与Mac M芯片smoke test可以正式训练别指望CPU和Mac M芯片能不能跑能但只能用来验证数据和脚本链路别指望训出一个能上线的模型。启动方式如下# CPU把device指定为cpubatch降到8或16epochs先跑5轮 python train.py --data data.yaml --weights yolo11n.pt --device cpu --batch 8 --epochs 5 --imgsz 640 # Mac M芯片PyTorch的MPS后端 python train.py --data data.yaml --weights yolo11n.pt --device mps --batch 8 --epochs 5 --imgsz 640Mac上device mps依赖PyTorch的MPS支持新版PyTorch基本可用但个别算子仍然会触发数值问题。如果loss在训练几轮后变成nan优先退回device cpu验证是否MPS的问题。CPU训练5000张图、113类、640分辨率一个epoch可能要十几分钟到半小时100轮就是几十个小时只适合做链路验证。有一点值得提醒博主提供的训练日志大概率是在GPU上跑出来的你在CPU/Mac上复现时loss曲线和mAP会明显差一截这不是脚本问题是算力差异。脚本里CPU和Mac平台的默认epochs做了调低处理我建议第一次跑5轮确认loss在降、目录结构没错再换到GPU正式训练。4.5 进阶参数resume、seed、cache、amp一键脚本除了改平台和batch有些参数值得固定下来。resume用于训练中断后接续比如跑到第80轮机器重启加上--resume能从断点继续。seed必须固定YOLO11训练有随机性不固定seed两次训练结果差异很大复现实验时对比不了。cache参数把图片加载进内存显存够的话训练会快不少但5000张图全cache会占不少内存建议先确认内存余量。amp混合精度默认开启能省显存但某些老旧GPU上可能出现loss异常如果发现训练结果不稳关掉amp再对比一轮。5. 读博主训练日志从loss到mAP判断零售柜模型能不能上线很多人训练完只看最后一行mAP这是不够的。博主提供的训练结果日志里包含每个epoch的loss、精度、召回率、mAP等指标这些数据能回答一个核心问题模型到底是真能部署还是只在测试集上好看。5.1 loss曲线train_loss与val_loss的方向才是关键YOLO11训练日志里的loss分三块box_loss定位损失、cls_loss分类损失、dfl_loss框分布损失。正常训练时这三者都随epoch下降val_loss会有波动但整体趋势向下。真正要警惕的是train和val之间的gap。具体判断方法看最后20轮的val_loss如果它在某个区间内稳定不再下降说明模型到了收敛点如果train_loss很低、val_loss反弹就是过拟合常见对策是减小epochs、增大数据增强、换更小的模型。如果train_loss和val_loss都降不下去先别折腾网络结构检查数据有没有类别ID错位、标签有没有空文件。损失曲线还有个作用判断脚本平台是否正常。CPU或MPS上训练loss下降通常更慢且抖动更大如果你看到loss在第1轮就变成负值或nan大概率是精度问题或设备算子问题不是模型问题。5.2 mAP0.5 vs mAP0.5:0.95零售柜结算该盯哪个YOLO训练结果里会同时给出两个mAP含义差别很大零售柜场景要分开看。指标计算方式零售柜场景含义mAP0.5IoU阈值0.5时各类别AP均值框大概对上就算对反映粗定位能力mAP0.5:0.95IoU从0.5到0.95取平均框要压得很准才算好反映精细定位能力零售柜结算逻辑通常要求检测框中心落在商品区域内对框和商品的贴合度要求高。mAP0.5看着高但mAP0.5:0.95低说明框边缘不稳定同一帧里框会抖。如果目标是上线两个指标都要看但最终上线前还要单独调置信度阈值mAP是训练阶段的参考不是部署阶段的直接依据。5.3 混淆矩阵与每类召回率找出“长得像”的商品训练完成后runs目录里会自动生成混淆矩阵图。零售柜场景里重点看对角线以外的格子那里是不同类别互相误判的位置。罐装可乐和罐装雪碧、不同口味的果粒橙这类外观接近的商品是最容易串的。每类召回率可以从结果日志里抽出来单独看。如果某个类别样本数不少但召回率明显低于平均大概率是标注框质量或类间相似度问题。我的处理方式是先拉出该类所有训练图看是不是遮挡严重、样本单一再决定补充数据还是合并类别。113类不是所有类都值得保留比如两个外观几乎一样的口味合并成一个类线上损失反而小。5.4 训练日志里经常出现的三个异常信号第一个是loss突然变NaN。原因可能是标签里出现负坐标或宽高为0、学习率过大、MPS后端数值问题。解决思路是检查labels txt里的数值范围把学习率降到0.0005以下Mac上退回CPU验证。第二个是某几个epoch的mAP突然跳0。原因通常是验证集太小某个batch里全是难例指标被拉崩。解决方法是增大val集、固定随机种子。这类跳变不代表模型坏了不用频繁重训。第三个是mAP0.5高但mAP0.5:0.95一直上不去。原因是预测框虽然位置命中但边界不贴合目标。常见对策是提高imgsz到768、调整box_loss权重、延长训练轮数。如果这些都试过没改善考虑标注框本身是不是画得松框不准再怎么训都提不上去。6. 训练完怎么验证导出ONNX、调阈值、真实柜内抽检模型训练完我习惯先别急着部署按下面三个步骤走一遍每一轮都筛掉过不少“看着能上线”的模型。先导出ONNX。YOLO11的best.pt是PyTorch权重部署时边缘端大多不直接吃PyTorch导出成ONNX通用性最好yolo export modelruns/detect/train/weights/best.pt formatonnx opset12opset12是我常用的保守值太新的opset在旧设备上不支持太老的又表达不了模型里的算子。导出后用onnxruntime跑通一次推理确认输出维度是[1, num_detections, 6]这类形状再送去部署。然后是置信度阈值。验证集上mAP最高点时对应的置信度阈值不一定适合线上。零售柜场景里漏检比误检更严重漏检意味着顾客拿了东西没记上直接资损。我一般会把conf阈值设在0.3到0.5之间宁可多出几个误检框让后端结合重力传感器或购物流程二次消解也不能把商品漏掉。具体数值拿验证集算P/R曲线选召回率较高、误检可接受的那个点。最后是真实场景抽检。测试集图片再标准也比不上一段真实柜内视频。拿手机或测试摄像头录一段“拿起、放回、遮挡”的连续动作把视频切成帧跑推理看检测框会不会闪烁、类别会不会跳动。这一步能发现训练数据里没有的灯光反光、玻璃指纹、标签褶皱。从那以后我每次拿到新数据集都会强制走一遍“先验格式、再跑通脚本、固定seed、导出ONNX抽检真实场景”的流程这个流程能挡住80%的返工。这份数据集的获取方式我放在文末了需要的直接取。希望帮到你。本文还有配套的精品资源点击获取