简介：面向目标检测与图像分类学习者的yolo鲜花分类数据集，涵盖康乃馨、玫瑰、向日葵、雏菊等14种常见花卉，适合用于快速模型验证、小样本分类训练和性能评估。数据集按train/val目录组织，训练集13618张、验证集98张，共202MB图片数据，并附有与标注对应的classname.txt，方便直接替换到YOLO等框架中进行训练。资源包共2000个文件，以JPG图片为主（1994张），同时包含4个json标注文件和说明文档，整体压缩包约844.66MB，解压后目录结构清晰，便于按类别检索使用。目前已有381人浏览学习，适合想要快速上手YOLO花卉识别、进行模型迭代验证的开发者。 最近在给一个园艺类项目做视觉识别方案，需求是能判断画面里的花是什么品种。一开始团队有人提议直接上图像分类，认为鲜花这种目标形态规整，分类网络就够用。结果真实场景一跑就露馅了：花束里好几朵花叠在一起、叶片遮挡、光线角度千奇百怪，图像分类只能给整张图一个标签，根本无法区分“图里有玫瑰也有郁金香”这种多目标情况。最后我决定用 YOLO 做目标检测，从零构建了一套鲜花分类数据集，完成标注、格式转换、训练和调优。这篇文章就把整套流程完整拆开讲清楚。
这篇内容不是单纯丢给你一个训练命令，而是把数据集从无到有的完整链路都过一遍：类别怎么定、图片怎么清洗、标注规范是什么、VOC 格式怎么转成 YOLO 的 txt、data.yaml 里每个字段怎么填、训练参数为什么这样设，以及我实际踩过的坑。无论你是第一次用 yolov8 训练自己的数据集，还是已经跑通过但被 mAP 卡住，这篇都能给你一些可落地的参考。
1. 项目整体设计与鲜花分类方案取舍
1.1 为什么是目标检测而不是图像分类
先聊一个核心问题：鲜花识别到底该用分类网络还是检测网络。单独一朵玫瑰怼在画面正中间，用 ResNet 做分类完全没问题，但实际使用场景不可能这么干净。我采样的花束、花田、花盆场景里，经常一朵花挨着一朵花，前后遮挡，有的花只露半个花冠。分类网络给整张图打标签，遇到这种混合场景直接就懵了。
目标检测网络输出的是“检测框 + 类别 + 置信度”，一张图里检测出几个目标就输出几个结果。同样是花束图片，YOLO 能同时给出玫瑰、百合、满天星各自的位置和类别，这对后续做计数、定位、筛选很有用。在工程落地层面，YOLO 家族的部署生态也最成熟，训练完导出 ONNX 或者 TensorRT 都很方便，边缘设备跑起来兼容性也好。所以方案最终定为：基于 YOLOv8 训练一个鲜花检测模型。
1.2 类别设计与数据规模评估
类别数量需要克制。一开始有人建议把玫瑰细分成红玫瑰、白玫瑰、粉玫瑰，我直接否了。细分类会带来两个问题：一是标注成本成倍上升，二是相近颜色类别之间的类间距离太小，模型很容易混淆。第一版只定 6 个差异明显的类别：rose（玫瑰）、sunflower（向日葵）、tulip（郁金香）、chrysanthemum（菊花）、lily（百合）、hydrangea（绣球花）。
数据规模方面，每类收集了大约 850 到 900 张图片，总计约 5200 张。这个数量看起来不多，但足够验证 pipeline 是否跑通，也足够决定是否值得继续扩大数据量。实际标注出来的目标框总数在 3.2 万个左右，平均每张图 6.1 个目标。有一个数字值得关注：混合场景（一张图包含多种花）占比做到了 40% 左右，纯单花特写控制在 60%，这是为了让模型更早接触真实推断时的场景分布。
2. 数据集构建：采集、清洗与人工标注全流程
2.1 图像采集渠道与清洗标准
鲜花图片的获取渠道主要是三个：公开开源数据集（注意看许可证，尽量用 CC0 或允许商用的来源）、高清图库下载、自己拍摄补充特定场景。这里有个很重要的原则：先确定目标场景再去找数据。如果最终要部署在户外花园，就不要大量使用纯白背景的棚拍图。我当时发现下载的很多图片都是摄影作品，背景虚化严重，花占画面比例极大，这类图比例一旦过高，模型在密集场景下的表现会明显变差。
清洗环节我至少筛掉了 20% 的原始图片，标准很明确：模糊的不要、带大面积水印的不要、滤镜过重的不要、花朵占比低于 10% 的不要、目标被遮挡超过 80% 的不要。还有一个容易忽略的点：检查图片的 EXIF 方向信息和通道数。我从某个渠道下载的一批图片是 RGBA 四通道，还有少量是灰度图，不处理会导致后续训练报错或者读取异常。
2.2 标注工具选型与标注规范
标注工具我试过 LabelImg 和 X-AnyLabeling。LabelImg 是经典方案，界面简单，但纯手动框选效率太低。X-AnyLabeling 自带了一些预标注模型，可以先用模型自动标一遍，人工再修正，5000 多张图能省下不少时间。如果团队预算充足，Roboflow 的在线标注也值得考虑，它支持团队协作和格式转换，但数据出网这件事需要评估。
标注规范直接决定模型能学到什么，这里必须定死规则：
- 标注对象以“可见的花冠/花序主体”为准，叶片和花茎不要框进去，除非花茎是花朵不可分割的一部分。
- 被遮挡面积超过 50% 的花朵不标，避免大量半截目标干扰学习。
- 极小目标（长边小于图片尺寸 3% 的目标）不标，因为 640 分辨率下这类目标对训练贡献很小，反而增加标签噪声。
- 矩形框贴近花朵边缘，留 2 到 3 像素的余量即可，不要框一大片背景。
这套规则看起来简单，但真到了密集花束图就知道有多重要。没有规范的时候，我一度把叶片误框进目标，模型训完对叶子也有响应，误检率飙到让人崩溃。
2.3 标注格式转换：从VOC到YOLO
X-AnyLabeling 默认导出的是 VOC 格式（XML 文件），而 YOLO 需要的是每张图对应一个 txt 文件，每行是“class_id x_center y_center width height”，坐标都归一化到 0 到 1。这个转换逻辑不复杂，但批量处理时容易出幺蛾子，我写过一个 Python 脚本处理，顺手做了三项检查：坐标是否越界、类别 id 是否超出类别数、是否出现空标注文件。核心代码长这样：
import os import xml.etree.ElementTree as ET def convert_voc_to_yolo(xml_path, out_txt_path, class_list): tree = ET.parse(xml_path) root = tree.getroot() img_w = int(root.find('size/width').text) img_h = int(root.find('size/height').text) lines = [] for obj in root.findall('object'): cls_name = obj.find('name').text if cls_name not in class_list: continue class_id = class_list.index(cls_name) bbox = obj.find('bndbox') xmin = float(bbox.find('xmin').text) ymin = float(bbox.find('ymin').text) xmax = float(bbox.find('xmax').text) ymax = float(bbox.find('ymax').text) # 归一化到 0~1，并转换为 center_x, center_y, width, height center_x = ((xmin + xmax) / 2) / img_w center_y = ((ymin + ymax) / 2) / img_h box_w = (xmax - xmin) / img_w box_h = (ymax - ymin) / img_h lines.append(f"{class_id} {center_x:.6f} {center_y:.6f} {box_w:.6f} {box_h:.6f}") with open(out_txt_path, 'w') as f: f.write('\n'.join(lines))转换完必须做一次可视化验证，把标注框画回原图上人眼抽查。这一步看起来笨，但能发现很多格式上看不出来的问题，比如归一化公式写错导致框偏移、类别映射错位导致玫瑰被标成菊花。我抽查了约 300 张图，真的抓到了两三处批量转换逻辑 bug。
3. 数据组织与YAML配置：训练前的最后一步
3.1 数据集目录结构
YOLO 训练对目录结构有约定俗成的规范，虽然不同版本有些差异，但基本骨架是一致的。我用的目录结构如下：
flowers-dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yaml训练集、验证集、测试集按 8：1：1 划分，划分时注意一件事：同一来源、同一场景的连续帧图片要一起放同一边，避免数据泄露。如果视频抽帧得到的图片被随机划分成 train 和 val，模型在 val 上的成绩会虚高，部署到真实场景就露馅。
3.2 data.yaml里到底写了什么
data.yaml 是 YOLO 训练的数据入口，很多人在这里栽跟头。字段很简单，但 path 的写法我特意提醒一下：最好写相对路径，相对于 yaml 文件所在目录。我一开始写的绝对路径，后来项目从服务器拷到本地，路径全变了，挨个改起来很烦。正确写法示例如下：
path: . train: images/train val: images/val test: images/test nc: 6 names: ['rose', 'sunflower', 'tulip', 'chrysanthemum', 'lily', 'hydrangea']注意 nc 和 names 的顺序必须对应，names 列表的索引就是类别 id，标注文件里的 class_id 是数字，数字对应到这里的名字。很多训练后推理出错的问题，都出在训练时和推理时的 names 顺序不一致。
4. YOLO环境配置与训练执行
4.1 环境准备：显卡、驱动与框架版本
训练环境我用的是 Ubuntu 22.04 + Python 3.10 + PyTorch 2.1 + CUDA 11.8，显卡是 RTX 2080 Ti。Ultralytics 的 YOLOv8 安装很简单，pip install ultralytics就完了，但 PyTorch 和 CUDA 版本必须匹配。
这里要专门回应一个热词里的高频问题：AMD RX 580 显卡能跑 YOLO 吗，需要 CUDA 吗。实测结论是：能跑，但很折腾。RX 580 的 8GB 显存版本跑推理没问题，训练也能跑，但 YOLOv8 官方生态基于 CUDA，AMD 显卡要借助 ROCm 或者 DirectML 适配。ROCm 对 RX 580 这种老架构的支持不够友好，很多算子缺失，跑训练时可能报“operator not implemented”。如果手里只有 RX 580，建议先用 CPU 跑通小数据集验证流程，然后考虑换成 N 卡做正式训练。这不是 A 卡不行，是 YOLO 这条技术栈的默认路径就是 CUDA，没必要跟自己过不去。
4.2 训练参数到底怎么调
训练脚本我直接给了最常用的命令行形式：
yolo detect train data=flowers.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16 device=0每个参数都值得细说。model 选了 yolov8s.pt，是在速度和精度之间取的平衡点。YOLOv8 模型从 n、s、m、l、x 依次增大，n 最快但精度低，x 准确但推理慢。鲜花检测不算复杂任务，s 级足够，训练速度也快。我用 2080 Ti 单卡，batch=16 时显存占用约 7GB，比较安全。如果显存低，就调小 batch，比如 8，再把 imgsz 从 640 降到 512，属于用速度换显存。
epochs 我设了 100，同时开了早停，patience=15。早停的作用是当验证集指标连续多个 epoch 不提升就自动停止，避免白白浪费时间。实测这个数据集大概在第 70 个 epoch 就收敛了。还有一个参数容易忽略：mosaic。训练前 10 个 epoch 建议开启 mosaic 增强，但最后 10 个 epoch 要关掉，否则模型学到的目标分布和真实场景有偏差。Ultralytics 默认的配置会在训练最后自动关闭 mosaic，这也就是为什么默认参数表现稳定的原因之一。
4.3 训练过程看哪些指标
训练时我主要盯三个指标：box_loss、cls_loss、dfl_loss 三条曲线，以及每个 epoch 结束后的 mAP50、mAP50-95。损失曲线要平滑下降，如果有大幅震荡，优先怀疑学习率过大或者标签噪声严重。mAP50 和 mAP50-95 是两回事，mAP50 只算 IoU 阈值在 0.5 时的精度，通常容易刷到很高，mAP50-95 是多个 IoU 阈值的平均，更苛刻，也更能反映检测框的贴合度。
我训练的最终结果是 mAP50 约 0.94，mAP50-95 约 0.82，对这个数据规模来说算不错的了。要注意一点：mAP 高不代表部署效果一定好。mAP 是全局指标，具体到某个类别可能差异很大。我每次都单独打印每个类别的 AP 值，发现郁金香和百合这两个类别 AP 偏低，原因是它们的颜色和形状在某些光影下太像了，后面针对性地补了一些侧拍和逆光的样本才拉上来。
5. 常见问题与排查技巧实录
5.1 损失不降、震荡怎么办
训练前 20 个 epoch 损失曲线不下降，这是最常见的问题。先检查学习率，YOLOv8 默认 lr0 是 0.01，配合 warmup 机制一般没问题，但如果数据集很小，初始学习率可能偏大，可以把 lr0 降到 0.005 再试。另一个原因是标签噪声过大，建议用 2.3 里的可视化脚本把全部训练集的标注框画出来，连续翻 100 张图基本就能发现问题。最后还有一个容易忽略的点：类别不平衡。如果 rose 有两千个框，hydrangea 只有三百个框，模型会倾向预测 rose。解决办法不是简单删数据，而是给 hydrangea 加数据，或者给少样本类别加大 loss 权重。
5.2 漏检误检的调优顺序
漏检和误检的处理优先级完全不同。漏检优先查图像尺寸和目标大小：imgsz 640 下小花朵本来就难学，可以试 imgsz 960（显存够用的话），或者给这类小目标单独补一批特写图。误检则优先查背景相似性：如果模型把绿色叶片识别成菊花，说明训练样本里菊花大多带绿叶背景，模型学了背景而不是花本身。我当时的处理是把菊花样本里的背景多样性拉高，加上随机裁剪增强，误检率明显下降。
如果漏检问题在调参后还是解决不了，我建议换用 YOLOv8-seg 实例分割模型。分割模型输出的是像素级掩码，对遮挡目标和密集目标的建模能力比纯检测框强一个量级。代价是标注成本高不少，需要画多边形。项目如果对精度有硬性要求，预算又够，这一步值得投入。
5.3 标注与格式相关的“隐形坑”
我踩过最隐蔽的坑是空标签文件。有些图片经过清洗后一张图里没有有效目标，但图片本身还在 images 目录下，labels 目录里没有对应的 txt。训练时这会导致警告甚至崩溃。处理方式是写脚本扫描所有 images 下的文件，检查 labels 下是否有同名 txt，没有的直接从训练列表里剔除。
还有一个坑是关于多类别映射的。我从公开数据集整合了一批现成标注，来源 A 把鸢尾标成 iris，来源 B 同一个类别标成 iris_flower，合并时如果没有统一字典，模型会把同一个东西当两个类别学，大概率训废。合并任何来源的数据前，先统计全部标签名，建好统一的映射表再转换。
6. 实操心得与后续扩展
6.1 我的几个核心体会
这套数据集从采集到训练完毕，折腾了大概三周。我的核心体会是：数据质量永远大于模型选择。中间有一版我换成 yolov8m，以为更大模型能提升效果，结果 mAP 只涨了 0.8%，反而推理时间翻倍。后来把精力放在清洗噪声标注和补充困难样本上，同样的 yolov8s 直接涨了 4%。另一个体会是要有数据版本意识。每次清洗规则变更，我都会把数据集按日期打标签存档，出了问题能快速回溯，不会出现“明明上周效果很好，这周重训就崩了”的尴尬局面。
6.2 后续还能怎么玩
这个项目后续还有很大的扩展空间。当前只做了检测，可以继续做实例分割细化，或者加一个跟踪模块实现视频流里的多花计数。如果对推理速度敏感，可以蒸馏一个小模型到 yolov8n，部署到树莓派或者手机端。数据侧也可以增加花期的时序变化，同一个花在不同季节的形态差异很大，目前的模型主要集中在盛花期，如果目标是全年可用，还需要收集花苞期和凋谢期的样本。根据我个人经验，做这类垂直场景模型，不要一开始追求大而全，先把一个季节跑通、跑稳，再逐步扩数据，这条路走起来才踏实。
本文还有配套的精品资源，点击获取
