1. 为什么在深度学习框架百花齐放的今天还要聊Caffe
如果你是在2015年前后入行计算机视觉的，Caffe这个名字大概率是你接触的第一个深度学习框架。那时候PyTorch还没发布，TensorFlow刚开源不久，学术界和工业界做图像分类、目标检测，Caffe几乎是默认选项。现在回头看，Caffe的生态确实老了，Python 2的支持、Protobuf的版本冲突、编译时各种依赖报错，每一条都够让人头疼半天。但有一个场景我至今仍然觉得Caffe有它的独到之处——车牌识别这类结构相对固定、对推理速度要求高、部署环境受限的工业级任务。
车牌识别这个任务本身很有意思。它不像通用目标检测那样需要处理千变万化的类别，也不像自然语言处理那样模型结构日新月异。它的核心流程非常清晰：先定位车牌在图像中的位置，再对车牌区域做字符分割或序列识别，最后输出车牌号码。整个pipeline的每一环都有成熟的技术方案，而Caffe在这个链条里的优势在于：模型结构定义直观（Prototxt）、C++推理接口成熟、内存占用可控、在嵌入式设备上部署方便。我见过不少做智能交通的团队，至今仍在用Caffe训练的车牌检测模型跑在工控机上，稳定运行了好几年。
这篇文章适合两类人看：一类是手里有Caffe遗留项目需要维护或优化的开发者，另一类是想理解车牌识别完整技术链路、不满足于只调库的学生和工程师。我会从数据准备开始，一路讲到模型训练、调参、部署推理，把每个环节里我踩过的坑和总结的经验都摊开来说。文章里涉及的代码和配置都是可以直接参考的，但具体参数需要根据你的数据集做调整。
注意：Caffe的安装本身就是一个大坑，不同版本的CUDA、cuDNN、Protobuf组合会产生各种奇怪的编译错误。如果你还没装好环境，建议先用Docker镜像跑通流程，再考虑本地编译。
2. 车牌识别任务的拆解与Caffe的适配逻辑
2.1 车牌识别的两阶段与端到端之争
车牌识别在技术路线上一直有两派做法。一派是两阶段方案：先用目标检测网络（比如SSD、YOLO的Caffe版本）把车牌框出来，再把车牌区域送进一个字符识别网络（比如CRNN或者简单的多标签分类网络）得到号码。另一派是端到端方案：直接输入整张图，网络同时输出车牌位置和号码，类似OCR里的检测+识别联合训练。
两阶段方案的好处是每一环都可以独立调试和替换。检测不准就换检测模型，识别不准就换识别模型，互不影响。端到端方案理论上更优雅，但训练数据要求高，调参难度大，而且在Caffe里实现复杂的端到端结构比较费劲。我个人的经验是，在Caffe框架下，两阶段方案是更务实的选择。原因很简单：Caffe的Layer定义是静态图，自定义Loss Layer和复杂的后处理逻辑写起来不如PyTorch灵活，两阶段方案可以把复杂度分散到两个相对独立的模型里，每个模型的结构都更简单、更容易收敛。
具体来说，检测阶段我推荐用SSD（Single Shot MultiBox Detector）的Caffe实现。SSD在Caffe社区有比较成熟的代码，输入分辨率可以灵活调整，对小目标（车牌在整张图里通常只占很小一块）的检测效果经过调参后可以做到很好。识别阶段可以用多标签分类的思路：把车牌号码的每一位当作一个独立的分类任务，比如中国蓝牌是7位，就设计7个分类头，每个头负责预测对应位置的字符。这种做法的好处是训练简单、推理速度快，缺点是对车牌字符分割的精度有一定依赖。
2.2 为什么Caffe适合做车牌识别的推理部署
说一个实际场景。我之前参与过一个停车场出入口的识别系统，硬件是一台低功耗的工控机，没有独立显卡，只有Intel的集成显卡。这种环境下，PyTorch的推理速度惨不忍睹，TensorFlow也好不到哪去。最后换成Caffe，用C++接口加载模型，单张图片的检测+识别总耗时控制在80毫秒以内，满足了实时性要求。
Caffe之所以在推理端有优势，核心原因有几个。第一，Caffe的Blob内存管理是预分配的，推理过程中不会频繁申请和释放内存，这在嵌入式环境里非常重要。第二，Caffe的Layer实现是高度优化的C++代码，尤其是卷积层，Intel的MKL和开源的OpenBLAS都能直接对接。第三，Caffe模型可以很方便地转成其他推理引擎的格式，比如通过ONNX转到TensorRT或者OpenVINO，进一步加速。
当然，Caffe的缺点也很明显。训练的时候没有TensorBoard那样的可视化工具，loss曲线要靠自己解析日志画图。数据增强的灵活性不如PyTorch的DataLoader，需要自己写Python Layer或者提前把增强后的图片存到磁盘。但这些缺点在车牌识别这个任务里是可以接受的，因为车牌识别的数据增强手段相对固定（亮度调整、对比度调整、轻微旋转、加噪声），不需要太复杂的增强策略。
2.3 整体技术链路概览
我把整个车牌识别项目拆成以下几个环节，后面的章节会逐一展开：
| 环节 | 主要工作 | 产出物 |
|---|---|---|
| 数据准备 | 收集车牌图片、标注检测框和号码 | LMDB数据集 |
| 检测模型训练 | 用SSD训练车牌检测器 | 检测模型caffemodel |
| 识别模型训练 | 用多标签分类训练字符识别器 | 识别模型caffemodel |
| 推理部署 | C++接口集成、后处理逻辑 | 可执行程序 |
| 调优 | 难例挖掘、模型压缩、加速 | 优化后的模型 |
这个链路看起来清晰，但每个环节都有不少细节需要注意。比如数据准备阶段，车牌的标注格式和普通目标检测不太一样，需要同时标注框的位置和号码内容。检测模型训练时，SSD的默认anchor设置对车牌这种长条形目标不太友好，需要调整aspect ratio。识别模型训练时，字符类别的不平衡问题很突出，数字和字母的出现频率远高于省份简称汉字。
3. 数据准备：从原始图片到LMDB的完整流程
3.1 车牌数据的采集与标注规范
车牌识别的数据来源主要有几个渠道：公开数据集（比如CCPD、CRPD）、自己采集的监控截图、合成数据。公开数据集的好处是标注质量高、数量大，但场景可能和你的实际应用有差异。自己采集的数据更贴近实际场景，但标注工作量大。合成数据可以用工具生成，但域适应问题需要额外处理。
我建议的做法是：先用公开数据集训练一个基础模型，再用自己采集的数据做fine-tune。这样既能保证模型有足够的泛化能力，又能适应特定场景。
标注的时候，每张图片需要记录两个信息：车牌框的坐标（xmin, ymin, xmax, ymax）和车牌号码字符串。标注格式我习惯用类似VOC的XML格式，每个图片对应一个XML文件。车牌号码的标注要注意几点：省份简称要用正确的汉字，字母要统一大小写（建议全大写），新能源车牌是8位，不要漏掉最后一位。
提示：标注车牌框的时候，建议框稍微放大一点，把车牌边缘的铆钉和边框都包含进去。这样训练出来的检测器对边缘的鲁棒性更好，不会因为框太紧导致字符被切掉。
3.2 检测数据集的LMDB生成
Caffe最常用的数据格式是LMDB，生成检测数据集的LMDB需要把图片和标注框转换成SSD要求的格式。SSD的Caffe实现通常要求一个txt文件，每行包含图片路径和对应的标注信息。格式大概是这样的：
# 图片路径 图片宽 图片高 类别数 xmin ymin xmax ymax ... /path/to/image1.jpg 1920 1080 1 100 200 300 250 /path/to/image2.jpg 1280 720 1 50 60 200 120然后写一个Python脚本，用Caffe提供的convert_annoset工具或者自己用caffe.proto里的Datum结构生成LMDB。这里有个坑：SSD的Caffe版本对LMDB的生成方式有特定要求，不同fork的代码可能不一样。我用的那个版本要求LMDB里存储的是Datum，但标注信息是通过一个额外的txt文件在训练时读取的。所以实际上LMDB里只存了图片数据，标注信息走的是另一个通道。
生成LMDB的脚本核心逻辑是这样的：
import caffe import numpy as np import cv2 def generate_lmdb(image_list, output_path): # 初始化LMDB环境 map_size = int(1e12) env = lmdb.open(output_path, map_size=map_size) with env.begin(write=True) as txn: for i, (img_path, labels) in enumerate(image_list): # 读取图片 img = cv2.imread(img_path) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # 构造Datum datum = caffe.io.array_to_datum(img) datum.label = 0 # 检测任务不用这个label # 写入LMDB txn.put('{:08d}'.format(i).encode(), datum.SerializeToString()) env.close()这段代码看起来简单，但实际跑的时候要注意图片的通道顺序。Caffe默认是BGR，但OpenCV读进来也是BGR，所以如果你用cv2.imread读图，不需要做通道转换。但如果你用PIL读图，PIL是RGB，就需要转成BGR再存。
3.3 识别数据集的制作与字符类别映射
识别模型的数据集制作是另一个重点。我采用的多标签分类方案，需要把车牌号码的每一位拆开，每一位对应一个类别。首先需要统计所有出现过的字符，建立一个字符到索引的映射表。
中国车牌用到的字符包括：31个省份简称汉字、26个大写字母（I和O通常不用，避免和1、0混淆）、10个数字。总共大约67个类别。但实际项目中，如果你只做某个省份的车牌，汉字类别可以缩减到1个。
映射表建好之后，每个车牌号码就转换成一个整数数组。比如"京A12345"转换成[0, 10, 1, 2, 3, 4, 5]（假设京的索引是0，A的索引是10）。然后把这个数组作为标签，和车牌区域的裁剪图片一起存入LMDB。
这里有个细节：车牌区域的裁剪要留一点边距。如果严格按照检测框裁剪，有时候会把字符的边缘切掉。我通常会在检测框的基础上向外扩5%到10%的像素，保证字符完整。
3.4 数据增强策略与Caffe的实现方式
Caffe的数据增强不如PyTorch方便，但可以通过几种方式实现。第一种是在生成LMDB之前做增强，把增强后的图片也存进去。这种方式的缺点是数据集会膨胀好几倍，LMDB文件可能大到几百GB。第二种是写Python Layer，在训练时实时做增强。这种方式灵活，但Python Layer的速度是瓶颈，可能会拖慢训练。
我一般采用折中方案：对训练集做适度的离线增强，对验证集不做增强。离线增强的手段包括：
- 亮度调整：随机乘以0.8到1.2之间的系数
- 对比度调整：随机乘以0.8到1.2之间的系数
- 轻微旋转：-5度到5度之间
- 高斯噪声：标准差在5到15之间
- 运动模糊：模拟车辆运动造成的模糊
这些增强手段在OpenCV里都有对应的函数，写一个脚本批量处理即可。注意增强后的图片要重新生成标注框，因为旋转会改变框的位置。如果嫌麻烦，可以只做不改变几何位置的增强（亮度、对比度、噪声），这样标注框不用重新计算。
4. SSD检测模型的训练与调参实战
4.1 SSD网络结构的修改要点
SSD的原始版本是基于VGG16的，输入分辨率300x300。但车牌检测有几个特殊之处：车牌是长条形目标，宽高比通常在3:1到5:1之间；车牌在整张图里占比很小，尤其是远距离拍摄的场景；车牌的角度可能有倾斜。针对这些特点，需要对SSD做几处修改。
第一，调整anchor的aspect ratio。原始SSD的aspect ratio是[1, 2, 3, 1/2, 1/3]，对车牌来说不够用。我改成[1, 2, 3, 4, 5, 1/2, 1/3, 1/4, 1/5]，增加长条形的anchor。同时把anchor的scale范围也调整一下，让更小的anchor覆盖远距离的小车牌。
第二，修改输入分辨率。300x300对车牌来说太低了，字符会糊成一团。我通常用512x512或者600x600。分辨率提高会增加计算量，但检测小目标的效果会明显改善。如果硬件条件允许，用800x800效果更好。
第三，调整特征图的选取。SSD从多个尺度的特征图上做预测，浅层特征图负责小目标，深层负责大目标。车牌通常是小目标，所以浅层特征图的权重更重要。我在修改的时候会确保conv4_3这一层被包含在预测层里，并且给它分配足够的anchor数量。
4.2 训练参数配置与loss曲线解读
SSD的solver配置里，几个关键参数需要根据数据集规模调整。假设你的训练集有5万张图片，batch size设为16，那么一个epoch大约需要3125次迭代。初始学习率我一般设0.001，用step策略，在80%和95%的迭代次数时各降一次学习率，降为原来的0.1倍。
# solver.prototxt base_lr: 0.001 lr_policy: "step" gamma: 0.1 stepsize: 100000 max_iter: 200000 momentum: 0.9 weight_decay: 0.0005 batch_size: 16训练过程中要盯着loss曲线看。SSD的loss由两部分组成：分类loss（conf loss）和定位loss（loc loss）。正常情况下，两个loss都应该稳步下降。如果分类loss下降但定位loss不降，说明模型在学分类但没学好定位，可能是anchor设置有问题。如果两个loss都震荡，可能是学习率太大或者batch size太小。
我遇到过一个典型问题：训练到中期，loss突然变成NaN。排查后发现是某张图片的标注框坐标超出了图片边界，导致计算loss时出现异常值。解决办法是在生成LMDB之前，检查所有标注框，把超出边界的坐标裁剪到边界内。
4.3 难例挖掘与数据平衡
车牌检测的一个难点是正负样本极度不平衡。一张1920x1080的图片里，车牌可能只占100x30像素，其余全是背景。SSD默认使用hard negative mining，在训练时挑选loss最高的负样本参与梯度更新。这个策略在Caffe的SSD实现里通常已经内置了，但参数需要调整。
具体来说，MultiBoxLoss层里有一个neg_pos_ratio参数，控制负样本和正样本的比例。默认是3:1，我一般调到5:1或者7:1，让模型看到更多的负样本，减少误检。但也不能调太高，否则正样本的梯度会被淹没，导致漏检增加。
另外，如果某些场景的误检特别严重（比如把广告牌上的文字误认为车牌），可以专门收集这些误检的图片作为负样本加入训练集。这种针对性负样本挖掘的效果比盲目增加数据量要好得多。
4.4 检测效果评估与常见问题排查
评估检测模型的时候，不能只看mAP。车牌检测有它的特殊性：漏检的代价比误检高。漏检意味着系统完全没看到车牌，误检还可以通过后续的识别模型过滤掉（识别模型对非车牌区域的输出置信度通常很低）。所以我在评估时会单独看recall，确保recall在95%以上。
常见的检测问题和对策：
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| 远距离车牌漏检 | anchor太小或特征图分辨率不够 | 增加小anchor、提高输入分辨率 |
| 倾斜车牌漏检 | anchor角度单一 | 增加旋转增强、用旋转框检测 |
| 误检广告牌文字 | 负样本不足 | 加入针对性负样本 |
| 框位置不准 | 定位loss权重太低 | 提高loc loss的权重系数 |
| 训练不收敛 | 学习率太大或数据标注错误 | 降低学习率、检查标注 |
5. 字符识别模型的设计与训练细节
5.1 多标签分类 vs 序列识别：为什么选前者
字符识别这块，主流方案有两种。一种是序列识别，用CRNN（CNN+RNN+CTC）直接输入车牌图片，输出字符序列。另一种是多标签分类，把每一位字符当作独立的分类任务。CRNN的好处是不需要字符分割，对不定长车牌更友好。但在Caffe里实现CRNN比较麻烦，因为Caffe对RNN的支持很有限，CTC Loss也没有官方实现。
多标签分类在Caffe里实现起来就简单多了。网络结构就是一个普通的CNN，最后接一个全连接层，输出维度是7×67（假设7位车牌，67个字符类别）。训练时每一位独立计算softmax loss，然后求和。推理时每一位取argmax，拼起来就是车牌号码。
这种方案的缺点是对字符分割有隐式依赖。如果车牌图片里字符粘连严重，或者有倾斜导致字符位置偏移，分类准确率会下降。解决办法是在训练数据里加入各种粘连和倾斜的样本，让模型学会处理这些情况。另外，可以在网络里加入空间注意力机制，让模型自动关注到每一位字符的位置。
5.2 识别网络的结构设计与字符类别处理
识别网络我通常用一个轻量级的CNN，比如MobileNet的Caffe版本，或者自己搭一个5层卷积+2层全连接的小网络。输入尺寸统一resize到96x32（宽x高），这个尺寸对车牌来说刚好，既能保留字符细节，又不会太大影响速度。
字符类别的处理有几个细节要注意。第一，省份简称汉字的样本量通常远少于字母和数字。比如"京"的出现频率可能只有"1"的十分之一。这种类别不平衡会导致模型对汉字的识别率偏低。解决办法是对汉字类别的loss加权，在SoftmaxWithLoss层里设置class_weighting参数，给汉字更高的权重。
第二，容易混淆的字符要特别处理。比如"0"和"O"、"1"和"I"、"2"和"Z"、"8"和"B"。虽然车牌规范里通常不用I和O，但实际图片里因为字体和模糊的原因，这些字符看起来很像。我通常会在训练数据里故意加入一些模糊的样本，让模型学会区分。
第三，新能源车牌是8位，比普通车牌多一位。如果两种车牌都要支持，网络输出维度要设成8×67，普通车牌的最后一位用padding填充。或者训练两个独立的识别模型，分别处理7位和8位车牌。
5.3 训练技巧：学习率策略与正则化
识别模型的训练比检测模型容易收敛，但也有一些技巧。学习率我一般从0.01开始，用poly策略衰减：
lr_policy: "poly" power: 0.9 max_iter: 100000poly策略的好处是学习率平滑下降，不会像step策略那样在切换点产生震荡。对于识别这种相对简单的任务，poly策略通常能收敛到更好的局部最优。
正则化方面，Dropout是必须的。我在全连接层前面加一个Dropout层，dropout ratio设0.5。另外，权重衰减（weight decay）设0.0001到0.0005，防止过拟合。如果训练集比较小（少于1万张），还可以加L2正则化或者用数据增强来增加样本多样性。
还有一个容易被忽略的点：Batch Normalization的位置。我习惯在每个卷积层后面加BN层，但BN层的参数在训练初期会剧烈变化，可能导致loss震荡。解决办法是在训练初期冻结BN层的参数，等loss稳定后再放开。Caffe里可以通过设置lr_mult为0来冻结BN层的参数。
5.4 识别准确率的提升路径
识别准确率从90%提升到99%的过程，往往比从0到90%更费劲。我总结了几条有效的提升路径：
第一条是增加难例样本。把识别错误的样本收集起来，人工检查后加入训练集。这种迭代式的难例挖掘通常能在两三轮之后把准确率提升2到3个百分点。
第二条是调整输入分辨率。96x32的输入对清晰的车牌够用，但对模糊的车牌就力不从心了。可以尝试把输入提高到128x48，看看准确率有没有提升。但要注意，分辨率提高会增加计算量，需要权衡。
第三条是模型融合。训练多个识别模型，推理时取平均或者投票。这种方法能稳定提升1到2个百分点，但推理时间会成倍增加。如果对速度要求不高，可以考虑。
第四条是后处理规则。利用车牌号码的先验知识做校正。比如中国车牌第一位必须是省份简称，第二位必须是字母，后面五位是字母或数字。如果模型输出的第一位是数字，就可以根据置信度选择次优的汉字。这种规则后处理能纠正一部分明显的错误。
6. C++推理部署与性能优化
6.1 Caffe C++接口的集成方式
Caffe的C++接口用起来比Python接口麻烦一些，但性能更好，而且不依赖Python环境。集成的基本流程是：加载模型、构造Blob、前向传播、读取输出。
#include <caffe/caffe.hpp> // 初始化网络 caffe::Net<float> net("deploy.prototxt", caffe::TEST); net.CopyTrainedLayersFrom("model.caffemodel"); // 构造输入Blob caffe::Blob<float>* input_blob = net.input_blobs()[0]; input_blob->Reshape(1, 3, 512, 512); // 填充数据 float* input_data = input_blob->mutable_cpu_data(); // ... 把图片数据拷贝到input_data // 前向传播 net.Forward(); // 读取输出 const caffe::Blob<float>* output_blob = net.output_blobs()[0]; const float* output_data = output_blob->cpu_data();这段代码看起来简单，但实际集成时有几个坑。第一，Caffe的编译选项要和你的项目一致，比如是否用GPU、是否用OpenBLAS、Protobuf的版本。如果编译选项不一致，链接时会报各种奇怪的错误。第二，多线程环境下要小心，Caffe的Net对象不是线程安全的，每个线程需要独立的Net实例。第三，内存管理要手动处理，Caffe的Blob不会自动释放，需要自己管理生命周期。
6.2 检测与识别的串联逻辑
检测和识别两个模型串联的时候，有几个工程上的细节需要处理。首先是检测框的筛选。SSD会输出很多框，需要根据置信度阈值（通常0.5到0.7）和NMS（非极大值抑制）来筛选。NMS的IoU阈值我一般设0.45，既能去掉重复框，又不会把相邻的车牌误删。
然后是车牌区域的裁剪和校正。检测框可能是倾斜的，直接裁剪会导致字符变形。我通常会用仿射变换把车牌旋转到水平。旋转角度可以通过检测框的四个角点计算，或者用最小外接矩形。校正后的车牌再送进识别模型。
最后是识别结果的拼接和后处理。识别模型输出每一位的字符和置信度，如果某一位的置信度低于阈值（比如0.8），可以标记为不确定，或者用语言模型做校正。中国车牌有固定的格式，可以用正则表达式做初步校验。
6.3 推理速度的优化手段
推理速度的优化可以从几个层面入手。模型层面，可以用更轻量的网络结构，比如把VGG换成MobileNet，参数量减少一个数量级，速度提升明显。计算层面，可以用Intel MKL或者OpenBLAS加速矩阵运算，GPU环境下用cuDNN。工程层面，可以用多线程并行处理多路视频流，或者用批处理（batch inference）提高GPU利用率。
我实测过的一组数据：在Intel i7-8700 CPU上，SSD 512x512的检测模型单张推理约45毫秒，识别模型约15毫秒，加上前后处理总共约80毫秒。如果用GPU（GTX 1060），检测降到8毫秒，识别降到3毫秒，总共约20毫秒。这个速度对于25fps的视频流来说足够了。
还有一个容易被忽略的优化点：图片预处理的速度。图片的缩放、归一化、通道转换这些操作如果都用CPU做，可能比模型推理还慢。可以用OpenCV的UMat或者GPU加速，或者用Intel IPP库优化。
6.4 实际部署中的稳定性问题
部署到生产环境后，稳定性问题比精度问题更让人头疼。我遇到过几个典型情况：
第一个是内存泄漏。Caffe的Blob在每次Forward之后不会自动释放中间结果，如果循环调用Forward，内存会持续增长。解决办法是定期重建Net对象，或者用net.ClearParamDiffs()清理中间变量。
第二个是多线程竞争。如果多个线程共用一个Net对象，会出现数据竞争，导致结果错乱甚至崩溃。解决办法是每个线程维护独立的Net实例，或者加锁串行化。
第三个是异常输入的处理。如果输入的图片损坏、尺寸异常、或者全黑全白，模型可能会输出奇怪的结果。需要在预处理阶段做校验，过滤掉异常输入。
第四个是模型版本管理。生产环境可能同时运行多个版本的模型，需要有一套版本管理机制，确保加载的模型和配置文件匹配。我通常会在模型文件名里加入版本号和日期，部署时通过配置文件指定。
7. 项目复盘：那些文档里不会写的经验
7.1 数据质量比模型结构更重要
这个道理听起来像废话，但我在车牌识别项目里体会特别深。早期我花了很多时间调网络结构，尝试各种trick，准确率提升缓慢。后来把精力转到数据清洗上，把标注错误的样本修正、把模糊到无法辨认的样本剔除、把重复的样本去重，准确率一下子提升了5个百分点。
具体来说，标注错误的样本危害极大。一张标注错误的车牌图片，会让模型学到错误的映射关系。如果这种错误样本占比超过1%，模型的准确率上限就会被拉低。我建议在训练之前，至少抽样检查5%的标注数据，确保标注质量。
7.2 学习率是最重要的超参数
如果只能调一个超参数，我会选学习率。学习率太大，loss震荡不收敛；学习率太小，收敛慢且容易陷入局部最优。我的经验是：先用一个较大的学习率跑几百次迭代，观察loss曲线，如果loss下降很快但后期震荡，就减小学习率；如果loss几乎不降，就增大学习率。
另外，warmup策略对车牌识别这种小数据集特别有效。在训练的前几千次迭代里，学习率从很小的值线性增加到初始学习率，可以避免训练初期的不稳定。Caffe里可以通过修改solver的lr_policy为"poly"并设置合适的power来实现类似效果。
7.3 不要忽视后处理的作用
很多人把精力全放在模型上，忽略了后处理。实际上，合理的后处理能纠正不少模型错误。比如车牌号码的格式校验：中国车牌第一位必须是汉字，第二位必须是字母，后面是字母或数字。如果模型输出的第一位是数字，就可以根据置信度选择次优的汉字。这种规则后处理在实测中能提升1到2个百分点的准确率。
还有一个后处理技巧是多帧投票。视频流里同一辆车会出现很多帧，把多帧的识别结果做投票，取出现次数最多的号码。这种方法对静态场景特别有效，能过滤掉偶发的识别错误。
7.4 模型更新与迭代的节奏
车牌识别系统上线后，模型需要持续迭代。新的车牌样式（比如新能源车牌）、新的拍摄场景（比如夜间红外）、新的干扰因素（比如雨雪天气）都会导致模型性能下降。我建议建立一个反馈闭环：系统运行时记录低置信度的样本，定期人工审核后加入训练集，重新训练模型。
迭代的节奏不用太频繁，一般一个月一次就够了。太频繁会导致模型不稳定，太慢又跟不上场景变化。每次迭代后要做A/B测试，确保新模型在各项指标上都不差于旧模型。
7.5 一些零散但有用的技巧
最后分享几个零散但很实用的技巧。图片的EXIF信息要处理，有些相机会在EXIF里记录旋转角度，如果不处理，读进来的图片可能是旋转的。OpenCV的imread默认是BGR，但Caffe的Blob期望的也是BGR，所以不需要转换，但如果你用其他库读图就要注意。LMDB的map_size要设得足够大，否则写入时会报错，我一般设1TB。训练日志要定期备份，Caffe的日志默认输出到stderr，重定向到文件后可以用Python脚本解析出loss曲线。
还有一个关于Caffe编译的经验：Protobuf的版本一定要和Caffe匹配。我遇到过因为Protobuf版本不一致导致模型加载失败的情况，排查了很久。建议用Caffe自带的Protobuf版本，或者用conda安装指定版本的Protobuf。
这个项目后续还可以往几个方向扩展：一是加入车牌颜色识别，区分蓝牌、黄牌、绿牌；二是支持多角度车牌，用旋转框检测；三是模型量化，把float32的模型转成int8，进一步加速推理。这些方向都有实际需求，值得深入探索。
