尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

车辆检测数据集构建与YOLO训练实战全流程指南

车辆检测数据集构建与YOLO训练实战全流程指南 简介目标检测是计算机视觉的核心任务之一其落地效果高度依赖训练数据的质量与匹配度。以车辆检测为例公开数据集虽多但视角、场景与真实业务需求往往存在偏差导致模型部署后漏检频发。YOLO系列作为工业界主流检测框架凭借实时性与精度平衡成为车辆检测的理想选择。构建高质量车辆检测数据集需系统规划数据采集策略、标注规范、清洗流程与增强方案并结合预训练权重进行微调训练。通过科学的评估指标与阈值调节可有效平衡误检与漏检。本文从数据工程与模型训练的双重视角完整解析车辆检测数据集的设计思路与YOLO实操流程覆盖从场景分析、标注实施到部署迭代的全链路为实际项目提供可落地的工程参考。 当年我第一次拿YOLO跑车辆检测的时候心里想得特别简单数据集不就直接下载现成的模型训练一下不就完事了吗结果真上手才发现事情远没有那么顺利。下载一个公开数据集类别是对上了但场景和我的需求完全不匹配——我要检测的是停车场俯视视角下的车辆公开数据集里全是行车记录仪的正前方视角模型训练出来一测漏检率惨不忍睹。后来我又尝试自己采集数据又掉进标注规范不统一的坑前前后后折腾了快一个月才把一套能用的车辆检测数据集流程给跑通。这篇内容就是把我踩过的坑、验证过的方案、以及一套可以落到实处的操作流程完整整理出来。无论你是刚接触目标检测的学生还是要在实际项目里做车辆检测的工程师只要你打算用YOLO系列模型训练自己的车辆检测模型这篇文章都能帮你少走不少弯路。文章会覆盖数据采集策略、标注规范、预处理和增强、训练参数调整、效果评估以及我实际遇到的典型问题。其中很多细节是常规文档里不会写的属于“不试不知道一试吓一跳”的类型。1. 车辆检测数据集的整体设计思路1.1 先搞清楚你的检测场景再决定数据从哪来做车辆检测数据集最忌讳的就是上来就到处找数据。你首先要问自己三个问题我要检测什么视角的车我的摄像头装在哪里我最终要在什么设备上跑模型这三个问题直接决定了你需要什么样的数据。举个例子如果你做的是路边违章停车检测摄像头通常是高点俯视车辆在画面里大多是车顶视角这时候你去用行车记录仪的前视角数据集训练出来的模型一到实际场景就废了。反过来如果你是做辅助驾驶的前方碰撞预警那就需要大量前视角、近距离的车辆数据。我自己的项目是做一个园区内部的车辆统计系统摄像头架在入口和道路上方视角是斜向下45度左右。最开始偷懒直接用公开数据集结果实际测试时检测精度不到60%。后来自己采集了两周的监控画面重新标注训练精度直接拉到了90%以上。所以数据集的场景匹配度远比数据量重要。另一个要提前想清楚的问题是你只需要“车”这一个类别还是需要细分多种车辆类型常见的有car、bus、truck、motorbike、bicycle这几种。类别定义得越细数据标注成本越高训练难度也越大。如果你是做车流量统计这种粗粒度应用建议先只分2到3个大类就够了。类别越多类别间相似性带来的误检就越难处理比如卡车和公交车在某些角度下非常像。1.2 公开数据集和自采数据的搭配策略业内开源数据集其实不少我这里列几个我用过的、适合车辆检测的数据集特点适用场景注意事项BDD100K10万张行车视角路况丰富自动驾驶、行车记录仪视角标注类别多需筛选车辆相关类别UA-DETRAC2万多张监控视角车辆为主交通监控、车流量统计标注质量较高但场景偏向固定摄像头Cityscapes街景为主有车辆标注城市道路场景主要是分割标注转换为检测框需要额外处理VisDrone无人机视角车辆密集无人机巡检、俯视检测小目标居多训练难度大自采数据完全匹配你的场景任意定制场景需要自己标注成本高但效果最可靠我的经验是不要二选一要两者结合。先用公开数据集做预训练或作为基础数据再叠加自采数据做微调。这样既能减少标注工作量又能保证场景匹配度。实操中我用过一个比例供参考公开数据占40%自采数据占60%。公开数据负责提供车辆外观的多样性自采数据负责提供你的目标场景特征。关于数据量经常有人问“我要标多少张才够”。说实话没有一个绝对的数字要看场景复杂度和模型基础。但有个大概经验值如果从头训练一个YOLOv8模型建议至少20000张以上的有效车辆样本如果只是用预训练权重微调2000到5000张就能看到不错的效果。我们项目用的车辆检测模型是拿大约3000张自采数据加5000张公开数据在预训练权重上微调的效果已经能满足业务需求。1.3 为什么选YOLO系列而不是其他检测模型车辆检测用YOLO系列现在已经算是工业界的默认选择了。原因无非这几点速度快可以实时跑精度不错在同等速度下属于第一梯队生态成熟从YOLOv5到YOLOv8网上教程多、部署方案全。具体选哪个版本我的建议是看你的部署环境。如果要在嵌入式设备比如Jetson Nano、树莓派上跑YOLOv5s或者YOLOv8n这种轻量版本比较合适。如果算力充足比如服务器上用GPU推理YOLOv8m甚至YOLOv8l都能获得更高的精度。我自己目前在用的主力是YOLOv8m在推理速度和精度之间算是比较平衡的。另外提一个新一点的趋势就是YOLO系列现在也有了实例分割的能力比如YOLOv8-seg。如果你的场景对车辆的轮廓边界有要求比如要做车位占用判断、车辆遮挡分析可以试试分割模型。但注意分割标注成本远高于检测框标注前期投入会大很多。常规的车辆计数、轨迹跟踪、违章检测用检测框就足够了。2. 数据采集与标注的实操要点2.1 自采数据的采集方案与注意事项如果你决定自己采集一些数据我建议按下面这套流程来。先解决素材来源。最常见的三种方式一是用现成的监控录像导出画面二是用手机或相机固定机位拍摄三是从网上找符合条件的视频素材通过抽帧得到图片。无论哪种方式都注意两点画面分辨率要尽量接近实际使用场景的分辨率画面里要覆盖不同时段、不同天气、不同车流密度。以我当时做园区车辆统计为例采集周期大概是两周。我会从每天的监控录像里抽帧每个小时抽5到10帧避免同一辆车在连续帧里反复出现太多相似样本。两周下来大概积累了8000多张原始图片人工筛选一轮除掉模糊、过曝、重复度过高的图片剩下大概5000张进入标注环节。这里有个容易忽视的环节画面多样性。很多人自采数据容易采着采着就趋同了比如全是在晴天白天拍的。一定要刻意去覆盖阴天、傍晚、雨天、夜间开灯场景否则模型在光线变化时的鲁棒性会非常差。我后来在夜间测试时发现漏检率显著上升回头检查数据才发现夜间样本只占不到5%补充夜间数据后问题才缓解。还有一个采集细节不要只拍车辆稀疏的画面尽量把车辆密集、相互遮挡的复杂场景也采集进来这对模型处理遮挡情况非常重要。只靠稀疏车辆数据训练出来的模型一到高峰期画面里车多的时候漏检、误检全来了。2.2 标注规范最容易埋雷的环节标注在整条链路里看起来最没技术含量其实恰恰是最容易出问题、又最影响最终模型效果的一环。我第一次做标注就没定规则三个人各标各的结果训练出来的模型效果稀碎后来逐张排查才发现同一个目标有的框到车灯、有的框到整个车身、有的连后视镜也算进去了。从此我学乖了每次标注前先制定一份明确的标注规范文档并保证所有标注人员参照同一标准来标。一份车辆检测标注规范至少要包含以下内容类别定义每种类别的准确定义。比如car指的是轿车、SUV、MPV等乘用车bus指的是公交车、班车truck指的是货车、卡车。遇到皮卡这种容易混淆的要明确归到哪一类。框选范围检测框必须包含车辆完整主体包括突出的后视镜和保险杠。车辆被遮挡时框要用车辆的完整轮廓来框不能只框住可见部分。极端情况处理车辆极小比如远处的一辆车时是否标注车辆大面积被遮挡时是否标注夜间灯光过曝看不清车身时是否标注帧间同一辆车是否每帧都要标。这些情况必须提前定好规则。边界处理目标有一部分在画面外时检测框可以超出画面边界但前提是画面内可见部分能清晰判断出车辆类型。我用过几款标注工具比较推荐的有LabelImg、LabelStudio和X-AnyLabeling。LabelImg是老牌工具轻量简单适合小规模标注LabelStudio支持标注任务多人协作管理适合团队标注X-AnyLabeling支持辅助标注可以用预训练模型自动打框再人工修正效率能提升不少。标注效率这块手动标注一辆车平均需要2到5秒一张图如果有10辆车大约要半分钟到一分钟。5000张图一个人标大概需要40到60小时的工作量所以如果时间紧建议多找几个人分工或者用辅助标注工具先自动预测再人工订正。2.3 标注质量检查比标注本身更重要标注完成后不要急着训练先做一轮质量抽检。我一般会从每类数据里随机抽10%到20%的图片手动快速浏览一遍重点看以下几类问题有没有漏标画面里明显完好的车辆却没有框有没有错标框里根本不是车辆或者类别标错了有没有框过大或过小检测框没有贴合车身误差超过车身面积的10%有没有重复标注同一个目标被标注两次。排查完之后还有一个小技巧用已训练好的模型先测一遍把置信度低且没有匹配到标注框的预测结果挑出来人工检查。这些通常就是漏标的高发区域用这种方式来补漏的效率比人工纯翻看高很多。我遇到过最坑的一次是合作方标注的数据里把画面中一张巨大的宣传海报上的车也算进去了。模型训练出来后一看到墙上类似形状的海报就狂报车辆排查了很久才找到根源。标注数据里混入错误样本对模型的影响是隐性的且非常难查所以质量检查阶段多花的时间后期都会加倍省回来。3. 数据预处理与数据集划分3.1 格式转换与目录结构采集和标注完成之后下一步是把标注数据转换成YOLO需要的格式。YOLO格式的标注是一个txt文件每行对应一个目标格式是类别id、中心点x坐标、中心点y坐标、宽度w、高度h。注意这些数值全部是相对于图片宽度和高度的归一化值范围在0到1之间。如果你用的是LabelImg直接选择YOLO格式输出就行。如果标注时用的是Pascal VOC格式或者COCO格式需要做一个转换。这里给一段我常用的转换脚本把VOC格式转成YOLO格式import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_file, class_names, output_dir): tree ET.parse(xml_file) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) txt_name os.path.basename(xml_file).replace(.xml, .txt) out_path os.path.join(output_dir, txt_name) with open(out_path, w, encodingutf-8) as f: for obj in root.iter(object): cls obj.find(name).text if cls not in class_names: continue cls_id class_names.index(cls) box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) cx (x1 x2) / 2.0 / img_w cy (y1 y2) / 2.0 / img_h w (x2 - x1) / img_w h (y2 - y1) / img_h f.write(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}\n) class_names [car, bus, truck]转换完之后建议按下面的目录结构来组织数据集这是YOLO系列通用的一种结构datasets/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamldata.yaml文件内容大致是这样的train: datasets/images/train val: datasets/images/val test: datasets/images/test nc: 3 names: [car, bus, truck]3.2 数据清洗该删就删不要恋战训练前一定要做一轮数据清洗把不适合训练的样本剔除出去。我通常按以下优先级排查首先删除严重模糊的图片。运动模糊、失焦、分辨率极低导致人眼都无法辨认车辆的图片直接删。模型从这种图里学不到有用的特征只会增加训练噪声。其次删除标注明显错误的图片。比如框和车辆完全不贴合、类别标错、出现重复框的如果在质量检查阶段没处理完这时候可以趁最后的机会删掉或重新标注。再次删除过度相似的重复图片。连续帧抽帧产生的图片往往高度相似如果大量保留会导致训练集里某些场景被过度表示产生过拟合。一般做法是计算相似度或者直接隔帧抽稀确保训练集里同一辆车、同一角度的图不超过几十张。最后还要检查图片与标注是否一一对应。图片存在但标注缺失、标注存在但图片缺失、图片尺寸和标注尺寸不匹配这些低级错误会直接导致训练中断或者loss异常务必用脚本提前校验一遍。我吃过一次亏图片和标注文件的文件名后缀不一致——图片是.png标注txt却用了和图片同名但大小写不同的前缀跑训练时一直报错找不到对应标注检查了半天才发现是命名规范不统一。建议所有标注文件和图片文件名完全一致只保留后缀不同。3.3 数据增强与类别平衡车辆检测数据集的类别不均衡问题非常常见尤其是自采数据里可能car占了90%bus只占3%。如果不处理模型会对car过拟合对bus的召回率很低。处理类别不平衡有几个常用手段我列一下实际效果过采样少数类把bus和truck的图片复制几份加入训练集简单有效但容易过拟合欠采样多数类从car里抽稀一些样本适合car样本量很大的情况针对少数类做增强对包含bus、truck的图片做更强的数据增强增加它们的训练权重调整loss权重有些训练框架支持按类别设置loss权重少数类的loss加大多数类的loss减小。除了类别平衡数据增强也很重要。YOLOv8自带了一系列增强策略比如mosaic、mixup、随机翻转、颜色抖动、缩放旋转等通常默认配置就能用。但要注意增强不是越强越好过强的增强会让模型学到的特征偏离真实分布。我的调法是在预处理里开启mosaic和mixup概率设到0.5到0.8颜色抖动适度降低因为过曝、过暗的极端颜色变化在真实监控场景中不一定常见。关于数据集划分我推荐train:val:test按8:1:1或者7:2:1来切。注意划分前要按场景分布来打散不能让所有夜间数据都跑到了测试集里否则验证指标会严重失真。分割的时候按整个视频片段作为基本单位划分而不是按单帧随机分否则同一段连续帧会同时出现在训练集和测试集里造成数据泄漏指标虚高。4. YOLO训练与评估的全流程记录4.1 环境准备与训练配置YOLO训练环境没有太多玄学核心就是PyTorch加对应的YOLO库。我自己用的YOLOv8通过ultralytics这个包来训练安装命令很简单pip install ultralytics如果要用GPU训练提前装好和你的显卡匹配的CUDA版本这里有个小经验不要追新PyTorch官方推荐什么版本就用什么版本能避免大量编译和报错问题。没有GPU的话用CPU也能训练只是慢很多一个小数据集可能要跑十几个小时建议还是想办法搞一块GPU哪怕是云服务器也行。训练之前检查一下显卡显存和batch size的关系。显存不够时要么调小batch size要么降低图片分辨率。YOLOv8默认输入分辨率是640x640如果显存吃紧可以降到512甚至416。但要注意最终部署时用的推理分辨率要尽量和训练分辨率一致差别太大精度会打折扣。我的经验是训和推都固定640x640虽然训练慢一些但效果最稳。我常用的一套训练命令是这样的yolo detect train datadatasets/data.yaml modelyolov8m.pt epochs100 batch16 imgsz640 device0 patience20这里的参数说明一下epochs是训练轮数100轮对一个中等规模数据集来说基本够用batch是批次大小根据显存调整device0表示用第一块GPUpatience是早停参数连续20轮验证集指标没有提升就自动停止可以节省大量时间。如果你是从零开始训练把model参数换成yolov8m.yaml而不是yolov8m.pt。但绝大多数场景我都建议加载预训练权重微调因为预训练模型已经在COCO等大规模数据集上学到了丰富的通用特征微调不仅收敛更快精度也更高尤其在自采数据量不足时效果差异非常明显。4.2 训练过程中的关键观察点训练启动后不要只是刷手机等结束。我一般会盯着几个指标看任何一个出现异常都值得停下来排查。第一看loss曲线的下降趋势。正常情况是训练loss和验证loss同步稳步下降最后趋于平缓。如果训练loss下降但验证loss不降反升说明过拟合了需要增强数据、加正则化或者减少训练轮数。如果两个loss都在震荡不降可能是学习率设置不合理或数据本身有问题。第二看验证集的mAP50和mAP50-95。mAP50是指IoU阈值0.5时的平均精度mAP50-95是多个IoU阈值的平均后者更严格也更反映真实检测精度。一般来说一个效果可用的车辆检测模型mAP50应该到90%以上mAP50-95至少到70%。第三看PR曲线和置信度曲线。训练完成后会生成一系列图表其中PR曲线如果右下角出现明显凹陷说明某些类别的召回率存在问题。置信度曲线能帮你看清楚一个很现实的问题阈值调多高合适这直接影响线上误检率和漏检率的平衡。训练结束后还有一个容易被忽视的习惯先把best.pt和last.pt都保留下来。best.pt是验证集上表现最好的权重last.pt是最后一轮的权重。两者偶尔会有明显差异我一般都会在两个权重上都跑一遍测试集选实际效果更好的那个。4.3 模型评估与关键指标解读训练完之后在测试集上做最终评估这一步不能省。测试集必须是从未参与训练和验证的数据比如你单独留出来的另一批监控画面。这样评估出来的指标才是真实的泛化能力。我常用的评估命令是yolo detect val modelruns/detect/train/weights/best.pt datadatasets/data.yaml输出结果里有一列Per Class指标一定要逐类看不要只看总体mAP。比如模型对car的mAP50可能是95%但bus可能只有70%这个差距如果存在说明bus的样本量不足或者特征区分度不够需要针对性补充数据。除了mAP实际部署中更要关注的是单类别的精确率和召回率。如果做车辆计数召回率优先——漏检一辆车比误检一辆车更要命因为漏检直接导致计数不准确而误检在后续的跟踪算法里往往可以被滤波掉。如果做违停检测则精确率优先——误报一次会导致工作人员白跑一趟而过低的召回率可以通过加大概率抽查频次来弥补。这个侧重点的取舍直接影响你最终选择多少置信度阈值来部署模型。4.4 模型导出与部署推理车辆检测模型在实验室里的指标再好看最终都要落到实际推理环境里。YOLOv8支持导出多种格式我常用的是ONNX和TensorRT。导出ONNX很简单yolo export modelruns/detect/train/weights/best.pt formatonnx dynamicTruedynamicTrue表示允许动态输入尺寸如果部署时输入尺寸固定这个参数可以不加性能会更好。导出之后可以用onnxruntime或者OpenCV的DNN模块做推理。我自己在服务器上用ONNX Runtime跑部署时修改输入尺寸为640x640单张推理时间在10毫秒级别。TensorRT是NVIDIA显卡上加速效果最好的推理引擎导出步骤多一点需要先导出ONNX再转engine格式但推理速度能比ONNX提升至少一倍。如果是Jetson系列设备强烈建议用TensorRT部署。有一点要提醒TensorRT的推理精度在FP16模式下会有轻微下降对车辆检测这种粗粒度任务影响很小但如果你的场景里有大量小目标建议先用FP32验证一下精度再决定。部署推理时还需要处理一个非常实际的问题监控画面通常是1920x1080或更大分辨率而模型输入是640x640是直接resize还是做等比缩放填充我的经验是直接用简单resize会导致车辆比例变形影响小目标检测效果更好的做法是等比缩放加灰色填充让目标保持原有宽高比。ultralytics库在推理时默认就是这么处理的所以不建议自己在外部做粗暴的resize来喂给模型。5. 常见问题与排查技巧实录5.1 训练不收敛或loss异常这个是最常见的问题也是大家最喜欢找我吐槽的。我自己的排查顺序是这样的先检查数据。用可视化脚本把训练样本的标注框画出来逐一检查数据增强后的图片是否正常。很多时候是标注文件有问题比如坐标超出了图片边界、类别id越界、txt文件为空或者内容串行。我遇到过一次txt文件里混入了UTF-8的BOM头导致解析报错排查了半天。再检查学习率。YOLOv8默认学习率对大多数情况是合适的但如果数据量很小可以把初始学习率适当调低比如从0.01降到0.001。学习率过大容易导致loss震荡甚至发散过小则收敛极慢。然后检查batch size和显存。如果batch size太小比如只能设为2或4训练时的梯度噪声会很大loss曲线的震荡也会明显。如果数据量不大可以用梯度累积来模拟更大的batch sizeultralytics里有accumulate参数可以调整。最后检查类别是否极端不均衡。如果某类样本只有几十张它的loss会被其他类别淹没表现为该类别的AP几乎为零。这种情况就要回到数据集层面去补样本或者做增强光调参解决不了。5.2 训练集指标好一到实际场景就翻车这是所有做实际项目的人都会经历的痛。模型在测试集上mAP50有95%一到现场新场景各种漏检误检全冒出来。核心原因就一个你的测试集和实际场景存在分布差异。我遇到过几个典型案例测试集里全是白天晴朗天气现场一到傍晚光线变暗检测率骤降测试集里车辆都是正常行驶姿态现场出现大量斜停车、侧方位停车模型对非常规角度的车检测不稳定测试集里画面是固定的高清摄像头现场是老旧摄像头画面偏暗还有噪点模型明显不适应。这种问题的解法没有捷径就是不断收集实际场景的难例加入训练集做增量训练。我现在的习惯是模型上线后持续收集线上的误检和漏检截图每周做一次小批量标注和二次微调。这个持续迭代的流程才是保证实际效果的真正关键。5.3 小目标车辆检测效果差车辆在监控画面中有时会非常小比如远处的车辆可能只有二三十个像素宽。小目标检测一直是目标检测领域的难点解决思路可以从几个方向入手。第一个方向是提高输入分辨率。同样是640x640输入小目标占的像素比例太小如果显存允许把训练和推理的输入分辨率提高到960甚至1280小目标的检测效果会有明显提升。代价是推理速度下降需要权衡。第二个方向是数据层面对包含小目标的图片做切片处理或过采样。比如把大图切成几个小块分别训练相当于变相放大了小目标。Ultralytics里可以结合SAHI这种切片推理工具来解决小目标检测问题实际效果非常明显。第三个方向是模型层面YOLOv8本身在颈部网络里已经有对不同尺度特征的融合对小目标的支持比早期版本好不少。如果还不够可以考虑用更大尺寸的模型或者在训练时增大mosaic增强的概率因为mosaic把多张图拼接后小目标的样本数量和多样性都会增加。5.4 标注质量引发的隐性效果问题有一种情况特别容易让人抓狂模型训练过程一切正常loss收敛了mAP也挺高但一到现场就出现“莫名其妙”的错误比如把路牌上的车形图案、地面上的车影都检出来。这种基本可以断定是训练数据里混入了大量相似特征的错误标注。我之前提过的海报事件就是一个典型案例。还有一个类似的案例是某个项目里模型总是把货车侧面的大型广告图案检测成车辆查了很久才发现训练数据里卡车样本严重不足模型无法区分“卡车”和“卡车上的图案”只能靠外观整体相似度来判别。这类问题的排查方法也很简单把模型的检测结果按置信度排序人工检查高置信度误检和低置信度漏检的图片找到共性和规律回到数据层面去解决。千万不要指望通过调阈值来根治那只是暂时盖住症状。5.5 误检率与漏检率的调节技巧实际部署的时候多数情况下你不会直接用默认的0.25置信度阈值。我把我的调节经验整理成一句口诀漏检多就降阈值误检多就升阈值。看似废话但实际操作里很多人不知道阈值调多少合适。我会在验证集上画一条置信度-精确率/召回率曲线根据业务需求找到曲线的“甜点”。比如车辆计数项目里我要求召回率不低于95%那就去找对应的置信度阈值一般会在0.1到0.2之间。而在违停检测这种对误报敏感的场景我要求精确率不低于98%阈值通常要调到0.5甚至0.6。还有一个联动技巧同时使用类别级阈值。YOLO系列支持对每个类别单独设置置信度阈值如果car的置信度普遍偏高、bus的置信度普遍偏低就分别设置不同的阈值这样比统一调整更灵活。结尾从数据采集、标注规范、预处理、训练到部署和持续迭代车辆检测数据集加YOLO这条链路我已经完整跑过好几遍了。如果让我总结一句最核心的感受那就是大部分模型效果问题根子都在数据层面而不在模型结构或训练参数上。花在数据采集、清洗、标注规范和数据分布分析上的时间回报率远高于在调参上死磕的时间。最后再分享一个小技巧是这套流程跑顺之后我自己保留的习惯训练完成后不要单看验证集指标就收工而是把测试集里每个类别的错误案例都截图保存下来按错误类型分类归档。积累一段时间后回看你会发现模型的迭代方向会越来越清晰——哪些场景还需要补数据、哪些类别还需要细化、哪些规则还需要调整全都一目了然。这套方法用下来我的车辆检测模型从第一版到当前版本准确率提升了近20个百分点其中大部分提升都来自于这种基于错误驱动式的数据迭代而不是换更大的模型。本文还有配套的精品资源点击获取
返回列表