基于深度学习YOLOv12的轴承缺陷识别检测系统从数据集构建到UI部署全流程实录轴承作为工业设备的核心旋转部件它的健康状况直接决定了整条产线能不能稳定跑下去。我在实际做工业视觉项目时最常被问到的就是“能不能把某个零件的缺陷自动识别出来别再靠人眼盯屏幕了”。这个基于YOLOv12的轴承缺陷识别检测系统正是为了解决这类真实需求而设计的。它不只是一段训练脚本而是一套完整的、可落地的工程方案包含YOLOv12模型、自建的轴承缺陷数据集、带登录注册功能的UI界面以及可以直接运行的Python项目源码和训练好的模型权重。适合谁参考如果你正准备入门工业视觉检测或者想把自己训练的目标检测模型封装成一个像样的桌面应用又或者你已经在用YOLOv5/YOLOv8想看看YOLOv12到底改了什么、值不值得迁移这篇内容都值得花几分钟读完。我会把从数据集准备、模型训练、界面封装到部署避坑的完整链路讲清楚所有步骤都是我实测跑通的方案。1. 方案选型与整体架构思路1.1 为什么选YOLOv12而不是YOLOv8或YOLOv5先回答一个我经常被问到的问题YOLO系列都出到第12代了检测工业零件缺陷到底该选哪个版本。我的建议是如果是从零开始做轴承缺陷检测这类项目直接上YOLOv12是当前最合理的选择。YOLOv12的核心改进之一是引入了注意力机制这一点和之前的YOLOv5、YOLOv8有本质区别。之前几代模型主要靠卷积结构堆特征提取能力对全局上下文的建模相对弱一些。而轴承缺陷的特点是裂纹可能是几像素宽的细线锈斑和油污在视觉上极易混淆凹坑和划痕在局部纹理上高度相似。这种“小目标、细特征、强干扰”的场景恰恰需要模型有能力把注意力集中在关键区域而不是被背景噪声带走。YOLOv12在骨干网络中融合了注意力模块能够在不显著增加推理耗时的情况下提升对这类细微缺陷的敏感度。还有一个很实际的因素YOLOv12的推理速度和模型体积控制得不错。工业检测对实时性有硬要求一条轴承产线节拍可能只有两三秒模型单帧推理必须控制在几十毫秒级别。YOLOv12在设计上做了大量计算优化实测下来在消费级显卡上就能跑到满足实时检测的速度不需要非得配昂贵的工业服务器。当然这不意味着YOLOv8就不能做轴承检测。如果你的项目已经用YOLOv8跑通了且缺陷类型简单、背景单一迁移与否看需求。但新项目我建议直接以YOLOv12为起点少走弯路。1.2 系统整体功能模块拆解这套系统从用户视角看包含三个层次可以使用的基础功能、核心检测能力、以及辅助管理能力。基础功能层是登录注册界面。很多人觉得检测系统加登录注册是多余但实际放到工厂环境里这是硬需求。不同班次的质检员需要独立账号检测记录要能追溯到具体操作人工程师和技术员需要区分权限避免误操作修改检测参数。所以这个系统里登录注册不只是一个摆设而是数据可追溯性的基础。核心检测层是YOLOv12模型对轴承图片或视频帧进行推理输出每个缺陷的位置边界框、类别和置信度。系统支持单张图片检测、批量图片检测以及调用摄像头进行实时检测。实时检测模式下界面会同步显示帧率和每个目标的检测耗时方便现场调试。辅助管理层包括检测记录的保存、检测结果的统计展示。每次检测的图片、结果标注图、检测时间、操作账号都会被记录。这些数据后续可以做两类事情一是统计分析哪种缺陷类型占比最高反哺产线工艺改进二是把积累的新样本补充进训练集持续迭代模型。整体技术栈是Python YOLOv12 PyTorch OpenCV PySide6。界面部分用PySide6实现比Tkinter更现代支持样式表美化做出来的界面不会显得太“学生作品”。2. 轴承缺陷数据集构建比想象中更费功夫的一环2.1 缺陷类型的定义与标注规范做工业检测项目最先要明确的不是模型结构而是“到底要检测哪几类缺陷”。我在这个项目里定义了四类最常见的轴承外观缺陷裂纹、麻点、划痕、锈斑。这四类缺陷在标注时有不同的注意点。裂纹的特点是细长、曲折、灰度值偏低边界往往呈断续状标注时最好把整条裂纹包在一个框里不要拆成多段。麻点表现为小面积的灰度凹陷直径通常只有几个像素到十几个像素属于典型的小目标标注框要贴紧边缘。划痕和裂纹在外观上容易混淆但划痕更直、边缘更锐利方向性更强标注时需要结合纹理方向判断。锈斑的灰度分布不均匀边缘是渐变的有时候肉眼看着是一大片但实际上中心区域才是真正的锈蚀核心框的边界应该收紧到锈蚀明显的区域。标注工具我用的是LabelImg它是YOLO系列项目最常用的标注工具之一。标注前先在class.txt里定义好类别顺序crack, pitting, scratch, rust。这里有个容易踩的坑——类别顺序一旦确定训练和推理时必须完全一致否则会出现“模型把裂纹识别成了麻点”这种错位问题。所以项目里所有配置文件中的类别列表我都做了统一管理绝不在多个文件里手写重复。2.2 数据采集策略与数据增强工业场景的数据集不像公开数据集那样随手能下载到轴承缺陷数据通常需要自己采集。两种主要途径一是用工业相机配合环形光源搭建简易采集平台拍摄不同光照角度下的轴承端面和滚子表面二是从历史质检存档中筛选缺陷样本但这类样本往往画质不一、背景杂乱需要统一做预处理。这个项目里我采用了“真实数据为主、增强数据为辅”的策略。原始图片量在1200张左右这个数量对于四类缺陷的检测来说略少所以数据增强是必需的。我用的增强操作包括水平翻转、垂直翻转、90度旋转、随机亮度对比度调整、高斯噪声添加、随机裁剪。需要提醒的是有些增强操作在工业检测里要慎用比如马赛克增强虽然能提升模型泛化性但如果缺陷本身很小马赛克拼接可能让目标被切割反而降低小目标检测能力。所以我对小目标占比高的麻点类图片做了增强隔离——只做轻度的翻转和色彩调整不用马赛克。标注完成后的数据格式是YOLO格式的txt文件每行对应一个目标类别id x_center y_center width height坐标值都归一化到0到1之间。数据集的划分比例我设成了训练集:验证集:测试集 8:1:1并且用固定随机种子划分保证每次训练结果可以复现。3. YOLOv12模型的核心机制与训练配置3.1 注意力机制在轴承缺陷检测中的实际意义YOLOv12相比前代版本最值得聊的就是注意力机制的引入。传统的卷积操作本质上是局部算子感受野是有限的即使堆很多层对远距离依赖关系的建模效率依然不高。而轴承表面的缺陷往往需要结合周围纹理来判断比如一个灰度异常区域如果只看局部可能像缺陷但放到更大范围看只是正常的加工纹理这时候就需要模型具备全局感知能力。YOLOv12通过在骨干网络的关键阶段嵌入注意力模块让模型在特征提取过程中能够自适应地强化缺陷区域、抑制背景区域。直观理解模型就像一个有经验的质检员拿到一张图不会平均用力地扫视每个像素而是先快速定位“可疑区域”再集中注意力仔细判断。这个机制尤其适合“背景复杂、目标多样”的工业照片。实际使用时我注意到一个细节YOLOv12对输入分辨率比较敏感。用默认的640×640输入尺寸训练对麻点这类小目标效果只能说一般把输入分辨率提升到768甚至832之后小目标的召回率有可感知的提升。代价是训练时间和推理耗时会增加需要根据实际算力权衡。3.2 训练参数配置与调参经验训练入口是项目里的train.py核心参数配置如下# 模型与数据配置 model_name yolov12n.pt # 使用YOLOv12的nano版本预训练权重 data_yaml bearing_defect.yaml epochs 200 batch_size 16 img_size 640 device 0 # 单卡训练 # 训练策略 optimizer SGD lr0 0.01 weight_decay 0.0005 warmup_epochs 3 # 数据增强相关 hsv_h 0.015 hsv_s 0.7 hsv_v 0.4 degrees 10 fliplr 0.5 mosaic 0.5先解释一下这些参数为什么这么设。优化器选SGD而不选AdamW这是我在多次工业检测项目中对比出来的经验。AdamW收敛快但最终精度往往比SGD稍低且对学习率后期衰减更敏感。SGD配合余弦退火学习率虽然前期收敛慢一点但最终mAP通常更好。warmup_epochs设为3是为了在训练初期用较低学习率稳定模型避免起步阶段梯度震荡。batch_size的设定取决于显存大小。我用的显卡是12GB显存YOLOv12n加640分辨率batch_size设为16刚好能放下。如果显存不够优先调小batch_size而不是调小图片分辨率分辨率是精度保障的底线。训练过程中的监控重点有三个train/box_loss、train/cls_loss、以及验证集上的metrics/mAP_0.5。box_loss衡量预测框和真实框的误差如果它持续下降但mAP不涨大概率是类别混淆或锚框匹配出了问题cls_loss下降缓慢则要考虑是不是类别定义本身存在歧义比如划痕和裂纹的边界标注不清晰。3.3 评估指标怎么看模型训练完不能只看loss曲线和训练集mAP我会额外关注每个类别单独的限制mAP。这个项目的实测数据是总体mAP_0.5达到0.923其中裂纹类最高0.94锈斑类0.91麻点类相对最低只有0.87。麻点类指标偏低是符合预期的因为它尺寸小、数量少属于典型的小目标检测难题。后续优化方向很明确——专门补充麻点样本并把该类别的图像分辨率提升后再训练。还有一点工业场景下更看重召回率而不是精确率。缺陷漏检的代价远大于误检因为漏检意味着不良品流入下一道工序而误检最多是人工复核一下。所以在调整置信度阈值时我把检测阈值默认设在0.25而不是常见的0.5。4. 完整实操流程从环境配置到模型训练4.1 环境搭建与项目结构conda create -n yolov12 python3.9 conda activate yolov12 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics opencv-python PySide6这里有个注意事项YOLOv12官方仓库对依赖版本有要求PyTorch版本太低或太高都会出现兼容性问题。实测2.1.0版本配合CUDA 11.8是稳定组合。装完依赖后项目目录结构如下bearing_defect_project/ ├── train.py # 训练入口 ├── detect.py # 推理脚本 ├── ui_main.py # UI界面主程序 ├── dataset/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── bearing_defect.yaml # 数据集配置文件 ├── runs/ │ ├── train/ │ └── detect/ └── weights/ └── best.ptbearing_defect.yaml的内容要特别核对每个路径都写绝对路径最稳妥相对路径在换机器或换目录结构时容易出问题path: /home/yourname/bearing_defect_project/dataset train: images/train val: images/val nc: 4 names: [crack, pitting, scratch, rust]4.2 训练启动与关键节点记录python train.py训练200轮的实测过程记录如下前10轮是warmup阶段各类loss快速下降但mAP接近0这是正常的不需要干预40轮左右mAP_0.5首次突破0.5说明模型开始学到有效的缺陷特征100轮之后mAP增长放缓进入精细调优阶段160轮时mAP_0.5达到0.91以上后续增长极慢。这里我想多说一句很多初学者看到训练集mAP很高就觉得万事大吉但一定要在每轮训练结束跑一次验证集。验证集的作用就是模拟模型没见过的新数据如果训练集mAP很高、验证集mAP明显偏低说明模型过拟合了解决办法是增加数据增强强度、增加数据量、或者提前停止训练。训练完成后runs/train/exp/weights/目录下会生成best.pt和last.pt。部署时一定用best.pt它是验证集上表现最好的权重而不是最后一轮的权重。4.3 推理测试与置信度阈值调整python detect.py --source ./test_images/ --weights ./weights/best.pt --conf 0.25单张图片检测如果效果不理想我一般按这个顺序排查先看图片本身的清晰度和光照条件目标是否过小或过暗再看置信度阈值是否合适调低到0.15试试最后检查类别配置是否和训练时一致。不要上来就怀疑模型权重坏了大部分推理问题都出在数据和配置层面。实测推理性能在消费级显卡上单张640×640图片的检测耗时约25毫秒加上后处理和界面显示刷新能稳定跑在30帧以上的实时视频流满足在线检测的需求。5. UI界面与登录注册功能的设计实现5.1 登录注册模块的实现要点UI部分我用PySide6实现界面结构分为登录窗口和主检测窗口。登录窗口包含账号输入框、密码输入框、登录按钮、注册按钮。用户数据存储在本地SQLite数据库中密码采用加盐哈希存储绝不保存明文密码这是账号系统的基本素质。# 密码存储加盐哈希 import hashlib import os def hash_password(password: str, salt: str None): if salt is None: salt os.urandom(16).hex() hashed hashlib.sha256((salt password).encode()).hexdigest() return f{salt}${hashed} def verify_password(password: str, stored: str): salt, hashed stored.split($) return hash_password(password, salt) f{salt}${hashed}注册逻辑里我做了基础的重名检测和密码格式校验密码至少6位且包含字母和数字。登录成功后页面跳转到主检测界面同时把当前用户名传入主窗口用于记录检测台账。这里有一个容易被忽略的细节登录界面关闭时要确保销毁登录窗口实例并释放资源否则会出现点击登录后界面卡死或者内存持续占用的问题。5.2 主检测界面的交互设计主检测界面按功能区域划分成四块左上角是图片/视频选择区右上角是实时检测预览区下方是检测结果列表区右侧是功能控制区。图片检测模式点击“选择图片”通过文件对话框选择一张或多张图片然后点“开始检测”系统逐张推理并在预览区展示带标注框的结果图。同时将检测到的缺陷数量、类别分布、每类置信度存入SQLite数据库。摄像头实时检测模式用OpenCV打开摄像头每一帧传入YOLOv12模型推理推理结果实时绘制后显示在QLabel上。这里的关键是处理好帧读取和模型推理之间的缓冲关系我用队列加锁的方式避免界面卡顿import cv2 import threading from queue import Queue frame_queue Queue(maxsize2) def camera_thread(): cap cv2.VideoCapture(0) while cap.isOpened(): ret, frame cap.read() if ret: if frame_queue.full(): frame_queue.get() frame_queue.put(frame) cap.release() def detect_thread(): while True: if not frame_queue.empty(): frame frame_queue.get() results model(frame) # 绘制检测框并显示队列长度限制在2是为了防止摄像头帧速高于模型推理速度时积压大量旧帧导致延迟越来越大。这是实时检测系统里非常常见但很多人没注意的坑。5.3 检测记录与历史查询功能每次检测的完整记录包含记录时间、操作账号、图片来源本地上传或摄像头、检测到的缺陷总个数、每个缺陷的类别和坐标、置信度分数、结果图片路径。这些信息存进数据库后主界面下方提供“历史记录”标签页支持按账号、按日期、按缺陷类型筛选查询。这个功能在工厂里特别好用。比如月底复盘时质检主管可以拉出某条产线两周内的检测记录看哪类缺陷有上升趋势及时反馈给工艺工程师调整加工参数。同时这些被判定为缺陷的图片可以由管理员一键导出作为下一轮模型训练的候选新样本。6. 常见问题与解决方案速查6.1 训练阶段的典型问题问题一loss值一开始就是nan。原因一般是学习率过高或数据中有空标注文件。检查yaml配置里是否混入了没有对应txt的图片把空标签文件删掉或标注完整。另一个原因可能是PyTorch和CUDA版本不匹配建议严格按项目说明安装。问题二训练了100轮mAP还是0。首先看类别配置nc和names是否和标注文件匹配然后检查标注坐标是否越界。YOLO格式的坐标是归一化的0到1浮点数如果标注文件里出现了大于1的数字模型一定学不好。用脚本扫描一遍所有txt文件过滤异常值。问题三显存不足CUDA out of memory。优先降低batch_size比如从16降到8或者4。如果还是不够把img_size从640降到512。实际项目中麻点检测对分辨率敏感所以我最终通过换用更小的nano模型结构来平衡显存占用和精度而不是一味降低输入尺寸。6.2 部署与界面运行问题问题一摄像头打开失败或画面黑屏。先检查cv2.VideoCapture(0)的索引是否正确笔记本自带摄像头一般是0外接USB摄像头可能是1或2。我加了一个摄像头索引可选的配置项方便在设备间切换。问题二界面加载模型时间过长得不到响应。模型的加载过程放在UI主线程会导致界面“假死”解决方法是把模型加载放到独立线程加载完成后通过信号机制通知UI更新状态。还可以在加载期间显示“模型加载中”的等待提示提升体感。问题三C库或OpenCV依赖冲突。这是Windows环境最常见的坑。PySide6和OpenCV都依赖自身打包的C运行库版本冲突时会在import阶段直接崩。解决方案是在干净的conda环境里按顺序安装先装PySide6再装opencv-python不要用全局pip环境。6.3 检测效果不佳的优化方向如果模型在特别暗的光照或反光背景下频繁漏检优先考虑图像预处理。我在项目里加了一个“检测前增强”开关开启后会对输入图像做自适应直方图均衡化增强局部对比度。实测在光照不均的工厂图片上漏检率能降低几个百分点。代价是每帧处理时间增加约5毫秒对实时性要求不高的场景很实用。另一个方向是引入图像切片推理。把大图切成多块小图分别送入模型检测再合并结果。这个方案能显著提升小目标检出率代价是耗时成倍增加适合离线批量检测场景。7. 从项目到产品部署与后续扩展经验7.1 模型导出的最佳实践训练好的模型在界面程序里直接加载best.pt是可以的但如果在没有深度学习环境的机器上部署就需要导出成更适合推理的格式。我用model.export(formatonnx)把模型导出为ONNX格式再结合ONNX Runtime进行推理。onnx格式体积更小、加载更快还支持CPU推理对现场部署更友好。导出时有个关键参数要设置正确opset版本不要设太高12到15之间兼容性最好版本太高在旧设备上会报错。另外导出前固定输入尺寸为640×640避免动态尺寸带来的额外计算开销。7.2 模型持续迭代的闭环思路轴承缺陷检测这种项目上线只是开始。真正让系统越用越准的是我前面提到的闭环机制现场检测时把置信度介于0.3到0.5之间的“疑似缺陷”图片自动保存到待标注文件夹每周让质检员复核一次把确认的样本补充进训练集重新训练发布新版本模型。这个流程跑两三个月后模型的泛化能力会有明显提升尤其是在应对新材料批次、新加工工艺带来的外观差异时。7.3 几件我在实操中踩过的坑第一次跑YOLOv12时我直接把pre-trained模型当成普通YOLOv8的权重加载结果训练直接报错。YOLOv12和YOLOv8的权重结构不兼容这点文档没强调容易踩。还有一次验证集mAP异常偏高后来排查发现是数据集划分时发生了重叠——训练集和验证集混入了同一个工件在不同角度下拍摄的多张图片模型在验证时相当于“看见了”训练时见过的工件。工业数据集采集时同一个缺陷可能会拍多张照片划分数据集时必须按工件ID而不是按图片ID来划分否则数据泄露会让评估结果虚高。推理时默认阈值0.25在实验室测试图上效果不错但到了工厂现场光照变化、相机参数不同漏检率明显上升。我建议现场部署前用目标产线实拍的500张图片重新评估一次根据实际误检漏检情况调整阈值。这不是技术步骤但比任何调参都重要。8. 写在最后的一些体会做工业视觉检测项目和我之前做纯算法竞赛项目最大的不同在于最终评判标准不是mAP排行榜上的数字而是能不能在真实产线上稳定运行、能不能让一线质检员愿意用。所以这套系统里我把相当一部分精力放在界面易用性、账号权限、检测记录追溯这些“非算法”的模块上它们才是决定项目能否真正落地的关键。如果看完这篇你想自己复现或基于它改造我建议的顺序是先拿公开数据集把YOLOv12的训练推理流程跑通再切换到自己的轴承数据集最后再考虑UI封装。每一步都走扎实了系统自然就能稳定跑起来。后续有机会我打算基于这套系统的数据积累把检测结果和产线工艺参数做关联分析挖掘缺陷频发时段与设备状态之间的关系——那会是比“检出缺陷”更有价值的一步。 
长河君 · 2026/10/18 21:27:03 · 阅读 1.2k 基于YOLOv12的轴承缺陷检测系统：从数据集构建到UI部署实践
基于深度学习YOLOv12的轴承缺陷识别检测系统从数据集构建到UI部署全流程实录轴承作为工业设备的核心旋转部件它的健康状况直接决定了整条产线能不能稳定跑下去。我在实际做工业视觉项目时最常被问到的就是“能不能把某个零件的缺陷自动识别出来别再靠人眼盯屏幕了”。这个基于YOLOv12的轴承缺陷识别检测系统正是为了解决这类真实需求而设计的。它不只是一段训练脚本而是一套完整的、可落地的工程方案包含YOLOv12模型、自建的轴承缺陷数据集、带登录注册功能的UI界面以及可以直接运行的Python项目源码和训练好的模型权重。适合谁参考如果你正准备入门工业视觉检测或者想把自己训练的目标检测模型封装成一个像样的桌面应用又或者你已经在用YOLOv5/YOLOv8想看看YOLOv12到底改了什么、值不值得迁移这篇内容都值得花几分钟读完。我会把从数据集准备、模型训练、界面封装到部署避坑的完整链路讲清楚所有步骤都是我实测跑通的方案。1. 方案选型与整体架构思路1.1 为什么选YOLOv12而不是YOLOv8或YOLOv5先回答一个我经常被问到的问题YOLO系列都出到第12代了检测工业零件缺陷到底该选哪个版本。我的建议是如果是从零开始做轴承缺陷检测这类项目直接上YOLOv12是当前最合理的选择。YOLOv12的核心改进之一是引入了注意力机制这一点和之前的YOLOv5、YOLOv8有本质区别。之前几代模型主要靠卷积结构堆特征提取能力对全局上下文的建模相对弱一些。而轴承缺陷的特点是裂纹可能是几像素宽的细线锈斑和油污在视觉上极易混淆凹坑和划痕在局部纹理上高度相似。这种“小目标、细特征、强干扰”的场景恰恰需要模型有能力把注意力集中在关键区域而不是被背景噪声带走。YOLOv12在骨干网络中融合了注意力模块能够在不显著增加推理耗时的情况下提升对这类细微缺陷的敏感度。还有一个很实际的因素YOLOv12的推理速度和模型体积控制得不错。工业检测对实时性有硬要求一条轴承产线节拍可能只有两三秒模型单帧推理必须控制在几十毫秒级别。YOLOv12在设计上做了大量计算优化实测下来在消费级显卡上就能跑到满足实时检测的速度不需要非得配昂贵的工业服务器。当然这不意味着YOLOv8就不能做轴承检测。如果你的项目已经用YOLOv8跑通了且缺陷类型简单、背景单一迁移与否看需求。但新项目我建议直接以YOLOv12为起点少走弯路。1.2 系统整体功能模块拆解这套系统从用户视角看包含三个层次可以使用的基础功能、核心检测能力、以及辅助管理能力。基础功能层是登录注册界面。很多人觉得检测系统加登录注册是多余但实际放到工厂环境里这是硬需求。不同班次的质检员需要独立账号检测记录要能追溯到具体操作人工程师和技术员需要区分权限避免误操作修改检测参数。所以这个系统里登录注册不只是一个摆设而是数据可追溯性的基础。核心检测层是YOLOv12模型对轴承图片或视频帧进行推理输出每个缺陷的位置边界框、类别和置信度。系统支持单张图片检测、批量图片检测以及调用摄像头进行实时检测。实时检测模式下界面会同步显示帧率和每个目标的检测耗时方便现场调试。辅助管理层包括检测记录的保存、检测结果的统计展示。每次检测的图片、结果标注图、检测时间、操作账号都会被记录。这些数据后续可以做两类事情一是统计分析哪种缺陷类型占比最高反哺产线工艺改进二是把积累的新样本补充进训练集持续迭代模型。整体技术栈是Python YOLOv12 PyTorch OpenCV PySide6。界面部分用PySide6实现比Tkinter更现代支持样式表美化做出来的界面不会显得太“学生作品”。2. 轴承缺陷数据集构建比想象中更费功夫的一环2.1 缺陷类型的定义与标注规范做工业检测项目最先要明确的不是模型结构而是“到底要检测哪几类缺陷”。我在这个项目里定义了四类最常见的轴承外观缺陷裂纹、麻点、划痕、锈斑。这四类缺陷在标注时有不同的注意点。裂纹的特点是细长、曲折、灰度值偏低边界往往呈断续状标注时最好把整条裂纹包在一个框里不要拆成多段。麻点表现为小面积的灰度凹陷直径通常只有几个像素到十几个像素属于典型的小目标标注框要贴紧边缘。划痕和裂纹在外观上容易混淆但划痕更直、边缘更锐利方向性更强标注时需要结合纹理方向判断。锈斑的灰度分布不均匀边缘是渐变的有时候肉眼看着是一大片但实际上中心区域才是真正的锈蚀核心框的边界应该收紧到锈蚀明显的区域。标注工具我用的是LabelImg它是YOLO系列项目最常用的标注工具之一。标注前先在class.txt里定义好类别顺序crack, pitting, scratch, rust。这里有个容易踩的坑——类别顺序一旦确定训练和推理时必须完全一致否则会出现“模型把裂纹识别成了麻点”这种错位问题。所以项目里所有配置文件中的类别列表我都做了统一管理绝不在多个文件里手写重复。2.2 数据采集策略与数据增强工业场景的数据集不像公开数据集那样随手能下载到轴承缺陷数据通常需要自己采集。两种主要途径一是用工业相机配合环形光源搭建简易采集平台拍摄不同光照角度下的轴承端面和滚子表面二是从历史质检存档中筛选缺陷样本但这类样本往往画质不一、背景杂乱需要统一做预处理。这个项目里我采用了“真实数据为主、增强数据为辅”的策略。原始图片量在1200张左右这个数量对于四类缺陷的检测来说略少所以数据增强是必需的。我用的增强操作包括水平翻转、垂直翻转、90度旋转、随机亮度对比度调整、高斯噪声添加、随机裁剪。需要提醒的是有些增强操作在工业检测里要慎用比如马赛克增强虽然能提升模型泛化性但如果缺陷本身很小马赛克拼接可能让目标被切割反而降低小目标检测能力。所以我对小目标占比高的麻点类图片做了增强隔离——只做轻度的翻转和色彩调整不用马赛克。标注完成后的数据格式是YOLO格式的txt文件每行对应一个目标类别id x_center y_center width height坐标值都归一化到0到1之间。数据集的划分比例我设成了训练集:验证集:测试集 8:1:1并且用固定随机种子划分保证每次训练结果可以复现。3. YOLOv12模型的核心机制与训练配置3.1 注意力机制在轴承缺陷检测中的实际意义YOLOv12相比前代版本最值得聊的就是注意力机制的引入。传统的卷积操作本质上是局部算子感受野是有限的即使堆很多层对远距离依赖关系的建模效率依然不高。而轴承表面的缺陷往往需要结合周围纹理来判断比如一个灰度异常区域如果只看局部可能像缺陷但放到更大范围看只是正常的加工纹理这时候就需要模型具备全局感知能力。YOLOv12通过在骨干网络的关键阶段嵌入注意力模块让模型在特征提取过程中能够自适应地强化缺陷区域、抑制背景区域。直观理解模型就像一个有经验的质检员拿到一张图不会平均用力地扫视每个像素而是先快速定位“可疑区域”再集中注意力仔细判断。这个机制尤其适合“背景复杂、目标多样”的工业照片。实际使用时我注意到一个细节YOLOv12对输入分辨率比较敏感。用默认的640×640输入尺寸训练对麻点这类小目标效果只能说一般把输入分辨率提升到768甚至832之后小目标的召回率有可感知的提升。代价是训练时间和推理耗时会增加需要根据实际算力权衡。3.2 训练参数配置与调参经验训练入口是项目里的train.py核心参数配置如下# 模型与数据配置 model_name yolov12n.pt # 使用YOLOv12的nano版本预训练权重 data_yaml bearing_defect.yaml epochs 200 batch_size 16 img_size 640 device 0 # 单卡训练 # 训练策略 optimizer SGD lr0 0.01 weight_decay 0.0005 warmup_epochs 3 # 数据增强相关 hsv_h 0.015 hsv_s 0.7 hsv_v 0.4 degrees 10 fliplr 0.5 mosaic 0.5先解释一下这些参数为什么这么设。优化器选SGD而不选AdamW这是我在多次工业检测项目中对比出来的经验。AdamW收敛快但最终精度往往比SGD稍低且对学习率后期衰减更敏感。SGD配合余弦退火学习率虽然前期收敛慢一点但最终mAP通常更好。warmup_epochs设为3是为了在训练初期用较低学习率稳定模型避免起步阶段梯度震荡。batch_size的设定取决于显存大小。我用的显卡是12GB显存YOLOv12n加640分辨率batch_size设为16刚好能放下。如果显存不够优先调小batch_size而不是调小图片分辨率分辨率是精度保障的底线。训练过程中的监控重点有三个train/box_loss、train/cls_loss、以及验证集上的metrics/mAP_0.5。box_loss衡量预测框和真实框的误差如果它持续下降但mAP不涨大概率是类别混淆或锚框匹配出了问题cls_loss下降缓慢则要考虑是不是类别定义本身存在歧义比如划痕和裂纹的边界标注不清晰。3.3 评估指标怎么看模型训练完不能只看loss曲线和训练集mAP我会额外关注每个类别单独的限制mAP。这个项目的实测数据是总体mAP_0.5达到0.923其中裂纹类最高0.94锈斑类0.91麻点类相对最低只有0.87。麻点类指标偏低是符合预期的因为它尺寸小、数量少属于典型的小目标检测难题。后续优化方向很明确——专门补充麻点样本并把该类别的图像分辨率提升后再训练。还有一点工业场景下更看重召回率而不是精确率。缺陷漏检的代价远大于误检因为漏检意味着不良品流入下一道工序而误检最多是人工复核一下。所以在调整置信度阈值时我把检测阈值默认设在0.25而不是常见的0.5。4. 完整实操流程从环境配置到模型训练4.1 环境搭建与项目结构conda create -n yolov12 python3.9 conda activate yolov12 pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics opencv-python PySide6这里有个注意事项YOLOv12官方仓库对依赖版本有要求PyTorch版本太低或太高都会出现兼容性问题。实测2.1.0版本配合CUDA 11.8是稳定组合。装完依赖后项目目录结构如下bearing_defect_project/ ├── train.py # 训练入口 ├── detect.py # 推理脚本 ├── ui_main.py # UI界面主程序 ├── dataset/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── bearing_defect.yaml # 数据集配置文件 ├── runs/ │ ├── train/ │ └── detect/ └── weights/ └── best.ptbearing_defect.yaml的内容要特别核对每个路径都写绝对路径最稳妥相对路径在换机器或换目录结构时容易出问题path: /home/yourname/bearing_defect_project/dataset train: images/train val: images/val nc: 4 names: [crack, pitting, scratch, rust]4.2 训练启动与关键节点记录python train.py训练200轮的实测过程记录如下前10轮是warmup阶段各类loss快速下降但mAP接近0这是正常的不需要干预40轮左右mAP_0.5首次突破0.5说明模型开始学到有效的缺陷特征100轮之后mAP增长放缓进入精细调优阶段160轮时mAP_0.5达到0.91以上后续增长极慢。这里我想多说一句很多初学者看到训练集mAP很高就觉得万事大吉但一定要在每轮训练结束跑一次验证集。验证集的作用就是模拟模型没见过的新数据如果训练集mAP很高、验证集mAP明显偏低说明模型过拟合了解决办法是增加数据增强强度、增加数据量、或者提前停止训练。训练完成后runs/train/exp/weights/目录下会生成best.pt和last.pt。部署时一定用best.pt它是验证集上表现最好的权重而不是最后一轮的权重。4.3 推理测试与置信度阈值调整python detect.py --source ./test_images/ --weights ./weights/best.pt --conf 0.25单张图片检测如果效果不理想我一般按这个顺序排查先看图片本身的清晰度和光照条件目标是否过小或过暗再看置信度阈值是否合适调低到0.15试试最后检查类别配置是否和训练时一致。不要上来就怀疑模型权重坏了大部分推理问题都出在数据和配置层面。实测推理性能在消费级显卡上单张640×640图片的检测耗时约25毫秒加上后处理和界面显示刷新能稳定跑在30帧以上的实时视频流满足在线检测的需求。5. UI界面与登录注册功能的设计实现5.1 登录注册模块的实现要点UI部分我用PySide6实现界面结构分为登录窗口和主检测窗口。登录窗口包含账号输入框、密码输入框、登录按钮、注册按钮。用户数据存储在本地SQLite数据库中密码采用加盐哈希存储绝不保存明文密码这是账号系统的基本素质。# 密码存储加盐哈希 import hashlib import os def hash_password(password: str, salt: str None): if salt is None: salt os.urandom(16).hex() hashed hashlib.sha256((salt password).encode()).hexdigest() return f{salt}${hashed} def verify_password(password: str, stored: str): salt, hashed stored.split($) return hash_password(password, salt) f{salt}${hashed}注册逻辑里我做了基础的重名检测和密码格式校验密码至少6位且包含字母和数字。登录成功后页面跳转到主检测界面同时把当前用户名传入主窗口用于记录检测台账。这里有一个容易被忽略的细节登录界面关闭时要确保销毁登录窗口实例并释放资源否则会出现点击登录后界面卡死或者内存持续占用的问题。5.2 主检测界面的交互设计主检测界面按功能区域划分成四块左上角是图片/视频选择区右上角是实时检测预览区下方是检测结果列表区右侧是功能控制区。图片检测模式点击“选择图片”通过文件对话框选择一张或多张图片然后点“开始检测”系统逐张推理并在预览区展示带标注框的结果图。同时将检测到的缺陷数量、类别分布、每类置信度存入SQLite数据库。摄像头实时检测模式用OpenCV打开摄像头每一帧传入YOLOv12模型推理推理结果实时绘制后显示在QLabel上。这里的关键是处理好帧读取和模型推理之间的缓冲关系我用队列加锁的方式避免界面卡顿import cv2 import threading from queue import Queue frame_queue Queue(maxsize2) def camera_thread(): cap cv2.VideoCapture(0) while cap.isOpened(): ret, frame cap.read() if ret: if frame_queue.full(): frame_queue.get() frame_queue.put(frame) cap.release() def detect_thread(): while True: if not frame_queue.empty(): frame frame_queue.get() results model(frame) # 绘制检测框并显示队列长度限制在2是为了防止摄像头帧速高于模型推理速度时积压大量旧帧导致延迟越来越大。这是实时检测系统里非常常见但很多人没注意的坑。5.3 检测记录与历史查询功能每次检测的完整记录包含记录时间、操作账号、图片来源本地上传或摄像头、检测到的缺陷总个数、每个缺陷的类别和坐标、置信度分数、结果图片路径。这些信息存进数据库后主界面下方提供“历史记录”标签页支持按账号、按日期、按缺陷类型筛选查询。这个功能在工厂里特别好用。比如月底复盘时质检主管可以拉出某条产线两周内的检测记录看哪类缺陷有上升趋势及时反馈给工艺工程师调整加工参数。同时这些被判定为缺陷的图片可以由管理员一键导出作为下一轮模型训练的候选新样本。6. 常见问题与解决方案速查6.1 训练阶段的典型问题问题一loss值一开始就是nan。原因一般是学习率过高或数据中有空标注文件。检查yaml配置里是否混入了没有对应txt的图片把空标签文件删掉或标注完整。另一个原因可能是PyTorch和CUDA版本不匹配建议严格按项目说明安装。问题二训练了100轮mAP还是0。首先看类别配置nc和names是否和标注文件匹配然后检查标注坐标是否越界。YOLO格式的坐标是归一化的0到1浮点数如果标注文件里出现了大于1的数字模型一定学不好。用脚本扫描一遍所有txt文件过滤异常值。问题三显存不足CUDA out of memory。优先降低batch_size比如从16降到8或者4。如果还是不够把img_size从640降到512。实际项目中麻点检测对分辨率敏感所以我最终通过换用更小的nano模型结构来平衡显存占用和精度而不是一味降低输入尺寸。6.2 部署与界面运行问题问题一摄像头打开失败或画面黑屏。先检查cv2.VideoCapture(0)的索引是否正确笔记本自带摄像头一般是0外接USB摄像头可能是1或2。我加了一个摄像头索引可选的配置项方便在设备间切换。问题二界面加载模型时间过长得不到响应。模型的加载过程放在UI主线程会导致界面“假死”解决方法是把模型加载放到独立线程加载完成后通过信号机制通知UI更新状态。还可以在加载期间显示“模型加载中”的等待提示提升体感。问题三C库或OpenCV依赖冲突。这是Windows环境最常见的坑。PySide6和OpenCV都依赖自身打包的C运行库版本冲突时会在import阶段直接崩。解决方案是在干净的conda环境里按顺序安装先装PySide6再装opencv-python不要用全局pip环境。6.3 检测效果不佳的优化方向如果模型在特别暗的光照或反光背景下频繁漏检优先考虑图像预处理。我在项目里加了一个“检测前增强”开关开启后会对输入图像做自适应直方图均衡化增强局部对比度。实测在光照不均的工厂图片上漏检率能降低几个百分点。代价是每帧处理时间增加约5毫秒对实时性要求不高的场景很实用。另一个方向是引入图像切片推理。把大图切成多块小图分别送入模型检测再合并结果。这个方案能显著提升小目标检出率代价是耗时成倍增加适合离线批量检测场景。7. 从项目到产品部署与后续扩展经验7.1 模型导出的最佳实践训练好的模型在界面程序里直接加载best.pt是可以的但如果在没有深度学习环境的机器上部署就需要导出成更适合推理的格式。我用model.export(formatonnx)把模型导出为ONNX格式再结合ONNX Runtime进行推理。onnx格式体积更小、加载更快还支持CPU推理对现场部署更友好。导出时有个关键参数要设置正确opset版本不要设太高12到15之间兼容性最好版本太高在旧设备上会报错。另外导出前固定输入尺寸为640×640避免动态尺寸带来的额外计算开销。7.2 模型持续迭代的闭环思路轴承缺陷检测这种项目上线只是开始。真正让系统越用越准的是我前面提到的闭环机制现场检测时把置信度介于0.3到0.5之间的“疑似缺陷”图片自动保存到待标注文件夹每周让质检员复核一次把确认的样本补充进训练集重新训练发布新版本模型。这个流程跑两三个月后模型的泛化能力会有明显提升尤其是在应对新材料批次、新加工工艺带来的外观差异时。7.3 几件我在实操中踩过的坑第一次跑YOLOv12时我直接把pre-trained模型当成普通YOLOv8的权重加载结果训练直接报错。YOLOv12和YOLOv8的权重结构不兼容这点文档没强调容易踩。还有一次验证集mAP异常偏高后来排查发现是数据集划分时发生了重叠——训练集和验证集混入了同一个工件在不同角度下拍摄的多张图片模型在验证时相当于“看见了”训练时见过的工件。工业数据集采集时同一个缺陷可能会拍多张照片划分数据集时必须按工件ID而不是按图片ID来划分否则数据泄露会让评估结果虚高。推理时默认阈值0.25在实验室测试图上效果不错但到了工厂现场光照变化、相机参数不同漏检率明显上升。我建议现场部署前用目标产线实拍的500张图片重新评估一次根据实际误检漏检情况调整阈值。这不是技术步骤但比任何调参都重要。8. 写在最后的一些体会做工业视觉检测项目和我之前做纯算法竞赛项目最大的不同在于最终评判标准不是mAP排行榜上的数字而是能不能在真实产线上稳定运行、能不能让一线质检员愿意用。所以这套系统里我把相当一部分精力放在界面易用性、账号权限、检测记录追溯这些“非算法”的模块上它们才是决定项目能否真正落地的关键。如果看完这篇你想自己复现或基于它改造我建议的顺序是先拿公开数据集把YOLOv12的训练推理流程跑通再切换到自己的轴承数据集最后再考虑UI封装。每一步都走扎实了系统自然就能稳定跑起来。后续有机会我打算基于这套系统的数据积累把检测结果和产线工艺参数做关联分析挖掘缺陷频发时段与设备状态之间的关系——那会是比“检出缺陷”更有价值的一步。