YOLOv5与YOLOv8水果好坏检测实战：训练调优与部署全复盘

之前帮某农业基地做过一个水果品质分拣的Demo，用的就是YOLO水果好坏检测这条技术路线。数据源直接来自一套现成的“水果好坏数据集”，里面不仅带了标注好的图片，还附带了YOLOv5和YOLOv8两个版本的模型权重，省掉了我大量从零开始的时间。这篇文章就把我从数据摸底、模型选型、训练调优到落地部署的完整过程复盘一遍，重点说那些常规文档里不会写的细节和踩过的坑，希望能给正在做类似目标检测项目的人一个可以直接抄作业的参考。

先交代一下这个项目适合谁看：如果你正要交一个目标检测相关的课程设计、比赛作品，或者想给某电商、某果园做一个“自动挑出坏果”的质检原型，那这条路线非常匹配。整个项目只需要一台带GPU的电脑（当然CPU也能跑，就是慢），加上一点点Python基础就能复现。我尽量把每一步的原因也讲清楚，让新手也能知道“为什么这么配”，而不只是“照着敲就行”。

1. 先搞清楚这个水果好坏检测项目到底在解决什么问题

1.1 理解“好坏”的定义边界是第一步

很多人拿到这类数据集就直接开训，结果训练出来的模型看起来指标还行，一上线就漏检严重。核心原因往往是没搞清楚“坏果”这个概念到底包含哪些形态。以我当时手里的数据集为例，它把“坏”拆成了几种典型状态：磕碰伤、腐烂斑、霉变、表皮皱缩，还有部分水果常见的黑斑病。这些状态在外观上差异非常大，如果只把它当成一个笼统的“坏果”类别，模型很容易只学会其中一种形态，其他形态就当成好果放过去了。

所以拿到数据集的第一件事，不是急着配环境，而是把图片翻一遍，统计一下坏果样本里都包含哪些“坏法”。我当时做了个小脚本，把标注框里的内容全部裁剪出来放到一个文件夹里，快速浏览了一遍，心里立刻就有底了。这一步大概花半小时，但能帮你后面省下几个小时的盲目调参。

另外一个容易忽略的点是边界模糊的图片。比如一颗苹果的一面完好，另一面已经开始腐烂，这种图到底算好果还是坏果？不同数据集定义完全不同。有的以“是否可食用”为标准，只要有一处烂斑就算坏；有的以“商业售卖等级”为标准，轻微瑕疵也算二等品，不算坏果。这个定义一定要在项目初期明确，并且写进标注说明里，不然后面做标注或者审核的时候大家标准不统一，标签质量会非常差。

1.2 为什么非要用目标检测，而不是图像分类

有些读者可能会问：我就想知道这张图里水果是好是坏，用图像分类不就行了吗？确实，如果场景固定，每次拍摄只有一个水果，且背景干净，分类模型完全够用。但实际的分拣场景几乎不会这么理想。常见的情况是传送带上有好几个水果挤在一起，有的互相遮挡，有的位于画面边缘，这时候分类模型只能给整张图一个标签，你根本不知道坏的是哪一个，也没法引导机械臂去抓取。

目标检测解决的正是“是什么”和“在哪里”两个问题。它会在图中输出若干个边界框，每个框带一个类别和一个置信度：框出的是坏果，置信度0.92。这个信息直接对接后续的分拣逻辑：置信度超过阈值，就触发机械臂把对应位置的水果推走。所以只要是做质检、分拣、巡检这类落地任务，目标检测几乎是标配，而不是可选。

这里也顺便解释一下YOLO这类模型的特点。它把目标检测当成一个端到端的回归问题，网络直接预测边界框的坐标和类别概率，不需要像老式的两阶段方法那样先找出候选区域再逐个分类。好处就是快，特别适合视频流和实时场景。我第一次用YOLO跑实时检测的时候，最直观的感受就是“这个速度，机器还没眨眼它已经给出了结果”，跟传统图像处理里写一堆阈值判断的效率完全不是一个量级。

2. YOLOv5和YOLOv8的选择逻辑：数据集里两个模型怎么用

2.1 YOLOv5：成熟稳定的“稳妥牌”

这个数据集里放了v5和v8两套模型权重，很多人第一反应是“既然有新版，干嘛不直接用v8”。但我实测下来的感受是：YOLOv5在这个场景里依然非常能打，尤其是作为第一个baseline的时候。它的优势在于社区资料极多，任何报错几乎都能搜到答案；而且CSPDarknet骨干加C3模块的结构经过大量项目验证，训练稳定，对新手极其友好。

v5有n/s/m/l/x几个尺寸档位，我当时先用yolov5s.pt作为起点做迁移学习。为什么选s而不是更小的n或者更大的m？原因很简单：s的参数量适中，在单张消费级显卡上可以跑得动，训练速度也快，适合先快速验证数据质量和整体流程。如果你的数据集没问题，训练曲线正常，再换更大的模型去冲精度也不迟。我见过很多新手一上来就开yolov5x，结果显存爆掉，或者训练了三天还没半个结果，其实都是在选型阶段就埋了坑。

2.2 YOLOv8：Anchor-Free思路带来的精度提升

YOLOv8是后来发布的版本，最大的结构变化是把Anchor-Based的检测头换成了Anchor-Free方式，同时在骨干部分用了C2f模块代替C3模块，检测头也改成了解耦结构，分类和回归分支各自独立。这些变化带来的实际效果是：训练收敛更快，小目标检测能力更强，整体mAP往往比同尺寸的v5高出一截。

在我这个水果好坏数据集上，同样训练100个epoch，v8s的验证集mAP50比v5s高出大概2到3个百分点。这个提升看起来不算夸张，但在坏果检出率这种业务指标上，2个百分点可能就意味着一天少漏掉几十个问题果。所以我后来把正式方案切到了v8，v5只作为流程验证工具。

不过v8也并非全是优点。它的模型导出和部署工具链相对新，如果你用的是比较老旧的嵌入式平台，可能要花额外精力去适配。而且v8的“快收敛”在某些小数据集上反而容易过拟合，需要配合更强的数据增强或者更早的早停策略。

2.3 项目选型对照表与我的推荐

为了让你一眼看清两者差异，我整理了一个对比表，参数以s档为例：

我的推荐逻辑很简单：如果你是第一次跑这个数据集，先跑yolov5s，确保整条链路通了，拿到一个正常的baseline；如果你有一定经验，或者业务精度要求更高，直接上yolov8m效果会更惊喜。对于边缘设备部署，就选v5s或者v8n，以帧率优先。

3. 从零跑通YOLO水果好坏检测：环境准备与训练实操

3.1 环境准备：一个命令聊不完的坑

训练环境这块，最容易出问题的其实是版本匹配，我说一下我试过的比较稳妥的组合。Python用3.9或者3.10，深度学习框架用PyTorch 2.0以上版本，显卡驱动和CUDA版本对上。如果你的显卡是NVIDIA的，先在命令行里输入nvidia-smi看一下驱动支持的最高CUDA版本，再去PyTorch官网选对应的安装命令，不要用pip默认装的CPU版本。

以YOLOv5为例，环境安装可以这样做：

# 创建虚拟环境 conda create -n fruit_yolo python=3.10 conda activate fruit_yolo # 安装PyTorch（以CUDA 11.8为例） pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 拉取YOLOv5代码并安装依赖 git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt

YOLOv8的环境更简单，直接安装ultralytics这个包就行：

pip install ultralytics

环境装完别急着跑，先随便拿一张图推理一次，确认能输出结果，再进入训练环节。这一步能帮你把环境问题和使用问题分开排查，不然后面报错你根本分不清是数据问题还是环境问题。

3.2 数据目录结构：90%的新手在这里翻车

YOLO系列对数据目录结构的要求非常明确，很多人训练直接报错，就是因为文件夹层级不对。标准的组织方式是：

dataset/ images/ train/ val/ labels/ train/ val/

注意images和labels是平级的，train和val里面的文件名必须一一对应，只是扩展名不同。比如images/train/apple_001.jpg对应labels/train/apple_001.txt。如果你的数据集是VOC格式的XML标注，还要先转成YOLO格式的txt，转换逻辑稍后会展开。

标签文件的内容是每行一个目标，格式为：

class_id center_x center_y width height

这里的前四个数字都是相对图片宽高的归一化坐标，范围在0到1之间。我给个例子：一张宽度为1000、高度为800的图片，某个坏果边界框左上角在(200, 150)，右下角在(500, 450)，那么中心点就是((200+500)/2/1000, (150+450)/2/800)，也就是(0.35, 0.375)，宽高分别是((500-200)/1000, (450-150)/800)，即(0.3, 0.375)。那行的内容就是：

0 0.35 0.375 0.3 0.375

我见过一个新手把所有框写成了像素坐标喂给模型，结果train.py报错数据解析失败，这就是对格式理解不到位。记住，YOLO格式永远用归一化相对坐标，不是绝对像素。

数据集的配置文件fruit.yaml也很关键，里面定义类别和路径。一个最简版本如下：

path: ../dataset train: images/train val: images/val nc: 1 names: ['bad_fruit']

这里path可以写相对路径，也可以写绝对路径。我建议写相对路径，因为换机器以后不容易踩路径问题。

3.3 训练命令和参数怎么给

训练YOLOv5的命令长这样：

python train.py \ --data fruit.yaml \ --weights yolov5s.pt \ --epochs 100 \ --batch-size 16 \ --img 640 \ --patience 10 \ --name fruit_run

YOLOv8的命令更简洁：

yolo train data=fruit.yaml model=yolov8s.pt epochs=100 batch=16 imgsz=640 patience=10

几个关键参数我展开说一下：

• epochs：训练轮数。对于这种单类别的简单检测任务，80到120个epoch一般足够。太多反而容易过拟合，盲目堆到300轮只会浪费算力。
• batch-size：一次喂给模型的图片数量。这个参数受显存限制，8GB显存跑batch=16、imgsz=640基本是极限，再大要么降低batch，要么把imgsz降到416。
• imgsz：输入图片尺寸。640是默认值，也是速度和精度的平衡点。如果你的数据集里水果大多很小，可以尝试更大的尺寸如1280，但训练时间会成倍增长。
• patience：早停耐心值。也就是连续多少个epoch验证集的指标没有提升就提前停止。这个参数特别有用，我一般设10到15，能省下不少无效训练时间。

3.4 训练过程怎么看：loss与mAP的读法

训练过程中终端会不断刷新每个epoch的指标，新手看到一排数字经常不知道该盯哪个。我自己的经验是分两步看：

第一步看loss曲线。训练loss在前期会快速下降，然后趋于平缓；验证loss如果跟着下降，说明模型在正常学习；如果验证loss降了一段之后开始回升，而训练loss还在下降，就是过拟合的典型信号。

第二步看mAP指标。训练结束或每个epoch结束后会打印mAP50和mAP50-95。mAP50指的是IoU阈值为0.5时的平均精度，数值直观，适合快速判断模型好坏；mAP50-95则是在多个IoU阈值下计算的平均值，更严格，也更贴近真实场景中框的定位精度。在这个水果检测任务里，mAP50能到90%以上就说明检测效果相当好，而mAP50-95通常比mAP50低10到15个百分点，属于正常现象。

训练完成后会生成训练日志和结果图片，包括混淆矩阵、PR曲线、F1曲线等等。我个人最常看的是PR曲线和混淆矩阵。PR曲线能告诉你当前置信度阈值下查准率和召回率的权衡，混淆矩阵则直观看清楚好果和坏果之间有没有互相误判。比如有一次我发现好果大量被误判成坏果，一看混淆矩阵立刻定位到是训练集里坏果样本太少导致模型偏向于“多报坏果”。

4. 决定模型上限的细节：数据标注与样本分布的隐藏讲究

4.1 先看数据再训模型：数据目录里的猫腻

很多开源数据集下载下来以后，你以为是整理好的“干净状态”，实际上往往包含几个坑。我当时打开这个水果好坏数据集，第一眼看到的是图片数量还不少，单类坏果的标注框也算细致。但仔细盘过之后发现几个问题：一部分图片的坏果框标注比较粗糙，边界框把大量背景也圈进去了；还有一些图片里好果占多数，坏果的样本数量明显偏少。

这些问题都会直接影响训练效果。粗糙的标注框会让模型很难学到水果的真实边缘，尤其是坏斑有时只占水果表面一小块区域，如果框得太大，模型会误以为坏果区域包含周围的完整果面，推理时就会框出比实际坏果大得多的范围。所以我建议在训练前写个小脚本，统计一下每张图的标注框面积和宽高比分布，把那些框面积异常大或异常小的样本挑出来人工复查一遍。

你可能会问，开源数据集不是都标好了吗，还要复查？我的观点是：标好的数据也要抽查，尤其是当它的来源不明确时。你会发现自己花半小时修正几百个明显有问题的框，比花三个小时调模型参数更有效。数据质量决定模型上限，这句话不是空话。

4.2 坏果样本的多样性比数量更重要

在水果好坏这个任务里，类别不平衡往往是最大的敌人。常见的情况是好果样本很多，坏果样本只占两成。如果模型训练到后期发现“老是看到好果，坏果偶尔见一面”，它就会倾向于把一切正常水果判为好果，偶尔遇到坏果也不敢报。反映到指标上就是mAP还可以，但坏果的召回率很低，这正是质检场景最不能接受的问题。

解决方向不是简单复制坏果图片硬凑数量，而是增加坏果形态的多样性。我前面提到的“腐烂、霉变、磕碰、皱缩”这几种状态，在数据集中最好各能覆盖几十张到上百张，每张图里坏果的位置、遮挡程度、拍摄角度都要有变化。宁可用300张形态丰富的坏果，也不要用1000张角度都差不多的腐烂苹果图片。模型学到的是泛化特征，不是某个特定角度的“模板”。

我在这个项目里还做了一个小实验：把坏果样本按形态分组，分别统计各组在训练集和验证集里的分布。结果发现验证集里霉变水果特别多，训练集里却很少，导致模型在验证集上的召回率波动非常大。找到这个原因以后，我重新划分了训练集和验证集，确保各类形态在两个集合里占比相近，验证结果立刻稳定了许多。

4.3 数据增强与类别不平衡：不砸钱也能提升效果

数据增强是解决样本不足和类别不平衡的有效手段。YOLO框架内置的增强策略已经很强，尤其是马赛克增强，会把四张图拼在一起做训练，相当于变相扩充了样本量，也迫使模型学会在更复杂的背景下检测目标。我一般会保留马赛克增强，同时把HSV颜色扰动调大一点，让模型对白天、黄昏、偏暖或偏冷的光照更鲁棒。

类别不平衡还可以通过loss权重来缓解。YOLOv8里可以给每个类别单独设置loss系数，把坏果类别的权重调高一点，相当于告诉模型“分错好果问题不大，漏掉坏果代价很高”。我从权重1.0调到1.5之后，坏果召回率提高了3到4个百分点，而好果的误报率只上升了1个百分点，这笔账很划算。

另外要强调一个容易忽略的点：验证集不要做增强，也不要做任何过采样。验证集的作用是模拟真实场景下的表现，必须保持原始分布。如果验证集被复制过或者增强过，模型在验证集上的指标会虚高，但到真实场景立刻露馅。

5. 推理与部署落地：从单张图片到实时视频流

5.1 加载预训练权重做推理：先确认模型没白训

训练完以后，第一时间拿一张训练时没见过的图片做推理，确认模型没有白折腾。YOLOv5的推理命令：

python detect.py \ --weights runs/train/fruit_run/weights/best.pt \ --source test_images/sample1.jpg \ --conf 0.45 \ --save-txt

YOLOv8则是：

yolo predict model=runs/detect/train/weights/best.pt source=test_images/sample1.jpg conf=0.45 save=True

推理输出中，每个检测结果会打出类别ID、置信度和边界框坐标。比如0 0.88 320 240 80 120，意思就是类别ID为0（坏果）、置信度0.88、框的中心在(320,240)，宽高为(80,120)。在实际项目中，这个置信度阈值conf很关键。调太高会漏检，调太低会误报，我一般先从0.45开始，再根据业务容错空间上下浮动，批量跑一遍验证集找最优值。

5.2 视频/摄像头实时检测：工程化的注意事项

从单张图片到实时视频流，看着只是换了个输入源，实际牵扯到不少工程问题。最基本的方式是用OpenCV读取摄像头，每帧送入模型做推理，拿到结果后把框画在图像上：

import cv2 from ultralytics import YOLO model = YOLO("best.pt") cap = cv2.VideoCapture(0) while cap.isOpened(): ret, frame = cap.read() if not ret: break results = model(frame, conf=0.45) annotated_frame = results[0].plot() cv2.imshow("fruit detection", annotated_frame) if cv2.waitKey(1) & 0xFF == ord("q"): break

这段代码能跑通整个流程，但离“工程可用”还有距离。首先，完整分辨率画面直接送入模型会拖慢速度，通常会先把图像按比例缩放到640或416，做完检测再把检测框的坐标映射回原图。其次，实时推理可以结合目标跟踪或者区域抽帧来减少重复检测。比如传送带场景，帧与帧之间水果位置变化不大，可以每两帧推理一次，中间帧用跟踪算法补位，帧率立刻翻倍。

还有一个实际经验：画面里如果有多个水果，板子又比较忙，可以先做一个粗略的ROI区域裁剪，只对感兴趣区域做检测。比如传送带上水果只出现在图像的下半部分，那就把上半部分裁掉，既减少计算量，也降低背景误检。

5.3 模型导出：从PyTorch到可部署格式

模型要想在边缘设备上真正跑起来，通常要进行格式转换。PyTorch训练出来的.pt权重不能直接在大部分嵌入式推理框架里用，一般需要导出为ONNX格式。YOLOv8的导出命令非常省事：

yolo export model=best.pt format=onnx dynamic=True

导出之后可以用ONNX Runtime在CPU上跑推理，很多没有CUDA的工控机也能流畅运行。如果目标平台是GPU，还可以进一步转成TensorRT格式，推理速度会再上一大截。我个人实测，同一套模型从PyTorch转ONNX再转TensorRT之后，帧率能提升2到3倍。

但需要注意：导出的时候如果开了dynamic=True（动态输入尺寸），兼容性更好，但某些推理引擎上速度会略慢；如果你的输入尺寸固定为640，那导出时用固定尺寸通常能达到最优性能。这里要结合你实际部署设备的推理框架做取舍。

6. 典型问题复盘：我踩过的坑和排查思路

6.1 训练时loss直接变成NaN

这个问题我遇到过两次，出现原因基本都指向数据或者学习率。第一次是因为数据集里有一个空的标签文件，也就是对应图片没有任何标注，YOLO训练读到这种文件时可能出现数值问题。排查方法很简单：写个脚本把labels目录下所有txt文件统计一遍，找出大小为0的文件，要么删掉对应图片，要么把空标签补上。

第二个常见原因是学习率设得过大。当你自己调整了lr0参数，比如从默认的0.01改成0.1，模型很容易在前几个epoch就loss爆炸。如果数据检查没问题，就试着把学习率降低到默认值的十分之一，再从0.001起步慢慢调。

6.2 坏果漏检率高，明明训练mAP不差

训练mAP高但漏检多，最直接的原因可能是验证集选取偏简单，导致mAP虚高。比如验证集中的坏果都很大、很居中、背景干净，但真实场景里坏果出现在边缘、有遮挡或者尺寸较小，模型自然表现不佳。我之前有一版模型就是这种“高分低能”状态，后来重新划分验证集，加入更多有挑战性的样本，mAP掉了5个百分点，但真实场景里的漏检率反而降了。

另一个原因是置信度阈值设置不够合理。如果推理时不区分场景统一用0.5，坏果特征不明显、置信度在0.3到0.5之间时就被扔掉了。对这种漏检代价高的场景，我会把阈值降到0.25左右，再用NMS去重，宁可多出几个误报，也不要放过坏果。

6.3 同一颗果出现一堆重复框

这个现象几乎都是NMS参数没调好导致的。模型会为同一个目标生成大量候选框，NMS负责挑出最合适的那个。YOLOv5和v8的iou_thres默认一般在0.45到0.5，如果设得过高（比如0.9），框之间IoU达不到阈值，就会被保留下来，形成重复框。

解决方法有两种思路：一是调高NMS的IoU阈值，让重叠框被合并；二是调低置信度阈值的同时配合更激进的NMS。另外，如果你的场景里水果本身密度比较大，相邻水果的框可能会被NMS误合并成一个框，这时候就要适当降低iou_thres，让不同目标的框更容易被区分开。

6.4 验证集指标不涨又不过拟合

这种最让人头疼：训练loss在降，验证集指标一直横盘。我排了一通后发现，原因往往是学习率太小，模型更新太慢，不到100个epoch根本跑不动。解决方法是把训练轮数加长，或者每训练50个epoch手动降低一次学习率，让模型在后期做更精细的调整。

还有一种可能性是数据分布冲突：训练集和验证集来自不同的采集环境，比如一个是在室内灯光下拍的，另一个是在室外自然光下拍的，模型在训练集上学到的颜色和纹理特征，在验证集上完全不适用。这种问题靠调参很难解决，只能重新整理数据，或者加入更多光照、背景变化的数据增强来强行缩小分布差距。

6.5 部署到边缘设备帧率太低

帧率太低的根因通常不是模型而是流程。我一开始在某嵌入式平台上跑v8s，帧率只有8帧出头，后来做了三件事，帧率提到了20帧：第一，输入尺寸从640降到480，虽然精度掉了1到2个百分点，但感知上完全够用；第二，把模型导出为TensorRT格式，替代原来直接跑PyTorch模型的推理方式；第三，检测区域裁剪省掉了将近一半的计算量。

如果还嫌慢，最后的手段是换更小的模型档位，比如v8n。模型从s降到n，参数量可以减少一半以上，速度提升明显，代价是精度有所下降。这种取舍在真实项目里非常常见，关键是你的业务允许损失多少精度，提前想清楚，免得上线以后再来回折腾。

整体走下来，我最大的感受是这个“水果好坏检测”项目是入坑目标检测非常合适的一条路线。数据不难理解，任务边界清晰，而且v5和v8两个模型相互印证，正好可以对比感悟不同版本设计带来的影响。如果你也想动手练一练，我建议你先把数据组织和环境装好，用默认参数完整跑通一次训练再加花样，这比你上来就调一堆参数靠谱得多。等第一版模型拿到手，再逐步叠加那些调优技巧，整个过程会很顺。