深層学習のモデルを訓練するとき、オプティマイザに何を選んでいますか？
多くの人が「とりあえずAdam（実際にはAdamW）」と答えるでしょう。
それが事実上の標準だからです。
しかし先日、Redditの機械学習コミュニティである投稿が注目を集めました。
「Adamを理解せずにデフォルトのまま使うと、いずれ痛い目を見る」という趣旨の投稿です。
投稿者は強化学習に取り組む人物でした。
そして、Adam特有の挙動に悩まされた経験をもとに問題提起したのです。
発端：説明のつかない損失スパイク
投稿者の悩みはシンプルでした。
強化学習の訓練中、損失の値が突発的に跳ね上がるというものです。
いわゆる「バースト的な」挙動ですね。
原因の特定は難しく、髪をかきむしりたくなるほど苦しんだと語っています。
Adamが機能しないわけではありません。
ただ、なだめすかしながら使う必要があると投稿者は表現しました。
さらに興味深いのは、この現象が強化学習に限らないという主張です。
投稿者は12〜24層クラスの深いTransformerも訓練しています。
すると、Adamのデフォルト設定では激しい損失スパイクが現れたそうです。
つまり、「Adamを使うな」ではありません。
「使い方を考え直せ」というのが投稿の主旨でした。
なぜスパイクが起きるのか
コメント欄では、このスパイクの仕組みについて具体的な解説が寄せられました。
Adamは勾配の一次モーメントと二次モーメントを指数移動平均で保持します。
そして、二次モーメントの平方根で更新量を正規化します。
この仕組みには前提があります。
勾配の統計的な性質が滑らかに変化する、という前提です。
ところが強化学習では、この前提が崩れやすいのです。
方策が変われば、データの分布も変わります。
さらに、ターゲットの更新やリプレイバッファの構成変化も加わります。
その結果、勾配の性質が突然シフトするのです。
問題はここからです。
小さな勾配が続くと、二次モーメントの推定値はどんどん小さくなります。
そこへ大きな勾配が突然到着したらどうなるでしょうか。
小さな値で割り算するわけですから、更新量が爆発します。
これが「何の前触れもなく現れる巨大な損失スパイク」の正体だという説明でした。
あるコメントは、強化学習フレームワークの実装例にも触れています。
不自然に大きなεが設定されているケースがあるというのです。
εを大きくすれば、正規化の効きが弱まります。
それにより、極小の二次モーメントが巨大なステップに化けるのを防げるという見立てでした。
反論：それは本当にAdamのせいか
一方で、投稿の主張に懐疑的なコメントも目立ちました。
まず「これはAdamの問題というより強化学習の問題だ」という指摘です。
非定常な設定の外で、Adamが劇的に破綻する場面に遭遇した人は多くありません。
おそらく投稿者は、特定の問題で苦労したのでしょう。
そして、その経験をAdam全般への批判に一般化してしまったのではないか。
そう分析するコメントもありました。
対処法についても、具体的な反論が出ています。
挙がったのは次の3つです。
- 勾配クリッピング
- 低めの学習率
- 学習率スケジュール
しかも、この現象はAdamに限りません。
どのオプティマイザでも起こり得るし、Transformerの自己注意機構との相性の問題が大きいという指摘です。
むしろAdamは、雑なハイパーパラメータ設定でも動いてくれます。
だからこそ選ばれている、という趣旨でした。
もうひとつ鋭かったのは、チューニング議論そのものへの批判です。
βやεの調整を語りながら、学習率をほとんど扱わないのはおかしいという指摘でした。
これらのパラメータは独立していません。
βやεを変えれば、ステップの振る舞いも変わります。
それなのに、学習率だけを別問題として切り離すのは矛盾しているというわけです。
「Adamの誤解」を語る記事が、チューニングの議論を単純化してしまっては皮肉でしょう。
AdamとAdamWの本当の違い
技術的に踏み込んだコメントの中でも、AdamとAdamWの違いに関する解説は特に有益でした。
両者の違いをweight decayのデフォルト値の差くらいに捉えている人は少なくありません。
しかし、本質は別のところにあります。
素のAdamでは、L2正則化の項が勾配に混ざった状態で処理されます。
つまり、二次モーメントによる正規化を一緒に通過してしまうのです。
√v̂で割られるため、減衰の強さがパラメータごとにバラバラになります。
この正則化を更新則から切り離したこと。
それこそがAdamWの存在意義だという説明でした。
投稿者自身も、この点は認めています。
記事中では「Adam」と書きました。
しかし、実際に念頭にあったのはAdamWだったと補足しています。
多くの実装で置き換えが進んでいる現状を反映した発言と言えます。
脱線から生まれた学び：ノーフリーランチ定理
議論の途中で、ノーフリーランチ定理をめぐる脱線がありました。
これがなかなか面白い展開を見せます。
最初のコメントは「すべての大域最適化手法は平均的に同等の性能になる」と紹介しました。
しかし、別のコメントがすぐに修正を入れます。
定理が本当に言っているのは「あらゆるタスクで最良となる単一の探索手法は存在しない」ということです。
だから、手法選択にはタスクごとのトレードオフが伴うという内容でした。
さらに補足も付きました。
定理は「考え得るすべての問題」にわたる平均の話です。
ところが、現実に扱う問題はその一部にすぎません。
だからこそ、特定の問題群では特定のアルゴリズムが優位に立てるのです。
局所最適解で妥協するなら、手法間の差はさらに開くという指摘もありました。
匿名掲示板の議論で誤解が訂正され、より正確な理解に収束していく。
この過程自体が、コミュニティの価値を示しているように思います。
SGDとの比較はどう考えるべきか
「結局SGDとどちらがいいのか」という論点にも触れておきましょう。
コメント欄での整理はこうです。
チューニングなしで比べれば、たいていAdamがSGDに勝ちます。
ただし、丁寧に調整したSGDが勝つワークロードも残っています。
古典的なCNNによる画像分類は、その代表例です。
ではなぜTransformer界隈はほぼAdamW一色なのか。
答えは「悪いハイパーパラメータへの耐性が高いから」でした。
アーキテクチャやレシピが変われば、優劣も入れ替わります。
そのため、普遍的なランキングは存在しないという結論です。
代替案の提案もありました。
Adam-atan2という変種を推すコメントです。
εを排し、大きな更新スパイクを抑える設計になっています。
また、投稿者はAdagradやRMSpropについても聞かれました。
答えは「適応的なステップサイズという根本の問題は共通している」というものです。
ただし、累積和に頼るAdagradより、指数移動平均を使うRMSpropのほうがまだマシだと評価しています。
データを整えれば済む話なのか
「オプティマイザをいじる時間があるなら、データを増やして綺麗にするほうが効く」というコメントもありました。
一般論としては頷ける主張です。
しかし、投稿者の返答は具体的でした。
データは数億件規模です。
整備には約3か月を費やしました。
しかも、バージョン管理のたびに整合性テストを回しています。
それでも問題は起きた、というのです。
さらに厄介な事情も明かされました。
この種の異常は、訓練開始から2000万ステップを過ぎてようやく顔を出すことがあるそうです。
大規模な分散ジョブでは、ハイパーパラメータ探索だけで事前に炙り出せません。
現実的なコストの問題があるからです。
まとめ
今回の議論から得られる教訓を整理してみましょう。
Adam（AdamW）が悪いわけではありません。
ただし、その正規化の仕組みには前提があります。
勾配統計が滑らかに変化する、という前提です。
強化学習のような非定常な設定では、この前提が崩れます。
そして、損失スパイクという形で牙をむくことがあるのです。
対策の候補は議論の中に出揃っていました。
勾配クリッピング、学習率のウォームアップとスケジュール、εやβ₂の見直し。
そして、これらのパラメータと学習率は独立ではないという認識です。
同時に、すべてを理解してから使うべきだという潔癖さにも限界があります。
巨大な重み行列の中で、個々のパラメータが何をしているか。
それは誰にも把握できません。
ブラックボックスであることを受け入れ、テストと検証で品質を担保する。
この現実的な姿勢を支持する声も強かったのです。
「とりあえずAdam」は多くの場面で正解です。
でも、損失グラフに説明のつかないスパイクを見つけたときは思い出してください。
オプティマイザの前提が、あなたの問題設定と噛み合っていないのかもしれません。
