做行人车辆检测这个方向有些年头了。早几年提到“智能交通”“园区安防”多数人的第一反应是找AI公司买现成方案价格高不说后期算法迭代还得看别人脸色。现在我自己更倾向于直接用YOLO系列模型搭建一套可落地的“行人车辆智能检测系统”——就是这个《人车识鉴》项目输入端接摄像头或视频流输出端实时框出画面里的行人和车辆给出类别与置信度再联动业务做统计、告警、轨迹分析。它适合安防监控、智慧交通、车路协同、校园园区管理等场景也适合所有想把目标检测真正部署到实际视频流中、而非只停在demo层面的开发者参考。这篇文章我会把项目的完整链路拆开来讲从需求分析、数据准备、模型训练到推理速度对比和工程部署中间穿插大量实操中踩过的坑和排查思路。如果你正好在看YOLOv5和YOLOv26之间怎么选或者训练完模型后发现有漏检误检不知道怎么调这篇应该能给你一份可复制的参考答案。1. 项目需求与技术选型行人车辆检测为什么不能只靠“效果好”1.1 核心需求解析在做任何检测项目之前先把需求聊透是最高优先级的工程动作。《人车识鉴》的核心需求其实很清晰在固定或移动摄像头画面中对行人和车辆两类目标进行实时定位和分类。但“实时”和“准”这两件事在工程上经常打架。场景不同侧重点完全不同。比如单向车道的卡口监控车辆目标占画面主体行人往往只是背景局部这时候模型的检出压力主要在车辆而园区人行道场景恰好相反行人可能会被树干、路灯、机动车局部遮挡目标形态多变。所以我在最开始就把需求拆成了三个约束维度检测精度、推理速度、部署成本然后才去选模型。这个顺序不能反——先定需求再选型而不是看到新模型就往上套。另一个容易被忽视的点是“持续运行”要求。监控场景的摄像头一年365天不关机这意味着模型不仅要准还要稳不能出现偶发的大面积漏检。所以我在方案里把“模型鲁棒性”放在和“精度”同等重要的位置这也直接影响后面的数据增强策略和模型阈值设计。1.2 为什么选YOLO系列而不是两阶段检测器行人车辆检测在技术路线上有好几个选择传统HOGSVM那一套早就不满足精度要求了属于可以跳过不谈的考古内容两阶段的Faster R-CNN、Cascade R-CNN在精度上有优势但在实时视频流场景里单张图片动辄几十毫秒甚至上百毫秒的推理耗时多路摄像头并行时算力成本会直接爆炸。工业落地优先考虑的是“摄像头路数×单路帧率”这个综合指标一阶段检测器的速度优势是压倒性的。YOLO系列在工业界受欢迎不单是因为快。它的工程生态成熟从标注数据到训练脚本、再到导出ONNX/TensorRT工具链几乎是一条龙。对于我这种经常要快速验证想法的人来说YOLO系模型的开箱即用程度远比很多论文里的SOTA模型高。它把“把模型跑起来”的成本降到了极低这本身就是生产力。《人车识鉴》选YOLOv26除了它作为系列新版本在精度与速度上的进一步平衡更重要的是它延续了YOLO生态的打包方式迁移成本低。项目里我从YOLOv5迁移到YOLOv26训练脚本、数据格式基本无缝切换这种生态兼容性在技术选型里是很关键的隐性优势。1.3 行人车辆检测的难点与应对思路行人车辆检测表面上看只有两个类目实际做起来比想象中复杂。行人目标形态变化大站立、弯腰、奔跑、骑电动车外观差异极大车辆则有轿车、卡车、公交车、自行车、三轮车等不同形态同类别内差异也不小。另外还有几个硬骨头小目标密集场景十字路口远处的人群、车辆、目标遮挡行人被车辆遮挡、车辆被树荫覆盖、光照剧变逆光、夜间、炫光。这些问题不是单靠换一个更大的模型就能解决的而是需要从数据、增强、推理后处理多个层面协同优化。项目里我确定了一条核心应对思路以YOLOv26为基线模型在数据层面做针对性增强在训练策略上通过分阶段调节解决类别不平衡在推理端设计带面积筛选的NMS后处理。后面几节我会分别展开把这套组合拳的细节讲清楚。2. 数据准备决定模型上限的隐藏工程2.1 训练数据集的选择与整合很多新手上来就急着写训练脚本实际上一个检测模型的效果天花板很大程度在数据阶段就定死了。行人车辆检测没有特别大的公开“人车双类”专用数据集所以我的做法是整合多个公开数据集再补一部分自采数据。COCO的person类、车辆相关类可以用但类别标签需要重映射UA-DETRAC在交通监控场景下表现不错车辆密集而且有遮挡还有CrowdHuman虽然主打人体检测但对行人形态覆盖很全。整合时最重要的一步是清洗。不同数据集的标注风格、边界框定义不一样有的框全身有的框可见部分如果不加处理直接混训模型会学出很奇怪的框偏好。我统一把行人标注定义为“全身可见部分的外接矩形”车辆标注定义为“车身主体外接矩形含后视镜但不含明显突出物”。数据清洗阶段我写过一段小脚本批量检查不同数据集的标签分布和框尺寸分布把明显错误的标签挑出来人工复核。整合之后的数据规模大约8万张图其中行人目标约20万个车辆目标约15万个。光有数量不够还要看分布。我统计了目标宽高比和面积分布发现小目标占比很高——小于32×32像素的目标占了接近三成这也是训练阶段需要专门处理小目标的直接依据。2.2 标注规范与类目平衡类目只有“person”和“vehicle”两类听起来简单但标注规范不提前定后续会出各种奇葩问题。我定了几条硬性规则被遮挡超过70%的行人/车辆不标避免模型学到大量无意义的局部特征。镜面反射里的目标不标那是训练噪音。车辆类别统一不细分轿车、卡车、公交车原因是当前业务只关心“有无车辆”细分反而会拉低整体精度。类别平衡方面行人目标数比车辆多如果直接训模型容易偏向行人。我的处理方式是在损失函数里给车辆类适当加权重。具体在YOLOv26配置里调整cls_loss的类别权重让车辆类的损失权重略高于行人平衡两个类别的梯度贡献。这个操作幅度要小通常加0.10.2就够加太猛会把行人的召回率拉下来。2.3 数据增强策略多算力换鲁棒性数据增强是成本最低的鲁棒性来源。YOLOv26内置了Mosaic增强、随机仿射变换、HSV色域扰动、MixUp等但默认策略不能无脑开全尤其是Mosaic。Mosaic把四张图拼成一张好处是小目标数量变多、上下文信息丰富坏处是训练后期如果一直用模型会对拼接边界产生依赖。我的策略是训练前80个epoch开启Mosaic最后20个epoch关闭让模型回归到正常分布的图片上做精调。这个细节在多个YOLO项目里都验证过能明显降低验证集上的边界框抖动。针对行人车辆场景我还额外加了两种增强随机遮挡模拟Random Erasing和亮度对比度扰动。随机遮挡模拟能模拟行人被树木、车辆局部遮挡的场景亮度扰动则提升了对逆光、傍晚光线的适应能力。这些增强在YOLOv26的训练配置里都有对应参数项也可以自己在数据加载器里写但先用内置的够用。注意数据增强不是越狠越好。我在调试时曾把HSV饱和度扰动范围开到0.9结果验证集精度掉了近2个点。原因是在夜间监控画面中色彩分布本来就偏暗过度增强让模型学到了不真实的颜色分布。一般饱和度扰动在0.5左右比较合理。2.4 数据划分验证集是模型的“照妖镜”数据划分看起来是常规操作但如果划分不合理后面所有指标都会失真。我的做法是先按视频片段分组同一个视频的帧只进训练集或只进验证集再按8:1:1划分训练、验证、测试集。这样做避免了同源视频帧的数据泄露。另外我会单独准备一个“困难集”专门挑那些隧道入口、雨夜、强逆光、行人密集遮挡的图片。这部分数据不参与训练只在最终评估时使用。模型在常规验证集上可能都到95%的mAP了但在困难集上往往会掉到80%以下这个差距才是真实落地时你会感受到的差距。所以我特别建议做检测的朋友都给自己建一个困难集它比任何训练曲线都能暴露问题。3. 从零训练YOLOv26配置、调参与踩坑实录3.1 环境准备与依赖安装训练环境这块没什么玄学一张显存够大的卡CUDA、cuDNN、PyTorch版本对得上就行。我用的是单张RTX 4090训练显存24GBYOLOv26默认输入尺寸640×640batch size可以开到32左右。环境搭建有个容易踩的坑是版本兼容。PyTorch版本、CUDA版本、GPU驱动版本三个之间如果搭配不当训练过程中会出现莫名其妙的CUDA error。我的建议是不要追赶最新版本直接用官方推荐的组合。安装完依赖后先用官方预训练权重跑一次推理确认环境正常再开始训练这一步能省下很多排查装环境的时间。依赖安装可以用官方给的requirements文件创建虚拟环境后一次性装齐。我这里贴一下常用的操作不限定版本号大家按自己环境匹配pip install -r requirements.txt python -c import torch; print(torch.cuda.is_available())如果输出True说明环境基本没问题。3.2 训练配置的核心参数YOLOv26的训练参数虽然多但真正影响命脉的就那么几个。我用的是官方默认的数据格式在data目录下准备yaml文件指向训练集和验证集路径然后写一个train.yaml里面主要调以下参数model: 选择模型规模。项目里选了中等规模的配置兼顾精度和速度。如果算力紧张也可以选轻量版本但行人密集场景下轻量版漏检会明显增多。epochs: 我设为300。对这个数据量级300个epoch足够收敛太少欠拟合太多容易过拟合。batch-size: 32。imgsz: 640。输入尺寸不是越大越好。之前试过960小目标检出确实更准但推理速度慢了一半对视频流实时性不友好。640是监控场景里比较折中的值。patience: 早停机制设为50。如果连续50个epoch验证集指标不提升自动停止省时间。训练启动命令大致如下python train.py --data data/people_vehicle.yaml --weights yolov26.pt --batch-size 32 --imgsz 640 --epochs 300 --device 0这里的“yolov26.pt”是预训练权重。用预训练权重做迁移学习比从零训练收敛快得多而且最终精度通常更高。3.3 训练过程的监控与判断训练不是一键跑完就完事实时监控曲线才能及时发现问题。我主要看两个东西一个是训练集和验证集的loss曲线另一个是验证集的mAP曲线。Loss曲线正常应该是在前几个epoch快速下降然后逐渐趋于平缓。如果训练loss持续下降但验证loss回升那是过拟合信号可以提前停止或加大数据增强。如果训练loss和验证loss都下不去卡在很高的位置先检查数据标签是否有错再考虑是不是学习率太大或太小。YOLOv26默认配置里自带学习率自动调度。我在项目里观察到前20个epoch是loss下降最快的阶段到100个epoch以后mAP的提升变得非常缓慢每10个epoch可能才涨0.10.2个点。这种时候不要焦虑那是模型在精调边界框回归头属正常现象。训练过程中每隔一段时间我会在验证集上随机抽一批图片可视化检测结果。看可视化比看数字更直观框的位置是否贴合、漏检的目标长什么样、误检的类型是什么。这一步能帮你直观发现数据标注阶段遗留的问题比如某个场景下大量行人没框出来很可能训练集里这种姿态的行人数量太少。3.4 调参实战欠拟合、过拟合与学习率训练完第一版模型后大概率不是一次到位。我遇到的第一个问题是有轻微过拟合——训练集上的置信度很高、loss很低但验证集mAP只有82%左右。排查下来有两个因素一是数据量还不太够二是某些增强在后期没有关掉。处理方法是在训练后段冻结backbone只fine-tune检测头。YOLOv26里可以设置冻结参数这样模型对图像底层特征的改动变小更加专注于任务本身。另外一个技巧是给大模型加一点weight decay。从默认的0.0005调整到0.001略微改善了过拟合。还有一次遇到学习率问题。前30个epoch的loss下降极其缓慢后来检查发现是初始学习率设小了。YOLOv26的默认学习率一般够用但如果用了自定义优化器配置要注意基础学习率是否匹配。我后来直接初始化后先跑20个epoch观察如果loss下降太慢就把初始学习率乘2到3倍重跑。这是最省时间的试探。4. 推理速度对比与工程优化YOLOv5和YOLOv26怎么选4.1 YOLOv5与YOLOv26的推理速度理解很多人搜YOLOv5和YOLOv26推理速度对比其实想知道的就是“新版本值不值得升级”。我拿同一个数据集、同一张测试卡分别部署了YOLOv5中模型和YOLOv26中模型比较结果有一个比较直观的判断维度在输入尺寸640×640、TensorRT FP16精度下YOLOv26的推理速度与YOLOv5基本持平但检测精度在行人车辆这类场景下高出3%左右。也就是说新版模型用接近相同的算力换来了更准的结果这笔账是划算的。但要注意推理速度这个指标不能只看模型名字。实际影响延迟的因素还包括是否开启TensorRT、是否使用FP16/INT8量化、batch是否合并、输入分辨率多大、是否做了frame skip。同一个模型在不同优化配置下速度可以差出3到5倍。YOLOv5在工程界的存量巨大它的优势是稳定、资料多、踩坑经验丰富而且对于一些轻量级边缘设备YOLOv5n或YOLOv5s的部署方案已经非常成熟。如果你的设备算力极低、场景相对简单沿用YOLOv5是完全合理的。但如果你在做一个对精度有一定要求的新项目且算力不是极其紧张直接上YOLOv26是更面向未来的选择。4.2 模型量化与TensorRT部署训练好的PyTorch模型直接用来做视频流推理速度是远远不够的必须走部署优化一环。我的标准流程是先导出ONNX再转TensorRT engine。YOLOv26官方的导出脚本已经支持这些格式但有几个细节值得注意。导出ONNX时我设置了--simplify做图优化减少冗余算子。同时--opset版本要和TensorRT支持范围匹配。转换TensorRT时FP16是绝大多数场景的首选——精度损失在1%以内但推理速度能比FP32快一倍。INT8虽然更快但需要校准数据集且在小目标密集的行人检测场景中精度波动较大我一般不轻易用。转换后的实测数据是单张640×640图像在RTX 3060上的TensorRT FP16推理延迟约810ms在Jetson Orin Nano上约1822ms。这个速度跑25帧每秒的视频流完全够用。如果有多路摄像头需求可以进一步把多路视频帧拼成一个batch做批推理能显著提高GPU利用率。提示部署时一定要把图像的预处理缩放、归一化也写进推理管线里不要在Python端做逐帧的base64转换和resize。我之前在Jetson上部署时光图像预处理就占了整个管线一半的耗时后来把resize和归一化都合并成一个CUDA预处理算子端到端延迟直接下降了30%。4.3 部署硬件选型建议硬件选型取决于你面向的落地场景。如果是中心机房服务器部署一颗中端GPU如RTX 3060及以上即可稳定跑46路720P视频流如果是边缘盒子部署Jetson Orin Nano/Orin NX是性价比不错的选择功耗低、算力够用。另外推荐把检测结果通过MQTT或RTSP回传这样业务端可以做实时告警和统计分析。我在《人车识鉴》里的做法是检测服务只做检测把结构化结果目标类别、坐标、置信度、时间戳封装成JSON推给下游消息队列由独立业务服务负责告警、统计和界面展示。解耦之后检测服务的吞吐量和稳定性都大幅提升。5. 常见问题与排查技巧实录5.1 小目标漏检怎么破行人车辆检测最典型的问题是远处的小目标漏检。小目标在640×640输入下可能只有十几个像素特征信息本来就稀缺模型很难兼顾大目标和小任务。排查思路分三步。第一步确认是不是输入分辨率太低适当提升imgsz到960往往立竿见影但代价是速度下降需要权衡。第二步检查训练集中小目标的数量和标注质量如果小目标占比过低模型学不好是必然的。第三步调低推理时的置信度阈值从0.25降到0.15通常能找回一些低置信度的漏检目标但要配合NMS阈值调整否则误检会增多。我还用过一种trick在推理端做多尺度测试multi-scale inference对同一帧图像分别用640和960尺寸推理再合并结果。这个方法能明显提升小目标召回但推理时间接近翻倍适合离线分析场景不适合实时视频流。5.2 误检、遮挡与目标形态变化误检频发的核心原因是模型学到的特征不够“判别性”。比如把路灯杆的影子当成人把路牌当成车这种场景通常需要回到数据层面补“负样本”。我在项目里专门收集了一批不包含行人和车辆的纯背景图加入训练集并在训练配置里让模型学习“背景”类别。同时提升了NMS的IoU阈值从默认的0.45调高到0.5减少重叠框的误保留。遮挡问题则通过放宽检测框的宽高比设定来缓解因为行人被车辆遮挡时检测框会变得很窄或很扁约束太严格容易丢目标。5.3 夜间与恶劣天气的鲁棒性模型在白天表现良好到夜间就崩——这个问题在监控场景几乎必现。我在数据增强里专门加了亮度增强和噪声模拟还从开源夜景数据集中抽了一部分夜间图像做fine-tune。效果最明显的是加了一个简单的“low-light增强”逻辑训练时对部分图像做Gamma校正模拟暗光环境。这个操作不需要额外数据纯粹是数据处理层面的事。最终夜间场景的mAP从76%提升到83%虽然还是不如白天但至少能用了。5.4 常见问题速查表现象可能原因处理建议训练loss不下降学习率过小数据标签错乱调大初始学习率抽样检查标签验证集mAP偏低过拟合或数据分布单一冻结backbone fine-tune增加数据增强小目标漏检输入分辨率低小目标样本少提高imgsz补充小目标数据夜间误检多训练数据缺乏暗光样本增加亮度扰动加入夜间数据fine-tune推理速度慢未启用TensorRT/量化转ONNX/TensorRT用FP16多路视频卡顿单帧推理逻辑阻塞用batch推理接入消息队列解耦6. 项目落地的一些实在经验最后分享几个项目结束后沉淀下来的体会不扯虚的。最核心的一点训练出一个高mAP的模型并不是项目终点稳定地跑在真实环境里才是。《人车识鉴》上线初期模型在演示视频里效果惊艳但接到真实摄像头流后因为现场光照、角度和训练分布差异巨大前两周的漏检率明显偏高。我当时的应对是建立了一套“线上数据回流”机制——把推理中置信度很低但实际有目标的帧抽样保存下来人工复核后定期补充进训练集做增量训练。两轮迭代之后真实场景的精度才追上来。做检测项目的人我建议从一开始就预留这个流程不要等上线了再补。第二个体会是版本升级要理性看待。YOLOv26作为新版本确实带来了更高的精度上限和更优的部署体验但如果你现有的YOLOv5模型在场景里已经跑得很稳业务目标也都能满足那强行换版本的意义不大。技术选型永远服务于需求不是为了追新而追新。反过来说如果你正好要启动一个新项目直接选用当前生态成熟、社区活跃的最新版本是降低长期维护成本的合理决策。另外我个人在做这个项目后养成了一个习惯每个阶段的实验都要留档。哪个数据集、哪个增强配置、哪个超参数对应的验证集mAP是多少记录下来。这个习惯在你后续调参或复现实验结果时能节省大量时间因为很多问题不是“方法不对”而是“记不清上次是用什么跑出来的结果”。《人车识鉴》这个项目目前已经能稳定支撑园区场景下的实时人车检测与统计功能后续我还在规划加入多摄像头跨镜追踪和轨迹热力分析。如果你正在做类似的方向或者对行人车辆检测有自己的一套玩法欢迎交流。工程这条路永远是动手做一遍比看十篇文章更有效。