铁路巡检是个苦活儿。我早些年和某实验室的工程师跑过一段线路凌晨的天窗点几个人扛着探伤仪沿着钢轨一步步走眼睛盯到发酸。人工巡检的问题不在于不认真而在于人的注意力是有上限的——再仔细的老师傅连续盯几个小时也会漏掉细小裂纹。所以当YOLO系列模型逐步成熟之后用深度学习做轨道缺陷识别这件事几乎是必然的走向。这篇文章就围绕一个实际项目展开基于YOLOv11的铁路轨道缺陷识别检测系统包含完整的数据集处理流程、模型训练方案、PyQt5 UI界面、登录注册模块、Python源码和训练好的模型文件。我会把整个系统的设计思路、关键参数、实操步骤和踩过的坑一次性讲透。无论你是刚接触目标检测的初学者还是已经在做工业视觉落地的工程师这篇内容都能直接拿来参考。1. 系统整体设计思路与方案选型1.1 为什么是YOLOv11目标检测模型的迭代逻辑要理解为什么选YOLOv11得先把目标检测算法的演进捋一遍。早期的Faster R-CNN走的是两阶段路线先用Region Proposal Network生成候选区域再对每个区域做分类和回归。精度确实高但速度实在提不上去在工业现场动辄需要实时处理的场景里根本跑不动。SSD虽然把速度拉起来了但对小目标的检测效果一直不理想。YOLO系列把目标检测变成了单次回归问题直接在图像上预测边界框和类别速度优势非常明显。从YOLOv3到YOLOv8每一代都在权衡精度和速度。到了YOLOv11这一代几个关键改进让它特别适合轨道缺陷检测这类工业视觉任务骨干网络采用了C3k2结构比之前的CSPDarknet有更丰富的梯度流特征提取能力更强对钢轨表面那种细小的纹理异常更敏感。引入了部分自注意力机制让模型能更好地捕获全局上下文信息。轨道缺陷出现的区域往往和周围环境有强关联比如扣件缺失附近的枕木状态、裂缝周边的锈蚀痕迹注意力机制能帮模型建立这些关联。Anchor-Free检测头去掉了预设锚框的依赖减少了一个需要手动调整的超参数。轨道缺陷的形状差异极大——一条横向裂缝和一块剥落区域的宽高比完全不同Anchor-Free方案天然更适合这种目标形态不固定的场景。选型的时候我对比过YOLOv8和YOLOv11在同样的数据集上训练YOLOv11的mAP大约高了0.8到1.2个百分点推理速度几乎没有损失。考虑到我们还要在UI里做实时预览速度不能妥协最终就定了YOLOv11。对比项YOLOv8nYOLOv11n模型大小约6.3 MB约5.4 MB输入分辨率640x640640x640推理速度GPU约2.1 ms约2.0 ms同等数据下mAP基准提升约1%1.2 缺陷类别定义与数据集构建轨道缺陷检测不是笼统地检测有没有问题而是要告诉巡检人员哪里出了问题、是什么问题。类别的定义直接决定了模型的可用性。我在这个项目里把缺陷划分成五类钢轨表面裂纹、轨头剥落、钢轨磨损、扣件缺失、轨枕破损。这个分类不是拍脑袋定的参考了实际线路巡检中最常见、也是人工巡检最容易漏掉的情况。类别英文标识典型特征检测难度裂纹crack细线状灰度突变明显高目标小剥落spalling块状掉皮边缘不规则中磨损wear轨头亮面带面积较大低扣件缺失missing_fastener扣件位置为空上下文线索强中轨枕破损sleeper_damage混凝土块碎裂中数据集的来源主要有两个渠道现场巡检车拍摄的线路影像资料以及公开的轨道缺陷数据集。我强烈建议不管用开源数据还是自采数据一定要做一次人工复核。开源数据集里经常有标注框偏移、类别标签错误的情况脏样本会让训练过程非常痛苦——模型可能会去学习那些错误的标注特征收敛速度明显变慢。标注工具我用的是LabelImg它是VOC格式XML文件需要转换到YOLO格式TXT文件每行一个目标类别序号、中心点x、中心点y、宽度、高度均为归一化值。转换脚本用Python写一个批量处理就行核心逻辑就是读取XML里的bounding box坐标除以图片宽高得到归一化值。1.3 系统模块划分登录、界面、推理三层整个系统我拆成了三个模块用户层登录注册、交互层UI界面、核心层模型推理。这样拆的好处是各模块职责单一后续维护或者替换组件都方便。用户层负责登录注册、用户信息存储、会话管理。用SQLite存用户数据密码哈希处理。交互层负责展示检测画面、结果列表、按钮交互。用PyQt5实现模型推理放到独立线程里跑避免阻塞UI。核心层负责调用YOLOv11模型对输入图像做推理返回检测结果。数据流向是用户登录系统进入主界面加载模型选择输入来源单张图片、视频文件或摄像头实时画面模型推理返回检测框、类别和置信度界面把这些信息绘制出来并支持结果导出。2. 训练环节数据准备与关键参数解析2.1 数据划分与增强策略数据准备好之后第一件事是划分数据集。我按8:1:1划分训练集、验证集、测试集。这个比例在中小规模数据集几百到几千张上是比较合理的训练集要足够多验证集不能太少否则评估结果波动太大。划分的时候有一个容易忽略的问题同一个场景连续拍摄的若干帧图片内容高度相似如果这些帧同时出现在训练集和验证集里验证指标会虚高。我处理的方式是先把连续帧按照场景分组同一组要么全进训练集要么全进验证集这样评估结果才真实反映模型的泛化能力。数据增强是提升模型鲁棒性的关键。YOLOv11训练时自带的增强策略包括Mosaic增强把四张图拼接成一张增加目标尺度的多样性对小目标检测特别有帮助。HSV扰动随机调整色相、饱和度、亮度。轨道图像受光照影响大这个增强能让模型对光线变化更鲁棒。随机翻转左右翻转注意轨道缺陷检测不能做上下翻转因为倒影和阴影会误导模型。随机仿射变换轻微旋转、缩放模拟巡检设备的角度变化。我在项目里的做法是默认增强保留Mosaic和HSV翻转只开左右翻转。如果你的缺陷类别里有些是方向敏感的比如裂纹翻转之后依然正确但某些特定形态的缺陷翻转后可能某一方向的样本变多了导致不平衡需要根据实际结果微调翻转概率。2.2 data.yaml配置与训练命令实操YOLOv11用ultralytics框架训练配置文件是data.yaml。里面就是数据路径和类别定义train: ./datasets/rail/images/train val: ./datasets/rail/images/val test: ./datasets/rail/images/test nc: 5 names: [crack, spalling, wear, missing_fastener, sleeper_damage]训练命令非常简单yolo detect train datarail_defect.yaml modelyolo11n.pt epochs150 imgsz640 batch16 device0参数的选择都有讲究输入分辨率imgsz设置为640。轨道缺陷里面小目标很多有人会直接切到1024但训练显存和推理耗时会明显增加。选640是因为YOLOv11在640尺度上预训练权重效果最好而且可以配合滑窗切图解决小目标问题后面细讲。batch size设成16前提是单卡有12G以上显存。如果显存不够优先调低到8而不是降低输入分辨率。epochs设为150但配合早停机制验证集mAP连续50轮不提升就会自动停止。实际训练中大概在90到120轮之间收敛。device0指定GPU。没有GPU也可以用CPU训练但速度会慢一个数量级建议至少一张入门级显卡。启动训练之后你主要是盯验证集mAP曲线和loss曲线的走势。前20轮loss快速下降是正常的之后逐步平缓。如果训练到50轮还在持续波动不收敛很可能是学习率过大或者数据里有脏样本。2.3 指标怎么看mAP、Precision、Recall训练完后会自动输出一组指标我平时主要看这四个Precision、Recall、mAP50、mAP50-95。这几个指标的记忆方式很直接Precision关注的是预测为正的里面有多少是对的Recall关注的是真实存在的目标里有多少被找出来了。mAP综合了这两个维度mAP50是IoU阈值为0.5时的平均精度mAP50-95则是在0.5到0.95区间上取平均更严格。在铁路缺陷检测这个场景里我个人的经验是Recall比Precision更重要。漏报一个缺陷可能导致安全事故而误报顶多是让巡检人员多看一眼。所以调参的时候可以适当降低置信度阈值确保该检出来的别漏掉。比如在测试集上把置信度阈值从默认的0.25调到0.15Recall能从88%提升到93%代价是Precision从95%降到90%这在巡检场景下是值得的权衡。训练权重会自动导出模型文件best.pt这个best是验证集mAP最高的那一轮不是最后一轮。我通常把best.pt作为最终部署模型。3. 界面系统实现登录注册与检测交互3.1 登录注册模块存储设计与密码安全登录注册模块看着简单但有几个细节值得说说。数据库用SQLite很好理解不用额外起服务。表结构这样设计CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE NOT NULL, password_hash TEXT NOT NULL, salt TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );密码不能明文存储这是底线。我用的是sha256加盐哈希注册时生成一段随机salt拼上密码一起做哈希把哈希值和salt一起存库。登录时取出salt重新拼接输入密码做哈希比对两个哈希字符串是否一致。import hashlib, os def hash_password(password: str, salt: str) - str: return hashlib.sha256((salt password).encode(utf-8)).hexdigest() def generate_salt() - str: return os.urandom(16).hex()登录成功后界面通过QStackedWidget切换到检测主界面。我另外用了一个全局变量保存当前登录用户名后续检测记录导出的时候会把用户名写进文件名里方便追溯是谁在什么时间做的检测。3.2 主界面设计与交互逻辑主界面的布局用了PyQt5的QMainWindow顶部放菜单栏和工具栏中间是检测画面显示区域右侧是结果列表。检测画面的显示我用QLabel控件通过setPixmap把QPixmap直接显示在界面上。推理时有一个关键问题如果直接在主线程里跑模型界面会在推理期间完全卡死表现为未响应。解决方法是把推理逻辑放到QThread里通过signal把结果传回主线程更新界面。class InferenceThread(QThread): result_ready pyqtSignal(object, object) def __init__(self, model, source): super().__init__() self.model model self.source source def run(self): results self.model.predict(sourceself.source, conf0.25, imgsz640) boxes results[0].boxes self.result_ready.emit(self.source, boxes)UI上提供一个加载模型按钮点击后可以选择本地训练的best.pt文件。模型加载本身也需要一定时间同样放在独立线程里完成加载完成后再弹窗提示。3.3 检测结果可视化与导出模型推理返回的boxes对象包含边界框坐标、置信度和类别索引。绘制检测框我用OpenCV直接画线宽根据原图分辨率动态调整。类别颜色固定分配同类别在画面中始终是同一种颜色方便巡检人员快速判断。置信度标签的格式是类别名 置信度比如crack 0.87。字体用OpenCV的cv2.FONT_HERSHEY_SIMPLEX字号0.6到0.8之间太小在视频画面里看不清太大又遮挡目标区域。结果导出支持两种格式CSV和带标注的图片。CSV每行一条检测记录包含图片名、类别、置信度、边界框坐标。标注图片则是在原图上画框后另存到导出目录。我建议把导出目录在界面上做成可配置的默认放在项目根目录的export文件夹下。4. 从零到一实操全流程与踩坑记录4.1 环境配置与依赖版本环境配置是整个项目里最容易劝退新手的一步。我用的环境是Python 3.9 PyTorch 2.1.0 CUDA 11.8 ultralytics库。依赖版本建议用途Python3.9 - 3.10运行环境ultralytics8.3.0及以上YOLOv11模型加载与推理torch2.1.0深度学习框架torchvision0.16.0图像处理opencv-python4.8.0图像读取与绘制PyQt55.15.9界面开发PyMySQL不用SQLite内嵌无需额外依赖安装ultralytics的时候有一个坑它依赖的opencv版本可能会和系统里已经装的opencv冲突导致import cv2时报错。建议用虚拟环境安装避免污染系统环境。GPU版本的PyTorch安装命令是pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118安装完检查GPU是否可用python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))输出True和显卡名称就说明环境OK了。这一步我每次都先跑一下省得后面训练到一半才发现GPU没启用浪费几个小时的排错时间。4.2 完整训练流程记录数据准备完毕、环境搭好之后直接跑训练命令。我用的是yolo11n.pt预训练权重作为起点相当于迁移学习比从零训练收敛快得多。整个训练过程我记录一下前10轮loss从8左右快速降到3左右20轮后降到1.5附近之后进入慢速下降阶段。验证集mAP50在60轮左右达到0.8590轮达到0.92之后基本平缓。到120轮时早停机制触发训练结束。训练完之后在验证集上做了一次bad case分析。我随机取了100张验证图片把预测错误的样本单独挑出来看。发现主要问题集中在裂纹漏检上——有些细裂纹和钢轨表面的划痕几乎无法用肉眼区分。解决办法是收集更多裂纹样本增加这个类别的数量占比。4.3 模型导出与系统联调训练好的best.pt是PyTorch格式部署时可以选择两种方式直接使用PyTorch格式推理时需要PyTorch环境适合本地演示和二次开发。导出为ONNX格式推理速度更快也可以部署到无PyTorch环境的生产系统中。导出命令yolo export modelbest.pt formatonnx imgsz640导出ONNX后可以在UI中选择是加载.pt还是.onnx模型。两者在界面上的调用逻辑略有不同.pt模型用ultralytics的predict.onnx模型用onnxruntime的InferenceSession跑推理。我建议第一次先跑通.pt版本等整个链路没问题了再尝试ONNX。联调阶段比较常见的界面问题有两个。一个是QThread反复启动导致程序崩溃或资源泄露解决办法是在启动新线程前检查旧线程是否还在运行确保它结束后再启动新线程。另一个是摄像头实时画面解析耗时过长导致画面卡顿我后来通过把摄像头的读取放在另一个线程里解决主线程只负责显示效率提高了不少。5. 常见问题排查表与经验心得5.1 训练阶段的坑训练阶段最常遇到的几个问题我整理了一张排查表现象可能原因解决办法显存不足OOMbatch size过大调小batch开启梯度累积loss震荡不收敛学习率过大降低初始学习率到1e-4过拟合严重训练数据太少加强数据增强增加样本mAP一直很低标注框和标签错误重新检查数据集标注质量训练速度太慢CPU训练或无GPU换GPU或降低imgsz验证集mAP和测试集差异大数据划分同场景帧泄漏按场景分组重新划分显存不足这个问题最不受欢迎因为遇到它的时候往往模型已经训练了一半。我的经验是训练前先跑一次预热脚本用一个小批次数据测试显存占用情况再决定最终的batch size。5.2 推理阶段的坑推理部署阶段漏检和误报是两个永恒的主题。最初部署到实拍视频里发现很多真实场景下的缺陷检测不到原因有两个一是真实缺陷的形态比训练集里的更复杂多变二是视频帧往往存在运动模糊。解决办法除了扩充训练集还可以在推理时对输入做预处理比如自动对比度增强或直方图均衡化让纹理细节更突出。误报集中在轨头磨耗亮光区域模型经常把反光区域判成剥落。处理思路是收集一批消除负样本确定无缺陷但容易激活检测器的图片加入训练集把train集的背景丰富度提升之后误报率降了将近一半。5.3 独家经验小目标检测的三种优化手段轨道缺陷里小目标特别多比如细裂纹可能只有十几像素宽。如果你也遇到小目标检测效果差的问题按照以下顺序尝试性价比从高到低首先是提高输入分辨率。这是最直接的方案把imgsz从640提到1024相当于把小目标放大了约1.6倍。代价是推理时间增加显存需求增大。如果部署机器显存够优先用这个方法。其次是滑窗切图检测。把大图切成互相重叠的多个小块每个小块单独送入模型推理最后再把结果合并回大图的坐标系。切图尺寸通常设为640x640重叠率50%左右这样小目标在每个窗口里都是相对清晰的。缺点是推理次数变多速度明显下降适合离线分析如果用于视频实时检测还要考虑多窗口之间的去重逻辑。最后是数据层面的人工补充。如果有条件专门把那些小尺寸目标样本挑出来做过采样或者用图像增强的方式把小目标放大后作为新样本加入训练集。这个做法见效慢但能从根本上提升模型对小尺寸目标的表征能力。还有一条冷门但有效的经验把输入转成灰度或做直方图均衡化。钢轨表面的缺陷往往以纹理差异而非色彩差异为主要特征灰度图在减少色彩干扰的同时有时反而能提升缺陷检测的准确率。我在部分场景做过实验均衡化后对裂纹和剥落的Recall提升了3到5个百分点。另一个值得重视的点是目标的长宽比。轨道缺陷类别里裂纹是典型的长条形而剥落接近块状。如果训练样本中裂纹框的宽高比分布过于集中会对不同走向的裂纹检测造成偏差。我的做法是在标注阶段尽量覆盖横向裂缝、纵向裂缝和斜向裂缝三种形态让模型学到更多形态变化。对这个项目后续扩展的一些个人看法检测系统本身跑通之后我复盘了整个过程觉得最值得沉淀的不是代码和模型而是数据流动的意识。从现场图片到标注文件再到训练数据和推理结果每一步都直接影响最终效果。很多项目一开始模型效果不理想追根溯源大概率是数据链路某个环节出了问题。后续如果要继续扩展我建议关注三个方向一是从静态图像检测延伸到视频连续帧跟踪利用帧间信息的关联性减少单帧漏检二是引入更丰富的输入模态比如红外热成像和可见光影像的融合很多早期缺陷在热像上更明显三是往边缘设备上落地把模型量化后部署到巡检机器人或小型边缘计算盒子上这需要工程化能力但也是工业视觉应用的必经之路。我个人在实际操作中最深的体会是模型再强也离不开对业务场景的理解。YOLOv11只是一个强大的工具真正让系统发挥价值的是你对轨道缺陷的了解、对数据分布的把控、对现场环境的敬畏。这套系统做完之后再去跑现场我的关注点已经完全变了——不再盯着钢轨表面看而是下意识地判断这段线路如果让模型来检测哪个位置可能会漏报哪段光照条件会让误报率上升。这种人机互补的视角或许是做这类项目最有趣的收获。 
长河君 · 2026/10/19 12:56:27 · 阅读 1.2k 基于YOLOv11的铁路轨道缺陷检测系统设计与实战
铁路巡检是个苦活儿。我早些年和某实验室的工程师跑过一段线路凌晨的天窗点几个人扛着探伤仪沿着钢轨一步步走眼睛盯到发酸。人工巡检的问题不在于不认真而在于人的注意力是有上限的——再仔细的老师傅连续盯几个小时也会漏掉细小裂纹。所以当YOLO系列模型逐步成熟之后用深度学习做轨道缺陷识别这件事几乎是必然的走向。这篇文章就围绕一个实际项目展开基于YOLOv11的铁路轨道缺陷识别检测系统包含完整的数据集处理流程、模型训练方案、PyQt5 UI界面、登录注册模块、Python源码和训练好的模型文件。我会把整个系统的设计思路、关键参数、实操步骤和踩过的坑一次性讲透。无论你是刚接触目标检测的初学者还是已经在做工业视觉落地的工程师这篇内容都能直接拿来参考。1. 系统整体设计思路与方案选型1.1 为什么是YOLOv11目标检测模型的迭代逻辑要理解为什么选YOLOv11得先把目标检测算法的演进捋一遍。早期的Faster R-CNN走的是两阶段路线先用Region Proposal Network生成候选区域再对每个区域做分类和回归。精度确实高但速度实在提不上去在工业现场动辄需要实时处理的场景里根本跑不动。SSD虽然把速度拉起来了但对小目标的检测效果一直不理想。YOLO系列把目标检测变成了单次回归问题直接在图像上预测边界框和类别速度优势非常明显。从YOLOv3到YOLOv8每一代都在权衡精度和速度。到了YOLOv11这一代几个关键改进让它特别适合轨道缺陷检测这类工业视觉任务骨干网络采用了C3k2结构比之前的CSPDarknet有更丰富的梯度流特征提取能力更强对钢轨表面那种细小的纹理异常更敏感。引入了部分自注意力机制让模型能更好地捕获全局上下文信息。轨道缺陷出现的区域往往和周围环境有强关联比如扣件缺失附近的枕木状态、裂缝周边的锈蚀痕迹注意力机制能帮模型建立这些关联。Anchor-Free检测头去掉了预设锚框的依赖减少了一个需要手动调整的超参数。轨道缺陷的形状差异极大——一条横向裂缝和一块剥落区域的宽高比完全不同Anchor-Free方案天然更适合这种目标形态不固定的场景。选型的时候我对比过YOLOv8和YOLOv11在同样的数据集上训练YOLOv11的mAP大约高了0.8到1.2个百分点推理速度几乎没有损失。考虑到我们还要在UI里做实时预览速度不能妥协最终就定了YOLOv11。对比项YOLOv8nYOLOv11n模型大小约6.3 MB约5.4 MB输入分辨率640x640640x640推理速度GPU约2.1 ms约2.0 ms同等数据下mAP基准提升约1%1.2 缺陷类别定义与数据集构建轨道缺陷检测不是笼统地检测有没有问题而是要告诉巡检人员哪里出了问题、是什么问题。类别的定义直接决定了模型的可用性。我在这个项目里把缺陷划分成五类钢轨表面裂纹、轨头剥落、钢轨磨损、扣件缺失、轨枕破损。这个分类不是拍脑袋定的参考了实际线路巡检中最常见、也是人工巡检最容易漏掉的情况。类别英文标识典型特征检测难度裂纹crack细线状灰度突变明显高目标小剥落spalling块状掉皮边缘不规则中磨损wear轨头亮面带面积较大低扣件缺失missing_fastener扣件位置为空上下文线索强中轨枕破损sleeper_damage混凝土块碎裂中数据集的来源主要有两个渠道现场巡检车拍摄的线路影像资料以及公开的轨道缺陷数据集。我强烈建议不管用开源数据还是自采数据一定要做一次人工复核。开源数据集里经常有标注框偏移、类别标签错误的情况脏样本会让训练过程非常痛苦——模型可能会去学习那些错误的标注特征收敛速度明显变慢。标注工具我用的是LabelImg它是VOC格式XML文件需要转换到YOLO格式TXT文件每行一个目标类别序号、中心点x、中心点y、宽度、高度均为归一化值。转换脚本用Python写一个批量处理就行核心逻辑就是读取XML里的bounding box坐标除以图片宽高得到归一化值。1.3 系统模块划分登录、界面、推理三层整个系统我拆成了三个模块用户层登录注册、交互层UI界面、核心层模型推理。这样拆的好处是各模块职责单一后续维护或者替换组件都方便。用户层负责登录注册、用户信息存储、会话管理。用SQLite存用户数据密码哈希处理。交互层负责展示检测画面、结果列表、按钮交互。用PyQt5实现模型推理放到独立线程里跑避免阻塞UI。核心层负责调用YOLOv11模型对输入图像做推理返回检测结果。数据流向是用户登录系统进入主界面加载模型选择输入来源单张图片、视频文件或摄像头实时画面模型推理返回检测框、类别和置信度界面把这些信息绘制出来并支持结果导出。2. 训练环节数据准备与关键参数解析2.1 数据划分与增强策略数据准备好之后第一件事是划分数据集。我按8:1:1划分训练集、验证集、测试集。这个比例在中小规模数据集几百到几千张上是比较合理的训练集要足够多验证集不能太少否则评估结果波动太大。划分的时候有一个容易忽略的问题同一个场景连续拍摄的若干帧图片内容高度相似如果这些帧同时出现在训练集和验证集里验证指标会虚高。我处理的方式是先把连续帧按照场景分组同一组要么全进训练集要么全进验证集这样评估结果才真实反映模型的泛化能力。数据增强是提升模型鲁棒性的关键。YOLOv11训练时自带的增强策略包括Mosaic增强把四张图拼接成一张增加目标尺度的多样性对小目标检测特别有帮助。HSV扰动随机调整色相、饱和度、亮度。轨道图像受光照影响大这个增强能让模型对光线变化更鲁棒。随机翻转左右翻转注意轨道缺陷检测不能做上下翻转因为倒影和阴影会误导模型。随机仿射变换轻微旋转、缩放模拟巡检设备的角度变化。我在项目里的做法是默认增强保留Mosaic和HSV翻转只开左右翻转。如果你的缺陷类别里有些是方向敏感的比如裂纹翻转之后依然正确但某些特定形态的缺陷翻转后可能某一方向的样本变多了导致不平衡需要根据实际结果微调翻转概率。2.2 data.yaml配置与训练命令实操YOLOv11用ultralytics框架训练配置文件是data.yaml。里面就是数据路径和类别定义train: ./datasets/rail/images/train val: ./datasets/rail/images/val test: ./datasets/rail/images/test nc: 5 names: [crack, spalling, wear, missing_fastener, sleeper_damage]训练命令非常简单yolo detect train datarail_defect.yaml modelyolo11n.pt epochs150 imgsz640 batch16 device0参数的选择都有讲究输入分辨率imgsz设置为640。轨道缺陷里面小目标很多有人会直接切到1024但训练显存和推理耗时会明显增加。选640是因为YOLOv11在640尺度上预训练权重效果最好而且可以配合滑窗切图解决小目标问题后面细讲。batch size设成16前提是单卡有12G以上显存。如果显存不够优先调低到8而不是降低输入分辨率。epochs设为150但配合早停机制验证集mAP连续50轮不提升就会自动停止。实际训练中大概在90到120轮之间收敛。device0指定GPU。没有GPU也可以用CPU训练但速度会慢一个数量级建议至少一张入门级显卡。启动训练之后你主要是盯验证集mAP曲线和loss曲线的走势。前20轮loss快速下降是正常的之后逐步平缓。如果训练到50轮还在持续波动不收敛很可能是学习率过大或者数据里有脏样本。2.3 指标怎么看mAP、Precision、Recall训练完后会自动输出一组指标我平时主要看这四个Precision、Recall、mAP50、mAP50-95。这几个指标的记忆方式很直接Precision关注的是预测为正的里面有多少是对的Recall关注的是真实存在的目标里有多少被找出来了。mAP综合了这两个维度mAP50是IoU阈值为0.5时的平均精度mAP50-95则是在0.5到0.95区间上取平均更严格。在铁路缺陷检测这个场景里我个人的经验是Recall比Precision更重要。漏报一个缺陷可能导致安全事故而误报顶多是让巡检人员多看一眼。所以调参的时候可以适当降低置信度阈值确保该检出来的别漏掉。比如在测试集上把置信度阈值从默认的0.25调到0.15Recall能从88%提升到93%代价是Precision从95%降到90%这在巡检场景下是值得的权衡。训练权重会自动导出模型文件best.pt这个best是验证集mAP最高的那一轮不是最后一轮。我通常把best.pt作为最终部署模型。3. 界面系统实现登录注册与检测交互3.1 登录注册模块存储设计与密码安全登录注册模块看着简单但有几个细节值得说说。数据库用SQLite很好理解不用额外起服务。表结构这样设计CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE NOT NULL, password_hash TEXT NOT NULL, salt TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );密码不能明文存储这是底线。我用的是sha256加盐哈希注册时生成一段随机salt拼上密码一起做哈希把哈希值和salt一起存库。登录时取出salt重新拼接输入密码做哈希比对两个哈希字符串是否一致。import hashlib, os def hash_password(password: str, salt: str) - str: return hashlib.sha256((salt password).encode(utf-8)).hexdigest() def generate_salt() - str: return os.urandom(16).hex()登录成功后界面通过QStackedWidget切换到检测主界面。我另外用了一个全局变量保存当前登录用户名后续检测记录导出的时候会把用户名写进文件名里方便追溯是谁在什么时间做的检测。3.2 主界面设计与交互逻辑主界面的布局用了PyQt5的QMainWindow顶部放菜单栏和工具栏中间是检测画面显示区域右侧是结果列表。检测画面的显示我用QLabel控件通过setPixmap把QPixmap直接显示在界面上。推理时有一个关键问题如果直接在主线程里跑模型界面会在推理期间完全卡死表现为未响应。解决方法是把推理逻辑放到QThread里通过signal把结果传回主线程更新界面。class InferenceThread(QThread): result_ready pyqtSignal(object, object) def __init__(self, model, source): super().__init__() self.model model self.source source def run(self): results self.model.predict(sourceself.source, conf0.25, imgsz640) boxes results[0].boxes self.result_ready.emit(self.source, boxes)UI上提供一个加载模型按钮点击后可以选择本地训练的best.pt文件。模型加载本身也需要一定时间同样放在独立线程里完成加载完成后再弹窗提示。3.3 检测结果可视化与导出模型推理返回的boxes对象包含边界框坐标、置信度和类别索引。绘制检测框我用OpenCV直接画线宽根据原图分辨率动态调整。类别颜色固定分配同类别在画面中始终是同一种颜色方便巡检人员快速判断。置信度标签的格式是类别名 置信度比如crack 0.87。字体用OpenCV的cv2.FONT_HERSHEY_SIMPLEX字号0.6到0.8之间太小在视频画面里看不清太大又遮挡目标区域。结果导出支持两种格式CSV和带标注的图片。CSV每行一条检测记录包含图片名、类别、置信度、边界框坐标。标注图片则是在原图上画框后另存到导出目录。我建议把导出目录在界面上做成可配置的默认放在项目根目录的export文件夹下。4. 从零到一实操全流程与踩坑记录4.1 环境配置与依赖版本环境配置是整个项目里最容易劝退新手的一步。我用的环境是Python 3.9 PyTorch 2.1.0 CUDA 11.8 ultralytics库。依赖版本建议用途Python3.9 - 3.10运行环境ultralytics8.3.0及以上YOLOv11模型加载与推理torch2.1.0深度学习框架torchvision0.16.0图像处理opencv-python4.8.0图像读取与绘制PyQt55.15.9界面开发PyMySQL不用SQLite内嵌无需额外依赖安装ultralytics的时候有一个坑它依赖的opencv版本可能会和系统里已经装的opencv冲突导致import cv2时报错。建议用虚拟环境安装避免污染系统环境。GPU版本的PyTorch安装命令是pip install torch2.1.0 torchvision0.16.0 --index-url https://download.pytorch.org/whl/cu118安装完检查GPU是否可用python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))输出True和显卡名称就说明环境OK了。这一步我每次都先跑一下省得后面训练到一半才发现GPU没启用浪费几个小时的排错时间。4.2 完整训练流程记录数据准备完毕、环境搭好之后直接跑训练命令。我用的是yolo11n.pt预训练权重作为起点相当于迁移学习比从零训练收敛快得多。整个训练过程我记录一下前10轮loss从8左右快速降到3左右20轮后降到1.5附近之后进入慢速下降阶段。验证集mAP50在60轮左右达到0.8590轮达到0.92之后基本平缓。到120轮时早停机制触发训练结束。训练完之后在验证集上做了一次bad case分析。我随机取了100张验证图片把预测错误的样本单独挑出来看。发现主要问题集中在裂纹漏检上——有些细裂纹和钢轨表面的划痕几乎无法用肉眼区分。解决办法是收集更多裂纹样本增加这个类别的数量占比。4.3 模型导出与系统联调训练好的best.pt是PyTorch格式部署时可以选择两种方式直接使用PyTorch格式推理时需要PyTorch环境适合本地演示和二次开发。导出为ONNX格式推理速度更快也可以部署到无PyTorch环境的生产系统中。导出命令yolo export modelbest.pt formatonnx imgsz640导出ONNX后可以在UI中选择是加载.pt还是.onnx模型。两者在界面上的调用逻辑略有不同.pt模型用ultralytics的predict.onnx模型用onnxruntime的InferenceSession跑推理。我建议第一次先跑通.pt版本等整个链路没问题了再尝试ONNX。联调阶段比较常见的界面问题有两个。一个是QThread反复启动导致程序崩溃或资源泄露解决办法是在启动新线程前检查旧线程是否还在运行确保它结束后再启动新线程。另一个是摄像头实时画面解析耗时过长导致画面卡顿我后来通过把摄像头的读取放在另一个线程里解决主线程只负责显示效率提高了不少。5. 常见问题排查表与经验心得5.1 训练阶段的坑训练阶段最常遇到的几个问题我整理了一张排查表现象可能原因解决办法显存不足OOMbatch size过大调小batch开启梯度累积loss震荡不收敛学习率过大降低初始学习率到1e-4过拟合严重训练数据太少加强数据增强增加样本mAP一直很低标注框和标签错误重新检查数据集标注质量训练速度太慢CPU训练或无GPU换GPU或降低imgsz验证集mAP和测试集差异大数据划分同场景帧泄漏按场景分组重新划分显存不足这个问题最不受欢迎因为遇到它的时候往往模型已经训练了一半。我的经验是训练前先跑一次预热脚本用一个小批次数据测试显存占用情况再决定最终的batch size。5.2 推理阶段的坑推理部署阶段漏检和误报是两个永恒的主题。最初部署到实拍视频里发现很多真实场景下的缺陷检测不到原因有两个一是真实缺陷的形态比训练集里的更复杂多变二是视频帧往往存在运动模糊。解决办法除了扩充训练集还可以在推理时对输入做预处理比如自动对比度增强或直方图均衡化让纹理细节更突出。误报集中在轨头磨耗亮光区域模型经常把反光区域判成剥落。处理思路是收集一批消除负样本确定无缺陷但容易激活检测器的图片加入训练集把train集的背景丰富度提升之后误报率降了将近一半。5.3 独家经验小目标检测的三种优化手段轨道缺陷里小目标特别多比如细裂纹可能只有十几像素宽。如果你也遇到小目标检测效果差的问题按照以下顺序尝试性价比从高到低首先是提高输入分辨率。这是最直接的方案把imgsz从640提到1024相当于把小目标放大了约1.6倍。代价是推理时间增加显存需求增大。如果部署机器显存够优先用这个方法。其次是滑窗切图检测。把大图切成互相重叠的多个小块每个小块单独送入模型推理最后再把结果合并回大图的坐标系。切图尺寸通常设为640x640重叠率50%左右这样小目标在每个窗口里都是相对清晰的。缺点是推理次数变多速度明显下降适合离线分析如果用于视频实时检测还要考虑多窗口之间的去重逻辑。最后是数据层面的人工补充。如果有条件专门把那些小尺寸目标样本挑出来做过采样或者用图像增强的方式把小目标放大后作为新样本加入训练集。这个做法见效慢但能从根本上提升模型对小尺寸目标的表征能力。还有一条冷门但有效的经验把输入转成灰度或做直方图均衡化。钢轨表面的缺陷往往以纹理差异而非色彩差异为主要特征灰度图在减少色彩干扰的同时有时反而能提升缺陷检测的准确率。我在部分场景做过实验均衡化后对裂纹和剥落的Recall提升了3到5个百分点。另一个值得重视的点是目标的长宽比。轨道缺陷类别里裂纹是典型的长条形而剥落接近块状。如果训练样本中裂纹框的宽高比分布过于集中会对不同走向的裂纹检测造成偏差。我的做法是在标注阶段尽量覆盖横向裂缝、纵向裂缝和斜向裂缝三种形态让模型学到更多形态变化。对这个项目后续扩展的一些个人看法检测系统本身跑通之后我复盘了整个过程觉得最值得沉淀的不是代码和模型而是数据流动的意识。从现场图片到标注文件再到训练数据和推理结果每一步都直接影响最终效果。很多项目一开始模型效果不理想追根溯源大概率是数据链路某个环节出了问题。后续如果要继续扩展我建议关注三个方向一是从静态图像检测延伸到视频连续帧跟踪利用帧间信息的关联性减少单帧漏检二是引入更丰富的输入模态比如红外热成像和可见光影像的融合很多早期缺陷在热像上更明显三是往边缘设备上落地把模型量化后部署到巡检机器人或小型边缘计算盒子上这需要工程化能力但也是工业视觉应用的必经之路。我个人在实际操作中最深的体会是模型再强也离不开对业务场景的理解。YOLOv11只是一个强大的工具真正让系统发挥价值的是你对轨道缺陷的了解、对数据分布的把控、对现场环境的敬畏。这套系统做完之后再去跑现场我的关注点已经完全变了——不再盯着钢轨表面看而是下意识地判断这段线路如果让模型来检测哪个位置可能会漏报哪段光照条件会让误报率上升。这种人机互补的视角或许是做这类项目最有趣的收获。