YOLO车辆行人识别数据集从采集到部署全流程详解

简介本资源是面向计算机视觉初学者与YOLO目标检测实践者的车辆行人识别数据集专为训练和验证轻量级检测模型设计适用于智能交通、安防监控等场景下的双类别person/car检测任务。压缩包共16822个文件包含5607张JPG图像、5608个YOLO格式txt标签及5607个PASCAL VOC格式XML标签两类标注互为补充便于适配不同训练框架整体体积499.54MB结构清晰图像与标签严格一一对应。已有3695人学习下载体现了其在入门实践中的广泛认可度。用户可直接用于YOLOv5/v8等主流版本的端到端训练配套博文还展示了典型检测效果与数据加载流程节省数据清洗与格式转换时间显著降低算法落地门槛。 做车辆行人检测这几年有一个感受特别深很多人拿着YOLO开源权重直接跑觉得效果差不多就完事了。可真到了自己要训一个能用的模型才发现数据集才是决定模型上限的那块短板。公开的COCO、VOC虽然覆盖面广但车辆行人在里面的类别划分、场景分布、遮挡情况跟实际项目需求往往对不上。所以YOLO车辆行人识别数据集这类项目才会反复被提出来——它不是简单地把图片喂进去跑一个训练脚本而是从数据采集、标注规范、模型选型到训练调参、落地上线的完整链路。这篇就把我做这套数据集的全部过程掰开揉碎讲清楚包括踩过的坑和最终沉淀下来的方法论。1. 车辆行人识别数据集的真实需求与边界1.1 这个数据集解决的是哪一类问题先说清楚车辆行人识别在目标检测里属于一个非常典型的细分场景。它不像通用检测那样什么都要认核心对象基本就两类车和人。但就两类恰恰是难点所在——类别越少模型对类内差异的敏感度要求越高。行人里有骑车人、推婴儿车的、打伞的、穿玩偶服的车辆里有轿车、卡车、公交车、三轮车甚至工程机械。如果数据集的覆盖度不够模型很容易出现这个人是人但没框出来或者把路牌后面的人影当成人这种低级错误。我做这个项目时第一步不是急着找数据而是先定义了数据集的用途边界。这里有个关键判断车辆行人识别数据集到底是给智能交通监控用的还是给辅助驾驶用的还是给智慧园区车辆管理用的不同场景下的数据要求天差地别。监控场景的摄像头角度高、视场固定行人尺度小遮挡频发车载场景的视角低、运动模糊明显光照变化剧烈园区车闸场景则相对简单车辆朝向固定、背景单一。这个定位决定了后面所有工作尤其是负样本和困难样本的占比设计。1.2 公开数据集与自建数据集的取舍逻辑但凡做这个方向绕不开的就是要不要用公开数据集。我的建议是公开数据集一定要用但不能直接拿来当训练主力原因有三个。第一公开数据集的标注风格跟你的业务需求不一定一致。比如COCO把person作为一个大类但它的person标注里包含了大量只有上半身或者严重遮挡的行人VOC的person类别则偏向常规全身行人。如果你要做车闸场景模型会用COCO的行人标准去学习结果就是它认为只要露个头就算行人导致误检率飙升。第二公开数据集的场景分布不一定覆盖你的部署环境。国内的城市道路、高速公路、乡村道路车辆类型和行人行为特征跟国外数据集差异非常大。电瓶车、三轮农用车、人力板车这些在国内道路上极其常见的交通工具在COCO、VOC里几乎是空白。第三公开数据集的类别体系在你眼里是过拟合的。它们把车辆拆成了car、truck、bus、motorcycle等一堆子类但很多实际项目只需要一个vehicle大类。这种粒度差异会导致训练资源的浪费也会让模型在某些细分小类上因为样本不足而表现不稳定。所以我的最终策略是以自建数据为底座用公开数据集做预热和增强。自建数据保证业务场景覆盖度公开数据提供背景多样性和模态多样性。2. 数据采集与清洗决定模型上限的隐形工程2.1 从零开始攒数据来源渠道与耗时评估数据采集是最磨人的一个环节没有捷径。我核心用了四个渠道自己的摄像头点位实拍、合作方提供的脱敏监控片段、公开数据集筛选抽取、网络爬取补充。自己实拍是性价比最高的方式因为只有你知道目标场景长什么样。我在做交通路口场景时直接找了几个不同朝向的摄像头机位连续录制了不同时段的路口视频然后按帧抽图。抽帧有个经验值每秒1-2帧就够不要贪多。相邻帧之间的目标位移太小标注出来全是高度相似的样本对模型泛化能力几乎没帮助反而把数据集撑得虚胖。爬虫补充需要注意合规问题尽量选择开放许可的图片源而且爬下来之后必须做一轮人工审核把广告图、插画图、动画图全部过滤掉。我有一次偷懒没细筛结果训练集里混进了两张卡通风格的警车图片模型在某个测试片段上就出现了把蓝色出租车当警车的误判——数据里的一点点杂质最后都会在线上以奇怪的方式暴露出来。整个数据采集阶段耗时约三周最终收集到原始图片约6万张这个数量级对于两类检测任务来说已经够用了后面关键靠清洗和标注质量拉效果。2.2 数据清洗的两道筛子规则筛与人工筛6万张原始图片如果直接进标注那就是灾难。我做了两轮清洗。第一轮用脚本按规则自动筛。主要看三个指标图像分辨率、清晰度拉普拉斯方差、重复度感知哈希。把小于640x640的、模糊到人眼都看不清的、以及跟已有图片哈希距离过近的统统剔除。这里注意一个细节分辨率筛选不能一刀切。有些低分辨率的老监控画面虽然清晰度一般但恰好就是你线上要处理的真实输入这类丑数据反而要留一部分否则训练集和推理环境的数据分布就不一致了。第二轮是人工粗筛按场景分组快速浏览。我按城市道路-白天、城市道路-夜晚、高速-白天、高速-夜晚、乡村道路、园区停车场、恶劣天气分了七个组每组抽样检查把那些画面里目标过多导致标注根本做不完的、镜头带强水印遮挡目标的、多路拼接全景图这类不适合训练的直接删掉。两轮清洗下来原始数据损耗率大概在20%左右最终剩了约4.8万张进入标注阶段。2.3 类别定义与困难样本的比例设计这个阶段要确定标注的类别体系。我最终定的是三个类别person、car、truck。没有单独设bus和motorcycle因为这两个类别在业务里归入了vehicle大类而细分的话样本量又撑不住。这里给新手一个建议如果类别样本量不足以支撑训练宁可合并不要硬拆。合并类别只是损失粒度样本不足会让模型在这个类别上整体摆烂。困难样本的比例是数据质量的关键。我从清洗后的图片里专门挑出了大约8000张作为困难样本集包括强遮挡人被树挡一半、车被栏杆挡住、小目标远距离行人只有20个像素高、极端光照逆光、夜间只开近光灯、恶劣天气雨天玻璃反光、雾天轮廓模糊这几类。训练时困难样本占整个训练集的比例控制在15%-20%比较合适。低于10%模型在corner case上基本没招架之力高于25%会让模型过度关注细节反而在常规样本上变得畏手畏脚。3. 标注规范与质量管控数据集的宪法3.1 标注工具的选型与团队协同标注工具我对比过LabelImg、LabelMe、X-AnyLabeling和开源的CVAT。个人单干用X-AnyLabeling最舒服因为它自带YOLO预标注模型可以先让模型自动生成一批框人工只负责修正边界和补充漏检效率至少提升3倍。如果是团队协作直接上CVAT它在任务分配、多人审校、标注冲突处理上成熟得多。我自己是混合模式先用X-AnyLabeling做预标注导出后再用内部脚本转成CVAT格式做人工抽检。这里有个血泪教训标注工具的导出格式五花八门一定要在项目一开始就统一好标注规范文档规定清楚什么情况必须标、什么情况不标、什么情况可以标为忽略。否则每个人按自己的理解标最后数据集的标注一致性就没法看了。3.2 标注规则里的关键决策点对于一个两三类别的检测数据集标注规则主要卡在这几个地方。遮挡怎么处理我的规则是目标可见部分超过50%就标完整框框要包含被遮挡部分的预测位置30%-50%标完整框并标记为occluded低于30%不标除非这个目标在业务上极其关键比如车闸附近的行人。完整框的预测位置是标注员主观判断的所以一定要在培训阶段给出大量的边界案例统一判断口径。小目标标不标这是一个容易被忽略的坑。很多标注员习惯性地忽略很小的目标觉得这么小标了也没用。但小目标恰恰是实际推理时的重灾区。我的规则是只要人眼能确定类别无论尺寸多小都要标。一条路上五十米外的行人在1080P画面里可能只有15x30像素也必须框出来。边界框贴边程度车辆行人框不要贴得太紧也不要放太松。我统一的做法是框要紧贴目标的可见轮廓留2-3像素的呼吸空间。太紧会剪切掉目标的边缘特征太松会把背景学进目标特征里。另外车窗玻璃这类透明区域框就按车身整体轮廓走不要试图钻进去框座椅。3.3 标注质量的量化验收方法标注完成不代表数据能用我会做三层验收。第一层是脚本检查跑规则框是否超出图像边界、宽高是否为非法值、类别是否在指定集合内、是否出现空标注文件。这一步能筛掉80%的低级错误。第二层是人工抽检抽检率不低于10%。抽检时重点看之前定的规则是否被执行到位小目标有没有漏标、遮挡目标有没有标注越界、类别是否混淆比如把三轮车标成car把骑电动车的人只标了person没标vehicle。第三层是试跑排查。我会用清洗后数据先训练一个快速版YOLO只训练30个epoch把训练集的预测结果可视化出来找那些预测框跟标注框差异极大的样本。这些往往是标注边界模糊的地方拿回来二次修正。这三层做完标注数据的可靠性才算基本有底。最后统计下来标注修正率在12%左右其中一半以上是漏标小目标。4. YOLO模型选型与训练配置的实战经验4.1 版本选型为什么是YOLOv8而不是其他YOLO版本迭代令人眼花缭乱从v5到v8到v11甚至v12我的经验判断很直接看稳定生态、看任务适配、看部署成本。我选YOLOv8有三个理由。第一Ultralytics的代码库维护非常活跃文档和社区案例丰富遇到问题几乎都能搜到解决方案。第二YOLOv8在训练逻辑上做了很多工程化封装——自动锚框、自动数据增强、余弦退火调度器都是默认选项开箱即用很适合数据工程向的项目。第三它的检测头设计在中小目标上的表现比v5有可见提升而车辆行人场景恰恰充满中小目标。YOLOv9和v10在部分榜单上指标更漂亮但它们的改进点更多集中在训练效率和结构设计上对部署环节的推理框架支持不如v8成熟。YOLOv11虽然也上来了但我当时评估时它的配套生态还不够厚而且C2fA模块的设计更偏向小模型场景于是没选。简单说项目追求的是稳定可用不是刷榜好看。4.2 数据集划分与目录组织数据集划分比例我用了8:1:1也就是38400张训练、4800张验证、4800张测试。一定要按视频片段而不是单张图片来划分。相邻帧内容高度相似如果同一个视频的帧同时出现在训练集和验证集里验证集指标会很假因为模型相当于见过这些图像了。我都是按视频文件名做分组切分保证同源视频的帧全部进同一个集合。目录结构就直接按YOLO格式来dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ ├── data.yaml └── classes.txtdata.yaml里写清楚路径和类别名path: /path/to/dataset train: images/train val: images/val test: images/test names: 0: person 1: car 2: truck4.3 训练参数详解从预训练权重到数据增强训练配置是整个环节里最值得花时间精调的部分。我在YOLOv8上最终的训练命令长这样yolo detect train \ --model yolov8m.pt \ --data dataset/data.yaml \ --epochs 150 \ --batch 32 \ --imgsz 1280 \ --optimizer SGD \ --lr0 0.01 \ --lrf 0.01 \ --momentum 0.937 \ --weight_decay 0.0005 \ --warmup_epochs 3 \ --mosaic 1.0 \ --mixup 0.1 \ --close_mosaic 5 \ --patience 30 \ --device 0,1几个核心参数我展开说一下。imgsz 1280这个是我做了多轮对比后确认的。车辆行人场景里有大量中小目标输入尺寸如果只给640很多20像素以下的人和小车特征会被压缩到几乎看不见。用1280训练mAP50能提升约3-4个点代价是训练时间几乎翻倍。如果你的算力吃紧退而求其次用960也凑合但千万不要在640上直接开训不然前面的数据工程基本白做。预训练权重用yolov8m.pt而不是从零训练。原因是车辆和行人这类通用目标在COCO预训练权重里已经有很好的底层特征我们自己的数据只需要在之上做领域适配。从零训练不仅慢而且在小数据集上很容易过拟合。m这个尺寸是精度和速度的平衡点s偏弱、l偏重我最终选了m。数据增强参数mosaic设为1.0mixup设为0.1。mosaic拼图增强对中小目标尤其有用它会把四张图拼在一起相当于被迫在更小的尺度上识别目标。但mosaic也会让标注框偏离真实目标位置所以我把close_mosaic设为5即最后5个epoch关闭mosaic让模型在正常分布上做收尾微调。warmup_epochs 3学习率预热。刚起步时模型权重还很乱直接用大学习率容易把预训练学到的特征冲掉。前3个epoch让学习率从0逐步升到目标值后面再交给余弦退火慢慢降。patience 30早停策略。如果连续30个epoch验证集指标没有提升训练自动终止。我实际训练时大约到120个epoch就停了。4.4 训练过程中的监控指标解读训练过程中不要只盯mAP这几个指标都要看。Box Loss和Cls Loss这两个loss在训练集和验证集上的差距如果越拉越大说明过拟合开始出现。车辆行人数据集因为场景集中过拟合的风险比通用数据集高得多。Recall对车辆行人场景Recall比Precision要优先保证。漏检一个行人或者一辆车在安防场景里可能直接是安全事故。我训练时的策略是如果最终模型的Recall明显低于Precision就把置信度阈值线下调宁可多框几个虚警也不要漏掉真目标。每类别的mAP只看总体mAP会把问题掩盖掉。我见过模型总体mAP一直在涨但truck类别的mAP50始终只有0.5左右——原因是truck在数据集里的占比太低。后来我专门去补了一批truck样本情况才有改善。类别不平衡不会因为总体mAP提升而自动解决。5. 模型评估与部署落地的实测数据5.1 测试集上的最终指标与坏例分析150个epoch跑完模型在测试集上的最终指标如下类别mAP50mAP50-95PrecisionRecallperson0.8720.5830.8810.843car0.9030.6240.9150.889truck0.7810.4920.8260.745全部0.8520.5660.8740.826truck的指标明显偏弱这在我预料内。分析坏例后发现了三个典型问题第一truck和bus的混淆。数据集里有几类箱式货车外观跟公交车非常接近模型经常把长头厢式货车误判成car或者反过来。这个本质上是类间特征重叠解决方法是增加这两种形态的对比样本。第二夜间场景的person漏检。夜间的行人对比度低且行人经常和路灯杆、广告牌等竖长物体混在一起。我发现模型在夜间会把某些行人漏掉但把路灯杆误检成人的情况反而不多。第三雨天镜头的玻璃反光把车体轮廓切成几段模型有时会在一辆车上输出两个框。这是经典的检测框分裂问题跟NMS参数有关。我把NMS的iou阈值从默认的0.7调到了0.6之后这个问题改善了不少。5.2 从PyTorch权重到实际部署的转换过程训练得到的是.pt权重但实际部署通常要导出为其他格式。我这边有两条部署路径。服务端走TensorRT导出命令yolo export modelruns/detect/train/weights/best.pt formatengine device0 dynamicTrue imgsz1280导出之后用TensorRT推理时有个要注意的地方TensorRT会做层融合和精度校准FP16精度下mAP会掉0.5-1个点但这个损失通过稍微调低置信度阈值就能补回来。动态shape可以支持不同分辨率输入但实际部署时为避免显存抖动我建议固定成1280x1280输入在送入模型前做letterbox缩放。边缘端如果跑的是瑞芯微RK3588这类芯片则需要先转ONNX再转RKNN格式。这个过程中最容易出问题的地方是自定义算子的兼容性YOLOv8本身的结构比较标准算子都能映射上但CPU和NPU之间的耗时分配需要做一下profiling否则整个推理pipeline会阻塞在某个预处理节点上。5.3 端到端推理耗时实测部署完成后我做了完整压测。所用设备是单张NVIDIA GeForce RTX 3060Ampere架构12GB显存输入视频流分辨率1920x1080帧率25fps。环节耗时解码3-5ms预处理缩放归一化2-3msTensorRT推理7-9ms后处理NMS1-2ms总计约15ms这个延迟水平可以支撑约60fps的实时检测对于道路监控、车闸识别这类场景完全够用。如果要跑到边缘设备上视芯片算力不同推理耗时大概在30-80ms之间也基本能保证实时性。6. 数据集的迭代机制让模型越用越懂业务6.1 半自动标注用旧模型产新数据做了一版模型之后再扩充数据集就不需要纯人工了。我搭建了一条半自动数据回流pipeline把新采集的未标注视频送进当前模型做预测置信度高于0.9的预测结果可以直接作为伪标签进入候选集置信度在0.5-0.9之间的进入人工复核队列低于0.5的交给标注员单独处理。这套流程跑下来标注员只处理约40%的数据其余60%都半自动消化了。而且因为伪标签来自一个已经在业务数据上微调过的模型标注的标准跟原来的数据集高度一致。数据集的迭代速度从每周几千张直接提到了每天几千张。6.2 数据集的版本管理数据集和代码一样需要版本管理。我整个项目的目录是分布式的每批次新增数据都会记录以下元信息batch_id: batch_009 source: 城市路口03号相机 time_range: 2025-07-01 至 2025-07-07 weather: 晴/多云/午后雷阵雨 img_count: 1240 annotation_count: 5123 quality_check_pass_rate: 96.7% added_to_train: true每一版模型训练前都会记录使用的数据集版本这样模型出了问题可以精确回溯到是哪个批次的数据导致的。我在项目里遇到过模型突然对红色车辆误检率升高一查才发现是上一个批次的雨夜样本里红色车占比过高比例失衡导致模型产生了颜色偏好。有了版本管理这类问题五分钟就能定位。6.3 部署后的持续反馈闭环最后一个环节容易被忽略就是线上反馈怎么回流到数据集。我在推理服务的代码里加了一个记录模块所有置信度低于0.9的检测结果把裁剪图保存下来按周汇总后人工抽样看。每周大概会积累几百张低置信度样本人工筛选后把其中的真实目标补标进数据集。同时线上出现的用户投诉漏检事件必须当天追溯——把对应时间段的原始视频拉出来重新跑模型确认是模型问题还是阈值问题再决定是调整阈值还是补数据重训。这套闭环跑起来之后模型才算真正长在了业务上。每次重训完验证集和测试集指标可能都只微涨零点几个点但线上真实漏检率是在持续下降的。数据驱动的价值就体现在这里。7. 写在最后几个值得反复强调的实战教训整套流程走完有几条经验我认为比任何具体参数都值得记住。第一个是关于数据量的迷信。不要一开始就追求几十万张图片。对车辆行人这个特定场景来说如果场景集中两三万张高质量标注数据就足够训练出一个可用的模型了。关键在于困难样本的占比和标注的规范性而不是单纯堆数量。第二个是训练和业务要在一起思考。我在项目初期就定下了数据集要覆盖哪些场景、模型要服务于哪些需求的基调所以训练过程中遇到的大多数问题都能在数据侧找到答案。如果你上来先把数据集搞了再想模型要干嘛那你多半要返工。第三个是不要忽视半监督和自监督的潜力。用旧模型做伪标注再人工复核这套流程虽然看起来简单但它带来的效率提升是量级的。特别是在业务已经跑起来之后数据回流机制就是模型的生长激素。第四个是保存中间产物。无论是清洗前的原图、清洗脚本、标注规范文档还是每个批次的验收报告全部归档保存。项目做到后面你会发现最值钱的不是那套最终权重而是从原始数据到可用数据集的整个工程链路。这套链路才让你的模型具备快速迭代的能力。做数据集的过程确实枯燥清洗、标注、检查、再清洗周而复始。但当你看到模型在自己定义的数据上训练出来第一次在真实视频流里稳稳框住每一个人和每一辆车的时候前面那些磨人的时间都会觉得值得。本文还有配套的精品资源点击获取