网站右下角弹窗代码,互联网门户网站,选择网站模板注意事项,网站建设 徐州这篇文章是在完成 HW02 的过程中所产生的#xff0c;是关于各 scheduler #xff08;ReduceLROnPlateau()#xff0c;CosineAnnealingLR()#xff0c;CosineAnnealingWarmRestarts()#xff09;使用的对比实验。 起因是为了在 Kaggle 上跑出更高的成绩#xff0c;但结果确… 这篇文章是在完成 HW02 的过程中所产生的是关于各 scheduler ReduceLROnPlateau()CosineAnnealingLR()CosineAnnealingWarmRestarts()使用的对比实验。 起因是为了在 Kaggle 上跑出更高的成绩但结果确出乎我的意料为了工作不白费我决定将它们的结果重新可视化分享给你们。我一开始没有过多的修改初始配置这篇文章的目的仅仅是为了给你展现不同 scheduler 下的学习率变化以及对实验结果的影响片面的。 时间原因我仅在这个数据集上跑了对比实验。 文章目录开始实验**ReduceLROnPlateau()**学习率变化曲线实验数据**Kaggle 分数: 0.74427****CosineAnnealingLR()**学习率变化曲线实验数据**Kaggle 分数: 0.74391没有提升****CosineAnnealingWarmRestarts()**学习率变化曲线实验结果**Kaggle 分数: 0.74328没有提升**T_0 * 2学习率变化曲线实验结果**Kaggle 分数: 0.74403没有提升****no scheduler**学习率变化曲线实验结果**Kaggle 分数: 0.74408****实验结果对比**修改 lr2.5e-4重新实验**实验结果对比**总结开始实验 为了对比每个 scheduler 都跑了 300 个epoch可能不多但也能看出些端倪。 这里贴一下我的其他参数如果不需要做这个 HW可以跳过这段往下看并不影响。 跑 300 个 epoch 是因为在这个参数的设置请勿模仿下大概到 300 就没有什么波动了。 dropout(p0.25)concat_nframes 15 # the number of frames to concat with, n must be odd (total 2k1 n frames)
train_ratio 0.95 # the ratio of data used for training, the rest will be used for validation# training parameters
seed 1213 # random seed
batch_size 512 # batch size
num_epoch 300 # the number of training epoch
learning_rate 5e-4 # learning ratehidden_layers 6 # the number of hidden layers
hidden_dim 512 # the hidden dim最初我增加了一个自动调整 learning_rate 的 scheduler选择的是 torch.optim.lr_scheduler 中的 ReduceLROnPlateau()。
ReduceLROnPlateau()
先介绍一下参数方便理解 torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, mode‘min’, factor0.1, patience10, threshold0.0001, threshold_mode‘rel’, cooldown0, min_lr0, eps1e-08, verboseFalse) optimizer (Optimizer) 指定需要对哪个优化器对象进行学习率调整。mode (str)指标的模式。可以是“min”或“max”。如果是“min”那么当指标停止降低时将调整学习率如果是“max”那么当指标停止升高时将调整学习率。factor (float)学习率缩小的因子。新学习率旧学习率 * factor。注意factor 不能大于1。patience (int)如果指标没有改善则等待多少个epoch来调整学习率。threshold (float)指标的变化量阈值如果小于此值则将其视为没有改进。threshold_mode (str)判断阈值的模式。可以是“rel”或“abs”。如果是“rel”动态阈值等于最优值乘以(1threshold)在’max’模式下或最优值乘以(1-threshold)在’min’模式下。在’abs’模式下动态阈值等于最优值加上threshold在’max’模式下或最优值减去threshold在’min’模式下。cooldown (int)表示在减小学习率之后等待几个epoch才能再次减小学习率。min_lr (float or list)学习率的下限。eps (float)表示应用于学习率的最小衰减量。如果新旧学习率之间的差异小于eps则更新会被忽略。verbose (bool)如果为True则在调整学习率时打印更新的消息。 optimizer torch.optim.Adam(model.parameters(), lr5e-4) # 假设初始学习率为 5e-4
scheduler torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, modemax, factor0.8, patience10, threshold0.001) # 如果 10 个 epoch 后都没有提升lr * factorfor epoch in range(num_epoch):train(...) # 训练模型validate(...) # 验证模型scheduler.step(metric) # 根据 metric 更新学习率学习率变化曲线 实验数据 Kaggle 分数: 0.74427
最初选择 ReduceLROnPlateau() 的原因是基于一个设想的较乐观的情况只要慢慢减少学习率一定会收敛到优秀的解。
当时发现了好几种scheduler但看到根据 epoch 变化 learing rate 的 scheduler比如 StepLRExponentialLR觉得完全不如根据实验结果动态变化的 ReduceLROnPlateau 便没有进行选择。
看到这里你应该仅仅对 ReduceLROnPlateau() 有了简单的认识不妨继续往下看看看实验对比。
在 acc 卡住后我试图去寻找其他的 scheduler看能不能让 learning rate 在中途变大跳出一些区域后再变小然后发现还有周期性变化的 scheduler比如 CosineAnnealingLRCyclicLR于是我尝试修改成 CosineAnnealingLR()。
CosineAnnealingLR() torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max, eta_min0, last_epoch- 1, verboseFalse) optimizer (Optimizer) 指定需要对哪个优化器对象进行学习率调整。T_max (int): 表示半个周期的长度。例如如果T_max10则学习率在第0个epoch时为最大值在第0到第10个epoch之间以余弦函数形式逐渐减小在第10个epoch时达到最小值在第11到第20个epoch之间以余弦函数形式逐渐增大在第20个epoch时回到最大值。eta_min (float): 表示学习率的最小值在学习率下降到这个值之后就不再下降了。默认为0。last_epoch (int): 表示上一次更新学习率的epoch索引。默认为-1表示还没有开始训练。这个参数用于恢复训练时使用可以将其设置为已经训练的epoch数减 1。verbose (bool)如果为True则在调整学习率时打印更新的消息。 optimizer torch.optim.Adam(model.parameters(), lr5e-4) # 假设初始学习率为 5e-4
scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max10, eta_min1e-7)for epoch in range(num_epoch):train(...) # 训练模型validate(...) # 验证模型scheduler.step() # 更新学习率学习率变化曲线 实验数据 Kaggle 分数: 0.74391没有提升
这个 scheduler 中的 learning rate 变化曲线与余弦函数一致但观察发现CosineAnnealLR 的周期性变化似乎让收敛的过程变得曲折多次实验效果都类似。
观察 acc 和 lr 的变化每一次 lr 逐步上升都会让 acc 下降。于是我想着有没有一种 scheduler让 lr 跳过逐步上升的过程于是找到了 CosineAnnealingWarmRestarts这个 scheduler 会让 learning rate 在周期的最后瞬间上升 这个概念在李宏毅老师过去的视频中也有说到即warm restart。
CosineAnnealingWarmRestarts() torch.optim.lr_scheduler.CosineAnnealingWarmRestarts(optimizer, T_0, T_mult1, eta_min0, last_epoch- 1, verboseFalse) optimizer (Optimizer) 指定需要对哪个优化器对象进行学习率调整。T_0 (int): 表示第一次restart的epoch即在T_0个epoch后学习率将回到最高点重新开始下降。默认值为10。T_mult (float): 表示每次restart之后T_0的值将乘以T_mult。默认值为1。eta_min (float): 表示学习率的最小值在学习率下降到这个值之后就不再下降了。默认为0。last_epoch (int): 表示上一次更新学习率的epoch索引。默认为-1表示还没有开始训练。这个参数用于恢复训练时使用可以将其设置为已经训练的epoch数减 1。verbose (bool)如果为True则在调整学习率时打印更新的消息 optimizer torch.optim.Adam(model.parameters(), lr5e-4) # 假设初始学习率为 5e-4
scheduler torch.optim.lr_scheduler.CosineAnnealingWarmRestarts(optimizer, T_010, T_mult1, eta_min1e-7)for epoch in range(num_epoch):train(...) # 训练模型validate(...) # 验证模型scheduler.step() # 更新学习率学习率变化曲线 实验结果 Kaggle 分数: 0.74328没有提升
我以为实验结果会变得更好发现并没有无论哪种 scheduler最终的结果都差不多epoch 300这可能是我初始lr设置的太大5e-4的原因
虽然我产生了修改学习率的想法但我还想尝试一下另一种修改方式因为我发现 CosineAnnealLR 参数中 T_max 指代的是半个周期的长度而 CosineAnnealingWarmRestarts 参数中的 T_0 指代的是一个周期长度我将二者都设置成了 10这使得 CosineAnnealingWarmRestarts 在300个epoch中有30个周期是 CosineAnnealLR 的两倍我或许应该将 T_0 设置为 2*T_max 来进行最终的对比实验。 T_0 * 2
学习率变化曲线 实验结果 Kaggle 分数: 0.74403没有提升
看起来各个 scheduler 最终的表现似乎没有区别我决定跑一个没有scheduler的版本是的我一开始默认的觉得加上scheduler一定会让实验变得更好但发现似乎并不是这样最起码在当前的配置下不是有可能是batchnorm的原因。
no scheduler
学习率变化曲线 实验结果 Kaggle 分数: 0.74408
实验结果对比 评价是花里胡哨没有区别HW02 下。真要用的话 ReduceLROnPlateau() 就够了有时可以减少训练时间。
现在我决定根据一个现象去改变 lr 的初始值从输出中观察到在所有周期中每次 lr2.5e-4 和 1.72e-4 的时候上升幅度最大于是我将 lr 设置成 2.5e-4 重新跑了所有的实验。
修改 lr2.5e-4重新实验
实验结果对比 可以看到Kaggle 分数没有提升。
下图是 lr 5e-4 和 lr2.5e-4 的 CosineAnnealingWarmRestarts 对比结果 原以为会有很大的变化比如在 lr 的最高点处 acc 不会降低这么多发现并没有甚至可以说是一模一样这其中一定有什么我还不了解的东西在发挥作用。
总结
scheduler 真的没有作用吗不尽然这很大程度上取决于你现在的损失函数面和参数配置使用 scheduler 往往可以更快的收敛。下图是对比
但相对于盲目的使用一些可能提高 metric 的函数你更应该在预处理数据上下功夫
跑完这个对比实验后我增加了输入的维度让数据在一开始拥有更多的信息对应到 HW02 就是将 concat_nframes 从 15 增加到了 21使得在网络可以更多的考虑到相邻的音素仅仅改变这一条Kaggle 的分数便超过了 strong baseline达到了 0.75623。 进一步的dropout 其实不应设置成 25通过观察可以发现没有 dropout 的时候训练集很容易便能达到 90 的准确率当然这是过拟合了。但 p25 时acc 一直上不去又何尝不是欠拟合呢基于这个想法我在 p25/15 下做了对比下图是大致的实验结果使用了 ReduceLROnPlateau() 发现这使得 acc 比之前更快的抵达了 strong baseline至于刚刚所想的欠拟合好像没有体现出来 : )
P.S. epoch 设置成 300 完全是为了跑对比实验做 HW 的时候不要设这么大浪费时间。 实验局限在一个可能不好的参数配置也局限在单独的 optimizer 之下仅向大家展示片面的的结果 : )
以上是关于部分 scheduler 使用的实验对比和总结希望对你有所帮助
