PyTorch原型网络小样本分类：episodic训练与评估

简介面向小样本学习研究与入门实践的 PyTorch 原型网络实现对应论文 Prototypical Networks 的核心思路适合已具备一定深度学习基础、希望复现少样本分类实验的开发者与高校学习者。压缩包共 12 个文件约 135KB以 7 个 Python 源码文件为主体辅以 2 张示意图、README 说明、LICENSE 与 .gitignore体量轻巧但保留了模型定义、损失计算、批采样、Omniglot 数据加载和训练入口等关键模块。已有 920 人学习下载。读者可据此理解原型网络如何通过类原型完成度量分类并沿训练脚本与数据管线复现实验结合文档和图示梳理目录结构与运行逻辑也便于在此基础上替换数据集、调整采样策略或开展课程项目与论文复现对理解度量学习在少样本场景中的优势与局限也有直接帮助尤其适合复现论文基线、课堂演示及二次开发。1. 每个类别只有五张图这套 PyTorch 原型网络实现能解决什么接一个商品图分类的活新类别只有四五张标注图从零训一个 CNN 基本没戏。这就是典型的 few-shot 场景而我手上这份用 PyTorch 写的 Prototypical Networks 实现正好冲着它来Python 代码量不大主干就那么几个文件却把 N-way K-shot 的 episodic 训练、原型计算和评估流程完整跑通了。这篇不推导公式只讲这套代码怎么跑起来、每个模块在干什么、以及你想换编码器或换数据集时该动哪几行。适合两类人一类是模型还没跑通、想先把 baseline 拉起来的新手另一类是已经有自己的 backbone想找个干净的小样本训练框架往里塞的熟手。2. 工程骨架拆解从目录结构到一个 episode 的完整数据流这份实现最值得先看的地方不是模型而是它把「小样本」这件事拆成了数据层的问题。普通分类任务里DataLoader 一个 batch 就是「随机若干张图 对应标签」类别集合在整个训练过程中固定不变而 episodic 训练里每个 batch 自己就是一个小任务类别是从全集里现抽的抽完还要在 support 和 query 之间切分。这个差异决定了你没法直接套torch.utils.data.DataLoader的默认行为得自己在 dataset 之上再盖一层采样器。2.1 目录结构与模块职责先看整体骨架。这类项目的目录组织基本是固定的我看过的几个实现都大同小异project/ ├── data/ │ ├── raw/ # 原始图片按类名分文件夹 │ └── splits/ # train/val/test 的类别划分 json ├── models/ │ └── convnet.py # 编码器输出 embedding ├── experiments/ # 每个实验一份配置 │ └── exp_20way_1shot.json ├── train.py # 训练入口 ├── test.py # 评估入口加载权重跑 episode ├── io_utils.py # 读目录、读 splits、拼图片路径 ├── utils.py # episode 采样、损失、评估指标 └── config.py # 参数解析文件职责你多久会改一次models/convnet.py定义编码器把 (B, C, H, W) 压成 (B, D)换 backbone 时改utils.pyepisode 采样、原型计算、准确率与置信区间换距离度量时改io_utils.py扫描类别目录、生成类别索引、加载 splits接新数据集时改train.py训练循环、日志、保存权重加正则、加调度器时改test.py固定权重下重复采样评估基本不动这个划分的好处是把「会变的东西」集中了。数据格式变只碰io_utils.py模型结构变只碰models/训练策略变只碰train.py。我第一次读的时候觉得文件太碎后来加了第三个数据集才发现碎是对的——所有和数据集相关的脏活都压在io_utils.py里训练脚本一行不用动。还有一个容易忽略的点experiments/下的配置文件。它在这套代码里不是装饰训练和测试都从同一份配置里读n_way、k_shot、q_query。这三个值如果训练和测试不一致评估出来的数字毫无意义而配置文件是唯一能保证两边对齐的地方。我一般会在配置里再加一个seed字段方便复现。2.2 episode 采样器一个 batch 到底长什么样这是整份代码里最核心的三十行。episodic 训练的精髓就在这儿每抽一次就是造一个新的 N 分类任务。import random import torch def sample_episode(class_to_indices, n_way, k_shot, q_query, rngrandom): 从全部类别里抽一个 episode。 class_to_indices: dict, {类名: [该类所有样本索引]} 返回 support_idx, query_idx 两个列表以及各自的标签 # 1. 先抽类别类别不重复 classes rng.sample(sorted(class_to_indices.keys()), n_way) support_idx, query_idx [], [] support_y, query_y [], [] for label, cname in enumerate(classes): pool class_to_indices[cname] # 2. 关键k_shot q_query 一次抽完天然避免 support/query 重叠 picked rng.sample(pool, k_shot q_query) support_idx picked[:k_shot] query_idx picked[k_shot:] support_y [label] * k_shot query_y [label] * q_query return support_idx, support_y, query_idx, query_y几个参数必须说清楚n_way每个 episode 的类别数。它同时决定了两件事——分类头的宽度原型数量以及任务难度。训练时用 20-way、测试时用 5-way 是常见做法因为训练任务更难模型学到的 embedding 更判别性。k_shot每类 support 样本数也就是算原型时参与平均的样本数。1-shot 时原型就是一个点方差极大这是 1-shot 任务本身的上限不是代码 bug。q_query每类 query 数决定 loss 里有多少个样本参与平均。太小梯度噪声大太大显存吃紧。最容易踩的坑是k_shot q_query超过每类实际样本数。手写字符那类数据集每类正好 20 张图你配个 20-way 5-shot 15-query 刚刚好改成 5-shot 20-query 就直接抛ValueError: Sample larger than population。注意rng是作为参数注入的不是直接调random.sample。这样训练和评估可以用不同的随机源也方便在调试时固定种子重放同一个 episode。我调试 sampler 的时候就是靠这个固定 seed 反复抽肉眼检查 support 和 query 有没有串。如果换成一个torch.utils.data.Dataset版本这段逻辑会变成用一个Subset包住原 dataset再把Subset喂给DataLoader。两种写法都行直接用索引列表反而更直观因为小样本场景下一个 episode 的样本量本来就不大20-way 5-shot 15-query 也就 400 张不需要多进程预取。2.3 技术选型为什么是 PyTorch为什么是平方欧氏距离选 PyTorch 没什么可纠结的但小样本场景下一个额外好处值得说episodic 训练里每个 batch 的形状是动态的、类别是随机的调试时你经常要停下来看「这个 episode 抽了哪几个类、原型算对没有」。动态图和逐行 pdb 在这里的体验比静态图好太多support_emb[support_y c].mean(0)这种写法你可以直接打断点看中间张量。距离度量的选择更值得聊。原型网络用的是平方欧氏距离d ||f(x) - c_k||^2然后对-d做 softmax。为什么是平方欧氏而不是余弦因为这背后有一个很干净的概率解释如果假设 embedding 在每一维上的分布是同方差的、且各类先验相同那么属于某类的后验就正比于exp(-d)的形式平方欧氏距离正好和这个假设对齐。余弦相似度丢掉了模长信息在归一化特征上等价于欧氏距离但你得自己乘一个温度系数才训得动。和迁移学习、微调比episodic 训练的优势在于「训练目标和测试目标一致」。你在训练时就让模型反复面对「给你 5 张图认出另外 15 张」的任务测试时自然不会有分布落差。代价是收敛慢同样量级的图片常规分类训几十个 epoch 就收敛episodic 往往要跑上万到几万个 episode。这也是后面第 4 章那个--num-episodes参数为什么动辄两三万的原因。3. 核心代码精读编码器、原型计算与 episodic 训练循环骨架理清了接着看真正承载算法的那几段。这部分代码量不大但每一行都和论文里的公式对得上看懂了就能自己改。3.1 编码器Conv4 风格 backbone 的取舍这份实现默认用的是一个四层卷积的小 backbone业内常叫 Conv4。它的结构很朴素每一层都是「卷积 → BN → ReLU → 池化」import torch.nn as nn class ConvEncoder(nn.Module): def __init__(self, in_ch1, hid64, out_dim64): super().__init__() def block(i, o): return nn.Sequential( nn.Conv2d(i, o, kernel_size3, padding1), nn.BatchNorm2d(o), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), ) self.features nn.Sequential( block(in_ch, hid), # 84 - 42 block(hid, hid), # 42 - 21 block(hid, hid), # 21 - 10 block(hid, out_dim), # 10 - 5 ) self.out_dim out_dim def forward(self, x): return self.features(x).flatten(1) # (B, out_dim*5*5)参数含义in_ch是输入通道数灰度图是 1RGB 是 3hid是中间通道数64 是通用配置out_dim是最后一层通道数。注意flatten(1)之后实际维度是out_dim * 5 * 5不是out_dim——输入 84×84 经过四次池化正好变成 5×5。这个细节很多人第一次看会忽略然后在写下游分类头时维度对不上。这里有个典型取舍Conv4 够浅20-way 5-shot 一个 episode 才 400 张 84×84 的图显存压力很小单卡就能跑但它表达能力有限在稍微复杂一点的自然图像上就顶不住了。我一般的做法是先用 Conv4 把整条流水线跑通、确认采样和评估逻辑没问题再把 backbone 换成更深的残差网络。如果顺序反过来你会同时面对「模型不收敛」和「我的评估代码写错了没有」两个问题排查起来就是黑匣子。in_ch这个参数容易翻车。手写字符是灰度图默认 1 通道能跑换成彩色图忘了改第一个卷积就会因为通道不匹配报错而报错信息指向的是Conv2d的输入维度不太直观。我习惯在io_utils.py里读出第一张图就打印一次shape肉眼确认通道数。3.2 原型计算与前向从 (N*K, D) 到 (N, D)原型就是每类 support 样本 embedding 的均值。这一段是整个算法的核心也是最短的一段import torch import torch.nn.functional as F def compute_prototypes(support_emb, support_y, n_way): # support_emb: (N*K, D), support_y: (N*K,) 取值 0..N-1 # 返回 (N, D) return torch.stack([ support_emb[support_y c].mean(dim0) for c in range(n_way) ]) def prototypical_logits(support_emb, support_y, query_emb, n_way): prototypes compute_prototypes(support_emb, support_y, n_way) # cdist 给的是欧氏距离平方之后才是论文里的 d d torch.cdist(query_emb, prototypes) ** 2 # (N*Q, N) return -d # 距离越小logit 越大这段代码里有两个细节值得抠第一** 2不能省。torch.cdist算的是开方后的欧氏距离直接对开方值做 softmax 和论文里的平方距离不是一回事。虽然单调性一致、argmax 结果相同但 softmax 的梯度分布会变——平方距离对大间距的惩罚更重模型收敛更快。我试过省掉这个平方训到同样的 episode 数准确率会差一截而且 loss 曲线更抖。第二维度顺序。query_emb是(N*Q, D)prototypes是(N, D)cdist出来的矩阵是(N*Q, N)——每一行是一个 query 样本对 N 个原型的距离正好对应分类头的 logits。这个形状对上了后面接交叉熵就是水到渠成的事。如果数据量再大一点torch.stack([... for c in range(n_way)])这种 Python 循环会有点慢因为每个类都要做一次布尔索引。常见做法是改用scatter_add或者先把 support 按 label 排序再view(n_way, k_shot, D).mean(1)。后者最快前提是你的 sampler 输出的顺序本来就是按类聚好的——第 2 章那个sample_episode恰好就是这么吐数据的直接view即可省掉循环。3.3 损失与训练循环log_softmax(-d) 和它的数值细节有了 logits损失就是标准的负对数似然def prototypical_loss(support_emb, support_y, query_emb, query_y, n_way): logits prototypical_logits(support_emb, support_y, query_emb, n_way) log_p F.log_softmax(logits, dim1) loss -log_p[torch.arange(query_emb.size(0)), query_y].mean() pred logits.argmax(dim1) acc (pred query_y).float().mean() return loss, acc, log_p用log_softmax而不是先softmax再log是为了数值稳定性。距离平方之后数值可能到几千softmax会直接溢出成inf和nan。这是个很经典的翻车点尤其在你把n_way调大、或者 embedding 没做归一化的时候。训练循环本身没什么花活但有几个位置必须写对model ConvEncoder(in_ch1).cuda() optimizer torch.optim.Adam(model.parameters(), lr1e-3) for ep in range(args.num_episodes): model.train() s_idx, s_y, q_idx, q_y sample_episode( class_to_indices, args.n_way, args.k_shot, args.q_query) s_x load_images(s_idx).cuda() # (N*K, C, H, W) q_x load_images(q_idx).cuda() s_y torch.tensor(s_y).cuda() q_y torch.tensor(q_y).cuda() s_emb model(s_x) q_emb model(q_x) loss, acc, _ prototypical_loss(s_emb, s_y, q_emb, q_y, args.n_way) optimizer.zero_grad() loss.backward() optimizer.step() if ep % args.log_interval 0: print(fep {ep} loss {loss.item():.4f} acc {acc.item():.4f})这里是「按 episode 更新」而不是「按 epoch 更新」因为压根没有 epoch 的概念——数据是无限采样的。args.num_episodes就是总共更新多少次参数动辄两三万。学习率的量级我一般从 1e-3 起步配 Adam。如果 loss 在前几百个 episode 就掉到接近 0、但验证准确率不涨八成是过拟合到了训练类别上这时候降n_way或者加权重衰减比调学习率有用。反过来如果 loss 一直横在ln(n_way)附近不动20-way 就是 3.0 左右说明模型根本没学到东西先检查图片归一化和标签有没有错位。3.4 评估600 个 episode 与 95% 置信区间小样本评估最忌讳「跑一个 episode 报一个数」。因为 episode 是随机采的单次结果方差极大20-way 5-shot 的随机基线就有 5%你不跑几百次根本分不清模型是真的学到了还是在瞎猜。def evaluate(model, class_to_indices, n_way, k_shot, q_query, n_episodes600): model.eval() accs [] with torch.no_grad(): for _ in range(n_episodes): s_idx, s_y, q_idx, q_y sample_episode( class_to_indices, n_way, k_shot, q_query) s_emb model(load_images(s_idx).cuda()) q_emb model(load_images(q_idx).cuda()) _, acc, _ prototypical_loss( s_emb, torch.tensor(s_y).cuda(), q_emb, torch.tensor(q_y).cuda(), n_way) accs.append(acc.item()) accs torch.tensor(accs) mean accs.mean().item() ci95 1.96 * accs.std().item() / (n_episodes ** 0.5) return mean, ci95三个硬性要求model.eval()必须有否则 BatchNorm 会用当前 episode 的统计量等于偷看了 query 的信息torch.no_grad()必须有不然显存会一路涨n_episodes至少 600这是这类工作里约定俗成的量级600 次采样下 95% 置信区间的半宽大概在 1% 上下足够比较两个模型了。ci95这个数很多人不报但它很能说明问题。如果你的模型准确率 48%、置信区间 ±1.2%隔壁方案 50%、±3.5%那大概率两者没有显著差异。反过来如果区间半宽超过 2%说明你的评估还不稳定先把 episode 数加够再说结论。另外evaluate里用的是model.eval()但没做数据增强这是对的——评估阶段的 support 和 query 必须同分布一旦对 support 做了随机裁剪原型就会被污染。我见过在评估时开增强导致准确率掉了七八个点的查了半天以为是模型问题。4. 跑通流程环境、数据目录与训练/评估命令的完整参数表到这儿算法部分就齐了接下来是让人真正能跑起来的那部分。这套代码对环境要求不苛刻但有几个地方不配好就是跑不动。4.1 环境与依赖三个必须确认的点# 建议单独建虚拟环境避免和系统里的 torch 打架 python -m venv venv source venv/bin/activate pip install torch torchvision pip install numpy pillow tqdm三个必须确认的点第一CUDA 和 torch 版本要匹配。用python -c import torch; print(torch.cuda.is_available())验证一下输出False的话训练会退到 CPU几万个 episode 能跑到天亮。第二Pillow读灰度图要显式指定模式。Image.open(p).convert(L)不写convert有的 PNG 会带 alpha 通道变成 4 通道第一个卷积层直接报通道不匹配。第三图片尺寸。Conv4 里写死了四次池化和5*5的展平维度这是按 84×84 输入算出来的。如果你的图是 28×28两次池化就到底了得改网络结构。常见做法是在 dataset 里统一Resize((84, 84))把这个问题挡在数据层。4.2 数据目录与 splits 文件标签从哪来数据组织方式是「一个类一个文件夹」这是图像分类最通用的约定io_utils.py直接扫目录名就能拿到类别名data/ ├── raw/ │ ├── glyph_001/ │ │ ├── img_0001.png │ │ └── ... 每类 20 张 │ ├── glyph_002/ │ └── ... └── splits/ ├── train.json ├── val.json └── test.json关键在 splits。小样本的类别划分是「按类别切」不是「按样本切」——训练时见过的类测试时一个都不能出现否则就是数据泄漏。splits 文件里存的就是类名列表{ train: [glyph_001, glyph_002, glyph_003], val: [glyph_800, glyph_801], test: [glyph_1200, glyph_1201] }加载时常见的做法是先在io_utils.py里做一次全量扫描把{类名: [图片绝对路径...]}建成字典再按 splits 过滤出三个子集。这一步有点慢几万个文件 stat 一遍我一般会把结果 pickle 缓存下来第二次启动直接读缓存加个--rebuild-cache参数控制什么时候重扫。类别数分配上train 要占大头比如 60%val 和 test 各留 20% 左右。val 的作用是选超参和早停test 只在最后跑一次。这条纪律很多人不守反复在 test 上调参最后报出来的数字就没什么参考价值了。4.3 训练命令与参数表python train.py \ --dataset-root ./data/raw \ --splits ./data/splits/train.json \ --n-way 20 --k-shot 5 --q-query 15 \ --num-episodes 20000 \ --lr 1e-3 \ --log-interval 100 \ --val-interval 1000 \ --val-episodes 200 \ --save-path ./out/conv4_20way5shot.pt参数逐个说明参数含义常用取值调它的影响--n-wayepisode 类别数训练 20测试 5越大任务越难embedding 越判别--k-shot每类 support 数1 或 51-shot 方差大天花板低--q-query每类 query 数5 到 15影响梯度噪声和显存--num-episodes总更新步数20000 起少了欠拟合多了过拟合--lr学习率1e-3Adam大了 loss 抖小了不收敛--val-interval每多少 episode 验一次1000太频繁拖慢训练--val-episodes验证时采样多少次200训练期够用最终评估要 600注意k_shot q_query必须小于等于每类样本数。上面配的 51520正好卡在手写字符那种每类 20 张的数据集上限再大就会在采样时抛异常。如果每类图多一点把q_query加到 15 以上能明显降低 loss 的抖动。--val-interval和--val-episodes是为训练过程服务的验证只用来判断「还要不要继续训」所以 200 次采样就够不用上 600。真正的最终数字在test.py里跑。4.4 测试与断点续跑python test.py \ --model-path ./out/conv4_20way5shot.pt \ --dataset-root ./data/raw \ --splits ./data/splits/test.json \ --n-way 5 --k-shot 5 --q-query 15 \ --num-episodes 600测试用 5-way 而训练用 20-way这是这套流程的标准姿势训练时任务更难逼模型学出更细的判别边界测试时任务简单看它在常规设定下的表现。如果你两边都用 5-way训出来的 embedding 会明显更松。断点续跑这块代码里如果没有现成实现加起也很简单把model.state_dict()、optimizer.state_dict()和当前 episode 数一起存成一个 dict训练启动时判断有没有 checkpoint 就加载。我一般每 2000 个 episode 存一次同时保留最近三个防止存盘时进程被杀导致文件损坏。5. 避坑清单episode 采样、BatchNorm 和评估阶段的五个高频翻车点这一章是我自己踩过、也帮别人看过的问题。小样本这套流程的坑集中在一处训练和评估的「任务构造方式」必须严格一致任何一处不一致你看到的数字都是假的。5.1 验证准确率永远在 20% 附近模型像在瞎猜现象训了两万个 episode训练 loss 从 3.0 掉到 0.3验证准确率一直卡在 18%22%5-way 的随机基线是 20%。原因最常见的是标签错位。sample_episode里label是按enumerate(classes)生成的也就是 0..N-1 的局部编号但load_images读图时如果顺手从路径里解析了全局类别名转成整数两边就对不上了。模型在学一个和 query 标签无关的映射。解决在训练循环里加一次断言打印第一个 episode 的s_y和q_y取值范围必须是[0, n_way-1]。另外可以做一个 sanity check把 query 的标签换成 support 的标签准确率应该显著高于随机——如果还是 20%那一定是数据管线的问题不是模型的问题。5.2 换成彩色数据集后第一个卷积就报维度错现象RuntimeError: Given groups1, weight of size [64, 1, 3, 3], expected input[400, 3, 84, 84] to have 1 channels。原因ConvEncoder(in_ch1)是写死的或者从配置里读但配置没改。灰度手写字符是单通道换成自然图像就是三通道。解决把in_ch提到配置文件里和数据集绑定。更稳的做法是在io_utils.py里读出第一张图后自动推断通道数写进 dataset 的元信息训练脚本从元信息里取。我现在的习惯是先跑一个--dry-run只加载一个 batch 打印形状形状对了再开训。5.3 训练准确率很高测试时掉一大截现象训练期验证 65%test.py跑出来 52%。原因三个可能。一是 BatchNorm 在评估时没切eval()模式用当前 episode 的统计量做了归一化而当前 episode 里混着 query等于泄漏。二是 train/test 的 splits 有类别重叠测试集里出现了训练时见过的类。三是训练时的图片归一化用了整个数据集的均值方差评估时用了另一个值。解决model.eval()和torch.no_grad()一起检查用脚本 diff 一下 train.json 和 test.json 的类名集合交集必须为空归一化的均值方差写死在配置里训练评估共用一份常量别在两边各算一次。5.4 跑着跑着显存炸了而且越跑越慢现象前几百个 episode 正常之后显存缓慢上涨最后 OOM。原因评估函数里忘了torch.no_grad()每个验证 episode 的计算图都挂在内存里或者把loss、acc这些 tensor 直接 append 进了 list而不是.item()。解决评估统一包在with torch.no_grad():里所有要记进 list 的标量都.item()转成 Python float如果确实需要保留 tensor用detach()。这个坑我在别的项目里也踩过一旦养成.item()的习惯就再也不会犯。5.5 报错Sample larger than population现象ValueError: Sample larger than population or is negative训练刚启动就挂。原因k_shot q_query超过了每类实际样本数。20 张图每类配 5-shot 15-query 是 20 张刚好但如果某一类只有 19 张数据集里少了一张抽到它就挂。解决加载数据时统计每类样本数取最小值打印出来参数配置不超过这个数。更稳妥的做法是在 sampler 里对样本数不足的类做过滤或者干脆在io_utils.py里把样本数不达标的类整类剔除——小样本场景下少几个类影响不大但训练中途崩掉很伤。6. 二次开发编码器替换、距离度量改造与新数据集接入要改这套代码我建议按「风险从低到高」的顺序来先接数据集再换 backbone最后动度量。因为前两步出错时错误信息很明确第三步出错时你只能看到一个不涨的准确率。换编码器是最常见的需求。把ConvEncoder换成一个残差网络注意三点输入分辨率要提到 84×84 或更高因为残差网络的第一个卷积通常带 stride 2最后的全局池化用AdaptiveAvgPool2d(1)替代flatten(1)这样不用手算展平维度BN 的momentum调小一点0.1 以下因为每个 episode 只有几百张图统计量本身噪声就大。class ResEncoder(nn.Module): def __init__(self, in_ch3, out_dim640): super().__init__() self.backbone torchvision.models.resnet12(pretrainedFalse) # 换成你的实现 self.backbone.fc nn.Identity() self.out_dim out_dim def forward(self, x): return self.backbone(x)换距离度量改动更小就在prototypical_logits里。余弦距离的写法是先归一化再乘温度def cosine_logits(support_emb, support_y, query_emb, n_way, scale10.0): prototypes compute_prototypes(support_emb, support_y, n_way) s F.normalize(query_emb, dim1) F.normalize(prototypes, dim1).t() return scale * s # scale 是温度太小不收敛太大梯度爆scale一般从 10 起调这个值本质上是把余弦相似度映射回 logits 的量级太小等于 softmax 都是平的太大就等于硬标签。改完记得重新调学习率余弦版本通常能接受更大的 lr。接新数据集的活全在io_utils.py写一个扫描函数返回{类名: [路径]}再生成三个 splits json。改完之后我的固定动作是先做一次过拟合测试——只取 5 个类把--num-episodes设成 100跑一遍看训练 loss 能不能打到接近 0。打不到就说明数据管线有问题可能是路径拼错、标签错位、或者图片全是黑的。这个检查只要两分钟但能省掉后面几个小时的瞎猜。改造点改动位置主要风险换 backbonemodels/输入分辨率与展平维度不匹配换距离度量utils.py温度系数没调loss 不降接新数据集io_utils.py类别泄漏、样本数不足加数据增强dataset 类评估阶段误开增强这套流程我从几年前第一次跑通到现在最值钱的一条经验就是那个「5 类 100 episode 过拟合测试」。有一次我接一个自采数据集图片是灰度但部分带了 alpha 通道被读成 4 通道训练照样跑、loss 照样降、准确率就是不动查了一整天才发现问题出在读图那行。从那以后我每次接新数据集都强制先跑一遍过拟合测试loss 不下来就绝对不往下走。希望帮到你。本文还有配套的精品资源点击获取