早期終了の罠：RLの学習が始まる前に台無しにしていた話

early stopping（早期終了）は、学習を終えたモデルに計算資源を無駄に費やすのを防ぐためのものだ。だが長い間、それは私の計算資源を無駄にしていた張本人だった。優秀なエージェントが優秀になる前に、息の根を止めていたのだ。

私の強化学習（RL）の実験は、悪いアイデアによってよりも、自分で設定したearly stoppingルールによって死んでいったものの方が多かった。規律を保つために組み込んだはずのこのキルスイッチは、システムの中で最も規律を欠いた存在になっていた。

これは説明用のイラストであり、実際のパフォーマンスデータではない。エージェントは通常の落ち込みの最中に終了させられた。まさにこの後で上昇していたはずなのに。

裏目に出たキルスイッチ

私はearly stoppingを教師あり学習から借用した。教師あり学習ではこれは定石だ。validation loss（検証損失）を監視し、しばらく改善しなくなったら止める。それ以降はoverfitting（過学習）するだけだからだ。シンプルで安全、そして教師あり学習ではたいていうまくいく。

そこで私は同じ発想をRLの学習に組み込んだ。指標を監視し、plateau（停滞）が続いたらpatience（忍耐）を切らして実験を止め、GPU時間を節約する。責任ある判断のように感じられた。だが実際には、それは静かに実験を次々と捨てていった。その多くは早すぎる段階、つまりエージェントがまだ何も見つけていないうちに止められていた。結果として、私の手元にはそもそも始まってすらいなかった実験のフォルダが残った。

なぜRLではこのルールが破綻するのか

教師あり学習のvalidation曲線は、おおむね滑らかで単調に近いものだ。強化学習エージェントの進歩はそうではない。rewardは構造上ノイズが多い。それ自体が変化し続けるpolicyに依存し、そのpolicyが分散だらけの環境と相互作用するからだ。改善は断続的に訪れる。長い横ばい、突然のジャンプ、そして回復する落ち込み。RLにおけるplateauは、学習の終わりではないことが多い。むしろその直前の段階なのだ。

だから教師あり学習の滑らかさに合わせて調整したpatienceは、ごく正常なRLの分散の最中に発動してしまう。学習を終えたモデルを捕まえるのではなく、まさに面白くなろうとしていたモデルを処刑してしまうのだ。そして「節約」は幻想にすぎない。早期に死んで何も返してこなかった実験すべてに、結局コストは支払っているのだから。

早く止めるのをやめる

解決策は、より良い数値ではなかった。デフォルトを反転させることだった。early stoppingは積極的ではなく、まれに起きるべきものだ。ノイズに対する過敏なトリガーではなく、本物の持続的なoverfittingに対する防御線でなければならない。つまり、ノイズが現実的には到達できないところに基準を置き、わずか数回の評価ではなく、実験本来の分散を圧倒するほど長い窓で劣化を判断するということだ。デフォルトは継続するでなければならない。立証責任は、止めることの側にあって、続けることの側にはない。

率直に言えば、patienceもまたhyperparameter（ハイパーパラメータ）だ。そして私を含む多くの初心者は、まるでRLが教師あり学習であるかのようにこれを設定してしまう。RLは教師あり学習ではない。

人間がなお担うべき領域

これは第1回の教訓と響き合う。私は実験ごとにいつプラグを抜くかを判断しない。それは結局、推測をシステムに凍結し込んでいるだけだ。私が判断するのは、*「本当に悪化している」とは何を意味し、「正常なノイズ」*とは何を意味するかであり、その定義に止める仕事を任せる。私は審判を設計しているのであって、一つ一つの判定を手作業で下しているのではない。審判を正しく設計できれば、うまくいったはずの実験を捨てることはなくなる。

まとめ

RLにおいて、最も高くつくバグはしばしば焦りだ。計算予算を早すぎる段階で最適化しても、計算資源は節約されない。代わりにエージェントを失う。そして残酷なのは、自分が殺してしまった結果を決して見ることがないという点だ。

だからもし実験が「うまくいかない」状態が続くなら、それらにそもそもチャンスが与えられていたのかを確認してほしい。モデルが失敗していたのではないこともある。失敗していたのは、あなた自身だったのだ。

これは、強化学習を用いたトレーディングシステムを構築する、匿名の継続的な記録の第2回である。これは手法と失敗についての記録であってシグナルについてではない。ここに書かれていることは投資助言ではなく、戦略の詳細も一切共有していない。