OhtaEngineerOptuna開発メンバの太田(@sile)です。この記事では、Optuna開発時に利用している拙作のkurobakoというツールの紹介をさせていただきます。GitHubkurobakoを一言で表すなら「Optunaの(ほぼ)全機能に対応した、ブラックボックス最適化向けベンチマークツール」となります。[1]は、PFNが開発しているオープンソースのハイパーパラメータ自動最適化フレームワークです。Optunaにはsamplerおよびprunerと呼ばれる構成要素が存在し、これらを変更することで、最適化アルゴリズムをカスタマイズすることが可能になっています。samplerは、ユーザが定義した目的関数の結果の最小化または最大化を目指し、次のトライアルで評価するハイパーパラメータを決定します(図1)。その際には、対象の目的関数に特別な性質(例えば微分可能性)は要求せずに、過去のハイパーパラメータの評価結果だけを考慮して動作します。このような最適化アルゴリズムは、ブラックボックス最適化アルゴリズムとも呼称されます。一方で、prunerはハイパーパラメータの評価を途中で打ち切るかどうかを決定します。深層学習でモデルを訓練する際のハイパーパラメータを最適化したいとします。この場合、ハイパーパラメータの一回の評価(モデルの訓練)に長時間を要することは珍しくありません。そこでprunerを用いて、明らかに性能が悪いモデルは完全には評価(訓練)せずに、初期段階で中止するようにすれば、最適化に掛かる時間を短縮することが可能になります。ブラックボックス最適化の文脈では、samplerとprunerといった明確な区別は設けずに、両者を合わせて、multi-fidelityブラックボックス最適化といった枠組みで扱われることが多いです(図2)。sampler/prunerとmulti-fidelityブラックボックス最適化kurobakoは、このmulti-fidelityブラックボックス最適化に対応したベンチマークツールとなっています。開発の動機Optunaの開発に携わっていると、samplerやprunerのアルゴリズムの改善や試作を行う機会がたびたびあります。その際に難しいのが「新しいアルゴリズムの最適化性能の評価をどう行うか」といった問題です。[2]が開発されています。[3]というOSSのベンチマークフレームワークも存在します(図3)。これらの関数の多くは「連続変数で構成された探索空間」かつ「単一fidelity」のみを扱っており、Optunaが想定している問題設定のサブセットしかカバーされていません。COCOに含まれるベンチマーク関数の一部(一覧)より現実的な問題を扱ったベンチマークツールとしては、今年にGitHubで公開されたnas_benchmarksがあります。これはニューラルネットワークのアーキテクチャ探索(NASBench)[4]およびハイパーパラメータ探索(HPOBench)[5]という二種類のタスクに基づくベンチマークを提供しており、その探索空間は離散変数とカテゴリ変数から構成されています(図4)。加えて、multi-fidelityな評価にも対応しています。[5]上述のベンチマーク群は、それぞれ有用なものではありますが、これだけで事足りるかといえば、そうではありません。categorical})multi-fidelityな評価(枝刈り)複数トライアルの非同期並行実行(分散最適化)ifやforループを含んだ探索空間(define-by-run)私の知る限りでは、上記の全てに対応したベンチマークツールは存在しませんでした。これらをカバーし、Optunaの全機能を簡単に評価できるようにしたかった、というのがkurobakoの開発動機です。特定のベンチマークに絞って性能評価を行い続けると、最適化アルゴリズム(およびそれ自体のハイパーパラメータ)が、そのベンチマークにオーバーフィットしてしまう危険性があります。それを防ぐために、新しいベンチマーク問題の追加が簡単で、多様なベンチマーク群を同じ枠組みで扱えるようにしておきたかった、というのもモチベーションの一つです。[6]で提供されているベンチマーク関数が、kurobakoに標準で組み込まれています。#447といったPRで、最適化性能評価にkurobakoが使用されています。基本的な使用方法kurobakoは、Rustで書かれたコマンドラインツールで、入出力フォーマットにはJSONを採用しています。report...長いので省略...最後のレポートの内容はこのgistに貼ってあります。図のY軸は目的関数のベスト値(三十回平均)です。X軸は最適化時のリソース消費量を表し、一バジェットが「目的関数の一回の完全な評価」に対応します。HPOBenchでは、完全な評価(モデルの訓練)に100エポック掛かるので、例えばバジェットの値が40なら、4000エポック分の訓練を実行していることになります。HPOBenchでは、事前に探索空間内の全てのハイパーパラメータの組み合わせを評価して、その結果がキャッシュされているので、ベンチマーク実行時には実際のモデルの訓練は不要で、キャッシュ参照だけで済むようになっています。上のベンチマークは一例に過ぎませんが、利用可能なバジェットが少ない場合には、枝刈りを有効にした方が良好な結果が得られていることが見て取れるかと思います。[7]が、枝刈りなしのものに追い抜かされています。最適化アルゴリズムの追加方法kurobako自体はRust製ですが、独自の最適化アルゴリズム(solver)を、コマンドラインプログラムとして実装することが可能になっています(problemも同様)。result.jsonおわりにこの記事ではkurobakoという、ブラックボックス最適化用のベンチマークツールを紹介させていただきました。「Optunaのアルゴリズム周りにコントリビュートしてみたいけれど、最適化性能がちゃんと出ているかが心配」といった人がいれば、是非試してみてください。最終的には、OptunaのCIの一部にベンチマークを組み込むところまで持っていけると嬉しいです。multi-objective、制約付き最適化、トライアルのsuspend/resume)のベンチマークにも対応しています。変わった使い方をすれば「solver自体のハイパーパラメータ最適化(solverのproblem化)」や、さらに進んで「複数のproblemに跨って満遍なく良く動作するデフォルトハイパーパラメータの探索」といったメタ最適化的な用途で使用することも可能となっています。ドキュメント作成が追いついてないですが、順次追加予定なので、もし興味を持った方がいればGitHubのREADMEやWikiも参照していただけると幸いです。分散処理、専用ハードウェア、バイオインフォマティクス、ケモインフォマティクスといった幅広い分野で研究開発を行っています。