TensorFlow实现DQN时权重更新后变量变为NaN的问题排查

这种训练刚开始没几步就崩成NaN的情况我之前也碰到过好几次，结合你的DQN场景和动作空间（0-10的整数），大概率是这几个地方出了问题，咱们一个个捋：

1. 奖励值未归一化引发梯度爆炸 #

DQN的损失计算完全依赖目标Q值，如果你的奖励设置得太夸张（比如一次奖励几百上千），很容易让预测Q值和目标值的差距拉得过大，直接把梯度推到溢出，权重更新几次就变成NaN了。

• 解决办法：先把奖励做归一化处理，比如缩放到[-1,1]或者[0,1]区间；另外一定要给梯度加裁剪，TensorFlow里可以用tf.clip_by_norm(gradients, max_norm=1.0)来限制梯度的范数，从根源上防止梯度爆炸。

2. 目标Q值计算时的数值溢出 #

看你代码里提到了y_targets，如果用贝尔曼方程计算目标Q的时候（也就是y = r + gamma * max(Q_target)），gamma设置得太接近1，再加上奖励不断累积，很可能让目标Q值越来越大，最后超出浮点数范围变成NaN。

• 解决办法：先把gamma调低试试，比如从0.9开始；另外可以改用Double DQN的方式计算目标值——用在线网络选动作，目标网络来算对应Q值，既能避免max操作带来的Q值过估计问题，也能减少数值溢出的概率。

3. 动作空间的索引处理出错 #

你的动作是0-10的整数，要是在Q_Values_of_Given_State_Action里处理actions_的时候，动作值和网络输出的维度不匹配，或者选了超出输出维度的索引，TensorFlow有时候不会直接报错，而是返回NaN来“糊弄”你。

• 解决办法：仔细检查动作转索引的逻辑，确保动作0对应网络输出的第0位，动作10对应第10位；可以加个断言提前排查问题，比如tf.debugging.assert_less(actions_, self.num_actions)，一旦索引越界直接报错，别等变成NaN才发现。

4. ADAM优化器的学习率过高 #

ADAM默认的学习率是0.001，但DQN对学习率比较敏感，要是设得太高，哪怕梯度正常，几次更新也会把权重推到NaN。

• 解决办法：把学习率调低试试，比如改成optimizer = tf.keras.optimizers.Adam(learning_rate=1e-4)；另外也可以检查下是否开启了不合理的权重衰减，这也可能导致数值异常。

5. 网络输出未做范围约束 #

如果你的Q值网络最后一层没加任何约束，当输入状态出现极端值的时候，网络输出可能会变得极大，进而导致损失和梯度直接爆炸。

• 解决办法：可以在网络最后一层加个Lambda层做约束，比如tf.keras.layers.Lambda(lambda x: tf.clip_by_value(x, -100, 100))，给Q值设置一个合理的上下限，避免数值溢出。

内容的提问来源于stack exchange，提问作者sunjeet95