简介面向计算机视觉目标检测任务的集装箱缺陷检测数据集包含1476张集装箱表面缺陷图片涵盖Deframe变形、Dent凹坑、Hole孔洞、Rusty锈蚀、Scratch划痕五类常见缺陷共4227个标注框。数据同时提供Pascal VOC和YOLO两种格式的标注文件可直接用于训练Faster R-CNN、YOLO系列等检测模型适合工业质检、港口运维等场景的算法研发与教学实验。压缩包共2000个文件以jpg图片配合xml与txt标注为主其中xml为VOC格式、txt为YOLO格式标签文件与图片一一对应另含说明文档整体约163.76MB。该数据集已吸引494人关注下载标注规范、类别分布清晰便于研究者快速开展缺陷检测模型训练与评估也可作为毕业设计或企业项目的数据基础。1. 集装箱缺陷检测为什么拿到数据集的第一天都在处理格式做过工业质检的人都有这种体会模型选型、训练参数都不是最耗时的真正磨人的是数据本身。一份标注好的集装箱缺陷检测数据集跑到手里是 1476 张、5 类缺陷、带 VOC 和 YOLO 两种格式听起来省事实际上第一周的工作基本都耗在格式转换、标签校验和类别平衡这三件事上。这份数据集能解决的是集装箱外表面缺陷检测的起步问题适合正在做港口、物流园或钢厂表面质检方案的人也适合想用目标检测练手但找不到工业场景数据的学习者。它的价值不在 1476 这个数字而在标注格式是否干净、类别定义是否一致、坐标有没有越界——这些才是直接决定训练能不能跑通、mAP 能不能看的因素。2. 这 1476 张图里到底有什么VOC 与 YOLO 双格式的构成拆解2.1 用 VOC 还是用 YOLO两种格式的坐标系统与适用场景拿到压缩包第一件事不是解压看图片而是先看清目录结构。这类集装箱缺陷检测数据集常见做法是把同一批图片同时导出成 VOC 和 YOLO 两套标注VOC 用 XML 存边界框YOLO 用 TXT 存归一化坐标。两套格式各有各的适用场景VOC 适合用 Faster R-CNN、SSD 这类框架或者你需要在 LabelImg 里人工复核标注YOLO 格式则直接喂给 YOLOv5、YOLOv8 这类模型训练时不需要中间转换。两种格式最关键的区别是坐标表达方式做格式衔接之前必须先把这个映射关系刻在脑子里对比项VOC XMLYOLO TXT坐标形式左上角 xmin、ymin 与右下角 xmax、ymax像素绝对值中心点 cx、cy 与宽 w、高 h均除以图宽图高做了归一化类别表达字符串如namedent/name整数索引 class_id从 0 开始文件后缀.xml每张图一个 xml.txt每张图一个 txt内容为纯文本行是否能直接读需要 XML 解析直接按空格 split 即可适合训练框架Faster R-CNN、SSD、MMDetectionYOLO 系、也能转 COCO转换公式就这么一行cx (xmin xmax) / 2 / widthcy (ymin ymax) / 2 / heightw (xmax - xmin) / widthh (ymax - ymin) / height。反过来从 YOLO 转回 VOC 就是把分母乘回去。2.2 5 类缺陷的定义与类别分布先数清楚再谈训练集装箱缺陷检测里常见的 5 类一般覆盖表面裂纹、涂层破损与锈蚀、凹陷、形变以及焊缝或结构件损伤这几个方向具体到这份数据集里是哪五类解压后打开标签目录一眼就能确认。我拿到任何数据集的第一操作永远是写一个统计脚本把类别分布和每类的样本数打出来而不是急急忙忙开训。1476 张图听着不少但摊到 5 类上平均每类不到 300 张如果有一类只有几十个框后面的训练策略就要跟着调整——比如少样本类别单独做数据增强或者对损失函数里各类别的权重动手。from pathlib import Path from collections import Counter import xml.etree.ElementTree as ET # 假设 VOC 标注在 Annotations 目录图片在 JPEGImages 目录 voc_dir Path(Annotations) class_counter Counter() per_class_bbox Counter() for xml_file in voc_dir.glob(*.xml): tree ET.parse(xml_file) root tree.getroot() seen set() for obj in root.iter(object): name obj.findtext(name) class_counter[name] 1 # 每张图里同一个类别只计数一次避免框数虚高 if name not in seen: per_class_bbox[name] 1 seen.add(name) print(类别 - 出现该类的图片数) for name, cnt in per_class_bbox.most_common(): print(f{name:20s} {cnt:4d}) print(类别 - 标注框总数) for name, cnt in class_counter.most_common(): print(f{name:20s} {cnt:4d})这段脚本干的事是把每个类出现在多少张图里、总共有多少个框分别统计出来。为什么要区分这两个数因为一个类可能在 200 张图里出现但每张图有 10 个框另一个类在 150 张图里出现但每张图只有 1 个框两者对训练的难度影响完全不同——前者模型能在一个图里多次学习后者场景少容易过拟合。如果一个类别的图片数低于 100后续训练时就得准备针对性处理了。2.3 文件名对应关系双格式最容易翻车的暗坑VOC 和 YOLO 两套格式同时存在时最隐蔽的问题是文件名不匹配。常见的有三种情况一种是 XML 文件名和 JPG 文件名完全一致但后缀不同这种最省心另一种是 YOLO 的 txt 文件名与图片名一致但 XML 文件名带额外前缀或后缀还有一种是 ImageSets/Main 里的 train.txt、val.txt 列出的文件名和实际文件对不上。这三类情况都会在训练时表现为No labels found in ...或者图片全部被跳过。我的处理习惯是拿到数据集先把所有文件名拉出来对比一遍按 stem不含后缀的主文件名做交集。理论上 VOC 的 Annotations、JPEGImages 和 YOLO 的 labels、images 四个目录的 stem 集合应当完全一致不一致的就是脏数据直接踢掉或单独挪到一个目录里等后续处理。from pathlib import Path img_dir Path(JPEGImages) ann_dir Path(Annotations) yolo_img_dir Path(images) yolo_label_dir Path(labels) def stem_set(path): return {p.stem for p in path.glob(*) if p.suffix.lower() in {.jpg, .jpeg, .png, .xml, .txt}} img_stems stem_set(img_dir) ann_stems stem_set(ann_dir) yimg_stems stem_set(yolo_img_dir) ylab_stems stem_set(yolo_label_dir) # 只保留四个目录全匹配的文件名 valid img_stems ann_stems yimg_stems ylab_stems lost_in_voc ann_stems - img_stems lost_in_yolo ylab_stems - yimg_stems print(f有效样本数: {len(valid)}) print(fVOC 中有标注但无图片: {len(lost_in_voc)}) print(fYOLO 中有标签但无图片: {len(lost_in_yolo)})这段脚本做的是四目录交集校验。lost_in_voc 如果大于 0说明 Annotations 里存在没有对应图片的孤儿 XML这类文件在训练时会让数据加载器报错或跳过必须清理lost_in_yolo 同理。1476 张图的数据集如果这里差了十几张训练的 valid 集指标就会忽高忽低看起来像是模型不稳定其实是数据名没对齐。3. 把双格式数据送进训练管线环境配置、标签校验与划分策略3.1 用一个校验脚本把 YOLO 标签里的坐标脏数据揪出来YOLO 格式的 txt 文件是纯文本每行class_id cx cy w h看着简单但标注工具导出的数据经常有边界问题坐标归一化后出现负值、宽高算出来大于 1、或者框的面积小到只有几个像素。这些问题不会让训练直接报错但会让损失函数在早期震荡得很厉害甚至让个别类别的 AP 永远为 0。目标检测模型对标签质量非常敏感进去的是垃圾出来的就是看似收敛但检测结果一塌糊涂的模型。from pathlib import Path import numpy as np label_dir Path(labels) img_dir Path(images) issues [] for txt_file in label_dir.glob(*.txt): img_file img_dir / (txt_file.stem .jpg) if not img_file.exists(): img_file img_dir / (txt_file.stem .png) # 读图拿真实尺寸用于反算像素面积 from PIL import Image w, h Image.open(img_file).size lines txt_file.read_text().strip().splitlines() if not lines: issues.append((txt_file.name, 空标签文件)) continue for i, line in enumerate(lines): parts line.split() if len(parts) ! 5: issues.append((txt_file.name, f第{i}行字段数不对)) continue _, cx, cy, bw, bh map(float, parts) # 归一化坐标必须在 0~1 之间且宽高不能为负数 if cx 0 or cy 0 or bw 0 or bh 0: issues.append((txt_file.name, f第{i}行坐标越界/非正)) continue if cx bw / 2 1.05 or cy bh / 2 1.05 or cx - bw / 2 -0.05 or cy - bh / 2 -0.05: issues.append((txt_file.name, f第{i}行边界框超出图片范围)) continue # 反算像素面积小于 16 像素的框基本是误标或无效框 px_area bw * w * bh * h if px_area 16: issues.append((txt_file.name, f第{i}行面积过小: {px_area:.0f}px)) print(f共检查 {len(list(label_dir.glob(*.txt)))} 个标签文件) for name, reason in issues[:50]: print(f{name}: {reason})常见做法是预留 0.05 的容差而不是严格按 0~1 卡边界因为标注工具偶尔会把紧贴图片边缘的框多画出去一个像素归一化后变成 1.001 这种值训练时 OpenCV 读取坐标会直接 clip问题不大但超过 0.05 就是真越界说明标签和图片对不上这种样本建议直接删掉。另有一个含金量很高的点是校验后的文件用np.clip把坐标修正到合法区间再写回去而不是删样本——1476 张的数据集删不起修比删划算。3.2 训练集、验证集划分不要随机打乱按集装箱状态分层数据集划分是另一个看起来简单但实际影响很大的环节。随手train_test_split一把梭的做法在这类工业缺陷数据集上特别容易翻车因为同一批集装箱的连续拍摄帧之间高度相似随机划分会把很像的图同时分进训练集和验证集导致验证 mAP 虚高部署到现场立刻被打回原形。对集装箱缺陷检测来说更稳妥的做法是按集装箱个体分层划分——如果你能从文件名或目录看出哪些图来自同一个箱体就把同一个箱体的图全部放进同一个集合。import random from pathlib import Path img_dir Path(images) random.seed(42) # 假设文件名格式为 container_XX_view_YY.jpgXX 是箱体编号 containers {} for f in img_dir.glob(*.jpg): cid f.stem.split(_)[1] containers.setdefault(cid, []).append(f.stem) # 按箱体为粒度划分 8:1:1 stems list(containers.keys()) random.shuffle(stems) n len(stems) train_cids set(stems[:int(n * 0.8)]) val_cids set(stems[int(n * 0.8):int(n * 0.9)]) test_cids set(stems[int(n * 0.9):]) def write_split(cids, outfile): files [] for cid in cids: files.extend(containers[cid]) Path(outfile).write_text(\n.join(files) \n) write_split(train_cids, train_split.txt) write_split(val_cids, val_split.txt) write_split(test_cids, test_split.txt) print(ftrain: {len(train_cids)} 个箱体, val: {len(val_cids)}, test: {len(test_cids)})按箱体划分的本质是切断数据泄漏路径。如果同一箱体的前 10 帧在训练集、后 10 帧在验证集模型其实是在背这个箱体的特征而不是学习缺陷的通用模式验证分数会漂亮很多但换个箱体就完全失灵。这是工业视觉里最常见的过拟合形态之一比参数过拟合更难发现因为训练曲线一切正常。划分完之后还需要给 YOLO 训练准备数据集配置。这个配置文件的作用是告诉模型到哪里找图、标签在哪、类别有几个、类名是什么# dataset.yaml path: /data/container_defect train: train_split.txt val: val_split.txt nc: 5 names: [crack, rust, dent, deform, weld_defect]3.3 跑通最小训练命令从数据到权重文件的一站式流程环境和依赖齐了之后训练命令本身并不复杂。以 YOLOv8 为例最小可运行命令是这样yolo taskdetect modetrain \ modelyolov8m.pt \ datacontainer_defect.yaml \ epochs100 \ imgsz640 \ batch16 \ lr00.01 \ patience15 \ projectruns/container_defect \ nameexp1逐项拆解参数含义modelyolov8m.pt是预训练权重用小模型 s 或 n 起步更快用 m 起步精度上限更高1476 张的小数据集不建议直接上 l 或 x容易过拟合imgsz640是输入分辨率集装箱缺陷大多是表面裂纹或锈蚀这类细节分辨率调大到 960m 有时有奇效但 VRAM 占用会明显上升lr00.01是初始学习率在预训练权重上继续训练时 0.01 是相对保守的值patience15表示验证集指标连续 15 轮不提升就早停这是一个防止在无效训练上浪费时间的保险丝。训练跑完之后产物在runs/container_defect/exp1/目录下weights/best.pt就是验证集上表现最好的权重做推理用这个文件而不是last.pt。我见过不少把last.pt拿去部署的翻车案例因为 last 是最后一轮的权重不一定是分数最高的。from ultralytics import YOLO model YOLO(runs/container_defect/exp1/weights/best.pt) results model.predict(test_images/container_001_view_03.jpg, conf0.25, imgsz640) boxes results[0].boxes for b in boxes: cls_id int(b.cls[0]) conf float(b.conf[0]) xyxy b.xyxy[0].tolist() print(f类别 {model.names[cls_id]:12s} 置信度 {conf:.2f} 坐标 {xyxy})推理时的conf参数是置信度阈值工业场景下建议比默认值高一些设在 0.3 到 0.4 之间因为港口现场误报一次就要派人去复核成本比漏检低这句话只适用于部分场景在集装箱缺陷检测里漏检缺陷箱子放进码头和误报好箱子被拉去做二次检验的代价需要按实际流程权衡。.xyxy拿到的是左上右下像素坐标如果下游系统需要的是 VOC 或 YOLO 格式再按第 2 节的公式反向转一次即可。4. 双格式数据集的避坑记录五条血泪经验4.1 VOC 类名顺序和 YOLO class_id 对不上现象训练能跑但 loss 降到一定程度就不再下降验证集的 PR 曲线里某些类别 AP 接近 0预测框位置正确但类别全是错的。原因VOC 的 XML 里类别是字符串YOLO txt 里类别是整数索引这个索引必须和类名字典一一对应。数据集作者导出的 class_id 顺序和你写进dataset.yaml的 names 顺序不一致模型学到的类别语义就完全错位了。这是双格式数据集最典型也最隐蔽的陷阱。解决训练前用脚本把 YOLO txt 里的每个 class_id 取出来去 XML 里找同名文件的类别名反推出 id 到类名的映射再和你配置里的 names 对比不一致就重写 txt 或改配置。这个检查做一次两分钟不做可能浪费几天。4.2 XML 和 txt 坐标系弄混导致验证集指标虚高现象用 VOC 格式做验证时 mAP 有 0.85切到 YOLO 格式同一个模型只剩 0.6两个数字差异巨大。原因VOC 的坐标是左上右下xmin, ymin, xmax, ymaxYOLO 是中心点cx_center (xmin xmax) / 2如果转换脚本把 YOLO 的 cx 直接当成 VOC 的 xmin 用框的位置就偏了半个身位。某些框架内部做了坐标换算所以这种错误不报错只是指标全面失真。解决写个可视化校验脚本把检测框直接画在图上人工抽检。抽 20 张图框的位置和集装箱缺陷位置对得上再继续。坐标问题肉眼秒发现比任何数据指标都可靠。4.3 1476 张图里有空标签文件训练时静默跳过现象训练日志里显示每轮处理的图片数比数据集总数少或者某个类别的 AP 波动很大时有时无。原因YOLO 系列框架的数据加载器对空标签文件默认跳过不报错。如果这份数据集里某些图没有任何缺陷——这其实是正常情况负样本在工业检测里很常见——它们对应的 txt 就是空文件这类样本在验证时没有 ground truth但训练时被静默排除。问题出在如果你把空标签文件也算进总数做划分分布就被打乱了。解决数据划分前统计空 txt 的数量和位置确认它们是负样本还是标注遗漏。负样本可以保留但要么单独分成一类要么在验证集里固定比例标注遗漏的直接从严删掉。4.4 小目标缺陷在降采样后直接消失现象训练时 loss 正常下降但推理时小裂纹一个都检测不出来大凹陷全部命中。原因集装箱表面裂纹这类缺陷在原始图上可能只有 20×20 像素YOLO 训练时会把图缩放到 640×640如果原图是 1920×1080缩放后这个裂纹只剩不到 7×7 像素已经低于特征图上的有效响应范围。解决两个方向一是把imgsz提到 960 或 1280 训练让小目标保留更多像素二是用 YOLO 的safer思路做切图推理把 1920 宽的图切成四块 640 分别推理再合并结果。显存能撑住的话前者最简单省事。4.5 类别严重不均衡且没有任何处理现象占样本量 40% 的类别 AP 有 0.9占 5% 的类别 AP 只有 0.1整体 mAP 看着还行但实际项目需要的是那个弱类别。原因目标检测模型对类别分布极其敏感占比较低的类在每轮训练中只有少量正样本参与计算梯度容易被模型当作背景忽略。1476 张的规模太少不做处理这种现象必然出现。解决先加数据增强——对少样本类别的样本做 Mosaic、随机旋转、亮度抖动都是有效手段再用损失函数层面的手段给cls_loss配一个按类别频率倒数计算的权重向量。这两招都做了以后弱类别 AP 通常能提升 10 到 15 个点。5. 验证指标与集装箱场景的三个进阶技巧当模型训练完毕真正的工作才开始。第一件事是别只看 mAP0.5这个指标对集装箱缺陷检测来说太宽容了——缺陷检测对定位精度有实际要求下游机械臂或人工复核需要知道缺陷具体在哪个位置。官方验证代码会自动输出 mAP0.5 和 mAP0.5:0.95 两组值后者对框的定位要求更严格我建议把 0.5:0.95 的结果作为模型选型的核心指标。如果这部分偏低优先调imgsz和conf_thres这两个参数对定位精度的影响比换更大规模的模型更直接——前提是你的显存允许。第二个技巧是把预测框的宽高比作为后置过滤器。集装箱是刚体表面缺陷的几何特征相对稳定裂纹类缺陷的长宽比通常在 3:1 以上凹陷类更接近正方形锈蚀类则可能是大面积的片状区域。训练完成后统计一次各类别预测框的宽高比分布超出合理区间的预测结果大概率是误检可以直接用规则过滤掉。这个做法不需要重训模型在推理代码加几行判断就行但对降低现场误报率非常有效。第三个技巧是用热力图检查模型的关注区域。集装箱表面有规律的纹理比如瓦楞波纹模型有时会把纹理误认作裂纹缺陷——这种特征根本不是靠调参能解决的属于数据层面的问题需要在训练集里补充大量负样本让模型学会区分。跑一次验证集的热力图如果发现模型大量关注集装箱边缘和纹理高光区域就要警惕了。这些技巧都是让人少走弯路的经验积累。我做这类工业缺陷检测项目最多的感悟是数据集的格式正确性比模型大小更重要label 里的一个坐标错误比十个超参没调好都影响大。拿到新数据集先花一天做校验和清洗后面所有环节都会顺畅得多。希望这几点对你有帮助。本文还有配套的精品资源点击获取 集装箱缺陷检测数据集双格式处理与YOLO训练实战指南
简介面向计算机视觉目标检测任务的集装箱缺陷检测数据集包含1476张集装箱表面缺陷图片涵盖Deframe变形、Dent凹坑、Hole孔洞、Rusty锈蚀、Scratch划痕五类常见缺陷共4227个标注框。数据同时提供Pascal VOC和YOLO两种格式的标注文件可直接用于训练Faster R-CNN、YOLO系列等检测模型适合工业质检、港口运维等场景的算法研发与教学实验。压缩包共2000个文件以jpg图片配合xml与txt标注为主其中xml为VOC格式、txt为YOLO格式标签文件与图片一一对应另含说明文档整体约163.76MB。该数据集已吸引494人关注下载标注规范、类别分布清晰便于研究者快速开展缺陷检测模型训练与评估也可作为毕业设计或企业项目的数据基础。1. 集装箱缺陷检测为什么拿到数据集的第一天都在处理格式做过工业质检的人都有这种体会模型选型、训练参数都不是最耗时的真正磨人的是数据本身。一份标注好的集装箱缺陷检测数据集跑到手里是 1476 张、5 类缺陷、带 VOC 和 YOLO 两种格式听起来省事实际上第一周的工作基本都耗在格式转换、标签校验和类别平衡这三件事上。这份数据集能解决的是集装箱外表面缺陷检测的起步问题适合正在做港口、物流园或钢厂表面质检方案的人也适合想用目标检测练手但找不到工业场景数据的学习者。它的价值不在 1476 这个数字而在标注格式是否干净、类别定义是否一致、坐标有没有越界——这些才是直接决定训练能不能跑通、mAP 能不能看的因素。2. 这 1476 张图里到底有什么VOC 与 YOLO 双格式的构成拆解2.1 用 VOC 还是用 YOLO两种格式的坐标系统与适用场景拿到压缩包第一件事不是解压看图片而是先看清目录结构。这类集装箱缺陷检测数据集常见做法是把同一批图片同时导出成 VOC 和 YOLO 两套标注VOC 用 XML 存边界框YOLO 用 TXT 存归一化坐标。两套格式各有各的适用场景VOC 适合用 Faster R-CNN、SSD 这类框架或者你需要在 LabelImg 里人工复核标注YOLO 格式则直接喂给 YOLOv5、YOLOv8 这类模型训练时不需要中间转换。两种格式最关键的区别是坐标表达方式做格式衔接之前必须先把这个映射关系刻在脑子里对比项VOC XMLYOLO TXT坐标形式左上角 xmin、ymin 与右下角 xmax、ymax像素绝对值中心点 cx、cy 与宽 w、高 h均除以图宽图高做了归一化类别表达字符串如namedent/name整数索引 class_id从 0 开始文件后缀.xml每张图一个 xml.txt每张图一个 txt内容为纯文本行是否能直接读需要 XML 解析直接按空格 split 即可适合训练框架Faster R-CNN、SSD、MMDetectionYOLO 系、也能转 COCO转换公式就这么一行cx (xmin xmax) / 2 / widthcy (ymin ymax) / 2 / heightw (xmax - xmin) / widthh (ymax - ymin) / height。反过来从 YOLO 转回 VOC 就是把分母乘回去。2.2 5 类缺陷的定义与类别分布先数清楚再谈训练集装箱缺陷检测里常见的 5 类一般覆盖表面裂纹、涂层破损与锈蚀、凹陷、形变以及焊缝或结构件损伤这几个方向具体到这份数据集里是哪五类解压后打开标签目录一眼就能确认。我拿到任何数据集的第一操作永远是写一个统计脚本把类别分布和每类的样本数打出来而不是急急忙忙开训。1476 张图听着不少但摊到 5 类上平均每类不到 300 张如果有一类只有几十个框后面的训练策略就要跟着调整——比如少样本类别单独做数据增强或者对损失函数里各类别的权重动手。from pathlib import Path from collections import Counter import xml.etree.ElementTree as ET # 假设 VOC 标注在 Annotations 目录图片在 JPEGImages 目录 voc_dir Path(Annotations) class_counter Counter() per_class_bbox Counter() for xml_file in voc_dir.glob(*.xml): tree ET.parse(xml_file) root tree.getroot() seen set() for obj in root.iter(object): name obj.findtext(name) class_counter[name] 1 # 每张图里同一个类别只计数一次避免框数虚高 if name not in seen: per_class_bbox[name] 1 seen.add(name) print(类别 - 出现该类的图片数) for name, cnt in per_class_bbox.most_common(): print(f{name:20s} {cnt:4d}) print(类别 - 标注框总数) for name, cnt in class_counter.most_common(): print(f{name:20s} {cnt:4d})这段脚本干的事是把每个类出现在多少张图里、总共有多少个框分别统计出来。为什么要区分这两个数因为一个类可能在 200 张图里出现但每张图有 10 个框另一个类在 150 张图里出现但每张图只有 1 个框两者对训练的难度影响完全不同——前者模型能在一个图里多次学习后者场景少容易过拟合。如果一个类别的图片数低于 100后续训练时就得准备针对性处理了。2.3 文件名对应关系双格式最容易翻车的暗坑VOC 和 YOLO 两套格式同时存在时最隐蔽的问题是文件名不匹配。常见的有三种情况一种是 XML 文件名和 JPG 文件名完全一致但后缀不同这种最省心另一种是 YOLO 的 txt 文件名与图片名一致但 XML 文件名带额外前缀或后缀还有一种是 ImageSets/Main 里的 train.txt、val.txt 列出的文件名和实际文件对不上。这三类情况都会在训练时表现为No labels found in ...或者图片全部被跳过。我的处理习惯是拿到数据集先把所有文件名拉出来对比一遍按 stem不含后缀的主文件名做交集。理论上 VOC 的 Annotations、JPEGImages 和 YOLO 的 labels、images 四个目录的 stem 集合应当完全一致不一致的就是脏数据直接踢掉或单独挪到一个目录里等后续处理。from pathlib import Path img_dir Path(JPEGImages) ann_dir Path(Annotations) yolo_img_dir Path(images) yolo_label_dir Path(labels) def stem_set(path): return {p.stem for p in path.glob(*) if p.suffix.lower() in {.jpg, .jpeg, .png, .xml, .txt}} img_stems stem_set(img_dir) ann_stems stem_set(ann_dir) yimg_stems stem_set(yolo_img_dir) ylab_stems stem_set(yolo_label_dir) # 只保留四个目录全匹配的文件名 valid img_stems ann_stems yimg_stems ylab_stems lost_in_voc ann_stems - img_stems lost_in_yolo ylab_stems - yimg_stems print(f有效样本数: {len(valid)}) print(fVOC 中有标注但无图片: {len(lost_in_voc)}) print(fYOLO 中有标签但无图片: {len(lost_in_yolo)})这段脚本做的是四目录交集校验。lost_in_voc 如果大于 0说明 Annotations 里存在没有对应图片的孤儿 XML这类文件在训练时会让数据加载器报错或跳过必须清理lost_in_yolo 同理。1476 张图的数据集如果这里差了十几张训练的 valid 集指标就会忽高忽低看起来像是模型不稳定其实是数据名没对齐。3. 把双格式数据送进训练管线环境配置、标签校验与划分策略3.1 用一个校验脚本把 YOLO 标签里的坐标脏数据揪出来YOLO 格式的 txt 文件是纯文本每行class_id cx cy w h看着简单但标注工具导出的数据经常有边界问题坐标归一化后出现负值、宽高算出来大于 1、或者框的面积小到只有几个像素。这些问题不会让训练直接报错但会让损失函数在早期震荡得很厉害甚至让个别类别的 AP 永远为 0。目标检测模型对标签质量非常敏感进去的是垃圾出来的就是看似收敛但检测结果一塌糊涂的模型。from pathlib import Path import numpy as np label_dir Path(labels) img_dir Path(images) issues [] for txt_file in label_dir.glob(*.txt): img_file img_dir / (txt_file.stem .jpg) if not img_file.exists(): img_file img_dir / (txt_file.stem .png) # 读图拿真实尺寸用于反算像素面积 from PIL import Image w, h Image.open(img_file).size lines txt_file.read_text().strip().splitlines() if not lines: issues.append((txt_file.name, 空标签文件)) continue for i, line in enumerate(lines): parts line.split() if len(parts) ! 5: issues.append((txt_file.name, f第{i}行字段数不对)) continue _, cx, cy, bw, bh map(float, parts) # 归一化坐标必须在 0~1 之间且宽高不能为负数 if cx 0 or cy 0 or bw 0 or bh 0: issues.append((txt_file.name, f第{i}行坐标越界/非正)) continue if cx bw / 2 1.05 or cy bh / 2 1.05 or cx - bw / 2 -0.05 or cy - bh / 2 -0.05: issues.append((txt_file.name, f第{i}行边界框超出图片范围)) continue # 反算像素面积小于 16 像素的框基本是误标或无效框 px_area bw * w * bh * h if px_area 16: issues.append((txt_file.name, f第{i}行面积过小: {px_area:.0f}px)) print(f共检查 {len(list(label_dir.glob(*.txt)))} 个标签文件) for name, reason in issues[:50]: print(f{name}: {reason})常见做法是预留 0.05 的容差而不是严格按 0~1 卡边界因为标注工具偶尔会把紧贴图片边缘的框多画出去一个像素归一化后变成 1.001 这种值训练时 OpenCV 读取坐标会直接 clip问题不大但超过 0.05 就是真越界说明标签和图片对不上这种样本建议直接删掉。另有一个含金量很高的点是校验后的文件用np.clip把坐标修正到合法区间再写回去而不是删样本——1476 张的数据集删不起修比删划算。3.2 训练集、验证集划分不要随机打乱按集装箱状态分层数据集划分是另一个看起来简单但实际影响很大的环节。随手train_test_split一把梭的做法在这类工业缺陷数据集上特别容易翻车因为同一批集装箱的连续拍摄帧之间高度相似随机划分会把很像的图同时分进训练集和验证集导致验证 mAP 虚高部署到现场立刻被打回原形。对集装箱缺陷检测来说更稳妥的做法是按集装箱个体分层划分——如果你能从文件名或目录看出哪些图来自同一个箱体就把同一个箱体的图全部放进同一个集合。import random from pathlib import Path img_dir Path(images) random.seed(42) # 假设文件名格式为 container_XX_view_YY.jpgXX 是箱体编号 containers {} for f in img_dir.glob(*.jpg): cid f.stem.split(_)[1] containers.setdefault(cid, []).append(f.stem) # 按箱体为粒度划分 8:1:1 stems list(containers.keys()) random.shuffle(stems) n len(stems) train_cids set(stems[:int(n * 0.8)]) val_cids set(stems[int(n * 0.8):int(n * 0.9)]) test_cids set(stems[int(n * 0.9):]) def write_split(cids, outfile): files [] for cid in cids: files.extend(containers[cid]) Path(outfile).write_text(\n.join(files) \n) write_split(train_cids, train_split.txt) write_split(val_cids, val_split.txt) write_split(test_cids, test_split.txt) print(ftrain: {len(train_cids)} 个箱体, val: {len(val_cids)}, test: {len(test_cids)})按箱体划分的本质是切断数据泄漏路径。如果同一箱体的前 10 帧在训练集、后 10 帧在验证集模型其实是在背这个箱体的特征而不是学习缺陷的通用模式验证分数会漂亮很多但换个箱体就完全失灵。这是工业视觉里最常见的过拟合形态之一比参数过拟合更难发现因为训练曲线一切正常。划分完之后还需要给 YOLO 训练准备数据集配置。这个配置文件的作用是告诉模型到哪里找图、标签在哪、类别有几个、类名是什么# dataset.yaml path: /data/container_defect train: train_split.txt val: val_split.txt nc: 5 names: [crack, rust, dent, deform, weld_defect]3.3 跑通最小训练命令从数据到权重文件的一站式流程环境和依赖齐了之后训练命令本身并不复杂。以 YOLOv8 为例最小可运行命令是这样yolo taskdetect modetrain \ modelyolov8m.pt \ datacontainer_defect.yaml \ epochs100 \ imgsz640 \ batch16 \ lr00.01 \ patience15 \ projectruns/container_defect \ nameexp1逐项拆解参数含义modelyolov8m.pt是预训练权重用小模型 s 或 n 起步更快用 m 起步精度上限更高1476 张的小数据集不建议直接上 l 或 x容易过拟合imgsz640是输入分辨率集装箱缺陷大多是表面裂纹或锈蚀这类细节分辨率调大到 960m 有时有奇效但 VRAM 占用会明显上升lr00.01是初始学习率在预训练权重上继续训练时 0.01 是相对保守的值patience15表示验证集指标连续 15 轮不提升就早停这是一个防止在无效训练上浪费时间的保险丝。训练跑完之后产物在runs/container_defect/exp1/目录下weights/best.pt就是验证集上表现最好的权重做推理用这个文件而不是last.pt。我见过不少把last.pt拿去部署的翻车案例因为 last 是最后一轮的权重不一定是分数最高的。from ultralytics import YOLO model YOLO(runs/container_defect/exp1/weights/best.pt) results model.predict(test_images/container_001_view_03.jpg, conf0.25, imgsz640) boxes results[0].boxes for b in boxes: cls_id int(b.cls[0]) conf float(b.conf[0]) xyxy b.xyxy[0].tolist() print(f类别 {model.names[cls_id]:12s} 置信度 {conf:.2f} 坐标 {xyxy})推理时的conf参数是置信度阈值工业场景下建议比默认值高一些设在 0.3 到 0.4 之间因为港口现场误报一次就要派人去复核成本比漏检低这句话只适用于部分场景在集装箱缺陷检测里漏检缺陷箱子放进码头和误报好箱子被拉去做二次检验的代价需要按实际流程权衡。.xyxy拿到的是左上右下像素坐标如果下游系统需要的是 VOC 或 YOLO 格式再按第 2 节的公式反向转一次即可。4. 双格式数据集的避坑记录五条血泪经验4.1 VOC 类名顺序和 YOLO class_id 对不上现象训练能跑但 loss 降到一定程度就不再下降验证集的 PR 曲线里某些类别 AP 接近 0预测框位置正确但类别全是错的。原因VOC 的 XML 里类别是字符串YOLO txt 里类别是整数索引这个索引必须和类名字典一一对应。数据集作者导出的 class_id 顺序和你写进dataset.yaml的 names 顺序不一致模型学到的类别语义就完全错位了。这是双格式数据集最典型也最隐蔽的陷阱。解决训练前用脚本把 YOLO txt 里的每个 class_id 取出来去 XML 里找同名文件的类别名反推出 id 到类名的映射再和你配置里的 names 对比不一致就重写 txt 或改配置。这个检查做一次两分钟不做可能浪费几天。4.2 XML 和 txt 坐标系弄混导致验证集指标虚高现象用 VOC 格式做验证时 mAP 有 0.85切到 YOLO 格式同一个模型只剩 0.6两个数字差异巨大。原因VOC 的坐标是左上右下xmin, ymin, xmax, ymaxYOLO 是中心点cx_center (xmin xmax) / 2如果转换脚本把 YOLO 的 cx 直接当成 VOC 的 xmin 用框的位置就偏了半个身位。某些框架内部做了坐标换算所以这种错误不报错只是指标全面失真。解决写个可视化校验脚本把检测框直接画在图上人工抽检。抽 20 张图框的位置和集装箱缺陷位置对得上再继续。坐标问题肉眼秒发现比任何数据指标都可靠。4.3 1476 张图里有空标签文件训练时静默跳过现象训练日志里显示每轮处理的图片数比数据集总数少或者某个类别的 AP 波动很大时有时无。原因YOLO 系列框架的数据加载器对空标签文件默认跳过不报错。如果这份数据集里某些图没有任何缺陷——这其实是正常情况负样本在工业检测里很常见——它们对应的 txt 就是空文件这类样本在验证时没有 ground truth但训练时被静默排除。问题出在如果你把空标签文件也算进总数做划分分布就被打乱了。解决数据划分前统计空 txt 的数量和位置确认它们是负样本还是标注遗漏。负样本可以保留但要么单独分成一类要么在验证集里固定比例标注遗漏的直接从严删掉。4.4 小目标缺陷在降采样后直接消失现象训练时 loss 正常下降但推理时小裂纹一个都检测不出来大凹陷全部命中。原因集装箱表面裂纹这类缺陷在原始图上可能只有 20×20 像素YOLO 训练时会把图缩放到 640×640如果原图是 1920×1080缩放后这个裂纹只剩不到 7×7 像素已经低于特征图上的有效响应范围。解决两个方向一是把imgsz提到 960 或 1280 训练让小目标保留更多像素二是用 YOLO 的safer思路做切图推理把 1920 宽的图切成四块 640 分别推理再合并结果。显存能撑住的话前者最简单省事。4.5 类别严重不均衡且没有任何处理现象占样本量 40% 的类别 AP 有 0.9占 5% 的类别 AP 只有 0.1整体 mAP 看着还行但实际项目需要的是那个弱类别。原因目标检测模型对类别分布极其敏感占比较低的类在每轮训练中只有少量正样本参与计算梯度容易被模型当作背景忽略。1476 张的规模太少不做处理这种现象必然出现。解决先加数据增强——对少样本类别的样本做 Mosaic、随机旋转、亮度抖动都是有效手段再用损失函数层面的手段给cls_loss配一个按类别频率倒数计算的权重向量。这两招都做了以后弱类别 AP 通常能提升 10 到 15 个点。5. 验证指标与集装箱场景的三个进阶技巧当模型训练完毕真正的工作才开始。第一件事是别只看 mAP0.5这个指标对集装箱缺陷检测来说太宽容了——缺陷检测对定位精度有实际要求下游机械臂或人工复核需要知道缺陷具体在哪个位置。官方验证代码会自动输出 mAP0.5 和 mAP0.5:0.95 两组值后者对框的定位要求更严格我建议把 0.5:0.95 的结果作为模型选型的核心指标。如果这部分偏低优先调imgsz和conf_thres这两个参数对定位精度的影响比换更大规模的模型更直接——前提是你的显存允许。第二个技巧是把预测框的宽高比作为后置过滤器。集装箱是刚体表面缺陷的几何特征相对稳定裂纹类缺陷的长宽比通常在 3:1 以上凹陷类更接近正方形锈蚀类则可能是大面积的片状区域。训练完成后统计一次各类别预测框的宽高比分布超出合理区间的预测结果大概率是误检可以直接用规则过滤掉。这个做法不需要重训模型在推理代码加几行判断就行但对降低现场误报率非常有效。第三个技巧是用热力图检查模型的关注区域。集装箱表面有规律的纹理比如瓦楞波纹模型有时会把纹理误认作裂纹缺陷——这种特征根本不是靠调参能解决的属于数据层面的问题需要在训练集里补充大量负样本让模型学会区分。跑一次验证集的热力图如果发现模型大量关注集装箱边缘和纹理高光区域就要警惕了。这些技巧都是让人少走弯路的经验积累。我做这类工业缺陷检测项目最多的感悟是数据集的格式正确性比模型大小更重要label 里的一个坐标错误比十个超参没调好都影响大。拿到新数据集先花一天做校验和清洗后面所有环节都会顺畅得多。希望这几点对你有帮助。本文还有配套的精品资源点击获取