我已经注意到,在培训期间经常发生的是引入了NAN
。
通常,它似乎是通过权重引入内部产品/完全连接的或卷积层中而产生的。
这是由于梯度计算正在爆炸而发生的吗?还是因为权重初始化(如果是的话,为什么权重初始化会产生这种效果)?还是可能是由于输入数据的性质引起的?
这里的首要问题很简单:在训练过程中发生NAN的最常见原因是什么? 其次,有什么方法可以解决这个问题(为什么它们起作用)?
最佳答案
我多次遇到这种现象。这是我的观察结果:
渐变爆炸
原因:大梯度会使学习过程偏离轨道。
您应该期望:查看运行时日志,应该查看每个迭代的损失值。您会注意到,损失在迭代之间开始显着增长,最终损失将太大而无法用浮点变量表示,并且它将变为nan
。
您可以做什么:将base_lr
(在Solver.prototxt中)减少一个数量级(至少)。如果您有多个损失层,则应检查日志以查看是哪个层造成了梯度爆炸,并减少了该特定层的loss_weight
(在train_val.prototxt中),而不是一般的base_lr
。
不良的学习率政策和参数
原因: caffe无法计算有效的学习率,而是获取'inf'
或'nan'
,此无效率会乘以所有更新,从而使所有参数无效。
您应该期望:查看运行时日志,您应该看到学习率本身变成'nan'
,例如:
... sgd_solver.cpp:106] Iteration 0, lr = -nan
您可以做什么:修复
'solver.prototxt'
文件中影响学习率的所有参数。例如,如果您使用
lr_policy: "poly"
而忘记定义max_iter
参数,则最终会得到lr = nan
...有关咖啡学习率的更多信息,请参见this thread。
故障损失功能
原因:有时,损耗层中损耗的计算会导致
nan
出现。例如,使用带有错误的自定义损失层喂 InfogainLoss
layer with non-normalized values,等等。您应该期望:在运行时日志中,您可能不会注意到任何异常情况:损耗在逐渐减少,并且突然出现了
nan
。您可以做什么:看看是否可以重现错误,将打印输出添加到损失层并调试错误。
例如:一旦我使用了损失,就可以按批次中标 checkout 现的频率归一化惩罚。碰巧的是,如果其中一个训练标签根本没有出现在批次中-计算得出的损失将生成
nan
。在那种情况下,使用足够大的批次(相对于标签中的标签数量)就足以避免此错误。输入错误
原因:您输入了带有
nan
的输入!您应该期望什么:,一旦学习过程“命中”了这个错误的输入输出,就会变成
nan
。查看运行时日志,您可能不会注意到任何异常情况:损失正在逐渐减少,并且突然出现nan
。您可以做什么:重新构建您的输入数据集(lmdb/leveldn/hdf5 ...),请确保您的训练/验证集中没有不良的图像文件。为了进行调试,您可以构建一个简单的网络,该网络读取输入层,在其上具有虚拟损耗并遍历所有输入:如果其中一个输入有故障,则该虚拟网也应生成
nan
。跨度大于
"Pooling"
层中的内核大小由于某些原因,选择
stride
> kernel_size
进行池化可能会导致nan
s。例如:layer {
name: "faulty_pooling"
type: "Pooling"
bottom: "x"
top: "y"
pooling_param {
pool: AVE
stride: 5
kernel: 3
}
}
在nan
中带有y
的结果。"BatchNorm"
中的不稳定性据报道,在某些设置下
"BatchNorm"
层可能会由于数值不稳定而输出nan
。此issue是在bvlc/caffe中提出的,而PR #5136试图对其进行修复。
最近,我意识到
debug_info
标志:在debug_info: true
中设置'solver.prototxt'
将使caffe打印以在训练期间记录更多调试信息(包括梯度幅度和激活值):该信息可以help in spotting gradient blowups and other problems in the training process。
关于machine-learning - 训练过程中出现Nans的常见原因,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37142830/