バッチサイズと学習率の関係について
「学習率をバッチサイズに比例して増やす」（ルール1）
という慣例があるが、これの根拠について説明する。
典拠
まず、このアイデアの出所は論文[1]だと思われる。 この論文では「学習率をバッチサイズに比例して増やす」というルールを適用すると幅広いバッチサイズで収束後の性能が良くなることを経験的に示した。
論文ではこの法則がうまくいく理由について、「バッチサイズがk倍になると、1epochあたりの更新頻度が1/kになる。1回の更新量が両者で概ね同じだと仮定すると、kステップ後の更新量に大きな差が出ると考えられる。後者で学習率をk倍すると、少なくなった更新量を補償することができるのではないか」といった趣旨の考察をしている（"informal discussion"と断っている）。
DDPにおける学習率について
このルールはDDP(Distributed Data Parallel)における学習率についても当てはめることができる。 DDPでは仮想的なバッチサイズが全プロセスのバッチ数の総和となるため、個々のプロセスのバッチサイズをB、プロセス数をPとすると、バッチサイズはPBとなる。 バッチサイズが大きくなることで更新頻度が少なるなる、という性質は変わらないので、ルール1を適用すると、DDPにおける学習率はPBα / B=Pαとなる。つまり、1プロセスあたりのバッチサイズが一定の場合、学習率はプロセスの並列数に比例して設定することになる。
参考文献
Appendix: Adamにおける更新量について
論文[1]で扱っているのはoptimizerがSGDのケースだが、この解釈はAdamにも当てはまる。むしろ、Adamの場合はより物理的に意味のある解釈ができることを以下で示す。
まず、Adamは「signed SGD」の一種である。これは「学習率を乗じる前の更新量の絶対値が概ね1で、更新の符号のみパラメータごとに異なる」という性質を持つことに由来する。以下に示すパラメータ更新式を見れば明らかである。
つまり、Adamでは「1回の更新における変異ベクトルの絶対値が学習率に概ね一致する」と言い換えることができる。つまり「Adamにおけるkステップ後の移動量の総和はk * αである」と言える（ここでは簡単のために学習率のスケジュールは無視している）。
さて、元の学習率の議論に戻り、ルール1を当てはめると、以下のような設定となる。
- バッチサイズがBで1epochあたりのステップ数がN/B、学習率がα
- バッチサイズがkBで1epochあたりのステップ数がN/kB、学習率がkα
ここで1、2のケースで1epochあたりのパラメータの移動量の総和を計算すると、どちらのケースの場合もαN/Bとなることがわかる。つまり、Adamの場合は「学習率をバッチサイズに比例して増やすと、パラメータ空間における移動量が不変となり、バッチサイズに比例しなくなる」と言える。
このように、ルール1はAdamの場合は物理的に意味のある解釈ができる。
