早停必须监控验证集Loss而非训练集Loss，因为训练Loss天然持续下降无法反映泛化能力，只有验证Loss上升才表明过拟合；核心参数需设monitor='val_loss'、mode='min'、patience=7，并开启restore_best_weights=True。
早停为什么必须监控验证集Loss而不是训练集Loss
因为训练集Loss持续下降是常态，哪怕模型已经在过拟合——它只是在死记硬背训练样本。早停的目标是防止泛化性能变差，而验证集Loss上升才是泛化崩溃的直接信号。用train_loss做早停条件，几乎一定会停得太晚，甚至根本不停。
tf.keras.callbacks.EarlyStopping的必要参数怎么设
核心是三个参数：监控目标、方向、容忍轮数。默认配置monitor='val_loss'（必须显式写，不能依赖默认）、mode='min'（Loss越小越好）、patience=7（连续7轮没改善才停）。漏掉mode在某些自定义指标下会出错；patience太小容易误停，太大又失去早停意义。
-
restore_best_weights=True一定要开——否则模型保存的是最后一步权重，不是验证Loss最低时的权重 - 如果用
validation_split而非独立validation_data，注意数据划分是每次fit前重新打乱的，可能影响稳定性 - 避免监控
val_accuracy做回归任务，或监控val_loss但训练时没传validation_data——会直接报ValueError: Not found in model metrics
验证集Loss不下降但模型还在“假学习”怎么办
常见于验证集太小、噪声大，或验证Loss震荡剧烈。这时单纯看“是否上升”不可靠。可以改用min_delta=1e-4（只认大于该值的下降），或换用mode='auto'让Keras根据监控名自动推断方向（但名字必须含loss或acc）。
- 更稳妥的做法是配合
ReduceLROnPlateau：先降学习率，等几轮再早停，给模型一点“抢救机会” - 如果验证Loss平台期很长（比如连续20轮波动±0.001），
patience设成15比设成3更合理 - 注意batch size影响验证Loss方差——小batch导致
val_loss抖动大，此时适当增大patience或用滑动平均平滑判断
早停后如何拿到最佳模型权重
关键就一条：restore_best_weights=True必须开启，且要在model.fit()中传入callbacks=[early_stopping]。停训后模型对象model的权重就是验证Loss最低时的状态，无需手动加载。
- 如果想单独保存那个最优权重，可以在EarlyStopping里加
filepath配合ModelCheckpoint，但别重复设save_best_only=True——早停本身不保存文件 - 检查是否生效：fit结束后打印
early_stopping.stopped_epoch和early_stopping.best，前者非0说明真触发了，后者是记录的最低val_loss值 - 多卡训练（
DistributedStrategy）下，EarlyStopping仍有效，但val_loss是全局平均值，不用额外处理
早停真正难的不是写那几行callback，而是确认验证集足够代表真实分布、且Loss计算逻辑和线上推理一致——比如用了label_smoothing却在验证时没对齐，或者预处理pipeline在训练/验证/预测三端不统一，这时候早停停得再准也没用。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
