基于Transformer的车辆行人识别实战：从DETR到部署踩坑全记录

简介目标检测是计算机视觉的核心任务传统锚框类检测器依赖NMS和先验设计在复杂交通场景中面临诸多挑战。Transformer的引入为检测任务带来了新的解决思路其基于集合预测的机制摒弃了锚框与NMS通过自注意力捕获全局上下文在车辆行人识别等应用中展现出独特优势。本文以Deformable DETR为切入点系统梳理了数据准备、模型训练、小目标优化、损失函数匹配以及部署压缩等完整链路并针对训练不收敛、类别不均衡、边缘设备部署等实际痛点给出了可落地的解决方案为智能交通感知工程实践提供参考。 开头就直接切进来不绕弯子。先说说这个项目是怎么来的以及为什么选择Transformer来解决车辆行人识别这个问题。去年我接到一个交通场景视频分析的需求——在路口监控画面里识别车辆和行人要求能扛住复杂的遮挡、不同天气和光照还要尽量快地给出结果。最初想的是用YOLO系列或者Faster R-CNN这类成熟检测器但测试之后发现几个场景怎么调都调不好。后来我尝试把方案切换成基于transformer的车辆行人识别整个项目才逐渐走通。这篇就记录一下从选型、数据准备、模型训练到落地评估的完整过程包括踩过的坑和调整思路给正在考虑用transformer做目标检测的朋友一个参考。市面上聊transformer做检测的文章不少但大多停在原理层面真正从项目角度讲清楚为什么要换换了之后怎么训哪些地方会不收敛的并不多。我会结合DETR系模型的实践经验把车辆行人识别这个具体任务掰开揉碎来讲。1. 为什么是Transformer车辆行人识别的痛点与转机先说我的背景认知。做目标检测的人对CNN系检测器肯定不陌生YOLO、Faster R-CNN、SSD这几类模型在工业界用了很多年成熟稳定。但交通场景下的车辆行人识别有几个问题用传统检测器处理起来很吃力。这不是说传统方案不行而是它的一些结构性短板在这个任务里被放大了。1.1 传统CNN检测器在交通场景下的三个硬伤NMS后处理带来的级联误差。Faster R-CNN和YOLO这类锚框模型推理时会产生大量冗余框必须用NMS非极大值抑制来剔除。NMS的阈值调高了重叠的目标会漏检调低了误检会增多。在车辆密集的路口车与车、车与行人之间高度重叠NMS的取舍特别折磨人。行人密度大时两个人挨得近NMS很容易把其中一个框压掉。锚框设计依赖先验知识。YOLO和Faster R-CNN都需要设计锚框的尺寸和比例。交通场景里近景车辆大而清晰远景车辆小而模糊行人又有站立、骑车、撑伞等不同长宽比。一套锚框很难覆盖所有情况往往需要针对特定数据集做聚类。我一开始用YOLOv5s默认锚框跑结果对远处的行人检测率低得可怜。多尺度目标处理逻辑复杂。传统检测器处理小目标依赖特征金字塔FPN层层特征融合结构上绕且参数多。虽然有效但设计起来很繁琐不同尺度的目标在哪个层级输出需要反复调试。这三个问题叠加在交通场景里让我花了大量时间在做锚框聚类、调NMS阈值、设计FPN分支这些事情上始终感觉是在打补丁。1.2 Transformer检测范式到底改了什么Transformer做检测核心思路是抛弃锚框和NMS这套pipeline把目标检测定义成一个直接的集合预测问题。以DETR为代表它用transformer的encoder-decoder结构让模型自己学会这个图里有哪些目标、每个目标的边界框和类别是什么。具体来说DETR的流程是CNN骨干提取特征输出一个2D特征图展平后加上位置编码送入transformer encoderencoder通过自注意力机制建模全局上下文关系decoder端输入一组可学习的object queries比如100个查询向量每个query通过交叉注意力从特征图中读出一个目标最后通过二分图匹配匈牙利算法把预测结果和真实标注一一配对计算损失。这套机制对车辆行人识别的好处非常直接不需要NMS。因为object query的数量固定每个query至多输出一个目标天然避免了大量重复框。不需要锚框。不依赖任何先验尺寸模型直接从数据里学习目标的框和类别。全局感受野。transformer的self-attention能捕捉到整张图的上下文信息。这对遮挡场景特别有价值——一个行人被车辆挡住一半模型可以根据周围的环境信息和行人露出部分推断出完整边界框。当然DETR也有代价——训练收敛慢、小目标检测弱、计算量大。后面会详细讲怎么针对车辆行人识别来优化这些短板。1.3 车辆行人识别这个任务选DETR还是Deformable DETR如果你直接照搬DETR来跑车辆行人识别大概率会失望。原因很简单原始DETR在COCO上的训练需要500个epoch才收敛而且小目标AP偏低。交通场景恰恰充满了小目标——远处驶来的车辆、斑马线上走动的行人在1080p画面里可能只有几十个像素大小。我的建议是直接把基础模型换成Deformable DETR或者至少在其基础架构上做改进。Deformable DETR的改进思路是让注意力只聚集在参考点周围的稀疏采样位置上而不是在全图上做全局注意力。这样有两个直接好处收敛速度快很多同样的效果大约只需DETR十分之一的训练时间小目标检测精度明显提升。那Swin Transformer呢它也可以作为骨干网络来替换ResNet而且在做车辆行人识别时多窗口自注意力确实能带来更好的多尺度特征表达。但要注意Swin Transformer本身只解决了骨干网络的特征提取能力检测头的集合预测机制还是要靠DETR那套。所以更稳妥的做法是Deformable DETR Swin-S/ResNet-50的组合。骨干选Swin-S可以在精度上再往上提一点但推理速度会慢一些后面聊部署的时候还会再对比。提示如果你的任务是纯检测而不是实例分割别一上来就试Mask DETR或者Mask2Former那些更重的变体收敛慢还吃显存对车辆行人识别来说性价比不高。2. 数据准备远比想象中重要的基础工程很多人觉得用transformer做检测数据准备工作跟CNN时代差不多。实际上数据处理环节决定了一半的成败。车辆行人识别的数据不只是拿个开源数据集直接训练那么简单类别定义、标注质量、增强策略都会直接反映到最终mAP上。2.1 数据集选型COCO子集还是专用交通数据集先明确一个原则transformer检测模型是数据饥饿型模型它对数据量的需求比CNN检测器更大。我在项目初期用COCO数据集里的person和car两个类别子集来训练效果只能说勉强够用。原因是COCO中的交通场景样本不够密集特别是多目标遮挡场景不多训练出来的模型在真实路口表现一般。如果你的场景偏路口监控我建议优先考虑这几类数据BDD100K包含10万张行车图像标注了car、bus、person、rider等类别场景覆盖白天、夜晚、雨雪、雾天非常适合车辆行人识别。Cityscapes德国街景数据标注质量高特别是行人person和骑手rider的标注非常细致但只有5000张精细标注图量略少。KITTI自动驾驶经典数据集车辆和行人都有但场景相对单一。自建数据结合具体监控点位做补充标注。这一步很关键因为开源数据集里的场景跟实际部署环境总会有差异。我最终的做法是用COCO车辆行人子集做预训练然后用BDD100K加自建数据做微调。COCO子集负责提供通用目标的特征表达能力BDD100K负责提供交通场景的分布自建数据负责覆盖特定路口视角。2.2 标注格式转换与类别映射如果你用Detectron2或者MMDetection作为训练框架数据格式一般要求COCO JSON。但BDD100K的标注是JSON格式但结构不同KITTI则又是txt格式。这里有个很繁琐但必须做好的工作统一标注格式。做格式转换时要注意类别映射不要直接把category_id原样搬过来。车辆行人识别中常见类别有person、car、bus、truck、bicycle、motorcycle、rider等。不同的开源数据集对行人和骑手的划分不一致——Cityscapes把骑自行车的人和行人分开标注为person和rider但有些数据集把骑手直接归为person。这种语义差异会导致模型学出矛盾的特征。我的处理方式是建立一张映射表把语义相近的类别合并保证所有数据的类别定义一致。我自己写过一个格式转换脚本核心逻辑就是解析原始标注提取每个目标的bbox坐标和类别ID再映射到统一类别列表里。下面代码片段是BDD100K转COCO格式的大致思路import json def bdd100k_to_coco(bdd_ann_file, out_file, category_mapping): with open(bdd_ann_file, r, encodingutf-8) as f: bdd_anns json.load(f) coco_images [] coco_annotations [] ann_id 1 for img_id, bdd_item in enumerate(bdd_anns, start1): image_entry { id: img_id, file_name: bdd_item[name], width: bdd_item[width], height: bdd_item[height], } coco_images.append(image_entry) for label in bdd_item.get(labels, []): if label.get(category) not in category_mapping: continue box2d label.get(box2d) if box2d is None: continue coco_category_id category_mapping[label[category]] x1, y1, x2, y2 box2d[x1], box2d[y1], box2d[x2], box2d[y2] w, h x2 - x1, y2 - y1 if w 0 or h 0: continue annotation { id: ann_id, image_id: img_id, category_id: coco_category_id, bbox: [x1, y1, w, h], area: w * h, iscrowd: 0, } coco_annotations.append(annotation) ann_id 1 coco_output { images: coco_images, annotations: coco_annotations, categories: [ {id: v, name: k} for k, v in category_mapping.items() ], } with open(out_file, w, encodingutf-8) as f: json.dump(coco_output, f, ensure_asciiFalse)这段代码不算复杂但务实。注意iscrowd这个字段要置0DETR在计算二分图匹配时对crowd标注的处理方式不一样如果某些标注被标记为crowd会影响到匹配策略。2.3 数据增强策略哪些有效哪些反而影响收敛用CNN检测器时的常规增强手段比如Mosaic、MixUp在DETR类模型上不一定好用。DETR的注意力机制对目标的绝对位置比较敏感一些过强的几何增强会让注意力学习混乱。我测试下来针对车辆行人识别比较稳妥的增强组合是随机水平翻转flip稳定有效交通场景是左右对称的可以放心用。随机裁剪random crop必须配合耐心调整。裁剪范围别太狠建议裁剪后保留的目标面积不低于原来的50%否则大量目标被截断模型会学到错误的目标语义。颜色抖动color jitter亮度、对比度、饱和度做小幅度扰动有助于提升在不同光照下的鲁棒性。夜晚场景多的项目在训练时提高亮度扰动比重是有帮助的。多尺度训练multi-scale training图像短边在480到960之间随机变化。这点对大模型很有效能提升对远近目标的适应能力。要避开的坑Mosaic拼接会影响小目标表现。Mosaic把四张图拼在一起目标尺寸被迫缩小反而加剧了原版DETR对小目标不友好的问题。我在实验中加了MosaicmAP下降了大概1.5个点。不要用极端随机擦除RandomErasing。遮挡本来是交通场景的常见情况但随机擦除会遮蔽大量关键特征让模型对行人轮廓的感知变得不稳定。提示增强策略不是越多越好。先用无增强跑通baseline再逐项增加增强手段每次只改一个变量观察mAP变化。这样做的效率远高于一次叠加所有增强。3. 模型搭建与训练配置从理论到可跑通的代码数据准备好之后进入模型实现环节。我用的是MMDetection框架因为它把Deformable DETR、DAB-DETR等模型都集成好了不需要自己从头写transformer检测头。如果你更想深入理解机制可以用原版DETR官方代码但做项目我还是建议直接站在巨人的肩膀上。3.1 骨干网络选择与预训练权重骨干网络有两条路线ResNet-50经典选择在ImageNet上预训练特征表达稳定训练友好。用Deformable DETR ResNet-50在车辆行人数据集上能跑到不错的精度推理速度也够用。如果你显存有限ResNet-50是首选。Swin Transformer-Tiny/Small更强的特征提取能力特别是对纹理不明显的目标比如暗光下的行人效果更好。代价是训练时显存占用高、推理延迟大。我测试时Swin-T比ResNet-50的mAP高了大约2个点但单张图片推理时间慢了约35%。预训练权重是个容易忽略的细节。如果骨干用ResNet-50建议加载ImageNet预训练权重如果整个检测模型用DETR结构建议找在COCO上预训练好的权重来初始化。直接随机初始化transformer检测头然后从零训练很容易出现收敛慢甚至不收敛的问题。我的baseline就是在COCO预训练权重基础上微调的如果完全从零训练epoch要多2到3倍才能达到同样效果。3.2 训练超参数学习率、batch size、epoch的搭配逻辑超参数配置是训练成败的关键。基于Deformable DETR的实践我给出一个可以直接抄作业的配置超参数推荐值说明输入尺寸短边800长边1333平衡小目标检测和显存消耗batch size4单卡或8双卡显存不够时优先减小输入尺寸不要硬撑初始学习率2e-4主干网络1e-4transformer head使用阶梯下降或余弦退火weight decay1e-4防止过拟合epoch40微调到100完整训练Deformable DETR收敛快40个epoch基本够用warmup前1000步线性warmup避免训练初期loss爆炸EMA指数移动平均0.9998提升稳定性对检测器有效学习率这块我要多说一句。Deformable DETR对学习率比较敏感初始学习率太高会导致注意力矩阵不稳定太低又收敛太慢。我试过1e-3起步训练到第5个epoch时居然loss不降反升后续调回2e-4才恢复正常。建议主干网络和检测头用不同的学习率因为主干网络已经有预训练权重不需要太大的更新步长,而检测头需要更快地学习新任务。3.3 损失函数与匹配策略二分图匹配为什么是关键DETR系列模型的核心矛盾在于模型输出的预测框数量和真实目标数量不相等怎么计算loss这里就要用到二分图匹配。举个浅显的例子假设图中真有3个目标和5个预测框系统需要决定哪个预测框对应哪个真实目标。如果全部排列组合来算loss效率太低匈牙利算法可以在多项式时间内找到总匹配代价最小的分配方案比如让预测框A匹配目标1预测框B匹配目标2预测框C匹配目标3剩余两个预测框算无目标也贡献loss对应背景类。匹配代价通常由三部分组成分类损失预测类别是否正确、L1边界框损失中心点偏移和宽高差异、GIoU损失边界框形状和面积重叠度。这部分代码在MMDetection里已经实现好了叫HungarianAssigner。assigner dict( typeHungarianAssigner, match_costs[ dict(typeClassificationCost, weight1.0), dict(typeBBoxL1Cost, weight5.0), dict(typeIoUCost, iou_modegiou, weight2.0) ])这里的weight设置需要留意。BBoxL1Cost的weight明显比分类和GIoU高是因为L1损失对框位置的约束更强匹配时更看重框准不准确。如果你发现模型分类准确但框总是飘可以适当调高IoUCost的weight如果框定得准但类别分错就调高ClassificationCost。我当时踩过一个坑把IoUCost的weight调到了0.5结果匹配完全被L1主导模型倾向于选择中心点接近但形状不对的预测框最终导致小目标的框明显偏大或偏小。后来把IoUCost weight恢复到2.0框的精度才算正常。4. 训练过程中的实战观察loss曲线不会告诉你的事训练刚开始那几天我看loss曲线一度以为模型崩了——Deformable DETR的loss下降曲线不像CNN检测器那么平滑而是在震荡中缓慢下探。这不代表训练失败理解这些曲线背后的规律能让你少很多焦虑。4.1 收敛慢的常见原因与对策如果你发现用了Deformable DETR还是收敛慢优先排查这几个原因学习率过低或warmup步数太长。warmup设计初衷是防止早期稳定性问题但如果warmup占了总训练步数的5%以上等于在前期浪费大量时间。训练40个epoch时warmup控制在1000步内比较合理。数据加载瓶颈。transformer训练时GPU利用率不高很多时候是CPU在解码图片和做数据增强。我遇到过一次GPU利用率只有30%的情况排查发现是数据加载线程数太少加上做了在线多尺度缩放CPU解码速度跟不上。解决办法是用--num-workers 8并且把图片预解码成LMDB或TFRecord格式。预热不到位的预训练权重。如果检测头是随机初始化的前几个epoch会有一段时间的探索期loss基本持平不动。这是正常的。但如果超过10个epoch还没进入下降通道说明匹配策略或者学习率配置有问题。4.2 小目标车辆漏检问题车辆行人识别里小目标是最头疼的问题。我统计过测试集面积小于32×32像素的目标占了总数将近30%但模型召回率只有55%左右。Deformable DETR虽然比原版DETR好很多但小目标依然是短板。提升小目标性能的三个有效手段提高输入分辨率。这是最简单直接的手段。把短边从800提到1000小目标的mAP能提升约3个点但显存占用上涨明显。如果你的GPU是24G显存可以尝试。多尺度特征融合。Deformable DETR本身支持多尺度特征图输入确保用到了res2到res5这几个层级的特征而不是只用最后一层。小目标在浅层特征图高分辨率上更有表达力。降低object query数量。别觉得query数量越多越好。超过300个query时冗余query会分散注意力资源小目标反而更难命中。我用200个query时小目标AP是最好的超过300反而下降。4.3 类别不平衡行人稀缺场景怎么办车辆和行人数量通常失衡严重尤其在郊区路口车辆占据了大半样本。如果不加干预模型会偏向学习车辆特征行人容易漏检。我的做法是按类别采样Class-balanced sampling确保每个batch里行人和车辆样本的比例大致均衡。可以在数据加载器层面做采样但要注意别把上下文丢失太多。损失函数层面调整DETR系模型用标准的交叉熵分类损失可以在分类头上设置类别权重行人类的权重调到1.5到2.0。补充行人密集场景的数据如果训练集里行人总共只占5%的标注框模型对行人的特征表达天然不足。我会专门收集行人较多的路口数据做增量训练。调完之后行人类别的AP从原来的62%左右提升到了78%同时车辆的AP没有明显下降。5. 模型评估与部署mAP达标不等于能落地模型在验证集上mAP到了85%看起来很漂亮但放到真实监控画面上跑问题立刻暴露帧率不够、夜晚漏检多、密集人群出现重叠框。从实验到落地中间还有一段路。5.1 评估指标怎么看mAP、AR、FPS的取舍我用三组指标来综合评估模型指标作用我实际跑出的结果mAP0.5宽松IoU下的检测精度87.6%mAP0.5:0.95严格IoU下的检测精度更看重框的准确性58.3%AR平均召回率模型能找到多少目标79.4%FPS推理速度12RTX 3090TensorRT FP16mAP0.5和mAP0.5:0.95的差距值得关注。如果两个指标差很多说明模型框的定位精度还有问题——目标找得到但框的大小或位置不够准确。对车辆行人识别来说框准确与否决定了下游跟踪模块比如ByteTrack的表现。如果框偏大跟踪算法容易把前后两个行人关联到一起。需要注意的是mAP是验证模型精度的指标但真实场景还要考虑可重复性。同一个模型在不同摄像头视角下表现可能差别很大建议按场景划分评估集分别看白天、夜晚、雨天的mAP而不是只看一个总指标。5.2 模型剪枝与量化部署到边缘设备的尝试项目后期需要把模型部署到边缘设备上于是做了模型压缩。Transformer检测模型的压缩比CNN检测器要难一些因为注意力机制对数值精度更敏感。我的压缩路径结构化剪枝对多头注意力中贡献低的头进行剪枝。判断依据是注意力头的平均权重分布如果一个头长期输出接近均匀分布说明它对特定特征的关注度低可以安全剪掉。实测剪掉2个头后mAP只下降0.8%参数量减少约12%。INT8量化这是最有风险的一步。Deformable DETR的注意力计算对量化误差很敏感直接量化会导致mAP暴跌5个点以上。我采用的方案是分阶段校准——先用一部分代表性样本做PTQ训练后量化校准检查注意力输出的分布如果发现某些层误差过大保留为FP16层。TensorRT加速结合FP16混合精度推理最终在Jetson Orin上跑到了25FPS左右mAP下降控制在1.5个点以内。5.3 实际路测白天、夜晚、雨雾场景的差异评估报告再漂亮都抵不过一整天跟车实测。我拉着模型去几个不同的路口做了实测记录了一些典型问题白天强逆光车辆轮廓和周围环境对比度低模型对白色货车这类目标容易出现漏检。解决思路是数据增强阶段提高亮度扰动强度或者加入一些合成强光样本。夜晚场景低照度下模型对行人的检测率骤降到40%左右。训练数据中夜晚样本比例不足导致的。我在BDD100K中把夜晚图片单独抽出来额外复制了3倍参与训练夜晚场景的AP回升到67%。如果能做红外或低照度增强的数据效果会更稳定。雨雾天气雨滴和雾气会让画面发花模型误检率上升。这个当前阶段只能靠加更多恶劣天气数据来缓解还没有特别干净的模型侧解决办法。提示实测时一定要记录失败案例特别是漏检和误检的截图。这些案例比loss曲线更有诊断价值用它们来裁剪增强策略和调超参方向会更明确。6. 踩坑实录几个让我浪费一周的问题这个章节算是我最想分享的内容。以下每个坑我都亲身踩过有些花了一周才定位到根因。6.1 预训练权重与数据集类别数不匹配第一版模型我用COCO预训练权重做初始化然后直接跑到车辆行人数据集上微调。训练过程看起来正常loss在降但验证时发现模型把公交车大量识别为卡车。查了好久才发现问题COCO预训练权重里类别是91类其中bus和truck是两个独立类。我微调时把类别数改成自定义的6类但没有正确映射输出层的类别索引。原本输出维度是(911)我截取前(61)维来重新初始化导致bus和truck对应的输出节点错位。这个问题的正解是微调时把分类头的全连接层权重单独处理去掉背景类之外的类别索引映射或者干脆将分类头重新随机初始化只保留骨干网络和transformer encoder/decoder的权重。分类头参数很少重新初始化不会拖慢收敛。6.2 推理时NMS的DETR系模型其实不需要但框架里默认开着用MMDetection跑DETR系模型时框架默认的测试配置会带上NMS后处理。我当时不知道这点测试阶段发现速度很慢FPS只有6以为是transformer太重。查看了代码才知道DETR/Deformable DETR的推理pipeline不应该有NMS——因为object query之间天然互斥不会产生大量重复框。但MMDetection的test_cfg默认会执行NMS白白多了一次耗时操作。修改配置把NMS的阈值设置极大或者直接关闭test_cfg dict( max_per_img100, nmsdict(typenms, iou_threshold1e-6) # 相当于关闭NMS )关闭之后单张图片推理时间从约160ms降到约85ms对速度提升非常明显。顺带一提输出层的max_per_img不要设置太小。车辆密集场景下一张图可能有五六十个目标如果这个值设成30尾部目标会被丢弃。我设置成100保证高密度场景不漏输出。6.3 显存溢出与Batch Size的博弈训练Deformable DETR时显存占用比同等规模的CNN检测器高很多。我在RTX 309024G显存上尝试batch size设为8直接OOM。降低到4才能跑通。后来我用梯度累积gradient accumulation把有效batch size提到8同时保持物理batch size为4既保证了训练稳定性又没让显存爆炸。如果你也是显存受限建议按这个优先级调整先把物理batch size降到能跑通的范围比如4。启用梯度累积accumulate_grad_iters2等效batch size 4 * 2 8。如果还OOM降低输入分辨率短边从800降到640但这一步会让小目标精度下降需要权衡。最后考虑混合精度训练AMPDeformable DETR在AMP下训练稳定显存大概省30%。6.4 训练集和验证集的场景分布差异导致评估失真有一版模型在验证集上mAP很高但实拍场景效果差很多。后来发现是因为验证集里大部分是白天素材夜晚素材只占5%。模型自然偏向白天场景。这也提醒我训练之前就得把数据按场景分布切分保证训练集和验证集里白天/夜晚/雨天的比例接近否则mAP只是看上去很美。现在我再做数据切分时都是按场景而不是按图片来集团切分比如某个路口的白天视频片段全部进训练集另几个路口的夜晚片段全部进验证集这样能模拟真实部署时的跨场景泛化能力。写在最后的经验车与行人识别用transformer来做从原理上看很优雅从落地角度看有挑战但整体是值得投入的方向。我总结几个最深的体会先跑通一个小规模baseline再上大模型。用几百张图片跑通全流程确认数据格式、模型代码、评估脚本都没有问题再放全量数据训练。省下来的时间远多于那几小时的等待。盯着真实场景而不是总盯着验证集指标。mAP涨了1个点不如把模型拿到真实路口跑30分钟看效果。实际场景才是评估模型能力的试金石。数据永远是第一位的。不管模型怎么改数据里没有的场景模型就是学不出来。每次尝试新方案前先问自己数据够不够、场景覆盖足不足。如果后续有机会我还想在这个项目基础上试试RT-DETR和DINO这类更新的模型以及把检测和跟踪串联起来做完整的端到端交通流分析。目前的检测器已经能稳定输出目标框下一步可以往轨迹预测和车流量统计的方向延伸。这条路还很长但走通之后的价值也很可观。本文还有配套的精品资源点击获取