
简介目标检测是计算机视觉领域的核心任务之一广泛用于安防、交通与智能停车场景。传统图像处理方法在光照变化、复杂背景下的鲁棒性往往不足而基于深度学习的目标检测算法能够自动学习特征显著提升识别精度。YOLOv5作为主流单阶段检测算法兼顾速度与准确率在小目标检测和边缘设备部署方面表现稳定。车牌识别是目标检测的典型落地应用通常采用“检测识别”两段式架构先定位车牌区域再进行字符识别。本文从环境配置、CCPD数据集转换、标注策略、数据增强与训练调参出发详细讲解如何训练一个高精度的车牌检测模型并介绍字符识别与规则后处理方案。同时结合RK3568边缘计算盒子的部署经验梳理模型导出、INT8量化与工程落地的关键要点为开发者提供从算法到硬件的完整参考。 两年前我接手过一个停车场道闸的车牌识别项目准确率在白天还好一到傍晚和雨天就频繁漏检。换摄像头、调打光、改传统图像处理里的定位参数折腾了快半个月效果还是不稳定。后来我把整套方案从“边缘检测形态学定位”迁到了YOLOv5这个深度学习算法框架上第一个晚上测完现场人员跟我说“这回晚上终于像回事了”。从那以后车牌识别这类任务我再也没回头用过传统方案。所以这篇文章不打算只贴一段训练代码而是把“用YOLOv5实现车牌识别”的完整链路拆开讲清楚数据怎么准备、标注怎么避坑、超参怎么调、检测到车牌之后字符识别怎么做以及最终落到RK3568这类边缘盒子上的问题。适合两类人看一是刚入门深度学习、想拿车牌识别练手的同学二是已经在做边缘视觉项目、打算把车牌识别落到嵌入式设备上的工程师。1. 车牌识别任务的第一拆解为什么选YOLOv5而不是其他方案1.1 车牌识别本质上是两段式任务不是单模型任务很多第一次接触车牌识别的人会问有没有一个神经网络输入一张图直接输出“粤B12345”这串字符严格说确实有端到端的方案但实际项目里极少有人这么干原因后面细说。行业里更通用的做法是把它拆成两个子任务先用目标检测模型把车牌区域从整张图中找出来再做分类或序列识别把车牌区域里的字符读出来。YOLOv5负责的正是前一半——检测环节。这个拆分不是图省事而是因为两个子任务的输入输出差异太大。检测任务要处理的是全图范围的目标搜索图片里可能有汽车、树木、行人、灯牌目标尺度变化也大而字符识别面对的基本是一张已经裁剪好的矩形小图内容固定是车牌字符本质上是细粒度分类或序列标注问题。把这两件事情塞进同一个端到端网络模型的容量和训练数据需求都会成倍增长而且解释性差——现场识别错了你很难判断是“没找到车牌”还是“找到了但读错字”。所以我的建议是老老实实采用“YOLOv5检测车牌 字符识别网络读字符”的标准两段式流水线这条路线在工程上最成熟各部分可替换、可单独调优排查问题也方便。1.2 检测环节选型YOLOv5在准确率和部署友好度上的平衡国内车牌识别场景检测模型的无非这几个候选Faster R-CNN 为代表的两阶段检测器SSD、YOLOv5 为代表的单阶段检测器以及 Transformer 系的新锐模型。做一个表格对比可能更直观模型推理速度小目标能力部署生态工程熟悉度Faster R-CNN慢强一般偏低SSD快弱一般偏低YOLOv5快中上极好高YOLOv8 / RT-DETR快中上较好中等车牌在整张监控画面里往往只占很小一块区域尤其远距离闸机场景车距离相机三四米时车牌可能只有几十个像素宽。这种小目标检测场景Faster R-CNN 的精度理论上最高但它在嵌入式设备上的推理速度太慢很难满足道闸20毫秒到100毫秒级别的实时性要求而且模型文件大部署和后续优化都不灵活。反过来SSD 虽然快但由于它对小目标的召回能力弱在路侧停车这种车牌容易被遮挡、倾斜的场景里漏检率会明显偏高。YOLOv5 赢在平衡它的anchor机制和多尺度特征融合PANet结构对小目标支持不错推理速度在单阶段检测器里属第一梯队而且Ultralytics维护的工程版本非常完善——训练、验证、导出ONNX/RKNN都有官方脚本社区资料也足够多遇到问题基本都能搜到解决方案。我个人的观点是如果项目没有硬性追求SOTA指标而是要做成可交付的稳定产品YOLOv5仍然是车牌检测最稳的选择。你甚至可以认为它不是学术上最前沿的但绝对是最“顺手”的。1.3 为什么不直接训练端到端车牌识别网络端到端方案最诱人的地方是省掉了中间对齐环节一张图进去字符串出来。但实际落地时会有几个硬伤。第一端到端网络很难兼顾“全图搜索”和“字符精细识别”这两件事。目标检测里广泛使用的下采样倍数比如原始图像的1/32对字符级别的小目标来说是毁灭性的一个字符可能只占特征图上的一个像素信息全丢了。要么把输入分辨率做得很高要么设计复杂的多尺度注意力机制训练成本陡增。第二端到端模型难处理多车牌场景。路边停车、停车场进出口两车并排时车牌经常出现多个端到端模型要么设定固定输出长度要么引入复杂的序列对齐机制稍微复杂一点的场景就会崩。第三从排查故障的角度讲两段式的好处是你可以单独看检测召回率、单独看字符识别准确率。如果现场反馈“偶尔有一辆车识别不了”你能很快定位是检测漏了还是字符读错了。端到端模型出问题基本只能盲调。我自己做项目时最怕不可解释的模型这种两段式架构能省下大量联调时间。2. 训练环境的版本选择和从CCPD数据集到YOLO格式的转换2.1 环境版本搭配建议YOLOv5对版本兼容性比较敏感尤其是PyTorch版本和CUDA版本的组合。网上“yolov5安装步骤”相关的搜热度一直很高多半是版本配错导致各种报错。我整理一套目前最稳的搭配按这个来基本不会卡在环境环节Python 3.8 或 3.10PyTorch 1.10 到 2.0 之间均可CUDA 11.3 或 11.8对应cuDNN 8.xYOLOv5 官方仓库的 v6.0 或 v7.0 分支为什么推荐 v6.0/v7.0 而不是最新主分支因为后续导出RKNN、NCNN这些工具链时很多算子优化是按v6/v7的模型结构做的版本太新反而容易遇到算子不兼容的问题。如果你只是做纯训练实验那用最新版也无所谓。安装命令可以直接抄# 创建虚拟环境 conda create -n yolov5 python3.8 -y conda activate yolov5 # 安装 PyTorchCUDA 11.8 对应版本 pip install torch1.13.1 torchvision0.14.1 --extra-index-url https://download.pytorch.org/whl/cu118 # 拉取 YOLOv5 仓库 git clone -b v6.0 https://github.com/ultralytics/yolov5.git cd yolov5 # 安装依赖 pip install -r requirements.txt装完以后跑下面这条命令验证环境可用python detect.py --weights yolov5s.pt --source data/images/bus.jpg --device 0第一次运行会自动下载预训练权重。如果看到一张带框的检测结果图说明环境基本没问题。这个验证步骤虽然简单但很多人跳过了结果训练到一半才发现GPU驱动有问题白白浪费时间。2.2 CCPD数据集公开车牌数据集的格式坑车牌识别行业最常用的公开数据是中科大的CCPD数据集里面大部分是安徽合肥场景的车牌包含蓝牌、黄牌、绿牌和部分新能源车牌总共大概30万张。用途上够用但它的标注格式不是YOLO的txt格式而是把所有信息编码在文件名里。比如一张图片文件名里包含车牌号、边界框四个顶点坐标、车牌四个角点坐标等信息。从CCPD训练YOLO必须先把标注转成YOLO要求的格式每张图对应一个txt每行是类别 中心点x 中心点y 宽度w 高度h全部按图片宽高归一化。转换思路很简单从文件名解析出四个角点坐标取最小外接矩形转成中心点宽高格式。核心代码大致是这个逻辑import os import cv2 def convert_ccpd_to_yolo(ccpd_file_path, image_root, save_root): with open(ccpd_file_path, r) as f: lines f.readlines() for line in lines: filename line.strip() parts filename.split(-) # CCPD文件名中第二段是bounding box的四个顶点坐标 box_part parts[1].split(_) x1, y1 int(box_part[0].split()[0]), int(box_part[0].split()[1]) x2, y2 int(box_part[1].split()[0]), int(box_part[1].split()[1]) x3, y3 int(box_part[2].split()[0]), int(box_part[2].split()[1]) x4, y4 int(box_part[3].split()[0]), int(box_part[3].split()[1]) xs [x1, x2, x3, x4] ys [y1, y2, y3, y4] min_x, max_x min(xs), max(xs) min_y, max_y min(ys), max(ys) img cv2.imread(os.path.join(image_root, filename)) h, w img.shape[:2] x_center (min_x max_x) / 2 / w y_center (min_y max_y) / 2 / h box_w (max_x - min_x) / w box_h (max_y - min_y) / h # 类别ID: 0 表示车牌 save_name os.path.splitext(filename)[0] .txt with open(os.path.join(save_root, save_name), w) as out: out.write(f0 {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}\n)注意这里取的是外接矩形而CCPD标注里其实有四个角点是适合做旋转框的。但YOLOv5原生只支持水平矩形框所以如果车牌倾斜角度很大直接取外接矩形会框进大量背景。这个矛盾我们在后面数据增强一节还会详聊这里先埋个伏笔。2.3 多场景数据混合只用CCPD是不够的CCPD虽然量大但有一个明显问题场景单一基本都是停车位和城市道路而且天气条件相对正常。实际项目里你面对的可能是夜间地库、雨天反光、老旧小区混乱背景、货车双层黄牌等等这些在CCPD里覆盖不足。我自己的经验是CCPD做基础训练集没问题但正式上线前必须加入现场数据。哪怕现场数据只有两三千张对模型的泛化能力提升也是质变。具体操作上可以按7:2:1随机划分训练集、验证集、测试集。划分时尽量保证同一辆车不大概率出现在两个集合里避免“背答案”式的假高分。如果你有现场数据建议手动抽一部分只放到测试集里专门用来评估模型到了新环境的真实表现。3. 车牌样本的标注与增强策略决定了模型的真实上限3.1 标注工具、类别设计和边界框松紧度训练车牌检测标注工具有两个主流选择LabelImg 和 Labelme。车牌是矩形目标直接用 LabelImg 画水平矩形框就够了如果后续要做旋转框需要换用 Labelme 或者 X-AnyLabeling。这里多说一句YOLOv5 不支持旋转框所以用 LabelImg 是标配。类别设定上我强烈建议只设一个类别“plate”不要按“蓝牌”“绿牌”“黄牌”分开标注。原因是后面字符识别环节可以轻松区分车牌类型没必要在检测阶段增加分类负担。而且如果按类型分开标注数据不均匀会导致某些颜色的车牌检测效果差非常常见。标注时的边界框松紧直接影响训练效果。我刚做第一个车牌项目时为了省事框画得很大把车灯、保险杠一部分都包进去了结果模型训练出来误检率特别高。后来把所有标注重新过了一遍要求边界框紧贴车牌边缘允许每边多出1到2个像素mAP 直接涨了好几个点。这个细节很少被入门教程提到但对检测精度影响非常实在。3.2 车牌倾斜和背景干扰用数据增强而不是硬扛前面提到CCPD标注用外接矩形会引入背景其实标注阶段没法避免因为YOLOv5训练时框是矩形的模型学的是边界框内部的特征。如果车牌倾斜30度以上框内有一半是背景模型很容易学歪把背景特征误当成车牌的一部分。解决办法主要靠数据增强。YOLOv5自带的random_perspective随机透视变换可以模拟车牌的不同视角训练时在形状和透视图上做一些扰动。对车牌项目我建议在 hsv 增强上保守一点尤其hsv_s和hsv_v不要设太高。车牌颜色是强特征——蓝牌就是蓝底白字、绿牌是绿底黑字HSV扰动过大容易把颜色信息破坏掉导致模型分不清“蓝牌”和“蓝绿色背景”。还有一个容易忽略的点上下翻转flip增强对车牌识别基本是无效甚至有害的。因为车牌上的字符有方向性一块“粤B12345”倒过来就不是正常样本了。好在YOLOv5默认配置里fliplr0.5是水平翻转水平翻转后的车牌字符虽然左右颠倒但在识别阶段你可以再翻转回来不过flipud上下翻转最好直接关掉否则会产生大量物理上不合理的车牌样本。3.3 有人问“yolov5训练单通道”怎么办“yolov5训练单通道”这个关键词的搜索量这几年一直不低需求大多来自工业相机或低成本摄像头成像只有灰度。但我的观点很明确除非你的成像设备已经锁定为单通道红外或灰度工业相机否则默认用RGB三通道训练。原因很简单颜色是车牌打眼的视觉特征蓝牌、绿牌、黄牌在灰度图里差别可能很小。尤其夜间场景在灰度图上蓝底白字和白底黑字的对比度差异非常小模型学起来非常吃力。如果项目确实必须用单通道也不是不能做需要改模型第一层卷积的输入通道数。YOLOv5的backbone第一层是普通卷积把in_channels从3改成1即可。为了利用预训练权重可以把预训练权重里第一层卷积的权重按通道做一个均值合并这样训练能从更高的起点开始。举个例子假设原来权重是[3, 64, 6, 6]合并成[1, 64, 6, 6]就是对前三个通道取平均。这种做法虽然能训练但效果和RGB相比基本都有明显下降尽量别走这条路。4. YOLOv5训练车牌检测模型超参配置与Loss曲线怎么看4.1 backbone选多大规模s、m 还是 lYOLOv5 提供 n/s/m/l/x 五个级别的模型规模。车牌检测这个任务我个人的建议是 s 或者 m优先尝试 s。原因是车牌目标结构简单颜色和形状相对统一不像Coco检测要区分80类天差地别的物体。yolov5s 已经有足够的特征容量来拟合“车牌区域”这个概念。即便把模型换到 x训练集只有几万张时模型的记忆容量超出任务本身极容易过拟合推理速度还变慢。嵌入式设备上更明显yolov5m 在RK3568上的推理耗时比 s 大不少而精度提升往往不到1%。所以我的默认推荐是起步用yolov5s预训练权重如果验证集 mAP 不够再换 m不要一上来就 l/x。后面部署边缘设备的时候你会感谢这个选择。4.2 一份可以直接作为起点的训练配置训练前需要准备两个文件数据集配置和一个简单的超参数文件。假设数据已经按YOLO格式准备好数据集配置大概这样# data.yaml train: /data/plate_dataset/train val: /data/plate_dataset/val test: /data/plate_dataset/test nc: 1 names: [plate]训练命令我一般这样写python train.py \ --data data.yaml \ --weights yolov5s.pt \ --imgsz 640 \ --batch 16 \ --epochs 150 \ --device 0 \ --cache一个关键经验是--cache开启后会把图片加载到内存里训练速度快很多。很多初学者不知道这个参数以为GPU利用率低是显卡不行其实是IO瓶颈。超参数方面下面这一组是基于车牌训练几次后得到的比较稳的配置超参数推荐值说明lr00.01初始学习率车牌数据集小过高容易发散lrf0.2余弦退火最终学习率取0.2比较常用momentum0.937默认动量即可不用动weight_decay0.0005小数据集建议保持默认过大会欠拟合warmup_epochs3预热3个epoch稳定起步mosaic0.6马赛克增强开启但对极小目标场景不建议开到1.0fliplr0.5水平翻转可以保留flipud0.0上下翻转必须关掉hsv_s0.3饱和度扰动不要太激进hsv_v0.2明度扰动同理degrees5旋转角度加一点点增强车牌倾斜适应性translate0.1轻微平移这些参数不一定要全改成我写的值但有一些红线不能碰flipud设为0、hsv增强压住、mosaic不要满配。4.3 Loss曲线怎么判断有没有学歪训练时分三个lossbox_loss定位误差、cls_loss分类误差、obj_loss置信度误差。还有验证集的mAP这才是最该盯的指标。一个常见误判是只看训练集loss降得越低越开心。但训练集loss低不代表验证集mAP高可能是严重过拟合了。我建议观察两个信号训练到大约100轮以后如果验证集mAP不再明显增长训练集loss还在持续下降说明模型开始背训练数据了继续训练意义不大不如停下来做早停。如果 mAP 一直上不去排查顺序是标注数据有没有错边界框紧不紧数据是不是太单一然后才轮到调学习率和换模型规模。顺序不要反了我见过不少同学上来就调一星期超参最后发现是标注文件里类别ID写错了。我用CCPD子集加现场数据训练的经验是车牌检测相对容易收敛。正常训练到100轮左右验证集mAP0.5就能到95%以上。如果你发现这个数迟迟到不了90%先别怀疑模型去看数据。4.4 加载预训练权重与冻结策略用COCO预训练权重是必须的因为从零训练车牌模型需要的数据量太大也容易在前期loss剧烈震荡。COCO权重的作用是让模型已经学会拿通用视觉特征比如边缘、纹理、颜色分布这些低级特征对车牌同样有效。训练前期也可以考虑冻结backbone的前几层让模型集中精力学习检测头和后面几层特征。命令里可以用--freeze 10冻结前10层。但我个人在实际项目里做的很少因为车牌模型训练周期短、数据量可控从预训练权重开始全量微调就能收敛得很好。冻结反而增加了调参负担收益不大。5. 检测到车牌之后字符识别与车牌规则后处理5.1 字符识别的两条技术路线YOLOv5输出的是一堆bounding box坐标和置信度。要变成车牌号码还需要一个字符识别模块。目前主流有两条路线第一条是字符级检测用另一个YOLO模型去检测车牌区域里的每个字符再按从右到左或从左到右顺序拼接。这种方式在中国车牌、尤其是字符间有明显间隔的车牌上精度很高但缺点是多一次检测耗时增加而且需要每个框准确对应一个字符对倾斜、反光场景要求高。第二条是基于序列识别的整串读取把裁剪好的车牌图直接送进一个OCR网络输出完整车牌字符串。典型代表是 LPRNet 或 CRNN。LPRNet 是轻量级卷积循环网络配合CTC损失自行对齐字符位置不需要预先做字符分割对倾斜和模糊样本的容忍度比字符级检测更高推理速度也快非常适合嵌入式设备。我的建议是优先上 LPRNet 这种整串识别方案。YOLOv5 定位到车牌后切图给 LPRNet 推理整个流程干净、速度快、易于部署。字符级检测方案精度上限高但复杂度也高更适合那种要求极端高精度的关卡场景。5.2 LPRNet 推理前的车牌校正和归一化LPRNet 的输入是一张固定宽高的车牌图训练时一般会把高度缩放到24像素左右宽度按比例缩放车牌是8位的宽度约94像素新能源牌要宽一些到190像素。输入分辨率太小但LPRNet就是为这种低分辨率设计的即使单字符只有12像素左右也能读出来。在把检测框裁剪出来之后通常要做倾斜校正。因为YOLOv5输出的是外接矩形框车牌本身倾斜明显时切图会带大量背景。一个可行的办法是用图像形态学或边缘检测找车牌的四个角点再计算透视变换矩阵做校正。也可以退一步不校正而直接均匀缩放让LPRNet自己去学习倾斜不变性。我建议先跑通不校正的版本再决定是否加校正模块毕竟增加模块意味着部署多一套OpenCV逻辑工期和稳定性都要考虑。校正后把图resize到固定尺寸、归一化像素值到0到1之间就可以送进LPRNet了。这里有一个容易踩的坑训练和推理时的归一化方式必须完全一致差一个量级都会导致精度悬崖式下跌。LPRNet通常用的是像素值除以255再做标准化注意和你的实现对齐。5.3 用规则后处理兜底把误识别“捞”回来字符识别模型再准也有出错的时候但中国车牌有很强的规则约束用一个简单的正则表达式就能筛掉大量明显错误的识别结果。一个大陆车牌号的通用规则是第一位是省份简称汉字第二位是发牌机关代号通常是一个大写字母后面五位通常是大写字母和数字的组合新能源车牌则是六位。所以可以用正则import re # 普通蓝牌省份简称 字母 5位字母数字 normal_plate re.compile(r^[\u4e00-\u9fa5][A-Z][A-Z0-9]{5}$) # 新能源车牌省份简称 字母 6位字母数字 energy_plate re.compile(r^[\u4e00-\u9fa5][A-Z][A-Z0-9]{6}$)推理时对 LPRNet 输出的字符串先过一遍这两个正则不匹配的直接判为识别失败或者把置信度降到最低。这个后处理看似简单却能实实在在把最终准确率提升1到2个百分点。因为在置信度阈值附近本来就有很多模糊样本让规则帮模型做最后一道判断是很划算的生意。另外LPRNet 输出的字符集里有些字形在低分辨率下非常容易混淆比如“0”和“O”、“1”和“I”、“2”和“Z”。处理手段一般是在字符集里不区分O和0训练时把它们统一映射为数字0或字母O避免模型在相似字形之间无所适从。6. 从PC到边缘盒子RK3568这类设备上的落坑经验6.1 模型导出pt 转 ONNX再转 RKNN很多工程师在GPU服务器上把模型训好到了部署阶段才发现“模型在服务器上跑得好好的怎么到板子上就废了”。关键在于边缘设备的模型转换链路。以瑞芯微RK3568为例完整链路是YOLOv5官方权重pt文件 - ONNX - RKNN瑞芯微的NPU模型格式。导出ONNX这一步YOLOv5官方提供了现成脚本python export.py --weights runs/train/exp/weights/best.pt --include onnx --opset 11 --simplify--simplify会调用onnx-simplifier做算子简化建议加上。转换过程如果报算子不支持的错通常发生在 Focus 和 SPP 结构上。YOLOv5v6.0之后的结构对ONNX导出友好很多如果遇到问题优先确认你拉的YOLOv5分支是v6.0及以上。拿到ONNX后再用瑞芯微提供的 rknn-toolkit 转成 RKNNpython rknn_convert.py \ --input_model yolov5s.onnx \ --output_model plate_yolov5s.rknn \ --dataset calibration_dataset.txt这里的calibration_dataset.txt是一份校准图片清单用于量化时统计激活值分布。校准图一定要从真实使用场景中抽至少100到200张。如果你拿了一堆无关图片做校准量化后的模型会在车牌这种特定目标上崩得非常厉害。6.2 量化的选择与理解不是所有场景都适合INT8RK3568的NPU支持FP16和INT8两种常见量化模式。FP16精度损失极小推理速度大概是INT8的一半多一点INT8速度最快但精度下降不可控。对车牌这种小目标、需要精确边界框的任务我建议第一步先用FP16跑通全链路如果帧率达标就不必上INT8。我印象很深的一次是INT8量化后检测框的位置偏移越来越明显远距离车牌经常框偏半个车身导致后续字符识别效果骤降。最后对比发现是校准图数量太少激活值分布没统计准。加大量校准图之后INT8精度有所回升但依然比FP16低了约1.5个mAP点。车牌是强特征目标INT8能跑但性价比未必高。如果路侧停车项目要求密集车流下都稳定输出我宁可选择FP16。准确说模型转换后一定要做“保真比对”取一组固定测试图对比pt模型和RKNN模型的输出框坐标偏差应该在几个像素以内置信度偏差也应该在可接受范围内。这一步很多人不做上线后出问题才回头查给自己挖坑。6.3 部署里三个容易忽略的隐藏坑第一个坑是图像预处理里的 letterbox 和坐标回算。YOLOv5 训练时会把图像缩放到640x640但保持宽高比并填充灰边这个操作叫 letterbox。部署在板子上时OpenCV读到的原始图像也要做完全一致的letterbox网络输出的框坐标要先抠掉灰边、再按缩放比例映射回原图尺寸。这个映射关系写错检测框就会出现百分制的偏移。这不是模型问题而是工程实现问题非常隐蔽。第二个坑是后处理耗时被低估。NPU上模型推理时间可能只有30毫秒但如果你在CPU上做NMS和置信度过滤写得不好或每帧都做太多for循环整体耗时可能翻倍。一个简单的优化手段是把NK个候选框按置信度排序后用向量化numpy操作做NMS尽量少写纯Python循环。实测下来同样一个NMS逻辑纯Python写法比向量化写法慢了5倍以上。第三个坑不在技术链路上而在项目流程上不要尝试在RK3568这种边缘设备上训练模型。板子CPU能力不足以支撑训练而且训练和推理环境不分的后果是系统过热降频板子稳定性变差。最稳妥的方式是GPU显卡或云GPU做训练和调参板子只负责加载RKNN模型做推理两边分工。最后分享一个我自己的习惯。车牌识别这类项目训练时间和调试成本的大头往往不在网络结构上而在数据集分布和后处理规则上。我每部署一个新路口或新停车场上线前都会先抓一周真实样本做增量训练哪怕只加入两三百张图夜间误检率通常就能下降一个可观幅度。这是比继续在超参上纠结更划算的投入至少在我做过的项目里这个经验从没让我失望过。本文还有配套的精品资源点击获取