YOLOv5垃圾识别检测系统实战：数据、训练与部署

我一直觉得，目标检测这类项目是接触深度学习算法最直观的入口。反馈链路短，模型效果好不好，画个框、算个置信度就摆在眼前，不用像做文本任务那样绕半天。这次完整做了一遍基于YOLOv5的垃圾识别检测系统，从数据集整理、模型训练、算法改进，到实时的摄像头检测系统原型，整套流程走下来踩了不少坑，也沉淀了一套可以复用的方法。如果你正打算做一个垃圾分类的AI实战项目，或者拿它当毕设、课程设计、算法验证的载体，这篇文章应该能帮你省掉大量试错时间。

这个项目能做的事很明确：给定一张垃圾图片或一段摄像头画面，模型能实时框出其中的垃圾目标，并识别出具体的类别，比如塑料瓶、易拉罐、纸箱、果皮、电池等。基于这个核心能力，可以往两个方向扩展：一是做算法研究，在YOLOv5基础上改进网络结构、做对比实验，验证某个改进点的有效性；二是做系统原型，把训练好的模型封装成实时检测服务，接摄像头或者网页上传接口，形成一个能演示、能答辩、能继续迭代的完整系统。适合的人群也很清晰：刚入门目标检测的同学，想系统走一遍训练到部署全流程的工程师，以及需要快速搭建算法验证Demo的研究生。

1. 项目整体设计与系统架构思路

1.1 核心需求与目标定位

在动手之前，我先把需求拆成了四块。第一是数据，垃圾检测没有公开的大规模统一基准，很多数据集类别口径不一致，标注格式也乱七八糟，所以必须自己动手整理一份可用的垃圾分类数据集。第二是模型，要有一个能在本地显卡上跑得动、精度和速度相对均衡的基线模型，YOLOv5是合理选择。第三是算法验证，光有一个能跑的模型还不够，项目里需要体现"改进"的过程，也就是做消融实验和模型对比，说明某个改动确实有效。第四是系统原型，要把模型从训练环境搬到真实场景，通过摄像头实时推理，形成完整的闭环。

这四块对应着完全不同的技术栈和评估方式。数据部分看的是标注质量和类别分布，模型部分看的是mAP和参数量，算法改进看的是对比实验的严谨性，系统原型看的是端到端的延迟和稳定性。很多人做这类项目只盯着训练出来的模型有多准，忽略了整个链路的完整性，导致最后答辩或者展示的时候只能说"我训了一个模型，精度挺高"，但经不住深挖。我的建议是，从一开始就把四条线并行推进，哪怕每条线做的深度浅一点，整体的项目完成度也会高很多。

1.2 为什么选YOLOv5而不是其他模型

这个项目选YOLOv5，不是因为它是技术上的最优解，而是因为它是最适合做快速迭代和工程落地的选择。第一，YOLOv5的代码结构非常工程化，训练、验证、导出、推理全部封装好了，改配置、换数据集、加模块都方便，对于算法验证和系统开发都是优势。第二，社区活跃度高，遇到问题基本能查到解决方案，这对一个既要写算法又要写系统的项目来说很关键。第三，推理速度足够快，在CPU上勉强可跑，在GPU上能做到实时，后面接摄像头做实时检测不会成为瓶颈。

有人会问为什么不直接用YOLOv8或者RT-DETR。YOLOv8在精度上确实有提升，但它的模块化程度更高，反而对想做底层算法改动的项目不太友好，改起来要动的地方更多。RT-DETR是端到端架构，省掉了NMS，但训练资源要求更高，部署链路也更复杂。对一个以"算法改进+系统原型"为目标的项目来说，YOLOv5就像一把用顺手的螺丝刀，旋钮清晰、反馈直接、容错率高。

1.3 系统模块划分与数据流

整个系统我分成了五个模块：数据模块、训练模块、模型改进模块、推理服务模块、前端展示模块。数据模块负责把采集到的图片转成YOLO格式，并按比例划分训练集、验证集和测试集。训练模块负责加载配置、启动训练、输出权重文件和评估指标。模型改进模块是训练模块的扩展，通过修改模型配置文件或代码结构，插入不同的改进组件，跑消融实验。推理服务模块负责加载训练好的权重，封装成可供调用的检测接口。前端展示模块在浏览器或桌面窗口中展示实时检测结果。

数据流的走向是这样的：原始图片 → 标注工具生成坐标文件 → 脚本统一转换成YOLO txt格式 → 按类别分层划分数据集 → YOLOv5训练 → 验证集评估 → 导出最优权重 → 推理服务加载 → 摄像头帧输入 → 检测框叠加 → 前端展示。这个流程里每一步都可能出问题，尤其是数据和格式转换阶段，我在后面的章节会详细拆解。

2. 垃圾数据集的构建与预处理

2.1 类别体系设计

垃圾分类检测的类别体系设计是整个项目的根基，也是最容易被忽略的部分。很多公开的垃圾分类数据集只有六类或者十类，比如可回收、厨余、有害、其他这种粗粒度的划分，但这对目标检测模型来说太不友好了。检测模型学的是"物体的视觉形态"，"可回收垃圾"这个标签对应的物体形态千差万别，模型很难收敛到一个稳定的特征。所以我的做法是往下拆，拆到具体的物品类别级别，再在标签层面映射到回收类别。

我最终设计了15个类别：塑料瓶、易拉罐、纸箱、纸杯、玻璃瓶、果皮、剩饭、电池、灯泡、旧衣服、鞋子、塑料袋、泡沫盒、口罩、烟头。这15个类别覆盖了最常见的垃圾场景，每个类别都有比较稳定的视觉特征。塑料瓶和易拉罐是圆形或圆柱形的反光物体，纸箱是方正的纸板纹理，果皮和剩饭是形状不规则的有机质，电池和灯泡则是小尺寸的高反光物体。类别之间有一定的相似度，比如纸杯和纸箱都是纸质的，灯泡和玻璃瓶都是透光的，这些恰恰是后面检测难点出现的原因，也让模型对比实验更有说服力。

2.2 数据收集与标注格式统一

数据来源我用了三个渠道：自采数据、公开数据集、合成数据。自采数据是在校园和社区场景用手机拍的，大概500多张，主要覆盖塑料瓶、纸箱、易拉罐这些常见类别，好处是场景真实、角度多样。公开数据集我从开源社区找了几份垃圾分类数据集，这些数据集中某些类别的图片质量参差不齐，有的甚至带水印，需要逐张筛选。合成数据是把透明背景的物体贴到不同背景上做出来的，用来补充小样本类别，比如电池和灯泡。

在标注格式上，我踩了一个非常典型的坑。有些开源数据集用的是VOC XML格式，有些是COCO JSON格式，还有的直接用labelImg标注生成的YOLO txt格式。一开始我想图省事，直接混合使用，结果训练的时候发现数据加载报错不断，坐标归一化方式对不上。后来我写了一个统一转换脚本，把所有格式都转成YOLO txt格式，格式是"class_id x_center y_center width height"，所有值都归一化到0到1之间。这个脚本很值得写，因为后面每加一批新数据都要走一遍这个流程。

2.3 数据清洗与增强策略

数据清洗这件事，我一开始觉得是浪费时间，直到第一次训练出来的模型在验证集上mAP只有0.5不到，才发现问题出在数据上。清洗主要做三件事：第一是删掉标注明显错误的图片，比如框完全偏了的、类别标错的；第二是剔除分辨率过低或者严重模糊的图片，这种图对训练没有正贡献；第三是检查类别分布，有些类别只有几十张，必须做数量补齐，否则模型会直接忽略这些类别。

数据增强的策略直接决定模型能否在真实场景里扛住。YOLOv5自带的增强策略已经很完善，包括Mosaic、MixUp、HSV色域变换、随机平移翻转、尺度变化等。其中Mosaic增强是YOLOv5的核心特性，它把四张图拼接在一起训练，相当于一个小型的多图融合，能显著提升模型对遮挡和小目标的鲁棒性。我额外做的一个工作是针对某些小尺寸类别，比如电池，单独用复制粘贴的增强方式扩充样本，把电池目标粘贴到自然背景里，同时生成对应的标注框，这样能在不破坏背景真实性的前提下补充小目标样本。

2.4 数据集划分策略

划分数据集不能直接用随机划分，因为不同来源的数据会有明显的分布差异。自采数据大都是自然光照，公开数据集不少是室内灯光，如果随机混在一起划分，验证集里可能会出现跟训练集来自同一批来源的图片，导致评估指标虚高。我采取的做法是分层划分：先按数据来源分成三个桶，再从每个桶里按8:1:1划分训练集、验证集、测试集，最后把三个桶的子集合并。这样能尽量保证验证集和测试集分布跟训练集不太一致，模拟真实场景的难度。

分层划分后的结果大约是训练集1400张，验证集180张，测试集170张。对目标检测来说这个数据量偏小，但配合数据增强和预训练权重，跑出来的效果已经足够支撑系统演示和算法对比实验了。

3. 模型训练、调参与评估

3.1 训练环境与依赖版本

训练环境这块，版本匹配是最大的坑。我第一套环境是PyTorch 1.12配合CUDA 11.6，后来因为显存不足想换一个版本，结果把CUDA也升级了，配套的cuDNN对不齐，直接导致训练时出现诡异的CUDA error: device-side assert triggered。这个错误非常磨人，它不一定是指令有问题，很可能是张量索引越界，而索引越界的根本原因是类别ID超过了模型配置里的类别数。排查了很久才发现是数据集的类别编号和模型配置文件里的nc参数不一致。

我的建议是直接用官方requirements.txt里的版本，不要自己乱组合。我最终用的是Ubuntu 20.04、Python 3.8、PyTorch 1.12.1、CUDA 11.6、GPU为RTX 3060 12G显存。12G显存在这个项目里刚好够用，batch_size可以开到16，如果显存只有8G，建议batch_size降到8，同时把图片尺寸从640降到512。

3.2 关键超参数选择与训练策略

超参数设置直接决定训练效率和最终精度，这里我把选过的参数和理由一并列出来：

• 输入尺寸：640x640，这是YOLOv5的默认推荐值，兼顾精度和速度。降到512能提速但mAP会掉2到3个点，升到768对小目标有改善但显存压力大，我用512跑过一次，速度确实快但电池的漏检变多了。
• batch_size：16，配合12G显存刚好。梯度累积是个替代方案，但会拖慢训练节奏，不如直接调小batch。
• epochs：200。前100个epoch模型从零快速收敛，后面50个epoch主要靠余弦退火把学习率压下去做精细调整。实测150个epoch之后的提升非常缓慢，但最后20个epoch的波动反而可能掩盖最优模型，所以我开启了best.pt保存逻辑，只保留验证集上mAP最优的权重。
• 学习率：初始0.01，搭配SGD优化器和warmup。前3个epoch做warmup，学习率从0.001线性升到0.01，避免一上来就大步长把预训练权重冲坏。如果换成AdamW，初始学习率要降到0.001左右，否则loss很容易震荡。

这些参数不是一次调出来的。第一版用的是默认配置，mAP50大概0.72；第二版把学习率降到0.005、增加warmup轮数，mAP50升到了0.78；第三版加了类别权重，把样本少的类别的损失权重提高1.5倍，mAP50到了0.81。可见这种小数据集上，调参的收益比改动网络结构来得更直接。

3.3 训练过程监控与日志分析

训练过程中，不要只看loss曲线，还要同时盯着验证集的mAP指标。loss下降正常只能说明模型在训练集上拟合，mAP才是泛化能力的体现。我常用的监控指标有四个：box_loss、obj_loss、cls_loss、mAP50。box_loss管的是边界框回归质量，obj_loss管的是目标存在置信度，cls_loss管的是类别分类准确率，mAP50则直接反映检测精度。

训练过程中我遇到的一个明显问题是，box_loss在80个epoch附近出现了小幅反弹，当时第一反应是学习率没调好，但仔细看训练日志，发现是因为这个阶段数据增强的强度太大，Mosaic增强在高epoch阶段反而干扰了模型对精确定位的学习。YOLOv5在接近训练结束时会自动关闭Mosaic增强，如果你改了相关配置导致这个机制失效，就很容易出现这种反弹。我在训练后期手动降低了Mosaic的概率，让模型在最后阶段精修定位能力，效果很好。

3.4 指标评估与模型选型

评估模型不能只看一个指标。我分别计算了mAP50、mAP50:95、Precision、Recall、模型参数量和单帧推理时间。mAP50是IoU阈值0.5下的均值平均精度，对定位精度不太敏感，适合看整体检测能力；mAP50:95是多个IoU阈值的平均，更严格，能反映边界框的精细程度；Precision和Recall这对指标需要一起看，Precision高说明误检少，Recall高说明漏检少。

我的基线模型YOLOv5s训练200轮后，mAP50约0.81，mAP50:95约0.53。这个结果在小数据集上算正常水平。用YOLOv5m做对比，mAP50提升了大概2个点，但推理时间几乎翻倍，从14ms涨到25ms左右，参数量也翻了好几倍。考虑到后面要做实时摄像头检测，我最终选了YOLOv5s作为系统原型的基座。

4. 算法改进与模型对比实验

4.1 主攻的三个改进方向

算法改进是这个项目里最体现技术含量的部分，也是最容易写出水的东西。我给自己定的原则是：每个改进点都要有明确动机，并且用消融实验验证有效性，而不是堆砌一堆新模块。

我选了三个方向。第一是注意力机制，在Backbone的C3模块后面插入轻量化的通道注意力模块，目的是让模型更关注有判别力的特征通道，比如塑料瓶的高反光区域和纸箱的纹理边缘。第二是特征融合网络，把原本的PANet的普通卷积替换成可学习的加权融合方式，改善不同尺度特征层的融合效率。第三是损失函数，把CIoU Loss换成SIoU Loss，SIoU在回归损失中额外考虑了预测框和真实框之间的角度差异，理论上能让边框回归更精准。

这三个方向分别对应特征提取、特征融合、损失优化三个环节，如果都能有一点性能提升，它们叠加起来就是一条完整的改进链路。

4.2 消融实验设计方法

消融实验最怕的是配置不统一。我的做法是：固定数据集、固定训练超参数、固定随机种子，只改变模型结构这一个变量。刚开始我不小心动了训练参数，导致跑出来的对比结果完全没法说明问题，后来重新把基线模型和新模型的所有配置对齐，连数据增强的概率也保持一致，才得到可信的数据。

实验分组是这样设置的：基线组（YOLOv5s）、基线+注意力机制、基线+改进特征融合、基线+SIoU Loss、全部改进叠加。每组都训练200个epoch，评估同一套验证集，记录所有指标。这样跑下来，每组的差异就能归因到对应的结构改动上。

4.3 对比实验结果与关键发现

实验结果的趋势符合预期。单独加注意力机制，mAP50从0.81提升到0.835；单独改特征融合，提升不太明显，mAP50大约0.823；单独换SIoU Loss，mAP50略降到0.818，但mAP50:95有小幅上涨，说明回归更精细了；全部改进叠加后，mAP50到了0.85，mAP50:95从0.53提升到0.57。

值得说明的是，所有改进叠加不一定就是最优解。我试过在叠加了注意力机制之后再加上一个额外的检测头，结果mAP反而掉了1个点。原因是小数据集上增加模型复杂度容易导致过拟合，参数变多但训练数据没变多，泛化自然变差。这个实验结果反而成了项目里一个有价值的结论，在答辩或者展示的时候可以拿出来讲。

模型对比表我整理了一份，方便直观对比：

4.4 改进方向的取舍思路

做完对比实验后，我给自己的结论是：这个项目里收益最高的是注意力机制，性价比也最高，参数量只增加0.2M，推理时间几乎没变；特征融合改进属于锦上添花，收益不稳定；SIoU Loss虽然对mAP50:95有帮助，但在mAP50上略降，如果项目更看重整体精度的直观展示，保留不加也行。

但话说回来，如果你拿这个项目做算法研究或者毕设，建议不要直接照搬我的结论。因为数据集不同、基座模型不同，改进效果的排名很可能不一样。关键是掌握这套实验方法：结构化改动、控制变量、量化评估、解释验证结果。

5. 实时检测系统原型开发

5.1 推理方案选择

模型训练完之后，要接入系统原型。这一步的核心是把PyTorch的训练代码裁剪成轻量化的推理代码，不需要梯度计算、不需要数据增强，只需要前向推理和结果后处理。

我选择了PyTorch原生的推理方案，没有转TensorRT，因为机型是本地显卡，且项目更偏向算法验证，TensorRT加速是锦上添花而非必需。推理代码里有一个关键点：要把模型切到eval模式，并用torch.no_grad()包裹推理过程，否则显存和速度都会出现明显问题。我见过身边有人忘了切eval模式，结果每次推理都带着dropout和动态图计算，速度慢得离谱。

推理的输入输出转换也很容易出错。模型输入是归一化到0到1的RGB图像，形状是[N, 3, 640, 640]，而OpenCV读出来的是BGR通道顺序的HWC图像。我写了一个辅助函数，统一处理：BGR转RGB、resize到640、归一化、转Tensor、加batch维度，推理后再把输出坐标映射回原图尺寸。这个辅助函数是整个推理服务的基石，所有摄像头帧都要先过它。

5.2 摄像头实时检测的实现

摄像头实时检测，本质上是一个循环：读取帧、预处理、推理、后处理、画框显示。但这里有一个性能问题：如果直接用单线程串行处理，每帧都要等推理完成才能读下一帧，导致画面掉帧严重。我的解决方案是双线程+队列：一个线程专门从摄像头读帧并丢进队列，另一个线程从队列取帧做推理，推理结果再送回主线程显示。

这个方案实测下来，在RTX 3060上跑YOLOv5s，摄像头端的处理帧率稳定在25到30FPS，基本能满足实时演示。如果你的机器比较弱，可以在队列里做跳帧策略，设定间隔帧数，比如每两帧推理一次，也能换来流畅度的明显提升。

摄像头选择也有讲究，普通USB摄像头容易在弱光下丢帧，推荐挑支持手动曝光调节的型号。我在宿舍测试时，光线变化很频繁，如果不手动固定曝光值，画面亮度忽明忽暗，模型的检测效果也跟着波动，最后是用OpenCV的CAP_PROP_AUTO_EXPOSURE参数强制关闭自动曝光才稳定下来。

5.3 前端展示与交互设计

前端展示我做了两个版本：一个是基于OpenCV的桌面窗口，另一个是基于Flask的网页服务。桌面窗口开发快，适合本地调试；网页服务的交互更强，可以把检测结果以HTTP接口的形式暴露出来，方便打包演示。

Flask这边，我建了一个简单的服务：/detect接口接收图片上传，调用推理模块，返回标注后的图片和检测结果JSON列表。JSON里包含每个目标的类别、置信度、边界框坐标，前端拿到之后可以直接渲染。页面我做了极简版，一个上传框、一个结果图、一个实时统计区，统计区显示各类别检测数量和置信度平均值。这套原型对系统的演示和测试价值很大，也方便后续扩展成真正的智能垃圾分拣设备的上位机软件。

5.4 实际部署中的性能优化

部署阶段最常遇到的问题就是"训练好好的，一接摄像头就卡"。原因是摄像头推流、画面显示、推理、日志输出都在同一条链路里挤占CPU资源，而且用了高分辨率图片。我做了几个针对性的优化：

• 摄像头端只保留画面的ROI区域，比如把整个画面裁剪到640x640再送入模型，避免把无关背景也算进推理输入里。
• 推理输出类别里有一些置信度极低的框，直接把conf_thres从默认的0.25提高到0.35，减少后处理时间和误检框数。
• 平时必须用GPU推理，但为了兼容没有GPU的部署环境，我也验证过CPU推理，FP16半精度在CPU上收益不大，还是用FP32更稳。

实测定格下来，GPU推理单帧约14ms，CPU推理约400ms，两者的差距提醒我，如果后续要做嵌入式设备部署，量化加速是不能省的一步。

6. 常见问题与排查技巧实录

6.1 训练阶段的典型问题与解决

Loss不降反升。这个现象遇到过两次，一次是学习率设置太高，一次是训练集里出现了标注错乱。排查思路是：先用小的测试集跑几个epoch，如果正常，说明是数据或配置问题；如果还是发散，就是代码问题。标注错乱更隐蔽，我通过可视化训练样本才发现的，每50个epoch导出一次预测结果覆盖在原始图上，一张一张看，很快就能发现。

训练时显存溢出。在RTX 3060上，batch_size从16调到8后，问题基本解决。如果还溢出，就把图片尺寸降到512，并关闭MixUp增强，这个操作对显存影响最大。

验证集mAP很高但照片测试很差。这是典型的数据泄露问题。原因是自采数据和公开数据混合时，划分没有做分层，导致验证集里混入了跟训练集高度相似的图片。写了分层划分脚本之后重新训练，指标虽然略降，但真实场景的表现反而更好了。

6.2 推理部署阶段的典型问题

模型加载报错找不到文件。权重文件路径问题，看起来毫无技术含量，却能卡半小时。建议在推理代码里用绝对路径拼接，不要用相对路径，并且把权重文件和推理脚本放在同一目录下，减少路径匹配的麻烦。

摄像头画面有延迟。OpenCV的VideoCapture默认读缓存帧，导致画面延迟感很明显。我用的是清空缓存的办法：每帧读取前先循环丢弃缓冲区的旧帧，只保留最新帧送入模型。这个技巧在USB摄像头上非常有效。

NMS阈值和置信度阈值互相影响。调的置信度阈值太低会冒出大量低分框，调NMS阈值太高又会在密集场景下输出重叠框。我实测的一个合理组合是conf_thres=0.3、iou_thres=0.45，对塑料瓶和易拉罐这类密集小物体效果最稳。

6.3 几类易混淆垃圾的检测心得

项目里最容易混淆的是玻璃瓶和塑料瓶，因为都是透明或半透明、高反光的瓶状物体。我的处理方法是：在数据增强阶段提高HSV色域变换中的饱和度扰动范围，让模型不要过度依赖颜色特征，而是去学瓶口和瓶底的轮廓特征。另一个改进是在标注时对玻璃瓶的边界框多预留几个像素，把瓶身的透光边缘也包含进去，这样模型学到的特征更完整。

纸杯和纸箱的混淆则是纹理问题，模型容易把有一定曲面的纸杯误判成小型纸箱。针对这个，我在数据里补了十几张俯视角度的纸杯图片，让模型看到杯子常见的俯视形态，解决了大部分误检。

6.4 一些可以省时间的操作经验

整个项目里，最浪费时间的是数据的格式转换和类别映射。如果一开始就统一好类别ID和标注格式，后续的每一轮训练迭代都能省几十分钟。我强烈建议把数据清理脚本、格式转换脚本、类别映射文件作为独立模块保存好，它们比模型权重更值得当作项目资产保留。

另外，训练不要每次都从头跑。YOLOv5官方提供的预训练权重是很好的起点，实测起来，用预训练权重微调比从头训练能少跑大概60个epoch，mAP还能高一两个点。等基线稳定之后，做改进实验时，可以从这个微调好的权重继续叠加上去。

最后再分享一个小技巧：训练完成之后，一定要导出一份推理脚本的独立文件夹，里面只放权重、类别文件、推理代码和README，不要跟训练代码混在一起。这样后面做演示或者给别人复现时，不会因为环境混乱而手忙脚乱。这套流程走完一遍，你会发现做AI项目的核心能力不只是调模型，更是管理好数据、实验和代码这三条线，让每一步的产出都清晰可控。