我在给某省收费口做车辆识别的时候第一个选型就是百度飞桨EasyDL图像分类。收费口的车辆类型自动识别听起来像个很垂直的小功能实际上牵扯到数据采集、标签体系、模型训练、边缘部署、计费系统联调一整条链路。这个场景用EasyDL来做最大的好处是不用从零搭训练框架平台帮你把图像分类算法的工程细节吞掉了我们只需要把业务数据管好、把业务逻辑想清楚就能在几周内上线一套可用系统。这篇文章适合三类人看一类是想在收费站、停车场、物流园区做车辆分类的算法工程师一类是刚接触EasyDL、被各种术语绕晕的项目新人还有一类是纯粹想看一个图像分类项目怎么落地的朋友。我会把收费口车辆识别的需求拆解、数据准备、模型训练、部署集成、常见坑都过一遍很多细节是文档里不会写的现场经验。1. 需求与场景收费口车辆识别到底要解决什么1.1 一分钟讲清业务价值收费口每天经过的车辆类型五花八门小轿车、SUV、面包车、皮卡、轻卡、中卡、大货车、挂车、罐车、专项作业车。不同车型对应不同收费标准人工判断会有两个问题一是慢高峰期每辆车多停两秒后面就会排长队二是主观性强同样一辆改装面包车这个收费员算客车下一个收费员可能就算货车容易产生费用纠纷。所以这个项目的核心目标很直接当车辆驶入收费车道、触发地感线圈或者抓拍相机后系统自动给车辆拍一张照片通过图像分类模型识别出车辆类型再把结果推给收费系统。收费系统拿到类别后按既定费率计算金额同时在人工大屏上展示识别结果。如果置信度不够高就转人工复核。整体上把“看车、判型、放行”这个动作从十几秒压缩到一两秒。我在启动这个项目之前专门去现场蹲了一下午。观察下来发现收费口的相机角度其实是固定的车辆基本是正面或斜前方进入画面背景就是收费岗亭、雨棚和车道线。这个场景看起来简单但真正难在极端情况夜间大灯照射导致车身过曝、雨天反光、车头挂满泥浆、装货遮挡挡风玻璃、特殊车辆改装。模型要处理的不是“标准证件照”而是“现场随手拍”。1.2 图像分类和“检测”怎么选很多人一上来就问要不要用目标检测要不要用语义分割其实在收费口这个场景里答案通常是先用图像分类。要理解这个选择得先看业务到底需要什么信息。图像分类解决的是“这张图是什么类别”的问题。一张图片里车基本占据了画面主体车道内有隔离墩背景相对干净我们只需要给整张图一个标签比如“大型货车”。目标检测解决的是“图里有哪些目标、目标在哪里”的问题适合画面里有多个目标、需要定位的场景比如停车场里同时停了好几辆车要框出每一辆再分别识别。收费口抓拍时通常只有一辆车进入线圈区域而且收费系统的关注点是“这一辆车属于什么收费档位”并不需要知道它的精确坐标所以图像分类足够。当然也有例外。如果你们的相机触发时机不稳定比如前车还没完全驶离、后车已经进入画面拍到一张图里有两辆车这就麻烦了。这种情况下要么调整触发逻辑确保只拍单辆车要么在图像分类之前加一个检测模型先抠出车体再分类。我在实际项目中选择了“地感线圈触发单辆车裁剪”方案把图像分类模型的输入尽量控制好比在模型层解决多车问题要简单得多。2. EasyDL选型从平台能力到模型思路2.1 EasyDL图像分类的核心能力EasyDL是百度飞桨推出的零门槛AI训练平台图像分类是里面非常成熟的任务类型。我选中它不是因为它多炫酷而是因为它解决了项目交付里最麻烦的几个点。第一是自动训练。我们自己用PyTorch训练一个分类模型要处理数据加载、增强策略、网络结构选择、超参数搜索、过拟合判断这套流程没有几周稳定不下来。EasyDL把图像分类算法的基础工作打包了平台会自动做训练集和验证集划分自动选择网络结构和训练策略最终产出一个可以直接发布上线的模型。对收费口这种业务快速迭代的场景省下的时间非常可观。第二是数据处理工具。数据上传之后平台会自动做样本清理和检查能帮我们识别重复图片、疑似标注错误。它还会做图像增强包括翻转、裁剪、颜色扰动等。现场灯光、天气、遮挡情况多增强策略让模型泛化能力更强而不是死记硬背训练集。第三是部署灵活。EasyDL训练出的模型既可以在公有云上以API形式调用也可以导出成私有化包部署到本地服务器或者边缘盒子。收费口对网络可靠性和实时性有要求尤其很多收费车道部署在偏远路段公网不一定稳定边缘部署能力就成了刚需。这个后面我会详细说。另外EasyDL团队一直在更新底层的图像分类模型结构。你不需要知道它内部用的是ResNet还是EfficientNet还是别的Backbone只需要相信官方发布模型已经跑过大量评测。站在工程交付角度这比自己在GitHub上扒一个训练脚本要靠谱。2.2 为什么我不直接上Transformer这类最新图像分类模型订阅Arxiv或者逛技术社区的朋友应该注意到了近几年图像分类算法的风向在向Transformer架构迁移很多最新图像分类模型在ImageNet上的精度确实一路飙升。那为什么我不去微调一个开源的Vision Transformer反而用EasyDL原因很现实算法指标不等于工程表现。最新图像分类模型刷榜用的训练集和真实收费口数据分布差别非常大预训练权重对车辆顶部视角、夜间补光、雨雾遮挡这些概念的建模能力不一定强。就算我用迁移学习去微调数据量不够的话模型很容易在训练集上表现很好验证集一换就掉点。EasyDL的好处是平台内部会根据数据规模自动选择合适的基础模型也会做集成策略降低单模型的不确定性。对收费口这种类别固定、场景固定的业务稳定比炫技重要得多。我见过不少团队拿一套最新的图像分类算法在公开数据集上刷出漂亮结果然后塞进实际场景被现场数据打得满地找牙。分类问题的本质是“数据分布建模”数据分布搞不定换什么模型都白搭。像森林图像分类也好收费口车辆识别也好归到根上都是在解决同一件事怎么把业务里的影像数据映射成稳定的类别标签。真正决定项目成败的永远是数据质量、标签边界、置信度策略和现场运维。3. 数据准备收费口样本的正确打开方式3.1 采集规范镜头怎么装、照片怎么拍EasyDL官方建议每个类别至少准备100张图片量越大效果越好。但我在收费口项目里发现比数量更重要的是覆盖度。固定相机拍出来的照片不同时段、不同天气、不同季节画面风格差很多。如果训练集里全是晴天上午的照片模型到了雨天夜班会彻底懵。我定的采集规范是这样的每个类别至少采集500张有效样本其中白班、夜班、凌晨各占三分之一晴天、阴天、雨天至少各覆盖一部分车头正面和斜前方角度都要有远近位置也要有差异。这里说的有效样本指的是车辆主体清晰、没有被栏杆或其他物体大面积遮挡、画面没有严重模糊的图。相机尽量安装在车道正前方偏上位置俯视角度控制在15到30度之间这个角度既能看清车头也能看到部分车顶轮廓有助于区分面包车和货车。采集时要注意隐私合规。车牌号属于个人信息虽然收费口抓拍本来就有业务需要但进入模型训练集之前最好对车牌区域做脱敏处理。EasyDL平台本身有数据权限管理但项目流程上我们还是会先把车牌打码避免模型在预测时过度依赖车牌特征。3.2 标注体系按收费标准定义类别标注是整个项目中最重要的决策点。收费口的车辆分类跟视觉上的“轿车/SUV/MPV”分类并不一样它要服从计价规则。我建议在开始标注之前先向收费业务方要一份车型分类标准把“收费标准中的类别”翻译成“图像里能看出来的类别”。举个例子有些省份的收费标准里客车按座位数分但座位数从图像里看不出来只能看到车身长短、车窗数量和车轴数。这时候就得跟业务方确认一个代理指标车长超过多少算大型客车轴数多少算大型货车。把这些规则写进标注说明文档标图的人才有据可依。否则标图员凭感觉标最后模型学到的边界跟收费规则对不上上线后计费就会乱。我在这个项目里把标签定成了8类小型客车、小型货车、中型货车、大型货车、挂车、专项作业车、摩托车、其他。其中“其他”类很关键用来兜底电动车、三轮车、特殊改装车等长尾情况。宁可给模型一个“不知道”的出口也不要逼它强行从8个真实类别里选一个错的。3.3 数据清洗与增强避免模型学歪很多项目死在数据清洗不是死在模型训练。EasyDL平台虽然会自动检查重复图片但自己心里也要有一杆秤。我把原始数据拉下来后会先按类别目录看一遍找两类典型问题一是“标错”比如一辆金杯面包车被标成小货车因为标注员看到车头有货箱特征就随手选了二是“混入”某个类别文件夹里混进了仪表盘特写、收费员手部遮挡、空车道背景这些图必须删。平台自带的增强功能我一般会默认开启。不过要注意增强不是万能的。EasyDL的在线增强会做翻转、裁切、颜色调整但如果你的样本类别本身不平衡比如“专项作业车”只有80张“小轿车”有2000张模型肯定偏向多数类。解决方法是先尽量把每个类别补到至少100张如果实在补不齐就在标注策略上合并相似类别别硬凑一个数量很少的标签。还有一个容易踩的坑同一辆车连续多次通过收费口拍的几十张图高度相似。这些相似图片如果全部进训练集会让模型在验证时“作弊”因为验证集里很可能混着同一辆车的不同帧准确率虚高。我是按照车牌脱敏后编号做去重抽样同一个车保留一定数量的不同角度/时段样本尽量保证数据独立性。EasyDL平台也会做相似图片去重但自己多筛一道更稳妥。4. 训练与调优在EasyDL上把模型跑起来4.1 创建数据集与任务配置登录百度智能云控制台进入EasyDL图像分类页面第一步是创建数据集。数据集类型选择“图像分类”然后按类别上传图片。这里有个小技巧提前把文件夹命名成标签名压缩包上传时平台会自动识别但如果图片非常零散也可以用平台提供的在线标注工具一张张标。整个任务配置没有太多玄学需要盯住几个点。一是选择单标签还是多标签。收费口车辆类型是单标签问题一辆车只能对应一个类别所以选单标签图像分类。如果某个场景需要同时识别“车型”和“颜色”那是两个分类任务不要塞进一个多标签模型里否则会互相干扰。二是数据划分。EasyDL会自动留出一部分验证集但如果你想手动控制尽量保证每个类别在训练集和验证集中的比例一致不要让验证集某个类别只有两三张。4.2 训练参数选择与训练过程EasyDL训练页面一般会提供“高精度”、“均衡”、“高性能”几档选项。我的经验是如果硬件条件允许第一次先选高精度档目的是摸清这个数据量下准确率的上限。等模型跑通、业务验证没问题之后再考虑用高性能档压一下延迟。高精度档训练时间长一点但收费口项目通常不需要秒级出结果多等几分钟训练不是问题。训练开始后平台会显示训练进度。这个阶段可以做别的事不需要守着终端。EasyDL自动训练会做很多超参搜索这是人工调参比不了的。有些初学者喜欢在训练前强行设置学习率、batch size等参数其实在自动训练框架里这些参数往往封装好了手动干预反而容易破坏平台内部的配合。有一点需要提醒每次训练模型不要只改数据却不记录版本。我在项目里会建一个Excel记录每次训练的“数据版本、训练模式、训练时间、验证集准确率、召回率、发布版本号、备注”。特别是当后来模型效果变差要回滚到上一版时这个版本记录能救命。EasyDL本身有模型版本管理但项目内部记录能帮我们追溯到底改了哪些数据。4.3 模型评估准确率之外还要看什么训练完成后平台会给出一个综合准确率。很多人在这一步看到95%就兴高采烈直接发布。我劝你冷静准确率在类别不平衡面前会骗人。假设“小型客车”占了数据集的90%模型把所有图片都判成小型客车准确率也有90%但“大型货车”完全没识别出来这个模型上线就是灾难。所以一定要看混淆矩阵逐类看Precision和Recall。对于收费场景我定的标准是每个类别的Recall不低于85%像大型货车、挂车这类高收费车型Recall要尽量冲到95%以上。一旦模型把大货车判成小客车少收的钱很难追回来。如果发现某个类别召回率低先别急着调阈值。优先去查两个方向一是这个类别的样本量是不是太少补充样本最常见二是这个类别和其他类别在图像上是否真的可区分比如“中型货车”和“大型货车”如果只差一个车轮数量图像上可能确实容易混淆。这时候可以考虑合并类别或者引入车牌侧面、轴数等辅助特征。EasyDL本身是图像分类不会融合结构化数据那就需要业务系统后端再做一层规则判断。5. 部署与业务集成从训练平台到收费系统5.1 部署形态公有云API还是边缘部署EasyDL训练出来的模型发布方式主要有公有云API和私有化部署两种。我在收费口项目里更推荐私有化部署原因很简单收费车道不能因为公网抖动就失去识别能力。每次交费都依赖云端往返一旦网络延迟高或者断网车辆通行就会受影响现场压力会非常大。私有化部署有两种落地形式。一种是直接部署到机房里的GPU或CPU服务器通过内网HTTP接口给收费系统调用另一种是部署到边缘计算盒子上比如英伟达Jetson系列或百度自研边缘盒子体积小、功耗低可以直接放在收费岗亭里。收费口通常一个站点只有一个车道或两三个车道边缘盒子完全够用运维也简单。选择部署形态时要评估请求量和机器配置。单车道高峰期一小时大概通过200到300辆车平均算下来每秒不到一次请求常规CPU服务器跑一个分类模型绰绰有余。EasyDL在私有化部署时支持模型加速如果现场CPU性能弱就开启INT8量化会牺牲一点点精度但换来更低的延迟。训练完成后可以先在服务器上做压测用历史图片一次性打1000个请求看平均延迟和最大延迟是否达标。5.2 接口调用示例不管公有云API还是私有化部署EasyDL的调用方式都差不多。下面是一个Python调用私有化部署接口的示例关键是往接口里传base64编码后的图片并指定返回top数量。import requests import base64 import json # 私有化部署地址默认启动在本机8080端口 service_url http://127.0.0.1:8080/image/classification # 读取图片并编码 with open(vehicle.jpg, rb) as f: img_base64 base64.b64encode(f.read()).decode(utf-8) # 请求参数 payload { image: img_base64, top_num: 3 } # 调用并解析结果 resp requests.post(service_url, jsonpayload) result resp.json() print(json.dumps(result, ensure_asciiFalse, indent2)) # 取出置信度最高的结果 results result.get(results, []) if results: top results[0] print(识别类别:, top[name]) print(置信度:, top[score])这里有几个细节要处理。第一图片不要直接传原图最好先把ROI感兴趣区域裁出来只保留车辆主体和必要的背景减小传输体积。第二接口请求超时时间设置长一点比如5秒但不要拖到几十秒否则收费系统会卡流程。第三业务端不要直接把置信度最高的结果当成最终结果要做阈值判断低于阈值就置为“待人工确认”。5.3 性能基准与硬件估算在硬件选型上我的实际压测参考是一张2080Ti显卡上批量大小为1的EasyDL图像分类模型单次推理延迟约20到40毫秒一台8核16G的CPU服务器单次推理延迟约200到500毫秒。收费口场景下车辆从触发抓拍到停在收费窗口差不多有好几秒所以CPU完全够用。如果你是纯CPU部署建议在EasyDL平台导出模型时选择“高性能”版本或开启量化然后压测时重点关注两个指标平均响应时间不超过500毫秒连续跑一小时后内存不持续上涨。收费系统是7x24小时运行内存泄漏这个坑很隐蔽上线前一定要用历史图片循环调用几万次观察进程内存曲线。平台导出的模型一般很稳定但集成到自己服务里后线程池、日志、异常重试都可能引发问题。6. 坑与解法我在现场踩过的典型问题6.1 常见问题速查表这个项目做了几轮迭代我把遇到最多的几类问题整理成了速查表给团队和现场运维用现象根因分析处理方案小轿车经常被识别成SUV样本里这两个类别从拍摄角度看不清车身高度和长度补充同角度、同色系样本检查标注边界必要时合并为“小型客车”夜间货车被误判成客车夜间大灯过曝车前脸特征丢失增加夜间和逆光样本加补光灯低置信度转人工集装箱挂车与普通大货车混淆类别边界依赖车轴和挂车结构图像上不明显重新定义标签把“挂车”独立成类引入轴数等后端规则雨天车头反光导致置信度低训练集中极端天气样本少建立天气补充采集机制雨天额外抓拍归档多辆车同时出现在一张图相机触发过早或过晚调地感线圈触发位置裁剪ROI区域必要时先检测后分类模型上线初期效果好一个月后掉点现场环境变化或新车型出现定期回捞低置信度图片补充迭代训练这张表看起来简单但每一条背后都是真金白银的教训。尤其是“类别边界不清晰”这个问题很多团队在标注阶段不重视等到训练完才发现混淆矩阵里某两块永远打架返工成本特别高。6.2 长期迭代的三个心得第一个心得不要只盯着模型要把置信度当成业务流程的一等公民。我在收费口现场见过太多因为单次识别置信度低就扣杆放行或拦截的例子。最合理的策略是设两条线置信度高于0.9直接放行介于0.6到0.9之间转人工确认低于0.6重新抓拍。这套逻辑写在业务系统里比反复调模型阈值更稳。第二个心得低频类别要人工补充不能等自然采集。像专项作业车、摩托车一天可能只过几辆一个季度也攒不了多少。我们后来专门安排现场人员在固定时段拍摄一些可遇不可求的特殊车辆甚至把园区内部车辆开进收费车道专门采集。平台再智能没有样本也是白搭。第三个心得上线不等于结束要建立回捞训练机制。我们把生产系统里所有置信度低于阈值但最终人工确认为某类的图片定期导回EasyDL数据集补充新样本后重新训练。这个闭环跑起来后模型在三个月里对特殊车辆的识别率明显提升。机器学习项目的护城河不在一次训练而在持续迭代的速度。这个项目做完之后我一直跟现场运维强调一句话模型不会一劳永逸数据才是长期资产。收费口每天都在产生大量有价值的影像数据把它们变成模型迭代的养料比换一个更复杂的图像分类算法有用得多。