EfficientNet训练后模型测试实战：从权重加载到指标评估

开头一段 最近帮别人看一个图像分类项目中途接手时模型已经训练完了剩下要做的事情非常明确把训练好的 EfficientNet 模型加载起来在测试集上完整跑一遍输出准确率、混淆矩阵这些指标顺便排查一下单张图片推理表现不对的几处坑。听起来很简单实际做下来发现“测试”这个环节其实藏了很多细节稍不注意就得出错误结论。这篇文章就把整个过程从头到尾拆开讲一遍包括模型架构的基本逻辑、加载训练好权重的正确姿势、图像预处理的隐藏细节、评估指标的真正含义以及我在实际测试中遇到的典型问题和解决方法。如果你手里刚好也有训练好的 EfficientNet 模型或者正准备拿预训练权重做迁移学习测试这篇文章可以当作一份可以直接上手的操作手册。我会尽量用从业者之间交流的口吻来写不绕弯子也不堆理论。1. 测试前的思路拆解EfficientNet 为什么值得单独讲“测试”这件事1.1 EfficientNet 核心设计思路回顾在进入测试环节之前我还是把 EfficientNet 的来龙去脉简单梳理一遍因为理解它的设计逻辑会直接影响你测试时的许多选择。EfficientNet 的核心是“复合缩放”compound scaling。过去的网络设计通常是在深度、宽度、输入分辨率这三个维度上单独做调整加层数、加通道数、提高图片分辨率。但 EfficientNet 的工作指出这三个维度并不是独立的它们之间互相影响应该用一个统一的系数同时缩放。具体来说深度按 $\alpha^\phi$、宽度按 $\beta^\phi$、分辨率按 $\gamma^\phi$ 缩放其中 $\alpha \cdot \beta^2 \cdot \gamma^2 \approx 2$ 是一个约束条件用来保证缩放后网络的计算量大致可控。这样做的好处是给你一个 baseline 网络你通过一个系数 $\phi$ 就能得到从 B0 到 B7 这一系列模型。这个设计带来的直接结果是 EfficientNet 系列在相同计算量下准确率往往优于很多手工设计的网络。比如 B0 的参数量和 FLOPs 都不大但精度能和不少更大的模型抗衡。也正因为这个“轻量但高效”的特点EfficientNet 在教育、医疗、工业视觉等对部署成本敏感的场景里用得非常多。当然EfficientNet 也有自己的短板比如在不同框架间转换权重时相对容易踩坑对输入预处理的敏感度也偏高。这两点恰好都会在“测试”环节暴露出来。1.2 “测试”不是训练的反向操作很多人觉得训练模型很难测试很容易加载权重喂图片拿输出就行。但实际经验告诉我测试阶段踩的坑往往比训练阶段更隐蔽因为测试涉及几个训练时不会注意到的关键点训练时模型处于 training 模式BatchNorm 会实时计算 batch 统计量测试时必须切换成 eval 模式否则单张图片推理结果会异常。训练时常会用随机裁剪、翻转等数据增强测试时如果沿用训练增强相当于每次评测都在给模型加扰动结果自然不会稳定。图像预处理的归一化参数、输入尺寸、通道顺序如果和模型训练时不一致再好的模型也会被“测崩”。所以我认为测试训练好的模型这件事本质上是对一条完整推理链路正确性的验证。要做的不只是调用model.predict()或者model(img)这么简单而是要把整个数据从磁盘到张量的流动过程都纳入检查范围。1.3 测试目标分层单图验证、批量评测、部署回归我一般会把模型测试拆成三个层次来做按顺序推进任何一个环节没通过都不会往后走单图验证确认加载的模型能对一张已知图片给出符合预期的结果重点排查预处理和加载链路。批量评测在完整测试集上统计准确率、Top-5、混淆矩阵等指标评估模型实际能力。部署回归在真实业务场景里验证模型表现必要时导出到推理框架做性能和稳定性压测。这篇文章的标题是“利用训练好的模型测试”所以我重点讲前两层部署回归稍微带一点思路。2. 模型加载与权重文件处理的几个关键点2.1 弄清楚你手里的模型是哪种形态测试一个训练好的模型之前先得搞清楚你的模型“长什么样”。按来源可以大致分成三类自己训练的完整模型文件比如 TensorFlow 的.h5、PyTorch 的.pth里面既有网络结构也有权重加载后可以直接推理。官方或开源社区发布的预训练权重通常只有权重没有结构需要配合对应的模型定义代码一起加载。中间产物、检查点文件比如 TensorFlow 的 checkpoint 或 PyTorch 的.pth.tar这类文件往往还包含优化器状态、epoch 信息需要抽取其中的model或state_dict字段。我在早期的项目里就吃过这个亏直接用torch.load把整个检查点文件当成权重塞进模型结果 key 对不上报了一堆错。后来我习惯先打印一下文件的键名再做针对性加载基本上就没有再出过类似问题。如果是 Keras 生态加载会稍微省心一点只要保存时用的是model.save()而不是model.save_weights()加载时tf.keras.models.load_model()就能一次性把结构和权重都恢复出来。但这里也有个版本兼容性问题Keras 2.x 和 Keras 3 之间的 h5 文件有时会互相不认实测下来比较稳妥的做法是保存时把自定义层和损失函数都注册好加载时显式传入custom_objects。2.2 官方权重加载与严格模式陷阱用timm一个非常常用的图像模型库加载 EfficientNet 预训练权重时代码很简单import timm model timm.create_model(tf_efficientnet_b0, pretrainedTrue) model.eval()但如果你是自己定义模型结构再手动加载官方权重就会遇到strictTrue的问题。默认情况下 PyTorch 的load_state_dict是严格模式只要 key 对不上就直接报错。出现这种情况常见原因有几个分类头classifier的维度与预训练模型不一致比如 ImageNet 上是 1000 类而你的项目可能只有 10 类或 5 类。输入层的通道数被改过比如你要做单通道灰度图分类。模型定义里的层名与官方层名不一致常见于手敲结构时命名不规范。解决方案也很常规把分类头的维度对齐或者加载时跳过最后一层state_dict torch.load(efficientnet_b0.pth) state_dict.pop(classifier.weight) state_dict.pop(classifier.bias) model.load_state_dict(state_dict, strictFalse)不过strictFalse不是万能的。它会让你错过其他层因为命名不一致而产生的问题。建议加载后打印一下“未匹配的 key”确认主要特征的权重都加载进去了再放心测试。2.3 推理模式train/eval 千万别搞混加载完模型以后第一件事是设置成推理模式。PyTorch 里一行model.eval()TensorFlow 里通常不需要显式设置但涉及 BatchNorm、Dropout 时训练和推理行为是不同的。EfficientNet 里大量使用了 BatchNorm如果不切到 eval 模式批归一化会继续用当前 batch 的统计量做归一化单张或多张图片测试时结果会非常不稳定。我见过不少人在实盘测试的时候明明训练准确率 90% 多一测单张图效果差得离谱最后发现就是忘了model.eval()。这个“坑”看起来简单但排查起来往往会浪费不少时间。2.4 关于“训练好的模型”的边界问题很多时候我们说的“测试”其实不只是把图片喂进去看输出而是要评估这个模型在目标业务场景下的真实表现。如果数据分布发生了明显变化比如训练时用的是公开数据集、上线时用的是项目组自己拍的图那么迁移过来的预训练模型的所谓“高准确率”并不代表实际效果好。这一点我留在后面的评估部分细说但加载模型之前先确认这个边界能省下后面很多无效工作。3. 图像预处理与单图推理链路搭建3.1 不同型号的输入尺寸EfficientNet 从 B0 到 B7输入分辨率是递增的B0 是 224B1 是 240B2 是 260B3 是 300B4 是 380B5 是 456B6 是 528B7 是 600。加载模型前务必确认对应型号的输入尺寸否则测试时图像缩放不对模型输入维度不对结果必然出错。注意这里的“输入尺寸”是官方训练时的分辨率测试时如果随意改成其他尺寸虽然多数网络可以通过全局池化接上全连接层而不至于报错但效果会打折扣因为模型的感受野和特征尺度是针对原始分辨率设计的。我在项目里习惯把尺寸配置写成字典方便切换不同型号input_sizes { efficientnet_b0: 224, efficientnet_b1: 240, efficientnet_b2: 260, efficientnet_b3: 300, }虽然使用 timm 时可以通过model.default_cfg[input_size]直接拿到默认尺寸但自己维护一个映射表在写预处理工具时会直观很多。3.2 归一化不是所有模型都用同一组 mean/stdEfficientNet 的预训练归一化方式和 ResNet 不一样。ResNet 系列通常用mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]而 EfficientNet 官方实现和部分第三方权重对归一化的处理是有差异的。有些实现会额外做一次0-1 归一化后再减均值除标准差有些则直接使用 ImageNet 的 mean/std。如果你用的是 timm它会自动从模型配置里读归一化参数不需要手写。但如果你是从其他渠道拿到的权重就一定要确认归一化方式是否一致。另外一个容易忽略的点是EfficientNet 官方实现和 timm 实现的数据增强策略不同会导致微调后的模型行为有细微差异。你用 timm 的推理管线测别人用官方实现训出来的模型时可能效果比预期略低这大概率不是模型的问题而是预处理差异。这种情况下优先按照对方训练时的预处理来测。3.3 单张图片推理的完整示例下面给出一段基于 PyTorch timm 的单图推理代码这里我以一张本地图片为例import torch import timm from PIL import Image from timm.data import resolve_data_config, create_transform model timm.create_model(tf_efficientnet_b0, pretrainedTrue) model.eval() config resolve_data_config({}, modelmodel) print(Config:, config) transform create_transform(**config) img Image.open(test_001.jpg).convert(RGB) input_tensor transform(img).unsqueeze(0) with torch.no_grad(): output model(input_tensor) probs torch.nn.functional.softmax(output[0], dim0) top5 torch.topk(probs, 5) print(top5)这段代码里有几个设计意图model.eval()关闭 Dropout 和 BatchNorm 的 batch 统计更新。resolve_data_config从模型配置里自动读取输入尺寸、归一化参数避免手写出错。torch.no_grad()推理阶段不需要计算梯度节省显存和耗时。softmax topk得到各类别的概率和 Top-5 结果这是图像分类任务最常用的输出形式。如果不想用 timm 的封装自己写预处理也完全可以核心流程是Resize(256) - CenterCrop(224) - ToTensor - Normalize。这套流程和传统 CNN 的测试预处理一致效果也稳定。3.4 批量测试与数据加载单图测试打通以后接下来就是批量测试。批量测试的常见诉求是看整体准确率、看单类效果顺带输出预测结果方便后续分析。批量推理的数据加载方式可以直接复用 PyTorch 的ImageFolder不需要自己造轮子from torch.utils.data import DataLoader from torchvision.datasets import ImageFolder dataset ImageFolder(test_data, transformtransform) loader DataLoader(dataset, batch_size32, shuffleFalse, num_workers4) correct 0 total 0 with torch.no_grad(): for images, labels in loader: outputs model(images) _, predicted torch.max(outputs, 1) correct (predicted labels).sum().item() total labels.size(0) print(fTop-1 Accuracy: {correct / total:.4f})这里有个经验批量推理时batch_size的选择要结合显存来定。EfficientNet-B0 在 224 分辨率下显存占用不大但换到 B4、B5输入分辨率和通道数都上去了显存占用会成倍上涨这时候要适当减小 batch。3.5 推理性能与实际部署中的注意点模型测试不仅是看准确率也要看推理速度是否能满足业务需求。如果你的场景是离线批量测试那对速度的要求不高但如果模型要上线做实时推理性能就是硬指标。我在实测中发现以下几个优化点非常有效图片解码是隐藏瓶颈。大量小图用 Pillow 逐张读取非常慢可以试试turbojpeg或cv2解码速度有显著提升。半精度推理将模型和输入都转成 FP16显存占用减半推理速度更快但要注意归一化操作也要在相同的精度下进行。导出 ONNX 后用onnxruntime或 TensorRT 推理这在端侧和服务端部署时都很常用。4. 测试指标评估别只盯着准确率4.1 从 Top-1 到 Top-5 的视角差异分类任务里最常见的指标是 Top-1 准确率预测概率最高的类别是否和标签一致。但很多实际业务问题里Top-1 并不够用。比如做细粒度分类两个亚类之间存在很强的视觉混淆用户可能只需要“大类正确”这时 Top-5 能给你更多信息。我举一个实际例子某个项目做零件表面缺陷分类模型把“划痕”判成了“轻微压痕”Top-1 是错的但 Top-5 里真正的类别排第二位。这时候如果你只看 Top-1会低估模型的实际可用性但如果结合 Top-5 看就能知道模型其实已经学到了足够的信息只是类别之间的决策边界还需要调优。评估时建议同时输出Top-1 准确率Top-5 准确率各类别的 Precision 和 Recall混淆矩阵4.2 混淆矩阵与误判分析混淆矩阵不能只用来“看”更重要的是从里面找规律。我通常会把矩阵行归一化这样每一行代表“该类别的样本被分到了哪些类”能直观看到哪些类别互相混淆、哪些类别几乎是随机猜。有一次我在项目里发现两个类别混淆率特别高打开图片一看发现标签本身就有问题标注员把“背景干净”和“背景轻微反光”混在一起标。纠正标签后模型准确率直接提升了 3 个百分点。这类问题不在模型本身而在数据质量而测试评估恰恰能帮你发现这个层面的问题。4.3 不同测试集的泛化评估训练时大家习惯把数据集随机划分成 train/val/test但这个划分方式有一个隐含假设测试集和训练集来自同一个分布。真实业务场景里模型上线后面对的数据往往和训练集有偏差。比如训练集是白天拍摄的照片夜间场景的图片效果就会差很多。所以在测试阶段我强烈建议准备至少两个维度的测试集随机划分的测试集评估模型在“同分布”数据上的表现。额外采集的业务真实数据评估模型在“目标分布”上的表现。如果业务数据量很小哪怕先拿 100 张真实场景图跑一轮得到的高低落差也能让你心里有数。模型在随机测试集上 95%在真实场景 70%那说明模型没有真正学到你要的规律后面要做的不是调测试管线而是回头补数据或做迁移学习。4.4 置信度校准问题很多测试报告只给准确率但实际业务往往还要看置信度。有些模型对陌生样本会输出很高的概率比如一张完全模糊的图也被给了 0.99 的置信度这在上线做自动决策时是非常危险的信号。测试阶段可以统计一下“正确分类样本的平均置信度”和“错误分类样本的平均置信度”。如果两者差距不大说明模型对错误结果过于自信需要考虑温度缩放temperature scaling等校准手段。这个指标虽然不常出现在入门教程里但对真正上线的系统很有价值。5. 常见的坑与排查思路这一节我把自己实际遇到过的问题整理成一个速查表再针对其中几个典型的做点说明。现象可能原因快速排查方法加载报错 size mismatch分类头维度不一致打印 state_dict 的 key对比模型定义推理结果和预期差距大忘了 eval / 预处理不一致用训练集中的样本做 sanity check批量推理速度慢图片解码瓶颈换用 cv2 / turbojpeg 解码显存爆掉batch 太大或输入分辨率太高减小 batch或使用半精度不同框架结果不一致归一化参数不同手动对齐预处理数值5.1 加载权重时报 size mismatch这个报错出现频率最高。原因通常是分类头维度不一致。比如预训练模型是 1000 类你的模型最后一层是 10 类。解决方法是加载时去掉最后一层的 key或者初始化后只加载除分类头外的权重再接一个自定义分类头。5.2 输入图尺寸不对导致的中途报错如果你的模型对输入有固定尺寸要求但图片没有缩放到对应尺寸就会在全连接层的地方报维度错误。解决方法是检查预处理后的张量维度和模型输入要求对齐。5.3 效果差但不清楚是模型问题还是预处理问题这种问题最隐蔽。通常的做法是做一个 sanity check拿一张训练集中表现很好的图片走完整测试流程看输出概率是否和训练时接近。如果训练时 0.99、测试时只有 0.5基本可以断定是预处理或模型模式的问题而不是模型本身的问题。6. 从“测试”到“部署”的后续思路如果测试结果达到预期下一步大概率是部署。这里我只说几个和“测试训练好的模型”直接相关的点。6.1 模型导出时的注意事项把 PyTorch 模型转成 ONNX 时最常遇到的问题就是动态输入尺寸和 op 集版本。我的习惯是固定输入尺寸导出例如[1, 3, 224, 224]这样后续用 onnxruntime 或 TensorRT 推理时兼容性更好。dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, efficientnet_b0.onnx, opset_version11, input_names[input], output_names[output], )如果你打算用 TensorRT尤其要注意模型里有些 op 在转换时会被替换或合并建议转换后跑一遍校验确保精度没有明显掉点。6.2 用回归测试集守住迭代质量模型迭代是常态不是一次性的。我的习惯是维护一个回归测试集里面包含过去犯过错的失败样本、容易混淆的边界样本以及新增业务场景的真实样本。每次换新模型都拿这套样本集跑一遍确保新模型没有在修复旧问题的同时引入新的退化。这个小习惯对长期维护一个图像分类系统非常有用尤其是当模型更新频率高的时候。7. 最后想说的话回到标题EfficientNet 利用训练好的模型测试。我自己的实践经验是模型本身很少成为瓶颈真正的瓶颈往往在“数据怎么喂进去”和“结果怎么解读”。只要你把预处理、加载、推理模式和评估指标这四件事对齐测试环节基本就能顺利走完。最后再分享两个小技巧。第一无论用什么加载方式都要准备一张“已知结果”的图片做冒烟测试比如拿一张训练集里准确率最高的图走一遍完整流程。如果这张图都测不对那一定是流程有问题。这个技巧帮我排查过很多“怎么调都不对”的情况。第二尽量把测试脚本参数化模型名称、权重路径、图片目录、输入尺寸都放到配置文件里。因为 EfficientNet 有 B0 到 B7 一大堆变体参数化之后切换模型测试只需要改一行配置不需要动处理逻辑能省下不少时间。如果你正准备拿训练好的 EfficientNet 做模型测试照着上面的流程走一遍应该能很快得到一份可靠、可解释的测试结果。测试顺利的话再考虑后面的优化和部署也不迟。