Ceci est une suite de cet article. Othello-De la troisième ligne de "Implementation Deep Learning" (1) http://qiita.com/Kumapapa2012/items/cb89d73782ddda618c99 Othello-De la troisième ligne de "Implementation Deep Learning" (2) http://qiita.com/Kumapapa2012/items/f6c654d7c789a074c69b

Cliquez ici pour les articles suivants. Othello-De la troisième ligne de "Implementation Deep Learning" (4) [Fin] http://qiita.com/Kumapapa2012/items/9cec4e6d2c935d11f108

J'ai mentionné la fonction d'activation dans le premier article, mais étant donné le potentiel de mort de ReLU, jouons à un jeu d'Othello avec peut-être le moyen le plus simple et le plus rapide de contourner cela, Leaky ReLU. Je l'ai essayé. Le code est ici. https://github.com/Kumapapa2012/Learning-Machine-Learning/tree/master/Reversi

Leaky ReLU ReLU est une fonction d'activation qui définit toutes les valeurs inférieures à 0 à 0.

f = \max(0,x)

Cette fois, le NN est une jointure complète, mais comme décrit précédemment, le problème de la mort de ReLU peut se produire. Une solution à cela est Leaky ReLU, qui donne une petite inclinaison aux valeurs négatives (par défaut 0,2 pour le chainer).

{f = \begin{cases}
    x & (x>0) 
    \\
    0.2x  & (x<=0)
  \end{cases}
}

Cela élimine la pente zéro. Il s'agit d'une interprétation personnelle, mais la mort de ReLU est essentiellement due au fait que la pente de la valeur négative est 0, vous pouvez donc ajouter une pente. Cependant, parce que nous voulons conserver les caractéristiques de ReLU "pente positive est 1 et pente négative 0", comme la différenciation facile et le calcul et l'apprentissage rapides (rétropropagation), la pente est faible. , Je pense que c'est une fonctionnalité de Leaky ReLU.

J'ai essayé d'utiliser Leaky ReLU.

Changez la fonction d'activation de ReLU en Leaky ReLU en ne modifiant que 8 lignes de code dans agent.py.

$ diff ~/git/Learning-Machine-Learning/Reversi/agent.py agent.py 
47,55c47,55
<         h = F.relu(self.l1(x))
<         h = F.relu(self.l20(h))
<         h = F.relu(self.l21(h))
<         h = F.relu(self.l22(h))
<         h = F.relu(self.l23(h))
<         h = F.relu(self.l24(h))
<         h = F.relu(self.l25(h))
<         h = F.relu(self.l26(h))
<         h = F.relu(self.l27(h))
---
>         h = F.leaky_relu(self.l1(x))   #slope=0.2(default)
>         h = F.leaky_relu(self.l20(h))
>         h = F.leaky_relu(self.l21(h))
>         h = F.leaky_relu(self.l22(h))
>         h = F.leaky_relu(self.l23(h))
>         h = F.leaky_relu(self.l24(h))
>         h = F.leaky_relu(self.l25(h))
>         h = F.leaky_relu(self.l26(h))
>         h = F.leaky_relu(self.l27(h))

En conséquence, le taux de gain a augmenté régulièrement sur le plateau 6x6. ** Lors de l'utilisation de Leaky ReLU (pente = 0,2) **

C'est assez différent du résultat précédent. Après tout, est-ce que ReLU mourant s'est produit? ** Lors de l'utilisation de ReLU **

Ensuite, dans le cas d'une carte 8x8 ... Le taux de gain n'était pas stable / (^ o ^)
** Lors de l'utilisation de Leaky ReLU (pente = 0,2) **

Dans le premier résultat, le taux de victoire semble finalement converger. ** Lors de l'utilisation de ReLU **

Si vous pensez très simplement, si le taux de gain est ReLU, c'est-à-dire Leaky ReLU avec Slope = 0, il semble converger, et s'il ne converge pas lorsque Leaky ReLU avec Slope = 0,2, il peut y avoir une valeur optimale entre-temps. Peut être. J'aimerais l'essayer plus tard avec Slope = 0.1. Mais le plus gros problème est qu'il y a une vague de taux de victoire. L'ondulation semble signifier que l'apprentissage ne s'arrête pas au bon endroit. Cela semble être lié au taux d'apprentissage. D'après le chapitre 6 du livre "Deep Learning from Zero", le taux d'apprentissage est essentiellement un coefficient qui indique le degré de mise à jour du poids W. Plus la valeur est élevée, plus le degré de mise à jour de W est élevé et plus l'apprentissage progresse rapidement, mais il diverge. Il y a une possibilité [^ 1]. Cependant, s'il est trop petit, l'apprentissage sera trop lent. C'est. L'argument lr (Learning Rate = learning rate) de RMSPropGraves utilisé cette fois est 0,00025. Dans RMSPropGraves de chainer, le lr par défaut est 0,0001, donc cet échantillon est un peu plus grand. Probablement, ce 0,00025 est une valeur optimisée pour la vitesse d'apprentissage de la disposition à trois voies de l'échantillon, et dans le cas de la carte 8x8 d'Othello cette fois, la valeur de W n'est pas stable, et par conséquent, le taux de gain est comme indiqué dans le graphique ci-dessus. On pense qu'il est devenu instable. Pour cette raison, j'aimerais essayer à l'avenir ce qui se passe lorsque le taux d'apprentissage est bas. [^ 2]

Les références

Ordinateur Othello https://ja.m.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E3%82%AA%E3%82%BB%E3%83%AD
Parlez des expériences d'échec et des anti-modèles dans Neural Network http://nonbiri-tereka.hatenablog.com/entry/2016/03/10/073633 (D'autres seront ajoutés à une date ultérieure)

[^ 1]: L'expansion des fluctuations de poids due à un taux d'apprentissage élevé peut également être un facteur de la mort de ReLU. [^ 2]: De plus, la fonction d'activation de la couche de sortie est-elle la même que la couche cachée en premier lieu? Dois-je y réfléchir séparément? Je suis également inquiet à ce sujet.

[PYTHON] Othello-De la troisième ligne de "Implementation Deep Learning" (3)

J'ai essayé d'utiliser Leaky ReLU.

Les références