基于深度学习的农作物叶片病害检测系统（UI界面+YOLOv5+训练数据集）

做农业AI项目这几年，我最大的感受是：真正能落地到田间的视觉系统，往往不是算法最花哨的那套，而是把数据、模型、界面这三件事扎实拧成一股绳。今天想拆解的项目，是一个基于深度学习的农作物叶片病害检测系统，核心组件就是UI交互界面、YOLOv5目标检测模型，以及一套完整可用的训练数据集。这个项目能解决的问题很具体：农户或者农技人员拍一张叶子照片，系统就能在界面上框出病斑位置并给出病害类别和置信度，省去翻书比对、凭经验猜测的麻烦。

如果你正打算入门目标检测，或者想在农业方向做一个毕设、课题、竞赛项目，这篇内容会比较对胃口。我会把从数据集怎么整理、YOLOv5怎么调参训练，到UI界面怎么把模型包装成普通人能用的工具，这一整条链路里最关键的环节和踩过的坑都摊开来讲。

1. 项目整体构思：从农业需求到技术选型

1.1 为什么农田里的病害识别值得做成一件事

农作物病害是农业生产的头号威胁之一，叶片作为病害最先显现的器官，几乎是所有病害诊断的“第一现场”。但现实问题是，大部分种植户不具备植保专业知识，看到叶片发黄、长斑、卷曲，很难判断到底是真菌感染、细菌性病害还是虫害，更不知道用什么药、用多少量。

深度学习目标检测技术恰好能切进这个场景。它不需要手工设计特征，只要给足标注好的图像，模型就能自动学习病斑在颜色、纹理、形状上的分布规律。拿YOLOv5来做叶片病害检测，核心优势就两条：一是推理速度快，一张图在普通显卡上跑到几十毫秒级别，完全够用；二是精度在同类实时检测模型里处于前列，能满足病害识别这种对错检比较敏感的场景。

这个项目的定位不是发论文那种“刷精度”玩法，而是做成一款能打开就用的小系统。所以我在架构上定了三个关键词：数据规范、模型可用、界面友好。换句话说，最终交付的不只是一堆训练代码，而是一个带图形界面、能加载模型、能实时推理的完整工具。

1.2 模型选型：为什么是YOLOv5，而不是别的

老实说，2025年来看，YOLO系列已经出到v8、v11，甚至还有各种Transformer架构的检测器。那为什么我在这套系统里还是用YOLOv5？理由很实际：

第一，生态成熟度。YOLOv5的文档、教程、预训练模型、社区问答数量在目标检测框架里属于最丰富的梯队。真做一个项目，遇到报错能搜到答案，比模型结构新几版重要得多。

第二，硬件门槛低。YOLOv5s权重文件只有14MB左右，CPU上也能勉强跑推理，配上GPU就是流畅体验。农业场景的终端设备往往不是顶级配置，轻量模型才是王道。

第三，部署灵活。YOLOv5的PyTorch模型可以很方便导出成ONNX、TensorRT、OpenVINO格式，后期如果要把系统搬到Jetson Nano这类边缘设备上，路径清晰。

当然，如果你有更强的算力、追求更高精度，YOLOv8甚至YOLOv11也完全可以套用这套项目框架，训练数据格式是相通的。选YOLOv5的本质是选性价比，不是选最强者。

1.3 系统整体架构怎么搭

在动手写代码之前，先把系统的信息流理清楚：

图像输入（本地图片/摄像头） → UI界面 → 预处理 → YOLOv5模型推理 → 后处理 → 界面绘制检测框 → 输出结果（类别、置信度、数量）

整个项目分成两大模块。第一个模块是离线训练部分，包含数据集整理、YOLOv5训练、模型评估；第二个模块是在线推理部分，就是UI界面加载训练好的权重文件，对输入图像做检测并可视化。这两部分通过一个约定好的模型文件格式（.pt或者导出的.onnx）衔接起来。

界面层我选择PyQt5而不是Web前端，原因有三：一是Python生态下PyQt5开发桌面工具足够快，不需要额外起前后端服务；二是农业用户的使用习惯是双击打开、直接操作，桌面应用比浏览器输入网址更直观；三是PyQt5的信号槽机制和OpenCV的图像格式可以无缝配合，省去大量图像传输的序列化开销。

2. 训练数据集准备：模型效果的“地基工程”

2.1 数据集从哪来：公开数据集与实际采集的取舍

很多初学者拿到项目第一反应是去网上找一个现成数据集直接开训，这个思路没错，但要注意数据分布和实际场景的匹配度。

农业病害识别领域有几个常见的公开数据集：PlantVillage是叶片病害图像分类的经典数据集，包含多种作物的健康与患病叶片，但它大多是单叶、纯色背景的“标准照”，和田间复杂背景差异较大。AI Challenger作物病害数据集是国内比较早的大规模农业病害数据集，包含茄科作物等多种病害类别，图像分辨率较高。Kaggle上还有一些农作物病害检测竞赛数据集，部分已经带有目标框标注，适合直接训练YOLO模型。

我在这套系统里用的是“公开数据集为主、自采数据补充”的组合策略。公开数据保证基础类别覆盖，自采数据则用来提升模型在真实光照、复杂背景下的鲁棒性。用手机拍摄病害叶片时，尽量涵盖不同角度、不同光照、不同生育期，让模型见过的“世面”更广。

2.2 标注的规范与细节

目标检测模型的训练依赖于高质量的边界框标注。YOLO格式的标注文件是TXT文本，每行对应一个目标，格式为：

class_id x_center y_center width height

注意，这里的x_center、y_center、width、height都是相对图像宽高的归一化值，取值范围0到1。举个例子：一张1000x800的图像，某个病斑中心点像素坐标是(500, 400)，框宽200，框高150，那标注就应该是：

0 0.5 0.5 0.2 0.1875

标注工具有很多选择。LabelImg是老牌工具，基于Python + Qt开发，支持PascalVOC、YOLO格式输出，操作逻辑简单，适合小规模数据标注。LabelStudio功能更全面，支持图像分类、目标检测、分割多种标注类型，适合团队协作。我个人在小样本场景下更推荐LabelImg，因为它的快捷键设计很顺手，W键画框、D键下一张，一天标几百张也不累。

标注时有几个细节直接影响模型精度：

• 病斑边界模糊怎么办？我的经验是框稍微收紧一点，包含主要病斑区域即可，不要把整个叶子都框进去，否则类别特征会被稀释。
• 一个叶片上有多处病斑，需要逐个框出还是只框大的？取决于你的业务目标。如果要做严重程度评估，建议每个可见病斑都标注；如果只做病害识别，框出最大的1-3处代表性病斑也够用。
• 标注一致性比标注精细度更重要。同一个病害类别，不同标注员的理解可能有偏差，建议一个人负责到底，或者制定明确的标注规范文档。

2.3 数据增强：用“穷举法”提升模型泛化能力

疾病识别模型在实验室数据集上表现好、一到田间就拉胯，这个问题八成出在数据多样性不足。解决思路是数据增强——在不改变语义标签的前提下，对图像做多种变换，变相扩充训练样本。

YOLOv5自带的增强策略已经很强大，包括马赛克增强、随机仿射变换、HSV色域变换、水平翻转等。Mosaic增强的原理是把四张训练图片随机裁剪拼接成一张新图，这样模型在一个batch里能看到更多上下文信息，对小目标检测效果提升明显。HSV变换则是对色调、饱和度、明度做随机扰动，模拟不同光照环境下的叶片颜色变化。

除了代码层面的增强，我建议还可以做“物理层面”的增强：把训练图像做适度旋转、缩放、加模糊、加噪点，模拟手机拍摄时可能出现的各种退化情况。这不涉及额外工具，用OpenCV写个脚本批量处理就行。

2.4 数据集划分与目录结构组织

训练前，把数据集按比例划分为训练集、验证集、测试集。常见比例是8:1:1，也可以按实际样本量调整。YOLOv5要求的目录结构是：

dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yaml

data.yaml文件内容示例如下：

train: dataset/images/train val: dataset/images/val nc: 4 names: ['healthy', 'leaf_spot', 'rust', 'blight']

这里有个新手高频报错点：YOLOv5训练时会自动根据images目录查找同名的labels目录，路径关系必须严格匹配，否则会报“image not found”或“no labels found”的警告。另外，类别ID从0开始，data.yaml里names列表的顺序必须和标注文件里的class_id一一对应，一旦搞混，模型学出来的类别就是乱的。

3. YOLOv5模型训练全过程拆解

3.1 环境配置的版本坑

YOLOv5的环境配置在深度学习项目里算是友好的，主要依赖PyTorch、OpenCV、NumPy、Matplotlib等。我整理的配置步骤是：

# 1. 创建Python虚拟环境，避免依赖冲突 conda create -n yolov5 python=3.8 conda activate yolov5 # 2. 安装PyTorch（CUDA版本根据自己的显卡驱动选择） pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 3. 克隆YOLOv5仓库并安装依赖 git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt

这里最容易踩的坑是PyTorch版本和CUDA版本不匹配。装完以后可以用一句命令快速验证GPU是否可用：

python -c "import torch; print(torch.cuda.is_available())"

如果输出True，说明GPU环境正常。如果输出False，大概率是CUDA驱动版本过旧，或者安装的PyTorch版本不支持当前显卡。

还有一个小建议：YOLOv5仓库更新频繁，如果没有特殊需求，建议固定一个稳定版本，用官方tag切换，避免新代码带来的行为变化影响你的实验结果。

3.2 训练参数的选择与原理

训练模型不是把命令敲完就完事了，几个关键参数的选择背后都有讲究。

img（输入图像尺寸）：YOLOv5默认是640，即训练时会把图像缩放到640x640再送入网络。如果图像分辨率较高、病害目标较小，可以适当调大到960或1280，但显存占用会显著增加。我的建议是先试640，看小目标的检测效果再决定要不要放大。

batch（批大小）：受显存限制。直观地说，batch越大，梯度方向越稳定，训练收敛越平稳，但对显存要求越高。一般显卡显存6GB可以跑batch=16（YOLOv5s），12GB以上可以尝试batch=32或更大。如果显存不足但想用大batch，可以开启accumulate参数，用梯度累积模拟更大的batch。

epochs（训练轮数）：不是越多越好。我通常的做法是先用300轮看训练曲线，如果验证集损失在200轮左右已经开始上升（过拟合信号），就果断提前停止。YOLOv5的early stopping机制默认开启，它会跟踪最佳模型的mAP并自动保存，不用担心训练时间过长。

超参数文件：YOLOv5提供了hyp.scratch-low.yaml和hyp.scratch-high.yaml两组默认超参数。加大数据增强的幅度（如hsv_h、hsv_s、degrees），可以提升模型的泛化能力，但也会让训练更慢、更难收敛。初学者建议先用默认超参数跑通流程，再尝试超参数遗传进化算法，让模型自己“进化”出一组更优参数。

3.3 训练启动与结果解读

数据集和参数准备好后，训练命令很简洁：

python train.py --img 640 --batch 16 --epochs 300 --data dataset/data.yaml --weights yolov5s.pt --name crop_disease

训练过程会实时打印每个epoch的loss、精度、召回率、mAP等指标，同时在runs/train/crop_disease目录下保存训练曲线、混淆矩阵、验证集检测结果图等文件。

这里解释一下几个关键指标，很多人看训练日志一脸懵：

• box_loss：边界框回归损失，衡量预测框与真实框的偏差，越小越好。
• cls_loss：分类损失，衡量类别预测的准确程度。
• mAP@0.5：IoU阈值取0.5时的平均精度均值，这是目标检测最常用的指标，数值越大越好。mAP@0.5:0.95则是在0.5到0.95不同IoU阈值下的平均，标准更严格。

以我用公开数据集训练的一个4类别叶片病害模型为例，最终mAP@0.5能达到0.87左右，mAP@0.5:0.95大概在0.69。这个成绩做实际推理已经够用，但如果你发现mAP很低，不要急着调模型结构，先回去看一下训练数据的标注质量和类别数量。

3.4 训练常见问题排查

训练过程中最常遇到的几个问题：

Loss不下降：可能是学习率设置不当、数据标注错误、类别不平衡。先检查数据增强是否过强，再确认标注框是否贴合真实目标。

过拟合：训练集loss持续下降但验证集loss回升。解决方向：增加数据量、加强数据增强、引入预训练权重、减小模型复杂度。

显存溢出：OutOfMemory错误。把batch减小、图像尺寸调小，或者换用更轻量的模型变体。

类别不平衡：某些病害样本数量特别少，导致模型几乎学不到该类特征。解决思路是类别加权、复制稀少类别样本、或者用数据增强针对性扩充少数类的样本。

提示：训练日志不只是用来“看结果”的，它更是排查问题的第一手证据。养成每次训练完都看一眼result.png的习惯，比瞎猜问题根源高效得多。

4. UI界面设计与系统集成

4.1 界面功能规划：用户真正需要什么

很多类似项目的UI界面做一个“选择图片→显示检测结果”的简单流程就算交差了，但实际使用中，农户或技术人员需要的远远不止这些。

我在设计界面时把功能分成三个层次：

核心功能：选择本地图片进行病害检测，显示检测框、类别标签、置信度。这是系统的基本盘，任何操作都要围绕“快速、清晰”展开。

辅助功能：检测结果统计（各类别数量）、单张图像多病害并存时的高亮预览、检测结果导出（保存标注后的图片和检测报告文本）。农田病害往往不是单一发生的，一张叶片上可能同时有炭疽病和褐斑病，导出报告对后续配药很有价值。

扩展功能：摄像头实时检测、批量检测文件夹内所有图片。实时检测对帧率要求较高，建议用YOLOv5s模型并开启半精度推理；批量检测则适合处理大量田间采样照片。

4.2 PyQt5界面实现的关键代码结构

PyQt5的界面我用Qt Designer设计好布局再转成Python代码，手动微调。整体布局是左右结构：左侧控制区（按钮、参数显示、结果列表），右侧图像显示区（QLabel控件承载图像）。

核心检测逻辑代码如下：

import cv2 import torch from PyQt5.QtGui import QImage, QPixmap def detect_image(self, img_path): # 读取图片 img = cv2.imread(img_path) img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 模型推理 results = self.model(img_rgb) # 绘制检测框 rendered_img = results.render()[0] # OpenCV图像转QImage并显示 h, w, ch = rendered_img.shape bytes_per_line = ch * w qimg = QImage(rendered_img.data, w, h, bytes_per_line, QImage.Format_RGB888) self.image_label.setPixmap(QPixmap.fromImage(qimg))

这里有个性能细节要注意：拿results.render()直接绘制检测框虽然方便，但每次调用都会重新做NMS等后处理，批量检测时会有冗余开销。更高效的方式是访问results.xyxy[0]拿到原始的检测框坐标数据，自己用OpenCV的cv2.rectangle绘制。

import cv2 def draw_boxes(self, img, detections, class_names): for det in detections: x1, y1, x2, y2, conf, cls = det label = f"{class_names[int(cls)]} {conf:.2f}" cv2.rectangle(img, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) cv2.putText(img, label, (int(x1), int(y1) - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) return img

4.3 模型加载与推理性能优化

UI界面容易出现的“卡顿感”，大部分不是界面代码的问题，而是模型推理耗时太长导致事件循环被阻塞。实战中我有几招：

模型只加载一次。不要在每次检测时都执行torch.hub.load()或实例化模型，应该在界面初始化时加载一次权重文件并常驻内存。

推理放到子线程。PyQt5的界面线程（主线程）不能做耗时操作，否则窗口会无响应。正确做法是用QThread或QThreadPool把模型推理放到工作线程，推理完成后通过信号把结果传回主线程更新界面。

class DetectThread(QThread): result_ready = pyqtSignal(object) def __init__(self, model, img_path): super().__init__() self.model = model self.img_path = img_path def run(self): img = cv2.imread(self.img_path) results = self.model(img) self.result_ready.emit(results)

开启半精度推理。如果显卡支持，设置model.half()可以将推理速度提升接近一倍，显存占用也降低一半。CPU推理则不用开启，反而更慢。

导出ONNX加速。YOLOv5官方脚本支持一键导出ONNX模型，ONNX Runtime在CPU上的推理速度通常比PyTorch原生快不少。实测在一个i5处理器的笔记本上，YOLOv5s的ONNX模型推理一张640x640图像大概在200毫秒左右，已经满足交互需求。

4.4 界面风格与用户体验细节

UI界面的价值很大程度上体现在细节上。

字体和配色要照顾中老年用户。检测结果的类别标签不要用“Class 0”这种内部命名，直接映射为“稻瘟病”“褐斑病”这样的中文名称，置信度用百分比显示，比小数直观得多。按钮的文字尽量用“选择图片”“开始检测”“保存结果”这种动词引导式文案，避免使用“执行”“运行”这类偏工程化的词。

检测结果的展示除了画框，还应该在侧边栏用列表形式汇总：“检测到3处异常，其中XX病2处，YY病1处”，语气平实，不夸大不恐吓。如果检测结果为健康叶片，明确提示“未检测到明显病害特征，建议持续观察”，比单纯输出一个“健康”更符合实际农业场景。

提示：界面上的检测阈值不要写死，建议在界面上提供“灵敏度”调节滑块。默认置信度阈值0.25在多数场景下合适，但用户可以根据实际情况微调。这个功能在叶片病斑较小、特征不明显时特别好用。

5. 常见问题与排查技巧实录

5.1 典型报错速查表

5.2 从“能跑”到“好用”的三个经验

经验一：评测指标要贴近业务。官方mAP指标只能作为模型选择的参考，实际落地要关注的是“假阴性率”——漏检一个病斑，可能直接导致病害蔓延。我在项目里额外统计了在真实田块照片上的漏检率，发现模型对早期小病斑的漏检率偏高，于是把训练图像的输入尺寸从640提升到960，并针对性扩充了早期病斑样本，漏检率明显下降。

经验二：数据版本管理比模型版本管理更重要。模型可以反复训练迭代，但数据集一旦发生了标注修正、样本增删，追溯起来就会变得混乱。我的习惯是每次数据集更新都单独保存一个带日期版本的目录，并在训练日志里记录对应的数据集版本，这样出现精度回退时能快速定位是数据变化还是代码变化导致的。

经验三：界面的稳定性测试不能省。快速连续点击检测按钮、反复切换图片、杀进程重启，这些看似无聊的操作能把界面里潜在的崩溃问题暴露出来。特别是图像读取阶段，如果用户选择的文件路径包含中文、或者图片格式不是常规的jpg/png，都容易让OpenCV读取失败。因此我在代码里对图像读取做了异常捕获并给出友好提示，而不是程序直接崩掉。

5.3 模型部署延展：从桌面端到边缘设备

这个系统目前的形态是桌面应用，但如果真要到田间地头用，便携性就成了刚需。我后续尝试过把模型部署到Jetson Nano这类边缘设备上，思路大致是：先用TensorRT把YOLOv5的模型做定点量化加速，然后通过CSI摄像头采集实时画面，在板子上跑推理，并通过HDMI接口输出界面。实测YOLOv5s在Jetson Nano上可以跑到15fps左右，基本满足实时检测的需求。

需要提醒的是，边缘设备的算力比PC弱得多，模型量化后精度会有轻微下降，所以部署前一定要先在桌面端把模型的精度余量留足。另外，如果项目要部署到手机端，可以考虑转换成NCNN或MNN格式，但那就涉及移动端UI重写，工作量会大一个数量级。

6. 写在最后的一点心得

整套系统断断续续做了大概两个月，现在回过头看，最有价值的不是最终跑得通的模型，而是踩过的那一堆坑。数据标注的规范性、训练参数的合理性、界面交互的流畅性，任何一个环节掉链子，整体效果都会大打折扣。我也越来越确信一件事：做AI项目，尤其是做面向非技术用户的AI工具，技术只是下限，对场景的理解才是真正的上限。

最后再分享一个实用小技巧：YOLOv5训练完成后保存的best.pt模型，在通过torch.hub.load加载时，如果遇到本地模块导入问题，可以直接改用yolov5仓库自带的detect.py脚本做推理参照，它能帮你快速确认是模型本身的问题还是代码调用方式的问题。等项目跑顺了，再封装成自己的推理类也不迟。