1. 为什么番茄叶片检测需要一份专门的数据集
做农业视觉项目最头疼的往往不是模型选型，而是数据本身。我之前接过几个智慧农业相关的巡检需求，发现大家都在问YOLOv8怎么调参、怎么部署，但真正把项目卡死的，是找不到一份贴合田间真实场景的植物病害数据集。网上公开的植物叶片数据集不是实验室单背景拍的，就是类别划分太粗糙，要么干脆是国外品种的叶片，和国内大棚里的番茄长势差距很大。所以我在棚里蹲了几个月，自己采集、清洗、标注了一套番茄健康叶片检测数据集——3100张图片，YOLO格式，直接瞄准智慧农业场景下叶片健康巡检这个具体任务。这篇文章把从采集思路、标注规范、训练调参到边缘设备部署的完整过程拆开来讲，希望能给正在做农业检测方向的朋友一条可以直接抄的路径。
1.1 通用目标检测数据集在农业场景的三个致命短板
很多人一开始会想：直接用COCO或者ImageNet预训练权重，然后在自己小批量图片上微调不就行了？理论上可以，但现实中会遇到三个绕不开的问题。
第一个问题是类别体系完全不匹配。COCO的80类里根本没有植物病害这个概念，模型学到的底层特征是通用物体轮廓、纹理、颜色，这些底层特征确实可以迁移，但番茄叶片病害的判别往往依赖于细微的纹理差异——比如早疫病同心轮纹的稀疏程度、晚疫病水渍状病斑的边缘形态，这些高级语义特征在自然图像数据集里是不存在的，靠微调强行学，需要的数据量远比你想象的大。
第二个问题是图片分布差异。网上能爬到的大多数植物病害图是单叶特写，背景干净、光照均匀、叶片完全展开，像标本照。但实际田间巡检拍到的是多叶片重叠、受光不均、背景里混着土壤、滴灌带、杂草、地膜反光。模型在实验室照片上训练出来，到了真实棚里往往溃不成军，检测框乱跳，置信度一片惨淡。
第三个问题是标注粒度。农业病害检测不是一个“框出叶子”就能交差的活，你需要的是“识别出这片叶子有没有病、是什么病、病斑范围在哪”。通用数据集只提供物体级标注，没有农艺层面的语义信息，这导致模型很难学到“叶片边缘枯黄不一定有病，中心病斑扩散才是发病早期”这类关键判断。
1.2 3100张样本量的制定逻辑：不是拍脑袋，是成本和收益的平衡
很多人一听3100张会觉得“才这么点，是不是不够用”。我的观点是：脱离任务谈数据量都是耍流氓。在智慧农业巡检场景里，采集和标注的边际成本都很高——每一张图都要人工拍摄、人工筛图、人工框目标，如果把目标从“做数据集”换成“训练一个能用的模型”，3100张经过严格清洗、均衡类别、覆盖多环境条件的图片，配合YOLO的预训练权重，是能训出一个及格线以上模型的。
我算过一笔账：这些图片里平均每张标注8到15个叶片目标，单人用标注工具每天大概能完成200到300个目标，整个标注周期大约是两周。再往上堆数量，标注成本翻倍，但模型精度的提升会明显放缓。先跑通一套完整流程，后续再针对模型暴露的短板去补数据，才是更务实的迭代方式。
这份数据集当时的定位也很明确：不追求上百类的病害大全，而是先解决“健康叶片 vs 常见病害叶片”的区分问题。类别太多，样本之间类间差异变小，3100张反而容易被稀释；类别太少，模型到了田间又不够用。最终选了4个类别：健康叶片、早疫病、晚疫病、叶霉病。这4类病害恰好覆盖了番茄种植中最常见、经济损失最大的几种情况，健康叶片作为正样本类，让模型不至于把一切叶片都往病害方向推。
2. 数据采集与环境设计：让样本贴近真实巡检场景
2.1 采集设备和场景的多样性安排
采集设备上我用了三路：手机主摄、入门单反、USB免驱摄像头。手机负责大量快拍，单反用来拍高分辨率细节，USB摄像头模拟后续边缘设备在低分辨率下的成像效果。这样做的好处是训练数据里天然带了不同传感器、不同分辨率的差异，模型对设备的敏感度会低很多。只用单一设备采集，后面换到巡检设备上，成像差异会让检测效果直接打折。
采集场景我覆盖了三类：温室大棚、露地种植、实验室补拍。温室里的光线以散射光和遮阳网透射光为主；露地直射强光会产生明显阴影；实验室补拍用于获取特定病害的典型症状特写。拍摄角度上，我要求自己尽量模拟巡检员第一人称视角——俯拍植株顶部、斜侧拍中下部叶片、蹲下来拍叶背。叶霉病早期症状更多出现在叶背，如果没有足够多的叶背视角，模型很难学到这个特征。
有人会问，为什么不把每片叶子摘下来平铺拍，那样不是更清晰吗？确实更清晰，但那是“标本思维”。真实巡检中，无人机和巡检车拍到的是整体植株，叶片相互遮挡、卷曲、垂挂是常态。如果训练集全是平铺展开的完美叶片，模型在应用中遇到重叠叶片就会产生大量漏检和误检。所以我在数据里特意保留了一个子集的自然株型照片，让模型习惯“不完美”的成像。
2.2 背景多样性和光照变化的刻意引入
背景这块是我花了很多心思的地方。一开始做出来的初版数据，模型训练指标看着挺高，一到大棚里实测就露馅。后来分析发现，训练集里大量图片背景都是简单的泥土或者育苗盘，模型实际是拿背景当“特征”在记忆——土壤纹理、塑料膜反光都被学到了权重里。这给我一个教训：背景必须多样化，才能逼模型真正去关注叶片本身。
我特意收集了滴灌带、黑色地膜、杂草覆盖、白色防虫网、水泥地面、露地黄壤等不同背景的样本。比例上大概控制为：常规土壤背景50%，其他复杂背景50%。光照方面也是有意制造梯度：晴天直射光、阴天散射光、大棚遮阳网下的暗光、清晨逆光、傍晚低色温光，都分配了一定数量。目标检测模型对亮度和色温比较敏感，如果训练集里全是正午顺光拍的图片，到了清晨和傍晚巡检，模型漏检率会明显上升。
2.3 清洗与去重：4000多张原图只剩3100张
采集阶段我一共拍了4000多张原图，最后进入数据集的只有3100张，清洗淘汰率接近四分之一，这个过程不能省。
第一步是肉眼粗筛，删掉对焦失败的、严重过曝的、叶片快速晃动产生动态模糊的。第二步是去重，用感知哈希（pHash）算法对图片算指纹，把相似度高于阈值的图片归为一组，每一组只保留成像质量最高、角度最独特的那张。这一步很关键，不然数据里大量重复样本只是“看起来数量多”，模型反而会因为同类样本过于集中而产生过拟合。
第三步是检查图像分辨率。采集设备里USB摄像头和部分手机照片在放大后叶片纹理不够清晰，这类图如果叶片占比大就保留，占比小且纹理模糊的就删掉。清洗完成后，每个类别都保证有700到800张以上的有效样本，类别之间最大差距控制在1.2倍以内，避免训练时模型被样本量大的类别带偏。
3. 标注规范与类别体系：框的质量决定模型上限
3.1 四个类别的农艺学判定标准
类别设计不是拍脑袋定的，我找了本地农技站的老师傅确认了几种病害的典型症状，把判定标准写在了标注规范里：
- healthy（健康叶片）：叶片颜色均匀、无明显病斑、无大面积黄化，允许有轻微机械损伤或老叶边缘轻微干枯。
- early_blight（早疫病）：叶片出现褐色同心轮纹斑，病斑周围有黄色晕圈，多从植株下部老叶开始。
- late_blight（晚疫病）：叶片出现水渍状暗绿色或褐色大斑，湿度大时叶背可见白色霉层，病斑边缘不规则。
- leaf_mold（叶霉病）：叶片正面出现褪绿黄色斑块，叶背对应位置出现灰褐色至紫灰色霉层。
为什么要把健康叶片单独列为一类，而不是做纯二分类“有病/没病”？因为病害检测的落地难点恰恰在“健康与疑似病害”的边界上。老叶的边缘枯黄、虫咬痕迹、日灼伤，都容易被简单模型误判成病害。单独设健康类，强制模型去学健康叶片的内在特征，有助于压制误检率。
3.2 边界框标注的统一标准：什么该框，什么不框
标注这一步我踩过不少坑，这里直接给结论。
第一，标注的基本单位是“叶片个体”，但允许例外。健康叶片要求完整框住叶片边缘，包括叶柄基部，不包括叶柄远端。病害叶片如果是整片发病就框整片，如果是局部病斑，就以病斑外缘为准框住发病区域，优先保证框内大部分区域是病斑特征。这里有个容易犯的错：为了省事把健康叶片的框画得很大，带着背景一起框进去。背景信息会污染特征，模型学到的是土壤加叶片的混合特征，在纯叶片特写和复杂背景之间反复摇摆。
第二，重叠叶片怎么标。两片叶子叠在一起但都能分辨轮廓，分别标两个框；遮挡严重导致轮廓不完整但能判断类别，按可见部分标框；只能看到一小条且无法判断类别的叶片，不标。原则是“宁缺毋滥”这四个字，标错了对模型的伤害远大于漏标。
第三，病害早期症状模糊怎么办。肉眼无法判定是早疫病还是晚疫病时，我采取的策略是标成更常见的那一类，并在图片备注里打上“弱标注”标记，后期单独复查。坚决不搞“两个标签都打”这种操作，YOLO格式单类别标注下这样做只会让模型学到错误的类间界限。
3.3 YOLO格式转换与目录结构划分
标注工具我用的是LabelImg，先导出VOC格式的XML，再写一个Python脚本转成YOLO的txt格式。转换的核心就是归一化坐标换算：把目标框的左上角坐标(x_min, y_min)和右下角坐标(x_max, y_max)转换成中心点坐标和宽高，再分别除以图片宽度和高度。
import os import xml.etree.ElementTree as ET def convert_voc_to_yolo(xml_file, classes): tree = ET.parse(xml_file) root = tree.getroot() image_w = int(root.find('size/width').text) image_h = int(root.find('size/height').text) lines = [] for obj in root.findall('object'): name = obj.find('name').text if name not in classes: continue class_id = classes.index(name) box = obj.find('bndbox') x_min = float(box.find('xmin').text) y_min = float(box.find('ymin').text) x_max = float(box.find('xmax').text) y_max = float(box.find('ymax').text) x_center = (x_min + x_max) / 2 / image_w y_center = (y_min + y_max) / 2 / image_h width = (x_max - x_min) / image_w height = (y_max - y_min) / image_h lines.append(f"{class_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}") return lines classes = ['healthy', 'early_blight', 'late_blight', 'leaf_mold'] # 遍历所有xml文件，逐个转换并写入同名txt目录结构我按YOLOv8的标准习惯来组织：
tomato_leaf_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ ├── data.yaml └── README.md训练、验证、测试按8:1:1随机划分。这里有一个容易忽略的坑：划分必须在清洗和去重之后做，否则同源图片（比如连拍的一组照片）会同时落到训练集和验证集里，导致验证指标虚高。我自己的做法是在pHash去重阶段就把相似图归组，按组为单位来划分，确保训练集和验证集之间没有相似度极高的样本。
3.4 标注质量的三重检查机制
标注完不能直接开训，我过了三道检查。
第一道是可视化回看：写脚本把标注框和类别名画回图片上，按每100张一组快速翻看，重点检查框是否贴合叶片边缘、类别是否明显标错。第二道是数据分布统计：统计每个类别在训练集、验证集、测试集中的数量占比，如果某个类别在测试集里只有几十张，指标波动会非常大，需要重新划分。第三道是农艺复核：随机抽10%的图片找懂番茄种植的人再过一遍，确认病害类别的判定没有原则性错误。
这三道检查听着繁琐，其实也就花半天时间，但能避免一个非常尴尬的局面：模型训练完发现某类检测指标异常低，排查到最后是标注时把几十张早疫病图片错标成了晚疫病，白白浪费几天训练时间。
4. 用YOLOv8训练这份数据集的完整配置
4.1 环境准备与硬件要求
训练环境我建议直接上miniconda，Python版本3.9以上，PyTorch按官方推荐版本装即可。YOLOv8的代码库就是ultralytics这个包，安装非常省心：
conda create -n yolo python=3.9 -y conda activate yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics硬件方面，训练这种3100张规模的检测数据集，一块显存8GB以上的显卡就能跑得很舒服，比如RTX 3060 Ti或更高。如果只有CPU，也不是不能训，但一个epoch可能就要十几分钟，100轮训练下来得熬一天一夜，建议还是想办法租个云GPU。部署端另说，那是后面要单独考虑的，训练端不用太省。
4.2 data.yaml配置与模型选型逻辑
data.yaml是整个训练流程的入口，里面指定了数据集路径、类别名称和类别数，内容很简单：
path: /path/to/tomato_leaf_dataset train: images/train val: images/val test: images/test nc: 4 names: 0: healthy 1: early_blight 2: late_blight 3: leaf_mold模型尺寸选择上，我在YOLOv8n和YOLOv8s之间纠结过。n模型参数量最小，推理速度最快，适合边缘部署；s模型精度更高，但参数量大约是n的三倍。考虑到智慧农业巡检无人机和巡检车通常跑在嵌入式设备上，算力有限，我建议先从n开始训练，跑通全流程拿到一个基线，再用s训练做对比。两个模型除了配置文件里的模型名不同，其他参数完全一致，对比才有意义。
4.3 训练超参数设置与训练命令
训练命令我直接用ultralytics提供的CLI，不额外写训练脚本：
yolo detect train \ model=yolov8n.pt \ data=tomato_leaf/data.yaml \ epochs=100 \ imgsz=640 \ batch=16 \ lr0=0.01 \ optimizer=AdamW \ augment=True几个关键超参数的取值逻辑说一下。epochs取100，因为在预训练权重基础上微调，100轮已经足够收敛，再增大训练时间成本高、精度收益小。imgsz取640是速度和精度的平衡点，取960会提升小目标检测能力，但训练和推理耗时都明显增加。batch=16在8GB显存下刚好跑满。优化器我选AdamW，比默认的SGD收敛更快，对这次类别均衡的数据集表现更稳。
数据增强方面，ultralytics默认开启mosaic、翻转、HSV扰动等策略。这里有个值得注意的细节：mosaic增强会把四张图拼接成一张，让小目标变得更小。番茄叶片目标本身不算小，但早期病斑相对整个画面来说是典型小目标，mosaic叠加后病斑特征会变得更加微弱。训练前期mosaic增强有助于提升泛化能力，不用关，但训练后期建议自动关闭，ultralytics会在最后10个epoch自动停用mosaic，这个设计很合理，不用手动干预。
5. 训练结果与问题排查：指标是表象，错误模式才是关键
5.1 训练曲线和关键指标的实测结果
训练完成后，我第一件事就是看results.png里的四张曲线图：box_loss、cls_loss、dfl_loss都应该是平滑下降后趋于平台期，val_loss没有明显回升就说明没有过拟合。这套配置下，100个epoch结束大概需要跑一个半小时到两个小时，最后收敛的指标大致在mAP50接近0.92、mAP50-95接近0.78的水平。对于3100张规模的农业检测数据集来说，这个成绩已经相当能打。
看指标不要只看mAP，还要看各个类别的单独表现。我习惯在训练结束后生成一张按类别的PR曲线。如果发现某个类别mAP明显低于平均值，基本可以断定这个类别是当前模型的短板，要么是类内样本多样性不足，要么是标注标准不一致，要么是类间特征过于相似。从我的结果来看，early_blight和late_blight早期阶段的互相误检是最主要的误差来源，这个下面详细说。
5.2 混淆矩阵里的典型误检模式分析
混淆矩阵是排查模型错误模式最好用的工具。我发现模型出了两类典型问题。
第一类是早疫病和晚疫病的早期症状混检。两种病在发病初期都是不规则褐色小斑点，在640分辨率的输入下，模型很难提取到足以区分二者的纹理特征。这实际上是农艺学上都会遇到的难题——早期症状用肉眼都容易搞混，让模型光靠小尺寸图片学区分确实强人所难。针对这个，我后续的迭代方向是增加一批人工标注的早期症状特写图，并且把这两类的标注阈值统一。
第二类是健康老叶被误判为早疫病。西红柿植株下部的老叶在正常生长周期中就会自然黄化和边缘干枯，这种叶片模型很容易当成病斑。这类误检在巡检场景里危害很大，会把本来健康的植株识别成发病，导致农户打不必要的药。排查清楚后，我调整了标注策略：健康类中尽量多收录一些“看起来有点吓人但其实是正常衰老”的叶片，同时把早疫病类别中病斑面积过小的样本做了二次确认。
5.3 我在训练过程中踩过的三个坑
第一个坑是标注框超出图像边界。LabelImg里框选目标时，如果叶片延伸到图片边缘外，标注框的坐标会超出图片尺寸。YOLO训练脚本对这类标注的处理是直接过滤掉越界框，不会报错，但会静默丢样本。排查方法很简单：转换脚本里加一个越界判断，把越界框裁剪回图像边界内。
x_center = min(max(x_center, 0.0), 1.0) y_center = min(max(y_center, 0.0), 1.0) width = min(width, 1.0 - x_center) height = min(height, 1.0 - y_center)第二个坑是验证集划分前没有去重。前面提过，连拍产生的相似图片如果不做组级划分，验证集会混入和训练集高度相似的样本，导致验证指标虚高。我吃过这个亏，后来老老实实按pHash分组再划分。
第三个坑是训练过程中显存溢出。batch=16在RTX 3060 Ti上没问题，但想加batch到32就爆了。有人说用梯度累积可以解决，ultralytics确实支持，但梯度累积会拖慢训练速度，实际效果也不如直接调小batch明显。最后的方案是保持batch=16，把mosaic增强的拼图数量从4张改回2张，显存压力缓解了很多。
6. 从笔记本到田间：部署与持续迭代的落地经验
6.1 边缘设备选型：不是所有设备都适合跑YOLOv8
模型训练完只是第一步，智慧农业巡检真正考验的是部署环节。我在Jetson Orin Nano、树莓派4B和手机端三种平台上都做过测试。
Jetson Orin Nano是当前性价比最高的选择，8GB内存版本能跑TensorRT加速后的YOLOv8n，FP16精度下推理速度能到30到40 FPS，完全满足巡检车实时检测的需求。树莓派4B性能就弱很多，跑ONNX Runtime的YOLOv8n大概只有8到10 FPS，做定点拍照抽检可以，实时视频流就别指望了。手机端用NCNN转换后速度不错，但开发成本和传感器适配成本都更高，除非产品形态是手机App，否则不建议优先考虑。
6.2 TensorRT转换和推理精度损失
Jetson上部署我走的是YOLOv8n -> ONNX -> TensorRT的路线。导出ONNX的官方命令很成熟，只要注意输入尺寸固定和batch=1就行：
yolo export model=best.pt format=onnx imgsz=640然后TensorRT需要用trtexec来做engine转换，FP16模式下精度损失很小，mAP基本不掉，速度却能提升接近一倍。转换完成后一定要做一次端到端验证：把测试集图片放到部署设备上跑一遍inference，统计输出结果和训练时验证指标的差距。不要只看推理速度，实际部署中容易遇到的问题是NMS后处理里的置信度阈值设置和训练时不一致，导致部署端漏检比训练指标严重得多。我最终把conf_thres设为0.25、iou_thres设为0.45，和训练验证时保持一致，效果最稳定。
6.3 真实大棚里的效果回落与迭代节奏
模型拿到真实大棚里，效果一定会比测试集指标打折，这不是你一个人的问题，而是农业视觉项目的普遍规律。我实测下来主要遇到三个变化：一是早上和傍晚的光线色温与训练集差异大，漏检率升高；二是不同品种番茄的叶片颜色、厚度、光泽度有差异，模型出现陌生感；三是无人机俯拍视角下叶片重叠严重，检测框互相挤压导致目标丢失。
针对这些问题，迭代策略比模型调参更重要。我的做法是每轮巡检收集现场误检图片，按周为单位人工筛选补充进数据集，每2到4周用新增数据重新训练一轮。这样形成“采集-标注-训练-部署-反馈”的闭环，模型才会越来越贴合实际场景。
另外如果你计划把这份数据集用于自己的项目，有几点建议供参考：检测任务之外的硬性指标要提前定好，比如最低召回率、单帧推理耗时上限；类别定义不要随意改动，改一个类别意味着整个数据集要重新标注一遍；训练前务必确认数据划分的独立性，否则后续所有指标都会失真。农业视觉项目的核心瓶颈从来不在模型结构，而在于数据能否真实反映田间地头的复杂性。把数据基础打扎实了，后面每一步都会顺畅很多。
