YOLOv8花卉分类实战：数据集准备、训练调参与评估避坑指南

简介面向花卉图像分类与yolov8模型训练需求该数据集包含daisy、dandelion、roses、sunflowers、tulips五个常见类别适用于图像分类、目标检测及迁移学习等任务也可支撑高校实验、园艺品种筛选和植物科普展示。资源共2000个文件其中1999张jpg图像提供多场景、多姿态的花卉样本另含1个py脚本用于数据集划分、格式转换或训练辅助压缩包整体约218.93MB。已有622人学习下载适合刚接触分类任务的学生或需要快速搭建花卉识别模型的开发者。数据集图片按类别组织、命名规范视觉差异明显便于开展数据增强与泛化能力评估结合yolov8训练流程可快速获得基线结果为后续扩充花卉品类、优化分类精度以及植物学教学演示提供了直接可用的数据基础。花卉分类在植物多样性保护、园艺选种和科学普及中应用广泛这份数据可作为相关系统开发与验证的标准化输入。1. 5类花卉YOLOv8数据集拿到手先认清它是什么能省多少事如果你手头攒了几千张花的照片想训练一个能分清 daisy、dandelion、roses、sunflowers、tulips 这五类的小模型最卡壳的往往不是模型选型而是数据格式图片放在哪个目录、类别怎么映射成数字、train 和 val 按什么比例切、坏图会不会让训练中断。这个 5 类花卉 YOLOv8 格式数据集解决的就是这件事——把五类花卉图像按 YOLOv8 分类任务的目录约定整理好train/val 已经划好类别顺序固定拿到手第一条训练命令就能跑通。对刚入门 YOLOv8 分类的新手它省掉了最磨人的数据准备阶段对已经在跑检测或分割任务的老手它也能当一份干净的 baseline 数据用来验证自己的训练流水线、对比增强策略或者测试不同骨干网络在细粒度图像分类上的表现。下面从数据集格式开始拆一路讲到训练参数、评估指标和最常见的几个坑。2. 目录结构与格式解析从原始照片到YOLOv8训练的准备工作2.1 YOLOv8分类数据集的标准目录约定YOLOv8 的分类任务classify和检测任务detect在数据组织上完全不同。检测需要 txt 标注文件和 data.yaml里面写类别列表和路径分类任务直接沿用了 ImageFolder 风格的目录结构数据根目录下放 train 和 val 两个子目录每个子目录里每类花一个文件夹文件夹名就是类别名。这种设计对新手非常友好因为标签就是文件夹名肉眼扫一眼目录树就能完成核对。flowers/ ├── train/ │ ├── daisy/ │ │ ├── daisy_001.jpg │ │ ├── daisy_002.jpg │ │ └── daisy_003.jpg │ ├── dandelion/ │ ├── roses/ │ ├── sunflowers/ │ └── tulips/ └── val/ ├── daisy/ ├── dandelion/ ├── roses/ ├── sunflowers/ └── tulips/训练时把 data 参数直接指向 flowers 这个根目录框架会自动扫描 train 下的子目录并按字母序生成类别映射daisy0、dandelion1、roses2、sunflowers3、tulips4。这里的 tu 就是 tulips 的缩写正式使用时我建议文件夹名写全称。原因很简单推理阶段打印类别名时全称可读性高也不会因为“tu”到底代表 tulips 还是 tulip 产生歧义。实际整理时还有几个容易忽略的点。一是目录里不要混入多余的隐藏文件比如 macOS 的 .DS_Store、Windows 的 Thumbs.db以及操作时误拷贝的空文件夹。框架扫描子目录生成类别表时多一个非预期文件夹就会多出一个类别训练日志里类别数会从 5 变成 6 甚至更多。二是路径尽量不要带中文和空格。YOLOv8 对带空格路径多数情况能处理但一旦在 Windows 环境下出现转义问题报错会非常难查。三是 train 和 val 的子目录名必须完全一致如果 val 里写成了“Daisy”或者“daisy 副本”类别映射就会对不上。2.2 坏图清洗与图像尺寸筛查别让一张坏图毁掉整轮训练原始图像在进入上面这个目录结构之前必须过一遍坏图检查。真实场景里最常见的三类问题扩展名是 jpg 但文件实际已损坏的下载过程被截断导致解码失败的以及某些 20x20 缩略图混进数据集的。坏图的危险在于训练时偶发抛错表现为“跑着跑着突然崩掉”或者某个 epoch 卡住不动定位起来非常痛苦。我一般会在划分目录之前跑一个全量校验脚本用 PIL 做两级检查from PIL import Image import os def inspect_images(root_dir, min_side32): problems [] for dirpath, _, filenames in os.walk(root_dir): for fn in filenames: if not fn.lower().endswith((.jpg, .jpeg, .png)): problems.append((os.path.join(dirpath, fn), bad_extension)) continue path os.path.join(dirpath, fn) try: with Image.open(path) as im: im.verify() with Image.open(path) as im: im.load() if min(im.size) min_side: problems.append((path, too_small)) except Exception as e: problems.append((path, repr(e))) return problems issues inspect_images(./raw_images) for path, reason in issues: print(path, -, reason)逻辑说明第一遍用 im.verify() 只解析文件头部开销很小用来快速淘汰扩展名伪造的假图片第二遍用 im.load() 强制把像素数据读进内存这一步能暴露头部正常但像素区损坏的文件。只做 verify 不做 load会让一批“能打开但一解码就崩”的文件漏过去。参数说明min_side 指宽高中较短一边低于 32 像素就标记为 too_small。这个阈值要按任务调整——如果图片里花占比很大32 已经够看如果花很小、要靠局部细节区分建议放宽到 16反过来如果都是高清原图阈值设 128 可以顺带清掉一批低质缩略图。脚本只输出问题列表而不直接删文件我会先人工扫一眼列表再批量移到 quarantine 目录防止把格式特殊但能正常用的图误删。2.3 按比例划分train/val的脚本与类别映射逻辑拿到原始图像后第一个动作通常是做 train/val 划分。最常见做法是按文件随机打乱后切分固定随机种子否则每次划分结果都不同实验之间没法比较。另一个容易被忽略的点是划分粒度应该是“文件批次”而不是“单张文件”。如果你同一个花的多张连拍内容高度相似它们要么全进 train要么全进 val否则就会出现数据泄露后面 val 精度虚高。import os import random import shutil src_root ./raw_images dst_root ./flowers categories [daisy, dandelion, roses, sunflowers, tulips] val_ratio 0.2 random.seed(42) for cat in categories: src_dir os.path.join(src_root, cat) if not os.path.isdir(src_dir): continue files [f for f in os.listdir(src_dir) if f.lower().endswith((.jpg, .jpeg, .png))] random.shuffle(files) val_count round(len(files) * val_ratio) val_set set(files[:val_count]) for f in files: split val if f in val_set else train dst_dir os.path.join(dst_root, split, cat) os.makedirs(dst_dir, exist_okTrue) shutil.copy(os.path.join(src_dir, f), os.path.join(dst_dir, f)) print(cat, train:, len(files) - val_count, val:, val_count)逻辑说明脚本对每个类别独立切分保证 val 里五类的分布比例和原始数据一致而不是把图片全局混洗后再切。全局混洗的问题在于如果某类原始数据只有 200 张另一类有 1000 张全局切分后 val 里各类比例与训练集比例不一致小类在 val 里的样本可能少到算不出稳定的精度。这里用的 copy 而不是 move是为了留一份原始图像做后悔药磁盘实在不够再改成 move但建议至少保留一个清单文件记录每张图属于哪个 split。参数说明val_ratio0.2 是大多数图像分类任务的经验值。几千张图时20% 的 val 足够算出稳定的 top1/top5 精度如果总量只有几百张建议提到 0.3并且考虑做交叉验证来选模型。random.seed(42) 保证不同机器、不同时间跑出来的划分一致这是实验可复现性的基础。如果数据有明显来源批次例如同一天、同一机位、同一个花圃拍摄的一批图上面这个脚本还是不够稳。更稳妥的做法是先按来源分组再对分组做切分。我常用的一种变通方案是按文件名里的序号前缀或拍摄时间戳做桶以桶为单位 shuffle 和划分桶内图像天然属于同一次拍摄批次这样能有效减少泄露。这个细节在第 5 章还会专门展开。3. 用YOLOv8训练花卉分类模型最小命令、骨干选型和四个必调参数3.1 一行命令启动训练分类任务的data指向与命令行写法数据目录就绪后训练本身非常简单。以 YOLOv8 的 CLI 方式为例yolo classify train data./flowers modelyolov8n-cls.pt epochs50 imgsz224 batch32这行命令做三件事加载 yolov8n-cls.pt 预训练权重扫描 flowers/train 下的五个子目录生成类别表用 224x224 输入在默认增强策略下训练 50 轮。训练产生的权重、曲线图和参数配置全部落在 runs/classify/train 目录下不会污染数据目录也不会覆盖旧实验。这里最关键的是 data 参数的指向分类任务里 data 必须是指向同时包含 train 和 val 两个子目录的根目录而不是某个类别文件夹也不是一个 yaml 文件。这是 classify 和 detect 任务最大的区别。检测任务必须提供 data.yaml里面写 train/val 路径和 names 列表分类任务只需要目录路径类别由子目录名称自动生成。我见过不少第一次用的人把 data 指到了 train 目录结果 val 扫描阶段直接报错提示找不到验证集。如果更喜欢在 Python 脚本里控制训练流程等价的写法是from ultralytics import YOLO model YOLO(yolov8n-cls.pt) results model.train( data./flowers, epochs50, imgsz224, batch32, lr01e-3, patience10, )参数说明epochs50 是花卉分类比较稳的起点。预训练权重来自大规模通用图像集合花卉这种细粒度任务通常 20 到 30 轮就能收敛50 轮留出了观察曲线形状的富余空间。patience10 表示连续 10 轮 val 精度不再提升就提前停止防止后半段刷过拟合。lr01e-3 是对预训练权重做微调时比较安全的学习率官方的某些默认策略在启动时会到 1e-2 量级小数据集上容易看到 loss 震荡。训练开始后终端会按 epoch 打印 train loss、val loss、top1_acc、top5_acc 等指标。第一次跑的时候不用太纠结每一行的波动先看整体趋势。如果前 5 轮里 top1_acc 能快速从几十爬到 80 以上说明数据和预训练权重是匹配的如果一直趴在 20% 附近五类任务的随机水平优先怀疑学习率设置或者数据路径是否正确。3.2 骨干网络选型n/s/m/l对花卉分类的性价比YOLOv8 分类系列按规模从轻到重有 n、s、m、l 几个档位对应 yolov8n-cls.pt、yolov8s-cls.pt 等预训练权重。对 5 类花卉这种任务我的建议是先用 n 跑通全流程确认数据没问题再用 s 作为最终模型。只有当 val 精度卡住不动、且混淆矩阵显示某两类确实难分时才考虑上 m 或 l。原因很直接花卉分类的瓶颈通常不在模型容量而在数据多样性。几千张图每类几百到一两千张n 模型在 224 输入下已经能到 90% 以上的 top1。换 l 模型计算量和显存翻几倍精度提升可能只有 1 到 2 个百分点对部署价值有限。从显存角度看一个经验参考batch32、imgsz224 时n 模型在 6G 显存卡上没问题s 模型建议 8G 以上m、l 就老实把 batch 降到 16 或 8。小显存不是不能跑大模型是训练速度慢到不值得。骨干选择的另一个维度是输入分辨率。n 模型配合 imgsz320 往往比 m 模型配合 imgsz224 更能解决细粒度分辨问题因为花的细节是空间信息提高分辨率比增加通道数更直接。所以我一般把“先提分辨率、再升骨干”作为调优顺序。3.3 必调参数imgsz、epochs、lr0、batch与早停patience训练中最值得手动调的四个参数可以浓缩成下面这张表参数常见范围我的默认说明imgsz224 / 320 / 640224花卉占画面主体时 224 够用花很小或要分辨花蕊纹理时上 320epochs30 ~ 10050配合早停使用给足就行不必死等lr01e-4 ~ 1e-21e-3迁移学习默认 1e-3数据很少时降到 1e-4 防震荡batch8 ~ 6432太小会让 BN 统计不稳定太大对精度提升有限先解释 imgsz。分类模型的输入分辨率决定它能看到多少细节。daisy 和 dandelion 的区别有一部分在花瓣形态和叶片形状上224 能看清整体结构但如果原图里花朵很小、只占画面的一半都不到模型会拿大量背景区域做判断。这时把 imgsz 提到 320等效于把花放大 1.4 倍再看精度提升往往比换骨干更明显。代价是训练时间大约增加 1.5 倍显存也跟着涨。epochs 和 patience 是一对。分类训练最怕的不是轮数太少而是你盯不住曲线、任它跑完 100 轮刷出一个过拟合模型。我的习惯是 epochs 给到 100patience 设为 10。框架每个 epoch 结束会在 val 上算一次 top1/top5连续 10 轮没有提升就停最终保留的是 val 精度最高那一轮的权重 best.pt。这个机制下epochs 给大点没有坏处。lr0 的调节要看训练日志前几轮的表现。跑了 3 轮如果 train loss 几乎不降、val acc 一直在 20% 上下晃大概率是学习率不合适。学习率过高时loss 曲线会出现“降一点、涨一点”的锯齿。1e-3 在微调场景下是安全起点翻车概率最低。batch 的调整则跟着显存走出 OOM 就把 batch 减半同时把 lr0 对应调低一点否则相同学习率在小 batch 上显得步子太大。训练过程中的监控只需要盯两个数字每个 epoch 末尾的 val/top1_acc 和当前的 train loss。top1_acc 在 30 轮后还在匀速上涨说明没到瓶颈可以继续等已经横盘 10 轮早停会帮你收工。所有曲线在 runs/classify/train 目录下的 results.png 里都能看到包含 loss 和 top1/top5 两组曲线。4. 评估与推理验证从val结果到能用的预测脚本4.1 val模式的输出文件怎么读训练完成后weights 目录下会保存 best.pt 和 last.pt 两个权重。best.pt 是 val 精度最高那一轮的产物last.pt 是训练结束时的产物。实际使用一律用 best.pt除非你明确知道 last 这一轮泛化更好——这种情况很少见但确实偶尔发生。对训练好的模型做一次完整验证用下面这条命令yolo classify val modelruns/classify/train/weights/best.pt data./flowers imgsz224val 命令会重新扫描 val 目录逐张做预测最后在终端打印 top1_acc 和 top5_acc同时在同一目录下更新 confusion_matrix.png、results.csv 等指标文件。这个独立 val 过程和训练时“每轮末尾的验证”用的是同一套数据加载逻辑但它更精确训练过程中的 val 会受数据增强的随机性影响独立 val 则是把增强关掉、逐张稳定评估结果更可信。新手容易以为训练日志里的 val 就够了省掉这一步。实际上两个数值之间偶尔会差 1 到 2 个点单论调参你该信独立评估的结果。参数说明data 指向和训练时相同的数据集根目录imgsz 要和训练时保持一致。如果训练用了 320、这里用 224 来验证模型输入分辨率变了精度会掉一点尤其从高分辨率降到低分辨率时比较明显。所以这条命令里的 imgsz 最好复制训练命令里的值不要随手改。4.2 混淆矩阵daisy和dandelion的分不清在哪一目了然val 跑完打开 confusion_matrix.png 能看到一张 5x5 的矩阵热力图。行是真值列是预测值对角线越亮越好。花卉场景里最常见的问题就是 daisy 和 dandelion 互相串这两类都是白色小菊花头花瓣形态也很接近混淆矩阵里对应格子总是特别亮。看到这种情况我的处理顺序是先不动模型结构回到数据看两个方向。第一val 里这两类的样本质量是否足够。如果 daisy 的 val 图大多是背景虚化严重、花头占画面不到 20% 的图模型拿到的有效特征太少误判很正常。第二看训练增强是否覆盖了这两类的共性差异。如果照片里只有 daisy 有密集重瓣、dandelion 全是单层花瓣这种分布差异会在训练时强化模型把“重瓣”当作 daisy 的特征泛化就很弱。如果数据没问题再调训练策略。一个便宜有效的做法是把 imgsz 从 224 提到 320让花蕊和花瓣边缘进入感受野另一个做法是做困难样本挖掘——把 val 里预测置信度在 0.5 到 0.8 之间的图挑出来人工看一遍。如果发现这些图背景相似度极高就补充一些“不同背景下同种花”的训练样本比单纯堆数据更高效。4.3 单图与批量推理脚本把模型变成可调用的服务评估通过后最常见的用法是把模型接进批量打标脚本或本地服务。用 Python API 做单图预测from ultralytics import YOLO model YOLO(runs/classify/train/weights/best.pt) results model.predict(test_flowers/001.jpg, imgsz224) probs results[0].probs top1 probs.top1 top1_conf probs.top1conf print(model.names[top1], round(float(top1_conf), 3)) print(top5:, [model.names[i] for i in probs.top5])逻辑说明分类任务的 predict 返回值里probs 是预测概率对象。top1 是最高概率对应的类别索引top1conf 是它的置信度top5 是概率前五的类别索引列表。这里不要尝试用 results[0].boxes那是检测任务的结果结构在分类任务里是空的取出来只会拿到 None。model.names 保存了类别名列表打印出来能看到类似 {0: daisy, 1: dandelion} 的映射。批量预测同样简单传一个目录路径就会递归扫描所有图片yolo classify predict modelruns/classify/train/weights/best.pt source./test_flowers save_txtTrue每条命令会为每张图生成一个同名 txt 文件内容格式是“类别索引 置信度”对应关系去 model.names 里查。适合给一组没有标注的新照片快速打标比如刚从相机里导出的花圃照片。如果你的场景是把模型接进 web 服务我一般不用 CLI而是在进程启动时加载一次模型之后每个请求直接调用 predict并把 imgsz 固定住避免重复初始化推理上下文。另一个实用技巧是传 device0 把推理放到 GPU没有 GPU 时模型自动落到 CPUimgsz 保持 224 的情况下单张推理通常能到几十毫秒量级已经够很多演示场景用。5. 花卉分类数据集常见坑不平衡、过拟合、背景干扰与脏标签5.1 类别样本数差三倍模型悄悄偏向多数类的现象与修正现象训练日志里整体 top1_acc 到了 92%按类别细看daisy 的 recall 是 98%tulips 只有 76%。原因是 tulips 的样本数只有 daisy 的三分之一模型在低置信度区间的预测倾向被多数类带偏统计先验把模糊样本推向了训练集中更常见的类别。原因随机采样构建 batch 时多数类在每个 batch 里出现概率高梯度更新方向被多数类主导。花卉数据集中 dandelion 和 daisy 外观本来就接近模型在两者间犹豫时更容易把模糊样本判成数据量更大的那一类。解决先统计五个类别的文件数。如果最大类和最小类相差超过 2 倍优先补数据而不是调权重。补数据不方便时常见做法是在训练前对少数类做简单增强复制——水平翻转、轻度旋转、调饱和度把少数类扩到多数类的 70% 以上再训练。YOLOv8 分类任务里没有直接暴露类别权重参数但通过这个办法同样能达到类似加权采样的效果。要注意增强复制出来的样本不是新信息扩太多反而容易让模型对复制样本过拟合一般扩到接近多数类就够了。这条坑的教训是只看 top1_acc 会掩盖少数类崩盘。我习惯在调参前单独打印每个类别的 recall再对照样本数看很多“精度上不去”的问题本质上只是数据不平衡。5.2 过拟合信号train_acc高而val_acc低的处理路径现象训练到第 45 轮train loss 降到 0.02train top1 到了 99.8%但 val top1 停在 86% 上不去了。这不是模型没学会是它把训练集里每张图的构图、光照、甚至 JPEG 压缩痕迹都背了进去。原因花卉数据天然容易过拟合。同一批花可能在同一个晴天、同一个角度被拍了很多张这些图内容高度相似模型不需要泛化也能在 train 上拿高分。另一个因素是数据量小的时候模型容量相对过剩记忆比泛化更容易。解决按顺序处理三个环节。第一看增强是否够强。YOLOv8 分类默认开启轻度增强如果 val 精度从第 20 轮开始就不动可以考虑在预处理阶段加更明显的色彩抖动和随机裁剪。第二加 dropout。YOLOv8 分类任务支持在训练时设置 dropout0.2对分类头做随机失活通常能在 val 精度上换回 1 到 3 个点。第三检查划分里有没有数据泄露——如果 val 里某张图和 train 里另一张图肉眼几乎完全一样这个 val 精度本身就是虚高的修划分比调模型更紧急。经验过拟合的典型曲线是 train_acc 一路向上、val_acc 在第 25 轮左右见顶后横盘。不要指望跑满 100 轮能突破patience10 的早停通常会在精度峰值后第 10 轮把你拉出训练保留的 best.pt 就是峰值权重。5.3 背景干扰模型学的是花瓣还是花盆现象模型在 val 上对某种花的判断受画面背景影响很大。测试图改成“花卉特写但背景里有其他植物”时预测概率出现明显下降。人工检查训练图后发现大量样本是带花盆、带完整植株的全身照模型很可能直接学了花盆轮廓和陶土色纹理而不是花瓣。原因分类模型会利用所有能帮助它降 loss 的特征包括背景。当某几类花的背景高度一致、而花本身的差异集中在花头时模型更容易捡起背景这个“捷径”因为背景比花瓣特征更稳定、更好学。解决掺入方向。一是在数据准备阶段做显著区域裁剪把花朵主体裁到画面中心再训练如果原始图是全身照不用手动抠图用增强里的随机裁剪和翻转就能弱化位置关联。二是补充背景多样性给每类花补充不同场地、不同光线、不同容器的样本破坏背景与类别的强关联。想判断模型是否在走捷径有个很简单的测试把 val 图四周裁掉 10%如果精度掉得比预期多说明模型依赖了花头以外的区域。5.4 脏标签与数据泄露换文件夹名也是一种标注现象某开发者 A 同学跑完 val 后抽查发现 sunflowers 类别里有 3 张图实际是雏菊被误放进了 daisy 文件夹还有一批“向日葵特写带蜜蜂”的图在 train 和 val 里各出现一份。原因分类任务的标签由文件夹位置决定人工整理时的拖拽错误、重复下载产生的重复文件都会形成脏标签和数据泄露。脏标签的隐蔽性在分类任务里比检测任务高因为模型能容忍少量错误标签而表现正常只有当精度卡住或你做人工抽检时才会暴露。解决训练前用脚本检查绝对重复计算每个文件的 md5把哈希相同的文件列出来人工裁决然后用“置信度抽检”流程找脏标签——用训练完的模型对 val 全量预测挑出 top1 置信度低于 0.6 的图人工过一遍确认标签错了就移动文件重训。这个流程成本很低通常只需要看几十张图就能发现一批问题。划分环节则建议按来源批次分组切分而不是文件级随机切分。我在 2.3 节提过按文件名哈希分桶的做法本质是把“同一时间拍的连拍图”分组到同一个桶再以桶为单位划分能有效避免同一来源的图像一半进 train、一半进 val 的泄露。6. 让花卉分类模型更耐打增强、导出与蒸馏的进阶收尾当基础流程跑通、val 精度也满意了决定这个模型能不能真正落地的还有三件事。第一是增强的精细化调整。YOLOv8 分类默认增强已经覆盖翻转和色彩抖动但花卉这种类别间差异小的任务可以针对性加入随机擦除把一张图里随机一块矩形区域填成纯色或模糊强迫模型不要只盯着一小片花瓣纹理做判断。对花瓣方向不敏感的花轻度旋转也很有帮助。这些增强参数大多能在训练配置里直接调不需要自己改写数据流水线。第二是权重导出。best.pt 只适合 Python 环境换到边缘设备或低延迟场景前先用一行代码导出model.export(formatonnx, imgsz224)导出的 onnx 文件不再依赖训练框架可以交给常见推理后端加载CPU 上的推理速度通常比原框架快一些。导完后要用推理工具确认输入输出节点再拿一张样本图对比导出前后 top1 是否一致这一步能拦截多数格式转换导致的隐性问题。第三是模型蒸馏。如果最终必须用 n 模型部署在嵌入式设备但 s 模型在 val 上比 n 高 2 到 3 个点可以把 s 模型当教师用它的预测概率做软标签去精调 n 模型。具体做法是先用教师模型对训练集全量预测保存每个样本的五类概率分布然后把 n 模型的训练目标改成“同时拟合真实标签和教师概率”。花卉这种五类任务蒸馏收敛很快n 模型通常能追回教师模型一大半的精度差距。我自己的习惯是任何花卉分类项目第一版永远是 n 模型加 224 输入加 50 轮先跑通全流程确认数据没有暗坑再谈精度优化。多数时候瓶颈在数据不在模型先把 val 混淆矩阵看明白比盲目升级骨干省时间得多。希望这些细节能帮你在自己的数据集上少走一圈弯路训练顺利。本文还有配套的精品资源点击获取