★ FEATURED ARTICLE 车辆识别可以说是计算机视觉里最接地气的落地场景之一。园区出入口的车牌抓拍、停车场剩余车位统计、高速路口的车型分类、城市道路的车流量分析背后都离不开一个基础能力在画面里把车辆位置找出来、把车辆类别分出来。我接触过不少接到这类需求的团队一开始的直觉都是自己买台GPU服务器搭环境结果在驱动、CUDA、框架版本这堆事情上耗掉两三个星期后来换成ModelArts这类一站式开发平台整个项目的节奏完全不一样数据集备好之后训练到上线基本是按天算的。这篇文章我按自己实际跑通一个车辆识别项目的路径来写从需求拆解、数据标注到ModelArts训练调优再到部署调用和问题排查整个过程不追求最新的算法用的全是成熟方案。适合三类人看一是准备用ModelArts做目标检测的开发者二是手头攒了一批车辆图片但不知道怎么变成模型的人三是想快速验证方案可行性的小团队。读完你应该能照着自己走一遍少踩几个我踩过的坑。1. 项目拆解车辆识别到底要做哪几件事1.1 先分清你要的是目标检测还是车牌识别“车辆识别”这个词在实际项目里其实很模糊至少可以拆成三种完全不同的任务。第一种是车辆检测也就是在画面里用框把每一辆车框出来顺带区分车型比如轿车、SUV、卡车、公交车。这是最常见的需求停车场统计车位、路口分析车流、园区车辆管控用的都是这个能力。第二种是车牌识别这个本质上是OCR问题流程通常是先定位车牌区域再识别上面的字符跟车辆本身长什么样关系不大。第三种是车辆属性识别比如判断车辆颜色、品牌、具体车系通常需要细粒度识别模型比前两种要难一些。我看到过很多项目翻车就是因为需求没拆清楚。用户说“我要个车辆识别”交付团队吭哧吭哧训练了个车型分类模型结果对方真正想要的是“车进场的时候自动抬杆顺便把车牌记录下来”。所以动手之前必须把需求问明白问清楚“识别出来之后要干什么”再决定用什么方案。如果你的需求恰好是“把车框出来统计数量或者判断车型”那这篇文章的方案对你就是可用的。图像分类和目标检测之间的差别可以用一个例子说清楚分类模型看到一张图只能告诉你“里面有车”检测模型能告诉你“图里有三辆车一辆出租车在左上角一辆卡车在中间偏右”。停车场场景要数车、要定位就必须走检测路线。ModelArts里对应的任务类型是“物体检测”这个别选错。1.2 为什么选ModelArts而不自建GPU环境自建环境最真实的体验是你以为的瓶颈是训练时间长实际的瓶颈是环境装不上。显卡驱动、CUDA版本、cuDNN、PyTorch或者TensorFlow版本四者之间任何一组不匹配都能让一个正经工程师折腾一个晚上。好不容易装好环境训练完还要考虑怎么提供服务。总不能为了一个接口专门再维护一台裸GPU服务器除了模型还有鉴权、负载均衡、日志监控一堆事。ModelArts这个平台解决的就是“从数据到服务”的整条链路问题。数据标注、训练任务、模型评估、在线部署在同一个界面里完成算力按需租用不用养机器。对车辆识别这种成熟任务来说还有一个很关键的优势自动学习。你甚至可以不写代码把标注好的数据传上去平台会自动选模型、自动训练先跑出一个可用的结果来。我个人的选型逻辑是这样的如果做的是研究型项目要改网络结构、要写自定义算子那ModelArts不一定是最合适的本地环境自由度更高。但车辆识别属于标准视觉任务YOLO系列这类成熟检测算法已经足够覆盖绝大多数场景这类任务放在托管平台上效率反而最高。打个比方自建环境像自己买菜做饭平台模式像去食堂食堂的菜不一定符合你所有口味但绝大多数时候比自己做省事得多。1.3 快速梳理出端到端的处理链路我自己习惯把车辆识别项目拆成六步每一步在ModelArts上都有对应的落脚点需求梳理明确检测目标、类别定义、应用场景、性能指标。数据准备采集图片、清洗数据、标注目标框。模型训练选算法、配参数、跑训练任务。效果评估看指标、看badcase、决定是否迭代。部署上线创建推理服务、对接业务系统。数据回流把线上产生的误检漏检样本收回来补进训练集。这个链路里第2到第5步基本都能在ModelArts体系内闭环数据版本、模型版本、服务版本之间自动关联。这一点对后期维护极其重要。我自己吃过“模型迭代了几个版本最后分不清线上跑的是哪一版”的亏有版本管理之后回滚和对比都清楚很多。2. 数据准备车辆识别的上限在标注不在模型2.1 数据集从哪里来数量和质量怎么权衡先说数据集来源常见的有三类。第一类是公开数据集。目标检测领域常用数据集里都有车辆类别像COCO数据集里就有car、truck、bus这些类。直接用现成数据集的优点是省时间缺点是场景和你的实际应用大概率对不上。公开数据集多为自然驾驶场景如果你要处理的是停车场俯拍视角直接拿公开数据训练的模型落地效果会打折扣。所以公开数据适合做预训练或者补充样本不建议完全依赖。第二类是自采数据。视频监控录像抽帧是最省力的方式一段1080P的监控视频按每秒一帧抽出来一个小时的视频能出几千张图再去重筛选真正可用的比例看场景复杂度。注意采集的画面要覆盖项目真实环境这个点极其重要后面会反复提。第三类是网络图片或者合成数据。网络图片要注意版权问题合成数据目前在车辆这类刚性物体上效果还行但和真实光照、遮挡条件仍有差距只建议作为补充。数量上我给一个粗标准单类别至少一两千个标注框起步类别多就按比例增加。如果要做十个类别总图片量最好到一万张以上。但数据质量比绝对数量更重要不少团队犯的错误是训练集看起来很多实际上全是同一个停车场、同一种光照、同一个角度拍出来的。这种数据训练出来的模型换一个场景就废。我做过一个实验对比同样是两千张图一组是单一场景反复抽帧得到的一组是刻意覆盖了白天、夜间、雨天、不同角度的后者训练出的模型在新场景上的表现明显更好。所以制定采集计划时最好先列一个覆盖矩阵比如下面这样场景维度建议覆盖情况说明光照白天、黄昏、夜间、逆光夜间样本最容易缺直接影响夜间召回率天气晴天、阴天、雨天、雾天雨天反光和水渍会让模型表现明显下降视角平视、俯视、倾斜高空俯拍和路边水平视角的车辆外观差异很大距离近景、中景、远景小目标远景小目标检测难度最高需要专门补充密度单车、稀疏、密集遮挡停车场高峰时段车辆密集互相遮挡很常见2.2 一套可以直接抄作业的车辆标注规范数据准备好了下一步是标注。ModelArts里物体检测用的是矩形框标注操作本身不难难的是标注规范是否统一。规范不统一模型就会学到一堆错误的边界表现就是loss降不下去或者验证集指标一直上不去。我每次做车辆检测项目都会先定一份标注规范文档几个关键点长期验证下来非常有效标注框要紧贴车身边缘包含完整车身不要留大段背景也尽量不要把后视镜、车牌这些部件切掉。车辆严重遮挡时如果遮挡面积超过一半可以不标注轻微遮挡就按可见轮廓正常标注。一辆车只标一个框不要把多个紧挨着的车辆框成一个大框。小目标不能被忽略。画面里只有二三十个像素大小的车辆只要清晰可辨就要标注出来这是提升小目标召回率的重要前提。类别定义提前敲死。举个例子越野车算SUV还是算卡车三轮车是不是要单独一类这些问题不提前统一标注返工率极高。另外提一句容易忽略的标注类别数量别贪多。实际项目里车辆类别定三到五类是最舒服的比如car、truck、bus、motorcycle最多加一个special_vehicle。类别越细单类样本数量要求越高标注难度也越大模型难度同步上升。很多时候“车”和“卡车”的分类比“具体是哪个品牌哪年款”实用得多。标注工作本身非常耗时但它是整个项目里性价比最高的一步。用一句行业里常说但确实有理的话标注质量决定模型上限训练只是尽可能逼近这个上限。2.3 用智能标注和多人协作把时间省下来纯人工标注确实让人崩溃两万张图画框熟练标注员也得半个月。ModelArts的智能标注功能在这里能帮上大忙。智能标注的原理并不神秘先用平台预置的检测模型对图片做一遍推理生成预标注框然后由人工进入界面检查修改确认正确的框直接保留错的拖动修改或者删除漏掉的目标人工补框。对普通场景的图片智能标注能省下差不多一半到七成的时间。实际操作经验是第一步先用人工标注两三百张高质量数据训练一个初始模型然后让这个模型去预标注剩余图片。这种做法比直接用平台通用模型预标注的准确率要高得多因为初始模型已经见过你场景的图片特征了。这里必须提醒一句智能标注审核时别只顾着修正框的位置。最常见的坑是模型漏检的目标你完全没注意到尤其是小目标车辆。我自己的习惯是审核完一批图片后专门把画面放大逐个区域检查有没有漏掉的车特别是画面边缘和车辆重叠区域。漏检比框不准对最终模型精度伤害大得多。多人协作方面ModelArts支持把标注任务拆给多个成员并行处理每人的进度和产出可追踪。团队协作时要注意的是每个人对“框得多紧算紧”的理解不一样建议在正式动手前先拉一个线上会议用三五张典型图片统一操作标准避免各标各的。3. 模型训练从快速跑通到把精度调到能用3.1 创建训练任务前的关键选择数据准备完进入训练阶段。ModelArts上训练一个车辆检测模型有三条路可以选。第一条路是自动学习。如果你是第一次接触这个平台或者只想快速验证“这批数据能不能训出个能用的模型”直接用自动学习的物体检测功能。它不需要你写任何代码也不需要关心算法细节平台会自动帮你完成模型选择和超参数配置。缺点是灵活性低类别多、场景复杂时精度天花板比较有限。我的用法是拿它跑baseline用它做后续实验的参照物。第二条路是订阅算法市场里的现成检测算法。ModelArts算法市场里能找到不少开源检测算法的打包版本比如YOLO系列的实现订阅之后直接作为训练入口把数据路径和超参数填进去就能跑。这条路的灵活度比自动学习高又不要求自己写训练脚本适合大多数工程落地场景。第三条路是自带代码。把本地写好的训练脚本上传到OBS然后创建训练任务指定入口脚本、框架版本、算力规格。适合对算法有定制需求、或者已经有一套自己调好的训练代码的团队。框架选择上车辆检测目前PyTorch生态最完整YOLO系列的成熟实现几乎都是PyTorch。如果你选择的算力规格是昇腾MindSpore版本在算子适配和性能优化上更好但需要确认你选的算法实现是否支持。我自己的习惯是不涉及昇腾算力就无脑选PyTorch省心。另外创建训练任务前要把数据格式准备好。ModelArts的物体检测任务一般支持COCO格式标注文件本地方便的话也可以转成VOC格式。注意图片和标注文件的目录结构要按平台约定的方式组织这个在平台的算法说明里通常都有别想当然混放。3.2 训练超参数与调参顺序训练参数是新手最容易懵的地方我列一组车辆检测任务比较合理的基础配置作为参照参数推荐值说明输入图片尺寸640x640尺寸越大细节越多但显存和耗时也成倍上升批量大小 batch_size16或32根据显卡显存调整显存不够就调小训练轮数 epochs100轮左右配合早停机制防止无效训练初始学习率 lr0.001到0.01优化器不同选择不同通常配合warmup优化器SGD或AdamWSGD配动量收敛稳AdamW类收敛快但要注意过拟合数据增强Mosaic、HSV扰动、随机翻转增强手段多车辆检测里Mosaic效果明显这几个参数背后各有各的道理。学习率相当于下山的步幅步幅太大容易在损失曲线上来回震荡太小则训练慢、容易困在局部最低点。批量大小决定了每次更新参数时用多少样本算梯度批量越大梯度估计越稳定但显存是硬约束。输入分辨率则是直接决定模型能看到多少细节分辨率从640提高到1280小目标的检测能力在多数场景下会有明显提升代价是推理速度几乎翻倍。调参顺序有个经验性的方法论先跑通再调优别一上来就追求最优参数。第一步用上述基础配置完整跑一百轮确认流程没毛病、loss能降第二步调学习率策略从固定学习率改成warmup加余弦退火通常能稳定涨两三个点的mAP第三步动数据增强和输入尺寸。我用这个顺序跑过几次车辆检测项目一般都能在可控的试验次数内拿到满意结果。有一组实际训练记录可以参考是一个停车场俯拍视角的车辆检测项目约八千张训练图片、五类目标阶段改动内容mAP0.5备注baseline640输入、100轮、默认增强0.62能跑通但小目标漏检明显增强加Mosaic、HSV、随机翻转0.70整体明显提升加数据补充夜间和雨天样本各一千张0.76夜间召回率是主要贡献调推理调整置信度阈值和NMS参数0.77指标涨幅小但实际误检明显减少这个趋势不是个例数据增强和数据补充带来的收益通常比换一个更复杂的骨干网络明显得多。3.3 评估模型时别只看总mAP训练完ModelArts会输出一组评估指标最常见的是mAP0.5和mAP0.5:0.95以及precision、recall。简单解释一下mAP0.5的意思是预测框和真实标注框的重叠度超过50%就认为这个检测是命中的再看所有类别的平均精度。mAP0.5:0.95是更严格的指标对框位置的精确度要求更高。但只看总mAP是个典型的坑。我曾经做过一个项目总mAP到0.78看上去已经不错用户拿真实视频一测夜间漏检非常严重。回看数据才发现训练集里夜间图片只占不到一成。按类别、按时段、按目标大小分别统计精度和召回才能真正找到项目的问题所在。一个有效方法是把验证集预测错误的图片全部导出来肉眼过一遍你会发现模型犯的错误往往集中在某几类特定场景上比如深色车夜间看不清、远景小目标漏检、卡车和公交车互相混淆。确认模型效果达标后生成模型产物时也要注意格式。ModelArts训练任务可以导出多种格式部署在线服务通常用平台默认格式如果要在本地做推理验证可以导出常见的模型格式。量化、剪枝之类的压缩操作能显著提升推理速度但会带来一定的精度损失上线前务必重新在验证集上测一遍。4. 部署上线车辆识别真正难的部分在后面4.1 在线服务、批量推理还是边缘部署模型训练好了下一步是把它变成可以调用的服务。ModelArts提供三种常见的部署方式选错会直接影响使用体验和成本。在线服务适合实时性要求高的场景比如停车场道闸、园区出入口抓拍。图片推送到服务接口几百毫秒内返回检测结果。在线服务可以按需配置计算资源支持实例数和规格调整还能设置并发能力。这是大多数车辆识别项目的默认选择。批量推理适合处理大量离线数据比如要识别存储了一个月的监控录像按时按量跑一次就行。批量推理不要求实时响应可以使用更便宜的算力规格成本控制上优势明显。我自己处理历史视频数据时都走批量推理费用大概是跑在线服务的几分之一。边缘部署适合摄像头现场环境复杂、视频不能出内网、或者带宽受限的场景。把模型转换后部署到边缘设备上图片在本地完成推理只把结构化结果传回服务器。代价是边缘设备的算力不如云端模型要做轻量化和裁剪精度会有损失。选型就一句话对延迟敏感、流量在线用在线服务大批量离线、对时间不敏感用批量推理数据不出内网、离线场景固定用边缘部署。4.2 接口调用与结果解析实战在线服务创建好后ModelArts会生成一个调用地址。实际对接业务系统时需要处理鉴权、请求格式、返回解析三件事。鉴权方面在线服务接口通常要求带签名信息或者临时凭证这个在平台的调用指南里有现成说明按步骤生成即可。代码层面一个典型的调用流程是读取本地图片base64编码组装请求体发送HTTP请求拿到返回结果后解析检测框。我把常用的一段调用示例放在下面。import requests import base64 # 图片转base64 with open(car.jpg, rb) as f: img_b64 base64.b64encode(f.read()).decode() # 组装请求体检测阈值可根据实际场景调整 payload { images: [img_b64], # 也有的服务使用url字段按模型文档来 parameters: { threshold: 0.5 } } headers { Authorization: 你的鉴权信息, Content-Type: application/json } endpoint https://你的在线服务地址/v1/infers resp requests.post(endpoint, jsonpayload, headersheaders) data resp.json() # 解析检测结果通常包含类别、置信度、目标框坐标 for item in data.get(detection_result, []): category item[category] score item[score] bbox item[location] # 注意坐标格式可能是[x, y, w, h]也可能是[x1, y1, x2, y2] print(f类别: {category}, 置信度: {score:.2f}, 位置: {bbox})返回坐标的解析是踩坑高发区。有的接口返回的是相对于模型输入尺寸的坐标有的是归一化坐标还有的直接给原图坐标。拿到坐标后要习惯性做校验把框画出来对比原图位置确认坐标是按什么基准返回的。坐标映射错了业务系统拿到的框位置就会偏移这种问题排查起来特别耗时。另外一个常见问题是请求体过大base64编码会让图片体积膨胀约三分之一一张几兆的照片编码后可能达到四兆接口容易超时。解决办法是调用前先把图片压缩到合适的尺寸比如长边压到1280像素以内质量损失不大但请求速度提升明显。4.3 上线后最常见的坑和排查清单把车辆识别服务真正跑起来之后问题的性质会从“模型学得好不好”变成“系统稳不稳定、结果准不准”。下面这些是我实际遇到过的典型问题整理成了一张排查清单现象可能原因排查与解决方法接口返回401或鉴权失败鉴权信息过期、系统时间偏差检查凭证有效期重新生成并确认服务器时间准确请求超时或返回体过大图片base64后体积过大先压缩图片再调用或改用对象存储URL方式传入检测框位置明显偏移返回坐标是归一化值业务端按像素坐标使用确认坐标基准归一化值要乘回原图宽高夜间漏检严重训练集夜间样本不足或图像亮度处理不当补充夜间真实样本适当预处理提亮同一辆车出现多个重复框置信度阈值或NMS抑制参数不合适调高置信度阈值或调整NMS重叠阈值远景小目标完全检测不到输入分辨率偏低小目标训练样本不足提高输入分辨率专门补一批小目标素材自测正常线上效果差摄像头角度、画质与训练集分布不一致采集线上真实图片加入训练集重新迭代这里有一个值得单独说的事项NMS参数。车辆检测推理时同一辆车经常会被多个候选框框住NMS的作用是合并重叠框、保留置信度最高的那一个。如果业务场景是密集停车场车身互相遮挡严重NMS参数过于激进会把本该保留的框一并抑制掉。实际调优时我倾向把置信度阈值稍微调高到0.4到0.5之间把NMS阈值控制在0.45左右在漏检和重复框之间取一个平衡点。上线阶段还有一个经验不要急着把模型直接接入生产系统。先做一到两周的旁路验证把线上真实图片也送到旧流程里跑一遍对比记录模型的表现后再决定是否切换。这个操作成本不高但能避免很多“上线后才发现问题”的尴尬。4.4 成本控制与团队协作的经验最后聊一聊很多人关心的成本问题。用过ModelArts的都知道算力规格选高一点训练费用涨得很快。成本控制有几个实际操作有效的手段。训练阶段先用小规格、小epoch数跑通流程确认代码和数据格式没问题后再开长训练。如果只是想验证某个改动有没有效果先训二十轮看loss走向比直接跑一百轮省得多。训练任务结束后及时释放或停止实例避免空闲状态的持续计费。在线服务如果夜间没有业务流量可以配置自动降级到零实例或者停用第二天再启动。批量推理处理历史数据的时候允许排队等待选规格低一些的算力跑费用能省下来一大截。团队协作上车辆识别项目往往不是一个人独立完成的标注、训练、交付可能要分给不同角色。ModelArts的版本管理功能建议从第一天就用起来数据版本和模型版本要一一对应标注清楚。迭代流程我习惯这样跑训练一个版本模型跑到验证集上收集badcase把badcase图片导出来标注补充再开新一轮训练。这个闭环每转一圈模型在真实场景的表现就稳一步。数据回流机制也值得认真建设。线上服务跑起来之后会源源不断产生误检和漏检样本这些样本是模型迭代最宝贵的素材。把线上服务周期性的预测结果保存下来由业务人员或标注员筛选错例定期补充进训练集。模型上线不是终点而是数据飞轮转起来的起点。我自己这些年跑视觉类项目最深的体会是很多人一上来就纠结用什么模型、要不要上最先进的算法但实际上车辆识别这类成熟任务模型选型的影响远小于数据分布的影响。ModelArts的价值是把从数据到部署这条路铺平了真正决定项目成败的仍然是你对自己场景数据的理解。建议拿到项目后先花一天时间把摄像头角度、时段、天气、车辆类型这些实际情况摸清楚再定标注规范和采集计划。这个准备工作做扎实了后面无论用自动学习还是一套YOLO代码结果都不会差到哪去。
阅读完成 · 觉得有帮助？
