Keras分类训练后获取验证集y_true与y_preds的三种方案-北京尧图网络

做图像分类训练最烦的事不是调参而是训练结束之后你想画验证集的混淆矩阵、ROC曲线、各类别精确率召回率结果打开代码发现你手里只有fit_generator返回的history里面全是每个epoch的loss和accuracy标量验证集上每一个样本的真实标签y_true和模型预测y_preds一样都没留。这个需求太常见了。只要你在训练结束之后想做细粒度评估就绕不开“从验证集里取出模型预测”这一步。但Keras的fit_generator处理验证集时默认逻辑就是“喂进去、算个平均loss、返回标量”中间任何批次的预测输出都不会暴露给外部。所以很多人只能网上到处搜“怎么在fit_generator里拿y_true和y_preds”收获的还都是零散片段。这篇文章我基于自己做分类任务时的踩坑过程把几种可行的取数思路全部拆开讲清楚为什么验证循环不给你预测结果、验证集顺序怎么保证不乱、训练后predict怎么用最稳妥、每个epoch跟踪预测用什么方式、拿到y_true和y_preds之后如何去算混淆矩阵/AUC/top-k准确率。无论你用的是老的fit_generator还是新版fit直接传生成器思路完全通用。1. 验证循环为什么不把y_preds还给你1.1 验证阶段在内部到底做了什么先弄清楚一件事fit_generator对验证集的处理从设计上看就是一个“评分过程”。它在每个epoch结束后把validation_data的批次逐一取出来做一次前向推理把每个批次的loss累积起来最后除以批次数得到平均验证loss再交给metrics计算标量指标。至于每个样例的softmax输出验证循环算完之后直接丢弃连临时变量都不保留。这和训练过程是一个道理——训练时你也不会拿到每个batch的实时预测概率因为计算图的目的是更新权重并累积损失不是为了给你留预测结果。所以“fit_generator内部拿不到y_preds”不是某个参数没开而是API设计就没打算把这一步还给你。你可以把验证循环理解为把原料送进加工厂最后给你一张“合格率统计表”中间每一批次的具体产出从来不返回。搞清楚这一点之后你就不会再试图在fit_generator的参数里找开关而是老老实实走外部路子。实操里我认为靠谱的只有三条训练结束后对验证集重新做一次model.predict。写一个自定义Callback在训练过程中自己收集每个epoch的预测。从生成器源头把y_true“留底”做一个包装生成器。下文就是这三条路的完整展开。1.2 验证生成器的顺序问题才是真正的拦路虎为什么获取y_true和y_preds最怕的问题不是长度而是顺序如果你用flow_from_directory生成验证集并且设置了shuffleTrue那每个epoch里验证样本的顺序都会被打乱一次。某个epoch结束时模型在验证集第5个位置预测到的样本和你用另一个生成器取到的第5个y_true根本不是同一个样本。就算你把seed固定住洗牌结果确实能复现但你并不知道洗完之后哪个样本去了哪里依然没法对齐。所以在准备“用于事后评估”的验证生成器时有一条铁律shuffle永远设为False。顺序固定成“目录遍历顺序”也就是class_indices按名称排序后每个类下面的文件依次排开。这样无论你从生成器里取几次第i个样本永远是同一个样本。另外ImageDataGenerator里那些数据增强参数在验证生成器上严格来说一个都不要开。我见过有人图省事直接用train_datagen给验证集做rescale顺带开了rotation_range和horizontal_flip。训练时验证集的平均准确率还算正常可一旦你直接对相同生成器做predict拿预测概率去算ROC结果会抖动得很厉害——因为每次预测用的是随机增强后的图像模型对同一样本在不同时刻的预测差异很大评估曲线全被污染。1.3 三条路的核心取舍这三条路不是非此即彼完全可以组合。训练后predict代码最少思路最直白适合只关心最终模型表现的人。缺点是它只给你“最终状态”的预测看不到训练过程中预测分布怎么变化。自定义Callback能拿到每个epoch的y_preds适合做过程诊断。缺点是每个epoch都要对验证集多跑一次推理训练时间会被拉长。生成器闭包缓存适合不想额外predict、想让fit自己消费验证数据、又想把标签留底的人。缺点是它本质上只能给“最后一次遍历”的标签想要epoch对应关系还得额外设计。我个人的建议是先做训练后predict简单可靠有过程分析需求再加Callback。生成器闭包这种偏hacky的方案放到框架把你限制死了再用。2. 最直接的方案训练后predict整个验证生成器2.1 准备一个顺序稳定的val_generator并预取y_true如果你只想要最终模型的验证集评估结果最简单的方法就是训练完之后用model.predict跑一遍验证集。困难点在于怎么确保predict出来的y_preds顺序和你手里的y_true完全一致。我的做法是从一开始就单独构建一个只用于评估的验证生成器import os import numpy as np import tensorflow as tf IMG_SIZE (224, 224) BATCH_SIZE 32 val_datagen tf.keras.preprocessing.image.ImageDataGenerator(rescale1. / 255) # 注意shuffleFalse顺序固定这是后续一切对齐的前提 val_gen_eval val_datagen.flow_from_directory( os.path.join(DATA_DIR, val), target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleFalse, seed42, ) # 一行取出全部真实标签 y_true np.concatenate( [val_gen_eval[i][1] for i in range(len(val_gen_eval))], axis0 ) print(y_true shape:, y_true.shape) print(class mapping:, val_gen_eval.class_indices)这里有两个细节值得说。val_gen_eval[i]访问的是第i个批次返回一个(x_batch, y_batch)的二元组y_batch就是该批次的one-hot标签。len(val_gen_eval)等于样本总数除以batch_size后向上取整最后一个批次样本数不满batch_size也没关系concatenate之后总行数就是验证集样本总数。class_indices就是标签到类名的映射顺序由目录名的字母序决定。模型的输出层如果设置了num_classes它的类别顺序和这个映射是对应的。评估完成后我习惯把这个映射存一份方便后面写报告时把类别索引翻译回真实名字。2.2 训练完之后对齐y_true与y_preds接着正常训练。新版Keras直接model.fit传生成器即可老代码里的fit_generator只是历史API内部逻辑一致model.fit( train_gen, steps_per_epochlen(train_gen), epochs50, validation_dataval_gen_eval, validation_stepslen(val_gen_eval), )训练结束之后直接predicty_preds model.predict(val_gen_eval, verbose1) # 转为类别标签 y_pred_labels np.argmax(y_preds, axis-1) y_true_labels np.argmax(y_true, axis-1) print(y_preds shape:, y_preds.shape) # (N, num_classes) print(y_true shape:, y_true.shape) # (N, num_classes)这里的y_preds是模型最后一层的输出对于分类模型通常就是softmax概率分布。为什么强调这一点如果你在自定义模型里把最后的softmax去掉了输出的是logits那这里的“预测概率”只是理解上的近似计算AUC之前需要自己补一个softmax转换。预测长度和标签长度正常情况下是相等的。如果发现不等优先检查你是不是对同一个生成器先做了fit又做了predict——生成器的内部迭代器状态在fit过程中会被消费predict时会从当前指针位置继续读取导致只预测了后半段样本输出行数远远小于y_true。这个问题很隐蔽我踩过一次。解决方式很简单不要复用同一个生成器对象用两个都shuffleFalse且seed相同的独立实例一个给fit一个给predict。2.3 为什么len(val_gen_eval)和steps要小心处理很多教程会建议predict时写stepslen(val_gen_eval)本质上等于“你走完全部批次”。不传这个参数时Keras内部也会默认走完整个生成器。所以预测阶段不要随手把steps调小比如为了加速只跑一小部分验证集那得到的结果行数就不等于y_true行数了后面的混淆矩阵全是错位。反过来如果你数据集特别大确实想用部分批次做快速验证那一开始就把y_true也截短到同样范围保持“预测多少就取多少标签”的原则。但我不推荐在最终评估阶段这么干子集验证请用专门的子集目录别在跑批时截断。还有一个容易忽略的小坑predict时如果验证集样本数恰好能被batch_size整除一切正常如果不能整除最后一个batch只有少量样本predict依然会把它们输出。个别很老版本的Keras对最后一个不满批次处理不好会出现维度报错这时建议把验证集样本数调整成batch_size的整数倍或者直接升级框架版本。我在现行版本里没有遇到过但网上见过反馈这里提一句预防。3. 想在训练过程中跟踪预测自定义Callback存下每个epoch的y_preds3.1 on_epoch_end里如何安全地predict验证集单次预测只解决最终评估。如果你想知道模型训练到第5个epoch时对难例样本的预测变化或者绘制PR曲线随epoch演变的动态图就需要在每个epoch结束后拿到一次验证集预测值。这时候自定义Callback是最合适的手段。我常用的一种写法是在Callback初始化时就用一个全新的验证生成器把y_true固定住然后在on_epoch_end里predict一次并保存import numpy as np import tensorflow as tf class ValPredsCallback(tf.keras.callbacks.Callback): def __init__(self, val_gen, save_every1): super().__init__() # 在训练开始前取y_true此时的生成器完全干净指针未移动 self.y_true np.concatenate( [val_gen[i][1] for i in range(len(val_gen))], axis0 ) self.preds_history {} self.save_every save_every self.latest_preds None def on_epoch_end(self, epoch, logsNone): if (epoch 1) % self.save_every ! 0: return preds self.model.predict(self.val_gen, verbose0) self.preds_history[epoch] preds self.latest_preds preds然后挂载val_gen_for_cb val_datagen.flow_from_directory( os.path.join(DATA_DIR, val), target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleFalse, seed42, ) val_gen_for_fit val_datagen.flow_from_directory( os.path.join(DATA_DIR, val), target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleFalse, seed42, ) model.fit( train_gen, steps_per_epochlen(train_gen), epochs50, validation_dataval_gen_for_fit, validation_stepslen(val_gen_for_fit), callbacks[ValPredsCallback(val_gen_for_cb, save_every5)], )注意这里我没有把val_gen_for_cb和给fit用的validation_data弄成同一个对象。这是一条重要经验fit和Callback两个地方都会消费验证生成器如果共享一个对象迭代状态会互相干扰。虽然迭代器支持索引和重置但为了彻底避免诡异行为我给它们各自准备了独立实例。两个实例都用同样的shuffleFalse和seed出来的批次顺序严格一致。3.2 把预测结果按epoch落盘如果一个epoch保存一次预测50个epoch就是50份(N, num_classes)的数组内存里可能放着近50倍验证集大小的float数据占的内存不小。所以我通常不把所有epoch的预测全部留在内存里而是在on_epoch_end里直接存npy文件只保留一个“最新预测”用来画曲线import os np.save(fval_preds_epoch_{epoch1:03d}.npy, preds) # 只保留最近一次 self.latest_preds preds这样既不会内存爆炸也能在训练中断时从磁盘恢复历史预测。文件命名里带上epoch之后做横轴对比时直接按文件名索引。如果只想画动态曲线还有一个更省内存的办法在每个epoch结束时不存完整预测只计算你关心的指标比如每个类别的AUC、top-k准确率把指标数值写进回调里的字典训练结束后再统一画图。这样不需要维护几十份预测数组内存压力小很多。3.3 注意时间开销与显存抖动这个方案的缺点非常现实每个epoch结束都要对完整验证集做一次predict。如果验证集有2万张图训练60个epoch等于额外多跑了60次完整验证推理。有些网络模型推理很快还扛得住但像VGG这种前向很重的模型二次开销就很明显。我有一次任务就是因为这个原因本来一个epoch只要40秒挂上Callback之后直接变成65秒。后来学乖了给Callback加了个save_every参数每5个epoch才做一次验证预测。代价是每个epoch的预测曲线没那么细但整体训练时间回到正常范围画出来的5步间隔曲线已经足够看出模型是否过拟合。显存方面也要提一下predict并不会清掉训练时已经加载的完整计算图而是复用同一个会话所以验证预测的显存额外占用主要是推理时的激活值缓存。如果你的模型本身已经把显存占得接近上限predict时有概率触发OOM。稳妥做法是给Callback里的验证生成器单独设置一个更小的batch_size反正预测结果行数只跟样本数有关跟batch大小无关。4. 用生成器闭包缓存y_true一种更底层的兜底方案4.1 为什么还需要第三种方案看到这里你可能会想前两种方案已经够用了第三种是干嘛的有些场景你还真得用第三种。比如你不想反复predict只想让fit的验证循环自然把验证集“消费”一遍同时把每个批次的真实标签留底又或者你的模型训练逻辑被包在一套公共框架里你想在不改动框架调用方式的前提下拿到标签。这时在生成器层面做包装是最不侵入的方案。实现思路很简单在生成器的迭代循环里顺手把每个batch的y_true复制一份缓存到外部列表。class CachingValGenerator: def __init__(self, keras_gen): self._gen keras_gen self.y_true_batches [] def __len__(self): return len(self._gen) def __iter__(self): self.y_true_batches [] for x, y in self._gen: # 存一份y防止原数据被后续修改 self.y_true_batches.append(np.array(y, copyTrue)) yield x, y cache_gen CachingValGenerator( val_datagen.flow_from_directory( os.path.join(DATA_DIR, val), target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleFalse, seed42, ) ) model.fit( train_gen, steps_per_epochlen(train_gen), epochs50, validation_datacache_gen, validation_stepslen(cache_gen), ) y_true np.concatenate(cache_gen.y_true_batches, axis0)这个类的逻辑就是每次被迭代时重置内部列表然后把生成器吐出来的x_batch和y_batch原样转发只是多复制了一份y。fit的验证循环会自动调用它的__iter__和__len__所以不影响训练流程本身。4.2 缓存数据的重复累积问题这个方案最大的坑在于fit_generator对验证集是每个epoch都会迭代一次的所以__iter__在每个epoch都会被触发而每次触发都会把y_true_batches清空重写。最终你拿到的缓存只对应最后一次验证遍历不一定就是你想要的某个epoch。如果你的验证集shuffleFalse那么每一次遍历的顺序都相同最终缓存内容和任意一个epoch的验证顺序都能对上问题不大。无非是你要记住“这个y_true是最后一次遍历时的顺序”。但如果shuffleTrue每个epoch的验证顺序不同这个方案基本没法用因为你不知道最后一次遍历的具体洗牌顺序拿到缓存也没法和某个epoch的预测对齐。所以我再次强调凡是涉及“拿验证集做事后评估”的需求验证生成器一律shuffleFalse。这不是代码洁癖而是数据对齐的必要前提。另外缓存的数据是每个epoch累加还是只缓存最后一个完整遍历取决于你定义__iter__时清空列表的位置。我这里是在__iter__开头清空保证每次完整遍历只留下一份快照。如果你希望把所有epoch的标签全部缓存下来以观察不同epoch之间的标签顺序差异那就不清空、直接append但那样数据量会膨胀而且通常没什么用。4.3 什么情况下才值得用这个方案诚实地说这个方案的实际使用频率不高。大多数情况下训练后predict的方案简单又可靠代码量也更少。包装生成器这个方式更适合下面两类场景一类是内部框架封装很死的情况。比如某训练平台只允许你传入一个生成器并调用统一fit函数你没机会在fit之后补一个predict。这时用包装生成器就可以在不改平台代码的前提下把标签偷出来。另一类是你在写示例代码、希望向别人展示“如何在数据流层面对齐标签”的场景。从生成器源头缓存y_true比在模型层面做预测再回头找标签逻辑上更直观——标签本来就是在数据生成阶段产生的。如果你不属于这两种情况建议直接跳过这一节用前面的方案就行。技术方案不是越多越好适合当前代码结构才是关键。5. 拿到y_true和y_preds之后混淆矩阵、AUC与top-k准确率5.1 标签编码对齐categorical、binary、sparse三种情况终于拿到两个数组了但别急着算指标先确认标签编码方式。因为不同class_mode下y_true的形状完全不同处理方式也不同。class_modey_true形状解释转换方法categorical(N, num_classes)one-hot向量np.argmax(y_true, axis-1)binary(N, 1)0/1标量y_true.flatten()sparse(N,)整数类别索引直接用y_preds的形状在单输出分类模型里始终是(N, num_classes)代表每个类别的概率。所以你只要把y_true统一成整数类别索引和np.argmax(y_preds, axis-1)比对即可。这里最容易翻车的细节是binary模式。模型输出层如果是sigmoid单输出y_preds形状是(N, 1)和categorical模式的(N, num_classes)相比你要先flatten成(N,)再去计算二分类AUC或混淆矩阵。很多报错“Found array with dim 3. Expected 2”就出现在这里不是模型问题是数组维度没对齐。5.2 一份可直接套用的评估脚本我一般在拿到y_true和y_preds之后直接跑这个脚本from sklearn.metrics import classification_report, confusion_matrix, roc_auc_score y_true_cls np.argmax(y_true, axis-1) y_pred_cls np.argmax(y_preds, axis-1) # 分类报告精确率、召回率、F1 class_names list(val_gen_eval.class_indices.keys()) print(classification_report(y_true_cls, y_pred_cls, target_namesclass_names)) # 混淆矩阵 cm confusion_matrix(y_true_cls, y_pred_cls) print(Confusion matrix:\n, cm) # 多分类AUC需要概率输出 auc roc_auc_score(y_true, y_preds, multi_classovo, averagemacro) print(Macro OVO AUC: {:.4f}.format(auc))如果类别特别多混淆矩阵直接打印会很长我会改用seaborn画成热力图矩阵作为数据传入。这里不展开画图代码你拿到cm之后想怎么画都行。5.3 结果对不上时先查这三个地方如果你发现y_true和y_preds的行数都对但指标异常地低或者混淆矩阵里预测标签集中在某几个类先别怀疑模型出了bug按下面清单排查。第一验证生成器是否在predict时还开着数据增强。如果val_datagen里混进了随机旋转、翻转不同时刻predict同一张图会得到不同结果指标波动很大。验证集只用rescale不做任何增强。第二类别顺序是否一致。模型输出层的类别顺序来自训练生成器的class_indices验证生成器如果目录结构或目录名排序不一致class_indices会不同。打印两个生成器的class_indices肉眼对比一下尤其是中文目录名或带数字前缀的目录名——比如“class1”“class10”字符串排序是class1在class10前面你很容易误以为顺序对。第三是否复用了被fit消费过的生成器做predict。生成器指针位置问题会导致预测行数不足或者顺序漂移。规则很简单每个用途一个独立生成器shuffleFalseseed相同。这三点我每次排查都能用上基本覆盖了“y_true和y_preds能跑但对不上”的常见情况。5.4 top-k准确率与预测结果落盘分类任务里除了单标签准确率我还经常算top-k准确率。比如ImageNet这类大类别任务模型给出的前5个预测里如果包含真实类别也算预测正确。这个指标在评估阶段很容易被忽略但对业务场景非常有用推荐系统里用户不一定选排名第一的候选只要推荐结果在前几名里就有价值。def top_k_accuracy(y_true_cls, y_preds, k3): top_k_preds np.argsort(y_preds, axis-1)[:, -k:][:, ::-1] hits np.array([ y_true_cls[i] in top_k_preds[i] for i in range(len(y_true_cls)) ]) return hits.mean() print(Top-3 accuracy: {:.4f}.format(top_k_accuracy(y_true_cls, y_preds, k3)))把预测结果整份保存下来也很有必要。有时训练完模型评估脚本是临时写的不想为了重算一个指标再跑一遍整个验证集的预测。我会直接np.save(val_y_preds.npy, y_preds)连同当时的y_true一起存之后随便怎么分析都行。6. 三种取数方案怎么选一张对比表和一个实战建议6.1 对比表与选择标准三种方案放在一起差异主要体现在“拿到什么”、“何时拿”、“额外开销”三个维度。对比项训练后predict自定义Callback生成器闭包缓存拿到什么最终模型的y_preds每个epoch的y_preds验证遍历时的y_true何时取训练结束后一次每个epoch自动fit验证循环内自动是否多花推理时间多一次完整预测每个epoch多一次预测无额外计算顺序对齐风险需shuffleFalse需shuffleFalse需shuffleFalse与快照典型使用场景最终评估报告训练过程诊断框架封装太死时兜底代码量少中中选择标准很简单只做最终评估选训练后predict想看训练过程的预测演变选Callback不方便在训后额外预测选生成器闭包。三个方案不是互斥的我个人现在常用组合是“训练后predict做最终评估隔N个epoch的Callback做过程监控”。6.2 我的推荐组合与完整代码骨架这里给一个我自己的组合模板你在自己的任务里把路径和模型结构替换掉就能用train_gen train_datagen.flow_from_directory( train_dir, target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleTrue, seed42, ) val_gen_for_fit val_datagen.flow_from_directory( val_dir, target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleFalse, seed42, ) val_gen_for_pred val_datagen.flow_from_directory( val_dir, target_sizeIMG_SIZE, batch_sizeBATCH_SIZE, class_modecategorical, shuffleFalse, seed42, ) cb ValPredsCallback(val_gen_for_pred, save_every5) model.fit( train_gen, steps_per_epochlen(train_gen), epochs50, validation_dataval_gen_for_fit, validation_stepslen(val_gen_for_fit), callbacks[cb], ) # 训练后最终预测直接用Callback里提前取好的y_true y_true cb.y_true y_preds model.predict(val_gen_for_pred, verbose1) print(y_true.shape, y_preds.shape)注意Callback里的y_true必须在fit开始前就从val_gen_for_pred取好这样最终评估得到的y_true与predict的生成器顺序一致fit里的val_gen_for_fit只是给训练过程算loss用。这两个生成器虽然内容完全一样但互不干扰。6.3 常见错误汇总与最终提醒最后把最容易出错的几个点再总结一遍希望你少走弯路验证生成器永远shuffleFalse。这是所有方案的前提没有这个前提后面所有对齐都是空谈。预测阶段不要用带增强的datagen。验证集只用标准化不用旋转翻转缩放。不要复用一个生成器对象同时服务fit和predict。各自实例化seed相同顺序才能保证一致。predict时别乱设steps走完整个验证集行数才能和y_true对齐。标签编码先确认binary模式和categorical模式的形状不一样直接argmax会出问题。每个epoch存预测之前想清楚内存能不能扛住最好按epoch落盘。这类问题的本质其实不在Keras的API而在于你对训练数据流水线的理解什么时候数据被消费、顺序被谁决定、标签在哪个环节产生。把这些点想透不管以后换PyTorch还是其它框架你都能很快定位到“取预测结果”应该在哪一个环节下手。我自己也是踩了几次坑才彻底理顺希望这篇文章能帮你省下这个时间。

Keras分类训练后获取验证集y_true与y_preds的三种方案

相关推荐

行为型设计模式详解：策略、模板方法、观察者、迭代器、责任链

K均值聚类实战：从原理到落地的完整指南

图像形成物理：计算机视觉的底层逻辑与工程避坑指南

更多资讯

VirtualBox VMM源码深度解析：世界切换与寄存器上下文管理

MSCNN多尺度卷积网络实战：人群密度估计从原理到落地

UML试题大集合：用例图与顺序图关系判断与画图避坑指南

RucBase C++数据库源码实战：B+树并发与缓冲池解析

std::format自定义格式化器：formatter特化与实战指南

COMSOL仿真波导BIC现象：原理与建模实践

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

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

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

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

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