在我去年接到的那个停车场智能管理需求里客户一开始提的要求很朴素——“能不能用摄像头自动数一下每天进出多少车、识别一下车牌”。结果一深入聊需求就变成了要识别车辆品牌和颜色、统计各时段车流量、还要在夜间和雨天尽量不误报。这类需求如果你用传统OpenCV那套背景差分、特征匹配去做基本会在两周内把自己劝退。所以最后我把技术方案定成了“深度学习目标检测分类车牌OCR”的组合整个系统用Python开发模型选择的是YOLO系列。这篇文章就把整套系统的设计思路、环境搭建、数据准备、训练调优、部署实测完整记录下来代码和参数都给到可直接用的程度。这套系统做下来核心能力可以概括成三件事车辆目标检测在画面里框出每一辆车、车辆属性识别品牌、颜色、车型、车牌识别OCR读取车牌号码。如果你还要做车流统计则在检测结果之上加一个多目标跟踪模块就能实现。整个项目比较适合正在学深度学习目标检测、或者需要把YOLO模型落地到实际场景中的开发者参考有Python基础就能跟上。1. 传统方法为什么会被我直接PASS掉很多新手拿到车辆识别需求第一反应是查OpenCV教程看到背景差分、帧差法、Haar级联这些名词就往上套。我早期也这么干过结果到了真实场景全部翻车。这里把这些方法的死穴讲清楚你就知道为什么要用深度学习了。1.1 传统视觉方案的三个致命弱点背景差分法对固定摄像头、固定背景的室内场景还行但停车场、公路监控这些场景光线变化剧烈树影摇晃、雨水反光、行人走动都会导致大量误检。HOGSVM那套虽然比纯图像处理稳定一些但一个致命问题是HOG特征对形变敏感——车辆的型号太多SUV、轿车、货车、面包车外观差异极大你很难设计一套特征把所有车型都覆盖住。更麻烦的是传统方法只能回答“画面里有没有车”回答不了“这是什么车、什么颜色、车牌号是多少”。你如果想要车辆品牌识别就得为每个品牌单独训练一个分类器工作量爆炸。Haar特征检测车牌在某些固定场景能用但角度一偏、光照一变检测率直线下降。1.2 深度学习为什么适合这个任务深度学习目标检测模型走的是端到端路线输入图像直接输出目标的类别和位置框。它不需要你手动设计特征模型会自己从数据里学到“车长什么样”。更重要的是一个模型可以同时完成多个任务——检测车辆的同时输出品牌、颜色的分类结果这是传统方法完全做不到的。从我的实测数据看在同样一个停车场监控画面下传统背景差分在白天光线正常时准确率大约只有85%到了傍晚光线变差会掉到70%以下而一个训练充分的YOLO模型全天候场景下mAP50能够稳定在90%以上夜间借助红外补光也能保持85%左右。这个差距在真实项目里就是“能不能交付”的区别。我选择YOLO系列还有几个实际考量一是推理速度快在普通GPU上能做到实时处理多路视频流二是社区生态完善预训练模型丰富资料多遇到问题容易查到解决方案三是对硬件要求相对友好甚至CPU也能跑小型模型。2. 系统整体架构检测、跟踪、识别三个模块怎么配合车辆识别系统听起来只是一个功能真正落地的时候实际上要拆成好几个模块。我在设计架构时遵循了一个原则模块之间解耦每个模块只做一件事通过统一的数据结构串联。这样任何一个模块要升级替换不会牵连其他部分。2.1 视频流接入与帧处理层最底层是视频输入。摄像头通过RTSP协议输出H.264编码的视频流Python这边用OpenCV的VideoCapture或者FFmpeg读取。这里有个实际经验不要用OpenCV的默认方式直接读RTSP流在网络波动时它经常卡死。我用的是ffmpeg拉流加OpenCV解码的组合稳定性好了非常多。读取到的视频帧先做预处理缩放、归一化、色彩空间转换。YOLO模型输入尺寸我设置为640x640这个尺寸在精度和速度之间比较均衡。帧率上不需要每帧都推理实际测试下来对于停车场出入口场景每秒处理3到5帧就完全够用算力消耗大幅降低。2.2 车辆检测与属性识别层这个层是整个系统的核心。模型输入一帧图像输出所有车辆的边界框、置信度、类别。类别包含两个维度车辆类型轿车、SUV、货车、公交车等和颜色黑、白、银、红、蓝等。这两个任务我用的是一个多任务模型同时输出而不是拆成两个模型这样推理开销更小。模型的具体选型对比我放在后面详细说这里先讲清楚模块之间如何协作。检测结果会进入跟踪模块跟踪模块给每辆车分配一个唯一ID这样就能统计“有这么一辆车在某段时间内从画面A区域移动到了画面B区域”车辆计数和轨迹绘制依赖的就是这个ID。2.3 车牌识别与结果存储层当车辆检测模块框出车辆位置后车牌识别模块只处理车牌的局部区域不用整张图跑OCR。实现方式是先根据车牌的宽高比中国蓝牌标准为440x140mm比例约3.14:1在车辆框内裁剪候选区域再用HyperLPR或PaddleOCR进行文字识别。识别结果汇总成结构化数据写入SQLite或MySQL。我用的是SQLite因为项目规模不大一个文件就能搞定部署的时候不用额外装数据库服务。每辆车记录字段包括通过时间、方向进/出、车牌号、车辆类型、颜色、对应图片路径。3. Python环境搭建这一步卡住了七成新手说句实在话我在这个项目上花在环境配置上的时间比训练模型还多。深度学习开发环境涉及Python版本、CUDA、cuDNN、PyTorch、各类依赖库之间的版本匹配版本对不上就是各种报错。这里把验证过最稳的一套组合写出来照着配不会翻车。3.1 Python环境与虚拟环境工具我用的Python版本是3.10。之所以不用更新的3.11或3.12是因为部分深度学习库的预编译包对新版本Python的支持会滞后与其踩坑不如选一个生态最成熟的版本。虚拟环境管理工具用conda它不仅管Python包还能管理CUDA相关的依赖比pip在深度学习场景里更好用。安装流程就三步装Anaconda创建虚拟环境激活环境。创建环境的时候直接指定Python版本conda create -n vehicle_detect python3.10 conda activate vehicle_detect后面所有操作都在这个虚拟环境里进行避免和系统自带的Python环境互相污染。很多新手装好包之后import报错十有八九是包的安装位置和Python运行位置不一致。3.2 CUDA与PyTorch版本匹配技巧深度学习框架选PyTorch这是目前目标检测领域生态最活跃的框架。PyTorch安装的第一步是确认CUDA版本两个命令搞定显卡驱动里查看CUDA版本运行nvidia-smi右上角的CUDA Version就是驱动支持的最高版本安装PyTorch时选择的CUDA版本不能高于驱动支持的最高版本我机器的驱动CUDA版本是12.1安装的PyTorch对应CUDA 12.1版本。这里有个容易混淆的点nvidia-smi显示的CUDA版本不代表你已经安装了CUDA工具包它只表示驱动支持的最高版本。PyTorch自带CUDA运行时不需要单独安装完整CUDA工具包很多教程让新手装CUDA Toolkit反而装出问题来。安装命令在PyTorch官网就能生成选择LinuxcondaCUDA 12.1后执行conda install pytorch torchvision torchaudio pytorch-cuda12.1 -c pytorch -c nvidia装完验证一下GPU是否可用import torch print(torch.__version__) print(torch.cuda.is_available())如果输出True说明PyTorch能正常调用GPU。这一步过不去后面训练全是空谈。3.3 常用视觉库与深度学习库安装除了PyTorch还需要用到下面这些库库名用途安装方式OpenCV图像读取、预处理、结果显示pip install opencv-pythonultralyticsYOLO模型的训练与推理APIpip install ultralyticsHyperLPR车牌识别pip install hyperlprPillow图像处理基础库pip install Pillownumpy数值计算pip install numpySQLAlchemy数据库操作pip install SQLAlchemy特别注意ultralytics这个库它是YOLOv8的官方库封装了从数据加载、模型训练到推理部署的全套流程。有了它你基本不需要直接操作PyTorch去写训练循环大大降低了上手门槛。安装它的时候会自动把依赖的PyTorch版本一起装好所以我建议先装torch再装ultralytics避免它自动拉一个和你CUDA不匹配的torch版本。全部装完后可以用一行命令验证YOLO能否跑起来from ultralytics import YOLO model YOLO(yolov8n.pt) model.predict(test.jpg, saveTrue)程序能正常输出检测结果说明环境完备可以进入下一步。4. 数据集模型效果的真正天花板做深度学习项目最深刻的体会是算法决定下限数据决定上限。对车辆识别来说模型的mAP能到多少七成取决于你的训练数据质量。这一节把我用到的数据集方案和标注处理细节完整讲清楚。4.1 使用公开数据集作为底座再用自有数据微调公开车辆数据集我用了两个比较成熟的UA-DETRAC城市交通场景车辆检测数据集和BDD100K伯克利自动驾驶数据集包含10万张图像、8个类别。这两个数据集的优势是场景覆盖广——白天、夜晚、晴天、雨天都有车辆包含轿车、SUV、卡车、公交等多种类型泛化能力有了基本保障。但公开数据集有个问题场景和你的实际部署环境有差异。停车场监控的俯拍角度、光照条件、画面分辨率都和公开数据集不同。所以我的做法是用自己的摄像头实际采集两三天数据大概1000到2000张图片标注好后和公开数据集混合训练。这样模型既学到了一般性的车辆特征又适应了你具体场景的视觉特殊性。实测下来这个策略非常有效。只用公开数据集训练的模型在我场景上mAP50约88%加入自有数据微调后提升到了93%以上误检率降低了一半还多。4.2 YOLO标注格式与数据整理细节YOLO系列的标注格式和常见的VOC、COCO格式不一样它是归一化的txt文件每行代表一个目标类别id x_center y_center width height所有值都是相对于图像宽度和高度的比例范围在0到1之间。比如一张1920x1080的图上有一个车辆框中心点坐标是(960, 540)宽400高300那么对应的标注就是0 0.5 0.5 0.2083 0.2778如果你的车辆类别有5种轿车、SUV、货车、公交、其他那类别id分别就是0到4。标注工具我用的是LabelImg或Label Studio界面操作容易上手画框选类别保存后自动生成对应的txt文件。标注时有个关键习惯宁可框大一点也不要框小。框到车辆边缘非常贴合时模型训练时反而容易学到错误的边界特征稍微多留一到两像素的余量训练更稳定。目录结构也需要注意YOLO要求的目录组织方式是datasets/ vehicles/ images/ train/ val/ labels/ train/ val/images和labels下的train、val文件夹一一对应同名图片和同名标注文件配对。训练集和验证集按9:1划分验证集不参与训练用来评估模型的真实泛化能力。4.3 数据增强策略实测经验数据增强是防止过拟合、提高模型泛化能力的关键。Ultralytics库默认就开启了Mosaic增强——把4张图随机拼接成一张图训练这个策略对小目标检测特别有效车辆被缩小之后模型能学到尺寸更小的目标特征。我在此基础上还额外开了水平翻转、随机色调和饱和度调整、轻微旋转和缩放。这里提一个反面教训一开始我把旋转角度加大到30度结果模型在真实俯拍场景下检测率反而下降了。后来想明白真实摄像头是固定的车辆不会倒着开大幅旋转生成的数据不符合实际分布反而干扰了模型学习。所以合成的增强数据一定要和真实场景特征相符不是越“强”越好。5. 模型选型与训练调优从原理到实际参数YOLO系列发展到现在有YOLOv5、YOLOv8、YOLOv9等多个版本新手经常会问“到底选哪个”。我的建议非常简单直接直接用YOLOv8原因后面细说。5.1 为什么选YOLOv8而不是其他版本YOLOv5是2015年的经典版本资料最多、社区最成熟很多老项目都在用。但它的劣势也明显代码不是官方维护是社区移植的部分功能更新滞后新数据增强、新训练技巧不会第一时间融入。YOLOv8是Ultralytics官方维护的版本使用体验最顺滑。它有以下几个关键优势训练、推理、导出ONNX/TensorRT全流程API化一个Python包搞定内置了最新的训练技巧和增强策略训练细节不用自己调得很好模型结构上引入C2f模块和Anchor-Free检测头精度和速度都有提升部署生态好导出到TensorRT之后在边缘设备上表现很稳定YOLOv8有n/s/m/l/x五个规格复杂度依次递增。我在实际项目中的对比数据是n模型虽然在最快速度上占优但在小目标车辆检测上明显偏弱s和m模型在精度和速度之间最均衡是我主力使用的规格l和x适合对精度要求极高且GPU算力充足的场景。模型规格参数量输入尺寸推理耗时(GPU)mAP50实测适用场景YOLOv8n3.2M640约3ms约86%算力受限的嵌入式设备YOLOv8s11.2M640约6ms约91%普通GPU实时监控YOLOv8m25.9M640约10ms约94%精度优先的服务器场景5.2 训练参数详解这几项必须手动调Ultralytics默认的训练参数可以直接跑通但要用好还是得自己调整几个关键参数。我在这个项目里的配置如下from ultralytics import YOLO model YOLO(yolov8s.pt) results model.train( datavehicles.yaml, epochs100, imgsz640, batch16, lr00.01, optimizerSGD, patience20, device0, workers4, cacheTrue, )几个关键参数逐个说明epochs训练轮数。100轮在车辆识别这个任务上是够用的不需要盲目追求大轮数。训练后期如果损失不再下降配合patience参数会自动早停。batch批大小受显卡显存限制。16以上需要至少8G显存如果你的显卡只有6G降到8或4也可以。批大小太小会导致训练不稳定。lr0初始学习率0.01是SGD优化器的常用值使用Adam优化器时建议降到0.001。imgsz输入分辨率640是精度和速度的平衡点。追求小目标检测精度可以提到960代价是训练和推理时间增加约一倍。整个训练过程在单张3080显卡上大约需要两到三个小时100轮结束时results文件夹里会保存最佳模型权重best.pt和最后一轮权重last.pt。测试时用best.pt它是在验证集上表现最好的版本不是最后一轮。5.3 训练曲线怎么读别被“val_loss下降”骗了训练完成后Ultralytics会自动生成results.png里面有loss曲线和指标曲线。很多人只看训练loss降了就以为训练成功了这是个典型误区。真实项目里一定要关注验证集指标val/box_loss验证集的目标框回归损失这个值持续下降说明定位越来越准val/cls_loss验证集的分类损失持续下降说明类别判断越来越准metrics/mAP50IoU阈值为0.5时的平均精度是衡量整体检测质量的核心指标metrics/mAP50-95更严格的评价指标横跨多个IoU阈值数值通常比mAP50低不用过分在意绝对值关注上升趋势即可有一个反差现象我必须强调训练loss降得很好但val/mAP数值上不去说明模型过拟合了——它把训练数据背下来了换了新场景就不认识了。解决过拟合的优先级顺序是增加数据 → 增强数据多样性 → 减少模型复杂度 → 加入Dropout正则化。优先级从高到低不建议一上来就换小模型。5.4 类别不均衡的处理停车场的车辆分布极度不均轿车可能占了70%货车只有不到3%。如果不做处理模型会倾向于把所有车都识别成轿车货车检测精度惨不忍睹。处理手段我在这个项目里用了两个一是针对少样本类别做过采样增强在数据加载时给货车、公交车这些低频类别更高的采样权重二是设置类别权重偏置class_weights参数让少样本类别的loss在反向传播时获得更大权重。补齐之后原来mAP50只有60%的货车类别提高到了85%以上整体指标被拉平了很多。6. 车辆识别的核心代码实现检测、计数、车牌一次说清环境配好、模型训练好之后就到了写业务逻辑的阶段。我用ultralytics的推理接口快速实现了一套完整的车辆识别与计数流程代码直接可用结构清晰拿来改改就能适配自己的摄像头画面。6.1 使用训练好的模型进行视频流检测下面这段代码是整套系统的主循环从摄像头读取视频帧送入YOLO模型推理在画面上绘制检测框和标签import cv2 from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) cap cv2.VideoCapture(rtsp://user:password192.168.1.64:554/stream1) while True: success, frame cap.read() if not success: break results model.predict(frame, conf0.5, iou0.45, imgsz640, verboseFalse) for r in results: boxes r.boxes for box in boxes: x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) cls_id int(box.cls[0].item()) conf float(box.conf[0].item()) label f{model.names[cls_id]} {conf:.2f} cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(frame, label, (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) cv2.imshow(Vehicle Detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()关键参数说明conf0.5是置信度阈值低于这个值的框会被过滤掉。实际调试时如果发现漏检多把这个值降到0.3如果发现误检多升到0.6到0.7之间。iou0.45是NMS的IoU阈值控制重叠框的去重严苛程度一般来说保持默认0.45到0.5之间就好。model.predict()里的verboseFalse是我特别建议设置的否则每一帧的推理日志都会刷屏终端会被日志淹没影响后续输出的观察。6.2 车流计数用简单的中心点跟踪搞定车辆计数不需要特别复杂的目标追踪算法。在出入口这种固定场景下我用一个中心点区域判断法就实现了准确率不错的进出计数line_y 400 # 计数线位置根据自家摄像头画面调整 count_in 0 count_out 0 previous_centers {} while True: success, frame cap.read() if not success: break results model.predict(frame, conf0.5, iou0.45, verboseFalse) current_centers {} for r in results: for box in r.boxes: x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) center_x (x1 x2) // 2 center_y (y1 y2) // 2 # 判断车辆中心点是否跨越计数线 for prev_id, prev_center in previous_centers.items(): if abs(center_y - prev_center[1]) 50 and abs(center_x - prev_center[0]) 100: if prev_center[1] line_y and center_y line_y: count_in 1 elif prev_center[1] line_y and center_y line_y: count_out 1 previous_centers current_centers这个方法的逻辑是对每一辆车记录它上一帧和当前帧的中心点位置如果上一帧在计数线的一侧、当前帧到了另一侧就判定为一次跨线。它没有做真正的目标追踪但依靠固定摄像头下相邻帧车辆位置变化连续这个事实就能达到实用的计数效果。如果你要应对车辆密集、严重遮挡的复杂场景那才需要引入ByteTrack或DeepSORT这类真正的多目标跟踪算法。6.3 车牌识别模块的实操细节车牌识别的链路是先用检测结果定位车牌区域再对车牌区域做OCR识别。检测车牌的这一步也可以用一个专门训练的车牌检测YOLO模型但为了减少部署复杂度我直接用车辆框下半部分作为车牌候选区域再用HyperLPR库识别from hyperlpr import HyperLPR def recognize_plate(vehicle_img): # 车辆框的下半部分通常是车牌位置 h, w vehicle_img.shape[:2] plate_region vehicle_img[int(h * 0.6):h, int(w * 0.1):int(w * 0.9)] result HyperLPR(plate_region) if result and result[0] and result[0][1] 0.7: plate_number result[0][0] confidence result[0][1] return plate_number, confidence return None, 0.0这个方案只适用于车辆正对摄像头、车牌清晰的情况。如果你的场景里车辆角度多样车牌可能被遮挡或者旋转那就得训练专门的车牌检测模型。我用的HyperLPR是开源方案识别中文车牌效果不错蓝牌和绿牌新能源都能处理。车牌识别有三个实际工程经验要分享一是识别前一定要对车牌区域做预处理灰度化加二值化能明显提升在暗光下的识别率二是置信度阈值建议设在0.7以上低于这个值的结果宁可丢弃也不要写入数据库否则会产生大量脏数据三是隐私合规问题——车牌是个人数据整个系统要设计数据脱敏机制图片定期清理数据库访问做权限控制这个在交付商业项目时是硬要求。7. 部署优化与实测结果模型能不能落地用数字说话模型训练完之后不是万事大吉了在真实摄像头场景下的部署和性能优化才是真正拉开经验差距的地方。我在这里记录了从模型导出到实际运行的全过程和数字。7.1 模型导出从PyTorch权重到ONNX再到TensorRTPyTorch训练出来的.pt权重文件必须经过格式转换才能高效部署。我的转换链路是.pt→ ONNX → TensorRT。ONNX是中间格式用途是验证模型结构正确性TensorRT是NVIDIA显卡上的高性能推理引擎推理速度比PyTorch原始模式快3到5倍。导出ONNX的命令from ultralytics import YOLO model YOLO(best.pt) model.export(formatonnx, imgsz640, simplifyTrue)导出TensorRT的命令model.export(formatengine, imgsz640, halfTrue, device0)halfTrue开启FP16半精度推理在兼容的NVIDIA显卡上速度提升明显精度损失很小。实测TensorRT引擎的推理速度比PyTorch原生模式快大约4倍这正是它能支持多路视频流实时处理的关键。7.2 实测推理性能数据我在三台不同设备上做了推理性能测试测试条件是1080p视频流、640x640输入分辨率设备推理引擎单帧推理耗时处理器路数RTX 3080TensorRT FP16约8ms8路以上RTX 3060TensorRT FP16约15ms4-6路Jetson Orin NanoTensorRT FP16约25ms2-4路纯CPU (i7-12700)ONNX Runtime约150ms只适合测试Jetson Orin Nano这种低功耗边缘设备是部署在停车场现场很好的选择功耗低、体积小不需要专门机房。如果现场只有CPU那就得接受帧率大幅下降的事实适合做定时抓拍检测不适合做实时连续检测。7.3 实际场景下的精度表现在真实停车场出入口场景跑了一周统计结果如下指标白天(8:00-18:00)夜间(20:00-6:00)车辆检测mAP5095.6%88.9%车辆计数准确率98.2%93.7%车牌识别准确率97.1%89.3%平均单帧处理耗时8.2ms8.5ms夜间性能下降的主要原因是红外补光下的画面存在大量噪点以及车辆大灯造成过曝。针对夜间场景有两个可选优化方向一是采集夜间数据单独微调模型二是图像预处理加入去噪和自适应直方图均衡化步骤。时间允许的话两个方案都做效果叠加最显著。8. 踩坑记录环境冲突、显存溢出、识别精度附排查链路做项目不踩坑是不可能的我把这次开发过程中遇到的三个最典型的坑完整记录下来连同排查思路一起希望帮大家跳过这些性价比极低的调试过程。8.1 CUDA out of memory不是显存真的不够训练中段报CUDA out of memory是出现频率最高的错误。第一次遇到时我第一反应是调小batch从16降到8、又降到4还是报错。后来检查日志发现训练前期的显存占用是正常的是训练到第30轮左右才爆的。排查过程逐步展开先确认是不是其他程序占用显存运行nvidia-smi查看进程列表发现显存基本被清空排除了外部干扰。再怀疑是不是输入图像尺寸有问题检查数据集图片尺寸正常。最后想到Mosaic增强——这个增强在训练后期会触发它会把4张图拼接成一张用更大的特征尺度训练显存消耗激增。解决办法有两种训练时加mosaic0.5降低Mosaic增强的使用权重或者把cacheTrue改为cacheFalse减少缓存数据集占用的内存。这个问题也让我养成了一个习惯跑训练前先运行nvidia-smi确认显存温泉是干净的再用小模型小batch试跑一个epoch验证显存峰值没问题再上完整训练。8.2 中文路径导致的加载失败把项目目录放在带中文的路径下训练时数据加载总是报错提示找不到文件。报错信息里路径显示是乱码但文件确实存在。当时排查了很长时间一度以为是数据目录结构写错了。最后定位到是编码问题Python在Windows系统下读取包含中文的路径时在某些环境下默认编码不是UTF-8导致文件路径解析错误。解决办法也很简单确保从虚拟环境创建到项目目录的整个路径都是纯英文。这也是为什么很多深度学习项目代码仓库里的目录名都是英文不只是习惯确实能规避一系列底层问题。做深度学习项目的基础习惯所有目录、文件名、标注类别名一律用英文小写加下划线全程不用中文和空格可以避开大量莫名其妙的坑。8.3 小目标车辆漏检不是模型的问题是标签的问题测试时发现画面远处的车辆经常检测不到但近处的车没问题。最初怀疑是模型容量不够换了大模型YOLOv8m之后改善有限排除模型因素。然后把注意力转到输入分辨率上从640拉到960之后远车检测率确实提升了一些但仍然不够理想。最后是在检查标注文件时找到了根源很多远处车辆的标注框只有二三十个像素这类小目标在训练时贡献的loss很小模型没有足够动力去学习它们。解决办法分两步一是对标注数据做预处理把所有标注框小于一定像素我用的阈值是15x15像素的目标放大到合适的尺寸再训练二是专门采集一些远处车辆的数据增加小目标在数据集中的占比。调整后小目标的mAP从原来的62%提升到了80%以上。小目标检测问题往往被误认为是模型不够强但实际上可以从数据层面解决。先检查标注质量再做针对性数据补充最后才考虑换更大的模型——这个排查顺序在目标检测领域是通用的。做这个项目最大的收获其实不在模型本身而是理解了系统思维的重要性一个车辆识别系统环境、数据、模型、部署每个环节都可能有坑任何一环掉链子都会让整个系统不可用。我个人的经验是当检测效果不好的时候先别急着调模型回过头检查数据和场景适配往往能找到比调参更有效的解决方案。另外建议第一次做这类项目的朋友可以从YOLOv8官方预训练权重开始用自带的数据集跑通全流程熟悉了每个环节后再换成自己的数据这会让你对整套系统的理解扎实很多。
