水稻病害检测实战：YOLO+VOC数据集解析与训练避坑指南

简介：面向水稻病害检测场景的YOLO+VOC格式数据集，共3355张田间水稻图像，含Hispa、Healthy、LeafBlast、BrownSpot四个类别，标注总框数3358个，其中健康叶片1489框、叶瘟病779框、Hispa 565框、褐斑病525框。每张图片均提供Pascal VOC格式XML与YOLO格式TXT两种标注，使用labelImg按矩形框规则绘制，可直接用于目标检测模型训练、验证与评估。压缩包内共2000个文件，以XML标注文件为主（1999个），另含1个使用授权说明，整体大小约617.7MB，便于批量下载与解压。目前已有810人学习，适合从事农业病害识别、智慧植保的算法工程师或研究人员快速获得规范标注数据，减少人工标注成本。数据集仅保证标注合理准确，不附带模型训练精度承诺。 近几个月一直在折腾水稻病害的视觉检测，模型调参改结构固然重要，但真正把我劝退过好几次的，反而是数据本身。今天借着手头这份“水稻病害数据集YOLO+VOC格式3355张4类别”的压缩包，把从数据结构、格式转换到训练排错的全过程复盘一遍。这套数据的核心价值一句话就能说清：省掉了从田里拍图、筛图、手动标框这些最耗时的工作，拿到手可以直接喂给YOLO系列训练，同时对VOC系工具链（比如LabelImg、标注转格式脚本）也完全兼容，适合刚入坑农业AI、做毕业设计或者搞植保无人机识别的朋友直接拿来当起点。

1. 这份数据集能解决什么问题——拆解名称背后的信息

先把压缩包名称里的信息拆开看。3355张图片、4个类别、同时提供YOLO和VOC两种格式，这三点基本决定了它的使用场景和上限。很多人拿到数据集后第一反应是赶紧跑训练，但忽略了一个关键问题：这份数据到底是为了让你“跑通流程”，还是为了让你“训练出能上线的模型”？我建议把这两种诉求分开对待。

1.1 3355张图片的真实体量

3355张图片在农业病害检测里不是小数目。自己去田里拍的话，单次调研可能需要跑好几个生长周期，每片试验区要覆盖不同角度、不同光照、不同病情严重程度，拍完还要删掉大量虚焦、重复、背景杂乱的照片，真正能留下的有效样本可能不到三分之一。所以3355张成体系的图片，背后对应的采集成本远比数字看起来更高。

另一个容易被忽略的点是：3355张图片不等于3355个目标。水稻病害尤其是稻瘟病、纹枯病这类，一张叶片上可能同时出现多个病斑，每张图标注后贡献的实例数可能是3到10个不等。这样算下来，实际参与训练的实例数量可能接近甚至超过一万个，对YOLO这类anchor-based或anchor-free的检测器来说，这个规模已经足够训练出一个具备基础泛化能力的模型。

1.2 4个类别通常指哪几个

名称里只写了4个类别，没有展开具体列表。根据国内水稻病害检测的常见数据集配置，这4个类别大概率落在稻瘟病、纹枯病、稻曲病、白叶枯病这几个高发病害上，覆盖了水稻生长过程中从叶部到穗部的主要病害类型。不过这里必须说一句：拿到压缩包后第一件事就是打开类别配置文件确认，不要想当然按自己的认知去套。

数据集里的类别名可能是英文缩写、拼音或者中文，比如rice_blast、sheath_blight这类，也可能是“稻瘟”“纹枯”这种简写。无论如何，最终做训练前都要统一映射成YOLO需要的类别索引。这一步看起来不起眼，但一旦类别顺序和训练配置对不上，后面所有结果都会错位，这个坑我放在第四章详细讲。

1.3 适合谁直接用这份数据

如果你的情况符合下面任意一条，这份数据可以直接用：

• 刚接触YOLO目标检测，想用真实业务数据而不是COCO这种通用数据跑一遍完整流程；
• 做农业方向毕业设计，需要一套干净、成体系的数据集来训练和验证算法；
• 在搞植保无人机或田间监测设备，需要先做病害识别的可行性验证；
• 想对比YOLO各版本（v5、v8、v11）在小目标检测上的效果差异。

反过来，如果你已经有大量自采的真实田间数据，只是想补充一些病害样本，这份数据可以作为预训练或数据增强的补充语料，但不建议作为唯一数据源，因为病害区域差异和拍摄设备差异可能会让模型产生严重的域偏移。

2. YOLO与VOC两种格式的分工与互相转换逻辑

标题里同时标注了YOLO和VOC两种格式，这其实是很多公开数据集发布者的惯例做法。原因很简单：标注工具和生产环境的数据格式往往不一致，给两种格式等于给使用者省去了中间转换的麻烦。但理解两种格式的底层逻辑，你才能在自己造数据时不用依赖别人的转换脚本。

2.1 两种格式的核心差异

VOC格式本质是XML文件，每一个目标用一个bndbox标签描述，里面的坐标是真实的像素坐标，也就是左上角x、左上角y、右下角x、右下角y，这些值直接取决于图片的宽高。XML结构的可读性很强，用文本编辑器打开就能看出每个框标在哪、类别是什么。

YOLO格式则完全不同。它用的是txt文件，每一行对应一个目标，结构是“类别ID 中心点x 中心点y 宽度 高度”，并且这四个数值全部做了归一化处理，取值范围在0到1之间，除以的是图片本身的宽和高。这样做的好处是：同一个标注文件，无论输入图片是640×640还是1280×1280，都能直接使用，不需要根据图片尺寸重新换算坐标。训练框架加载标注时也不关心图片的真实分辨率，只要txt数据和图片对应即可。

用表格看更直观：

2.2 为什么数据集要同时给两种格式

因为标注工具链和训练框架分别是两套生态。你打开LabelImg，默认导出的就是VOC格式的XML，方便人工检查和二次修正；但你喂给YOLO训练时，代码读取的是txt格式的标签，OCR的也是txt。如果数据发布者只给VOC，新手上来就要自己写转换脚本，一旦坐标公式写错，整个训练全废。而只给YOLO，又没法方便地用VOC生态的工具做可视化质检。

所以这份数据集同时提供两种格式，本质上是降低门槛：你把压缩包解压之后，VOC格式的标注可以用于质检和审计，YOLO格式的标注直接进训练流程，两边互不干扰，也不需要手工转换。

2.3 坐标换算公式与一个极简校验脚本

如果你以后要自己标注数据，或者需要从VOC转YOLO，核心公式其实只有四条。假设图片宽度为W，高度为H，VOC框的坐标为(xmin, ymin, xmax, ymax)：

• 中心点x：(xmin + xmax) / 2 / W
• 中心点y：(ymin + ymax) / 2 / H
• 框宽度：(xmax - xmin) / W
• 框高度：(ymax - ymin) / H

这四条公式把像素坐标转换成0到1之间的相对值。反过来，从YOLO转VOC，只需要把乘除方向掉转，并注意像素坐标要clip到图片边界内。

写一个极简的校验脚本很实用，用来检查转换后的标注是否越界：

import os def validate_yolo_labels(label_dir, img_w=640, img_h=640): for filename in os.listdir(label_dir): if not filename.endswith('.txt'): continue path = os.path.join(label_dir, filename) with open(path, 'r') as f: for line in f: parts = line.strip().split() if len(parts) != 5: print(f'[格式错误] {filename}: {line}') continue cls, cx, cy, w, h = parts cx, cy, w, h = map(float, (cx, cy, w, h)) if not (0 <= cx <= 1 and 0 <= cy <= 1): print(f'[中心点越界] {filename}: {line}') if w <= 0 or h <= 0 or w > 1 or h > 1: print(f'[宽高异常] {filename}: {line}') print('校验完成') if __name__ == '__main__': validate_yolo_labels('labels/train')

当时我跑这个脚本，真就揪出了几个中心点坐标大于1的脏标注，不查的话模型训练时这些框会直接给自己加噪声。

3. 开跑前必须完成的边界框可视化与目录检查

数据集到手，千万不要直接解压丢给train.py就跑。我见过太多人因为跳过这一步，训练到一半才发现图片和标签对不上，白白浪费十几个小时。这一节列的都是我自己踩出来的强制检查项。

3.1 检查目录结构是否满足YOLO要求

YOLO各版本的官方代码对数据集目录有一套约定俗成的组织方式。这份数据集如果解压后自带images和labels两个大目录，那大概率路径结构比较规整，但你还是需要确认图片和标签的文件名一一对应。一个典型的目录结构如下：

dataset/ ├── images/ │ ├── train/ │ │ ├── rice_blight_001.jpg │ │ └── rice_blight_002.jpg │ └── val/ ├── labels/ │ ├── train/ │ │ ├── rice_blight_001.txt │ │ └── rice_blight_002.txt │ └── val/ └── rice.yaml

一个很常见的坑是：图片是.jpg，标签是.txt，但文件名中间多了空格或大小写不一致，比如Image_001.jpg对应image_001.txt，在Windows下可能不敏感，但在Linux服务器上直接找不到文件，Visualize的时候一片空白。

检查方法很简单，写个脚本比对两个目录里的文件名前缀，把差异项打印出来。

3.2 可视化边界框是成本最低的质检方式

我自己最喜欢的质检方式是直接在图片上画矩形框，肉眼过几十张。这一步能把大多数VOC转YOLO过程中的坐标系错误、类别标签错位、框和病害区域严重不贴合的问题暴露出来。

如果你用的是LabelImg，直接打开XML看框的位置最直观。如果你用的是YOLO格式，建议先装一个开源的可视化脚本，从txt读取坐标，反算回像素坐标，然后用OpenCV画框。重点看两类情况：一是框是不是把整个病斑区域圈进去了，二是同一张图上不同类别的框是否有大量重叠。水稻病害里病斑通常比较小，如果框明显偏大、把整个叶片都包进去了，那这个数据集的标注精细度就要打个问号。

提示：可视化检查抽样的数量不要低于50张，并且要涵盖不同光照、不同病情严重度的图片。只挑前几十张看的话，很容易被视觉惯性欺骗。

3.3 类别映射与数据集配置文件

这一节直接上代码。YOLOv8及以上版本使用YAML文件描述数据集配置，我拿这份数据写了一个标准示例：

path: ./dataset train: images/train val: images/val names: 0: rice_blast 1: rice_sheath_blight 2: rice_false_smut 3: rice_bacterial_leaf_blight

注意names里的索引顺序必须和txt标签第一列的数字完全对应。如果数据集的txt里写的是0、1、2、3，而你的yaml里配的是1、2、3、4，训练过程不会报错，但模型会把所有类别都识别成错位的结果，比如把真正的稻瘟病输出成纹枯病。这种错误最坑，因为loss曲线看起来完全正常，直到测试才发现全乱了。

3.4 训练环境的一个现实问题：AMD显卡能不能跑

热门问题里反复出现AMD 580显卡能不能跑YOLO，结合这份数据集说下结论：能跑，但要注意环境选择。YOLOv8官方对N卡CUDA支持最完善，NVIDIA显卡在显存较小的情况下也能通过降低batch size训练。AMD显卡在Windows下可以借助DirectML后端跑ONNX格式的YOLO，在Linux下可以尝试ROCm，但遇到性能瓶颈的概率不小。如果是刚开始跑这套水稻病害数据，我更建议先用云服务器或者朋友的N卡跑通一遍流程，再考虑本机A卡的部署优化问题，不要卡在环境配置这一步消磨信心。

4. 训练中绕不开的坑：类别错位、小目标漏检与指标误读

前面准备工作做完，训练本身反而相对简单，多数YOLO版本直接一条命令就能开跑。真正耗时间的从来不是训练命令，而是各种隐藏的问题。我把高频踩坑场景整理了一下，这些基本覆盖了用这份数据能被绊倒的大部分位置。

4.1 类别编号错位导致“训练正常但全预测错”

前面提过类别索引错位的问题，这里展开说一下。我实际遇到过一次：别人的数据集txt里类别编号是1到4，我建yaml时习惯性写了0到3，结果训练loss正常下降到0.05以下，但在验证集上所有类别都被错误识别，最后检查发现是编号整体偏移了一位。出现这种问题时，损失曲线和mAP曲线都非常漂亮，很容易骗过新手。

排查方法很简单：训练完成后随机抽出几张验证图片，用模型推理一次，把预测结果和真实标签对比。如果出现“真实类别是0，预测大概率是1”这种系统性偏移，十有八九是类别索引错位，先检查数据集的类别顺序，再检查yaml文件。

4.2 小目标密集场景下的漏检问题

水稻病害目标有三个特征：小、密、边界模糊。一张叶片上的病斑可能只有几十个像素，YOLO在训练时对这类小目标天然不友好，尤其是下采样倍数较大的版本。如果在验证集上发现大量漏检，先不要急着换更大的模型，优先检查锚框尺寸和训练分辨率。

这个数据集如果是原始图片，分辨率可能有大有小，直接用640×640训练有风险。我的建议是把图片先统一到合适尺寸，或者用YOLO自带的letterbox机制处理，同时把imgsz参数适当调高到960甚至1280，看看小目标召回率有没有改善。如果显存吃紧，batch size可以降到8甚至4，用训练时间换精度。

4.3 类别不平衡与误检处理

4个类别在自然环境下出现的频率并不均匀，比如稻瘟病可能比稻曲病多很多。训练出的模型往往在样本量大的类别上表现好，样本少的类别上精度差。处理方式有两个思路：

第一个思路是数据增强。对样本少的类别做针对性增强，比如对包含该类别的小图块做随机旋转、亮度扰动、Mosaic增强，但注意增强幅度不要大到改变病害的基本形态特征。

第二个思路是调整损失权重。YOLOv8的class loss权重可以根据类别分布调高，或者用focal loss缓解难易样本不平衡。我在实际操作中发现，对样本量少的类别增加阈值调整比单纯堆数据更有效，具体做法是推理阶段把该类别对应的置信度阈值调低，减少漏检。

4.4 看懂指标再下结论

很多人看到终端输出mAP50=0.85就觉得很好了，但mAP50高不代表能落地。农业场景里更关心的是召回率，也就是真实病斑有多少被找出来了。

建议训练结束后重点看PR曲线和混淆矩阵。PR曲线能反映不同置信度阈值下的精度与召回率权衡，混淆矩阵能直接告诉你哪个类别之间经常互相误判。比如纹枯病和稻瘟病在颜色和纹理上接近，混淆矩阵里这两个类别之间的数值偏高，那就要考虑补充更多区分度高的样本，或者调整类别定义。

对于水稻病害检测，我建议优先关注Recall，因为漏检一个病斑的代价通常比误检一个非病斑区域更高。

5. 实际项目里这份数据还能怎么用

跑通训练只是开始，面向真实项目时这份数据还有几种进阶用法，可以把它从“练手数据集”升级成“项目基线”。

5.1 迁移学习：用预训练权重缩短收敛时间

不要每次都从随机初始化开始训练。用YOLOv8的官方COCO预训练权重作为起点，把分类头替换成自己的4类，然后在这份水稻病害数据上微调，可以明显加快收敛速度。实测下来，同样训练100轮，从COCO权重出发的模型在第30轮就能达到从零训练70轮的效果，而且泛化能力通常更好。

命令参考（YOLOv8风格）：

yolo detect train data=rice.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16

这里的model参数既写入了预训练权重路径，也写入了网络结构。如果不想要预训练，改成yolov8s.yaml，但它会从头训练，除非你有特殊需求，否则不推荐。

5.2 合并自采数据进行增量训练

数据集的一个潜在问题是不一定覆盖你部署区域的稻种和拍摄角度。比如你的监控设备装在大田里，视角是俯视，而这份数据集很多图可能是手持设备近距离拍摄。最好的方案是用这份数据做冷启动，然后采集少量自己场景的数据，先标注几百张，把模型在新场景上fine-tune一遍。这样既避免了从零标注的费时费力，又能解决域偏移问题。

5.3 部署阶段的注意事项

模型训练好只是第一步。落地到无人机或摄像头端侧时，一般要把PyTorch模型导出为ONNX再转成TensorRT或RKNN。这时候注意两点：一是导出前把训练时的输入尺寸固定下来，避免动态shape带来额外开销；二是把模型输出的后处理逻辑（NMS等）确认清楚，不然在端侧推理时会出现矩形框数量不对的问题。

之前我做RK3588上的部署测试，导出模型时忘记固定imgsz，结果板子上推理一张图耗时翻了近一倍，后来强制batch=1和固定640×640输入，速度才恢复正常。

5.4 如果效果不够理想，先回查数据而不是换网络

我见过不少人在模型效果不理想时反复换结构、调参数，最后发现根源问题出在标注质量。借助这份数据集带来的经验，我现在遇到模型效果差的情况，会先做一次错误分析，把预测错误的结果可视化输出，看模型到底错在哪。如果发现大量漏检的其实都是早期病斑或极小尺寸病斑，那就回查数据集里这类样本的比例；如果发现某类别系统性误判为另一类别，就回查标注是否存在边界不清的问题。

做了几轮农业AI项目之后，我最大的体会是：数据集的质量直接决定了模型效果的绝对上限，模型结构只是在逼近这个上限而已。很多公开数据集看起来规模不小，但标注粗糙、类别混淆严重，实际喂进模型后效果很差，这时候花费力气优化模型不如踏踏实实清洗一遍数据。这套水稻病害数据因为同时提供了YOLO和VOC两种格式，我后续做数据质检、格式转换、预训练实验时都非常顺手，直接把很多需要手动写脚本的环节省掉了。

最后说一个小经验：无论你从哪个渠道获得数据集，第一版模型跑通后，可以把置信度阈值调低到0.3左右运行一次，把预测结果全部保存下来，挑出那些置信度低但预测正确的样本，找时间补充相似场景的图像。这个简单的操作，往往比更换任何大模型结构都更能提升真实的田间识别效果。希望这份复盘能帮你把数据循环起来，少走几步我之前走过的弯路。

本文还有配套的精品资源，点击获取