Successfully reported this slideshow.
Your SlideShare is downloading. ×

最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 63 Ad

最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2

Download to read offline

2022年8月にリリースしたOptunaの最新メジャーバージョンV3の開発の様子、アップデート内容等をご紹介します。

イベントサイト: https://optuna.connpass.com/event/260301/

2022年8月にリリースしたOptunaの最新メジャーバージョンV3の開発の様子、アップデート内容等をご紹介します。

イベントサイト: https://optuna.connpass.com/event/260301/

Advertisement
Advertisement

More Related Content

More from Preferred Networks (20)

Recently uploaded (20)

Advertisement

最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2

  1. 1. 最新リリース: Optuna V3の全て 2022/12/10 Optuna Meetup #2 Hideaki Imamura(GitHub: @HideakiImamura)
  2. 2. 2 Hideaki Imamura / @HideakiImamura ● Preferred Networks, Inc. / リサーチャー ● Optunaコミッター ● Optuna V3の開発をリードしていました ● 大学の頃はベイズ最適化の理論研究をしていました ● GitHub: @HideakiImamura ● Twitter: @mamurai1208
  3. 3. 3 アジェンダ 1. Optuna: A Beginner's Guide 2. Optuna V3の全て 3. Optunaのこれから 主なターゲット ● Optunaに興味がある方 ● Optunaの開発に興味をお持ちの方 ● OSSプロジェクトがどのように進行するのか興味のある方 本発表について
  4. 4. Optuna A Beginner's Guide and Hyperparameter Optimization このセクションはHiroyuki Vincent Yamazakiさんによって PyData Global 2022 Sprintのために作成された資料を日本語訳したものです。
  5. 5. Background of Optuna いかにして開発が始まったか
  6. 6. 2018 Preferred Networks における内製ツールとして開発が始まる Google AI Open Images challenge において利用され2位を達成 β 版がGitHubで公開されオープンソース化する 2019 KDD, ODSC, SciPy (YouTube) などの会議/イベントで発表される 2020 v1.0 - stableな初めてのメジャーリリース v2.0 - 多くの新機能を含んだ2番目のメジャーリリース 2021 v2.10 - 多くの新機能やパフォーマンスの改善がなされる 1日あたり20,000+ ダウンロード … 2022 v3.0 - APIの見直しや様々な新機能を含んだ3番目のメジャーリリース 1日あたり60,000+ ダウンロード
  7. 7. 7 ● コミッターは10人以上 ○ 様々な企業や大学から参加 ● 全部でおよそ200人 の開発者 ○ (GitHub contributors) 開発者コミュニティ
  8. 8. The problem that Optuna is solving ハイパーパラメータ最適化の基礎
  9. 9. 9 モデルの性能を決定づける重要なコンポーネント 例えアルゴリズムやデータが良くても、不適切なハイパーパラメータを用いている とモデルは無意味な結果を出力してしまいます ハイパーパラメータの重要性 Bad 👎 Good 👍
  10. 10. 10 ● 過去の経験に基づいてパラメータを決定する ○ 例: 最適化アルゴリズムの学習率として、論文で初めて提案された値を用 いる ● いくつかの値を比較して決定する ○ ドメイン知識の利用が重要となります ● ハイパーパラメータの存在を全く気にせずチューニングしない ○ 例: ニューラルネットワークの構造 考えられるアプローチ
  11. 11. 11 先ほどのアプローチには最適性の保証がない という問題点があります。 また、探索空間が大きくなると実行不可能となります。 代わりに、ハイパーパラメータの最適化を ブラックボックス最適化問題として 定式化しましょう。 ハイパーパラメータ最適化 ここでいうブラックボックスとは、勾配などが解析的に計算で きず数理最適化の手法では取り扱うことのできない関数のこ とです。
  12. 12. 12 ブラックボックスな目的関数を、ハイパーパラメータ(x)から"良さ"の指標である評 価値(y)への写像として定義します。 我々は、この関数を最小化(または最大化)する適切なハイパーパラメータの値を 効率的に見つけたいです。 ブラックボックス最適化 x. 目的関数 y 探索空間 入力 出力
  13. 13. 13 ● Bad 👎: ○ ハイパーパラメータ (x) が大きすぎると矩形が重なってしまう ○ 小さすぎると再現率が悪化してしまう ● Good 👍:評価値 (y) が最適化されたxに対して高い 先ほどの例を見てみましょう x. 検出器 (ニューラルネット) 訓練および Validation y 入力 出力
  14. 14. Optimize with efficiency Optunaがいかにしてブラックボックス最適化問題を解いているか
  15. 15. 15 Optunaにおける最適化の全体像 最適化アルゴリズム 探索空間 目的関数 ハイパーパラメータ Trial の履歴 … n Trialまで Trial 1 Trial 2 Trial 3
  16. 16. 16 グリッドサーチ: 探索空間全体を均等に分割して探索 ランダムサーチ: ランダムに探索 ベイズ最適化/進化的アルゴリズム: 探索と活用のトレードオフを取りながら、有望そうな領 域を重点的に探索 ● TPE ● Gaussian processes ● CMA-ES ● NSGA-II ● ... いかにして良いハイパーパラメータを見つけるか グリッドサーチ ランダムサーチ ベイズ最適化
  17. 17. 17 Storage studyを保存し永続化するための抽象化 Study 一連のTrialを含む、一回の実験の単位 Trial 目的関数の一回の評価の単位 Sampler 最適化アルゴリズム Pruner 最適化効率を改善するために用いられる。性能が低いと予想されるTrialの評価を途中で打ち切るためのもの Optunaの用語 Storage Database (or other backend) Study Sampler Pruner Trial(s) Study Sampler Pruner Trial(s)
  18. 18. 18 一つのハイパーパラメータがどのように選ばれるか 探索空間がSamplerに伝 えられます Trial Study Storage Sampler StorageからSamplerに Trialの履歴が与えられ ます Samplerによってハイ パーパラメータが提案さ れます 目的関数の評価値が計算 され、Storageに報告さ れます 1 2 3 4 Database (or other backend)
  19. 19. Optimize with minimum code
  20. 20. 20 インストール方法 pip install optuna
  21. 21. 21 import optuna study: optuna.Study = optuna.create_study( study_name="my-study", sampler=optuna.samplers.TPESampler(), pruner=optuna.pruners.MedianPruner(), storage="sqlite:///my-storage.db", # RDB file が自動的に作られます direction="maximize", load_if_exists=True, ) Studyの作成 API リファレンスを見るには クリックしてみてください📝
  22. 22. 22 探索空間と目的関数の定義 def objective(trial: optuna.Trial) -> float: # 探索空間の定義です。 Pythonの条件分岐やforループを使うことができます。 iou_thresh = trial.suggest_float("iou_thresh", 0, 1) opt = trial.suggest_categorical("opt", ["SGD", "Adam"]) n_layers = trial.suggest_int("n_layers", 2, 5) n_channels = [ trial.suggest_int(f"n_channels_{i}", 32, 256) for i in range(n_layers) ] ... # 目的関数です。モデルの訓練と評価を行います。 ap = train_and_val(iou_thresh, opt, n_layers, n_channels, ...) return ap
  23. 23. 23 最適化の実行 study.optimize(objective, n_trials=50) # [I 2021-06-14 14:17:41,256] A new study created in RDB with name: my-study # [I 2021-06-14 14:31:09,376] Trial 0 finished with value: 0.4808... # [I 2021-06-14 14:46:23,466] Trial 1 finished with value: 0.3574... # [I 2021-06-14 15:01:29,615] Trial 2 finished with value: 0.5250... # … # 結果を分析することができます len(study.trials) # == 50 best_trial = study.best_trial best_params = best_trial.params # Or, study.best_params. # {'iou_thresh': 0.34907190168024279, ...}
  24. 24. 24 分散最適化 $ python optimize.py [I 2021-06-14 16:53:04,039] A new study created in RDB with name: my-study [I 2021-06-14 17:08:04,775] Trial 0 finished with... [I 2021-06-14 17:27:43,012] Trial 2 finished with... [I 2021-06-14 17:59:12,598] Trial 3 finished with... [I 2021-06-14 18:14:55,981] Trial 6 finished with... $ python optimize.py [I 2021-06-14 16:53:04,580] Using an existing study with name 'my-study' instead of creating a new one. [I 2021-06-14 17:31:35,011] Trial 1 finished with... [I 2021-06-14 17:40:02,211] Trial 4 finished with... [I 2021-06-14 18:01:43,645] Trial 5 finished with... [I 2021-06-14 18:17:59,447] Trial 7 finished with... ターミナル B ターミナル A
  25. 25. 25 分析 Web GUI $ optuna-dashboard sqlite:///my-storage.db ... Listening on http://localhost:8080/ https://github.com/optuna/optuna-dashboard Python API optuna.visualization.plot_...(study).show() https://optuna.readthedocs.io/en/v2.8.0/reference/visualization/index.html
  26. 26. 26 ● 多目的最適化・制約付き最適化 ○ 目的関数の出力が多次元であったり、探索空間や出力に制約がある場 合も扱えます。 ● Ask-and-tell API ○ Study.optimizeとは違って、ユーザ自身でTrialのループを作ることができ ます。 ○ ハイパーパラメータの選択と目的関数の評価が別プロセスである場合な ど、複雑なワークフローに対応可能です。 ● インテグレーションユーティリティ(PyTorch,Tensorflow,LightGBMなど) ● Pythonなしで利用するためのCLI ● 豊富な公式のExample集 ● ドキュメント ● … 他にも様々な機能が...
  27. 27. Release cycles of Optuna その他、互換性についてのポリシーなど
  28. 28. 28 バージョニングと互換性 3.0.4(2022年12月時点の最新版) ● Major ○ 破壊的変更あり ● Minor ○ 性能強化・新機能・バグ修正など数ヶ 月に一度のペースでリリース ● Patch ○ クリティカルなバグ修正 Operated according to Semantic Versioning 2.0.0 https://semver.org/ ● Deprecation ○ ユーザーに影響しうる機能の削除は注意 深く行われています。基本的にメジャー バージョンを丸々一つ跨いで非推奨期間 が設定されます。 ● Experimental ○ 実験的な機能が頻繁に追加されます。利 用する際は警告が発せられ、非推奨期間 なしで変更/削除される可能性がありま す。
  29. 29. Optuna V3の全て 我々がどのように開発を行い、 何を成功させ、何に失敗したか
  30. 30. 30 どのように開発を行なったか
  31. 31. 31 Optunaの3番目のメジャーバージョン およそ1年にわたって開発が行われたOptuna初の長期プロジェクトで、 全部で67名のコントリビュータが開発に参加しました。 Goals ● コミュニティに向けて開発方針をオープンに ○ ロードマップを公開し、GitHub issue上で開発アイテムについて議論する ● ソフトウェアとして安定性を高める ○ 仕様が曖昧な部分を大幅に削減する ○ 実験的に導入されていた機能を安定した機能としてリリースして良いか判断す る ● 重要な機能やアルゴリズムを全てのユーザに届ける ○ デフォルトの機能のパフォーマンスを改善する ○ 既存の重要な機能やアルゴリズムをライトユーザが利用できるようにする(多 変量TPE, constant liar戦略など) Optuna V3とは
  32. 32. 32 プロジェクトのタイムライン 2021/07 ロードマップの策定がコミッター内で始まる 2021/10 ロードマップをGitHubに公開し開発がスタート 初めての公開オンラインスプリントを実施 (その後、2022/04まで定期的に オンラインスプリントを実施) 2021/12 α版として、v3.0.0-α0をリリース 2022/02 α版として、v3.0.0-α1をリリース 2022/04 β版として、v3.0.0-β0をリリース 第6回オンラインスプリントを実施 2022/06 β版として、v3.0.0-β1をリリース 2022/08 release candidate版として、v3.0.0-rc0をリリース 正式版として、v3.0.0をリリース (その後、クリティカルなバグに対応してパッチを随時リリース)
  33. 33. 33 プロジェクトのタイムライン 2021/07 ロードマップの策定がコミッター内で始まる 2021/10 ロードマップをGitHubに公開し開発がスタート 初めての公開オンラインスプリントを実施 (その後、2022/04まで定期的に オンラインスプリントを実施) 2021/12 α版として、v3.0.0-α0をリリース 2022/02 α版として、v3.0.0-α1をリリース 2022/04 β版として、v3.0.0-β0をリリース 第6回オンラインスプリントを実施 2022/06 β版として、v3.0.0-β1をリリース 2022/08 release candidate版として、v3.0.0-rc0をリリース 正式版として、v3.0.0をリリース (その後、クリティカルなバグに対応してパッチを随時リリース) フェーズ1: ● ロードマップを策定しIssueを整備した ● コントリビュータが参加しやすい体制づ くりを行った フェーズ2: ● 多数の開発者によって多数の開発アイテ ムが高速に消化された ● 仕様の曖昧なIssueに対する継続的な議論 がコミッター内で行われた フェーズ3: ● コントリビュータが取り組みにくい残ア イテムに対してコミッターが中心となり 集中的に開発を行なった
  34. 34. 34 Optuna V3ロードマップ コントリビュータが開発に参加しやすくするため ロードマップをコミッター内で議論して策定しました。 ● V3で取り組むべきアイテムの列挙 ● アイテムの仕様の明確化(可能な限り) ● 対応するIssueの作成 ● 対応する開発アイテムごとに ○ なぜ取り組むのか ○ 完了したとみなせる基準は何か ○ を議論し、文書化しました。 ロードマップ策定開始から公開まで、およそ2ヶ月半ほどかかりました。 フェーズ1: ロードマップの策定と開発者の獲得
  35. 35. 35 より開発に参加しやすい体制づくりのため ● 定期的なオンラインスプリントの実施 (Optuna connpass ページ) ● 定期的なプレリリースによる開発状況 の周知 を行うことを決めました。 特に開発イベントは好評だったため、今後 も継続的に行なっていきます! フェーズ1: ロードマップの策定と開発者の獲得
  36. 36. 36 この時期は多数の開発者によって多くの開発アイテムが消化されました。 コントリビュータが取り組みやすいアイテムの特徴 ● 仕様が明確である ● 独立したモジュールのみを修正すれば十分である → 毎週コミッター内で議論を行い、仕様の曖昧なIssueの明確化や複雑な Issueの分解を行うことに フェーズ2:多数の開発者による高速な開発
  37. 37. 37 この時期になると開発の速度が鈍ってくるようになりました。 コントリビュータが取り組みやすいIssueが枯渇してきたからです。 そこで ● 定期的に実施していたオンラインスプリントを停止 ● コミッターによるスクラム開発の開始 ○ バックログの整備(Google spread sheetを用いました) ○ 1週間単位のスプリントを設定 ○ プランニングポーカーの実施によって残アイテムの粒度をコミッ ター内で確認し共有 フェーズ3:コミッターによる集中的な開発
  38. 38. 38 Released! (2022/08/29)
  39. 39. 39 何を成功させたか
  40. 40. 40 ● 安定性の改善: API単純化・安定化・リファクタリング ● パフォーマンス検証: 大規模なアルゴリズムベンチマーキング ● 予定よりも多くの様々な新機能 何を成功させたか
  41. 41. 41 探索空間からパラメータを選択するメソッドが以下の3種類に集約されまし た # 実数値変数 trial.suggest_float(name, low, high, *, step, log) # 整数値変数 trial.suggest_int(name, low, high, *, step, log) # カテゴリカル値変数 trial.suggest_categorical(name, choices) Thanks @himkt, @nyanhi, @nzw0301, and @xadrianzetx! 安定性の改善: Suggest APIの単純化
  42. 42. 42 Optunaのテストがどのように行われ るべきかをまとめて、Test Policyを 策定し公開しました。また、定めた Test policyに基づいてテストを修正し ました。 Thanks @HideakiImamura, @c-bata, @g-votte, @not522, @toshihikoyanase, @contramundum53, @nzw0301, @keisuke-umezawa, @knshnb! 安定性の改善: Test policyの作成
  43. 43. 43 仕様の明確化・バグフィックス・ユースケース分析などを通して、いくつか のexperimentalな機能を安定化させました ● optuna.study.MaxTrialsCallback ● optuna.study.Study.enqueue_trial ● optuna.study.Study.add_trial ● optuna.study.Study.add_trials ● optuna.study.copy_study ● optuna.trial.create_trial ● optuna.visualization.plot_pareto_front Thanks @contramundum53, @knshnb, @HideakiImamura, and @himkt! 安定性の改善: 機能の安定化
  44. 44. 44 PlotlyバックエンドとMatplotlibバックエンドが別々に開発されていた可視 化モジュールは、片方にある機能がもう片方になかったり、フォーマットに 統一性がなかったり、内部実装の差異が大きかったりという問題を抱えてい ました。 → 機能的な差異の解消・内部実装の共通化・テスト戦略の改善などを実施 Thanks @HideakiImamura, @IEP, @MasahitoKumada, @TakuyaInoue-github, @akawashiro, @belldandyxtq, @c-bata, @contramundum53, @divyanshugit, @dubey-anshuman, @fukatani, @harupy, @himkt, @kasparthommen, @keisukefukuda, @knshnb, @makinzm, @nzw0301, @semiexp, @shu65, @sidshrivastav, @takoika, @xadrianzetx! 安定性の改善: 可視化モジュールのリファクタリング
  45. 45. 45 経験的に知られていたアルゴリズムの振る舞いやOptunaにおける実装の特 徴をまとめてSampler比較表として公開しました パフォーマンス検証: 定性的な分析
  46. 46. 46 実験の再現性のためGitHub Actionsを用いるベンチマーク環境を整備しま した。 ● ローカル環境で実行可能なスクリプト ● スクリプトをGitHub Actionsで動かす仕組み ● 機械学習のハイパーパラメータ最適化や最適化分野のおける有名なテス ト関数を含む170種類以上の問題 Thanks @HideakiImamura, @drumehiron, @xadrianzetx, @kei-mo, @contramundum53, @shu65! パフォーマンス検証: ベンチマーク環境の整備 from https://www.sfu.ca/~ssurjano/branin.html
  47. 47. 47 Motivations ● アルゴリズムのフェアな比較 ● デフォルト引数/アルゴリズムの変更 Settings ● 30組以上のsamplerとprunerの組み合わせ ● 170種類以上のproblem ● 1000trialを100study ● PFNの計算クラスタを用いて7000CPU並列 で3日程度かけて実験 Results 詳細はIssue #2964 や #2906 全ての設定で優れているアルゴリズムはありませんでした。 → デフォルトは変更しないと結論 パフォーマンス検証: ベンチマーク実験の実施
  48. 48. 48 V3の開発当初では想定していなかった多くの新機能がコントリビュータの 協力によって導入されました。 ● NSGA-IIの交叉オプション ● 準モンテカルロ法 ● パレートフロント可視化の制約付き最適化サポート ● Shapley重要度評価器 ● TPEの制約付き最適化サポート ● 複数のStudyを同時に考慮した最適化履歴の可視化 様々な新機能
  49. 49. 49 NSGA-IIとは ● 遺伝的アルゴリズム ● 多目的最適化向け ● NSGAIISamplerとして実装 目的 実数値変数に対する性能向上 結果 ● crossover 引数の追加 ● 関連ドキュメント NSGA-IIの交叉オプション Thanks @yoshinobc and @xadrianzetx!
  50. 50. 50 準モンテカルロ法とは ● 高次元の問題で強い ● 探索空間を比較的少数のサンプルでカバーできる ● ランダムサーチの代わりとなりうる 結果 ● QMCSamplerとして実装 ● 特に高次元の問題でランダムサーチ を凌駕 準モンテカルロ法 Thanks @kstoneriv3!
  51. 51. 51 パレートフロント可視化とは ● 多目的最適化における可視化手法で、plot_pareto_frontとして実装 ● "これ以上全目的関数値を同時によくすることはできない"というTrials 目的 ● 制約を満たすTrialと満たさないTrial を区別したい 結果 ● constraints_func 引数の追加 パレートフロント可視化の制約付き最適化サポート 制約を満たす(色あり) 制約を満たさない(色なし) Thanks @semiexp and @fukatani!
  52. 52. 52 変数重要度評価機能とは ● 最適化後にどの変数が重要だったかを分析する機能 ● FanovaImportanceEvaluatorと MeanDecreaseImpurityImportanceEvaluatorが存在 目的 ● 機械学習コミュニティで有名なSHAPライブラリ に基づく全く新しい重要度評価器の実装 結果 ● ShapleyImportanceEvaluatorとして実装 ● optuna.integrations下にあるのでご注意を Shapley重要度評価手法 Thanks @liaison!
  53. 53. 53 TPEとは ● OptunaのデフォルトSampler ● TPESamplerとして実装 TPEの制約付き最適化サポート 結果 ● constraints_func引数の追加 ● 利用例 Thanks @knshnb!
  54. 54. 54 最適化履歴の可視化とは ● 横軸にTrial、縦軸に目的関数値をとったグラフ ● plot_optimization_historyとして実装 目的 ● 複数のStudyどうしを比較したい ● 同一設定の複数のStudyの平均と分散を 分析したい 結果 ● studyのリストが渡せるように ● error_bar引数の追加 複数のStudyを同時に考慮した最適化履歴の可視化 Thanks @knshnb, @TakuyaInoue-github, and @HideakiImamura!
  55. 55. 55 何に失敗したか
  56. 56. 56 V3の開発を進めて行く中で生じたいくつかの失敗についてお話しします。 開発体制についての難しさ ● 開発ペースの非一様性 ● コミュニケーションの非対称性 開発アイテム個別の事情による失敗 ● Storage関連アイテムの延期 ● デフォルト引数/アルゴリズム変更の延期 何に失敗したか
  57. 57. 57 V3開発をはじめた当初は開発アイテムの方針も含めてGitHub Issue上で広 くユーザ/コントリビュータの意見を集めて決めていこうと考えていました しかし、OSS特有の事情として以下がありました ● 開発ペースの非一様性 ○ コントリビュータがいつどのタイミングで開発に参加するか、予測 することは難しい ○ 開発に参加してくれるコントリビュータは多様なバックグラウンド を持っている ● コミュニケーションの非対称性 ○ 比較的頻繁に議論し合えるコミッターと、モチベーションベースで 開発に関わるコントリビュータのバランスを取ることは難しい 開発体制についての難しさ
  58. 58. 58 V3ではStorageの様々な仕様を明確にして修正を行うことを目指しました。 しかし、 ● 現状のStorage APIがあまりに複雑 ● Storage APIの互換性に関するポリシーが曖昧 ● スケジュールの関係上、大規模なリファクタリングは困難 といった事情から、V3ではいくつかのStorage関連アイテムは延期すること にしました。 一方で、我々はユーザがStorageを直接触ることはないと考え、V3リリース 後も以下を進めています ● Storage APIの単純化 ● 一部機能の切り出しなど部分的なリファクタリング Storage関連アイテムの延期
  59. 59. 59 V3では大規模なアルゴリズムベンチマークを通して、デフォルト引数/アル ゴリズムの変更を計画していました。 しかし、 ● ベンチマーク問題はOptunaが適用可能な全ての設定を包含していない ● 得られた結果からは、引数/アルゴリズムごとに得意な設定と苦手な設 定がある ● デフォルトの変更によって影響を受けるユーザは非常に多い ● デフォルトを変更するにあたってのポリシーが曖昧 といった事情から、V3ではデフォルトを変更しないこととしました。 デフォルト変更は、今後のメジャーバージョン(V4, V5など)で行うことにし ました。 デフォルト引数/アルゴリズム変更の延期
  60. 60. Optunaのこれから 今後のリリースと開発体制について
  61. 61. 61 v3.1 Coming Soon (mid Jan, 2023) 👇 Optuna v3.1 の主要開発項目 操作ログベースのStorage "値"ではなく"操作"を保存する全く新しいStorage: JournalStorage CMA-ES with Margin 整数変数の含まれた探索空間に対して高い性能を発揮するCMA-ESの亜種 TPE のパフォーマンス改善 アルゴリズムの分析とベンチマーク実験に基づいて、constant_liarオプ ションのバグを修正
  62. 62. We are looking for OSS contributors! GitHub https://github.com/optuna/optuna Twitter https://twitter.com/OptunaAutoML optuna.org https://optuna.org/ Medium https://medium.com/optuna Step-by-step Guide https://medium.com/optuna/optuna-wants-your-pull-request-ff6195 72302c Gitter https://gitter.im/optuna/optuna
  63. 63. Making the real world computable

×