基于YOLO11的水稻病害检测识别系统开发实战指南

今年毕业设计扎堆做深度学习目标检测的同学，十有八九会撞上“农作物病害检测识别”这个方向。我当初拿到“基于YOLO11的水稻病害检测识别系统”这个题目时，心里也没底：模型是开源的，数据集网上能搜到，但真正把一个能跑、能演示、能写进论文的系统做出来，中间隔着多少坑，只有亲手走一遍才知道。这篇分享没有教科书式的大道理，全部是实际推进项目的经验，覆盖数据、训练、部署、论文和答辩，希望能给正在做同类毕设的人一条能直接照走的路线。

1. 为什么选YOLO11做水稻病害检测：课题立意与方案权衡

1.1 毕设选题的底层逻辑：不是越前沿越好，而是越“完整闭环”越好

很多同学纠结选题是选“基于注意力机制的病害分类”还是“基于Transformer的检测”，我个人的看法是：本科或硕士毕设的评分核心，往往不是你有多少创新，而是你能否独立完成一个“数据—模型—系统—论文”的完整闭环。导师最想看到的是工作量饱满、各环节自洽、答辩时能清晰回答每一个技术选型的理由。水稻病害检测识别恰好具备这个条件：问题明确、场景集中、图像特征可区分，而且和智慧农业、粮食安全的行业趋势直接挂钩，讲起故事来也顺。

别急着把题目扩展成“多作物多病害智能诊断平台”，我见过太多人把范围铺大，最后数据不够、接口写不完、论文里全是空话。老老实实把水稻常见的几种病害——稻瘟病、纹枯病、白叶枯病、稻曲病——做深做透，就是一份体面的毕设。

1.2 检测模型的选型对比：为什么不是Faster R-CNN，也不是DETR

目标检测的主流路线无非三类：两阶段检测器、单阶段检测器、基于Transformer的检测器。我直接把三类的特点摆出来对比：

选择YOLO11，首先是因为它在公开COCO榜单上有不错的表现，尤其小型模型在算力有限的设备上推理很快，答辩演示时用笔记本也能跑出实时效果。其次是YOLO生态的工程化做得非常成熟，从数据准备、训练、验证到导出ONNX，几乎是一条龙服务，对毕设来说能省下大量无效工作时间，把精力留给数据质量和系统设计。

1.3 一个完整的水稻病害检测识别系统包含哪些模块

先说清楚一件事：毕设题目写的是“系统”，不是“模型”。如果只训练出一个模型然后画个pr曲线，那撑不起“系统”这两个字。

完整的系统至少包含四个模块：

1. 数据模块：原始图像采集、病害类别标注、数据集划分与增强
2. 模型模块：YOLO11的训练、验证、测试，保存最优权重
3. 推理模块：把训练好的权重封装成可调用的检测接口
4. 交互模块：Web界面或桌面界面，支持上传图片、摄像头检测、显示检测结果与防治建议

我后面会按这个顺序拆开讲。如果你时间有限，优先级是：模型 > 界面 > 论文。模型都不准，一切都白搭。

2. 水稻病害数据的获取与标注：这套系统80%的工作量

2.1 图像数据从哪来：公开数据集与自采的搭配策略

做检测系统的人最容易高估模型，低估数据。我实际统计了一下，整个项目周期里，数据清洗和标注花掉的时间远远超过训练调参。

水稻病害图像有几个来源渠道：

• 公开数据集：一些高校和农业科研机构发布过水稻病害图像集，可以在学术数据集平台上检索。要留意版权说明，论文里务必标注引用来源。
• 自采图像：如果你有条件接触农田，建议自己用手机拍一批。拍摄时注意俯拍为主，保证叶片占画面主体，背景不要过于杂乱。
• 网络图像抓取：网图作为补充，但要注意完清晰度和标注难度。

我的建议是“公开数据集打底 + 自采补充 + 网图增强”，每类病害的图像数量保证在300张以上，目标框（病斑或病叶）数量越多越好。数量太少，YOLO11再强也白搭。

2.2 标注规范：标病斑还是标叶片，一定要想清楚

这是新手最容易搞混的地方。水稻病害检测有两种标注思路：

• 标叶片级别：整片病叶画一个框，适合判断“这片叶子有没有病”
• 标病斑级别：叶片上的某个病斑画一个框，适合判断“哪里有病、病有多重”

我当时为了贴合“防治指导”的应用场景，选择标注病斑，这样检测结果能直接定位到病斑区域，系统展示时也更直观。但病斑级标注对框的贴合度要求高，不能把一大片健康组织也框进去。

标注工具我用的是LabelImg，它支持直接导出YOLO格式的txt文件，每行对应一个目标框：

class_id x_center y_center width height

这里的x_center、y_center、width、height都是归一化坐标（除以图像宽高后的0到1之间的浮点数）。比如图像宽800、高600，某个病斑框左上角在(200,150)、右下角在(500,400)，那么中心点就是(350,275)，宽高分别是300和250，最终写入txt的一行就是：

0 0.437500 0.458333 0.375000 0.416667

我见过不少同学没有归一化坐标，直接把像素值写进去，模型训练时loss直接飞掉。做完标注后，写个脚本扫描所有txt文件，检查坐标值是否都在0到1之间、类别ID是否越界、有没有空文件，这一步必须做。

2.3 数据集划分与增强：防止“作弊式”高精度

数据集划分是另一个大坑。一定按“图像”划分，而不是按“标注框”划分。举例来说，一张图片上有3个病斑，如果把其中2个划进训练集、1个划进验证集，那么验证集里的信息和训练集几乎一样，测出来的精度虚高，答辩时一旦被问到“训练集和验证集是否严格分离”，场面会很难看。

我采用的划分比例是8:1:1（训练：验证：测试）。数据增强方面，YOLO训练时会内置mosaic和仿射变换，但建议自己再补充HSV颜色抖动和随机翻转——水稻叶片在自然光照下颜色变化很大，增强后模型对阴天、晴天、黄色病叶的适应性会更好。注意一点：训练集增强，验证集和测试集保持原始图像，否则验证集指标失真。

3. 从训练命令到指标判读：把YOLO11跑起来的实操路线

3.1 环境版本组合与目录结构

环境这关能卡掉一半的人。我不建议自己从源码编译YOLO11，直接用官方封装好的库即可。比较稳的版本组合：

• Python 3.10
• PyTorch 2.x（根据显卡驱动选择对应的CUDA版本）
• ultralytics库（安装最新稳定版即可）
• OpenCV、matplotlib、pandas等常见依赖

建议新建独立的conda虚拟环境，不要在base环境里乱装包。当初我因为版本冲突跑了三天环境，后来发现重装一个干净环境只要20分钟。

数据集目录结构如下，train和valid下各含images和labels子目录：

dataset/ ├── train/ │ ├── images/ │ └── labels/ ├── valid/ │ ├── images/ │ └── labels/ ├── test/ │ ├── images/ │ └── labels/ └── rice_disease.yaml

data.yaml的内容：

path: dataset train: train/images val: valid/images test: test/images nc: 4 names: ["rice_blast", "sheath_blight", "bacterial_blight", "rice_black_streak"]

这里names的顺序必须和标注时的class_id完全一致，我见过同学改了类别顺序但没有重新生成标签，导致类别全部错位。

3.2 训练命令与关键参数

启动训练只需要一条命令：

yolo detect train \ --data rice_disease.yaml \ --model yolo11s.pt \ --epochs 150 \ --batch 16 \ --imgsz 640 \ --device 0 \ --patience 30

关键参数怎么选，我在实际训练后整理出下面这张表：

训练结束后，ultralytics会在runs/detect/train目录下输出best.pt和last.pt，还有一堆曲线图。我建议后续推理统一用best.pt，last.pt在训练后期不如中途最优的模型稳定。

3.3 训练过程的指标怎么看

很多同学训练完只看mAP一个数就完事，这不够。要会看三个阶段：

1. train/loss和val/loss曲线：如果训练loss持续下降、验证loss先降后升，就是过拟合的典型信号，早停机制会在patience轮后自动停止，这是好事。
2. metrics/mAP50和mAP50-95：mAP50是IoU阈值0.5时的平均精度，水稻病斑这种小目标场景下mAP50到0.8以上算不错；mAP50-95更严格，低一点正常。
3. 混淆矩阵和PR曲线：混淆矩阵能告诉你哪些类别互相容易认错。比如纹枯病和稻瘟病病斑颜色相近、形状相似，误检比例往往最高。

我在训练过程中观察到一个小规律：病斑较小的目标，在640分辨率下容易漏检。如果最终测试集mAP不高，可以先试试把imgsz提高到800重新训练，s模型在常见显卡上依然拖得动。

3.4 权重导出与部署格式选择

训练完成后，导出一个ONNX格式的权重文件，作为后续Web系统推理的“中间层”：

yolo export model=runs/detect/train/weights/best.pt format=onnx imgsz=640

导出ONNX之后，系统可以脱离原生的训练框架，只依赖ONNX Runtime推理，这样系统模块边界更清晰，答辩时也能解释：训练端和推理端解耦，工程上更合理。

4. 检测系统的推理链路与Web交互实现

4.1 推理链路的两种做法：懒人方案与稳妥方案

把模型权重部署到应用里，有两个思路：

• 方案A：直接用ultralytics库的API加载best.pt进行预测。几行代码就能跑通，适合快速演示，但对环境依赖较重。
• 方案B：导出ONNX后用ONNX Runtime加载推理，依赖更干净，速度更快，适合集成到Web服务。

我建议采用方案B的封装风格。核心推理代码大致是这样：

import cv2 import numpy as np import onnxruntime as ort session = ort.InferenceSession("best.onnx") input_name = session.get_inputs()[0].name def detect(image): resized, scale, pad = letterbox(image, (640, 640)) blob = np.expand_dims(resized.transpose(2, 0, 1), axis=0).astype(np.float32) / 255.0 outputs = session.run(None, {input_name: blob}) boxes, scores, class_ids = postprocess(outputs, scale, pad) return boxes, scores, class_ids

letterbox这一步很重要：训练时用的是640x640，推理时也必须把图像先等比缩放再填充到640x640，否则目标框坐标对不上，检测率会明显下降。很多人直接resize成640x640，造成图像变形，效果差了很多，调了半天模型，其实问题出在预处理上。

4.2 Web界面做什么功能、选什么框架

毕设检测系统不需要做得多花哨，功能围绕“能用、能演示、能截图写进论文”三点展开：

• 图片上传检测：用户上传水稻叶片图片，系统返回标注框、类别名、置信度、病斑面积占叶片比例等
• 摄像头实时检测：打开摄像头对叶片图像流进行逐帧检测，展示实时FPS
• 历史记录：保存最近检测记录，方便论文结果展示
• 防治建议字典：检测到对应病害后，给出简单的防治参考信息

后端框架我选的Flask，因为它轻量、上手快，代码量少，单文件就能跑起一个服务。如果对并发有要求可以考虑FastAPI，但毕设演示场景QPS根本不高，Flask完全够。

4.3 界面与推理服务的联动细节

有一个细节容易被忽略：如果你直接用Web框架的处理线程去跑推理，遇到推理时间稍长时整个服务会卡住。稳妥做法是把检测封装成一个独立函数，图片上传后先保存本地，再调用推理函数，结果以JSON形式返回给前端。

FPS的优化有两个思路：

1. 降低推理分辨率（例如从640降到416），检测速度会明显提升，但小病斑的召回率可能下降
2. 间隔抽帧检测，比如每3帧检测一次，中间帧直接沿用最近一次结果

系统演示时不需要追求极限帧率，稳定在20帧以上足够了。把画好框的图像原样展示出来，配合置信度数值，观众一眼就能明白系统做了什么。

5. 论文写作与答辩：把工程结果变成合格毕业设计的最后一公里

5.1 论文结构怎么安排

毕设论文的通用结构是“绪论—相关工作—数据集与预处理—模型与方法—实验与分析—系统设计与实现—总结与展望”。关键是不要写成“代码说明书”。很多同学的“系统设计与实现”章节把代码一段段贴上去，看着像注释文档，毫无逻辑。

我的写作策略是：每个功能模块都先写“要实现什么”，再写“为什么这么做”，最后写“效果如何”。比如推理模块，不是贴一遍ONNX Runtime的API手册，而是说“为了降低系统对训练框架的依赖，保证Web服务部署的稳定性，这里将模型导出为ONNX格式，并通过ONNX Runtime完成加载与推理”，然后再放关键代码段。

5.2 实验对比与图表呈现

毕业设计的实验部分最核心的是一个对比表，推荐这样设计：

这个表格里的数字是示意，你实际训练后填自己的数据。对比模型的用意是为了证明你选择的不是“拍脑袋”，而是实验得出的结论。

图表方面，至少要有：loss下降曲线、PR曲线、混淆矩阵、若干组检测效果前后对比图。效果图一定要从测试集里选取，从训练集里截图的“神仙图”在答辩时经不起追问。

5.3 “创新点”怎么实在地写

不要写“本文创新性地使用了YOLO11”，这句话在评审眼里等于没有创新点。可以从以下几个角度包装：

1. 数据策略：针对水稻病斑小目标占比高的特点，设计了包含复制粘贴增强与小目标过采样的数据方案
2. 系统逻辑：检测结果直接映射到病害防治建议，形成“识别—诊断—建议”的完整功能链
3. 优化策略：通过调整置信度阈值与NMS参数，在病斑检测场景下把漏检率降低到可接受范围

创新点是“有限但真实”的改进，不是大词空话。

5.4 答辩高频问题清单

我复盘了答辩中被问到最多的问题，提前准备就好：

• 为什么选择YOLO11而不是YOLOv8？
• 训练集、验证集、测试集是如何划分的？有没有做严格分离？
• mAP50和mAP50-95有什么区别？你的模型值是多少？
• 检测系统在实际田间环境里能实时工作吗？为什么？
• 当检测出现误报时，你会从哪些角度排查？

回答的核心逻辑是：先讲清楚本质原因，再给出实测数据支撑，不要背概念。

6. 复盘与避坑：那些教科书没写的真实问题

6.1 标注坐标全部逃逸，loss飞起

头一次训练时，我用了标注软件导出的VOC格式xml，然后写脚本转换成YOLO格式。脚本里忘了把坐标除以图像宽高，所有框的x_center和y_center都大于1，训练出来的模型完全不可用。排查了很久，最后用一个脚本遍历所有txt，发现最大值达到了2.3。

教训有两点：一是转换脚本写完先打印几行人工核对，二是自动化检验坐标范围一次都不要省。

6.2 训练集和验证集交叉，指标虚高

这个问题前面提过，但必须单独强调。我用脚本划分数据时，按分类目标（每张图片归属于某个类别）过滤后随机划分，看似没问题，实际上同一张原始图可能被增强器切出多个副本，增强后虽然像素变了，但仍属于同一张基础图。如果增强流程在划分之后进行，训练里出现了验证图的增强版本，指标就虚了。正确顺序是：先按原始图像划分文件夹，再做离线增强。

6.3 中文路径导致的推理崩溃

Web系统跑在Windows上时，上传文件的临时目录若包含中文，部分库在读取路径时直接报错。排查到最后，每个人都想不到是这个原因。解决方案很土：上传后统一改成英文文件名再保存，一劳永逸。

6.4 训练中断后从头再来

训练到第90个epoch时，电源断了一次，所有进度归零。后来加上了两条命令习惯：一是每次训练用相同的随机种子，方便复现；二是把ultralytics训练生成的runs目录定期备份，尤其是best.pt，训练中断后可以尝试在现有权重上继续训练：

yolo detect train --resume runs/detect/train/weights/last.pt

不过建议从一开始就把epoch数设置合理，配合patience早停，减少一次训练跑几个小时的概率。

6.5 检测准，但UI展示效果差

模型本身mAP不低，但界面截图出来很“丑”——病斑框线太细、标签文字重叠、置信度小数位数太多。论文里放这种截图是很吃亏的。我在最后阶段把画框逻辑改成了：框线加粗、标签背景块半透明、置信度保留两位小数、按类给不同颜色，截图效果立刻上了一个档次。

画框这种小事看起来不起眼，但在最终的论文和答辩PPT里，它就是评审对你的第一印象。

我个人的体会是，这种毕业设计项目的完成度不取决于任何一次“灵光一现”，而取决于每一个普通环节是否做到位：数据是否干净、标注是否规范、划分是否严谨、推理是否稳定、图表是否清楚。把这五件事打磨扎实，系统的技术含量和论文的说服力自然会立住。最后再分享一个小技巧：所有训练结束后，先不急着做界面，把模型跑验证集的检测结果图全部打印出来挑几组好的存下来——后面论文、PPT、演示截图都会用到，早存不慌。