简介这是一份面向YOLO系列目标检测学习者的工程机械数据集聚焦自卸卡车、挖掘机与轮式装载机三类目标适合需要快速搭建训练与验证流程的开发者、学生及算法工程师使用。压缩包共2000个文件以xml标注文件为主同时提供YOLO格式txt与VOC格式xml两套标签分别存放于独立文件夹文件名末尾标注对应类别名称便于按类别检索与核对。数据集已预先划分训练与验证集并附带data.yaml配置文件可直接适配YOLOv5、YOLOv8、YOLOv9、YOLOv7、YOLOv10及YOLO11等主流版本省去格式转换与目录整理成本。YOLO标签采用归一化中心点与宽高比例符合标准训练输入要求。资源包整体约232.47MB已有80人学习下载。对于想练习工程机械检测、验证模型迁移效果或补充自定义数据集的读者这份带标签数据能直接投入训练与测试帮助快速完成从数据到模型的闭环验证。1. 挖掘机数据集落地2656 张带标签图像能直接喂给 YOLO 吗工地上想做一个挖掘机、自卸卡车、轮式装载机的识别模型最卡脖子的往往不是网络结构而是手里没有一批标好的图。这份资源给的就是 2656 张工程机械图像每张都配了标签而且同时给了 YOLO 格式的 txt 和 VOC 格式的 xml 两套标注还附了划分好的数据集配置 data.yaml。换句话说它把「找图—打标—划分—写配置」这条最耗人力的链路直接跳过了拿到手就能接上 yolov5、yolov8、yolov9、yolov7、yolov10、yolo11 这一串 yolo 系列算法开训。适合两类人一类是想快速验证工程机械检测可行性、不想从零打标的算法同学另一类是要做工地安全监控、土方量统计、设备调度需要先跑通一个 baseline 的工程侧开发者。下面我按「这份资源到底长什么样 → 怎么接进训练 → 哪里容易翻车」的顺序拆一遍。2. 数据集结构与标签格式先看清 2656 张图是怎么组织的2.1 目录布局与两个标签文件夹这类工程机械数据集常见的组织方式是把图像放一个目录标签按格式分开放两个目录。从项目正文里那批img_0256_1178.xml、img_0256_143.xml这样的文件名能看出图像和标注是同一套主名靠扩展名区分。典型结构大致是这样excavator_dataset/ ├── images/ # 2656 张图像jpg/png │ ├── img_0256_1178.jpg │ ├── img_0256_143.jpg │ └── ... ├── labels_yolo/ # YOLO 格式txt │ ├── img_0256_1178.txt │ └── ... ├── labels_voc/ # VOC 格式xml │ ├── img_0256_1178.xml │ └── ... └── data.yaml # 数据集配置文件这里有个细节值得注意摘要里说「文件名末尾是部分类别名称」意思是有些标注文件名会带上类别后缀比如xxx_excavator.txt。这种命名在多人协作打标时很常见好处是一眼能看出这张图主标了什么坏处是如果你写脚本按「主名严格相等」去匹配图像和标签就会匹配失败。我一般会先把主名抽出来做一次对齐检查确认图像和标签数量一致再往下走。2.2 YOLO 格式的五个字段到底怎么读YOLO 的 txt 标注每行是一个目标格式是class x_center y_center width height。前一个是类别索引从 0 开始后面四个都是归一化到 0 到 1 的比例值不是像素。这一点是新手最容易搞混的地方——x_center和y_center是框中心点相对整张图宽高的比例width和height是框宽高相对整张图宽高的比例。举个具体例子一张 1920×1080 的图里有个框左上角 (480, 270)、右下角 (960, 540)那么中心点像素 ((480960)/2, (270540)/2) (720, 405)归一化中心 (720/1920, 405/1080) (0.375, 0.375)框宽高像素 (480, 270)归一化 (480/1920, 270/1080) (0.25, 0.25)所以这一行就是0 0.375 0.375 0.25 0.25。理解了这个换算后面无论你是要可视化检查标注还是要把 VOC 转 YOLO都不会绕晕。2.3 VOC 格式与 YOLO 格式的取舍VOC 的 xml 存的是绝对像素坐标bndbox里是xmin/ymin/xmax/ymax可读性好用 LabelImg 打开能直接看框。YOLO 的 txt 是归一化相对坐标训练时读取快、不用再算。这份资源两套都给实际用起来我的习惯是训练只喂 YOLO 的 txtVOC 的 xml 留着做人工复核和格式转换的备份。因为一旦你发现某张图标注有问题xml 里能直接看到像素框改起来比对着归一化小数猜要直观得多。提示先别急着开训花十分钟写个脚本统计每个类别的框数量类别严重不均衡的话训练策略要提前调整。3. 接进 YOLOv8/YOLO11 训练data.yaml 与最小可跑流程3.1 data.yaml 里三个必须对的字段data.yaml 是这套数据集能「直接训练」的关键它告诉训练框架去哪里找图、去哪里找标签、有几个类别。一个能跑的结构大概长这样# data.yaml path: ./excavator_dataset # 数据集根目录 train: images/train # 训练集图像相对路径 val: images/val # 验证集图像相对路径 nc: 3 # 类别数 names: # 类别名顺序必须和标注里的 class 索引一致 0: excavator 1: dump_truck 2: wheel_loader三个字段最容易出错。nc必须等于names的条目数写错了训练直接报维度不匹配。names的顺序必须和标注里class索引严格对应——如果标注里 0 是挖掘机你 yaml 里 0 写成自卸卡车模型学出来的类别就全反了而且 loss 还降得很正常属于典型的「训练看着没问题、推理全错」的玄学现场。train和val的路径是相对path的别写成绝对路径又和path叠加那样会找不到文件。3.2 用 ultralytics 跑通第一轮训练环境上yolov8 和 yolo11 现在统一走 ultralytics 这个包装起来比较省事。常见做法是建个 conda 环境Python 3.9 到 3.11 都行然后# 建环境并安装 ultralytics conda create -n yolo_train python3.10 -y conda activate yolo_train pip install ultralytics装完直接命令行起训不用自己写训练脚本# 从预训练权重开始训epochs 先给 100 试水 yolo detect train \ data./excavator_dataset/data.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16 \ device0这里几个参数值得说清楚。modelyolov8n.pt用的是 nano 版预训练权重工程机械这类目标特征比较明显nano 版先跑通验证流程足够真要上精度再换yolov8s.pt或yolo11s.pt。imgsz640是输入分辨率如果你的原图里挖掘机占的画面很小可以提到 960 甚至 1280但显存占用会明显上升。batch16是批大小显存不够就往下调调到 8 或 4 都行别硬撑导致 OOM。device0指定第一块 GPU纯 CPU 训练就把这个参数去掉但 2656 张图用 CPU 训会非常慢不建议。3.3 训练完怎么验证和推理训完之后权重默认落在runs/detect/train/weights/best.pt。验证集指标可以直接看训练日志里的 mAP50 和 mAP50-95也可以用命令单独跑一次验证# 在验证集上评估 yolo detect val \ modelruns/detect/train/weights/best.pt \ data./excavator_dataset/data.yaml \ imgsz640推理单张图或整个目录# 对一张测试图推理保存带框结果 yolo detect predict \ modelruns/detect/train/weights/best.pt \ source./test_images \ conf0.25 \ saveTrueconf0.25是置信度门限工程机械场景里如果漏检多可以降到 0.15 到 0.2 试试如果误检多就往上提到 0.4 到 0.5。这个门限没有标准答案得拿一批实际场景图去调属于典型的「调参靠手感、验证靠数据」的活。4. 从 VOC 转 YOLO 与标注自查几个容易翻车的点4.1 VOC 转 YOLO 的换算脚本虽然这份资源两套格式都给了但你后续自己补标、或者拿到一批只有 xml 的数据时还是得会转。核心就是把绝对像素坐标换成归一化相对坐标import os import xml.etree.ElementTree as ET # 类别名到索引的映射顺序必须和 data.yaml 的 names 一致 class_map {excavator: 0, dump_truck: 1, wheel_loader: 2} def voc_to_yolo(xml_path, out_txt, img_w, img_h): tree ET.parse(xml_path) root tree.getroot() lines [] for obj in root.findall(object): name obj.find(name).text.strip() if name not in class_map: continue # 跳过不在类别表里的目标 cls_id class_map[name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 转成中心点 宽高的归一化值 x_c (xmin xmax) / 2.0 / img_w y_c (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h lines.append(f{cls_id} {x_c:.6f} {y_c:.6f} {w:.6f} {h:.6f}) with open(out_txt, w) as f: f.write(\n.join(lines))逻辑上就三步读 xml 拿到像素框除以图像宽高做归一化按 YOLO 五字段拼行。参数上要注意img_w和img_h必须和这张图真实尺寸一致不能想当然用 640×640否则归一化全错。class_map的索引顺序一定要和 data.yaml 对齐这是转换脚本里最隐蔽的坑。4.2 标注自查越界框和空标签转换或拿到数据后我一般会跑一遍自查重点看两类问题。第一类是坐标越界归一化值理论上应该在 0 到 1 之间但打标时手抖拖出边界就会出现负数或大于 1 的值训练时这类框会被裁掉或报错。第二类是空标签文件有些图确实没有目标txt 是空的这本身没问题但如果图像里明明有挖掘机却没标模型就会把有目标的图当负样本学直接拉低召回。自查脚本可以这样写import os def check_labels(label_dir): bad [] for fn in os.listdir(label_dir): if not fn.endswith(.txt): continue with open(os.path.join(label_dir, fn)) as f: for i, line in enumerate(f): parts line.strip().split() if len(parts) ! 5: bad.append((fn, i, 字段数不对)) continue vals list(map(float, parts[1:])) if any(v 0 or v 1 for v in vals): bad.append((fn, i, 坐标越界)) return bad for item in check_labels(./excavator_dataset/labels_yolo): print(item)跑完把越界的框挑出来要么修要么删别带着脏数据硬训否则 loss 曲线会给你表演什么叫「震荡到怀疑人生」。4.3 类别不均衡的处理思路工程机械数据集里挖掘机往往比轮式装载机多得多这是场景决定的。类别不均衡不会让训练报错但会让模型对少样本类别几乎不响应。常见做法有几个一是训练时用cls损失加权ultralytics 里可以通过调整损失权重间接影响二是对少样本类别做数据增强比如 mosaic、mixup 加大强度三是干脆先训一个只分「有机械/无机械」的二分类再逐步细分。我一般先看每个类别的框数量分布差一个数量级以上的话增强和加权一起上。注意改完 data.yaml 的类别顺序后一定要回头检查所有 txt 里的 class 索引两者不一致是训练「看着正常、结果全错」的头号原因。5. 训练排查与踩坑记录现象、原因、解决5.1 报错「No labels found」现象是训练一启动就提示找不到标签或者 mAP 一直是 0。原因通常是 data.yaml 里的train/val路径写错或者标签目录名和框架预期的不一致——ultralytics 默认会去图像路径同级的labels目录找同名 txt如果你的标签放在labels_yolo这种自定义目录就得确认框架能正确映射。解决办法是把目录结构对齐成images/train配labels/train或者用软链接把自定义目录挂到框架预期位置。5.2 训练 loss 正常但推理框全错位现象是训练日志里 box loss 一路下降看着很健康但推理出来的框位置离谱。原因多半是标注坐标本身有问题比如把像素坐标当成了归一化坐标直接写进 txt或者 VOC 转 YOLO 时图像宽高用错。解决办法是拿几张图把标注框画出来肉眼比对用 OpenCV 读图后按归一化值反算像素框画矩形一眼就能看出对不对。5.3 显存不够 OOM现象是训练跑几十步就崩报 CUDA out of memory。原因是batch或imgsz给太大。解决办法是先把batch降到 8 或 4还不行就把imgsz从 640 降到 512或者开启梯度累积用时间换显存。别一上来就上大 batch2656 张图的数据量小 batch 多训几轮效果未必差。5.4 验证集指标虚高现象是验证集 mAP 很漂亮但拿真实工地图一测就拉胯。原因是训练集和验证集如果来自同一批视频抽帧画面高度相似验证集就失去了泛化意义。解决办法是划分时按场景或时间段切分别随机切让验证集真正代表「没见过的画面」。这份资源已经划分好了但你要清楚它的划分方式必要时自己重划。5.5 类别名对不上导致全判成同一类现象是推理时所有框都标成同一个类别。原因是 data.yaml 的names顺序和标注里的 class 索引错位。解决办法是回到 4.1 的class_map把索引和名字重新对齐改完重新训。这个坑最气人因为训练过程毫无异常全靠推理阶段肉眼发现。6. 进阶技巧用置信度门限和切片推理榨出小目标工程机械在远景画面里往往只占几十个像素640 分辨率下很容易被下采样丢掉。我一般会做两件事。第一件是调置信度门限配合 NMS 的 IoU 阈值漏检多就把conf降到 0.15、iou提到 0.6让更多候选框活下来误检多就反过来。第二件是切片推理把大图切成带重叠的小块分别推理再合并对小目标提升明显代价是推理变慢。ultralytics 里可以用augmentTrue开测试时增强也能一定程度改善小目标召回。# 小目标场景降门限 开 TTA yolo detect predict \ modelruns/detect/train/weights/best.pt \ source./site_images \ conf0.15 \ iou0.6 \ augmentTrue \ saveTrue参数上conf和iou是一对需要联调的旋钮别单独动一个。augmentTrue会做多尺度翻转推理再融合精度涨一点但速度掉不少实时场景慎用。验证方法很简单固定一批真实场景图改一组参数跑一遍把漏检和误检数记下来选综合最好的那组别凭感觉。从那以后我每次拿到新数据集都强制先跑一遍标注自查和类别分布统计再动训练脚本——省下的返工时间远比那十分钟多。希望帮到你。本文还有配套的精品资源点击获取 挖掘机数据集实战：2656张带标签图像直接训练YOLO全流程
简介这是一份面向YOLO系列目标检测学习者的工程机械数据集聚焦自卸卡车、挖掘机与轮式装载机三类目标适合需要快速搭建训练与验证流程的开发者、学生及算法工程师使用。压缩包共2000个文件以xml标注文件为主同时提供YOLO格式txt与VOC格式xml两套标签分别存放于独立文件夹文件名末尾标注对应类别名称便于按类别检索与核对。数据集已预先划分训练与验证集并附带data.yaml配置文件可直接适配YOLOv5、YOLOv8、YOLOv9、YOLOv7、YOLOv10及YOLO11等主流版本省去格式转换与目录整理成本。YOLO标签采用归一化中心点与宽高比例符合标准训练输入要求。资源包整体约232.47MB已有80人学习下载。对于想练习工程机械检测、验证模型迁移效果或补充自定义数据集的读者这份带标签数据能直接投入训练与测试帮助快速完成从数据到模型的闭环验证。1. 挖掘机数据集落地2656 张带标签图像能直接喂给 YOLO 吗工地上想做一个挖掘机、自卸卡车、轮式装载机的识别模型最卡脖子的往往不是网络结构而是手里没有一批标好的图。这份资源给的就是 2656 张工程机械图像每张都配了标签而且同时给了 YOLO 格式的 txt 和 VOC 格式的 xml 两套标注还附了划分好的数据集配置 data.yaml。换句话说它把「找图—打标—划分—写配置」这条最耗人力的链路直接跳过了拿到手就能接上 yolov5、yolov8、yolov9、yolov7、yolov10、yolo11 这一串 yolo 系列算法开训。适合两类人一类是想快速验证工程机械检测可行性、不想从零打标的算法同学另一类是要做工地安全监控、土方量统计、设备调度需要先跑通一个 baseline 的工程侧开发者。下面我按「这份资源到底长什么样 → 怎么接进训练 → 哪里容易翻车」的顺序拆一遍。2. 数据集结构与标签格式先看清 2656 张图是怎么组织的2.1 目录布局与两个标签文件夹这类工程机械数据集常见的组织方式是把图像放一个目录标签按格式分开放两个目录。从项目正文里那批img_0256_1178.xml、img_0256_143.xml这样的文件名能看出图像和标注是同一套主名靠扩展名区分。典型结构大致是这样excavator_dataset/ ├── images/ # 2656 张图像jpg/png │ ├── img_0256_1178.jpg │ ├── img_0256_143.jpg │ └── ... ├── labels_yolo/ # YOLO 格式txt │ ├── img_0256_1178.txt │ └── ... ├── labels_voc/ # VOC 格式xml │ ├── img_0256_1178.xml │ └── ... └── data.yaml # 数据集配置文件这里有个细节值得注意摘要里说「文件名末尾是部分类别名称」意思是有些标注文件名会带上类别后缀比如xxx_excavator.txt。这种命名在多人协作打标时很常见好处是一眼能看出这张图主标了什么坏处是如果你写脚本按「主名严格相等」去匹配图像和标签就会匹配失败。我一般会先把主名抽出来做一次对齐检查确认图像和标签数量一致再往下走。2.2 YOLO 格式的五个字段到底怎么读YOLO 的 txt 标注每行是一个目标格式是class x_center y_center width height。前一个是类别索引从 0 开始后面四个都是归一化到 0 到 1 的比例值不是像素。这一点是新手最容易搞混的地方——x_center和y_center是框中心点相对整张图宽高的比例width和height是框宽高相对整张图宽高的比例。举个具体例子一张 1920×1080 的图里有个框左上角 (480, 270)、右下角 (960, 540)那么中心点像素 ((480960)/2, (270540)/2) (720, 405)归一化中心 (720/1920, 405/1080) (0.375, 0.375)框宽高像素 (480, 270)归一化 (480/1920, 270/1080) (0.25, 0.25)所以这一行就是0 0.375 0.375 0.25 0.25。理解了这个换算后面无论你是要可视化检查标注还是要把 VOC 转 YOLO都不会绕晕。2.3 VOC 格式与 YOLO 格式的取舍VOC 的 xml 存的是绝对像素坐标bndbox里是xmin/ymin/xmax/ymax可读性好用 LabelImg 打开能直接看框。YOLO 的 txt 是归一化相对坐标训练时读取快、不用再算。这份资源两套都给实际用起来我的习惯是训练只喂 YOLO 的 txtVOC 的 xml 留着做人工复核和格式转换的备份。因为一旦你发现某张图标注有问题xml 里能直接看到像素框改起来比对着归一化小数猜要直观得多。提示先别急着开训花十分钟写个脚本统计每个类别的框数量类别严重不均衡的话训练策略要提前调整。3. 接进 YOLOv8/YOLO11 训练data.yaml 与最小可跑流程3.1 data.yaml 里三个必须对的字段data.yaml 是这套数据集能「直接训练」的关键它告诉训练框架去哪里找图、去哪里找标签、有几个类别。一个能跑的结构大概长这样# data.yaml path: ./excavator_dataset # 数据集根目录 train: images/train # 训练集图像相对路径 val: images/val # 验证集图像相对路径 nc: 3 # 类别数 names: # 类别名顺序必须和标注里的 class 索引一致 0: excavator 1: dump_truck 2: wheel_loader三个字段最容易出错。nc必须等于names的条目数写错了训练直接报维度不匹配。names的顺序必须和标注里class索引严格对应——如果标注里 0 是挖掘机你 yaml 里 0 写成自卸卡车模型学出来的类别就全反了而且 loss 还降得很正常属于典型的「训练看着没问题、推理全错」的玄学现场。train和val的路径是相对path的别写成绝对路径又和path叠加那样会找不到文件。3.2 用 ultralytics 跑通第一轮训练环境上yolov8 和 yolo11 现在统一走 ultralytics 这个包装起来比较省事。常见做法是建个 conda 环境Python 3.9 到 3.11 都行然后# 建环境并安装 ultralytics conda create -n yolo_train python3.10 -y conda activate yolo_train pip install ultralytics装完直接命令行起训不用自己写训练脚本# 从预训练权重开始训epochs 先给 100 试水 yolo detect train \ data./excavator_dataset/data.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16 \ device0这里几个参数值得说清楚。modelyolov8n.pt用的是 nano 版预训练权重工程机械这类目标特征比较明显nano 版先跑通验证流程足够真要上精度再换yolov8s.pt或yolo11s.pt。imgsz640是输入分辨率如果你的原图里挖掘机占的画面很小可以提到 960 甚至 1280但显存占用会明显上升。batch16是批大小显存不够就往下调调到 8 或 4 都行别硬撑导致 OOM。device0指定第一块 GPU纯 CPU 训练就把这个参数去掉但 2656 张图用 CPU 训会非常慢不建议。3.3 训练完怎么验证和推理训完之后权重默认落在runs/detect/train/weights/best.pt。验证集指标可以直接看训练日志里的 mAP50 和 mAP50-95也可以用命令单独跑一次验证# 在验证集上评估 yolo detect val \ modelruns/detect/train/weights/best.pt \ data./excavator_dataset/data.yaml \ imgsz640推理单张图或整个目录# 对一张测试图推理保存带框结果 yolo detect predict \ modelruns/detect/train/weights/best.pt \ source./test_images \ conf0.25 \ saveTrueconf0.25是置信度门限工程机械场景里如果漏检多可以降到 0.15 到 0.2 试试如果误检多就往上提到 0.4 到 0.5。这个门限没有标准答案得拿一批实际场景图去调属于典型的「调参靠手感、验证靠数据」的活。4. 从 VOC 转 YOLO 与标注自查几个容易翻车的点4.1 VOC 转 YOLO 的换算脚本虽然这份资源两套格式都给了但你后续自己补标、或者拿到一批只有 xml 的数据时还是得会转。核心就是把绝对像素坐标换成归一化相对坐标import os import xml.etree.ElementTree as ET # 类别名到索引的映射顺序必须和 data.yaml 的 names 一致 class_map {excavator: 0, dump_truck: 1, wheel_loader: 2} def voc_to_yolo(xml_path, out_txt, img_w, img_h): tree ET.parse(xml_path) root tree.getroot() lines [] for obj in root.findall(object): name obj.find(name).text.strip() if name not in class_map: continue # 跳过不在类别表里的目标 cls_id class_map[name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 转成中心点 宽高的归一化值 x_c (xmin xmax) / 2.0 / img_w y_c (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h lines.append(f{cls_id} {x_c:.6f} {y_c:.6f} {w:.6f} {h:.6f}) with open(out_txt, w) as f: f.write(\n.join(lines))逻辑上就三步读 xml 拿到像素框除以图像宽高做归一化按 YOLO 五字段拼行。参数上要注意img_w和img_h必须和这张图真实尺寸一致不能想当然用 640×640否则归一化全错。class_map的索引顺序一定要和 data.yaml 对齐这是转换脚本里最隐蔽的坑。4.2 标注自查越界框和空标签转换或拿到数据后我一般会跑一遍自查重点看两类问题。第一类是坐标越界归一化值理论上应该在 0 到 1 之间但打标时手抖拖出边界就会出现负数或大于 1 的值训练时这类框会被裁掉或报错。第二类是空标签文件有些图确实没有目标txt 是空的这本身没问题但如果图像里明明有挖掘机却没标模型就会把有目标的图当负样本学直接拉低召回。自查脚本可以这样写import os def check_labels(label_dir): bad [] for fn in os.listdir(label_dir): if not fn.endswith(.txt): continue with open(os.path.join(label_dir, fn)) as f: for i, line in enumerate(f): parts line.strip().split() if len(parts) ! 5: bad.append((fn, i, 字段数不对)) continue vals list(map(float, parts[1:])) if any(v 0 or v 1 for v in vals): bad.append((fn, i, 坐标越界)) return bad for item in check_labels(./excavator_dataset/labels_yolo): print(item)跑完把越界的框挑出来要么修要么删别带着脏数据硬训否则 loss 曲线会给你表演什么叫「震荡到怀疑人生」。4.3 类别不均衡的处理思路工程机械数据集里挖掘机往往比轮式装载机多得多这是场景决定的。类别不均衡不会让训练报错但会让模型对少样本类别几乎不响应。常见做法有几个一是训练时用cls损失加权ultralytics 里可以通过调整损失权重间接影响二是对少样本类别做数据增强比如 mosaic、mixup 加大强度三是干脆先训一个只分「有机械/无机械」的二分类再逐步细分。我一般先看每个类别的框数量分布差一个数量级以上的话增强和加权一起上。注意改完 data.yaml 的类别顺序后一定要回头检查所有 txt 里的 class 索引两者不一致是训练「看着正常、结果全错」的头号原因。5. 训练排查与踩坑记录现象、原因、解决5.1 报错「No labels found」现象是训练一启动就提示找不到标签或者 mAP 一直是 0。原因通常是 data.yaml 里的train/val路径写错或者标签目录名和框架预期的不一致——ultralytics 默认会去图像路径同级的labels目录找同名 txt如果你的标签放在labels_yolo这种自定义目录就得确认框架能正确映射。解决办法是把目录结构对齐成images/train配labels/train或者用软链接把自定义目录挂到框架预期位置。5.2 训练 loss 正常但推理框全错位现象是训练日志里 box loss 一路下降看着很健康但推理出来的框位置离谱。原因多半是标注坐标本身有问题比如把像素坐标当成了归一化坐标直接写进 txt或者 VOC 转 YOLO 时图像宽高用错。解决办法是拿几张图把标注框画出来肉眼比对用 OpenCV 读图后按归一化值反算像素框画矩形一眼就能看出对不对。5.3 显存不够 OOM现象是训练跑几十步就崩报 CUDA out of memory。原因是batch或imgsz给太大。解决办法是先把batch降到 8 或 4还不行就把imgsz从 640 降到 512或者开启梯度累积用时间换显存。别一上来就上大 batch2656 张图的数据量小 batch 多训几轮效果未必差。5.4 验证集指标虚高现象是验证集 mAP 很漂亮但拿真实工地图一测就拉胯。原因是训练集和验证集如果来自同一批视频抽帧画面高度相似验证集就失去了泛化意义。解决办法是划分时按场景或时间段切分别随机切让验证集真正代表「没见过的画面」。这份资源已经划分好了但你要清楚它的划分方式必要时自己重划。5.5 类别名对不上导致全判成同一类现象是推理时所有框都标成同一个类别。原因是 data.yaml 的names顺序和标注里的 class 索引错位。解决办法是回到 4.1 的class_map把索引和名字重新对齐改完重新训。这个坑最气人因为训练过程毫无异常全靠推理阶段肉眼发现。6. 进阶技巧用置信度门限和切片推理榨出小目标工程机械在远景画面里往往只占几十个像素640 分辨率下很容易被下采样丢掉。我一般会做两件事。第一件是调置信度门限配合 NMS 的 IoU 阈值漏检多就把conf降到 0.15、iou提到 0.6让更多候选框活下来误检多就反过来。第二件是切片推理把大图切成带重叠的小块分别推理再合并对小目标提升明显代价是推理变慢。ultralytics 里可以用augmentTrue开测试时增强也能一定程度改善小目标召回。# 小目标场景降门限 开 TTA yolo detect predict \ modelruns/detect/train/weights/best.pt \ source./site_images \ conf0.15 \ iou0.6 \ augmentTrue \ saveTrue参数上conf和iou是一对需要联调的旋钮别单独动一个。augmentTrue会做多尺度翻转推理再融合精度涨一点但速度掉不少实时场景慎用。验证方法很简单固定一批真实场景图改一组参数跑一遍把漏检和误检数记下来选综合最好的那组别凭感觉。从那以后我每次拿到新数据集都强制先跑一遍标注自查和类别分布统计再动训练脚本——省下的返工时间远比那十分钟多。希望帮到你。本文还有配套的精品资源点击获取