水果好坏检测实战：YOLOv5与YOLOv8模型训练到部署全攻略

做水果分拣这事，真不是把模型训练出来就完事。我一开始也以为，拿到一套标注好的水果好坏数据集，再配合现成的YOLOv5/YOLOv8权重，直接跑推理就能给产线交差。实际走了一遍才发现，数据格式、模型选型、训练参数、部署环境，每一步都有不少隐性门槛。这篇文章就把我这次完整跑通"水果好坏检测"的记录整理出来，覆盖数据集结构、YOLOv5与YOLOv8的取舍、训练命令与参数、结果指标分析，以及部署到真实分拣场景时最容易踩的坑。不管你是刚接触目标检测，还是已经跑过别的检测项目，这套流程都能直接参考。

1. 先摸底：水果好坏数据集的结构与标注规矩

拿到手的数据集不是简单一堆图片，里面通常已经按YOLO训练的标准格式组织好了。如果不先搞清楚目录结构和标签含义，后面训练报错、指标异常都很难排查。

1.1 目录与文件组织方式

常见的数据集目录大致长这样：

fruit_dataset/ ├── data.yaml ├── images/ │ ├── train/ │ │ ├── 001.jpg │ │ ├── 002.jpg │ │ └── ... │ └── val/ │ ├── 101.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── 001.txt │ │ ├── 002.txt │ │ └── ... │ └── val/ │ ├── 101.txt │ └── ... └── weights/ ├── yolov5s_best.pt └── yolov8s_best.pt

这可能是从某个实际项目里整理出来的数据，也可能是从公开渠道收集后重新标注的。重要的是images和labels两套目录必须一一对应，而且文件名一致。我曾经遇到过图片是.jpg、标签是.txt但前缀编号对不上，训练时大量图片被跳过，最后mAP直接崩掉。

如果数据集里已经给了weights/目录，说明提供者把YOLOv5和YOLOv8两套训练好的权重都放进来了。这种"好事"背后有个隐藏价值：我可以直接拿这两份权重做对比测试，不用自己从零开始训练，能省大量时间。

1.2 标签文件到底是什么内容

YOLO格式的标签是纯文本，每一行代表一个目标框，结构是：

class_id x_center y_center width height

其中坐标都是归一化到0到1之间的小数，不是像素绝对值。比如一个坏苹果的标签可能长这样：

1 0.4321 0.5678 0.2134 0.2876

含义是类别id为1（假设0是好果，1是坏果），目标框中心点位于图片横向43.21%、纵向56.78%的位置，框宽占图片21.34%，高占28.76%。

这里要注意，很多新手会把分类任务的标签格式和检测任务的标签格式搞混。分类任务只要一个类别数字，检测任务却必须包含边界框的四个数值。我自己第一次写脚本检查数据时，就发现有几张坏果图片的txt文件里只有一行"1"，后面没有坐标，这种错误数据会让训练过程报"标签数据长度不对"的错误，严重时直接影响loss计算。

1.3 样本数量与类别平衡

正常数据集里，train和val的比例大致是8:2或9:1。水果好坏检测这种场景有个典型问题：坏果样本往往偏少。毕竟在实际分拣中，好果是大多数，坏果属于"少数派"。如果数据集的坏果比例不足，模型很容易出现"偏好预测好果"的情况。

我建议拿到数据后第一件事就是做一个快速统计：

• 统计train和val各自的图片数量；
• 统计每张图片里好果框和坏果框的数量；
• 计算坏果框占总框数的比例。

如果坏果框占比低于20%，训练时最好给坏果类别提高loss权重，或者对坏果图片做复制粘贴增强。我当时统计完发现比例大约是一半一半，说明提供者还是做过平衡的，省了很多事。

1.4 类别名称定义容易忽略

data.yaml里的names字段要和标签文件的class_id顺序严格对应。典型配置是：

names: 0: good_fruit 1: bad_fruit

如果提供方用的是"fresh"和"rotten"，而我训练时写的是"good"和"bad"，虽然类别数量没变，但可视化时框上的名字会对不上，更重要的是如果数据集内部标签顺序不一样，比如0代表坏果、1代表好果，那模型训练出来的语义就完全反了。所以跑训练前一定要先抽查几张图片的标注可视化，确认类别ID和实际外观一致。

2. 为什么同时给了v5和v8两代模型：选型不是越新越好

YOLOv5和YOLOv8都是目标检测领域应用非常广泛的模型系列，但它们的结构、训练策略和部署生态有很大差别。数据集里同时附上两套权重，与其说是提供方顺手，不如说是在提醒使用者：要根据自己的硬件和业务场景做选择。

2.1 YOLOv5和YOLOv8的核心区别

从结构上看，YOLOv5采用的还是anchor-based的思路，通过预设一组不同大小和长宽比的anchor框来回归目标位置。YOLOv8改成了anchor-free结构，不再依赖手动设计的anchor，而是直接预测目标中心点和尺寸，同时把分类头和回归头解耦，收敛更稳定。

在训练流程上，YOLOv8的官方仓库做得更统一，命令更简洁，各种预训练权重也可以直接用一条命令下载；YOLOv5虽然官方早已停止大的功能更新，但它的社区积累非常厚，很多嵌入式设备、老版本推理框架、教程都围绕它展开。

我给一个比较实用的对比表：

对于水果好坏检测来说，两类模型都能用。坏果框和好果框的形状差异并不大，都是近似椭圆，所以不需要特别复杂的anchor设计。

2.2 从部署条件反推该用哪个

选型最重要的原则是从部署环境倒推。如果你的设备是一台较老的工控机，上面的推理引擎只支持某种固定版本的ONNX算子，那YOLOv5可能更稳妥，因为它的算子相对传统，兼容面广。如果你打算用新版本的官方推理SDK，或者想省去一堆配置文件，YOLOv8会更舒服。

另外还要看实时性要求。水果分拣传送带速度一旦快起来，单帧推理时间必须压到几十毫秒以内。此时可以先用YOLOv8n或者YOLOv5s这种小模型做基准测试，看哪个在目标设备上延迟更低。不要一上来就用大模型，比如YOLOv8x，即使精度高，部署跑不动也是白搭。

2.3 我的选择方案

我这次的做法是先用数据集自带的YOLOv8权重在验证集上跑一轮，确认数据格式正确、评测脚本没问题；然后再用YOLOv5权重做一次对比，重点看精度差异和导出ONNX后是否方便。实测下来，在同样640输入尺寸、同样推理设备上，两者mAP50差距在1个点左右，而YOLOv5导出的模型在某些老推理库上兼容性更好。

如果你的项目周期紧，建议直接采用这种"双模型对比"策略：用现成权重做验证，再选择团队更熟悉的一方继续训练调优。如果是从零开始，我更推荐先用YOLOv8快速跑通，再根据硬件决定是否回退到YOLOv5。别迷信新版一定全面优于旧版，实际业务中部署约束往往比模型结构更重要。

3. 数据准备与训练：从yaml到命令行

拿到数据集和预训练权重后，下一步就是真正训练。这里我把YOLOv5和YOLOv8的训练配置、命令行和关键参数都拆开讲，免得跑的时候到处找参数说明。

3.1 数据集yaml配置写法

YOLOv5和YOLOv8对data.yaml的解析基本兼容，但有些字段的路径规则不一样。推荐写成绝对路径，防止相对路径在不同目录下失效。

# data.yaml path: /home/your_name/fruit_dataset train: images/train val: images/val nc: 2 names: 0: good_fruit 1: bad_fruit

注意path字段在YOLOv8里是必须的，YOLOv5可以没有但建议保留。train和val可以直接写相对于path的路径，也可以写完整的绝对路径。

如果数据集里存在没有标签的图片，训练时会被跳过，并输出警告。数量少没关系，但如果图片本身是坏果却漏标了，这些图片就会变成"负样本"，误导模型把那些坏果也当成背景。我一般会用一个脚本统计每张图片的标签数量，若标签为空的图片超过总图片数的5%，就要回头检查标注质量。

3.2 训练命令与预训练权重加载

YOLOv8训练命令很简洁：

yolo detect train model=yolov8n.pt data=data.yaml epochs=100 imgsz=640 batch=16 device=0

如果显存不够，可以把batch调到8，或者把imgsz降到512，但检测小目标的能力会下降。YOLOv5则是：

python train.py --data data.yaml --weights yolov5s.pt --epochs 100 --batch-size 16 --img 640 --device 0

使用预训练权重是关键。不要用随机初始化的权重从零训练，尤其是数据量不大时，预训练模型已经学好了通用的边缘、纹理、形状特征，迁移到水果检测上收敛又快又稳。数据集自带的v5/v8权重也是基于预训练权重继续训练出来的，所以直接推理没问题，继续训练也可以。

3.3 超参数：epochs、batch、学习率与mosaic

水果好坏检测的目标不算特别难，难点在于坏果外观多样。训练轮数不要盲目追求多，100轮左右通常足够。如果发现验证集mAP在30轮后不再上升，反而过拟合，可以提前早停。

batch size越大，梯度越稳定，但显存有限时可能需要降低。一般原则是尽量用能塞进显存的最大batch，同时在训练时开启混合精度，AMP能省不少显存。YOLOv8默认开启混合精度，YOLOv5需要指定--amp。

学习率方面，YOLOv5和YOLOv8都支持cosine学习率调度。初始学习率一般不用动，但如果发现loss震荡严重，可以把lr0从0.01降低到0.005。

mosaic增强会在训练中把四张图片拼成一张，提升模型对遮挡、小目标的鲁棒性，但也会让模型在最后阶段适应不了真实图片的分布。YOLOv8提供了close_mosaic参数，建议在最后10个epoch关掉mosaic，让模型在接近真实分布的数据上做微调。

3.4 针对坏果多样性的数据增强思路

坏果形态远比好果复杂：有磕碰伤、有软腐、有霉斑、有果柄干枯。如果数据集中每个类的样本外观相对固定，模型就容易过拟合到特定颜色和纹理。

我在训练时除默认增强外，还额外加了颜色抖动和模糊增强。水果的新鲜程度往往和颜色、光泽有关，所以轻微改变亮度、饱和度和色相，能让模型学到更本质的"不新鲜"信号，而不是死记某些特定色块。对于运动模糊，模拟传送带上成像模糊的情况也很有用。

这里有个经验之谈：不要对图像做过度旋转和翻转。水果虽然有朝向，但好果和坏果在旋转后语义不变，翻转没问题；但过度的透视扭曲会让边界框形状失真，反而干扰训练。

4. 训练结果怎么看：指标解读与常见翻车现场

训练结束后，终端会输出一堆指标，很多人只看mAP就收工。但对水果好坏检测这种二分类任务，混淆矩阵和PR曲线才是真正能指导业务决策的东西。

4.1 训练曲线和验证指标的判断方法

训练完成后，在runs/detect/train/目录下会生成results.png，包含训练loss、验证loss、mAP等曲线。我一般重点看三个地方：

• train/box_loss和val/box_loss：两者都下降且差距不大，说明模型没有明显过拟合；
• mAP50：坏果和好果的类别平均精度，这个指标比mAP50-95直观，因为水果检测对框的精确度要求没那么苛刻；
• mAP50-95：更严格的指标，叠加了不同IOU阈值，数值会偏低，但更反映定位精度。

如果loss还在下降但mAP已经停滞，说明模型还在学习某些对检测没帮助的细节，可以提前停止。如果val loss在几十轮后反弹，而train loss一直下降，那就是过拟合了，应该增加数据增强、增加数据量或者减少模型复杂度。

4.2 混淆矩阵：好果坏果误判的最直观证据

二分类检测里，混淆矩阵能直接看出两类目标的误判情况。最典型的翻车有两种：

第一种是坏果漏检。模型把带有轻微腐烂、表面出现小面积褐变的水果判成了好果。原因通常是坏果样本里霉斑和伤疤面积太小，或者标注框把整个水果包含进去后，腐烂区域特征被稀释。解决办法是把坏果种类细分，比如"碰伤"、"霉变"、"干枯"分开标注，再合并成bad类训练；或者裁剪坏果局部区域作为额外训练数据。

第二种是好果误报为坏果。比较常见于光影复杂的场景，比如苹果上的高光反光、树枝阴影、标签贴纸，都可能被模型当成缺陷。这个问题的根源是训练数据里背景和光照多样性不足，单靠调阈值很难彻底解决。可以在训练数据里故意加入大量贴着标签、带反光的好果图片，并标注为好果，让模型学会忽略这些干扰。

4.3 对比验证集自带权重

我拿到数据集后直接跑了两次验证命令：

yolo detect val model=weights/yolov8s_best.pt data=data.yaml

和

python val.py --data data.yaml --weights weights/yolov5s_best.pt

这样做的好处是：如果我自己训练的模型指标比自带的还差，那就要回头检查训练配置；如果和自带权重差不多，说明数据划分和训练流程没有问题。

有一次我发现自带的YOLOv8权重mAP50达到0.94，但我自己训练的只有0.89，后来排查发现是训练时忘记设置类别权重，坏果样本虽然不少，但模型还是对坏果偏向不足。调整cls损失权重后重新训练，指标才追上。所以自带权重不光能用来推理，也是检验训练流程是否合格的参照物。

4.4 边框精度：别忽略小目标漏检

水果检测通常不是小目标，但在传送带远端、多个水果互相遮挡时，边界框会很小且不稳定。YOLO模型对这类目标的召回率往往偏低。

处理方式有三个思路：一是提高输入分辨率到768或960，小目标像素变多，召回率会有明显提升，但推理变慢；二是把大图切块推理，也就是在检测前把图像切分成多个子图，分别检测再合并结果，适合处理高分辨率摄像头画面；三是在训练时用更大的mosaic，增加小目标在训练样本中的出现频率。

5. 把模型落到真实分拣场景：推理链路和易踩的坑

训练好的模型最终要跑在产线摄像头后面。这个环节最考验工程能力，因为模型精度高不代表部署后就能稳定工作，预处理、推理、后处理每一环都可能让效果打折扣。

5.1 导出ONNX和TensorRT模型

PyTorch权重无法直接拿到生产环境的推理引擎里用，一般要导出成ONNX，再转成TensorRT或者直接用ONNX Runtime推理。

YOLOv8的导出命令：

yolo export model=best.pt format=onnx imgsz=640

YOLOv5的导出命令：

python export.py --weights best.pt --img 640 --batch 1 --simplify

导出后可以用onnxruntime验证一下输出形状，确保模型输入输出正常。如果用TensorRT，还需要把ONNX转成engine文件，这一步会在目标GPU上做算子优化，耗时较长，但推理速度通常能比ONNX Runtime再快一截。

一个非常容易踩的坑是：训练时用的是RGB图片，但OpenCV读图默认是BGR。如果导出模型后忘记把BGR转成RGB，检测精度会大幅下降。在写预处理代码时，要么在resize后加cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)，要么直接用PyTorch官方仓库里的letterbox函数，它们内部都统一做了RGB转换。

5.2 实时推理时的预处理细节

推理阶段不是简单把图片缩放到640x640就完事。直接拉伸会改变目标的长宽比，导致边框回归不准。正确做法是使用letterbox，也就是等比缩放后填充灰色边条，保证输入尺寸是640x640且图像不变形。

举个例子，一张1280x720的图片，等比缩放到640x360，然后在上下方向补上灰色块，变成640x640。推理完成后，要把预测框坐标减去padding部分，再按缩放比例还原到原图坐标。如果这一步做错，框会偏移，看起来就像模型定位不准，其实是后处理坐标换算有问题。

5.3 NMS阈值和业务置信度阈值怎么调

模型输出的是一堆候选框，需要通过NMS去除重复检测。水果场景中两个水果相邻时，NMS阈值设太严，可能把其中一个水果的框误删；设太松，则会出现一个水果多个框。

一般推荐iou_thres=0.45。如果发现重叠水果漏检，可以适当降低到0.4；如果发现同一个水果反复框选，可以升高到0.5。业务置信度阈值conf_thres则要根据产线容忍度调整：如果希望坏果尽可能被挑出来，阈值可以设低一点，比如0.2，代价是好果被误判为坏果的概率升高；如果希望尽量减少人工复核成本，阈值可以设到0.4以上。

实际上，阈值不是一次性调完就固定。不同的光照、水果品种、摄像头角度都会影响最佳阈值，最好是做一个简单的滑块工具，现场跑一遍视频，动态观察不同阈值下检测框的变化。

5.4 现场部署还会遇到的几个工程问题

第一，摄像头帧率与推理速度不匹配。如果推理速度是30毫秒一帧，而摄像头是60帧，直接用同步方式处理会丢掉一半画面。建议用生产者-消费者模式，摄像头线程只管取帧，推理线程从队列里取最新的一帧处理，保证延迟最低。

第二，多个检测框需要聚合。很多分拣场景关心的是"这个水果是不是坏的"，但一个画面里可能同时出现五六个水果，有的好、有的坏。不能只看全局有没有坏果框，而是要把每个水果当独立目标，结合它的位置、类别、置信度做追踪。简单做法是通过IOU匹配相邻帧的检测框，给每个水果一个临时ID，连续几帧都被判为坏果，才触发剔除动作。

第三，模型更新不能影响产线。现场模型迭代需要灰度发布。我一般把新旧模型同时部署，新模型先跑影子模式，只记录结果不参与实际分拣，对比一段时间都稳定后，再把新模型切换为正式模式。

5.5 数据闭环：让模型越用越准

诚实地讲，单靠一次训练很难覆盖产线上所有坏果形态。投入实际使用后，每天都会产生大量被漏检或误检的图片。如果没有数据闭环，模型精度大概率会在新的水果品种、新的光照条件出现时下滑。

我建议在部署代码里加一个简单的难例保存逻辑：当检测结果的置信度在0.3到0.5之间，或者人工复核发现预测结论与实际结果不一致时，把原始图片和检测框存下来。每周汇总一次，标注后加入训练集，做一次增量训练。

做增量训练时要注意，不能只用新增数据，否则模型会遗忘之前学到的特征。要按一定比例混合历史数据和新增数据，比如历史数据占70%，新增数据占30%。初始学习率可以设低一点，比如lr0=0.001，训练轮数也减少到30轮以内，避免在新数据上过拟合。

我在实际使用中发现，产线上真正拉低指标的问题往往不是模型结构，而是数据标注不一致。不同标注人员对"坏到什么程度算坏果"的理解不一样，导致标签噪声很大。后来我们规定：只要果面出现明显霉斑、塌陷、渗液，或者碰伤面积超过果面20%，都标为坏果。统一标准之后，同样的训练参数，mAP50直接涨了两个多点。做水果好坏检测的朋友，千万别忽略这个细节。