1. 为什么我放弃踩数据库选择自建农作物病虫害检测数据集做目标检测这几年我经手过不少数据集人头计数、车辆识别、安全帽检测都跑过。但真正让我觉得“这活儿没法直接抄作业”的是农作物病虫害检测。去年接了个水稻种植基地的合作需求对方希望用无人机和手机拍摄的田间图像自动识别稻瘟病、稻飞虱、纹枯病这几类常见问题。我第一反应是去公开数据集碰碰运气结果翻了一圈下来发现通用的农业数据集要么图像背景过于干净要么标注框是错位的要么类别少得可怜根本覆盖不了田间的真实复杂环境。于是就有了这篇文章的主题抛开现成资源从零整理一份农作物病虫害检测数据集并在同一套数据下跑YOLOv5、YOLOv8和YOLOv11做横向验证。说实话整个过程比我预想的更折腾但也正因为折腾我对目标检测落地农业场景这件事有了完全不一样的理解。如果你正准备做类似的项目或者你已经在用公开数据集训练但总觉得效果差点意思这篇内容应该能帮你省掉不少弯路。这篇文章会完整交代数据集的来源逻辑、采集和标注时的坑、训练多版本YOLO时实际用到的参数以及最终在验证集上呈现的评测结果。重点是我不只告诉你“跑通了”还会把那些失败尝试和参数调试过程一并摊开方便你复现和避开同样的问题。在开始之前先说明一点如果你是那种直接想要一份“下载即用”的数据包的人本文可能满足不了你因为脱敏后的数据涉及基地合作方的隐私要求不能公开分发。但我可以毫无保留地分享整个数据体系怎么搭、标注怎么做、模型怎么训这些方法论才是可以迁移到任何同类场景的核心资产。2. 数据集构建的前置思考田间图像的难点和公开数据集的硬伤2.1 真实田间环境到底难在哪很多人以为农作物病虫害检测的难点在模型其实真正卡住模型的不在算法而在图像本身。公开数据集里的病虫害图像很多是专家拿着专业相机近距离拍摄的光线均匀、背景单一、叶片姿态标准看起来赏心悦目。但实际田间的图像完全不是这么回事。比如水稻田里的稻瘟病病斑往往发生在叶片中下部被上层健康叶片挡住无人机拍到的角度非常有限稻飞虱这类虫害更麻烦虫子本身只有几毫米聚集在稻株基部光靠视觉识别需要极其清晰的近景图。而手机拍摄时手持抖动、逆光、露水反光、泥土飞溅这些干扰因素会把一个小小病斑的特征淹没在背景噪声里。另一个常被忽视的问题是尺度差异。同一种病害在苗期、分蘖期、抽穗期的形态完全不同病斑面积、颜色深度、扩散方式都不一样。如果你只采集某一生长阶段的数据训练出的模型换到另一个阶段基本就废了。所以数据采集必须覆盖不同生育期这直接决定了数据量的下限。2.2 公开数据集为什么不好用我不是说公开数据集没有价值作为预训练或者算法验证它很有用。但具体到某一个作物的特定病害公开数据至少存在三方面硬伤第一类别体系不一致。有的数据集把“稻瘟病”分成“苗瘟”“叶瘟”“穗颈瘟”有的则直接归为一个大类“稻瘟病”。模型学到的是标签边界你的实际需求是“看到病就得报警”这种语义粒度上的差异会让模型的表现高不成低不就。第二背景纯净度过高。公开数据集的评审标准往往更看重“目标清晰”所以图像里几乎没有杂草、土壤、积水、昆虫、遮挡物等干扰。实际推理时模型把稻飞虱错检成泥点、把健康叶片上的露珠当成病斑都是再正常不过的事。第三时空分布单一。很多数据集来自某个特定地区、特定年份、特定品种模型的泛化能力被严格限制在原产地的气候条件里。一旦跨纬度、跨季节检测效果断崖式下降。所以我才决定抛弃“拿来主义”从基地现场自己采集。虽然前期成本高但后期模型的鲁棒性会好很多。这个决定当时看是费时费力回头看却是最值的一笔投入。3. 数据集到底怎么搭采集规范、标注流程和质检方案3.1 图像采集规范不是拿个手机随便拍在正式采集之前我先和基地的技术员一起制定了拍摄规范目的是让数据尽量贴近真实使用场景同时保证目标特征可识别。我们按三个维度去控制设备维度主力使用手机广角镜头和无人机下视镜头偶尔补一些微距特写用于增强病斑细节特征但占比控制在总量的20%以内。这样做是为了让模型见到不同距离、不同分辨率下的目标形态。场景维度分别在晴天、阴天、清晨露水未干时、雨后、喷洒农药后等不同天气和时段拍摄让数据自然引入光照变化和背景干扰。每种天气条件是独立文件夹整理方便后续分析模型在哪种场景下最容易失效。生育期维度按水稻的分蘖期、拔节期、孕穗期、抽穗期、灌浆期分阶段采集每个阶段至少保证1周一次持续整个生长季。这样一来同一类病害在不同生育期呈现的差异都被记录了下来。这里有个细节值得特意提一下图像分辨率不要盲目求高。无人机原始图片常常是几千万像素如果直接拿去训练显存直接爆掉而且大尺寸图像里的病斑在缩放到640×640之后细节会严重丢失。正确的做法是先把原图切分成若干带有重叠区域的子图再筛选出含有目标的子图进入数据集。我们使用滑窗切图的方式窗口大小设成1024×1024重叠率30%最后保留的子图分辨率在1024级别训练前再缩放到640。3.2 标注工具的选型与标注规范的坑标注工具我用的是开源的LabelImg。虽然它界面朴素但胜在稳定VOC格式和YOLO格式都能直接导出跨平台支持也好。团队里有人推荐用Label Studio去做多边形标注但实测下来在大量叶片边缘不规则的目标上多边形标注带来的精度提升并不明显反而把标注时间拉长近一倍。病虫害检测本质上不需要像素级的实例分割精度矩形框足够支撑训练需求。真正需要重点设计的是标注规范这是整个数据集质量的地基。我们在规范里逐条明确了边界场景的处理方式病斑面积占叶片总面积小于5%时不标。这个阈值经过实际验证太小的病斑即使标注了训练时由于特征不充分也很难学出稳定规律反而增加误检。叶片重叠时如果病斑主体暴露面积超过60%正常标注低于这个比例不标。一个框内同时出现两种病害时遵循“优势病害优先”的原则只标面积占比更大的那类避免一个框产生二义性标签。稻飞虱这类密集小目标允许一个框覆盖一小簇5至10只但标注规范中明确“一簇到底”不允许框内只框一半位置以防模型学到不完整的空间分布。表格式地整理这些规则并不难难的是执行。标注员之间容易出现尺度漂移前一周觉得该标后一周觉得不该标。我的解决办法是每隔3天随机抽取已标注图像进行一致性校验发现分歧超过5%就召集标注员重新对齐标准。3.3 数据质检和清洗比标注本身更耗时标注完成后质检是整个环节里最容易被省掉但最不该省的一步。我们的质检分三个层次来做第一层是格式校验。脚本检查每个标注文件的类别ID是否在合法范围内坐标是否越界框的宽度和高度是否为正数目标面积是否过小等。这类问题在批量标注时非常常见特别容易出现在一边标注一边滚动图像的场景里。第二层是人工视觉抽检。按每个类别至少抽20%的比例把图像和标注框叠画后快速浏览重点看框与目标边缘的贴合度是否在合理范围、有没有漏标严重的大目标。这层依赖经验需要有人对农作物的病害特征有基本认知。其实这一点反而是很多项目最容易忽略的标注员如果没见过真正的田间病害很容易把机械损伤、药害斑点也标成病害模型训练出来就自带虚假概念。第三层是尺度分布统计。统计每个类别下目标框的宽高分布画出散点图直观地看是否存在大量异常极端的框。例如有些叶子很长但病斑集中在叶片中部标注框的高度几乎等于叶片高度这种框在缩放后目标占比会被严重压缩训练效果自然不好。这类框我们会考虑重新分割标注把一个长框拆成多个短框。整套流程走完我们最终整理出约12800张有效图像累计标注目标框超过67000个类别涵盖稻瘟病、稻飞虱、纹枯病、二化螟危害、生理性黄叶这五个类别。这个规模放在公开数据集里不算大但胜在图像分布贴近真实田间环境。4. 数据增强策略用有限图像“多榨”出训练价值4.1 增强不是为了“变多”而是为了“变多样”很多刚入门的人有个误区以为数据增强就是把图片左右翻转一下、调调亮度让数量翻倍。其实增强的核心价值在于提高模型对真实环境变化的鲁棒性。田间图像的光照变化跨度非常大从清晨的弱光到正午的强逆光色温和曝光差异明显。如果训练集里缺少这些变化模型到现场大概率会出问题。我的增强策略分两部分一部分在训练前用离线脚本生成另一部分在训练过程中在线实时增强。离线增强主要是针对一些耗时较重的操作例如模拟雨滴、雾化效果这些操作如果做成在线增强会拖慢训练速度。在线增强则使用YOLO官方库自带的增强管线包括随机翻转、随机缩放、色彩空间抖动、马赛克增强Mosaic、复制粘贴增强Copy-paste等。4.2 各项增强参数的设定逻辑在YOLOv8和YOLOv11的训练配置里增强参数是一组关键的超参数我最终采用的组合如下hsv_h0.015色相变化幅度很小只做微调防止叶片颜色发生不真实的偏移。hsv_s0.7饱和度抖动范围较大用来模拟不同施肥水平和品种在叶色上的差异。hsv_v0.4亮度抖动适中覆盖阴天到晴天的曝光变化。degrees0.0不旋转。水稻叶片的朝向基本一致旋转会制造大量不存在于田间的斜向叶片形态反而干扰模型学习。translate0.1平移幅度10%模拟拍摄时目标偏离画面中心的情况。scale0.5缩放幅度50%让模型适应不同拍摄高度下的目标大小变化。fliplr0.5左右翻转这个对叶片类目标影响不大是安全的增强方式。mosaic1.0默认开启把四张图拼成一张对密集小目标如稻飞虱的检测效果提升明显。copy_paste0.3把同一幅图里的目标实例粘贴到另一幅图的随机位置额外扩充小目标的样本数量。值得单独说明的是mosaic增强的利与弊。它能在很大程度上缓解小目标样本不足的问题但也容易让模型学到“拼接痕迹”。在训练后期最后50轮我选择关闭mosaic让模型在正常分布下微调收敛。这个“先开后关”的调度在多个版本上都验证有效最终mAP普遍提升了1到2个百分点。4.3 训练集和验证集的划分策略划分数据集不是随便按比例随机切分就结束。病虫害图像有很强的空间自相关性同一块田里相邻拍摄的图像往往背景高度相似如果全部混在一起随机划分训练集和验证集之间可能存在“近亲”图像验证集分数虚高到了真实场景就原形毕露。我的方案是分层划分先按采集日期、田块编号对图像分组确保同一个田块同一日期采集的图像全部落在同一侧不跨训练集与验证集。具体比例上训练集占70%验证集20%测试集10%。这个比例对于小数据集来说验证集稍大一些是合理的选择因为各类别样本量不均衡验证集太小会导致评估指标的方差过大。划分完之后我额外检查了每个子集的类别分布确保每个子集中各类别占比结构与全数据集大致一致避免某一个类别在验证集里样本极少、导致最终评估对该类别的mAP值失真。5. 多版本YOLO同场竞技从YOLOv5到YOLOv8再到YOLOv115.1 为什么选这三个版本横向对比选定YOLOv5、YOLOv8和YOLOv11做对比有我的实际考量。YOLOv5虽然是上一代产物但生态成熟、部署资料多、坑都被前人踩得差不多了在真实工程项目里依然有大量存量使用YOLOv8是当前应用范围最广的中间版本C2f结构和Anchor-Free检测头的组合在精度和速度之间取得了不错的平衡YOLOv11是最新主线版本在特征提取和训练效率上都有更新但实际落地时是否真的全面领先不能只看官方指标要放到我们自己的数据集上说话。顺便说一句我没有选YOLOv6、YOLOv7之类同样有名的版本主要原因是对比测试的控制变量要尽量简单。三个版本横跨两个技术代际足够说明问题了。另外GPIO资源有限多跑几个版本在时间成本上并不划算。5.2 训练环境的搭建细节硬件方面的配置是单张消费级显卡显存24GB。这个配置在目标检测领域算入门档但只要你控制好batch size训练这个小规模数据集完全够用。软件环境我用的是Python 3.10 CUDA 11.8 PyTorch 2.0.1的组合。CUDA版本的选择上有个坑新发布的某个PyTorch版本要求CUDA 12才能编译但我的显卡驱动版本偏旧只能匹配CUDA 11.8所以安装时确认好PyTorch与CUDA的对应关系非常重要。训练前还要修改一份数据集描述文件路径指向我们准备好的YOLO格式标注目录。这里特别提醒一个细节YOLO训练脚本对路径分隔符的解析在Windows和Linux下存在差异如果你在Windows下写完路径直接拿到Linux服务器运行极大概率报路径错误。建议所有路径统一使用正斜杠并启用强制重建参数来避免旧缓存干扰。5.3 训练参数配置和消融观察为了让三个版本之间的对比尽量公平所有共享参数保持一致。关键参数如下输入图像分辨率640×640batch size为16训练轮数300轮优化器选择SGD初始学习率0.01最终学习率0.001权重衰减0.0005动量0.937。热身训练采用3轮预热预热时学习率线性从0上升到初始值。SGD和Adam的选择上我特意没有用AdamW。原因很简单YOLO系列的官方默认配置长期使用SGD配套的学习率策略和衰减参数已经过充分调校贸然换成AdamW看起来更快收敛但最终精度往往不及SGD加上合理的余弦退火调度。这一点在YOLOv8上尤其明显AdamW训练到后期精度提升缓慢换成SGD后mAP涨了约两个点。训练过程中我在意的指标不只是最终的mAP还包括训练损失的下降曲线。例如YOLOv5在100轮以后损失曲线已经开始平缓YOLOv8则在180轮附近还有明显的下降这说明不同版本的收敛节奏完全不同。同样的300轮设定下YOLOv8实际上比YOLOv5有更多的“潜在潜力”没有被挖掘出来所以如果你时间充裕针对YOLOv8适当延长训练轮数或者调整早停阈值也许能榨出更好的精度。另一个值得一提的观察是小目标类别的表现。稻飞虱这一类别的标注框面积都非常小在640分辨率下锚框匹配阶段就很容易丢失。YOLOv5用的是基于Anchor的设计对小目标的召回率明显偏低YOLOv8和YOLOv11改成Anchor-Free后小目标的召回有了可见的改善。这一点在我最终的指标表里体现得十分清楚。5.4 各版本的实测结果对比训练完成后我不光看了验证集指标还专门做了一次“真实场景模拟测试”用一段无人机在基地拍摄的从未参与训练的视频抽帧输出检测结果观察效果。综合指标和模拟结果三个版本的对比情况如下表模型版本参数规模mAP50mAP50-95稻飞虱召回率单帧推理耗时毫秒YOLOv5s约7.2M0.8930.6170.715.2YOLOv8s约11.2M0.9120.6580.825.8YOLOv11s约9.4M0.9250.6840.866.1从表里能看出几个有意思的结论。第一YOLOv11在mAP50-95和高阶指标上全面领先这是新结构带来的特征提取能力提升不是简单的调参可以替代的。第二YOLOv5虽然整体精度略逊但推理速度最快在边缘设备部署时依然有优势。第三小目标召回率这个单项指标差异明显说明如果你的主要检测对象是稻飞虱这类小目标选择新版本几乎是必须的。但只看mAP也有骗人的时候。我在模拟测试中发现YOLOv5在“雨后积水反光”的镜头里出现了较多的误报把水面反光中的叶片倒影识别成了病斑而YOLOv11在这个场景下的误报明显少。这种从指标上很难直接体现的鲁棒性差异恰恰是农业场景落地最关键的品质。5.5 推理速度和部署体积的权衡精度只是模型选型的一个维度落地部署还要考虑推理速度和模型体积。我实测了三个版本在相同硬件条件下、相同视频流输入时的推理耗时数据已经放在上面的表格里。YOLOv5s的模型权重文件体积约14MBYOLOv8s约22MBYOLOv11s约19MB。体重和精度几乎同步增长但差异不悬殊。如果你的部署目标是无人机机载嵌入式板卡算力受限那可能需要掉头选择精度略低但速度更快的轻量化版本甚至考虑剪枝量化。但如果你和我一样先跑服务端验证算法可行性那么YOLOv11s的模型大小完全不是问题。关键还是看业务容忍度你更怕漏检还是更怕误报。6. 落地点滴部署过程里的几次意外与处理方案6.1 光照突变导致的闪烁误报实际部署时遇到的一个典型问题是坏帧。无人机在转向、云台调整或遮光瞬间画面会出现剧烈的曝光变化中间某些帧的亮度极低或极高。模型在这种帧上容易输出一些置信度较低但确实存在的伪框框的位置还飘忽不定叠加到视频流里就形成闪烁感。解决思路不是提高模型阈值而是加一帧间平滑逻辑。具体做法是保留前5帧的检测结果如果当前帧某个类别只有单个低置信度框出现且在前5帧中完全没有同类别目标就忽略这帧的该检测框。这个逻辑处理了大部分闪烁误报同时不会漏掉真实出现的低速移动目标。6.2 背景迁移导致的虚高置信度另一个意外是我们发现模型对训练集中常见的田埂泥土和枯草背景产生了“背景记忆”某些情况下虽然目标框内实际没有病虫害但置信度依然达到0.6以上。分析根因发现是训练数据里某块田的特定背景出现了太多次模型学到了背景-目标的相关性而不是纯粹的目标特征。常规做法是在训练时加入更多负样本即不包含任何目标类别的背景图像让模型学会输出“无目标”。我把基地中大量不存在病虫害的图像抽样加入训练集放在“无目标”类别下参与训练并把背景多样性拉满。这个操作明显压低了在陌生背景上的虚报率属于代价极低但收益显著的工程优化。6.3 类别的层级设计粗分类和细分类之争在整个项目接近尾声时基地技术员提出能不能把“稻瘟病”进一步细分为“叶瘟”和“穗颈瘟”。细分类对农业生产决策确实更有意义叶瘟发生在叶片上影响光合作用穗颈瘟发生在穗颈节直接关系产量防治策略完全不同。但如果直接在现有模型上增加细分类需要重新标注大量数据而且穗颈瘟在无人机视角下目标极小现有分辨率下难以稳定识别。最终我采取了折中方案保留现有五类粗分类模型用于巡检报警同时单独训练一个输入分辨率提升到1280的细分类模型专门用于近景确认。两个模型串联使用先粗筛报警、再细判定级。这种分层识别架构在实际项目中完全可行部署后误报率下降细分类准确率也达到预期。7. 一些实操层面的经验尤其是对准备自建数据的人做完整套流程后我最大的感受是在农作物病虫害检测这类场景里数据工程所占的比重远比模型训练大。模型版本的选择只要按流程走结果大概率差不太多但数据集的质量直接决定了项目上限。如果你准备照这个思路做自己的数据集有几个经验我可以直接分享。拍摄的时候宁可多拍也不要少拍。原始图像永远不嫌多因为标注过程中的筛选会把大量不合格图像淘汰掉比如严重过曝、脱焦、被遮挡。我最终保留的有效图像大概只占原始素材的45%如果一开始采集量不够标注到后期会发现样本根本凑不齐。标注标准要写成文档并全员对齐。我发现很多人就觉得标注很简单看到框就标一下结果几百张之后才发现前后标准不一致。返工的成本远高于一开始多花时间培训对齐标准的成本。建议标注规范里除了文字说明附上各类别的示例图像和“该标/不该标/模糊区”的对照图这是减少争议最有效的办法。增强参数不要盲目抄官方默认值。官方给的增强默认参数是基于COCO、ImageNet这类自然图像调出来的搬到农作物场景必须结合目标特性做减法。最典型的例子就是旋转增强对行人检测来说水平竖直翻转可能都是合理的但自然场景下无人机拍摄的农作物方向基本一致过度的旋转增强反而会干扰模型建立正确的空间先验。另外强烈建议训练时使用早停机制监控验证集mAP并在连续多轮不提升时自动停止。我在YOLOv8训练时设了30轮不提升就停最终在220轮左右触发早停省了不少算力。关键是早停轮次配合“关闭mosaic”的调度需要在触发之前生效不然停止时机可能落在过拟合的前夜微调余地就没有了。如果你打算在同样的任务上继续深入我觉得有几个方向值得探索一是引入多光谱图像通道把可见光之外的植被指数信息融进检测流程二是用大模型做辅助标注先让模型预测一轮再让人工只修正错误的框能在保持质量的同时把标注成本大幅降下来。这些方向我还只是在测试阶段等跑得差不多了再单独开一篇聊。