做槟榔、做瓜子、做花生坚果分选的朋友应该都有一个共同感受传统人工挑拣花生霉变颗粒不仅费眼而且标准非常不稳定。同一个工人上午和下午的判断标准都能差出一截更不用说换班之后了。所以当有人问我能不能用深度学习快速做一个花生霉变检测系统时我的第一反应不是直接甩一个训练脚本而是先想清楚一个问题我们到底要机器替代人工的哪一部分是单纯把肉眼判断变成模型判断还是要把从进料、拍照、识别到分选的全流程都串起来这次我基于YOLOv11做了一套完整的花生种子霉变检测系统覆盖了数据采集、标注、训练、评估再到带登录注册的UI界面部署。项目核心用到了YOLOv11深度学习模型配合YOLO格式数据集整体代码基于Python实现。下面把整个环节里踩过的坑、做过的取舍、以及一些容易被忽略的细节都写出来希望给正在做农产品质检类项目的朋友一点参考。1. 花生霉变检测的真实痛点为什么一个二分类不够用1.1 产线上人工分拣到底差在哪花生霉变这件事比想象中复杂。很多人以为霉变就是“长毛了、变黑了”但实际在产线上遇到的样本千奇百怪有的是表面出现黄褐色斑块有的是胚芽部位发暗有的是整体颜色发灰还有的只是局部油光异常。更麻烦的是有些花生表面看起来好好的切开后内部已经霉变——当然这类靠视觉本身就很难处理项目初期就不纳入范围。人工分拣的瓶颈在于持续注意力。一个工人坐在传送带旁边八小时盯着花生看前两个小时准确率还行后面就开始麻木。按每分钟过手几百粒的量来算漏检率会明显上升。而且花生大小、品种、表面纹理差异大新工人和老工人的判断标准很难统一质检记录也很难追溯。这套系统想解决的核心问题就是把“依靠人眼和经验”变成“依靠模型和阈值”让检测结果可量化、可复现。模型输出的每一帧检测结果都可以落日志任何一个批次的花生有多大的霉变比例随时能查。1.2 系统要做到什么程度才算能落地做一个演示Demo很容易难的是做成现场能用的东西。我给自己定的目标是拿着笔记本接一个USB摄像头对着托盘里的花生拍一下就能在界面上看到每一个霉变颗粒被框出来同时统计出霉变数量、霉变率还能登录账号、记录检测历史。从功能上看这套系统需要四块内容能够识别“正常花生”和“霉变花生”的检测模型能够框出霉变颗粒位置并提供置信度的推理逻辑一个操作简单的图形界面支持图片检测、摄像头实时检测、历史记录查看一个登录注册模块区分不同操作员的使用权限。也就是说算法能力只是其中一环工程化能力同样重要。如果模型精度再高但UI难用、结果不可追溯在产线上是推不下去的。1.3 为什么选择目标检测而不是图像分类一开始有人建议直接用图像分类把整张图丢给网络判断“有没有霉变”。但对于实际场景分类有两个硬伤第一如果托盘里同时有10颗正常花生和1颗霉变花生分类模型只能告诉你“这盘有问题”却没法告诉你是哪一颗有问题后续根本没法做分选第二分类模型对目标大小很敏感霉变区域在整张图中占比很小模型很容易被背景干扰。目标检测天然适合这类任务。它能在图中定位出每个目标的位置和类别尤其在花生这类小目标密集、个体边界清晰的场景下YOLO系模型是相当成熟的选择。我要做的就是在目标框的类别标签上做文章把“花生”和“霉变花生”分开甚至可以进一步细分“表面霉斑”“整粒霉变”等类别。2. YOLOv11选型决策v5、v8、v11之间的对比与适配性分析2.1 不同版本的能力差距没有想象中大开始动手之前我把YOLOv5、YOLOv8和YOLOv11都跑了一轮简单的对比实验。惊讶的是在花生霉变这种特征比较明显的任务上三者的精度差距其实很小真正拉开差距的是训练效率、推理速度和工程便利性。YOLOv5胜在稳定生态老资料多但代码风格相对陈旧YOLOv8在工程结构上做了很多优化训练和导出都很顺手接口清晰YOLOv11则在检测头结构上和训练策略上做了进一步优化整体推理效率比前代更高尤其是在边缘设备上速度优势能体现出来。我给一个初步结论如果目标是快速上线一套单机系统选YOLOv11没有毛病尤其在CPU推理和低算力环境下它的性价比更突出。但如果你有大量历史标注数据都是YOLOv5格式继续用v5也完全没问题模型选型的收益远小于数据质量的收益。2.2 网络结构上值得关注的几个点YOLOv11和v8直观的区别在于C3k2模块替换了一部分C2f结构在保持特征提取能力的同时减少了计算量。另外v11在骨干网络和颈部网络的连接方式上也做了调整这种调整带来的实际效果是在同等精度下模型更轻量推理更快。以我用的YOLOv11n为例模型参数量很小在笔记本的GPU上推理一帧640x640的图延迟基本在十几毫秒量级如果用CPU也只要几百毫秒。对于静态图片检测这种场景CPU完全顶得住如果是实时摄像头视频流建议至少用一张入门级独立显卡或者把推理分辨率从640降到416。实际项目里我选了YOLOv11n而不是更大的s或m原因很直接目标特征简单不需要超大模型系统最终可能部署在没有独立GPU的工控机上模型越小越安全。n版本在精度上的损失靠数据和训练策略完全能补回来。2.3 预训练权重的迁移YOLOv11预训练权重是在COCO数据集上训练的包含80类常见物体。虽然COCO里没有花生霉变这个类别但预训练权重学到的底层特征——边缘、纹理、颜色渐变、局部形状——对花生表面病变识别非常有用。我选择在官方预训练权重基础上微调而不是从头训练。这样收敛快很多一般来说几十个epoch就能达到可以用的状态。如果从头训练至少要多花一倍的时间而且初期loss波动很大不容易判断训练是否正常。3. 数据集构建是真正的上限采集、清洗与标注规范3.1 现场采集拍照背景、光照和角度都得固定很多人觉得数据集构建就是“多拍点照片”实际上采集环境不一致会让模型学到错误的东西。我第一次采集的时候上午在窗边拍下午在灯下拍背景一会儿是白纸一会儿是黑色塑料托盘结果训练出来的模型把“阴影”学成了“霉变”换到现场环境直接没法用。正确的做法是模拟实际部署环境固定一块颜色单一的底板固定光源位置和色温固定摄像头高度和俯仰角。这样采集到的图像分布稳定模型学到的是花生表面的真实差异而不是环境变化。采集时要注意几个细节花生不能堆叠太厚尽量铺成单层让每一颗都清晰可见拍照角度要接近垂直俯拍避免侧面透视导致花生轮廓变形每一批样本尽量覆盖不同品种、不同产地、不同含水量的花生霉变表现会不一样。3.2 标注环节边界框和类别标签的规则标注是枯燥但极其重要的环节。我用LabelImg工具输出格式直接保存为YOLO格式的txt文件每行对应一个目标类别ID、归一化中心点x、归一化中心点y、归一化宽度、归一化高度。标注规则需要提前定死一颗花生如果只有局部霉斑框住整颗花生类别标为霉变如果一颗花生表面有黑点但不是霉变比如泥土残留不标如果花生已经严重皱缩、变色框出来并标霉变正常花生也要框出来类别为正常如果不框正常花生模型会认为背景里出现花生也无所谓。这里强调一下正常花生和霉变花生都要标注。有些项目只标霉变然后把所有没标的东西都当背景这样做的问题在于模型无法通过对比学习区分“正常”和“霉变”误检率会很高。只有同时提供正负样本模型才能真正学到两类之间的边界。3.3 数据增强与样本平衡霉变样本少怎么处理花生产线上霉变颗粒的比例通常不高可能只有百分之几到十几。这意味着如果随机拍照霉变样本会远远少于正常样本训练出来的模型会对霉变类别严重不敏感。解决思路有两个方向。第一在采集阶段做富集专门挑选霉变花生摆成密集托盘拍照让霉变样本在数据集中占到百分之三四十的比例。第二在训练阶段用数据增强YOLOv11自带马赛克增强、随机透视、色彩抖动、翻转等策略。对于霉变这种颜色敏感的特征色彩抖动增强要注意幅度别太大否则会把正常花生也抖动成“看起来霉变”的样子。我最终的训练集比例大约是正常样本占60%、霉变样本占40%。这个比例在训练初期效果比较好模型不会过度偏向某一边。3.4 数据集划分同一颗花生不能同时出现在训练集和验证集数据集划分有一个容易忽略的坑如果在拍照时同一颗花生被拍了好几张或者同一盘花生被不同角度拍摄这些图像之间高度相关。如果它们被随机打乱分到训练集和验证集验证集损失会虚低模型实际泛化能力被高估。我的做法是以“拍照批次”为单位划分数据。比如拍了30批花生按批次而不是按单张图片划分一批进入训练集另一批才能进验证集。这样验证结果更接近真实场景。划分比例方面我用了训练集70%、验证集20%、测试集10%的比例。测试集是最后模型全部训练完之后才拿出来评估的用来模拟真实场景。4. 模型训练与评估参数配置和结果判读4.1 训练环境和基本命令训练环境不需要太夸张。我用的是一台带有RTX 3060显卡的笔记本显存12G跑YOLOv11n毫无压力。如果显存只有6G可以把batch size调小或者把图像分辨率降到512一样能训。数据准备好之后需要在项目目录下建一个data.yaml文件内容大概长这样train: ./datasets/peanut/train/images val: ./datasets/peanut/val/images test: ./datasets/peanut/test/images nc: 2 names: [normal, moldy]这里需要注意路径建议写绝对路径避免训练时找不到数据集。类别顺序要和你标注时的类别ID保持一致顺序错了模型就白训了。训练命令相对简单yolo detect train datapeanut.yaml modelyolo11n.pt epochs100 imgsz640 batch16 device0如果只想验证流程是否跑通可以先跑10个epoch确认loss在下降再跑完整训练。4.2 超参数设置的经验Epochs我设了100但其实在60轮左右就已经基本收敛。早停机制很有用YOLO训练时可以直接配置早停参数当验证集损失连续多轮不再下降时自动停止省时间也防止过拟合。Batch size受显存限制16到32都可以。实测batch size从8提到32收敛稳定性更好精度也有小幅提升。学习率不需要手动调YOLO默认的自动学习率调度策略表现就不错。图像分辨率上我对比过640和1280两种1280在密集小目标上确实有精度优势但训练时间和推理时间都翻倍。对于花生这种目标尺寸比较大的场景640完全够用所以我最终选择了640。4.3 训练结果怎么看训练过程中最需要关注几个指标box_loss、cls_loss、以及验证集上的mAP50和mAP50-95。mAP50看的是预测框和真实框的IoU超过0.5时算正确的平均精度这个指标对工程落地最有参考价值mAP50-95更严格跨度从0.5到0.95学术对比常用但实际使用中目标框稍微偏一点并不影响识别结果如果训练集loss持续下降但验证集loss反而上升那就是过拟合应该早停或者增加数据增强。我这个项目的最终结果mAP50在0.96左右mAP50-95在0.78左右。这个成绩对产线筛选来说已经足够用了漏检率控制在可接受范围内。4.4 置信度阈值怎么定模型输出的是一个置信度分数一般默认0.25表示只有置信度超过25%的框才显示。但这个默认值不一定适合实际场景。如果把阈值调低比如0.1召回率会提高漏检变少但误检也会增加把阈值调高比如0.5误检减少但可能会漏掉一些表现不明显、模型信心不足的霉变花生。我的做法是在验证集上画PR曲线找到精度和召回率平衡的拐点再根据现场容忍度微调。一般来说花生霉变检测更怕漏检而不是误检所以阈值可以适当偏低。5. 系统集成登录注册、UI界面与实时推理5.1 为什么需要登录注册很多做模型的人会把登录注册当成“多余的界面需求”但在实际产线部署中这个模块是有实际意义的。工厂里操作员、质检员、管理员职责不同有的只需要运行检测有的需要查看历史记录有的需要调整检测参数用账号体系把权限分开是合理的。另外检测记录需要对应到人。如果一批花生被判定霉变率超标工厂需要知道是谁操作的、什么时候检测的方便追溯。没有登录机制就没有操作留痕出了问题说不清楚。实现上我用的比较简单的方式注册时把用户名和加密后的密码写入本地SQLite数据库登录时读取比对再用一个会话变量记录当前登录用户。对单机系统来说SQLite足够不需要额外部署数据库服务。5.2 UI界面功能划分整个界面我用了PySide6来做分左中右布局左边是功能面板和登录信息中间是图像显示区域右边是检测结果和统计信息。功能面板里有三个主要入口图片检测点击上传图片跑一次推理显示检测结果图和检测统计摄像头检测打开本地摄像头实时显示检测画面每隔几帧执行一次推理历史记录查看当前账号的历史检测记录包括时间、图片路径、检测到的霉变数量。界面底部还有一个大号的统计栏实时显示霉变数量、正常数量、霉变率方便产线工人一眼看到结果。5.3 推理后处理框、计数和标记模型推理返回的是每个目标的边界框坐标、类别ID和置信度。拿到这些数据之后不能只是画个框还要做几件事过滤置信度低于阈值的框按照类别ID分别计数统计正常数量和霉变数量在霉变框旁边标注置信度百分比方便人工复核对霉变目标按坐标排序输出它们在托盘中的大致分布位置。另外实时视频流推理时模型输出的坐标是相对于当前帧的如果画面有抖动检测框会跟着晃。这种情况下可以用相邻帧之间的检测结果做简单的平滑或者直接保持固定摄像头位置避免画面频繁移动。5.4 项目代码结构整个Python项目的目录结构大致如下peanut_detection/ ├── models/ # 存放训练好的模型权重 ├── datasets/ # 数据集和data.yaml ├── utils/ # 数据库操作、图像处理等工具函数 ├── ui/ # 登录界面、主界面代码 ├── detect.py # 模型推理封装 ├── train.py # 训练脚本 ├── login_window.py # 登录注册窗口 └── main_window.py # 主界面入口把代码拆开而不是写成一个几百行的脚本后面维护会省很多事。比如摄像头检测逻辑和图片检测逻辑可以共用detect.py里的推理函数界面部分只负责展示结果互不干扰。6. 部署过程中的真实踩坑记录6.1 检测框抖动和置信度波动第一次接上USB摄像头做实时检测时发现连续帧之间检测结果很不稳定同一颗花生一会儿被框出来一会儿没被框出来置信度在0.2到0.6之间跳。排查下来有几个原因首先是摄像头自动白平衡导致颜色在漂移花生表面的颜色特征跟着变其次是图像压缩噪声影响了小目标的特征最后是推理分辨率如果不够高模型对边缘模糊的目标信心不足。解决办法是把摄像头的自动曝光和自动白平衡关掉固定一组手动参数推理分辨率保持在640不变对相同位置的检测框做时间上的平滑比如连续三帧都检测到才确定是霉变。6.2 CPU推理速度不够怎么办如果在没有独立显卡的电脑上部署实时摄像头检测会明显卡顿。YOLOv11n在CPU上推理一帧640x640的图大约需要300到600毫秒换成摄像头30帧每秒的输入根本跑不过来。我的优化思路是“降帧率 降分辨率 跳帧处理”。摄像头采集帧率保持30帧但只对每3帧执行一次推理其他帧直接显示上一帧的检测结果画面看起来是平滑的实际推理压力一下子降了下来。如果还不够可以把推理分辨率从640降到416速度能提升将近一倍精度损失很小。6.3 温度和湿度变化带来的误检项目做到后期现场反馈说“今天误检变多了”。我跑到现场一看是因为当天湿度大花生表面凝结了一层水汽反光特征和干燥状态下差别很大模型的判断受到了影响。这个坑很难完全靠模型解决因为训练数据里没有覆盖这种环境变化。可行的方案是在部署机台上增加固定除湿或恒温手段或者在数据采集阶段就考虑加入不同湿度条件下的花生样本。工程上永远是数据和环境的问题模型只是映射了数据中的规律。7. 扩展思路与个人经验总结7.1 从二分类扩展到多分级目前系统只区分“正常”和“霉变”两类。实际产线上很多工厂还想区分“轻度霉变”和“严重霉变”因为轻度霉变可能经过处理后还能用严重霉变必须剔除。这个需求可以通过增加类别标签实现在标注时把霉变分成轻度和重度两类重新训练模型即可。如果还想更精细可以增加“破损”“发芽”等类别让一条产线同时完成多项质检。数据集标注工作量会增加不少但YOLOv11的多标签分类能力完全能支撑。7.2 模型导出的几种形式训练的模型除了在Python界面里使用还可以导出成ONNX格式部署到其他平台。用YOLO自带的导出命令就能完成yolo export modelbest.pt formatonnxONNX模型可以被很多推理框架加载比如在C程序里用ONNX Runtime推理或者部署到嵌入式设备上。如果以后有人要求脱离Python环境运行导出ONNX是一条必经之路。7.3 做这类项目的一些体会整套系统做下来我最想强调的一个观点是模型训练只占整个项目不到三成的工作量数据采集、标注规范和系统集成才是大头。很多初学者把重心放在调参上反复试各种学习率、各种模型版本收获反而有限。把数据的采集环境固定好、把标注规范定清楚、把界面逻辑做顺畅这三件事做好项目已经成功了一大半。另外做农产品检测类项目一定要给自己预留现场调试的时间。实验室里效果再好到了现场也会有各种意外状况光源、反光、湿度、传送带速度、花生品种差异任何一个因素都能让模型表现明显下降。提前和数据采集方、设备方沟通好环境条件能省掉大量返工时间。如果后面有条件我计划把系统再往前推一步在界面上增加批次管理功能每次检测自动生成一份包含图片、检测结果、霉变率和操作员信息的报告直接导出成表格。这样整个系统就不只是“一个识别工具”而是能融入工厂现有质检流程的一个完整环节。