拓冰网站定制 
简介这份工程车辆目标检测数据集面向建筑工地智能监控、智能交通与自动驾驶环境感知等方向的算法开发者与院校研究者聚焦混凝土搅拌车、自卸卡车、挖掘机三类常见工程车辆的识别需求。资源包共902个文件以450张JPEG实景图片和450个YOLO格式标注txt为主另附1个yaml数据配置与1份docx说明文档压缩包约65.83MB可直接加载至YOLO系列等主流框架开展训练。图片取自真实建筑与运输场景涵盖多样化车辆姿态与背景标注边界框定位精确类别高度聚焦有助于提升模型在专业场景下的泛化能力。目前已有197人学习下载。读者可获得即用型训练数据、标准标注文件与配置说明快速搭建工程车辆检测基线并扩展至分类、安全预警与作业效率优化等衍生应用。1. 工程车辆目标检测数据集从工地监控到渣土车识别的落地起点工地出入口的摄像头每天产生几十 GB 视频但真正需要报警的事件可能只有几十条——渣土车未苫盖、挖掘机越界、混凝土搅拌车违规停放。靠人盯着屏幕看漏报率极高而通用 COCO 预训练模型对挖掘机压路机渣土车这些类别的识别效果说实话翻车是常态。原因很简单COCO 里根本没有这些细分类别模型见过的truck和工地上的渣土车在纹理、比例、遮挡模式上差异巨大。工程车辆目标检测数据集要解决的就是这个断层。它把工地、矿区、道路施工场景里的工程车辆框出来、标好类让 YOLO 系列或其他检测器能直接微调落地。适合谁用做智慧工地、矿区安全监控、市政渣土车管理的算法工程师以及想拿真实场景练手目标检测的学生。这一章先把这个数据集到底装了什么、为什么不能拿 COCO 凑合讲清楚后面再拆怎么用、参数怎么调、坑在哪。2. 工程车辆数据集里到底有什么类别体系与标注格式拆解2.1 工程车辆常见类别划分与场景分布工程车辆不是一个单一类别它至少包含以下几类常见目标挖掘机、推土机、装载机、压路机、混凝土搅拌车、渣土车自卸车、汽车起重机、泵车、叉车。不同数据集根据采集场景会做取舍——矿区数据集可能侧重矿卡和挖掘机市政数据集则更关注渣土车和搅拌车。场景分布直接决定模型泛化能力。如果数据集全部来自白天、晴天、固定机位训出来的模型换个阴天或侧视角就崩。我一般会先统计几个维度拍摄时段白天/夜间/黄昏、视角固定枪机/球机/车载、遮挡比例车辆被土堆、脚手架遮挡的程度、目标尺度近处大目标 vs 远处小目标。这些统计不需要写代码用标注工具的可视化功能过一遍就能心里有数。类别不平衡是另一个必须提前看的点。挖掘机和渣土车通常样本最多泵车、叉车可能只有几十张。如果直接训稀有类别 AP 会低得没法看。常见做法是对稀有类做过采样或者在 loss 里给稀有类更高权重。2.2 标注格式VOC XML、YOLO TXT 与 COCO JSON 的转换关系工程车辆数据集常见的标注格式有三种Pascal VOC 的 XML、YOLO 的 TXT、COCO 的 JSON。你拿到的压缩包大概率是其中一种但训练框架可能要求另一种。先把三者关系理清格式坐标表示文件结构典型用途VOC XMLxmin,ymin,xmax,ymax 绝对像素每图一个 XML老牌检测框架、LabelImg 默认YOLO TXTclass_id cx cy w h 归一化每图一个 TXT classes.txtYOLOv5/v8/v11 训练COCO JSON[x,y,w,h] 绝对像素单个 JSON 汇总所有图MMDetection、Detectron2转换时最容易翻车的地方是归一化。YOLO 的 cx、cy、w、h 都是除以图像宽高后的 0~1 浮点数如果原图尺寸记录错了框会整体偏移。下面是一个 VOC 转 YOLO 的脚本我用了很多次直接抄import xml.etree.ElementTree as ET import os # 类别映射必须和 classes.txt 顺序一致 classes [excavator, bulldozer, loader, roller, mixer_truck, dump_truck, crane, pump_truck, forklift] def voc_to_yolo(xml_path, out_txt_path): tree ET.parse(xml_path) root tree.getroot() size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) lines [] for obj in root.iter(object): cls_name obj.find(name).text if cls_name not in classes: continue # 跳过未定义类别避免训练时报 index 越界 cls_id classes.index(cls_name) bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) # 归一化并转为中心点宽高 cx (xmin xmax) / 2.0 / img_w cy (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_txt_path, w) as f: f.write(\n.join(lines)) # 批量处理 for xml_file in os.listdir(annotations): if xml_file.endswith(.xml): voc_to_yolo( os.path.join(annotations, xml_file), os.path.join(labels, xml_file.replace(.xml, .txt)) )逻辑说明先读 XML 里的图像宽高再把每个框的左上右下坐标转成中心点加宽高最后除以宽高做归一化。参数说明classes列表的顺序必须和训练时 data.yaml 里的 names 完全一致否则类别会错位:.6f保留六位小数是 YOLO 官方推荐的精度太少会导致小目标框抖动。转换完务必抽查几张用可视化脚本把框画回原图确认没偏。3. 用 YOLOv8/v11 在工程车辆数据集上跑通训练环境、配置与首轮结果3.1 环境配置与数据目录组织YOLOv8 和 YOLOv11 都走 Ultralytics 这套接口环境配置基本一致。我一般用 conda 建一个干净环境避免和系统里的 torch 版本打架conda create -n eng_vehicle python3.10 -y conda activate eng_vehicle pip install ultralytics8.3.0 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121装完跑一句yolo checks确认 CUDA 可用。如果显示 CPU only检查显卡驱动和 torch 版本是否匹配这一步不通过后面训练会慢到怀疑人生。数据目录按 Ultralytics 要求组织dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamldata.yaml 内容path: /home/user/dataset train: images/train val: images/val nc: 9 names: [excavator, bulldozer, loader, roller, mixer_truck, dump_truck, crane, pump_truck, forklift]注意nc必须等于 names 长度多一个少一个都会在训练启动时报错。train 和 val 的图片不能有重叠否则验证指标虚高上线就露馅。3.2 训练命令与关键参数设置首轮训练不要一上来就调复杂超参先用默认配置跑通确认 loss 能正常下降yolo detect train \ datadataset/data.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ projecteng_vehicle_runs \ namebaseline参数说明modelyolov8s.pt是 COCO 预训练权重工程车辆类别虽然 COCO 没有但底层纹理特征可迁移比从头训快很多imgsz640是默认输入尺寸如果数据集里小目标多远处车辆可以提到 1280但显存占用翻倍batch16在 8GB 显存上跑 640 尺寸基本安全显存不够就降到 8 并开ampTrue混合精度。训练启动后重点看三个指标box_loss 是否稳定下降、mAP50 是否在 20 个 epoch 后开始爬升、cls_loss 是否震荡。如果 box_loss 不降大概率是学习率太大或标注有问题如果 mAP50 一直卡在 0.1 以下检查 data.yaml 路径和类别顺序。3.3 首轮结果解读与过拟合判断100 epoch 跑完Ultralytics 会在 runs 目录下生成 results.csv 和混淆矩阵。先看混淆矩阵如果挖掘机和装载机互相误判严重说明这两类在视觉上确实接近需要补充区分性样本或调整类别定义。再看 mAP50-95工程车辆场景一般能到 0.5~0.7 就算可用低于 0.4 要排查数据质量。过拟合的判断信号训练集 loss 持续降但验证集 mAP 在某个 epoch 后不再涨甚至下降。这时候不要急着加数据先看验证集和训练集分布是否一致——如果验证集全是夜间图而训练集全是白天那不是过拟合是分布偏移。我一般会留一个和训练集同分布的验证集做模型选择另留一个跨场景测试集做最终评估。4. 工程车辆检测的避坑与排查标注、类别与部署的 5 个血泪教训4.1 标注框贴边导致训练不稳定现象训练前期 loss 剧烈震荡mAP 几乎不涨。原因部分标注框的 xmax 等于图像宽度或 ymax 等于图像高度归一化后 w 或 h 等于 1.0YOLO 在计算 loss 时对边界框做裁剪产生异常梯度。解决写脚本检查所有 label 文件把 cx±w/2 或 cy±h/2 超出 [0,1] 的框裁到边界内或者直接剔除这些样本。我一般会在转换脚本里加一句 clamp 操作省得后面返工。4.2 类别名大小写不一致导致漏检现象训练时提示某些类别样本数为 0但明明标了。原因XML 里写的是 Excavatorclasses.txt 里写的是 excavator转换时没做统一导致这些框被跳过。解决转换前先把所有类别名转小写并去空格再和 classes 列表比对。这个坑很隐蔽因为不报错只是静默丢样本。4.3 验证集混入训练集导致指标虚高现象验证 mAP 0.85上线后实际漏检严重。原因划分数据集时用了随机划分同一段视频的相邻帧被分到训练和验证两边模型相当于见过验证集。解决按视频源或时间段划分确保验证集的场景和训练集不重叠。如果数据集本身按视频组织直接按视频文件划分最稳妥。4.4 小目标车辆在 640 尺寸下消失现象远处的小型叉车、装载机检测不到。原因640 输入下一个 20x20 像素的目标经过 backbone 下采样后只剩几个像素的特征检测头根本抓不住。解决把 imgsz 提到 1280或者在数据加载时对小目标做 mosaic 增强。如果显存不够可以用切片推理SAHI把大图切成小块分别检测再合并。4.5 部署时预处理不一致导致精度掉点现象Python 端验证 mAP 0.7转 ONNX 部署后掉到 0.5。原因训练时的归一化是除以 255部署时忘了做或者 BGR/RGB 通道顺序搞反。解决把训练时的预处理步骤写成文档部署端逐条对齐。我一般会在导出 ONNX 后用 onnxruntime 跑一遍和 PyTorch 相同的输入对比输出差异超过 1e-3 就说明预处理有问题。5. 把工程车辆检测推到可用跨场景验证与难例挖掘的实操技巧模型在验证集上跑出好看的数字只是第一步真正决定能不能上线的是跨场景表现。我一般会做两件事跨场景验证和难例挖掘。跨场景验证的做法是另外找一段和训练集不同摄像头、不同光照的视频抽帧后人工标 100~200 张作为测试集。这个测试集不参与任何训练和调参只在最终评估时用。如果 mAP 比验证集掉超过 15 个点说明模型过拟合到训练场景需要补充多样化数据或做更强的数据增强。难例挖掘更直接用训好的模型跑一遍未标注的现场视频把置信度在 0.3~0.6 之间的检测框导出来人工复核。这些框要么是模型不确定的正样本要么是背景误检。把正样本补进训练集把误检作为负样本加入迭代两三轮mAP 通常能涨 5~10 个点。下面是一个导出难例的脚本片段from ultralytics import YOLO import cv2 model YOLO(eng_vehicle_runs/baseline/weights/best.pt) # 对视频抽帧推理保存中等置信度结果 cap cv2.VideoCapture(site_video.mp4) frame_idx 0 while cap.isOpened(): ret, frame cap.read() if not ret: break if frame_idx % 30 0: # 每秒抽一帧 results model(frame, conf0.3, iou0.5) for box in results[0].boxes: conf float(box.conf) if 0.3 conf 0.6: # 保存该帧和框信息供人工复核 cv2.imwrite(fhard_examples/frame_{frame_idx}.jpg, frame) break frame_idx 1 cap.release()参数说明conf0.3是低阈值确保不漏掉模型犹豫的框iou0.5是 NMS 阈值工程车辆重叠不多0.5 够用抽帧间隔按视频帧率调整25fps 视频每 30 帧抽一张差不多。导出的图片人工过一遍正样本补标注误检直接作为背景图加入训练集。还有一个技巧是测试时增强TTA。在推理时对同一张图做水平翻转、多尺度缩放把结果融合通常能涨 1~3 个点 mAP代价是推理速度慢 3 倍。如果业务对延迟不敏感比如离线分析场景TTA 值得开。Ultralytics 里直接model.predict(source, augmentTrue)就能启用。最后说一个我自己的习惯每次训完模型不管指标多好我都会拿工地现场的视频跑一遍用肉眼过 5 分钟。指标是给论文看的肉眼过视频才是给上线用的。很多问题——比如把黄色挖掘机认成校车、把静止的压路机漏掉——混淆矩阵里看不出来但视频里一眼就能发现。希望帮到你。本文还有配套的精品资源点击获取 工程车辆目标检测数据集：从标注格式转换到YOLO训练与部署避坑
简介这份工程车辆目标检测数据集面向建筑工地智能监控、智能交通与自动驾驶环境感知等方向的算法开发者与院校研究者聚焦混凝土搅拌车、自卸卡车、挖掘机三类常见工程车辆的识别需求。资源包共902个文件以450张JPEG实景图片和450个YOLO格式标注txt为主另附1个yaml数据配置与1份docx说明文档压缩包约65.83MB可直接加载至YOLO系列等主流框架开展训练。图片取自真实建筑与运输场景涵盖多样化车辆姿态与背景标注边界框定位精确类别高度聚焦有助于提升模型在专业场景下的泛化能力。目前已有197人学习下载。读者可获得即用型训练数据、标准标注文件与配置说明快速搭建工程车辆检测基线并扩展至分类、安全预警与作业效率优化等衍生应用。1. 工程车辆目标检测数据集从工地监控到渣土车识别的落地起点工地出入口的摄像头每天产生几十 GB 视频但真正需要报警的事件可能只有几十条——渣土车未苫盖、挖掘机越界、混凝土搅拌车违规停放。靠人盯着屏幕看漏报率极高而通用 COCO 预训练模型对挖掘机压路机渣土车这些类别的识别效果说实话翻车是常态。原因很简单COCO 里根本没有这些细分类别模型见过的truck和工地上的渣土车在纹理、比例、遮挡模式上差异巨大。工程车辆目标检测数据集要解决的就是这个断层。它把工地、矿区、道路施工场景里的工程车辆框出来、标好类让 YOLO 系列或其他检测器能直接微调落地。适合谁用做智慧工地、矿区安全监控、市政渣土车管理的算法工程师以及想拿真实场景练手目标检测的学生。这一章先把这个数据集到底装了什么、为什么不能拿 COCO 凑合讲清楚后面再拆怎么用、参数怎么调、坑在哪。2. 工程车辆数据集里到底有什么类别体系与标注格式拆解2.1 工程车辆常见类别划分与场景分布工程车辆不是一个单一类别它至少包含以下几类常见目标挖掘机、推土机、装载机、压路机、混凝土搅拌车、渣土车自卸车、汽车起重机、泵车、叉车。不同数据集根据采集场景会做取舍——矿区数据集可能侧重矿卡和挖掘机市政数据集则更关注渣土车和搅拌车。场景分布直接决定模型泛化能力。如果数据集全部来自白天、晴天、固定机位训出来的模型换个阴天或侧视角就崩。我一般会先统计几个维度拍摄时段白天/夜间/黄昏、视角固定枪机/球机/车载、遮挡比例车辆被土堆、脚手架遮挡的程度、目标尺度近处大目标 vs 远处小目标。这些统计不需要写代码用标注工具的可视化功能过一遍就能心里有数。类别不平衡是另一个必须提前看的点。挖掘机和渣土车通常样本最多泵车、叉车可能只有几十张。如果直接训稀有类别 AP 会低得没法看。常见做法是对稀有类做过采样或者在 loss 里给稀有类更高权重。2.2 标注格式VOC XML、YOLO TXT 与 COCO JSON 的转换关系工程车辆数据集常见的标注格式有三种Pascal VOC 的 XML、YOLO 的 TXT、COCO 的 JSON。你拿到的压缩包大概率是其中一种但训练框架可能要求另一种。先把三者关系理清格式坐标表示文件结构典型用途VOC XMLxmin,ymin,xmax,ymax 绝对像素每图一个 XML老牌检测框架、LabelImg 默认YOLO TXTclass_id cx cy w h 归一化每图一个 TXT classes.txtYOLOv5/v8/v11 训练COCO JSON[x,y,w,h] 绝对像素单个 JSON 汇总所有图MMDetection、Detectron2转换时最容易翻车的地方是归一化。YOLO 的 cx、cy、w、h 都是除以图像宽高后的 0~1 浮点数如果原图尺寸记录错了框会整体偏移。下面是一个 VOC 转 YOLO 的脚本我用了很多次直接抄import xml.etree.ElementTree as ET import os # 类别映射必须和 classes.txt 顺序一致 classes [excavator, bulldozer, loader, roller, mixer_truck, dump_truck, crane, pump_truck, forklift] def voc_to_yolo(xml_path, out_txt_path): tree ET.parse(xml_path) root tree.getroot() size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) lines [] for obj in root.iter(object): cls_name obj.find(name).text if cls_name not in classes: continue # 跳过未定义类别避免训练时报 index 越界 cls_id classes.index(cls_name) bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) # 归一化并转为中心点宽高 cx (xmin xmax) / 2.0 / img_w cy (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_txt_path, w) as f: f.write(\n.join(lines)) # 批量处理 for xml_file in os.listdir(annotations): if xml_file.endswith(.xml): voc_to_yolo( os.path.join(annotations, xml_file), os.path.join(labels, xml_file.replace(.xml, .txt)) )逻辑说明先读 XML 里的图像宽高再把每个框的左上右下坐标转成中心点加宽高最后除以宽高做归一化。参数说明classes列表的顺序必须和训练时 data.yaml 里的 names 完全一致否则类别会错位:.6f保留六位小数是 YOLO 官方推荐的精度太少会导致小目标框抖动。转换完务必抽查几张用可视化脚本把框画回原图确认没偏。3. 用 YOLOv8/v11 在工程车辆数据集上跑通训练环境、配置与首轮结果3.1 环境配置与数据目录组织YOLOv8 和 YOLOv11 都走 Ultralytics 这套接口环境配置基本一致。我一般用 conda 建一个干净环境避免和系统里的 torch 版本打架conda create -n eng_vehicle python3.10 -y conda activate eng_vehicle pip install ultralytics8.3.0 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121装完跑一句yolo checks确认 CUDA 可用。如果显示 CPU only检查显卡驱动和 torch 版本是否匹配这一步不通过后面训练会慢到怀疑人生。数据目录按 Ultralytics 要求组织dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamldata.yaml 内容path: /home/user/dataset train: images/train val: images/val nc: 9 names: [excavator, bulldozer, loader, roller, mixer_truck, dump_truck, crane, pump_truck, forklift]注意nc必须等于 names 长度多一个少一个都会在训练启动时报错。train 和 val 的图片不能有重叠否则验证指标虚高上线就露馅。3.2 训练命令与关键参数设置首轮训练不要一上来就调复杂超参先用默认配置跑通确认 loss 能正常下降yolo detect train \ datadataset/data.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ device0 \ projecteng_vehicle_runs \ namebaseline参数说明modelyolov8s.pt是 COCO 预训练权重工程车辆类别虽然 COCO 没有但底层纹理特征可迁移比从头训快很多imgsz640是默认输入尺寸如果数据集里小目标多远处车辆可以提到 1280但显存占用翻倍batch16在 8GB 显存上跑 640 尺寸基本安全显存不够就降到 8 并开ampTrue混合精度。训练启动后重点看三个指标box_loss 是否稳定下降、mAP50 是否在 20 个 epoch 后开始爬升、cls_loss 是否震荡。如果 box_loss 不降大概率是学习率太大或标注有问题如果 mAP50 一直卡在 0.1 以下检查 data.yaml 路径和类别顺序。3.3 首轮结果解读与过拟合判断100 epoch 跑完Ultralytics 会在 runs 目录下生成 results.csv 和混淆矩阵。先看混淆矩阵如果挖掘机和装载机互相误判严重说明这两类在视觉上确实接近需要补充区分性样本或调整类别定义。再看 mAP50-95工程车辆场景一般能到 0.5~0.7 就算可用低于 0.4 要排查数据质量。过拟合的判断信号训练集 loss 持续降但验证集 mAP 在某个 epoch 后不再涨甚至下降。这时候不要急着加数据先看验证集和训练集分布是否一致——如果验证集全是夜间图而训练集全是白天那不是过拟合是分布偏移。我一般会留一个和训练集同分布的验证集做模型选择另留一个跨场景测试集做最终评估。4. 工程车辆检测的避坑与排查标注、类别与部署的 5 个血泪教训4.1 标注框贴边导致训练不稳定现象训练前期 loss 剧烈震荡mAP 几乎不涨。原因部分标注框的 xmax 等于图像宽度或 ymax 等于图像高度归一化后 w 或 h 等于 1.0YOLO 在计算 loss 时对边界框做裁剪产生异常梯度。解决写脚本检查所有 label 文件把 cx±w/2 或 cy±h/2 超出 [0,1] 的框裁到边界内或者直接剔除这些样本。我一般会在转换脚本里加一句 clamp 操作省得后面返工。4.2 类别名大小写不一致导致漏检现象训练时提示某些类别样本数为 0但明明标了。原因XML 里写的是 Excavatorclasses.txt 里写的是 excavator转换时没做统一导致这些框被跳过。解决转换前先把所有类别名转小写并去空格再和 classes 列表比对。这个坑很隐蔽因为不报错只是静默丢样本。4.3 验证集混入训练集导致指标虚高现象验证 mAP 0.85上线后实际漏检严重。原因划分数据集时用了随机划分同一段视频的相邻帧被分到训练和验证两边模型相当于见过验证集。解决按视频源或时间段划分确保验证集的场景和训练集不重叠。如果数据集本身按视频组织直接按视频文件划分最稳妥。4.4 小目标车辆在 640 尺寸下消失现象远处的小型叉车、装载机检测不到。原因640 输入下一个 20x20 像素的目标经过 backbone 下采样后只剩几个像素的特征检测头根本抓不住。解决把 imgsz 提到 1280或者在数据加载时对小目标做 mosaic 增强。如果显存不够可以用切片推理SAHI把大图切成小块分别检测再合并。4.5 部署时预处理不一致导致精度掉点现象Python 端验证 mAP 0.7转 ONNX 部署后掉到 0.5。原因训练时的归一化是除以 255部署时忘了做或者 BGR/RGB 通道顺序搞反。解决把训练时的预处理步骤写成文档部署端逐条对齐。我一般会在导出 ONNX 后用 onnxruntime 跑一遍和 PyTorch 相同的输入对比输出差异超过 1e-3 就说明预处理有问题。5. 把工程车辆检测推到可用跨场景验证与难例挖掘的实操技巧模型在验证集上跑出好看的数字只是第一步真正决定能不能上线的是跨场景表现。我一般会做两件事跨场景验证和难例挖掘。跨场景验证的做法是另外找一段和训练集不同摄像头、不同光照的视频抽帧后人工标 100~200 张作为测试集。这个测试集不参与任何训练和调参只在最终评估时用。如果 mAP 比验证集掉超过 15 个点说明模型过拟合到训练场景需要补充多样化数据或做更强的数据增强。难例挖掘更直接用训好的模型跑一遍未标注的现场视频把置信度在 0.3~0.6 之间的检测框导出来人工复核。这些框要么是模型不确定的正样本要么是背景误检。把正样本补进训练集把误检作为负样本加入迭代两三轮mAP 通常能涨 5~10 个点。下面是一个导出难例的脚本片段from ultralytics import YOLO import cv2 model YOLO(eng_vehicle_runs/baseline/weights/best.pt) # 对视频抽帧推理保存中等置信度结果 cap cv2.VideoCapture(site_video.mp4) frame_idx 0 while cap.isOpened(): ret, frame cap.read() if not ret: break if frame_idx % 30 0: # 每秒抽一帧 results model(frame, conf0.3, iou0.5) for box in results[0].boxes: conf float(box.conf) if 0.3 conf 0.6: # 保存该帧和框信息供人工复核 cv2.imwrite(fhard_examples/frame_{frame_idx}.jpg, frame) break frame_idx 1 cap.release()参数说明conf0.3是低阈值确保不漏掉模型犹豫的框iou0.5是 NMS 阈值工程车辆重叠不多0.5 够用抽帧间隔按视频帧率调整25fps 视频每 30 帧抽一张差不多。导出的图片人工过一遍正样本补标注误检直接作为背景图加入训练集。还有一个技巧是测试时增强TTA。在推理时对同一张图做水平翻转、多尺度缩放把结果融合通常能涨 1~3 个点 mAP代价是推理速度慢 3 倍。如果业务对延迟不敏感比如离线分析场景TTA 值得开。Ultralytics 里直接model.predict(source, augmentTrue)就能启用。最后说一个我自己的习惯每次训完模型不管指标多好我都会拿工地现场的视频跑一遍用肉眼过 5 分钟。指标是给论文看的肉眼过视频才是给上线用的。很多问题——比如把黄色挖掘机认成校车、把静止的压路机漏掉——混淆矩阵里看不出来但视频里一眼就能发现。希望帮到你。本文还有配套的精品资源点击获取