说实话第一次接到“商品标签识别”这个需求时我心里是有点打鼓的。这不是那种常见的“猫狗分类”Demo而是要把货架上的商品标签——那种贴在饮料瓶、零食包装、纸箱侧面经常被反光、褶皱、透明胶带覆盖的小纸片——从真实场景照片中准确地找出来再交给下游去读取品名、规格、条码信息。当时甲方最直接的诉求是仓库盘点时人工核对标签太慢一天几千件货光扫码和录入就要耗掉两三个小时他们想要一套能自动识别并归档的方案。我花了大约三周时间用YOLO系列做了一条完整的“检测→裁剪→文字识别”流水线。今天这篇就把整个思考过程、踩坑记录和最终落地效果原原本本写下来。无论你是刚接触目标检测的学生还是被公司派去做类似“XX识别系统”的开发者这套从理论到实践的路径应该都能帮你少走不少弯路。1. 从一次盘点需求说起商品标签识别的真实痛点1.1 需求远不止“找到标签”那么简单先泼一盆冷水很多人听到“商品标签识别”第一反应是“用YOLO框出来不就行了”。但框出来之后呢如果下游还要人工去读标签上的字那这个系统就只是半个系统。我当时和需求方反复确认最终敲定的完整链路是第一级用目标检测模型在整图中定位标签位置输出带倾斜角的四边形坐标第二级把标签区域裁剪下来做透视矫正再丢给OCR组件提取文本字段第三级按预设规则解析出“品名、规格、生产日期、条形码”形成结构化记录。所以“YOLO识别商品标签”只是整条流水线的前半段。但恰恰是这个前半段决定了后面OCR能不能稳定工作。标签框得歪了、缺角了、把旁边另一个标签的边也包进来了OCR结果就会直接报废。1.2 商品标签场景里的几个“魔鬼细节”在做数据调研时我把真实货架照片翻了几百张发现商品标签的问题集中在四个方面小目标占比极高。一瓶550ml的矿泉水放在货架中层拍摄距离一到两米时整张图片里标签像素可能只有40×60占整图不到1%。标签密度大、相互粘连。同排商品紧密摆放两个相邻瓶子的标签几乎贴在一起检测框稍微大一点就会把两个标签框进同一个框。光照和反光干扰。透明塑料瓶上的标签被灯光照出高光热敏纸标签在暖光下偏黄金属罐装标签则可能整体反白。类别维度模糊。同样是某品牌的乌龙茶有“无糖”和“低糖”两个版本标签设计几乎一样只有一行小字不同。如果类别定义不清楚标注和训练都会乱套。1.3 一个关键决定把标签当作“目标”而不是“纹理”第一次设计模型时我差点走偏——想用一个模型同时完成“定位标签”和“识别标签上的文字”也就是端到端的检测识别。查了一圈资料和开源方案后发现这类端到端方案对数据量和算力要求极高而且文字长度不固定直接套用目标检测头并不灵活。最终我采用了“检测OCR”两级方案。这个决定的影响很大YOLO只需要负责“标签在哪里、大致是什么姿态”类别简单、正负样本分明模型压力小OCR可以单独训练、单独换模型后续想提升识别准确率不需要重新标注检测数据检测环节对算力的要求可以压得很低边缘设备也能跑。如果你也在做类似的“证件识别”“单据识别”“铭牌识别”我建议你先想清楚识别的主体是“区域”还是“文字序列”。绝大多数情况下拆成两段做比一个端到端模型省心得多。2. YOLO选型yolov5、yolov8还是更新的版本2.1 先别追新先看你的约束条件“基于YOLO系列”具体用哪个版本我当时的约束条件是推理设备是一块中端显卡支持半精度也有可能在Jetson类边缘盒子上部署标注数据量不多大约只有3000张图训练时间预算在一天以内。在这三个约束下我的选择逻辑是这样的大型模型如YOLO-X、YOLO-L参数多、精度上限高但小数据量下容易过拟合且边缘端推理帧率不理想优先排除nano模型最轻但标签这类小目标对特征表达能力要求高nano的浅层特征图语义信息不足实测漏检率偏高折中采用m或s规格配合输入分辨率提升性价比最高。我最后选了YOLOv5m版本开源社区成熟、文档多、ONNX导出方便作为主力实验同时也对比过YOLOv8s。YOLOv8的anchor-free检测头在密集目标上的召回率稍好一点但同等训练条件下反而因为标注框大小差异大收敛速度不如v5稳定。这倒不是说新版不好而是在“数据量不大、目标小且密集”的场景里v5的anchor机制配合手动聚类锚框反而更容易调出效果。2.2 小目标检测不是简单把图放大就行商品标签在整张图里占比很小这是模型精度最大的瓶颈。解决小目标问题一般有三条路提升输入分辨率。把训练和推理的输入尺寸从640×640提升到1280×1280小目标的AP收益非常明显但显存占用和推理耗时也会跟着涨。我在训练时用1280推理时根据设备性能在960~1280之间浮动。增加高分辨率检测头。YOLOv8的P2检测头、YOLOv5的P2层都是把特征图分辨率进一步提升专门增强小目标感受野。实际测试中加P2头之后瓶身小标签的召回率能提升4~6个百分点但训练显存需求增加约30%。图像切片推理。把大图切块分别检测再拼接结果。这个方法在极端小目标场景有效但标签识别属于“目标不算特别小”的范畴切片带来的后处理复杂度远大于收益我没有采用。如果你做过类似项目就会发现对小目标而言最大的提升往往不是换更强的骨干网络而是“把输入分辨率拉高”和“让标注框更准”。先把这两点做好比纠结换哪个版本收益大得多。2.3 锚框再聚类不要用官方默认参数YOLOv5自带的锚框是针对COCO数据集80类日常物体聚出来的直接用来检测长宽比悬殊的商品标签效果一般。标签的常见长宽比集中在2:1到5:1之间和COCO里“人、车、猫”那种接近1:1的目标差异很大。我在训练前用k-means对自建数据集的标注框重新聚类得到9组锚框重点增加了细长形锚框的数量。这一步不麻烦但对收敛速度的提升立竿见影同样的epoch数聚类锚框版本在验证集上的mAP比默认锚框高出了近2个点。提示重新聚类锚框时聚类的尺度要和实际训练尺寸保持一致。如果你训练时输入是1280×1280就用1280下的框尺寸聚类而不是用640下的。这个细节很多人会忽略导致聚类结果对不上实际训练分布。3. 数据准备3000张图是怎么攒出来、怎么标准的3.1 采集策略别只在“理想环境”下拍数据采集是最耗时、也最影响最终效果的环节。我当时的采集原则可以用一句话概括故意制造脏乱差再从中挑出可用的。具体做了三类采集货架正拍用手机在距离货架1~1.5米的位置水平拍摄覆盖不同层高、不同商品密度仓库手持拍模拟盘点员边走边拍画面有轻微的倾斜和抖动模糊补光/逆光拍用射灯或窗外自然光制造局部高光专门收集标签反光的失败样本。三步采集下来一共收集了约5000张原始图片经过人工筛选剔除了严重失焦、标签占比过小小于24×24像素、以及遮挡面积超过40%的样本最终保留3800张作为漏检训练集。3.2 标注规则一个框“该框什么”比想象中影响大我旁边有同事负责标注最开始标注质量参差有人把标签上方的促销贴纸也圈进去了有人只框了文字区域有人框了标签带背纸的完整区域。这些不一致直接导致模型训练时回归目标混乱。后来我把标注规则固定为框选区域是“标签的完整可视区域”包括底色、边框、文字不包含瓶身曲面明暗过渡如果标签被胶带覆盖框选到胶带边缘不扩展到胶带外如果同一商品有两个标签正面主标签侧面小标签作为两个独立目标框类别只设一个“商品标签”因为检测阶段不需要区分品名区分品名是OCR之后的事。这里强烈建议标注规范必须在项目启动第一天就写成文档并且前一百张图要由建模的人亲自标而不是直接甩给标注团队。标注问题造成的精度损失很多时候无法靠调参弥补回来。3.3 合成数据补强解决“标签透明”和“光照变化”真实标签中透明塑料瓶上的标签往往和瓶内液体颜色混在一起肉眼看着很清楚但模型容易把标签和背景当成一个整体。针对这类问题我做了两类合成增强背景替换合成把标签图片从原始背景中抠出贴到不同的货架、纸箱、手持场景背景图上同时随机叠加高斯模糊、泊松噪声、亮度扰动字体扰动合成对一些空标签模板用脚本随机生成“品名规格条码”组合的模拟标签再经过透视变换贴到商品图上这样模型见到的文本布局更多样。合成数据单看精度提升有限但配合真实数据混合训练后模型对“透明标签复杂背景”的鲁棒性确实变好了。需要注意合成比例不要超过30%否则模型会对合成纹理过拟合真实场景表现反而下降。3.4 增强策略里的一个“反向操作”大家都用Mosaic增强把四张图拼成一张训练它确实能提升模型泛化能力。但我在做小目标标签检测时发现Mosaic把图片缩小了标签目标也跟着变小如果叠加太多层随机缩放大量标签会退化成十几个像素的小点反而干扰训练。我的做法是训练集按照“原始图增强”和“Mosaic增强”1:1混合在Mosaic分支里限制最小缩放不低于0.6避免目标缩得太小关闭Mosaic的概率在前30个epoch设为0先让模型稳定拟合清晰的标签特征后期再打开增强。这个调整在验证集上直接带来了1.8%的mAP提升。如果你也做小目标检测建议优先检查Mosaic之后的标签像素分布而不是盲目堆增强。4. 模型训练配置、参数与调优记录4.1 训练环境的版本选择与坑训练机的显卡是GTX 309024GB显存系统为Ubuntu 20.04Python环境用的是3.8。YOLOv5官方代码依赖的PyTorch版本开发环境与生产环境之间有一个容易被忽视的坑训练时用的图像预处理库版本和推理时不一致会导致同样的图片推理结果不稳。举例来说我训练时用的OpenCV读取BGR图像而某个部署后端的图像加载组件默认读取RGB导致输入图像通道顺序错误模型准确率断崖式下跌。排查了很久才发现是推理脚本里少了一句cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。所以建议在项目第一天就把“图像读取→预处理→模型推理→后处理”的每个环节的格式写清楚尤其是通道顺序和归一化方式。这个问题不解决模型训练得再好也白搭。4.2 超参配置与训练命令最终采用的训练配置如下关键部分python train.py --data tag.yaml --weights yolov5m.pt \ --img 1280 --batch 16 --epochs 120 \ --hyp data/hyps/hyp.scratch-low.yaml \ --device 0 --workers 8几个关键参数的选择理由--img 1280输入分辨率直接决定小目标的特征像素数这点前面已经说过。代价是显存占用翻倍所以batch从32减到16--hyp hyp.scratch-low.yaml低数据增强的配置避免烂样本干扰早期训练。实际train时我额外把mosaic的开关按前面说的方式做了自定义--batch 16batch过大在小数据集上会加速过拟合batch过小则BN统计不稳定16是折中。学习率策略我使用cosine退火从0.01开始前5个epoch做warmup并在最后20个epoch设置--cos-lr让学习率平滑降到接近0。这个组合在多种检测任务上都很稳定省去很多手动调参时间。4.3 类别不均衡与验证集划分虽然检测阶段只有一个类别但“商品标签”本身大小差异极大大的纸箱标签可能有300×200像素小的瓶身标签只有30×60像素。模型天然会偏向学习大目标因为大目标的损失占大头。我的处理方式是给标注框面积小于32×32像素的样本提高采样权重。具体做法是拷贝多份小目标样本到训练列表中让同一epoch内小目标出现的次数翻倍。这个技巧比调损失函数权重更简单直观实测小目标AP提升了3个百分点。验证集划分也要特别注意同一商品的不同图片不能既出现在训练集又出现在验证集否则验证结果虚高。我当时是按“商品款式批次”分组的同一SKU的所有图片进同一侧避免数据泄漏。4.4 训练过程的监控与诊断训练不是跑完看个最终mAP就完了过程监控能提前暴露问题。我每天会固定看五个东西训练损失曲线和验证损失曲线是否同步下降验证损失在第80个epoch后开始回升就说明过拟合开始需要提前保存快照在验证集上抽样可视化检测框重点看漏检的小标签和误检的高光区域查看各类别按标注框面积区间划分的PR曲线确认小目标是否拖后腿记录F1曲线在不同置信度阈值下的变化为后续推理阈值提供参考输出confusion matrix看标签是否和“促销贴纸”“瓶盖”等相似物体混淆。这里多说一句mAP是整体指标但小目标漏检率才是生产环境真正关心的。我最终评估的时候没有死盯mAP而是把“标签召回率IoU0.5”作为主要考核标准因为漏检造成的成本损失远高于误检。5. 推理部署从权重文件到可用的服务5.1 导出与预处理细节训练好的模型要落地第一步是导出为ONNX格式再转成TensorRT引擎半精度FP16。这一步本身很常规但有两个经验值得分享导出时固定输入尺寸为1280×1280不要导出动态尺寸。动态尺寸虽然灵活但TensorRT在动态shape下会多次重新选kernel推理延迟抖动明显letterbox的填充颜色要和训练时保持一致。YOLOv5默认填充灰色(114,114,114)但你如果自定义了填充色导出和推理脚本都要改否则目标位置会偏移。推理时我统一用以下预处理逻辑import cv2 import numpy as np def preprocess(img, target_size1280): h, w img.shape[:2] scale target_size / max(h, w) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(img, (new_w, new_h), interpolationcv2.INTER_LINEAR) canvas np.full((target_size, target_size, 3), 114, dtypenp.uint8) offset_x (target_size - new_w) // 2 offset_y (target_size - new_h) // 2 canvas[offset_y:offset_y new_h, offset_x:offset_x new_w] resized return canvas, scale, offset_x, offset_y坐标映射回原图时别忘了减去offset再除以scale这个小错误会让所有框都偏到一边。5.2 NMS参数对密集标签的影响商品标签密集排列时NMS的IoU阈值很敏感。我最初用默认的iou_thr0.45结果一排十瓶饮料的标签被合并删除到只剩五六个框因为相邻两个标签的框交叠很大。后来把iou_thr降低到0.35并关闭了类别间NMS合并密集标签的保留情况改善明显。另一个问题是置信度阈值。商品标签的分类难度不高置信度普遍集中在0.85~0.95之间但也存在被遮挡、模糊导致置信度降到0.4的极端情况。我最终设了0.25的检测置信度并把低置信度框交给下游OCR二次确认。这样“漏检”和“误检”能得到平衡。5.3 小标签区域的透视矫正与OCR联动检测框输出的是带角度的四边形YOLOv5的旋转框需要额外接入一个角度回归头或者用最小外接矩形近似。我们做了个简化的方式用检测框的四个角点坐标配合固定的目标尺寸比如300×120像素计算透视变换矩阵把标签拉正。这一步非常关键。倾斜的标签直接送OCR精度很差矫正后识别准确率能从78%提升到96%。透视矫正的核心代码如下def rectify_label(src_pts, img): dst_pts np.array([[0, 0], [299, 0], [299, 119], [0, 119]], dtypenp.float32) M cv2.getPerspectiveTransform(src_pts.astype(np.float32), dst_pts) rectified cv2.warpPerspective(img, M, (300, 120)) return rectified这里的目标宽高比是根据聚类统计的“标签长宽比中位数”确定的。如果标签长宽比变化很大可以多设几个固定尺寸分别矫正后把多个OCR结果做投票融合能进一步压住个别错误识别。OCR部分我选用了一个对中文支持较好的开源OCR组件在矫正图上跑文本检测识别最后按关键词规则包括“净含量”“保质期”“生产日期”等字段解析出结构化字段。实际效果正常光照环境下单张图的检测矫正识别总耗时大约80msOCR识别准确率稳定在95%以上加上规则后处理最终输出记录的可用率约93%。5.4 边缘部署与加速的实测结论后来项目要求搬到Jetson边缘设备上跑我重新做了性能测试。以1280×1280输入、YOLOv5m模型、FP16精度为例设备推理耗时总流程耗时显存占用服务器 GPU22ms80ms3.1GB边缘设备 GPU85ms160ms2.2GB边缘设备上检测阶段占用仍然偏高主要瓶颈是小目标检测需要高分辨率输入。如果硬把输入降到640推理时间能缩短到35ms但小标签漏检率会暴涨将近一倍。所以部署这类小目标检测时“分辨率”这个参数必须格外谨慎不能为了帧率随意降。6. 实测效果与走弯路总结6.1 最终指标与验收口径最终系统在验证集上的指标如下标签检测mAP0.50.942标签召回率IoU0.5置信度阈值0.250.913平均检测误差框中心偏移占标签宽度的比例约4.2%OCR字段级准确率93.4%单张完整流程平均耗时服务端80ms。按甲方要求的验收口径每1000个标签中漏检数不超过25个误检数不超过40个。实测调优后达到漏检约22个、误检约31个算是在预算范围内通过了验收。6.2 走弯路后总结出的“三个最值”第一个最值“最容易被低估的环节是数据标注”。我最初对标注质量不以为意导致训练一天后发现验证集mAP只有0.88排查后发现是标注框边界不齐、部分标签包含背景过多。重新规范标注并回炉训练后mAP直接提升到0.924。这件事教会我一个道理检测任务的精度瓶颈很多时候不在模型结构而在“目标定义的一致性”。第二个最值“最值得做的一次改动是输入分辨率从640改到1280”。当时曾担心算力不够但实测发现1280下的mAP比640高6.3个百分点而推理耗时只增加了不到30%。对小型检测目标来说输入分辨率提升是投入产出比最高的操作。第三个最值“最后一公里往往是后处理”。检测模型输出一堆框看起来挺像样但如果不解决NMS误合并、透视矫正不到位、OCR文本解析规则不完善这三个问题系统在生产上根本无法用。检测性能只占整体体验的六成后处理才是决定上线体验的最后四成。6.3 现场适配时遇到的意外工况真实使用中有一类情况是测试集里没有覆盖的热敏标签在仓库高温环境下放久了会整体变成深褐色文字对比度极低。第一次现场测试时这类标签大量漏检后来在采集环节专门补拍了“陈旧标签”样本并在数据增强中加入了“整体亮度压低褐色偏色”的扰动分支才算把这一类补上。还有一类是高反光标签上叠加了透明胶带胶带边在图像里形成一道亮线模型偶尔会把这条亮线当成标签边缘导致检测框偏移。针对这个问题我在矫正后处理里加了一个“边缘平滑校验”检测框内边缘如果出现较长直线且与框边界平行会触发一次局部微调把框内收几个像素。虽然代码量不大但显著减少了后续OCR裁错区域的现象。6.4 这套方案后续还能怎么扩展做完这个项目之后我又琢磨了几条扩展路径分享给大家参考检测阶段输出标签的四个角点坐标进一步训练一个轻量的角点回归分支能直接替代“最小外接矩形”方案矫正精度更高把OCR解析出的品名、规格字段和已有商品库做相似度匹配可以实现“自动判断这瓶饮料是否与货架计划相符”这就从“识别”升级到了“盘点复核”如果场景变成监控视频流可以隔帧检测、结合跟踪算法减少重复识别降低算力消耗。我个人的体会是做这类“识别系统”的通用方法论是先用小数据集快速把链路跑通再回头补数据、调参数。一开始不要急着优化精度先确保每一环检测→矫正→OCR→解析都能动起来后面再逐环打磨整个项目的节奏会健康很多。希望这篇记录能帮到正在做类似项目的你。