新闻详情

新闻详情

首页 / 资讯中心 / 详情

曲奇饼干缺陷检测实战:基于YOLO11cls的图像分类与数据集训练

发布时间:2026/9/29 15:51:07来源:尧图网络
曲奇饼干缺陷检测实战:基于YOLO11cls的图像分类与数据集训练
简介面向曲奇饼干缺陷检测与食品工业智能质检场景资源围绕真实产线采集的曲奇饼干图像数据整理出可直接用于分类训练的数据集适合算法工程师、质检系统开发者及食品视觉检测项目团队作为数据补充和基线参考。数据集按 Defect_Color、Defect_No、Defect_Object、Defect_Shape 四类缺陷组织采用文件夹区分目标类别标注质量高可直接用于 YOLOCLS 等图像分类算法训练附带的 YOLO11cls 一键训练脚本和博主训练日志能帮助快速复现训练流程、观察不同阶段的 loss 变化并完成调参对照。资源包共 1 个文件类型为 PDF大小 5.87MB内附数据集基本情况介绍、类别定义、缩略图预览以及百度网盘获取方式PDF 便于先掌握数据分布和目录结构再按需下载完整图片。当前已有 29 人学习下载适合作为食品缺陷检测项目的数据补充与算法基线参考。1. 曲奇饼干缺陷检测食品厂质检场景与图像分类数据集曲奇饼干生产线上的外观质检过去靠质检员在传送带旁肉眼挑拣。长时间盯着烤焦、破碎、未熟透的饼干看注意力下滑几乎无法避免漏检率在下午班次尤其明显。这套资源就是为这个场景准备的1000 张已经按类别整理好的曲奇饼干图像每个缺陷类别对应一个分类文件夹配上一份 YOLO11cls 一键训练脚本从数据到权重只需要一条命令。它定位明确——食品工业质检里的图像分类任务不涉及目标检测的框标注。适合三类人食品厂里做产线自动化改造的工程师、想拿真实工业图像练手的算法工程师以及做机器视觉选型的技术负责人。先看数据再跑脚本半天就能看到自己的第一个缺陷分类权重。2. 数据集结构拆解五类缺陷的文件夹组织与数据划分1000 张图按缺陷类别分文件夹整理对 YOLO 分类任务来说文件夹结构本身就是标签。理解这套结构后面跑训练脚本才不会出现路径问题或者类别读错的情况。2.1 分类体系与目录结构五个类别对应五个目录从用途上数据集把曲奇饼干分成五个类别每个类别在训练和验证目录下各占一个文件夹。这套分类贴近产线质检的工位分工焦糊是烘烤温控问题发白是加热不足破碎是输送或翻盘机构问题形状异常是成型机模具或挤花压力问题。分得越细后续做质量归因越容易。类别目录名中文含义典型视觉特征normal正常表面金黄均匀、形状完整、厚度一致burnt烤焦表面有深褐色或黑色焦斑边缘发暗undercooked未烤熟中心发白没有烘焙上色整体偏浅broken破碎局部断裂、缺角、边缘有碎渣malformed形状异常轮廓不规则、挤花塌陷、边缘外溢目录结构如下dataset/ ├── train/ │ ├── normal/ # 表面金黄均匀、形状完整约160张 │ ├── burnt/ # 表面有明显烤焦深色斑块约160张 │ ├── undercooked/ # 中心发白、无烘焙上色约160张 │ ├── broken/ # 局部断裂、缺角或碎渣约160张 │ └── malformed/ # 形状外溢、扭曲或厚度不均约160张 └── val/ ├── normal/ # 约40张 ├── burnt/ # 约40张 ├── undercooked/ # 约40张 ├── broken/ # 约40张 └── malformed/ # 约40张五个类别train 和 val 按 8:2 划分合计正好 1000 张。YOLO11cls 的训练入口data参数直接指向这个根目录脚本会自动识别 train/ 和 val/ 子目录下的类别文件夹不需要额外写 yaml 文件。如果你下载的压缩包里还带着 test/ 文件夹那是作者额外留的随机抽样图片平常做推理演示和效果验证用。提示Ultralytics 扫描子目录时按字典序生成类别映射所以burnt永远是第 0 类cracked是第 1 类依此类推。后期解析预测结果时要记住这个映射关系不要按自己的直觉排。2.2 图像内容与拍摄条件单目标特写、固定机位、光源统一我拆过不少工业数据集这个数据集的图像内容有三个特征值得先说清楚。第一每张图是单目标特写。饼干基本占据画面主体背景是传送带或深色工作台没有多个物体混在一起的场景。这意味着训练出来的分类模型是在“当前画面里有一个目标”的前提下去做类别判断而不是先检测再分类。如果用多目标场景直接去套这个模型会把模型的类别置信度拉得很低甚至会因为背景占比变大而误判。第二拍摄视角和光照相对统一。从图像分布看数据集中大部分照片是在同一条视觉工位上拍的光源方向固定饼干没有严重反光。这是优点训练时收敛快、准确率高也是隐患一旦换到自然光或不同光源角度的现场准确率会明显下滑这一点在第 4 章重点展开。第三图像格式是标准 JPEGRGB 三通道边长大多在 640 到 1280 像素之间。YOLO11cls 训练时会把图像等比缩放再 padding 到imgsz所以原始分辨率不需要统一。但高分辨率图像比例太大时训练变慢建议按 640 传入如果缺陷特征很小比如裂纹只在局部几个像素里可以试着把imgsz提到 960。2.3 标签质量检查训练之前先做完这三件事标签质量直接决定模型上限。拿到数据集先别急着跑脚本花 20 分钟做三件事能省下后面几天调参时间。第一统计每个文件夹的文件数量确认类别平衡。按上面的结构正常类和缺陷类图像数量差不多。如果你发现某个类明显少于其他类说明这个类别的样本覆盖不足后面训练时就要留意要不要做复制采样或者补拍。# 统计 dataset/train 下每个类别文件夹的图片数量 for d in dataset/train/*/; do echo $d: $(ls -1 $d | wc -l) done # 统计 dataset/val 下每个类别文件夹的图片数量 for d in dataset/val/*/; do echo $d: $(ls -1 $d | wc -l) done这段命令在 Linux 或 Git Bash 下直接能跑把所有子文件夹的文件数打出来。$d 是遍历出来的目录路径ls -1列出每张图片文件名wc -l统计行数。如果只有 normal 类目录特别多说明数据集本身存在类别不平衡后面训练脚本里要开 augment 或者做权重补偿。第二抽查图片是否混入不合格样本。人工整理的数据集里偶尔会把一张烤焦的图放进行状异常文件夹。肉眼抽查每个文件夹里的三五十张随机图把明显放错的挑出来。1000 张图的工作量不大值得做。第三检查有没有重复帧或相似度过高的连续帧。工业数据集里同一个饼干常常拍了多张不同角度的照片如果这类重复帧大量存在训练集和验证集之间可能发生串扰让验证集指标虚高。遇到疑似连续帧看一眼文件名编号的连续性就能判断。一般来说文件名按时间戳命名比较可靠如果是随机命名就要多留个心眼。开始训练前还要确认 val 目录下每个类别都有图。有些数据集的验证集只覆盖了部分类别这类缺失会让验证指标完全失真甚至准确率跑到 99% 都不奇怪——那只是碰巧验证集中全是容易分类的样本。3. YOLO11cls 训练脚本拆解从预训练权重到参数调优Ultralytics 在 YOLO11 里把 classification 任务单独用yolo11cls前缀标识。它和检测任务最大的区别是输出层不做边界框回归只输出类别概率分布。对缺陷分类场景来说这个任务比检测更直接因为饼干是单目标特写不需要空间定位只需要回答“这是哪一类”。3.1 一键训练脚本每个参数对应什么下面是一份精简过的一键训练脚本直接保存为train_cls.py运行即可。from ultralytics import YOLO if __name__ __main__: # 预训练权重yolo11cls.pt 是 YOLO11 分类模型权重 # 从预训练权重开始微调比随机初始化收敛快得多 model YOLO(yolo11cls.pt) # data 参数指向数据集根目录根目录下必须有 train/ 和 val/ 两个子目录 # 每个子目录下按类别分子文件夹文件夹名就是类别名 results model.train( datadataset, # 数据集根目录 epochs80, # 训练轮数1000张图不用训练太久 imgsz640, # 输入图像边长正方形缩放 batch32, # 每批数量根据显存调整 lr00.001, # 初始学习率微调场景建议往小压 optimizerAdamW, # AdamW 在分类任务上比 SGD 稳 patience15, # 连续 15 轮验证损失不下降就早停 augmentTrue, # YOLO11 内置翻转、旋转、HSV 扰动 projectruns, # 训练输出根目录 namecookie_cls, # 本次实验的名称 device0 # GPU 设备号没有显卡就写 devicecpu ) # 训练结束后 best.pt 是验证集上表现最好的权重 print(训练完成最优权重路径:, results.save_dir)代码逻辑不复杂核心就是两件事加载 YOLO11 分类预训练权重yolo11cls.pt然后调用model.train()把数据集根目录传进去。data参数不需要写 yaml因为 train/ 和 val/ 的子目录结构已经表达了类别信息Ultralytics 会自动扫描每个子目录的文件夹名生成类名到索引的映射关系。这一点对新手非常友好但也要记住第 2 章提到的字典序映射问题。epochs80对于 1000 张图的规模是够用的。YOLO11 内置了 early stoppingpatience15表示验证集 loss 连续 15 轮没有改善就会自动终止训练不用手动盯着。lr00.001配合 AdamW 是微调场景里比较稳妥的起点。预训练权重已经学到过大量通用视觉特征太高的学习率会把已有特征冲掉。imgsz640是 YOLO11 分类模型的默认输入尺寸如果你的缺陷特征很小把 imgsz 提高到 960 能捕捉更多细节但显存占用和训练时间都会明显上涨。3.2 命令行方式不改代码直接换参跑实验Ultralytics YOLO 也支持完全不用 Python 脚本的纯命令行。如果需要快速验证数据是否有问题或者要换一组参数来回对比训练下面这种命令行方式是更省事的。yolo clf train datadataset modelyolo11cls.pt epochs60 imgsz640 batch16 device0 projectruns namecookie_cls_exp1这和脚本方式完全等价clf后缀表示 classification 任务。命令行适合批量跑参数对比比如把lr0从0.001改成0.01再跑一组或者把imgsz从 640 换成 960 看准确率变化。换参数时不用改文件直接把命令行追加到终端就能跑。训练参数按经验整理成下面的表照着这个起点调大部分场景不会翻车参数建议值作用与调试思路epochs80数据量小轮数过多必然过拟合配合早停使用imgsz640输入边长缺陷细节小可升到 960显存翻倍batch32按显存调整OOM 就减半到 16 或 8lr00.001微调场景的稳妥起点现场微调时降到 0.0005optimizerAdamW分类任务上收敛平滑比 SGD 好调patience15验证 loss 不降就停防止无效等待augmentTrue内置翻转、旋转、HSV 扰动默认开启这里的参数组合有一点玄学成分不同数据集的最佳值不可能完全一样。但按这个基准跑再根据验证集结果小幅调整比自己从零摸索要快得多。3.3 训练结果解读看哪条曲线选哪个权重训练跑完后runs/cookie_cls/下会生成weights/best.pt、weights/last.pt、args.yaml以及results.csv。results.csv里每一行是一个 epoch 的训练损失、验证损失、准确率和学习率信息。# 查看训练过程中的损失和准确率变化 cat runs/cookie_cls/results.csv | cut -d , -f 1,3,4,5 | head -20cut命令按逗号分隔把 epoch、训练准确率、验证准确率、学习率这几列筛出来head -20只显示前 20 行快速了解训练节奏。核心判断思路是看验证损失的趋势。训练损失降得漂亮不算数验证损失在第几个 epoch 开始反弹那个拐点就是过拟合的位置。best.pt是验证集上 loss 最低的那一个权重实际使用以它为准不要用last.pt后者只是最后一个 epoch 的权重往往已经过拟合。推理用下面这段代码和训练脚本放在同一个项目下from ultralytics import YOLO # 加载验证集上表现最好的权重 model YOLO(runs/cookie_cls/weights/best.pt) # 单图预测返回类别概率分布 res model.predict(dataset/val/broken/sample_001.jpg) print(预测类别:, res[0].probs.top1) print(置信度:, res[0].probs.top1conf) # 对整个文件夹做批量预测并保存结果图像 res model.predict(待检图片/, saveTrue)res[0].probs是一个长度为 5 的向量顺序对应数据集类别名的字典序。top1返回类别索引top1conf返回对应置信度。如果想直接拿类别名用res[0].names[res[0].probs.top1]取名字。批量预测时saveTrue会把画好标签的图片存到runs/predict/下先目测一遍预测结果是检查模型质量最快的方式。4. 训练避坑指南数据不平衡、过拟合与场景迁移数据集本身整理得挺规范真正让训练“翻车”的往往不是代码而是数据和场景理解上的偏差。这一章专门列我拆数据、跑训练时遇到过的五个坑每一条都是现象、原因、解决办法的结构照着排查能省很多时间。4.1 多数类压倒少数类预测结果全偏向 normal现象第一轮训练结束后验证集准确率看起来有 92%但打开混淆矩阵一看broken 和 malformed 两个类几乎全被预测成了 normal召回率只有 30% 出头。整体准确率是好看的细节却完全不能用。原因如果数据集各类别图像数量不均匀模型在训练过程中会倾向把不确定的样本分到样本量更大的类。虽然这个数据集整体上每类约 200 张但如果你手动往里补过其他图片很可能打破平衡。另一个常见原因是有的类别本身外观相近比如 broken 和 malformed模型学不到足够的区分特征就只能往大类靠。解决先用第 2 章的统计命令确认每类图片数量差异超过 20% 就要处理。最简单的办法是开启augmentTrue让模型每轮看到更多不同形态的缺陷样本。更主动的做法是在model.train()里传class_weights参数让少数类在损失函数里权重更大。最实在的做法是补拍缺陷样本缺陷类的图像数量上去了模型的判断依据才会扎实。4.2 过拟合训练集准确率 99%验证集只有 81%现象训练的 loss 一路下降验证 loss 在第 30 轮开始掉头往上走训练集准确率已经到 99% 了验证集准确率却停留在 81%而且后续轮次的验证准确率不再上升。原因1000 张图像的数据规模不大模型容量相对数据量是偏大的训练轮次一多模型会在训练集上记下每个样本的细节而不是提取缺陷的通用特征。YOLO11 内置的 early stopping 在这种情况下会在验证 loss 回升后及时截断但如果你把patience调到很大或者关闭了早停过拟合就会成定局。解决训练参数里重点管两个地方。第一epochs 控制在 80 以内让patience15生效验证 loss 一回升就停下。第二如果停得早但准确率还是不够优先提高 augment 的数据增强强度而不是加训练轮次。还有个思路是把imgsz从 640 降到 320模型参数规模减半过拟合压力小很多对缺陷区分度高的场景影响不大。4.3 光照不一致换到产线现场准确率掉到 60%现象数据集在厂房固定光源下拍的模型在测试照片上准确率 90%把同样的权重装到产线工业相机上发现烤焦类大量误报成正常类整体准确率掉到 60% 左右。原因模型学到的是“这个光源条件下什么颜色代表烤焦”。一旦现场光源色温、亮度、角度变了饼干的颜色分布整体偏移模型的分界线就失效了。这是工业视觉里最典型的场景迁移问题不是模型代码的问题。解决分两步走。第一步训练阶段把 augment 里的 HSV 扰动调到更高让模型见过更多亮度、饱和度变化。Ultralytics 允许在model.train()里直接加hsv_h0.02, hsv_s0.8, hsv_v0.6这类参数效果比单纯开 augment 更明显。第二步不要用全部数据集重训而是拿现场相机拍 200 张图用现有 best.pt 预测并人工校正标签再做一次低学习率微调。这样模型在保留数据集知识的同时适应当前产线光源。4.4 把分类模型当检测用找不到目标框就怀疑代码 bug现象有人拿到 best.pt 后直接写一段检测脚本调用model.predict()后想取目标框坐标结果res[0].boxes是空的于是怀疑脚本或者权重有问题。原因YOLO11cls 是 classification 模型的权重输出只有类别概率没有边界框分支。数据集也是按分类文件夹整理的不是 YOLO 检测数据集的 txt 标签格式。如果业务上必须知道缺陷在饼干上的位置这个资源就不是你需要的检测数据要换成带标注框的格式模型换成yolo11n.pt这类检测权重。解决先想清楚任务边界。只需要判断饼干有没有缺陷、是什么缺陷分类模型足够而且训练成本低。需要标记缺陷具体在哪个区域该去用检测或分割模型不要硬拿分类资源去凑。Ultralytics 生态里检测和分类的任务代码是分开的yolo clf命令只做分类检测要跑yolo detect。4.5 路径带中文或空格训练直接退出现象在 Windows 上把数据集解压到D:\资料\曲奇数据集\跑训练脚本刚启动就报 FileNotFoundError 或者 yaml 解析失败。原因Ultralytics 依赖的底层路径处理模块对非 UTF-8 路径支持不完善中文目录名在训练中途写临时文件时容易触发异常和数据集本身质量无关。解决统一把数据集放在全英文路径下比如C:\datasets\cookie_cls\训练脚本和保存输出目录也用英文。路径里的空格也尽量避免命令行参数在 shell 里要额外加引号容易引入不必要的麻烦。5. 进阶用混淆矩阵和现场数据微调把模型用到产线训练完模型不是终点真正让这套资源发挥价值的是后面的验证和迁移。两个习惯值得长期坚持用混淆矩阵反查标签质量用现场数据做低学习率微调。5.1 用混淆矩阵反查标签质量验证模型是否靠谱最好的工具就是混淆矩阵。它能把“哪个类别和哪个类别互相搞混”直接列出来比单纯看准确率有用得多。import glob from ultralytics import YOLO from sklearn.metrics import confusion_matrix model YOLO(runs/cookie_cls/weights/best.pt) categories [burnt, broken, malformed, normal, undercooked] y_true, y_pred [], [] for cat in categories: for img in glob.glob(fdataset/val/{cat}/*.jpg): res model.predict(img, verboseFalse)[0] y_true.append(cat) y_pred.append(res.names[res.probs.top1]) cm confusion_matrix(y_true, y_pred) print(cm)代码逻辑是把验证集所有图像都预测一遍生成 5×5 的混淆矩阵。对角线数字越大说明分类越稳非对角线数字越大就说明那两个类别在特征空间里太接近。通常burnt和undercooked、broken和malformed这两对容易互相误判这是视觉特征决定的不是调参能彻底解决的。如果某两类的混淆程度很高回到数据上补图是更有效的动作。5.2 用自己的缺陷样本增量微调改造成本最低任何公开数据集都不如自己的现场图可靠。最简单有效的迁移用法是用 best.pt 做初始权重放进新增现场图片的数据目录再次训练。model YOLO(runs/cookie_cls/weights/best.pt) model.train( datamy_production_data/, # 你的现场数据同样按 train/val 组织 epochs30, # 数据量小轮数不用太多 lr00.0005, # 比初始训练更低避免冲掉已有特征 freeze8, # 冻结前 8 层只微调后面分类头 )参数里lr00.0005是全项目中最关键的一个。微调场景学习率超过 0.001 容易在新数据上“灾难性遗忘”之前学到的通用特征会被冲掉。freeze8表示冻结网络前 8 层不更新只训练靠后层和分类头训练速度更快对数据量小的现场微调更稳健。30 轮加 early stopping一般跑 10 分钟就能拿到适配现场数据的权重。从那以后我每次做新产线的曲奇缺陷分类都强制先跑一遍这个增量流程先用公开数据集做预训练基座再用现场图微调最后用混淆矩阵反向检查标签质量。希望帮到你。本文还有配套的精品资源点击获取
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

Java编译报错“invalid source release: 16”根源与彻底修复指南 2026/9/29 16:50:54

Java编译报错“invalid source release: 16”根源与彻底修复指南

你有没有过这种经历:在 start.spring.io(Spring Initializr)上选好 Spring Boot 版本、点几下鼠标下载项目压缩包,IDEA 里一打开,还没写任何业务代码,编译就直接抛红:java: 无效的源发行版: 16。…

阅读更多 →
C++贪心算法实战:从排序、优先队列到经典题全解析 2026/9/29 16:50:40

C++贪心算法实战:从排序、优先队列到经典题全解析

作为常年在算法题和工程代码之间反复横跳的人,我越来越觉得贪心算法是最接近“现实决策”的一类算法。它在C里的落地,不只是背几个模板题,而是训练一种观察问题的角度:局部最优能不能推出全局最优,怎么证明&#xff0c…

阅读更多 →
SpringBoot+Vue+MySQL动漫网站全栈项目实战:从设计到部署 2026/9/29 16:50:33

SpringBoot+Vue+MySQL动漫网站全栈项目实战:从设计到部署

每年三四月份,是计算机专业学生开始为毕业设计头秃的时间。我见过太多人第一个选题是"基于SSM的XX管理系统",做了一半发现架构撑不住,又匆忙换题。真正做得顺、答辩不翻车的,往往是那种选得"中庸"但完成度高的…

阅读更多 →
用Dify构建AI复盘工具:对抗后见之明偏差的决策日志系统 2026/9/29 16:50:33

用Dify构建AI复盘工具:对抗后见之明偏差的决策日志系统

每次项目复盘会开到一半,总有人蹦出一句"我早说了会这样"。这个现象太常见了,常见到我们甚至觉得它理所当然。英文里有个特别准确的词形容这种能力——hindsight,也就是"后见之明"。它本身是好事,我们要靠它总…

阅读更多 →
从零搭建AI工程体系:数据管道、推理服务与监控反馈实战 2026/9/29 16:50:33

从零搭建AI工程体系:数据管道、推理服务与监控反馈实战

1. 从零搭建AI工程体系,为什么我劝你别急着调库 "ai-engineering-from-scratch"这个标题,第一次看到的时候我愣了一下。市面上讲AI的文章,十篇有八篇在教你 pip install 之后怎么调API,剩下两篇在讲Transformer的数学…

阅读更多 →
基于Node.js+Vue的血液中心血库管理系统设计与实战 2026/9/29 16:50:33

基于Node.js+Vue的血液中心血库管理系统设计与实战

做血液中心的血库管理系统,听起来是个蛮传统的业务系统,但真上手之后你会发现,它比一般的企业管理软件要敏感得多。血液不是普通商品,它有时效、有血型差异、有严格的合规追溯要求,甚至还有"不能等到快过期了才想…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉