铁路轨道缺陷检测这个方向我做过不止一个类似的项目。早年间用的是传统图像处理加手工特征后来换成Faster R-CNN再后来跟风上了YOLOv5现在做巡检系统的第一反应就是YOLOv11。为什么因为轨道缺陷检测这个场景既要看得准又要跑得快还得方便以后往巡检车上部署YOLO系列一直是平衡得最好的那个。这篇文章就把我基于YOLOv11做的一套铁路轨道缺陷识别检测系统整个拆开讲——数据集怎么做、模型怎么训、UI界面怎么搭、登录注册怎么实现以及那些不踩一遍根本注意不到的问题。内容完整、可直接抄作业适合正在做毕业设计、课程项目或者是小团队想快速搭一套轨道缺陷检测原型的开发者参考。1. 项目整体设计与思路拆解1.1 轨道缺陷检测的需求到底特殊在哪铁路轨道缺陷检测和普通的通用目标检测不太一样。首先缺陷目标的形态非常多样性钢轨表面裂纹是细长条轨枕裂纹是线状扣件缺失是一个小区域内的结构性缺失螺栓松动则体现在几何位置的微变。这些目标尺寸小、对比度低、背景纹理复杂用通用检测模型直接跑效果往往不理想。其次轨道场景有强烈的先验结构。轨道是直线延伸的道床、轨枕、钢轨之间有固定的空间关系。这意味着检测系统不能只做“看到目标”还要能做“判断目标出现的位置是否合理”。比如扣件应该在轨枕两侧固定位置如果这个位置空了才算缺陷。这个业务逻辑决定了我们在模型输出的基础上还要叠加一层规则判断而不是完全甩手给神经网络。再一个痛点就是样本极度不均衡。正常运行轨道上缺陷是偶发事件缺样本是常态。我统计过一套真实巡检数据正常样本和带缺陷样本比例可能超过100比1。这种情况下单纯靠模型硬学很容易把所有目标都判成正常或者反过来正常纹理扰动都误报成裂纹。解决这个问题不能光靠调参要从数据构建和损失设计两种思路同时下手。1.2 为什么选了YOLOv11而不是其他模型选模型的时候我其实快速对比了三条路。一条是继续用YOLOv5/v8一条是切到RT-DETR这类Transformer检测器另一条就是直接用最新的YOLOv11。YOLOv8和YOLOv11相比从部署角度看差异不大但v11在几个点上更戳我。一是它的C3k2模块在相同参数量下特征提取更充分对细小裂纹这类目标更友好二是v11对anchor-free的回归方式做了进一步优化在目标尺度差异大的场景下收敛更快泛化也更好。用大白话说就是同样的训练轮次v11能比前代更容易“学会”看裂纹那点细微的线条纹理。RT-DETR我也试过精度确实能打但推理速度在CPU和低端GPU上都不够理想。轨道巡检场景经常要跑在巡检小车上的边缘设备功耗和散热都是约束我没法为了一点精度放弃实时性。另外还有一点很现实YOLOv11的生态太好了。模型训练用ultralytics库一句话就能起训导出ONNX、TensorRT也很顺。对于这套要交付的完整系统来说后续的集成和维护成本是最低的。1.3 系统整体架构怎么拆整套系统我分成了四个模块职责非常清晰。第一个是数据层负责样本的采集、标注、增强和格式转换。这部分不直接跟业务代码耦合独立成一个文件夹方便后续继续扩展数据。第二个是模型层负责训练、验证、导出。我自己在项目里用了一个固定的结构训练批处理脚本、模型权重文件、推理用的Python封装类分开存放。第三个是业务层把模型推理结果和轨道结构规则融合生成缺陷类型、位置、置信度、报警级别这些结构化数据。第四个是展示层也就是PyQt5写的桌面UI包含登录注册、图片检测、视频检测、实时摄像头检测、历史记录和结果导出。这样拆的好处是每一层都可以单独替换。后续如果换了更轻量的模型只需要改模型层接口UI层完全不用动。如果业务规则要更新也只需要在业务层加规则文件不碰UI和模型。2. 数据集构建与标注要点2.1 数据来源怎么解决采集有哪些坑轨道缺陷数据最麻烦的就是获取。项目部会有些巡检记录和病害台账但数量有限而且角度单一。我这边最终是三个来源混在一起用的。第一是自己的采集车拍的高清巡检视频抽帧后按缺陷类型筛选保证真实性和覆盖角度。第二是网上能找到的开源轨道缺陷数据集但需要自己做清洗因为不同数据集的标注规范、图片分辨率、光照条件差异很大直接混训容易互相干扰。第三是做了一部分数据增强衍生样本比如对已有缺陷区域做局部变换生成更多裂纹朝向、裂纹宽度不同的变体。采集阶段有一个我踩过的坑最初我只关注白天晴天数据模型在阴天和隧道环境下漏检率直接翻倍。后来我在样本里刻意加入了不同光照、水渍反光、杂草遮挡的图片才把训练效果拉回正轨。做轨道场景数据多样性比数据量更关键覆盖率上去了模型才能真正在巡检中扛得住。2.2 标注规格与工具选择标注格式我统一用YOLO的txt格式每一行是“类别ID 中心点x 中心点y 宽度 高度”所有坐标都用图片宽高做归一化取值在0到1之间。类别的定义是模型学什么的直接依据定多了模型搞混定少了业务不好做。我这套项目实际定义了六类钢轨裂纹、轨枕裂纹、扣件缺失、螺栓松动、道床异物、钢轨断裂。其中钢轨断裂虽然样本最少但业务价值最大我给它在损失函数里加了类别权重。标注工具我用的是LabelImg虽然老一点但上手极快对团队内非专业标注员很友好。如果要对大量数据做自动预标注也可以用训练好的模型去生成初版标注交给人工去改能省不少时间。注意裂纹类目标不要把纹理边缘都框进去尽量紧贴缺陷主体。框大了会让模型学到背景纹理而不是缺陷本身训练半天误检降不下去。2.3 数据增强策略与数据集划分增强这块我不建议直接全开。我试过一上来就开Mosaic结果训练前期loss波动极大小目标本来就没几个像素再被Mosaic切碎更学不到。实际的策略是分阶段前30轮只开基本翻转、缩放、亮度变化等模型对目标有基本感知后再开Mosaic和Cutout这类强增强。在具体参数上我惯用的一组配置HSV饱和度扰动0.2亮度扰动0.15随机翻转打开旋转范围正负5度平移0.1缩放0.2。轨道目标是有方向性的旋转角度不敢给太大转多了钢轨的几何先验就崩了。数据划分我保持训练集80%、验证集10%、测试集10%的原则。测试集这部分会单独抽出来保证同类缺陷不出现在训练集里这样才能真正评估模型在没见过的新位置上的泛化能力。如果是自己从视频抽帧得到的图片还要避免同一段连续帧被同时分到训练和测试否则就相当于开卷考试测试指标全是虚高。3. YOLOv11模型训练与调优实战3.1 环境配置与项目目录训练环境我用了PyTorch 2.x搭配CUDAultralytics库直接pip安装就行不用从源码编。显卡是消费级的只要显存8G以上跑默认尺寸训练基本没问题。建议项目目录按下面这种方式组织rail_defect_detection/ ├── data/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── models/ │ ├── yolo11n.pt │ └── best.pt ├── scripts/ │ ├── train.py │ ├── detect.py │ └── convert_to_onnx.py ├── ui/ │ ├── login_window.py │ ├── main_window.py │ └── resources/ └── requirements.txt这个结构看起来简单但很重要的一点是图片和标签必须严格同名且一一对应路径不要出现中文和空格否则训练脚本读数据的时候会有各种莫名其妙的报错。我见过太多人卡在这一步根本不是模型或者参数问题就是路径里有个中文括号。3.2 训练命令与关键参数训练是用ultralytics的命令行起的我在项目里写成了脚本方便复现yolo detect train \ modelyolo11n.pt \ datarail_defect.yaml \ epochs200 \ imgsz640 \ batch16 \ lr00.001 \ lrf0.01 \ optimizerAdamW \ weight_decay0.0005 \ patience30 \ cacheTrue \ device0几个参数的解释给初学者排一下坑。imgsz640是分辨率想提升小目标检出率可以试768但显存占用和推理耗时都会涨轨道巡检如果是实时跑640是性价比较高的选择。patience30是早停耐心值连续30轮val指标不涨就自动停能防止过拟合也省时间。weight_decay调的是正则强度不要随手填个0.1然后又来问为什么loss不降这个值适合的量级是0.0005左右。数据配置文件长这样path: ./data train: images/train val: images/val names: 0: rail_crack 1: sleeper_crack 2: missing_fastener 3: loose_bolt 4: ballast_foreign_body 5: rail_break要特别注意的是YOLO格式的数据集路径配置中path字段作为根目录train和val是相对path相对路径。千万别把绝对路径写死换个机器跑就废了。我一般用一个相对路径配置训练脚本从项目根目录启动。3.3 训练结果怎么看指标怎么判断训练结束后重点看几个指标mAP0.5、mAP0.5:0.95、Precision和Recall。常见的错误是只看mAP0.5很高就以为模型能用。轨道缺陷检测属于安全关键场景漏检的代价远高于误报所以要优先看Recall。意思是能召回的缺陷占所有真实缺陷的比例这个低下去说明模型有漏巡检就会把病害漏过去。我的这套数据集和配置训下来mAP0.5做到0.87左右mAP0.5:0.95在0.63左右Precision和Recall都能保持在0.8以上。这里给一个判断经验如果Precision高但Recall低说明模型偏保守宁可漏也不报可以降低置信度阈值或者在损失里上调正样本权重。反过来Recall高但Precision低就是误报多可以把置信度阈值往上提。还要强调一点训练完不要只盯着验证集指标要单独跑一遍测试集。拿测试集里最典型的缺陷图片去看模型画框画得准不准框是不是紧贴缺陷边缘。指标是统计上的参考人眼扫一遍结果图才是最终判断。模型画框画得歪七扭八即便指标达标交付的时候业务方直接就会打回来。导出模型到部署格式也是一个重要节点from ultralytics import YOLO model YOLO(best.pt) model.export(formatonnx, imgsz640, dynamicFalse, simplifyTrue)导出ONNX后后续想走TensorRT加速或者接入推理引擎就有基础了。不过导出之后一定要实测推理结果因为有些算子在不同框架下的表现会有细微差别不是导出成功就万事大吉。4. UI界面与登录注册模块实现4.1 桌面端还是Web端我的选择逻辑做UI之前先定技术路线。这套系统的使用者是巡检人员或实验室维护人员使用场景偏固定工位数据要落本地推理要方便调用显卡资源。所以我选了PyQt5做桌面端而不是Flask做Web端。PyQt5有几项我比较看中的点一是自带窗口管理系统做登录后跳转主界面很顺二是QThread做推理任务线程隔离方便界面不会卡死三是打包成exe后单机部署简单不必要求使用方去配置浏览器环境。当然如果需求是多人远程访问、需要同时给多个业务人员使用那就要考虑后端服务加Web前端。但这不是主需求。桌面端做的事情不复杂核心就是三块登录注册的用户信息管理、检测主界面、结果展示与历史记录。4.2 登录注册界面与数据库设计登录注册的基础是用户数据存储。我这边直接用SQLite轻量无需单独配置服务一个文件搞定适合项目交付不需要用户去安装数据库客户端。用户表结构很简单CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT NOT NULL UNIQUE, password_hash TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );密码安全这里我要多说一句绝对不要明文存密码。我自己用的是hashlib配合盐值做哈希虽然比专门的bcrypt库弱一点但对于这个项目场景已经比明文强了不止一个量级。逻辑就是注册时生成一段随机盐值把盐值拼上密码做SHA-256得到哈希然后把盐值和哈希一起存进库。登录时取出盐值对输入的密码再做一次同样的哈希对比一致才放行。这样哪怕数据库文件泄露也无法反推原始密码。登录注册界面用PyQt5的QDialog实现窗口上放两个按钮登录和注册。注册弹一个子窗口填用户名和密码校验两次输入一致检查用户名是否已存在都通过才写入数据库。登录成功后窗口关闭再打开主界面。这里有个执行细节数据库操作不要放到UI主线程里做长I/O用户点击登录到校验完成的响应要快。如果后面用了远程数据库更是要把数据操作封装到单独的函数模块里通过信号与槽把结果传回界面。PуQt的线程之间不能直接操作界面控件这是新手最容易踩的问题。4.3 检测主界面与核心交互流程主界面我设计成左右两栏布局。左侧是操作面板包含功能按钮和参数设置右侧是画布区展示原始图像和检测结果图。左侧按钮至少包括图片检测、视频检测、摄像头检测、暂停/继续、保存结果、历史记录。参数设置区域放两个QDoubleSpinBox分别调置信度阈值和IoU阈值。这样使用方不用改代码就能适配不同场景。图片检测这部分逻辑是点击“图片检测”弹出QFileDialog选择图片加载图片到左侧预览区同时调model.predict()拿到检测结果在结果图上绘制边界框、类别标签和置信度把结果同时存一份到当天的检测记录里。推理不要直接写在主窗口的业务代码里。init中加载模型检测操作放到QThread的子线程里通过signal把结果图传回主线程更新UI。如果不这样做视频检测或者连续处理大批量图片时界面直接无响应体验极差。视频检测和摄像头检测的实现是类似的都是先打开视频流按帧读取抽帧送入模型推理绘制检测框后再显示。摄像头检测还要注意一点巡检场景一般帧率不高每帧都推理反而浪费资源。我通常加一个帧跳过机制比如每两帧跑一次检测中间帧直接展示上一帧结果这样UI流畅度会好很多模型也有更充裕的推理时间。4.4 历史记录与结果导出检测结果不能看了就完。轨道缺陷检测是要有台账的一段轨道哪里发现过问题、缺陷类型和置信度是多少、后续是否再次出现过这些都要能追溯。我做了两张表一张存每条检测记录的主信息另一张存记录内每张图片的详细框信息。选一张图片检测后历史记录会把缺陷类型、数量、位置信息列成表格展示出来。导出方面支持了CSV导出方便用户在自己的业务系统里做二次汇总。如果业务方有更复杂的报表需求我会建议导出成JSON格式让他们自己对接。一个完整的检测记录我一般存下来这七个字段时间、图片路径、缺陷类型、置信度、边界框坐标、检测任务ID、备注。这个结构基本够用多了反而乱。注意导出CSV时使用默认的utf-8编码会导致Excel打开中文乱码要在写入时改用utf-8-sig编码。这个小细节交付时最容易接到使用方的埋怨。5. 常见问题与排查技巧实录5.1 训练阶段的典型问题我按照自己实际踩坑的顺序把最常遇到的问题整理成了一张速查表。问题现象可能原因排查与解决loss不下降一直卡在某个值附近学习率过大或类别标签有误先查标签txt里每行是否五个数值将学习率降到0.0001试跑50轮训练到一半内存直接拉满缓存全量读入cacheTrue且图片尺寸过大改成cacheFalse或将imgsz降到512或减少batch小目标裂纹几乎不检出输入分辨率低或原始框太小上调imgsz到768对含小目标的图像做滑窗切图检查标注框宽度是否小于3像素验证集mAP高但测试集崩数据划分时同一场景帧泄漏进多个集合严格按场景而不是按单帧划分同一视频不要同时出现在train和val训练指标正常推理明显掉点导出ONNX后算子兼容问题不要直接信任导出链用测试集对比导出前后推理结果的边界框差异类别不均衡导致某一类学废了部分类别样本数过少提高类别权重或做该类别的针对性裁剪增强不要指望通用增强自动平衡样本均衡还有一个更直接的思路如果某个缺陷类别确实只有几十张图那就别硬凑去合成一部分样本。裂纹可以用图像处理在无缺陷轨枕背景上合成线条噪声扣件缺失可以拍摄同一机位有/无扣件的对比图用后处理做遮挡模拟。这种方法不是歪门邪道工业视觉项目里很常见。5.2 推理与界面的典型问题推理和UI层面的问题一半出在模型加载和线程处理上另一半出在对OpenCV和PyQt的图像格式转换上。首先是模型加载路径。交付后换一台电脑经常出现模型路径写死导致启动即崩溃。最终代码里要把模型路径做成相对路径结合sys.path定位到项目根目录再拼接模型文件名而不是在代码里写死一个C:\\Users\\xxx\\best.pt。其次是图像格式转换。cv2.imread读进来的图是BGR通道顺序PyQt界面显示时通常要转成RGB而QImage显示又要求数据连续、通道对齐。如果显示出来的图颜色发蓝就是BGR转RGB那一步漏了。这类问题以前经常让我排查到想摔键盘后来写了一个专门的工具函数来处理所有图像转QPixmap的流程一劳永逸。最后是线程崩溃。如果在子线程里弹出了QMessageBox程序极大概率闪退原因就是跨线程操作UI。我的处理方式是将所有UI操作集中到一个信号槽里子线程只管发送信号主线程的槽函数里去更新显示、弹窗、写日志。只要记住“线程只管算主线程只管画”这一条绝大多数界面卡死和闪退都不会发生。5.3 部署交付的打包细节打包PyQt应用我用的PyInstaller。核心命令是pyinstaller -D -w -n RailDefectDetector main.py-w参数隐藏控制台窗口-D生成目录模式方便放模型文件和数据文件夹不建议用-F打包单文件模式。单文件模式每次启动都要解压到临时目录那点冷启动时间在巡检现场会显得特别漫长。打包后别忘了把模型文件、数据文件夹一并放到exe同级的目录下。这里有个高频坑PyQt的资源文件和ultralytics自带的配置文件都可能被遗漏在打包之外启动时报缺少资源。建议打包后立刻在另一台干净机子上做一次完整冒烟测试把图片检测、视频检测、登录注册全走一遍再交付。6. 个人体会与进一步扩展思路这套系统做下来我的整体感受是技术栈本身并不神秘难点全在细节和边界情况上。YOLOv11、PyQt5、SQLite这些工具都是成熟技术真正的工程挑战是你能不能把模型效果稳定交付成业务方随手能用的产品。我自己在实际操作中最深的体会是不要过度迷信模型结构先花时间把数据和标注弄干净。这套系统训练效果提升最明显的一次改动不是换更复杂的模型结构而是重新清理了一遍标注把那些框偏了、框大了、标签标错的样本修正掉。这个动作直接让mAP提升了将近三个点比调任何参数都值。后续如果要继续扩展两条路值得考虑。一条是往轻量化方向走尝试把YOLOv11n蒸馏成更小尺寸的模型或者直接用TensorRT加速提高实时检测的帧率解放部署环境对GPU的依赖。另一条是增强缺陷的时序信息视频流检测时不只是单帧独立判断而是把连续几帧的检测框做跟踪匹配用置信度累加来判断这能显著降低单帧误报和闪烁。最后再分享一个交付时候的小技巧给使用方交付系统时除了代码和说明书一定要附带一个“模型效果说明和限制”文档。明确写上当前模型对白天光照、清晰轨面场景检测率最高对极端雨雪、重度锈蚀场景可能存在漏检建议配合人工抽检使用。这样既能让使用方对系统边界心里有数后续真出了问题也不是开发者一个人背锅。做工程交付把话说在前头比事后解释省心太多。