简介面向工程机械视觉检测场景这份数据集收录了五千零六十七张真实场景图片覆盖混凝土运输车、挖掘机、叉车、装载机、压路机、卡车及工人共七个类别。每张图片均配有Pascal VOC格式的xml标注文件和YOLO格式的txt标注文件可直接用于目标检测、实例分割等模型训练适配YOLOv5、YOLOv8、Faster R-CNN等主流框架也适合作为算法对比和毕业设计验证数据。压缩包内共约两千个文件以xml标注文件为主并附有一份使用前必读说明整体大小约三百二十一点八六兆字节图片与同名标注一一对应目录结构清晰便于快速检索和划分训练集与验证集。目前已有五百八十六人学习下载适合高校学生、算法工程师以及工程车辆智能化项目开发者使用借助该数据集可省去繁琐的数据采集与格式转换工作直接进入模型训练与效果评估环节。1. 工程车辆检测数据集入手先看标注格式别急着解压训练做智慧工地、厂区安防或矿区车辆调度的同行大概率经历过这种场面现场视频背景杂乱、车辆互相遮挡用通用 YOLO 模型去检测挖掘机和叉车要么把装载机认成挖掘机要么漏掉叉车的货叉。这时候缺的不是新模型结构而是一份针对性收集的工程车辆检测数据集。标题这个数据集是 VOC 和 YOLO 双格式5067 张图、7 个类别、7z 压缩打包对做车辆识别、计数和无人巡检的人能省掉爬图标注的两周时间。但数据拿到手不等于直接能训。格式兼容、类别编号对齐、目录组织、参数设置每一步都有隐藏坑。下面按我处理同类数据的完整流程讲从格式拆解到最终验证照着走能少踩一半坑。2. 拆解 5067 张与 7 类别先摸清格式再谈训练2.1 7 个类别怎么定检测器的输出边界在哪里标题写了 7 类别但在解压之前你并不知道这 7 类具体是什么。常见的工程车辆检测数据集类别一般围绕挖掘机、叉车、推土机、装载机、起重机、压路机、自卸卡车来组织也有的会把渣土车单独拎出来。拿到压缩包后第一件事不是翻图片而是把标签文件里的类别编号全部统计出来。因为压缩包对外宣称的 7 类和实际标签文件里的编号不一定对得上可能某个编号断档也可能某个类只有几十个实例。统计 .txt 标签里的类别分布Linux 下一条命令就行for f in $(find labels -name *.txt); do awk {print $1} $f; done | sort -n | uniq -c这段命令把 labels 目录下所有 txt 文件的第一列 class_id 取出来排序后统计每个编号出现的次数。输出第一列是次数第二列是类别编号。如果结果里某个编号的计数为 0说明这个类在标签里是空的配置 data.yaml 时就要注意。工程车辆类别里挖掘机和装载机外形接近叉车和托盘搬运车也常混如果统计发现这两类实例数明显偏少后面训练时要考虑针对短板类别做增强。类别不平衡的影响在工程车辆检测上比通用检测更明显。通用目标检测的多数类别有大量样本支撑而工程车辆数据集里挖掘机往往是最多的类压路机、起重机相对较少。如果最多类的样本数是弱势类的 5 倍以上模型的 loss 会被多数类主导弱势类目标在推理时漏检率很高。处理办法有三种复制增强、使用类别权重、调整 loss 的类别系数。复制增强最直接先把弱势类的图片复制几份再对复制出来的图片做水平翻转或小幅旋转成本低、效果直观。2.2 VOC 与 YOLO 两种格式从像素框到归一化中心的换算VOC 格式沿用 Pascal VOC 的目录约定JPEGImages 放原图Annotations 放同名 XMLImageSets/Main 里是划分后的 train/val 清单。XML 的object节点记录类别名和bndbox四个坐标 xmin、ymin、xmax、ymax 都是像素绝对值比如xmin182/xmin表示框左边距离图片左边 182 像素。YOLO 格式则是 images 和 labels 两个平级目录每张图片对应一个同名 txt每一行写作 class_id x_center y_center width height且四个坐标值全部归一化到 0~1 区间。有个高频混淆点归一化的分母是图片的原始像素宽高不是网络输入的 416 或 640。很多人把 VOC 转 YOLO 时顺手拿了 imgsz 当分母结果所有框坐标都偏到图片中心附近训练时损失直接 nan。标准的转换逻辑from PIL import Image import xml.etree.ElementTree as ET def voc_to_yolo(xml_path: str, img_path: str, class_map: dict): img Image.open(img_path) img_w, img_h img.size tree ET.parse(xml_path) lines [] for obj in tree.findall(object): name obj.find(name).text if name not in class_map: continue bndbox obj.find(bndbox) xmin float(bndbox.find(xmin).text) ymin float(bndbox.find(ymin).text) xmax float(bndbox.find(xmax).text) ymax float(bndbox.find(ymax).text) x_center ((xmin xmax) / 2) / img_w y_center ((ymin ymax) / 2) / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append(f{class_map[name]} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) return lines这段代码里img_w 和 img_h 是图片真实像素宽高所有除法都以它们为分母。class_map 是类别名到数字编号的映射比如 {excavator: 0, forklift: 1}。输出行的前两个小数是框中心点坐标后两个是框的宽高比例都保留 6 位小数。要注意 float 转换时 XML 里的值可能带换行或前后空格float 能自动处理但如果某个 bndbox 缺字段这里会直接抛异常。建议在循环外对 findall 结果先做空值检查避免一张损坏的 XML 中断整个转换流程。PIL 读取图片时还要留意 EXIF 旋转信息。手机或某些相机拍摄的 JPEG 会带 orientation 标签PIL 默认不处理它读出来的宽高和实际展示方向不一致转换出来的坐标全错。处理方式是用 ImageOps.exif_transpose 先转正图片再取尺寸。另一个相关坑是图片如果带 alpha 通道或色彩空间异常Image.open 不一定报错但尺寸可能读成 0遇到这种图直接剔除比修图更省事。2.3 5067 张怎么看数量背后是场景分布和分辨率5000 张对工程车辆这类“类别少、形态固定”的任务来说足够训练一个可用的检测器但有一个前提场景分布要撑得住。如果 5067 张都来自同一个机位的视频抽帧模型学到的是那个背景下的车辆外观换个工地就掉点。这是工程车辆数据集最典型的翻车原因不是数量问题是分布问题。拿到数据先把图片分辨率分布摸清命令如下python3 -c from PIL import Image import glob from collections import Counter sizes Counter() for p in glob.glob(images/train/*.jpg): w, h Image.open(p).size sizes[(w, h)] 1 print(sizes.most_common(10)) 这段代码用 Counter 统计训练集里每种分辨率的出现次数打印 Top10。如果发现所有图片都是同一个分辨率说明数据来源单一大概率是同一段视频裁剪。工程车辆数据集的常见分辨率为 1920x1080 和 1280x720属正常范围。如果出现大量超宽全景图或拼接图训练时会被强制拉伸检测性能下降。场景多样性靠分辨率看不出来需要抽查。我一般会在每个类别里随机挑 20 张图人工过一遍重点看背景是否变化、光照条件、目标尺度范围。如果 20 张里有 15 张的背景是同一个工地大门这数据只能作为预训练的底子真正用在自己的项目上还需要加入现场样本做微调。目标尺度分布可以用标签的宽高比粗筛统计所有标注框面积占整张图面积的比例小于 2% 的框算小目标。工程车辆的远距离拍摄经常产生大量小目标这类目标占比高时训练参数的选择策略完全不同第 4 章展开讲。另一个容易漏掉的经验压缩包里的图片总数和解压后实际落盘的图片数不一定一致。分卷压缩或转存过程可能丢文件解压后用 find images -name *.jpg | wc -l 数一下和宣传的 5067 对一下数少了先补文件再训练。数据完整性校验应该排在所有训练参数之前。3. 拿到 .7z 先别急着解压环境准备与目录校验3.1 解压 7zp7zip 安装与三条常用命令.7z 是 7-Zip 的压缩格式Linux 默认不带解压工具需要先装 p7zip。Debian/Ubuntu 系装 p7zip-fullCentOS/RHEL 系装 p7zip。安装后最常用的三条命令如下。# Debian/Ubuntu 安装 p7zip sudo apt update sudo apt install -y p7zip-full # 查看压缩包内容列表确认目录结构再解压 7z l 挖掘机叉车工程车辆检测数据集VOCYOLO格式5067张7类别.7z # 解压到指定目录避免文件散落到当前目录 7z x 挖掘机叉车工程车辆检测数据集VOCYOLO格式5067张7类别.7z -o./dataset # 测试压缩包完整性传输中损坏的情况能提前发现 7z t 挖掘机叉车工程车辆检测数据集VOCYOLO格式5067张7类别.7z注意7z x 的 -o 参数后面不能加空格写成 -o./dataset 而不是 -o ./dataset。三条命令用途要分清。7z l 只列出内容不落盘适合先看目录结构判断是 VOC 风格还是 YOLO 风格再决定解压后要不要做转换和划分。7z x 是真正解压并保留压缩包内的目录层级。7z t 是测试 CRC 完整性从网盘或转存渠道拿到的文件传输中损坏概率不低解压时报错再排查会耽误时间先测试是稳的。Windows 下解压 .7z 通常用 7-Zip 官方客户端右键选择“解压到当前文件夹”即可。但要注意7-Zip 解压时默认保留压缩包内的目录层级。如果压缩包根目录是个单独文件夹解压后会出现一层嵌套目录如果压缩包内没有根目录解压出的文件会直接散落到当前文件夹。建议在压缩包同级新建一个英文目录再解压避免文件散落。Windows 解压出的文件路径如果包含中文传到 Linux 服务器后要统一改名否则训练脚本大概率找不到文件。3.2 目录标准化把数据整理成 YOLO 能直接读的布局解压后常见两类目录形态。VOC 风格JPEGImages/、Annotations/、ImageSets/Main/YOLO 风格images/train、images/val、labels/train、labels/val。Ultralytics YOLOv8 训练时固定读取后一种布局所以拿到 VOC 风格要先转换和划分。一个直接可用的 VOC 转 YOLO 脚本如下#!/usr/bin/env python3 import xml.etree.ElementTree as ET from pathlib import Path from PIL import Image voc_img_dir Path(JPEGImages) voc_ann_dir Path(Annotations) out_img_dir Path(images/train) out_lbl_dir Path(labels/train) class_map {excavator: 0, forklift: 1} for xml_path in voc_ann_dir.glob(*.xml): img_path voc_img_dir / (xml_path.stem .jpg) if not img_path.exists(): continue tree ET.parse(xml_path) img Image.open(img_path).convert(RGB) w, h img.size out_lines [] for obj in tree.findall(object): name obj.find(name).text if name not in class_map: continue box obj.find(bndbox) xmin, ymin float(box.find(xmin).text), float(box.find(ymin).text) xmax, ymax float(box.find(xmax).text), float(box.find(ymax).text) xc (xmin xmax) / 2 / w yc (ymin ymax) / 2 / h bw (xmax - xmin) / w bh (ymax - ymin) / h out_lines.append(f{class_map[name]} {xc:.6f} {yc:.6f} {bw:.6f} {bh:.6f}) out_img_dir.mkdir(parentsTrue, exist_okTrue) out_lbl_dir.mkdir(parentsTrue, exist_okTrue) img.save(out_img_dir / img_path.name) (out_lbl_dir / (xml_path.stem .txt)).write_text(\n.join(out_lines))这个脚本把 VOC 标签转成 YOLO txt并把图片挪到 images/train。convert(RGB) 是为了把带 alpha 通道的图片统一转成三通道避免后续训练时 cv2 读取出错。class_map 只转需要的类别未知类别直接忽略这种过滤逻辑在处理多类别数据集时很常用。划分完还要保证 labels 里的 txt 文件名和 images 里的 jpg 文件名逐一对上。用命令检查两边的文件名集合是否一致diff (ls images/train | sed s/\.jpg$//) (ls labels/train | sed s/\.txt$//)如果 diff 有输出说明有文件名对不上缺的文件要补多的文件要查。这一步没做好训练时 Ultralytics 加载阶段会随机丢样本或者报 FileNotFoundError。这类错误不明显体现在训练日志中排查起来很花时间所以把校验放在训练前最划算。3.3 标签与图片对应检查一个脚本找出脏数据数据集的坑常常藏在标签文件里。空的 txt、坐标越界、类别编号越界、字段数不对每一种都会让训练过程变得很玄学——loss 降着降着变 nan或者 mAP 一直起不来。我先把这些问题一次性扫出来。#!/usr/bin/env python3 from pathlib import Path def scan(img_dir: Path, label_dir: Path): missing, empty, dirty [], [], [] for img in sorted(img_dir.glob(*.jpg)): lbl label_dir / (img.stem .txt) if not lbl.exists(): missing.append(img.name) continue if lbl.stat().st_size 0: empty.append(img.name) continue for line in lbl.read_text().strip().splitlines(): parts line.split() if len(parts) ! 5: dirty.append((img.name, 字段数不为5)) break try: cid int(parts[0]) vals [float(v) for v in parts[1:]] except ValueError: dirty.append((img.name, 数值解析失败)) break if any(v 0 or v 1 for v in vals): dirty.append((img.name, 归一化坐标越界)) break if cid 0 or cid 6: dirty.append((img.name, f类别id越界: {cid})) break return missing, empty, dirty miss, emp, dirt scan(Path(images/train), Path(labels/train)) print(f缺标签 {len(miss)}空标签 {len(emp)}异常 {len(dirt)})检查逻辑分三层。第一层看同名文件是否存在缺标签的图片会被模型当成背景样本这种样本过多时模型会把车辆学成背景。第二层看文件是否为空空标签意味着图上没有任何目标通常是清洗阶段漏删。第三层逐行解析归一化坐标必须在 0~1 之间类别 id 必须落在 0~6 区间。注意 YOLO 坐标允许正好等于 0 或 1 的边缘框但超过 1 或小于 0 就一定是脏数据。修数据的策略不是直接删。先把异常集中在哪些图片上找出来如果 100 张异常图都来自同一个转换脚本批次多半是那批图片尺寸读错了重新转换比删图更合理。如果异常是零散的说明原标注本身有问题人工修正或剔除都行。我一般倾向剔除5000 张数据里剔掉 1% 对整体训练影响很小但保留脏数据可能导致训练过程崩溃。4. 用 YOLOv8 跑通训练data.yaml 与关键参数设定4.1 从标签分布反推 names类别对齐是第一步很多人习惯直接抄一份现成的 data.yaml改个路径就开始训练最后推理时挖掘机和装载机标签互换这就是 names 顺序没对齐。正确做法是从标签文件反推类别顺序保证 data.yaml 里 names 的索引和标签文件里的 class_id 一一对应。先统计标签分布for f in $(find labels/train -name *.txt); do awk {print $1} $f; done | sort -n | uniq -c假设输出是3200 0 2800 1 1500 2 900 3 720 4 180 5 60 6编号 0 是样本最多的类编号 6 是最少的类。结合原数据集的类别说明或人工打开标签中该编号对应的图片确认语义。如果原数据集没有给类别清单就按自己看图认定的名称来写 names但务必保证编号与语义对应。写好的 data.yamlpath: /home/user/dataset train: images/train val: images/val names: 0: excavator 1: forklift 2: bulldozer 3: loader 4: crane 5: roller 6: dump_truckpath 指向数据集根目录train 和 val 是相对 path 的路径。names 的索引必须与标签文件里的 class_id 对应。如果标签里编号 0 是 excavator这里索引 0 也必须是 excavator。注意names 索引与标签 class_id 不对齐时训练不会报错但推理结果会类别错乱。4.2 训练命令与四个关键参数imgsz、batch、epochs、device数据集整理好之后用 Ultralytics YOLOv8 训练是最省事的路线。选择预训练权重时yolov8n.pt 适合快速验证流程yolov8s.pt 或 yolov8m.pt 对工程车辆这类小目标多的任务效果更好代价是显存和训练时间上涨。最小训练命令yolo detect train \ modelyolov8n.pt \ datadata.yaml \ imgsz640 \ batch16 \ epochs100 \ device0参数说明imgsz640 是网络输入尺寸。工程车辆数据集的远距离小目标占比高时建议提到 960 或 1280但显存占用按平方增长。如果大部分是近距离车辆640 够用。一个实用的判断办法先用 640 训 20 轮看验证集小目标召回率不够再上 960。batch16 受显存约束。batch 越大梯度越稳但没必要为了凑 batch 把 imgsz 降下来。工程车辆的小目标问题远大于梯度稳定性问题我的优先级是保 imgsz 再谈 batch。epochs100 对 5000 张左右的数据集足够。Ultralytics 默认开了早停 patience50模型在验证集不再提升时会提前结束不会硬跑满 100 轮。device0 指定 GPU 编号。没有 GPU 时可填 cpu但 5000 张图跑 100 epoch 在 CPU 上可能要几天预算允许还是租 GPU 更快。还有两个容易被忽略的参数。cacheTrue 会把图片缓存进内存IO 等待大幅减少数据集几个 G 时强烈建议开。workers 控制数据加载进程数默认 8如果训练时 CPU 被打满导致 GPU 利用率波动适当调低到 4。训练一旦开始日志里重点看两个信号box_loss 和 cls_loss 是否稳定下降、mAP50 是否每轮在涨。如果 loss 前几轮就降到接近 0 而 mAP 却很低数据多半有问题回头查第 3.3 节的扫描结果。训练中途断了不要慌Ultralytics 支持断点恢复重新运行命令时把 model 指向上次的 last.pt 并加 resume 参数yolo detect train \ modelruns/detect/train/weights/last.pt \ datadata.yaml \ imgsz960 \ batch16 \ resumeTrueresumeTrue 会把训练轮次、优化器状态、学习率调度全部恢复不用从头再来。另外用 --name 参数给每次实验打标签比如 --name excavator_960_v1Ultralytics 会把结果输出到 runs/detect/excavator_960_v1/多个版本对比时不会互相覆盖。这种版本管理习惯在调参阶段特别重要。4.3 验证集划分随机划分之外的另一个选择划分验证集时随机划分是最常见但不是最稳的选择。工程车辆数据集大量来自连续视频抽帧相邻帧背景几乎一样、车辆姿态几乎一样随机划分会把近重复帧同时分到训练集和验证集结果就是模型开卷考试验证集 mAP 虚高换个工地实测直接打对折。更稳的方案是按场景划分。把图片按文件名前缀或时间戳分成组同一个组的帧要么全进训练集要么全进验证集。比如文件名是 siteA_001.jpg、siteA_002.jpgsiteB_001.jpg那就把 siteA 和 siteB 分开模型在 siteB 上的表现才有参考价值。一个带固定随机种子的划分脚本import random from pathlib import Path all_imgs sorted(Path(images/all).glob(*.jpg)) random.seed(42) random.shuffle(all_imgs) split int(len(all_imgs) * 0.8) train_imgs all_imgs[:split] val_imgs all_imgs[split:]这段代码虽然做了随机划分但传入了固定随机种子保证每次复现的划分一致。如果要求按场景划分就把 shuffle 换成按前缀分组再按组分配。最后把划分结果写入 train.txt 和 val.txt或者直接在文件系统里移动图片到对应的 train/val 子目录。如果数据集自带 ImageSets/Main 的划分清单直接沿用原划分。作者在制作数据集时通常会把不同场景、光照条件拆开自己重划容易打破这个平衡——某个类别的样本全集中在某组里一拆就把这个类完全拆到验证集训练集里这个类归零。这种情况模型不仅学不好这个类还会在验证集上暴露出来mAP 直接塌方。经典的 8:2 划分在 5067 张下验证集约 1000 张足够评估。如果某次验证比上一次低了 5 个点但训练 loss 正常先确认是不是验证集太小导致的随机波动不要急着调参。5. 避坑工程车辆数据集从解压到训练的 5 个高频问题训练工程车辆检测模型的翻车点往往不在模型结构上而在数据本身。以下 5 个问题是我处理这类数据集时遇到过的真实案例按“现象、原因、解决”拆开写每个都可以对照自己的日志定位。5.1 训练时报 FileNotFoundError路径里全是中文和空格现象把数据集在 Windows 解压后传到 Linux 服务器训练刚开始就报图片路径找不到错误信息里路径含中文或空格去掉后能训练但数据加载异常慢。原因压缩包制作时目录名带了中文Windows 下用 GBK 编码创建的文件名传到 UTF-8 的 Linux 后路径拼接时出现编码不一致。带空格的目录则会在 YAML 路径解析时被截断成两段。解决解压后立即把整个数据集重命名为纯英文、无空格、无特殊字符的路径例如 /data/construction_vehicle。整个项目路径都不要出现中文。有同行把数据集放在 /root/下载/数据集/ 这种路径下yolo 训练时反复报路径错误挪到英文路径后一切正常这类问题排查一次就能记住。5.2 loss 变 nan启动时报 all labels are out of bounds现象训练启动时报 all labels are out of bounds或者训练到若干轮后 loss 突然变 nan验证集指标全部无效。原因VOC 转 YOLO 时归一化分母用错比如拿网络输入尺寸 640 当分母导致 x_center、width 超出 0~1 区间。另一种是图片有 EXIF 旋转信息PIL 读出的宽高与标注坐标系相反。如果确认标签没问题再检查 batch 是否太小导致 BN 统计量不稳定。解决先跑第 3.3 节的扫描脚本把所有越界标签找出来判断是全局性还是零散性问题。全局性说明转换脚本错了修正后重新生成 labels零散性说明原标注有误剔除再训。修正后启动训练前再用脚本复查一遍不要让 nan 浪费一次训练轮次。5.3 mAP50 高达 0.9 但现场实测一塌糊涂训练集和验证集重复现象训练日志里 mAP50 到 0.9 以上模型拿到工地现场测试检测率大跌误检漏检频出。原因数据集是视频抽帧随机划分时把同一场景的相邻帧拆到了训练集和验证集验证集和训练集高度相似属于开卷考试得分无参考价值。解决按场景划分验证集见第 4.3 节。划分前用 md5 对全图去重视频抽帧数据集里常见完全相同的帧重复出现。检查方法从验证集随机抽 50 张图到训练集里用 md5 比较如果有重复就重新划分。我见过 mAP 虚高到 0.95 的模型现场只有 0.4 的记录排查到最后就是划分方式的问题。5.4 推理结果张冠李戴挖掘机显示成叉车现象训练正常、验证正常推理时类别标签全部错乱背景里的挖掘机显示成了 forklift。原因data.yaml 的 names 顺序与标签文件的 class_id 索引不一致。模型只按数字索引学习类别语义名称只影响推理时的显示文本。解决严格按第 4.1 节的流程反推类别先统计 class_id 分布再人工看图确认每个编号的语义最后写 names。训练完跑一个推理脚本输出类别 id 和名称对照验证没有错位。如果已经训完但发现 names 写错了改对 data.yaml 后不需要重训直接用原权重重新预测类别显示会自动修正。5.5 mAP50-95 上不去远距离小目标全漏检现象mAP50 在 0.7 左右mAP50-95 只有 0.3远距离的小挖掘机、小叉车几乎漏检。原因工程车辆数据集中大量目标是小尺度远处或俯拍视角imgsz640 时小目标在骨干网络里经过多次降采样后特征丢失。样本最少的类别也集中在小目标上模型学不好。解决把 imgsz 提到 960 或 1280显存不够时下调 batch。关闭 mosaic 并启用对小目标更友好的增强策略。另一个有效技巧针对样本最少的类别手动挑选该类图片做水平翻转和随机裁剪后复制进训练集把短板补上。这类问题不要指望换模型结构一步解决先把输入分辨率和数据均衡调到位。6. 模型训完别急着交付现场验证与阈值调优训练完不等于能上线。工程车辆检测的落地场景里漏检一辆挖掘机和误报一堆背景业务侧都不会满意。我的习惯是训练完先不碰测试集指标把模型部署到推理脚本里拿几段现场视频或没参与训练的场景截图跑一遍。重点看两类问题远距离小目标漏检率以及同类车辆互相遮挡时的错检率。推理脚本最值得调的是置信度阈值。Ultralytics 默认 conf0.25 对工程车辆往往偏低工地背景里的栏杆、铁架、机械臂容易误报成车辆。我一般先用验证集跑一遍置信度分布看 0.25 到 0.5 区间里有多少真阳性再把阈值往上提到 0.35~0.45。同时 NMS 阈值也影响结果叉车停在挖掘机旁这种高重叠场景iou 阈值调太高会吞掉其中一个检测框。from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) results model.predict( sourcetest_video.mp4, conf0.35, iou0.45, imgsz960, saveTrue, )conf0.35 是手动调高后的置信度阈值iou0.45 是 NMS 阈值imgsz960 与测试场景的小目标匹配。跑完输出视频后不要只在电脑上盯着看把它放到现场监控同款分辨率下回放才能看出漏检发生在什么距离上。还有一个检查点是混淆矩阵。训练结束后用 model.val() 输出混淆矩阵看哪两个类别互相混淆最严重。工程车辆数据集里挖掘机和装载机、叉车和托盘搬运车容易混。注意混淆矩阵里的数值是归一化比例如果发现某一行总和不是 1先检查是不是有 GT 框在训练时被过滤掉了比如太小的框再下结论。如果这两类混淆确实明显优先补这两类的样本而不是换模型结构。我的习惯是每个拿到手的工程车辆数据集先花半天把格式、分布、脏数据摸清再花一小时跑训练。看似慢实际上这半天避开的坑后面能用一周的返工来还。标注格式验证得越细模型上线后翻车的概率越低。希望这篇能帮你少走一段弯路。本文还有配套的精品资源点击获取