简介为满足智能零售柜商品检测项目对真实商品数据的需求这套配套资料以PDF文档形式呈现面向目标检测开发者、算法工程师及新零售场景研究者。资源包共1个文件大小约5.79MB内附数据集详细介绍与百度网盘获取方式便于按说明下载完整数据。数据集源自真实智能零售柜监控场景包含1000张高质量商品图片覆盖罐装饮料、袋装零食等常见品类标注113个商品类别并提供VOC、COCO、YOLO三种格式标签可直接用于YOLO等主流检测模型训练。除数据外还附赠YOLO11一键训练脚本支持GPU、CPU、MacM芯片多平台运行并附有博主训练结果日志参考可快速复现训练流程。目前已有528人学习浏览适合作为智能零售柜商品检测项目的数据支撑也可补充通用新零售场景检测数据集。1. 项目拆解智能零售柜场景下的目标检测到底在检测什么做智能零售柜的视觉方案本质上不是做一个目标检测模型这么简单而是要在极其复杂的真实货架场景里把哪个商品、在什么位置、被拿走了还是放回来了这件事搞清楚。我拿到这套方案和数据的第一反应是它戳中了零售柜落地时的两个核心痛点数据集标注格式混乱、训练环境迁移成本高。很多人刚接触零售柜项目时会问这跟普通的目标检测有什么不一样区别非常大。零售柜里拍出来的图视角是自上而下或者斜上方俯拍货架层板之间会产生严重遮挡瓶装饮料的瓶盖和瓶身反光会让模型分不清是同一个商品还是两个不同的东西再加上玻璃柜门上的反光、夜间补光不匀、商品包装高度相似比如各种白色牛奶盒这些噪声叠加在一起对检测模型的鲁棒性要求比普通街景检测高出一个量级。这套方案用1000张真实柜内图像作为训练基底配齐了VOC、COCO、YOLO三种主流标注格式还内置了YOLO11的一键训练脚本支持GPU、CPU、Mac三平台。从数据到训练闭环都齐了对于想快速验证零售柜检测能不能跑通的团队、做毕设的学生、或者刚切入这个赛道的算法工程师是一套很完整的起步样板。接下来我会从数据集的标注设计、格式转换逻辑、YOLO11训练脚本的三平台适配以及实际训练时最容易踩的坑这几个维度把这套方案完整拆开来看。2. 为什么是1000张图小规模数据集在真实项目里的生存法则2.1 1000张图背后的权衡逻辑先说一个反直觉的结论在很多垂直场景里1000张高质量、标注严谨的图像比10000张差不多能用的图像更能训练出可落地的模型。原因很简单——零售柜商品检测的难点从来不是类别太多认不过来而是同一类商品在不同光照、不同角度、不同遮挡程度下长得完全不一样。1000张图如果覆盖了早中晚光照变化、正面/侧面/俯视角度变化、单瓶/整排/堆叠摆放状态模型能学到的特征分布反而更集中、更有效。从实际项目经验来看零售柜每个SKU库存量单位最少需要30~50张有效标注图像覆盖至少3种摆放角度和2种光照条件。如果柜子里有20个SKU1000张图正好卡在数据冗余度刚好够、标注量又不至于失控的甜点上。超过这个规模标注成本翻倍增长但mAP平均精度均值提升往往只有1~2个点边际效益明显下降。2.2 单类目标数量分布被大多数人忽略的细节评估这套数据集质量时不能只看总张数一定要看类别平衡度。我见过太多数据集1000张图里某个主力商品占了40%的标注框尾部长尾商品一共只有十几个框训练出来的模型对大样本类别过拟合严重小样本类别几乎全部漏检。拿到这套数据集后第一件事不是急着训练而是做一次标注框数量统计。用Python读一下COCO格式的JSON或者YOLO格式的txt数清楚每个类别的检测框总量和平均每张图的检测框密度。理想状态下单个类别标注框数量差异不应该超过一个数量级。如果发现某类框太少优先考虑用数据增强做类别级别的过采样或者针对这类商品补拍、补标注而不是盲目增加训练轮次。2.3 评价指标别被mAP这一个数字骗了智能零售柜这个场景光看mAP会严重失真。因为柜内商品遮挡多、小目标密布mAP 0.5和mAP 0.5:0.95之间的差距代表了模型框得准和框得中的差距。自己做模型评估时我会同时关注三个维度小目标检出率AP_s零售柜里后排商品经常只有几十个像素宽这一项不过关后排商品会集体漏检。遮挡目标的置信度分布拿一批人工标注了严重遮挡的图出来单独算召回率。遮挡场景召回率低于80%基本没法在真实柜机上用。类别混淆矩阵尤其是白色纸盒类商品之间的混淆情况牛奶盒和酸奶盒靠混淆矩阵能直观看出模型把A类认成B类的比例。这套数据集的真实价值在于提供了可以在这些维度上去反复验证的底层素材。3. VOC、COCO、YOLO三种格式的转换逻辑与使用场景3.1 三种格式的技术底座零售柜项目里最烦人的不是模型训练本身而是数据格式的来回倒腾。VOC、COCO、YOLO三种格式的存储结构和读取方式完全不同混在一起用的人不在少数。VOC格式的核心是XML文件一张图对应一个同名XML每个目标用一个object节点描述里面含类别名、bndbox边界框坐标、以及difficult和truncated等属性标记。它的优势是可读性极强、人工检查方便缺点是目录结构重——必须按照Annotations、JPEGImages、ImageSets/Main三个目录分开存放而且没有统一的类别ID管理机制。COCO格式把所有标注统一塞进一个大的JSON文件里采用info、licenses、images、annotations、categories五个顶层字段组织信息。每个annotation里用bbox字段存[x, y, width, height]格式的坐标area字段标面积category_id关联到categories里的类别表。它的优势是机器读取效率高、和服务器训练框架衔接顺畅缺点是JSON文件动辄几百MB肉眼检查几乎不可能。YOLO格式是三种里结构最简单但最容易踩坑的每个目标在txt里占一行格式是class_id x_center y_center width height所有坐标值必须归一化到0~1之间。它本身就是为YOLO系列模型量身定做的训练速度快、IO开销小但一旦有人误把像素坐标写进去或者忘了归一化模型会直接训练出离谱的loss值。3.2 三种格式在零售柜项目里的分工这套方案同时提供三种格式不是闲着没事干而是在实际项目里它们各有不可替代的用途。转换方向最常用的路径是VOC或COCO转YOLO因为YOLO系列训练只吃YOLO格式。当模型训练效果不理想、需要排查模型到底学到了什么时用VOC格式在LabelImg这类工具里逐张可视化边界框能快速定位标注错位、框偏大偏小的问题。而COCO格式主要用于做评估和对比实验——比如用Detectron2、MMDetection这些框架跑COCO格式的评测流程能拿到更细粒度的mAP分项报告。3.3 格式转换的三个关键要点自己写格式转换脚本时有三个环节最容易出错坐标换算公式必须记死。VOC和COCO存的是左上角和宽高YOLO存的是中心点和归一化宽高# VOC坐标转YOLO dw 1.0 / img_width dh 1.0 / img_height x_center (xmin xmax) / 2.0 * dw y_center (ymin ymax) / 2.0 * dh w (xmax - xmin) * dw h (ymax - ymin) * dh类别ID必须从0开始连续编号。YOLO格式的类别ID从0起算但VOC里类别是字符串。转换时一定要建立{商品A: 0, 商品B: 1}这样的映射表并且保证映射表顺序和后期训练用的YAML配置完全一致。这里一旦错位类别标签全乱损失曲线看起来正常但预测结果完全对不上。COCO格式要手动维护图片尺寸信息。COCO的JSON里每张图的width和height字段是归一化和还原坐标的基准。从COCO转YOLO时如果width填错整个归一化坐标全部错位但肉眼很难发现。我习惯在转换完成后随机抽10张图做反向验证——把转换后的YOLO坐标画回图上再用原图比对一眼就能看出错没错。4. 实操环节基于YOLO11的零售柜商品检测训练全流程4.1 环境准备与配置建议YOLO11是Ultralytics在2024年推出的新一代目标检测框架延续了YOLOv8的一体化设计思路默认情况下通过pip install ultralytics就能装好。安装命令只有一条pip install ultralytics但别以为装完就万事大吉了。零售柜项目训练时的显存占用和推理速度要求跟普通目标检测项目有明显差异。我建议按下面的场景做选择使用场景推荐硬件/模式说明日常训练NVIDIA GPU6GB以上显存建议开启cacheTrue做数据预加载训练速度提升明显应急训练/调试CPUYOLO11s模型在CPU上也能跑只是慢很多适合验证代码通不通Mac平台Apple SiliconM系列YOLO11支持Apple Metal加速表现优于同价位的入门级GPU注意如果你用的是Windows系统GPU训练前先手动确认CUDA和PyTorch版本是否匹配。torch.cuda.is_available()输出True再开始训练否则会自动掉回CPU训练速度慢十倍不止。4.2 数据集目录结构与YAML配置YOLO11训练自己的数据集时最关键的准备工作是把数据集整理成标准目录结构。我的建议是以下面这种方式组织retail_shelf_dataset/ ├── images/ │ ├── train/ # 训练集图片 │ └── val/ # 验证集图片 ├── labels/ │ ├── train/ # 训练集标注txt │ └── val/ # 验证集标注txt └── dataset.yaml # 数据配置文件dataset.yaml是训练脚本的地图YOLO11会严格按照这个文件来找数据。一个零售柜项目常见的配置长这样path: retail_shelf_dataset/ # 数据集根目录绝对路径或相对路径 train: images/train # 训练集图片目录 val: images/val # 验证集图片目录 nc: 20 # 类别总数按实际SKU数填 names: [cola, juice, milk, ...] # 类别名列表顺序必须与txt里的class_id一致4.3 一键训练脚本的设计与使用这套方案里最值得说的是它自带的三平台训练脚本。脚本设计的核心思路是先自动检测当前运行环境里的加速设备GPU、CPU还是Apple芯片再自动匹配对应的设备名称和混精度策略最后统一调起YOLO11的train接口。在GPU平台上脚本会自动调用device0并启用AMP自动混精度训练显存占用和训练速度都表现优秀在Mac平台上脚本走的是Apple Metal的MPS后端——YOLO11在这条路径上的适配已经比较成熟M系列芯片跑YOLO11s的体验要明显好于纯CPU训练。而在CPU平台上脚本会提示设置更小的batch-size避免内存溢出。真正意义上做到了拿到就能跑、跑起来就能训省了刚从Windows转到Mac开发的同学反复查文档的功夫。训练命令执行完之后模型权重文件默认保存在runs/detect/train/weights/best.pt。best.pt以验证集上loss或者mAP最优为准last.pt则是最后一个epoch的权重。线上部署或者做后续测试时优先取best.pt。4.4 零售柜场景的关键训练参数解读训练零售柜模型参数调整是收益最高的环节。我把自己常用的几个关键参数拆出来做个对照imgsz训练图像尺寸建议设640。零售柜里小目标偏多可以直接调到960算力许可的情况下小目标检出的提升很明显但训练时间会翻倍。epochs训练轮次1000张图、20个类别以内的任务300个epoch一般足够收敛。设太少会欠拟合设太多会过拟合重点看验证集loss曲线是否在后期出现反弹。batch-size批次大小GPU显存8GB以下建议设16显存不足时降低到8。不要超过32零售柜图片里商品密度高batch过大会导致单张图的梯度贡献被稀释。patience早停耐心值设30~50。如果连续30个epoch验证集指标都不再提升训练自动停止能省下不少时间。我这套方案在1000张图上实测大约140~180个epoch就能稳定收敛。cacheTrue数据缓存强烈建议开启。零售柜图片每次做Mosaic增强时IO开销很大开启缓存后训练效率提升30%以上。5. 训练过程质量评估从损失曲线到实际柜体效果5.1 四组损失曲线的读法训练过程中YOLO11会输出box_loss边框损失、cls_loss分类损失、dfl_loss分布焦点损失、以及对应的验证集损失。我的观察习惯是盯验证集的三条损失曲线——如果它们在训练后期开始反弹说明模型开始过拟合训练集此时最优权重早已出现在前面的某个epoch里靠best.pt就能挽回。5.2 从框准到好用真实柜体环境验证老实说在你的电脑上mAP再好看放进真实智能零售柜里能不能用完全是另一回事。我的固定流程是训练完毕之后马上用柜机回传的原始视频做一次盲测——模型完全没见过这些画面。重点看三类现象柜内灯光反光导致的误检、相邻商品遮挡导致的漏检、取货过程中手掌遮住商品时的短暂丢帧。这些现象在测试集上都不会暴露却决定了系统在商业场景里的存活率。5.3 模型量化和部署注意事项零售柜的算力板卡通常比训练服务器弱一大截YOLO11n或YOLO11s导出为TensorRT格式后推理速度能跑到30ms以内。导出的关键命令只有一行model.export(formatengine, halfTrue, imgsz640)但有几个小坑得提前避开导出用的imgsz必须和训练时保持一致否则精度掉得厉害halfTrue半精度要求板卡支持FP16导出后的engine文件绑定具体硬件环境换一块板卡必须重新导出。6. 常见问题速查表我这个项目的踩坑记录问题现象根本原因解决方案训练时loss不降数值在4~8之间震荡类别ID从1开始未从0开始检查txt文件首列确保所有类别ID ∈ {0,1,...,nc-1}训练时loss快速降到0但val集mAP几乎为0训练集和验证集用了相同图片划分数据集时去重按图片名哈希做分层抽样大量检测框偏大或偏移归一化坐标写错用反向绘制验证转换脚本对比原始标注CPU训练极慢一个epoch要1小时未检测到GPU环境执行python -c import torch; print(torch.cuda.is_available())排查模型在夜间补光场景下mAP骤降训练数据中夜间图片占比不足在1000张基础上补充100张夜间补光图做微调小瓶装饮料在远处漏检训练尺寸不足将imgsz从640提高到960重新训练Mac上训练时提示MPS unavailablePyTorch版本过旧升级至PyTorch 2.0以上确认系统为macOS 12.3零售柜商品检测这个方向前面还有不少路要走。1000张图起步只是第一步后面随着柜机的点位不断增加、季节限定商品的更替、门店光照环境的差异化数据积累是一个持续滚动的过程。拿着这套方案去跑通一遍流程比看十篇文章都有用。真上手之后你会发现最难的不是让模型收敛而是让数据集和标注规范能跟着真实场景一起进化这才是做得久、走得远的关键。本文还有配套的精品资源点击获取 智能零售柜商品检测：从数据集到YOLO11训练全流程解析
简介为满足智能零售柜商品检测项目对真实商品数据的需求这套配套资料以PDF文档形式呈现面向目标检测开发者、算法工程师及新零售场景研究者。资源包共1个文件大小约5.79MB内附数据集详细介绍与百度网盘获取方式便于按说明下载完整数据。数据集源自真实智能零售柜监控场景包含1000张高质量商品图片覆盖罐装饮料、袋装零食等常见品类标注113个商品类别并提供VOC、COCO、YOLO三种格式标签可直接用于YOLO等主流检测模型训练。除数据外还附赠YOLO11一键训练脚本支持GPU、CPU、MacM芯片多平台运行并附有博主训练结果日志参考可快速复现训练流程。目前已有528人学习浏览适合作为智能零售柜商品检测项目的数据支撑也可补充通用新零售场景检测数据集。1. 项目拆解智能零售柜场景下的目标检测到底在检测什么做智能零售柜的视觉方案本质上不是做一个目标检测模型这么简单而是要在极其复杂的真实货架场景里把哪个商品、在什么位置、被拿走了还是放回来了这件事搞清楚。我拿到这套方案和数据的第一反应是它戳中了零售柜落地时的两个核心痛点数据集标注格式混乱、训练环境迁移成本高。很多人刚接触零售柜项目时会问这跟普通的目标检测有什么不一样区别非常大。零售柜里拍出来的图视角是自上而下或者斜上方俯拍货架层板之间会产生严重遮挡瓶装饮料的瓶盖和瓶身反光会让模型分不清是同一个商品还是两个不同的东西再加上玻璃柜门上的反光、夜间补光不匀、商品包装高度相似比如各种白色牛奶盒这些噪声叠加在一起对检测模型的鲁棒性要求比普通街景检测高出一个量级。这套方案用1000张真实柜内图像作为训练基底配齐了VOC、COCO、YOLO三种主流标注格式还内置了YOLO11的一键训练脚本支持GPU、CPU、Mac三平台。从数据到训练闭环都齐了对于想快速验证零售柜检测能不能跑通的团队、做毕设的学生、或者刚切入这个赛道的算法工程师是一套很完整的起步样板。接下来我会从数据集的标注设计、格式转换逻辑、YOLO11训练脚本的三平台适配以及实际训练时最容易踩的坑这几个维度把这套方案完整拆开来看。2. 为什么是1000张图小规模数据集在真实项目里的生存法则2.1 1000张图背后的权衡逻辑先说一个反直觉的结论在很多垂直场景里1000张高质量、标注严谨的图像比10000张差不多能用的图像更能训练出可落地的模型。原因很简单——零售柜商品检测的难点从来不是类别太多认不过来而是同一类商品在不同光照、不同角度、不同遮挡程度下长得完全不一样。1000张图如果覆盖了早中晚光照变化、正面/侧面/俯视角度变化、单瓶/整排/堆叠摆放状态模型能学到的特征分布反而更集中、更有效。从实际项目经验来看零售柜每个SKU库存量单位最少需要30~50张有效标注图像覆盖至少3种摆放角度和2种光照条件。如果柜子里有20个SKU1000张图正好卡在数据冗余度刚好够、标注量又不至于失控的甜点上。超过这个规模标注成本翻倍增长但mAP平均精度均值提升往往只有1~2个点边际效益明显下降。2.2 单类目标数量分布被大多数人忽略的细节评估这套数据集质量时不能只看总张数一定要看类别平衡度。我见过太多数据集1000张图里某个主力商品占了40%的标注框尾部长尾商品一共只有十几个框训练出来的模型对大样本类别过拟合严重小样本类别几乎全部漏检。拿到这套数据集后第一件事不是急着训练而是做一次标注框数量统计。用Python读一下COCO格式的JSON或者YOLO格式的txt数清楚每个类别的检测框总量和平均每张图的检测框密度。理想状态下单个类别标注框数量差异不应该超过一个数量级。如果发现某类框太少优先考虑用数据增强做类别级别的过采样或者针对这类商品补拍、补标注而不是盲目增加训练轮次。2.3 评价指标别被mAP这一个数字骗了智能零售柜这个场景光看mAP会严重失真。因为柜内商品遮挡多、小目标密布mAP 0.5和mAP 0.5:0.95之间的差距代表了模型框得准和框得中的差距。自己做模型评估时我会同时关注三个维度小目标检出率AP_s零售柜里后排商品经常只有几十个像素宽这一项不过关后排商品会集体漏检。遮挡目标的置信度分布拿一批人工标注了严重遮挡的图出来单独算召回率。遮挡场景召回率低于80%基本没法在真实柜机上用。类别混淆矩阵尤其是白色纸盒类商品之间的混淆情况牛奶盒和酸奶盒靠混淆矩阵能直观看出模型把A类认成B类的比例。这套数据集的真实价值在于提供了可以在这些维度上去反复验证的底层素材。3. VOC、COCO、YOLO三种格式的转换逻辑与使用场景3.1 三种格式的技术底座零售柜项目里最烦人的不是模型训练本身而是数据格式的来回倒腾。VOC、COCO、YOLO三种格式的存储结构和读取方式完全不同混在一起用的人不在少数。VOC格式的核心是XML文件一张图对应一个同名XML每个目标用一个object节点描述里面含类别名、bndbox边界框坐标、以及difficult和truncated等属性标记。它的优势是可读性极强、人工检查方便缺点是目录结构重——必须按照Annotations、JPEGImages、ImageSets/Main三个目录分开存放而且没有统一的类别ID管理机制。COCO格式把所有标注统一塞进一个大的JSON文件里采用info、licenses、images、annotations、categories五个顶层字段组织信息。每个annotation里用bbox字段存[x, y, width, height]格式的坐标area字段标面积category_id关联到categories里的类别表。它的优势是机器读取效率高、和服务器训练框架衔接顺畅缺点是JSON文件动辄几百MB肉眼检查几乎不可能。YOLO格式是三种里结构最简单但最容易踩坑的每个目标在txt里占一行格式是class_id x_center y_center width height所有坐标值必须归一化到0~1之间。它本身就是为YOLO系列模型量身定做的训练速度快、IO开销小但一旦有人误把像素坐标写进去或者忘了归一化模型会直接训练出离谱的loss值。3.2 三种格式在零售柜项目里的分工这套方案同时提供三种格式不是闲着没事干而是在实际项目里它们各有不可替代的用途。转换方向最常用的路径是VOC或COCO转YOLO因为YOLO系列训练只吃YOLO格式。当模型训练效果不理想、需要排查模型到底学到了什么时用VOC格式在LabelImg这类工具里逐张可视化边界框能快速定位标注错位、框偏大偏小的问题。而COCO格式主要用于做评估和对比实验——比如用Detectron2、MMDetection这些框架跑COCO格式的评测流程能拿到更细粒度的mAP分项报告。3.3 格式转换的三个关键要点自己写格式转换脚本时有三个环节最容易出错坐标换算公式必须记死。VOC和COCO存的是左上角和宽高YOLO存的是中心点和归一化宽高# VOC坐标转YOLO dw 1.0 / img_width dh 1.0 / img_height x_center (xmin xmax) / 2.0 * dw y_center (ymin ymax) / 2.0 * dh w (xmax - xmin) * dw h (ymax - ymin) * dh类别ID必须从0开始连续编号。YOLO格式的类别ID从0起算但VOC里类别是字符串。转换时一定要建立{商品A: 0, 商品B: 1}这样的映射表并且保证映射表顺序和后期训练用的YAML配置完全一致。这里一旦错位类别标签全乱损失曲线看起来正常但预测结果完全对不上。COCO格式要手动维护图片尺寸信息。COCO的JSON里每张图的width和height字段是归一化和还原坐标的基准。从COCO转YOLO时如果width填错整个归一化坐标全部错位但肉眼很难发现。我习惯在转换完成后随机抽10张图做反向验证——把转换后的YOLO坐标画回图上再用原图比对一眼就能看出错没错。4. 实操环节基于YOLO11的零售柜商品检测训练全流程4.1 环境准备与配置建议YOLO11是Ultralytics在2024年推出的新一代目标检测框架延续了YOLOv8的一体化设计思路默认情况下通过pip install ultralytics就能装好。安装命令只有一条pip install ultralytics但别以为装完就万事大吉了。零售柜项目训练时的显存占用和推理速度要求跟普通目标检测项目有明显差异。我建议按下面的场景做选择使用场景推荐硬件/模式说明日常训练NVIDIA GPU6GB以上显存建议开启cacheTrue做数据预加载训练速度提升明显应急训练/调试CPUYOLO11s模型在CPU上也能跑只是慢很多适合验证代码通不通Mac平台Apple SiliconM系列YOLO11支持Apple Metal加速表现优于同价位的入门级GPU注意如果你用的是Windows系统GPU训练前先手动确认CUDA和PyTorch版本是否匹配。torch.cuda.is_available()输出True再开始训练否则会自动掉回CPU训练速度慢十倍不止。4.2 数据集目录结构与YAML配置YOLO11训练自己的数据集时最关键的准备工作是把数据集整理成标准目录结构。我的建议是以下面这种方式组织retail_shelf_dataset/ ├── images/ │ ├── train/ # 训练集图片 │ └── val/ # 验证集图片 ├── labels/ │ ├── train/ # 训练集标注txt │ └── val/ # 验证集标注txt └── dataset.yaml # 数据配置文件dataset.yaml是训练脚本的地图YOLO11会严格按照这个文件来找数据。一个零售柜项目常见的配置长这样path: retail_shelf_dataset/ # 数据集根目录绝对路径或相对路径 train: images/train # 训练集图片目录 val: images/val # 验证集图片目录 nc: 20 # 类别总数按实际SKU数填 names: [cola, juice, milk, ...] # 类别名列表顺序必须与txt里的class_id一致4.3 一键训练脚本的设计与使用这套方案里最值得说的是它自带的三平台训练脚本。脚本设计的核心思路是先自动检测当前运行环境里的加速设备GPU、CPU还是Apple芯片再自动匹配对应的设备名称和混精度策略最后统一调起YOLO11的train接口。在GPU平台上脚本会自动调用device0并启用AMP自动混精度训练显存占用和训练速度都表现优秀在Mac平台上脚本走的是Apple Metal的MPS后端——YOLO11在这条路径上的适配已经比较成熟M系列芯片跑YOLO11s的体验要明显好于纯CPU训练。而在CPU平台上脚本会提示设置更小的batch-size避免内存溢出。真正意义上做到了拿到就能跑、跑起来就能训省了刚从Windows转到Mac开发的同学反复查文档的功夫。训练命令执行完之后模型权重文件默认保存在runs/detect/train/weights/best.pt。best.pt以验证集上loss或者mAP最优为准last.pt则是最后一个epoch的权重。线上部署或者做后续测试时优先取best.pt。4.4 零售柜场景的关键训练参数解读训练零售柜模型参数调整是收益最高的环节。我把自己常用的几个关键参数拆出来做个对照imgsz训练图像尺寸建议设640。零售柜里小目标偏多可以直接调到960算力许可的情况下小目标检出的提升很明显但训练时间会翻倍。epochs训练轮次1000张图、20个类别以内的任务300个epoch一般足够收敛。设太少会欠拟合设太多会过拟合重点看验证集loss曲线是否在后期出现反弹。batch-size批次大小GPU显存8GB以下建议设16显存不足时降低到8。不要超过32零售柜图片里商品密度高batch过大会导致单张图的梯度贡献被稀释。patience早停耐心值设30~50。如果连续30个epoch验证集指标都不再提升训练自动停止能省下不少时间。我这套方案在1000张图上实测大约140~180个epoch就能稳定收敛。cacheTrue数据缓存强烈建议开启。零售柜图片每次做Mosaic增强时IO开销很大开启缓存后训练效率提升30%以上。5. 训练过程质量评估从损失曲线到实际柜体效果5.1 四组损失曲线的读法训练过程中YOLO11会输出box_loss边框损失、cls_loss分类损失、dfl_loss分布焦点损失、以及对应的验证集损失。我的观察习惯是盯验证集的三条损失曲线——如果它们在训练后期开始反弹说明模型开始过拟合训练集此时最优权重早已出现在前面的某个epoch里靠best.pt就能挽回。5.2 从框准到好用真实柜体环境验证老实说在你的电脑上mAP再好看放进真实智能零售柜里能不能用完全是另一回事。我的固定流程是训练完毕之后马上用柜机回传的原始视频做一次盲测——模型完全没见过这些画面。重点看三类现象柜内灯光反光导致的误检、相邻商品遮挡导致的漏检、取货过程中手掌遮住商品时的短暂丢帧。这些现象在测试集上都不会暴露却决定了系统在商业场景里的存活率。5.3 模型量化和部署注意事项零售柜的算力板卡通常比训练服务器弱一大截YOLO11n或YOLO11s导出为TensorRT格式后推理速度能跑到30ms以内。导出的关键命令只有一行model.export(formatengine, halfTrue, imgsz640)但有几个小坑得提前避开导出用的imgsz必须和训练时保持一致否则精度掉得厉害halfTrue半精度要求板卡支持FP16导出后的engine文件绑定具体硬件环境换一块板卡必须重新导出。6. 常见问题速查表我这个项目的踩坑记录问题现象根本原因解决方案训练时loss不降数值在4~8之间震荡类别ID从1开始未从0开始检查txt文件首列确保所有类别ID ∈ {0,1,...,nc-1}训练时loss快速降到0但val集mAP几乎为0训练集和验证集用了相同图片划分数据集时去重按图片名哈希做分层抽样大量检测框偏大或偏移归一化坐标写错用反向绘制验证转换脚本对比原始标注CPU训练极慢一个epoch要1小时未检测到GPU环境执行python -c import torch; print(torch.cuda.is_available())排查模型在夜间补光场景下mAP骤降训练数据中夜间图片占比不足在1000张基础上补充100张夜间补光图做微调小瓶装饮料在远处漏检训练尺寸不足将imgsz从640提高到960重新训练Mac上训练时提示MPS unavailablePyTorch版本过旧升级至PyTorch 2.0以上确认系统为macOS 12.3零售柜商品检测这个方向前面还有不少路要走。1000张图起步只是第一步后面随着柜机的点位不断增加、季节限定商品的更替、门店光照环境的差异化数据积累是一个持续滚动的过程。拿着这套方案去跑通一遍流程比看十篇文章都有用。真上手之后你会发现最难的不是让模型收敛而是让数据集和标注规范能跟着真实场景一起进化这才是做得久、走得远的关键。本文还有配套的精品资源点击获取