柑橘病害识别这个题目看上去是典型的计算机视觉分类任务但实际做下来涉及的东西远比想象中多。数据怎么采集、类别怎么定义、模型选什么结构、训练到什么样的精度才算“能用”每一步都有不少门道。我最初接手这个课题的时候以为把公开数据集跑通就完事了结果发现真实场景下要解决的问题完全不是训练集准确率那一回事。这篇就围绕“基于深度学习卷积神经网络的不同柑橘病变识别”这个项目把从选题拆解到最终交付的全过程梳理一遍给正在做类似毕设或者图像分类项目的同学一个完整的参考。1. 课题拆解从题目里能读出哪些关键信息1.1 题面背后的三层需求先说题目本身。“基于深度学习卷积神经网络对不同柑橘病变识别”这个表述核心关键词拆开来看就三个深度学习、卷积神经网络、柑橘病变识别。深度学习是方法论卷积神经网络是具体工具柑橘病变识别是应用场景。但作为毕业设计仅仅做到“跑通一个模型”是不够的审阅老师真正想看的是你完整走了一遍工程项目流程数据采集与处理、模型设计、训练调优、评估分析、问题排查这套体系化的能力才是毕设的核心价值。从行业角度看柑橘病害识别这个场景有明确的现实意义。柑橘类水果的病害种类多、表现相似度高比如溃疡病和疮痂病在叶片早期症状上非常接近即使是有经验的种植户也需要仔细观察才能判断更不用说普通农户。传统做法依赖植保专家的经验但专家数量有限覆盖不了广大产区。而基于深度学习的方法只要数据足够、模型训练到位就可以在几秒内完成单张图像的病害分类辅助农户做初步诊断。这也是这类课题在农业信息化领域持续热门的原因。再从技术角度看这个课题覆盖了深度学习的核心模块。图像分类是最基础的计算机视觉任务恰好适合用来理解和掌握CNN的工作机制同时又留出了足够的优化空间——可以在数据增强、迁移学习、模型轻量化等方向上做扩展。难度适中既不会让初学者无从下手也不会因为太简单而缺乏技术深度作为毕业设计课题是一个很平衡的选择。1.2 为什么是CNN而不是传统图像处理方法选CNN之前有必要先搞清楚一件事为什么传统的图像处理方案解决不了这个问题。早期做病害识别常见的手工特征方案是颜色直方图加支持向量机SVM或者提取纹理特征比如灰度共生矩阵加随机森林。这类方法在小规模、受控环境下的数据集还能跑出不错的效果但一旦遇到田间拍摄的照片就很容易翻车。原因在于手工特征的设计依赖开发者的先验知识。你要事先知道病害的表征是什么——颜色偏黄有斑点叶脉异常但实际上病害的外观变化极大受光照、拍摄角度、叶片成熟度、相机型号等因素影响同一病害在不同条件下拍摄出来的图像差异甚至比不同病害之间的差异还要大。手工设计一个通用的特征描述子来覆盖这种复杂度几乎是不可能完成的任务。CNN的方案从根本思路上改变了这个问题。不是人工指定特征而是让网络自己从数据中学习特征。浅层卷积核学到的是边缘、纹理、颜色块这类低级特征深层卷积核则能够组合出斑块形状、病变区域分布这类高级语义特征。这种由数据驱动自主学习特征的方式在图像分类任务上远胜于手工特征尤其适合果园这种光照变化大、背景复杂、拍摄条件不固定的现实场景。而且主流框架对CNN的支持已经非常成熟PyTorch、TensorFlow都有完善的预训练模型库和训练工具链工程实现成本并不高。这里也顺便说一句如果你做课题对比实验用SVM之类的传统方法做baseline对比是很合理的但不要期望它打赢CNN。对比实验的意义在于展现不同方法在精度上的差距突出深度学习方案的优越性这是课题逻辑的一部分而不是给自己挖坑。2. 数据准备整个项目的胜负手2.1 数据集从哪来如何构建类别体系做图像分类项目数据永远是第一个门槛。柑橘病害识别课题的数据来源通常有三个渠道。第一个是公开数据集最常见的是某高校开源的柑橘病害图像数据集包含健康叶片以及多种病害叶片的分类图像大概有数百张到数千张不等。第二个是自己采集有条件的话去果园、农场实地拍摄或者向当地农业技术推广部门获取资料。第三个是爬取互联网图片通过搜索引擎、农业知识库等渠道批量获取但这类数据噪声大需要大量人工清洗。数据集的类别体系设计是这个阶段的重点。根据常见柑橘病害类型可以划分为健康、溃疡病、疮痂病、黑星病、炭疽病、黄龙病等类别。这里有一个关键点是类别怎么定直接决定了后面模型学什么。如果类别定义太粗比如把各种叶部斑点全部归为“叶斑病”一类模型可能学不到有区分度的特征如果分得太细每一种病害图像数量不够又会导致训练不充分。一个比较稳妥的做法是参考植物病理学的标准分类优先保证主要几类病害的样本数量均衡其余类别根据数据量决定是否合并。实际操作中我建议数据量至少达到每类300张以上的原始图像。这个数字不是拍脑袋定的而是在很多实际项目里验证过的下限。CNN虽然本身有一定的平移、旋转不变性但训练时能看到多少种不同的形态变化直接决定了它在真实场景下的泛化能力。如果每类只有几十张图即使勉强训练完毕测试集上也能跑出不错的数字但换一批新拍摄的图像立刻就会暴露问题。数据量不足时优先考虑数据增强来扩充但数据增强不能完全替代原始数据的多样性二者要配合使用。2.2 数据清洗与增强的实操细节数据集的原始图像质量参差不齐清洗这一步不能省。常见的清洗操作包括过滤重复图像、删除与主题无关的图像、剔除标注错误的图像。标注错误的图像是最容易忽略的问题。比如下载的图片里图片本身是另一种病害但文件名标注的是溃疡病这种错误如果不清理模型会学到错误的特征映射直接影响准确率。我当时的做法是清洗阶段把每个类别的图像按目录浏览一遍花一下午时间人工过目全部图片发现可疑的直接挪到待定文件夹再做二次判断。数据增强的选择需要针对柑橘叶片图像的特点来设计。翻转、旋转、缩放、裁剪、色彩抖动这五类是最基础的标配。翻转和旋转解决的是叶片拍摄角度变化的问题随机裁剪增加模型对局部特征的感知能力色彩抖动则能增强模型对光照变化的鲁棒性——同样一种病害在晴天和阴天拍摄出来的色调差异很大没有色彩抖动训练出来的模型对光线非常敏感。这里说一个容易被忽视的点数据增强的参数设置要合理。随机旋转的角度范围设在20度以内比较合适。柑橘叶片虽然有各种姿态但超过45度的大角度旋转在真实场景中并不常见过度的旋转增强反而会让模型学到不符合实际的形态变化增加收敛难度。同样的道理裁剪比例不要太小保留原图至少70%以上的区域否则裁剪出来的局部块可能丢失关键的病灶特征。使用PyTorch的torchvision.transforms可以很方便地组合这些增强操作参考代码如下from torchvision import transforms train_transforms transforms.Compose([ transforms.RandomResizedCrop(size224, scale(0.7, 1.0)), transforms.RandomHorizontalFlip(p0.5), transforms.RandomVerticalFlip(p0.3), transforms.RandomRotation(degrees20), transforms.ColorJitter(brightness0.2, contrast0.2, saturation0.2), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ])数据集的划分同样要讲究。按照训练集、验证集、测试集6:2:2的比例进行随机划分划分时按照类别做分层采样确保每个类别在三个集合中的比例一致。这里有个小细节划完分之后随手把训练集里各分类的样本数量打印出来检查一遍防止某几类图像特别少导致类别不均衡问题在训练阶段被放大。3. 模型选型与网络结构设计3.1 从零训练还是迁移学习模型结构的选择是这个课题最核心的技术决策。面临的一个基本问题是从零训练一个CNN还是使用预训练模型做迁移学习。对这个课题来说结论非常清晰不做迁移学习就是自己给自己增加难度。从零训练需要海量数据。现代CNN模型的参数量动辄数百万甚至上亿要在如此大的参数空间中收敛到一个好的解需要充足的训练样本。而柑橘病害分类数据集通常只有几千张图像从这个规模来看从零训练的概率是很快就陷入过拟合。虽然理论上可以通过大量正则化和数据增强来缓解但效果远不如迁移学习直接。迁移学习的基本思路是先在大规模通用数据集上训练好一个模型让它具备强大的通用视觉特征提取能力然后把这套能力迁移到柑橘病害这个具体任务上。对于ImageNet预训练模型来说它已经学会了边缘、纹理、颜色、形状等通用特征这些底层特征在不同视觉任务之间是共享的。我们只需要把模型顶部的全连接分类层换成适合自己任务的结构然后用柑橘病害数据微调整个网络或者只微调后半部分就可以在较少的迭代次数内取得很好的效果。具体实现上ResNet系列是最稳妥的选择。ResNet50在ImageNet上表现优秀结构经典被GitHub和各大教程作为默认选项遇到问题时也容易找到参考资料。如果对推理速度有要求可以考虑MobileNetV3或者EfficientNet这类轻量化模型。我在项目里用的就是ResNet50实测效果稳定训练收敛速度快作为毕设项目的默认选择完全够用。3.2 模型结构的调整策略加载预训练模型之后需要对网络结构做一些调整。以PyTorch为例ResNet50的最后一层全连接层输出维度是1000对应ImageNet的类别数需要替换成对应柑橘病害类别数的全连接层。import torchvision.models as models model models.resnet50(pretrainedTrue) num_classes 6 # 健康 5种病害 model.fc torch.nn.Linear(model.fc.in_features, num_classes)这一步操作本身很简单但背后有一个值得理解的问题为什么只替换最后一层而不是重新设计整个网络。原因在于CNN网络的前面部分提取的是通用特征最后几层才在做类别相关的语义判别。保留前面几十层预训练权重相当于保留了模型“看图”的能力替换最后一层相当于更换模型的“判断标准”。这种组合方式既保留了通用视觉能力又让模型能适应特定的分类任务。迁移学习还有一个策略选择冻结前半部分只微调后半部分还是全部参数参加训练。如果数据集很小比如每类只有一两百张建议冻结前面大部分层只训练最后两三个block和全连接层防止小数据量微调时破坏预训练特征。如果总数据量在千张以上就可以让全部参数参加微调但学习率要设置得小一些比如初始学习率设为0.0001而只训练最后一层时可以用0.001。我实际这样操作。把ResNet50分成两段来考虑前面4个layer的参数用较小的学习率微调把学习率乘子设为0.1最后一层全连接层用正常学习率训练。这样既让预训练特征根据柑橘病害数据做了一定调整又不会因为学习率太大而破坏了预训练权重的稳定性。这些细节可以在PyTorch中通过设置不同层组的参数来实现参考代码逻辑optimizer torch.optim.SGD([ {params: model.conv1.parameters(), lr: 1e-5}, {params: model.layer1.parameters(), lr: 1e-5}, {params: model.layer2.parameters(), lr: 1e-5}, {params: model.layer3.parameters(), lr: 1e-5}, {params: model.layer4.parameters(), lr: 1e-5}, {params: model.fc.parameters(), lr: 1e-4} ], momentum0.9, weight_decay1e-4)4. 训练过程的完整记录4.1 训练超参数配置详解训练阶段涉及一批超参数。Batch size、学习率、优化器、迭代轮数、学习率调整策略这些参数的设置直接决定训练的质量和速度。我把实践中验证过的配置和踩过的坑一起说清楚。Batch size的选择受限于GPU显存。常用的消费级显卡显存在6GB到12GB之间ResNet50输入224x224分辨率的图像Batch size设为32在8GB显存上比较合适16也可以稳定运行。Batch size大小会影响梯度的平滑程度——Batch size太小梯度波动大训练不稳定太大则容易收敛到尖锐极小值泛化能力反而可能下降。6GB显存跑ResNet50Batch size设32已经是一个合理的均衡点。优化器方面SGD加动量是图像分类任务上经得起考验的组合。Adam收敛速度快但最终精度往往略逊于调好的SGD尤其在小数据集上更明显。动量系数0.9是PyTorch默认值也可以保留。Weight decay设为1e-4起到正则化作用防止模型过拟合。学习率是最敏感的超参数。迁移学习场景下学习率过大容易导致预训练权重剧烈震荡前几轮训练就能看到损失函数乱跳太小则收敛极慢跑了20个epoch还在原地踏步。我最后采用的方案是初始学习率0.0001加上余弦退火调度每一轮训练结束后根据验证集Loss决定是否降低学习率也可以用自适应调整策略。模型训练过程中一个重要原则是监控验证集指标而不是训练集指标。训练集Loss下降而验证集Loss不降反升这是过拟合的典型信号此时应该提前停止训练或者降低学习率。Early Stopping是一个很实用的策略比如连续5个epoch验证集Loss没有下降就暂停训练并恢复到验证集性能最好的那个epoch的权重。4.2 训练曲线分析和调优方向训练过程的记录和可视化是整个项目中最能体现工程能力的部分。建议在每次epoch结束后记录训练Loss、验证Loss、训练准确率、验证准确率绘制成曲线图这些图既帮助你分析模型状态也是最终论文里最有说服力的实验证据。一个典型的正常训练曲线是这样的前几个epoch验证准确率快速上升从随机猜测的水平涨到80%以上随后几轮提升速度放缓在90%左右波动Loss对应的下降趋势类似前期快速下降后期趋于平缓。如果出现了验证准确率在某个数值附近波动不再提升的情况常见原因有三个学习率过大导致Loss震荡数据集本身存在标注噪声类别不均衡导致模型对少数类拟合不足。逐个排查就好先降低学习率再检查数据分布最后分析混淆矩阵看具体哪些类别互相混淆。训练设置的轮数不用太长小数据集迁移学习场景下30到50个epoch就能看到收敛趋势。不需要一上来就跑200个epoch那是浪费时间。先用较小的训练轮数验证代码没有报错、数据加载正常、训练曲线在合理范围内确认整体流程通畅后再加大训练轮数也不迟。我一开始就犯过这个错代码存在隐蔽的问题直接跑了30个epoch白白浪费了时间。5. 常见问题与排查经验5.1 过拟合和数据不均衡柑橘病害识别项目里过拟合和数据不均衡是最常见也最影响最终效果的两个问题。二者经常同时出现互相加剧。过拟合的表现是训练集准确率接近100%但验证集或者测试集准确率明显偏低差距在10个百分点以上。缓解手段按效果排序是增加数据量或增强强度、降低模型容量、加大正则化、采用更激进的Dropout。数据增强方面可以试试引入随机擦除Random Erasing或者MixUp这类高级增强手段能有效提升泛化能力。在最终提交的代码里体现这些技巧也很容易在答辩时成为加分项。数据不均衡的问题在于模型偏向多数类。如果健康叶片图像有1000张某种病害只有100张模型倾向于把不确定的样本都预测为健康类因为这样总体的准确率仍然是高的。解决这个问题最简单的办法是在数据源头增加少数类的图像数量。如果采集不到更多数据可以考虑在损失函数层面调整使用加权交叉熵损失给少数类更高的权重或者采用Focal Loss降低容易分类样本的权重迫使模型关注难分类的少数类样本。我当时的做法是先用Count频次检查各类别数量发现有一类病害图像明显偏少之后针对这个类别单独加强了增强策略并且在训练时启用了类别权重最终效果改善很明显。两类措施结合使用比单独用任何一种都要有效。5.2 训练速度慢和硬件资源不足做深度学习毕设的同学经常遇到的现实问题是硬件不够。常见的卡顿场景是训练一个epoch耗时过长或者显存不足直接OOM报错。我的建议是分清问题类型再对症下药。显存不足OutOfMemoryError时优先缩小Batch sizeBatch减小到模型输入的最小可用值比如8或者4能解决大多数OOM问题。如果仍然不够再考虑降低输入分辨率从224降到192甚至160虽然会略微降低精度但并不会导致任务不可用。还有一招是用梯度累积来模拟更大的Batch size若干个Batch累加梯度后再更新参数这个技巧可以解决显存小但想要较大Batch size训练的矛盾。训练速度方面代码层面的优化空间要优先于硬件更换。数据加载改用DataLoader的num_workers参数实现多进程并行加载把预处理放到CPU端执行GPU就不用等待数据而空转。输入图像可以用WHC格式的numpy数组或者PIN memory方式加速CPU到GPU的数据传输。如果这些手段都用上之后训练还是太慢那就需要砍模型的容量比如从ResNet50换成ResNet18或者用MobileNetV3对于柑橘病害这种相对简单的分类任务轻量模型的精度损失不大但训练速度能快数倍。6. 评估指标与结果分析6.1 指标选择不只是准确率毕设论文里最常看到的就是“模型最终准确率达到98%”这一个指标打天下。但对于分类任务尤其是存在类别不均衡的分类任务只看准确率有很强的误导性。比如测试集中健康叶片占了60%一个把所有样本都预测为“健康”的模型准确率也能到60%你会觉得它根本没有学任何东西但这个数字并不会暴露问题。所以完整评估一个模型最好同时看多个指标。精确率Precision和召回率Recall的组合才是判断模型是否真正有效的关键。精确率衡量的是“预测为某病害的样本中有多少真的是该病害”召回率衡量的是“该病害的真实样本中有多少被正确找出来了”。一种病害的召回率低意味着这个病害经常被漏掉在实际场景中这比误报更严重——漏报会让病害得不到及时处理造成蔓延。引入F1-Score作为综合指标它同时考虑到精确率和召回率适合作为类别不均衡情况下的主指标。对于这个课题来说宏平均F1Macro-F1是一个合适的总评价指标。宏平均把所有类别的F1值算出来取平均不因多数类样本多而降低少数类的影响能更真实反映模型在所有类别上的平均表现。6.2 混淆矩阵与错误案例混淆矩阵是分析模型错误的最直观工具。横轴是预测标签纵轴是真实标签对角线越集中说明模型分类越准确。对角线以外的数值就是模型真正要改进的地方。我在项目里看到的最典型错误是把溃疡病和疮痂病互相混淆这两类病害在叶片上的症状都是斑点且颜色相近非常容易误判。另一边是黄龙病和缺素症的混淆这两种情况的叶片黄化表现非常接近但成因完全不同一个是病原体感染一个是营养失衡。这类错误暴露的是训练数据本身的局限——需要更细致、更有区分度的特征来区分这些近似类。分析错误案例时有个实践技巧把预测错误的图片单独保存成文件夹按错误类型归档然后批量浏览。在这个过程中很容易发现常见问题比如图像的背景噪声太大导致模型关注了背景纹理而不是叶片本身或者是病害出现在早期症状很轻的阶段肉眼都很难判断模型自然也无法准确分类。这些发现可以直接写进论文的“错误分析”章节这也是评委愿意看到的真实分析过程而不是只放一张完美的结果表格。如果错误分析之后需要进一步提升精度可以考虑在模型结构上增加注意力机制比如在ResNet中加入CBAM模块让网络更关注叶片上的病害区域而不是整幅图像的背景信息。这个在实验上通常会有一个百分点的精度提升大约两三个百分点的性能提升代价是模型计算量增大了而损失的这部分计算量对硬件的要求实际工程中大概率也在可以接受的范围内。7. 部署与真实场景测试从实验到落地7.1 模型导出与推理流程训练完成的模型需要落地到实际场景才能体现价值。针对这个课题一个合理的应用形态是用户拍摄一张柑橘叶片的照片通过网页或小程序上传后端调用训练好的模型推理返回病害类别和置信度。这个流程组合了前端界面和后端服务技术栈完整而且演示效果直观。模型推理的代码核心是加载训练好的权重文件将图像预处理后输入模型取Softmax输出的最大值作为预测结果。PyTorch官方代码风格大概这样import torch from PIL import Image from torchvision import transforms model.eval() image Image.open(leaf_sample.jpg) transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) input_tensor transform(image).unsqueeze(0) with torch.no_grad(): output model(input_tensor) prob torch.softmax(output, dim1)模型导出的时候建议在训练后固定住模型的BatchNorm层参数调用eval()模式来测试。训练阶段和推理阶段BatchNorm层的行为完全不同——训练时用当前Batch的统计量做归一化推理时用历史数据的滑动平均统计量。如果没有切换到eval模式推理结果会异常这是一个高频错误我用过好几次都是这个原因。7.2 测试集的真实表现与干扰因素部署完成后最关键的一步是用独立的测试集衡量模型在真实场景中的表现而不是用训练时的验证集结果。测试集最好使用新采集的图片这样能客观检验模型对未见数据的泛化能力。我在测试时故意混入了一批低分辨率图片和强光照干扰的图片模型的准确率从验证集上的96%左右降到了91%左右。这个下降幅度在合理范围内但暴露了模型的抗干扰能力还有提升空间。真实场景中用户拍摄的图像质量不会像数据集里那样规整。手机拍摄时的对焦不准导致图像模糊、叶子背面有阴影遮挡、背景杂乱导致目标区域不完整这些都是常见问题。建议在预处理阶段加入质量判断逻辑对过暗、过糊或目标区域占比过小的图像直接提示用户重新拍摄。这一层逻辑虽然不增加模型的精度但能让整个系统的使用体验显著改善。识别结果呈现阶段除了给出类别标签之外还应该输出置信度。置信度低于一个阈值比如0.8时界面提示“结果不确定建议上传清晰图像或咨询专业人士”。这种做法在AI落地场景中是非常必要的能避免低置信度下强行给出误导性诊断。模型会犯错系统要通过设计来管理错误的影响这是真实工程项目和实验室实验的本质差异。8. 答辩准备与论文写作要点8.1 实验对比怎么设计最有说服力毕业设计的答辩环节老师们关心的核心问题通常是你做的课题有什么意义用了什么方法实验结果好不好技术难点是什么实验对比的设计决定了第三个问题能否有说服力。一套合理的实验设计包含三层对比。第一层是方法对比把传统图像处理方法如SVM加HOG特征作为baseline与CNN方案做精度上的对比。这一层对比的意义是说明为什么深度学习更适合该任务。第二层是模型结构对比比如对比VGG16、ResNet50、MobileNetV3在相同数据集上的表现差异这能体现你对模型选型的判断力而不是只会照抄。第三层是消融实验分别去掉数据增强、去掉迁移学习、去掉类别权重采样观察每个模块对最终结果的影响。这一层最具技术含量因为它证明你不是只堆效果而是理解了每个组件的作用。三个层次的工作量每层两三组实验加上数据预处理和训练时间整体算下来是可控的但对论文说服力的提升非常明显。在答辩展示时把三组实验的表格对照呈现评委一眼就能看出你的工作量和技术深度。8.2 论文写作的一些经验论文里实验数据要真实可复现。所有实验都用固定的随机种子跑一次记录环境依赖的确切版本这部分内容放进附录附录里既不占正文篇幅又能体现工程规范。常见训练种子设置的经验值是42之所以设置随机种子既便于别人复现实验也便于自己在调整结构之后比对实验结果。结论部分不能只写“模型准确率达到XX%”。结合错误分析写清楚模型在哪些类别上表现好、在哪些类别上容易出错、为什么出错然后提出可能的改进方向。这种写法比写一句空泛的总结更有价值也是答辩时应对老师提问的重要底牌。在训练过程中保留模型不同epoch的检查点文件做一个中间过程的展示页或者制作一张训练曲线动态变化的图表这类过程性资料能够证明实验过程的真实性。8.3 答辩常见问题和准备方向预判答辩问题要站在评委角度想。最容易被问到也最值得提前准备的是以下几类问题第一类“你为什么选这个模型而不选别的模型”。准备思路是横向对比ResNet、VGG、MobileNet在精度、参数量、推理速度上的差异并能解释选择ResNet50的理由。不要只说“它效果最好”这会被追问“好在哪里”。第二类“数据增强对结果的影响有多大”。准备思路是展示消融实验数据比如去掉随机旋转后验证集精度下降了多少再解释为什么下降。这类问题在答辩中出现的频率很高因为老师能从问题中看出你到底是不是自己动手做的实验。第三类“模型的不足之处和可能的改进方向”。这个问题除了说数据量有限之外更重要的是给出有建设性的思路比如引入注意力机制、使用更细粒度的病害分期分类、结合叶片和果实的多部位信息等。这体现的是你对课题的深度思考而不只是完成了规定动作。第四类“如果部署到手机端需要考虑什么问题”。可以从模型轻量化、推理加速、离线运行三个角度回答展示开发的完整思维。提前准备一个实际可达的轻量化方案比如知识蒸馏或者对模型进行剪枝量化。9. 一些实操心得和扩展方向整个项目做完之后我感受最深的一点是数据决定效果上限模型只是逼近这个上限的手段。一开始我认为用更高级的模型就能提升准确率后来换了几种结构效果差异并没有想象中大。真正让我看到指标明显变化的是扩充了数据集、清洗了错误标注、使用了更贴合场景的数据增强策略。在模型复杂度达到一定程度之后数据层面的投入效率远高于模型的优化这在所有小规模图像分类任务里都成立。硬件配置普通也完全不影响完成这个课题。单块中端显卡完全可以支撑训练没有独显的话使用云端训练平台也是一条可行的路。我对接过一次免费的云端算力体验下来和本地训练差别不大关键是要把数据和代码组织好别把时间浪费在环境和调试上。如果想让这个课题锦上添花有几个扩展方向很适合作为后续工作。第一个是病害严重程度分级从“有没有病害”进化到“病害到什么程度”这在实际生产中更有价值。第二个是扩展到多种柑橘部位树叶和果实放在同一个模型里进行多任务或者多标签分类。第三个是引入目标检测模型识别复杂背景下的病斑区域再用分类模型判断病害类型两个模型串联增强模型的抗背景干扰能力。这些方向在毕设这个时间范围内都能展开一个小节的内容但需要安排好时间节奏不要影响主干试验的完成。到最后我想说用深度学习做柑橘病害识别不是一个只存在于论文里的项目。我把自己训练好的模型给一位做农业的朋友做测试他传了一批棚里刚拍的叶片照片给我模型预测的结果里有几个和实际植保人员的判断完全一致。那一刻我才意识到这类课题的技术含量本身是一方面更值得的是深度学习从数据集到应用链路走完后真正帮到现实场景的满足感。正在做这个课题的朋友也不妨在训练完成之后真正去采集一批新照片来检验一下你的模型。用到真实场景里去的那一天这个项目才算真正的结束。
