企业官网建设流程全解析

简介：这份资源面向从事工业质检、缺陷检测方向的目标检测学习者与工程人员，提供管道焊接缝缺陷检测数据集，按YOLOV5目录格式整理，可直接投入训练，省去格式转换与标注清洗的繁琐环节。数据为800×800的RGB图像，共2个类别：good与bad，覆盖合格与缺陷两类焊缝状态，适合二分类检测任务与模型对比实验。压缩包内共1995个文件，以jpg图像与同名txt标注为主，另含1个可视化py脚本和1个png说明图，整体约93.27MB；训练集908张图片配908个标签，验证集206张图片配206个标签，划分清晰。可视化脚本随机传入一张图片即可绘制边界框并保存到当前目录，无需修改即可运行，便于快速核验标注质量。目前已有196人学习下载，适合需要现成数据快速验证YOLO系列模型效果、搭建缺陷检测流程的读者参考使用。

1. 管道焊缝缺陷检测数据集：908 张训练图能跑出什么名堂

管道焊接缝的缺陷检测，在工业质检里属于典型的「小目标 + 高误检代价」场景。焊缝上一条几毫米的裂纹、一个气孔，肉眼在强光下都未必看得清，但一旦漏检，后续打压测试直接爆管。这份数据集把问题简化成了最朴素的二分类：good 和 bad。训练集 908 张图配 908 个 txt 标签，验证集 206 张配 206 个，全部是 800×800 的 RGB 图像，按 YOLOV5 的目录格式组织，总大小 94MB。拿到手不需要做格式转换，改个 data.yaml 就能开训。适合谁？手上已经有 YOLOv5 或 YOLOv8 训练环境、想快速验证焊缝缺陷检测可行性的工程师，以及需要一个小规模工业缺陷数据集做课程设计或算法对比的从业者。它不解决「缺陷分类细化」的问题，只回答一件事：这张焊缝图里有没有缺陷。

2. YOLOV5 目录结构与标签格式：为什么拿到就能训

2.1 目录树拆解与文件对应关系

这份数据集的核心价值在于「零预处理」。YOLOV5 对数据集的目录结构有固定要求，很多人在这一步翻车——图片和标签对不上、路径写错、类别索引从 1 开始导致训练时类别越界。先看它的实际组织方式：

datasets/ ├── images/ │ ├── train/ # 908 张 jpg │ └── val/ # 206 张 jpg ├── labels/ │ ├── train/ # 908 个 txt │ └── val/ # 206 个 txt └── data.yaml # 类别配置

图片和标签是严格同名的：IMG (1128).jpg对应IMG (1128).txt。YOLOv5 在加载时会把images路径替换成labels再找同名 txt，所以文件名里带空格和括号不影响，但如果你手动重命名时改了编号，标签就丢了。训练集 908 对、验证集 206 对，比例大约是 8:2，对于二分类缺陷检测来说，验证集 206 张够看出过拟合趋势，但不够做精细的阈值调优。

2.2 标签 txt 的归一化坐标与类别索引

每个 txt 文件里是一行或多行标注，格式为：

<class_id> <x_center> <y_center> <width> <height>

全部是归一化到 0~1 的浮点数。这份数据集只有 2 类，good 和 bad，类别索引通常是 0 和 1。这里有一个高频翻车点：如果你自己写脚本生成标签时把类别写成 1 和 2，YOLOv5 训练时会报Label class 2 exceeds nc=2。检查方法很简单：

# 统计所有标签文件里出现过的类别 id cat datasets/labels/train/*.txt | awk '{print $1}' | sort -u

正常输出应该只有0和1。如果出现其他数字，要么是类别定义错了，要么是标签文件混入了其他数据集。另外注意，YOLOv5 的标签里不允许出现空行或纯空格行，有些标注工具导出时会留空行，训练时虽然不报错，但会浪费一个 batch 位置。

2.3 data.yaml 的最小配置与路径陷阱

YOLOv5 训练时必须指定一个 data.yaml，里面至少包含train、val、nc、names四个字段。这份数据集没有附带 yaml，需要自己写：

# data.yaml train: ../datasets/images/train val: ../datasets/images/val nc: 2 names: ['good', 'bad']

路径写法有两个坑。第一，train和val指向的是图片目录，不是标签目录，YOLOv5 会自动推导标签路径。第二，相对路径是相对于train.py的运行目录，不是 yaml 文件所在目录。我一般直接用绝对路径，省得排查半天「为什么找不到图片」。如果是在 Docker 里跑，注意挂载路径要和 yaml 里一致，否则会报No labels found。

3. 从零跑通训练：命令行参数与可视化验证

3.1 环境准备与依赖版本

YOLOv5 对 PyTorch 和 CUDA 版本比较敏感，但这份数据集只有 1114 张图，CPU 也能跑，只是慢。常见做法是：

# 创建环境 conda create -n weld python=3.9 conda activate weld # 安装 PyTorch（根据你的 CUDA 版本选） pip install torch==1.13.1 torchvision==0.14.1 # 克隆 YOLOv5 git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt

注意不要用最新的 torch 2.x 配老版 YOLOv5，有些算子会报ATen相关错误。如果只是验证数据集能不能用，装 CPU 版 torch 就行，训练 100 epoch 大概 20 分钟。

3.2 启动训练：关键参数怎么设

python train.py \ --data data.yaml \ --weights yolov5s.pt \ --img 800 \ --batch-size 16 \ --epochs 100 \ --device 0 \ --project runs/weld \ --name exp1

逐项说明：--img 800必须和数据集分辨率一致，YOLOv5 默认 640，如果强行用 640 训练，焊缝上的小缺陷会被缩放到几乎看不见。--batch-size 16在 8GB 显存下比较稳，如果 OOM 就降到 8。--weights yolov5s.pt用预训练权重，小数据集上从头训很容易过拟合。--epochs 100是起步值，实际看 mAP 曲线，如果 50 epoch 后验证集 mAP 还在涨，可以加到 200。--device 0指定第一块 GPU，CPU 训练改成--device cpu。

训练过程中重点看三个指标：train/box_loss是否稳定下降、val/box_loss有没有反弹、metrics/mAP_0.5的爬升趋势。如果 val loss 在 20 epoch 后开始上升而 train loss 继续降，就是过拟合，需要加数据增强或减模型复杂度。

3.3 可视化脚本：随机抽图验证标注质量

数据集附带了一个可视化 py 文件，随机传入一张图片就能画边界框并保存到当前目录。这个脚本的价值在于：训练前先肉眼确认标签有没有画错。焊缝缺陷的标注尤其容易出问题——有些 bad 样本的框只框了缺陷的一部分，有些 good 样本被误标了框。脚本无需更改，直接运行：

python visualize.py

它会在当前目录生成一张带框的图。我一般会跑 10 次，每次随机抽一张，重点看 bad 类的框是否完整覆盖缺陷区域。如果发现框明显偏移或漏标，说明标签质量有问题，这时候直接训练就是在拟合噪声。另一个用法是训练后拿预测结果和这个脚本画的 GT 框对比，能快速判断模型是「没学好」还是「标签本身有问题」。

4. 避坑与排查：焊缝缺陷检测的五个血泪经验

4.1 现象：训练 loss 正常但 mAP 始终为 0

原因：类别索引和 names 顺序不匹配。YOLOv5 在计算 mAP 时会按 names 列表的顺序匹配类别，如果标签里 0 是 bad、1 是 good，但 yaml 里写的是['good', 'bad']，模型学到的类别就反了，验证时全部判错。解决：用awk '{print $1}'统计标签类别分布，确认 0 和 1 分别对应什么，再改 names 顺序。

4.2 现象：验证集图片加载报错cannot identify image file

原因：图片文件名里的空格和括号在某些 OpenCV 版本下会被截断。IMG (1128).jpg在 Linux 下没问题，但在 Windows 或某些 Docker 镜像里，路径解析可能把空格当分隔符。解决：批量重命名，把空格和括号去掉：

# 在 images 和 labels 目录下分别执行 for f in *; do mv "$f" "$(echo $f | tr -d ' ()')"; done

注意图片和标签要同步重命名，否则对不上。

4.3 现象：训练到一半报CUDA out of memory

原因：--img 800比默认 640 多占约 56% 显存，加上 batch-size 16，8GB 卡容易爆。解决：先降 batch-size 到 8，如果还爆就开梯度累积--accumulate 2，等效 batch-size 不变但显存占用减半。另一个办法是用--img 640训练，但焊缝小缺陷的召回会明显下降，不建议。

4.4 现象：验证集 mAP 很高但实际推理漏检严重

原因：验证集和训练集来自同一批数据分布，206 张验证图可能和训练图拍摄条件高度相似。解决：自己额外留 20~30 张不同光照、不同角度的焊缝图做测试集，不要混入训练。如果测试集 mAP 比验证集低 15 个点以上，说明模型泛化能力不足，需要加更多数据增强（--augment）或换更大的模型。

4.5 现象：可视化脚本画出的框和实际缺陷位置对不上

原因：YOLO 格式的坐标是归一化的，但可视化脚本可能按原图尺寸还原时用了错误的宽高。800×800 的图如果被 resize 过，坐标还原就会偏。解决：确认脚本里读取图片后没有做 resize，直接用cv2.imread的原始尺寸乘归一化坐标。如果脚本里写了cv2.resize(img, (640,640))，把这一行删掉。

5. 进阶技巧：用 206 张验证图做阈值调优与模型导出

5.1 置信度阈值与 IoU 阈值的联合调参

YOLOv5 默认推理阈值是--conf-thres 0.25、--iou-thres 0.45。在焊缝缺陷检测里，bad 类的漏检代价远高于误检，所以应该降低 conf 阈值提高召回。我一般会跑一组对比：

# 在验证集上批量测试不同阈值组合 for conf in 0.1 0.15 0.2 0.25; do for iou in 0.4 0.45 0.5; do python val.py --data data.yaml --weights runs/weld/exp1/weights/best.pt \ --img 800 --conf-thres $conf --iou-thres $iou --task val done done

重点看metrics/precision和metrics/recall的平衡。如果 recall 低于 0.85，继续降 conf 到 0.1；如果 precision 掉到 0.6 以下，说明误检太多，需要检查 good 类里是不是混入了标注错误的 bad 样本。206 张验证图虽然不多，但足够看出阈值变化的趋势。

5.2 导出 ONNX 与推理速度测试

训练完成后导出 ONNX 方便部署到 C++ 或边缘设备：

python export.py --weights runs/weld/exp1/weights/best.pt \ --include onnx --img 800 --batch 1

导出后可以用onnxruntime测单张推理耗时：

import onnxruntime as ort import numpy as np import time sess = ort.InferenceSession("best.onnx") img = np.random.randn(1, 3, 800, 800).astype(np.float32) # 预热 for _ in range(5): sess.run(None, {"images": img}) # 计时 start = time.time() for _ in range(50): sess.run(None, {"images": img}) print(f"平均耗时: {(time.time()-start)/50*1000:.1f} ms")

800×800 输入在 RTX 3060 上大约 12~15ms，CPU 上 80~120ms。如果部署到树莓派这类设备，建议先导出 FP16 或 INT8，但要注意焊缝小缺陷的精度损失，量化后一定要用验证集重新跑一遍 mAP。

5.3 一个习惯：训练前先跑一遍标签检查脚本

从那以后我每次拿到新数据集，都强制走一遍标签检查：统计类别分布、检查空标签文件、确认图片和标签数量一致、随机抽 10 张可视化。这份数据集虽然标称 908+206 对，但实际用的时候还是自己数一遍最踏实。尤其是工业缺陷数据，标注质量参差不齐，花 10 分钟检查能省下几小时的无用训练。希望帮到你。

本文还有配套的精品资源，点击获取