PyTorch运动鞋细粒度图像分类实战：从数据到ONNX部署-北京尧图网络

做运动鞋识别这个题目最开始是给一个做电商图像审核的朋友帮忙他们后台每天要过几万张商品图人工判断这双鞋是什么品类、什么系列效率太低。后来我把这套流程沉淀成了一个完整的实战模板正好对应学习计划里的第5周P5周任务用PyTorch把运动鞋识别从头跑通。这篇文章要聊的就是这件事——深度学习框架下做细粒度图像分类具体到运动鞋这个品类包含数据怎么攒、模型怎么选、训练怎么调、翻车了怎么救。适合已经会写几行PyTorch、但还没完整走过一个图像分类项目的人也适合带学生做课设的同行拿去当参考讲义。1. 项目整体设计与技术路线拆解运动鞋识别听着像识别这是不是鞋实际做起来是细粒度分类。它和识别猫狗完全不是一回事猫和狗的轮廓差异是数量级的而一双跑鞋和一双板鞋差异可能只在中底厚度、鞋面走线、鞋头形状这几个局部区域。这就决定了整个方案不能照搬入门教程里卷积网络堆几层直接训的路子。1.1 这个任务到底难在哪里先说清楚难点后面的技术选择才有依据。我把它归纳成三条。第一是类间差异小、类内差异大。同一款跑鞋换个配色在像素空间里差异可能比两款不同型号的鞋还大而不同品牌的两双复古跑鞋整体轮廓可能高度相似。模型如果只学到颜色和大致形状这种粗粒度特征很容易在验证集上虚高、到线上就崩。第二是长尾分布。真实商品图里热门款动辄上千张冷门款可能只有几十张。直接按自然分布训练模型会严重偏向头部类别尾部类别的召回率惨不忍睹。第三是拍摄条件不可控。白底图、模特上脚图、场景摆拍图混在一起光照、角度、背景差异极大。这部分如果不在数据阶段处理掉模型会把背景当成捷径特征——比如学到白底某品牌这在测试集上可能碰巧管用一换场景就失效。提示如果你的验证准确率很高但实际用起来很差第一件事不是调模型而是去看错误样本里有多少是背景干扰导致的。这个问题在细粒度分类里出现的频率远超你的想象。1.2 技术路线为什么这么定基于上面的难点我把路线定成迁移学习为主、数据增强兜底、分阶段微调。选迁移学习而不是从零训理由很实在从零训一个ResNet50级别的网络需要千万级带标注数据才能收敛到可用水平我们手上撑死几万张从零训必然过拟合。而ImageNet预训练权重里已经包含了对边缘、纹理、材质这些底层特征的提取能力鞋面织物纹理、鞋底橡胶质感这类信息正好能复用。这是用别人的通用特征换自己的训练成本。分阶段微调是第二个关键决策。很多人拿到预训练模型就直接解冻所有层、用一个大学习率猛训结果预训练权重被破坏效果反而不如只训最后一层。我的做法是先冻结骨干只训分类头让新初始化的分类器先收敛到一个合理区域再解冻后面几个stage用小学习率精调。这样梯度的冲击是渐进的预训练特征不会被一开始就带偏。数据增强兜底指的是把增强强度按任务特性来设计而不是无脑套Albumentations的默认配置。运动鞋识别里水平翻转是安全的左右脚互换不影响品类判断但垂直翻转就危险了——鞋底朝上的图在真实场景几乎不存在强行增强等于给模型灌噪声。这个细节下面会展开。1.3 环境与版本约束版本这块我吃过亏必须写清楚。PyTorch 2.x 和 1.x 在torchvision.models的权重接口上有变化老代码里的pretrainedTrue在2.x里会报弃用警告推荐改成weightsResNet50_Weights.IMAGENET1K_V2。另外torchvision.transforms在0.15之后推荐用v2接口支持对检测框和分割掩码同步变换虽然分类任务用不上但统一用v2能避免以后扩展时的麻烦。我的实测组合是Python 3.10、PyTorch 2.1、torchvision 0.16、CUDA 11.8。这套组合在单卡24G显存上跑batch size 64、输入224×224是稳的。如果你显存小把batch降到32同时把学习率按线性缩放规则除以2这个换算后面会讲。2. 数据集构建与预处理的关键细节模型再花哨数据烂了全是白搭。这一章是我认为整个项目里最值得投入时间的地方占比应该在六成以上。2.1 类别体系怎么设计类别体系不是有多少款就分多少类这么简单。分类粒度太细每类样本量不够模型学不动粒度太粗业务上又没用。我的经验是按业务需求倒推粒度。如果下游要做的是跑鞋/板鞋/篮球鞋/帆布鞋这种粗分类那4到8个大类足够如果要做的是具体型号识别那类别数可能上百这时候就得配合度量学习比如ArcFace、Triplet Loss而不是单纯靠Softmax。P5周这个阶段我建议先做两层级方案第一级粗分类定大品类第二级在品类内做型号细分。这样每一级的类别数都可控而且第一级的准确率通常能到95%以上第二级的错误不会污染整体结果。我在一个模拟项目X上就是这么做的粗分类8类、细分每类10到20个子类整体可控性好很多。2.2 数据清洗与标注规范标注这块最容易被低估。我见过太多团队栽在标注一致性上同一个款A标注员标成跑鞋B标成训练鞋模型学到的是标注员的偏好而不是鞋的特征。解决办法是写一份标注手册把每个类别的判定标准写成可执行的规则比如中底厚度超过2.5厘米且鞋头有明显上翘归为跑鞋。然后抽10%的样本做双人标注计算一致率低于90%就回去改手册。数据清洗要做三件事去重用感知哈希pHash阈值设8以内的直接判为重复、去坏图分辨率低于224×224的、严重模糊的、主体被裁掉一半的、去错标用一个在ImageNet上预训练的模型跑一遍把置信度极高但和标注不符的样本挑出来人工复核。第三步我实测能捞回大概3%到5%的错标别小看这个比例错标对损失函数的干扰是很直接的。2.3 训练/验证/测试划分的坑划分看起来最简单实际上坑最多。最典型的错误是按图片随机划分结果同一个商品的不同角度图同时出现在训练集和验证集里验证准确率虚高十几个点上线就露馅。正确做法是按商品ID分组划分同一个商品的所有图片只能落在同一个集合里。用sklearn.model_selection.GroupShuffleSplit一行就能搞定。比例我一般用7:1.5:1.5测试集要留够不然误差棒的置信区间宽得没法看。还有一个细节划分要分层。长尾分布下如果纯随机划分某些尾部类别可能在验证集里一张都没有。用StratifiedGroupKFold能同时兼顾分层和分组虽然sklearn里这个类出现得比较晚但值得升级版本用上。2.4 数据增强的参数怎么定增强策略我按安全增强和激进增强分开列实测下来这套配置在运动鞋任务上比较稳。增强操作参数设置是否必开设计理由RandomResizedCropscale(0.7, 1.0)必开模拟不同拍摄距离下界设0.7是为了避免把鞋裁成碎片RandomHorizontalFlipp0.5必开左右脚对称语义不变ColorJitterbrightness0.2, contrast0.2, saturation0.2, hue0.05必开模拟不同光源hue压到0.05是因为色相偏移过大会把红鞋变绿鞋RandomRotationdegrees10可选小幅旋转模拟手持拍摄超过15度就不真实了VerticalFlip-禁止鞋底朝上的图在真实分布里几乎不存在RandomErasingp0.25, scale(0.02, 0.15)推荐强制模型看局部缓解背景捷径归一化参数用ImageNet的mean[0.485, 0.456, 0.406]、std[0.229, 0.224, 0.225]这是必须的因为预训练权重是在这个分布下训出来的你不归一化等于让模型在一个它没见过的输入分布上工作。我踩过的一个坑是验证集也加了增强。这个错误很隐蔽因为代码跑起来不报错但验证指标会剧烈抖动。记住验证集和测试集只做Resize加CenterCrop加归一化其他一律不做。3. 模型选型与训练流程实现数据和路线定了接下来是模型本体。这一章给的是可以直接抄的配置和代码。3.1 骨干网络怎么选我在同一个数据集上对比过几个常见骨干条件是输入224×224、batch 64、训30个epoch。骨干参数量验证集Top-1单epoch耗时结论ResNet1811.7M86.2%42s快但细粒度上明显吃力ResNet5025.6M91.4%78s性价比最高首选EfficientNet-B05.3M89.8%51s参数量小适合端侧ConvNeXt-Tiny28.6M92.1%96s略好但慢不划算结论很清楚ResNet50是默认答案。如果部署端有算力限制退到EfficientNet-B0如果想再榨一点精度且不在乎速度ConvNeXt-Tiny可以试但提升幅度和耗时不成正比。选ResNet50还有一个隐性好处社区里针对它的调优经验最多遇到问题好查。用冷门骨干出了问题可能连个能问的人都没有。3.2 分类头的改造原版ResNet50最后一层是1000维的全连接我们要换成自己的类别数。这里有个细节很多人忽略分类头不要只加一层Linear。我的做法是Dropout(0.3) - Linear(2048, 512) - BatchNorm1d(512) - ReLU - Dropout(0.2) - Linear(512, num_classes)。中间加一层512维的瓶颈配合两层Dropout在小数据集上能明显压住过拟合。我实测这个改动带来大概1.5个点的验证提升代价是推理时多了不到1毫秒。BatchNorm1d放在Linear之后是为了稳定中间特征的分布尤其在batch size偏小比如16的时候作用明显。如果你的batch能上到64这个BN的收益会小一些但不亏。3.3 损失函数与优化器配置损失函数用带标签平滑的交叉熵label_smoothing0.1。标签平滑的作用是防止模型对训练标签过度自信在细粒度任务上通常能带来0.5到1个点的提升。原理不复杂把one-hot的1改成0.9、其他类各分0.1/(C-1)模型就不会拼命把logit推到极限泛化性更好。如果类别分布特别不均衡再加一个类别权重。权重按1/类别频率算完再归一化到均值为1用torch.FloatTensor传进CrossEntropyLoss的weight参数。注意别直接用原始频率的倒数数值范围会拉得太大训练不稳定。优化器用AdamW而不是Adamweight_decay0.05。AdamW把权重衰减和梯度更新解耦了正则效果更干净。学习率分两阶段阶段一冻结骨干只训分类头lr1e-3训5个epoch。阶段二解冻layer3和layer4精调lr1e-4余弦退火到1e-6训25个epoch。如果要按batch size缩放学习率用线性规则new_lr base_lr * new_bs / base_bs。我给的1e-4是基于batch 64的你如果降到32就用5e-5。3.4 训练循环的核心代码下面是训练循环的骨架我把关键注释写进去了可以直接改改就用。import torch import torch.nn as nn from torch.optim.lr_scheduler import CosineAnnealingLR from torchvision.models import resnet50, ResNet50_Weights device torch.device(cuda if torch.cuda.is_available() else cpu) # 1. 构建模型并替换分类头 model resnet50(weightsResNet50_Weights.IMAGENET1K_V2) in_features model.fc.in_features model.fc nn.Sequential( nn.Dropout(0.3), nn.Linear(in_features, 512), nn.BatchNorm1d(512), nn.ReLU(inplaceTrue), nn.Dropout(0.2), nn.Linear(512, NUM_CLASSES) ) model model.to(device) # 2. 阶段一冻结骨干 for name, param in model.named_parameters(): if not name.startswith(fc.): param.requires_grad False criterion nn.CrossEntropyLoss(label_smoothing0.1) optimizer torch.optim.AdamW( filter(lambda p: p.requires_grad, model.parameters()), lr1e-3, weight_decay0.05 ) # 3. 阶段二切换解冻最后两个stage def unfreeze_layers(model): for name, param in model.named_parameters(): if name.startswith((layer3, layer4, fc.)): param.requires_grad True return torch.optim.AdamW( filter(lambda p: p.requires_grad, model.parameters()), lr1e-4, weight_decay0.05 ) # 4. 训练主体 best_acc, patience_counter 0.0, 0 for epoch in range(TOTAL_EPOCHS): if epoch 5: optimizer unfreeze_layers(model) scheduler CosineAnnealingLR(optimizer, T_maxTOTAL_EPOCHS - 5, eta_min1e-6) model.train() for images, labels in train_loader: images, labels images.to(device), labels.to(device) optimizer.zero_grad(set_to_noneTrue) loss criterion(model(images), labels) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() if epoch 5: scheduler.step() # 验证 model.eval() correct, total 0, 0 with torch.no_grad(): for images, labels in val_loader: images, labels images.to(device), labels.to(device) preds model(images).argmax(dim1) correct (preds labels).sum().item() total labels.size(0) acc correct / total # 早停 if acc best_acc: best_acc, patience_counter acc, 0 torch.save(model.state_dict(), best_shoe_model.pth) else: patience_counter 1 if patience_counter 6: break几个代码里的小心思值得说一下。optimizer.zero_grad(set_to_noneTrue)比默认的zero_grad()省一点显存因为它把梯度置为None而不是填0新版PyTorch推荐这么写。clip_grad_norm_设5.0是保险丝防止某个batch的异常样本把梯度炸飞——我在真实数据上确实遇到过一张全黑的图导致loss突然飙到几十加了梯度裁剪之后就稳了。3.5 学习率调度与早停的配合余弦退火配合早停逻辑上有点冲突余弦退火假设你能跑完整个epoch预算早停又可能提前结束。我的处理是早停的patience给宽一点6到8个epoch因为余弦退火在中段会有一次明显的学习率下降下降前后精度常有小幅波动patience太短会误杀。另外一个技巧是保存最优权重而不是最后权重。上面代码里torch.save放在精度提升的分支里这样即使后面过拟合了你手上的还是最好的那个。这个习惯一定要养成我见过太多人训了30个epoch最后拿最后一代去评估白白丢掉两三个点。4. 评估、调优与常见问题排查训练跑起来只是开始真正决定成败的是评估和调优这一段。4.1 评估指标不能只看准确率准确率在类别均衡时好用在长尾分布下会骗人。假设100个类别头部10类占了80%的样本模型只要把这10类全猜对、其他全猜错准确率也能到80%但尾部类别全军覆没。我建议至少看四个指标Top-1准确率、Top-3准确率、宏平均F1、每类召回率。Top-3在细粒度任务上很有意义因为很多错误是把A款认成A的近似款业务上如果允许人工复核Top-3的候选集能大幅降低复核成本。宏平均F1对每个类别一视同仁能暴露尾部类别的问题。计算这些指标不用自己写sklearn.metrics.classification_report一次给全输出的表格直接贴进周报都没问题。4.2 混淆矩阵怎么读才有用混淆矩阵不是画出来好看是为了找系统性错误。我的读法是先看对角线再看非对角线上数值最大的那几个格子。如果发现A款和B款互相误判特别多八成是两个原因要么这两款本身就长得像那就考虑合并类别或者上度量学习要么标注本身有问题回去抽查这批图。我在一个项目里就遇到过两款鞋在混淆矩阵上几乎对称地互错最后查出来是标注手册里对这两款的界定有歧义标注员各标了一半。还有一个技巧把混淆矩阵按类别频率排序后再看头部类别的混淆通常集中在几个特定对手上尾部类别的混淆则比较分散。这两种模式对应的解法不一样前者做针对性数据补充后者可能需要考虑重采样或代价敏感学习。4.3 常见问题速查表下面这张表是我这几年攒下来的基本覆盖了八成的翻车场景。现象最可能的原因排查动作解决方向训练loss降验证loss升过拟合看训练/验证曲线分叉点加增强、加Dropout、减参数量、早停训练loss就不降学习率过大或过小打印前几个batch的loss试1e-2到1e-5的对数扫描loss变NaN梯度爆炸或学习率过大检查是否有异常输入梯度裁剪、降学习率、检查数据归一化验证准确率剧烈抖动验证集太小或加了增强检查val transform去掉验证集增强、扩大验证集训练很快到99%但线上很差数据泄漏检查是否按ID分组划分重新按商品ID分组某些类别召回率极低长尾分布看每类样本数和召回率类别权重、过采样、focal lossGPU利用率长期低于50%数据加载是瓶颈看DataLoader的num_workers提高worker数、开pin_memory这张表里我最想强调的是数据泄漏那一行。它的表现太有迷惑性了——训练集和验证集指标都漂亮你以为成了上线打脸。判断方法很简单如果验证准确率比你的经验预期高出5个点以上先怀疑泄漏别急着庆祝。4.4 过拟合和欠拟合的分线判断看曲线是基本功。训练loss和验证loss都在降但验证降得慢是正常训练降验证平是轻度过拟合加增强能救训练降验证升是明确过拟合得动结构或者减容量两个都不降那是欠拟合或者学习率有问题别加正则了先把学习率调对。还有一个常被忽略的指标是训练集准确率。如果你的训练集准确率都只有70%那模型根本没学到东西这时候谈泛化毫无意义。我见过有人一上来就调weight_decay结果训练集都拟合不了方向完全反了。5. 模型导出与推理部署训练完的模型躺在pth文件里没用得让它跑起来。5.1 权重保存的两种方式state_dict和整个模型对象我强烈推荐前者。存整个模型对象依赖具体的类定义换个代码结构就加载不了存state_dict只存参数加载时先实例化结构再load_state_dict解耦干净。保存时除了权重最好把类别映射表一起存下来。很多人训完模型类别到索引的映射是靠ImageFolder的文件夹排序隐式决定的换个环境顺序可能变预测结果全乱。我的做法是单独存一个class_to_idx.json推理时显式加载不依赖任何隐式约定。import json, torch # 保存 torch.save(model.state_dict(), shoe_model.pth) with open(class_to_idx.json, w, encodingutf-8) as f: json.dump(train_dataset.class_to_idx, f, ensure_asciiFalse, indent2) # 加载 model build_model(num_classeslen(class_to_idx)) model.load_state_dict(torch.load(shoe_model.pth, map_locationcpu)) model.eval()map_locationcpu这个参数别省不然在有GPU的机器上保存、在没GPU的机器上加载会直接报错。5.2 导出ONNX做推理加速如果部署在服务端导出ONNX再用ONNX Runtime推理通常比原生PyTorch快20%到40%具体取决于模型和硬件。导出代码不长但坑不少。import torch.onnx dummy_input torch.randn(1, 3, 224, 224).to(device) torch.onnx.export( model, dummy_input, shoe_model.onnx, input_names[input], output_names[logits], dynamic_axes{input: {0: batch_size}, logits: {0: batch_size}}, opset_version17 )dynamic_axes是关键不设的话导出的模型batch维度是写死的1批量推理就废了。opset_version建议17以上对BatchNorm1d和Dropout的支持更完整。导出后一定要做数值对齐验证同样的输入分别喂给PyTorch和ONNX Runtime比较输出的最大绝对误差正常应该在1e-4以内。如果误差大多半是某个算子导出有问题得回查。5.3 推理服务的接口设计服务端我一般用FastAPI包一层接口设计上有一个细节值得说预处理必须和训练时完全一致。很多人训练用RandomResizedCrop推理用Resize(256) CenterCrop(224)这两个的裁剪逻辑不一样会导致输入分布偏移精度掉几个点是常事。正确的做法是把推理用的transform单独定义一份并且做单元测试拿一张训练集里的图分别走训练transform的eval模式和推理transform比较输出张量的差异应该完全一致RandomResizedCrop在eval模式下退化为中心裁剪这点要确认。接口返回除了top-1类别我还建议返回top-3加置信度。业务上如果top-1置信度低于阈值比如0.6就把top-3推给人工这样能把错误率压得很低同时人工复核量也可控。这个设计比单纯追求模型精度实在得多。6. 我在这个项目里踩过的几个坑最后说几个不太适合放进教程、但确实影响很大的经验。第一个是不要迷信大模型。我一开始想上ConvNeXt-Base参数量快90M训了两天验证准确率只比ResNet50高0.3个点但推理耗时翻了四倍。项目上线时算力成本是硬约束0.3个点换四倍成本任何做工程的都不会同意。选模型的准则是够用就好先跑通ResNet50确认整条链路没问题再考虑要不要换。第二个是标注质量比数据量重要。我曾经为了凑数据量把一批外包标注的图直接混进训练集结果验证准确率卡在85%上不去。后来抽了200张人工复核发现错标率大概8%重新清洗之后同样的模型直接到90%。这5个点的差距靠调参是调不出来的。第三个是增强不是越多越好。我有一版配置加了随机旋转±30度、随机透视变换、随机灰度化心想增强越强泛化越好结果验证准确率反而掉了2个点。原因是这些增强超出了真实数据的分布——真实拍摄里不会有30度倾斜的鞋也不会有纯灰度的商品图。增强的目的是模拟真实变化不是制造不可能样本。第四个是早停的patience要结合学习率调度来定。前面提过但值得再强调一次。余弦退火在训练后段学习率很小精度提升本来就慢patience设3的话很容易在快要提升的时候被掐断。我的经验是patience至少等于余弦周期长度的四分之一。第五个是一定要留一个完全没碰过的测试集。这个测试集在你调完所有超参之前不能看一眼。我见过太多人反复在测试集上试不同配置最后报出来的数字严重乐观。测试集只用一次用完就封存这是纪律。这套流程我在几个模拟项目上跑过ResNet50配合上面这套配置8类粗分类的验证准确率稳定在92%左右20类细分的在85%左右端到端从数据到上线大概两周。当然具体数字和你的数据质量强相关数据干净的话还能再高数据脏的话先把清洗做扎实别急着调模型。

PyTorch运动鞋细粒度图像分类实战：从数据到ONNX部署

相关推荐

商务大数据建模实战：从数据清洗到决策优化

x86-64汇编栈帧原理与ABI规范实践

JMeter测试数据写入本地文件的四种方法与优化技巧

更多资讯

YOLO抽烟行为检测数据集与模型训练实战

AI欺骗行为解析：非验证性任务中的模型策略与应对

宝塔面板Shell脚本实现日志文件自动清理方案

无味的杂谈（26.3-26.10/25）

Java蓝牙Demo实战：扫描连接收发与重连避坑指南

RLDP快速链路检测协议：原理、部署与排错实战指南

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？