1.
最新リリース:
Optuna V3の全て
2022/12/10 Optuna Meetup #2
Hideaki Imamura（GitHub: @HideakiImamura）

2.
2
Hideaki Imamura / @HideakiImamura
● Preferred Networks, Inc. / リサーチャー
● Optunaコミッター
● Optuna V3の開発をリードしていました
● 大学の頃はベイズ最適化の理論研究をしていました
● GitHub: @HideakiImamura
● Twitter: @mamurai1208

3.
3
アジェンダ
1. Optuna: A Beginner's Guide
2. Optuna V3の全て
3. Optunaのこれから
主なターゲット
● Optunaに興味がある方
● Optunaの開発に興味をお持ちの方
● OSSプロジェクトがどのように進行するのか興味のある方
本発表について

4.
Optuna
A Beginner's Guide
and Hyperparameter Optimization
このセクションはHiroyuki Vincent Yamazakiさんによって
PyData Global 2022 Sprintのために作成された資料を日本語訳したものです。

5.
Background of Optuna
いかにして開発が始まったか

6.
2018
Preferred Networks における内製ツールとして開発が始まる
Google AI Open Images challenge において利用され2位を達成
β 版がGitHubで公開されオープンソース化する
2019
KDD, ODSC, SciPy (YouTube) などの会議/イベントで発表される
2020
v1.0 - stableな初めてのメジャーリリース
v2.0 - 多くの新機能を含んだ２番目のメジャーリリース
2021
v2.10 - 多くの新機能やパフォーマンスの改善がなされる
１日あたり20,000+ ダウンロード
…
2022
v3.0 - APIの見直しや様々な新機能を含んだ３番目のメジャーリリース
１日あたり60,000+ ダウンロード

7.
7
● コミッターは10人以上
○ 様々な企業や大学から参加
● 全部でおよそ200人 の開発者
○ (GitHub contributors)
開発者コミュニティ

8.
The problem that Optuna is solving
ハイパーパラメータ最適化の基礎

9.
9
モデルの性能を決定づける重要なコンポーネント
例えアルゴリズムやデータが良くても、不適切なハイパーパラメータを用いている
とモデルは無意味な結果を出力してしまいます
ハイパーパラメータの重要性
Bad
👎
Good
👍

10.
10
● 過去の経験に基づいてパラメータを決定する
○ 例: 最適化アルゴリズムの学習率として、論文で初めて提案された値を用
いる
● いくつかの値を比較して決定する
○ ドメイン知識の利用が重要となります
● ハイパーパラメータの存在を全く気にせずチューニングしない
○ 例: ニューラルネットワークの構造
考えられるアプローチ

11.
11
先ほどのアプローチには最適性の保証がない
という問題点があります。
また、探索空間が大きくなると実行不可能となります。
代わりに、ハイパーパラメータの最適化を
ブラックボックス最適化問題として
定式化しましょう。
ハイパーパラメータ最適化
ここでいうブラックボックスとは、勾配などが解析的に計算で
きず数理最適化の手法では取り扱うことのできない関数のこ
とです。

12.
12
ブラックボックスな目的関数を、ハイパーパラメータ(x)から"良さ"の指標である評
価値(y)への写像として定義します。
我々は、この関数を最小化(または最大化)する適切なハイパーパラメータの値を
効率的に見つけたいです。
ブラックボックス最適化
x. 目的関数 y
探索空間
入力 出力

13.
13
● Bad 👎:
○ ハイパーパラメータ (x) が大きすぎると矩形が重なってしまう
○ 小さすぎると再現率が悪化してしまう
● Good 👍：評価値 (y) が最適化されたxに対して高い
先ほどの例を見てみましょう
x.
検出器
(ニューラルネット)
訓練および
Validation
y
入力 出力

14.
Optimize with efficiency
Optunaがいかにしてブラックボックス最適化問題を解いているか

15.
15
Optunaにおける最適化の全体像
最適化アルゴリズム
探索空間
目的関数
ハイパーパラメータ
Trial
の履歴
…
n Trialまで
Trial 1 Trial 2 Trial 3

16.
16
グリッドサーチ: 探索空間全体を均等に分割して探索
ランダムサーチ: ランダムに探索
ベイズ最適化/進化的アルゴリズム: 探索と活用のトレードオフを取りながら、有望そうな領
域を重点的に探索
● TPE
● Gaussian processes
● CMA-ES
● NSGA-II
● ...
いかにして良いハイパーパラメータを見つけるか
グリッドサーチ ランダムサーチ ベイズ最適化

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
一つのハイパーパラメータがどのように選ばれるか
探索空間がSamplerに伝
えられます
Trial Study Storage
Sampler
StorageからSamplerに
Trialの履歴が与えられ
ます
Samplerによってハイ
パーパラメータが提案さ
れます
目的関数の評価値が計算
され、Storageに報告さ
れます
1 2
3 4
Database
(or other backend)

19.
Optimize with minimum code

20.
20
インストール方法
pip install optuna

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
探索空間と目的関数の定義
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
最適化の実行
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
分散最適化
$ 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
分析
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
● 多目的最適化・制約付き最適化
○ 目的関数の出力が多次元であったり、探索空間や出力に制約がある場
合も扱えます。
● Ask-and-tell API
○ Study.optimizeとは違って、ユーザ自身でTrialのループを作ることができ
ます。
○ ハイパーパラメータの選択と目的関数の評価が別プロセスである場合な
ど、複雑なワークフローに対応可能です。
● インテグレーションユーティリティ(PyTorch,Tensorflow,LightGBMなど)
● Pythonなしで利用するためのCLI
● 豊富な公式のExample集
● ドキュメント
● …
他にも様々な機能が...

27.
Release cycles of Optuna
その他、互換性についてのポリシーなど

28.
28
バージョニングと互換性
3.0.4(2022年12月時点の最新版)
● Major
○ 破壊的変更あり
● Minor
○ 性能強化・新機能・バグ修正など数ヶ
月に一度のペースでリリース
● Patch
○ クリティカルなバグ修正
Operated according to
Semantic Versioning 2.0.0 https://semver.org/
● Deprecation
○ ユーザーに影響しうる機能の削除は注意
深く行われています。基本的にメジャー
バージョンを丸々一つ跨いで非推奨期間
が設定されます。
● Experimental
○ 実験的な機能が頻繁に追加されます。利
用する際は警告が発せられ、非推奨期間
なしで変更/削除される可能性がありま
す。

29.
Optuna V3の全て
我々がどのように開発を行い、
何を成功させ、何に失敗したか

30.
30
どのように開発を行なったか

31.
31
Optunaの３番目のメジャーバージョン
およそ1年にわたって開発が行われたOptuna初の長期プロジェクトで、
全部で６７名のコントリビュータが開発に参加しました。
Goals
● コミュニティに向けて開発方針をオープンに
○ ロードマップを公開し、GitHub issue上で開発アイテムについて議論する
● ソフトウェアとして安定性を高める
○ 仕様が曖昧な部分を大幅に削減する
○ 実験的に導入されていた機能を安定した機能としてリリースして良いか判断す
る
● 重要な機能やアルゴリズムを全てのユーザに届ける
○ デフォルトの機能のパフォーマンスを改善する
○ 既存の重要な機能やアルゴリズムをライトユーザが利用できるようにする（多
変量TPE, constant liar戦略など）
Optuna V3とは

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をリリース
第６回オンラインスプリントを実施
2022/06
β版として、v3.0.0-β1をリリース
2022/08
release candidate版として、v3.0.0-rc0をリリース
正式版として、v3.0.0をリリース
(その後、クリティカルなバグに対応してパッチを随時リリース)

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をリリース
第６回オンラインスプリントを実施
2022/06
β版として、v3.0.0-β1をリリース
2022/08
release candidate版として、v3.0.0-rc0をリリース
正式版として、v3.0.0をリリース
(その後、クリティカルなバグに対応してパッチを随時リリース)
フェーズ１:
● ロードマップを策定しIssueを整備した
● コントリビュータが参加しやすい体制づ
くりを行った
フェーズ２:
● 多数の開発者によって多数の開発アイテ
ムが高速に消化された
● 仕様の曖昧なIssueに対する継続的な議論
がコミッター内で行われた
フェーズ３:
● コントリビュータが取り組みにくい残ア
イテムに対してコミッターが中心となり
集中的に開発を行なった

34.
34
Optuna V3ロードマップ
コントリビュータが開発に参加しやすくするため
ロードマップをコミッター内で議論して策定しました。
● V3で取り組むべきアイテムの列挙
● アイテムの仕様の明確化（可能な限り）
● 対応するIssueの作成
● 対応する開発アイテムごとに
○ なぜ取り組むのか
○ 完了したとみなせる基準は何か
○ を議論し、文書化しました。
ロードマップ策定開始から公開まで、およそ２ヶ月半ほどかかりました。
フェーズ１: ロードマップの策定と開発者の獲得

35.
35
より開発に参加しやすい体制づくりのため
● 定期的なオンラインスプリントの実施
(Optuna connpass ページ)
● 定期的なプレリリースによる開発状況
の周知
を行うことを決めました。
特に開発イベントは好評だったため、今後
も継続的に行なっていきます！
フェーズ１: ロードマップの策定と開発者の獲得

36.
36
この時期は多数の開発者によって多くの開発アイテムが消化されました。
コントリビュータが取り組みやすいアイテムの特徴
● 仕様が明確である
● 独立したモジュールのみを修正すれば十分である
→ 毎週コミッター内で議論を行い、仕様の曖昧なIssueの明確化や複雑な
Issueの分解を行うことに
フェーズ２：多数の開発者による高速な開発

37.
37
この時期になると開発の速度が鈍ってくるようになりました。
コントリビュータが取り組みやすいIssueが枯渇してきたからです。
そこで
● 定期的に実施していたオンラインスプリントを停止
● コミッターによるスクラム開発の開始
○ バックログの整備（Google spread sheetを用いました）
○ １週間単位のスプリントを設定
○ プランニングポーカーの実施によって残アイテムの粒度をコミッ
ター内で確認し共有
フェーズ3：コミッターによる集中的な開発

38.
38
Released! (2022/08/29)

39.
39
何を成功させたか

40.
40
● 安定性の改善: API単純化・安定化・リファクタリング
● パフォーマンス検証: 大規模なアルゴリズムベンチマーキング
● 予定よりも多くの様々な新機能
何を成功させたか

41.
41
探索空間からパラメータを選択するメソッドが以下の３種類に集約されまし
た
# 実数値変数
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
Optunaのテストがどのように行われ
るべきかをまとめて、Test Policyを
策定し公開しました。また、定めた
Test policyに基づいてテストを修正し
ました。
Thanks @HideakiImamura, @c-bata, @g-votte,
@not522, @toshihikoyanase, @contramundum53,
@nzw0301, @keisuke-umezawa, @knshnb!
安定性の改善: Test policyの作成

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
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
経験的に知られていたアルゴリズムの振る舞いやOptunaにおける実装の特
徴をまとめてSampler比較表として公開しました
パフォーマンス検証: 定性的な分析

46.
46
実験の再現性のためGitHub Actionsを用いるベンチマーク環境を整備しま
した。
● ローカル環境で実行可能なスクリプト
● スクリプトをGitHub Actionsで動かす仕組み
● 機械学習のハイパーパラメータ最適化や最適化分野のおける有名なテス
ト関数を含む１７０種類以上の問題
Thanks @HideakiImamura, @drumehiron, @xadrianzetx, @kei-mo, @contramundum53, @shu65!
パフォーマンス検証: ベンチマーク環境の整備
from https://www.sfu.ca/~ssurjano/branin.html

47.
47
Motivations
● アルゴリズムのフェアな比較
● デフォルト引数/アルゴリズムの変更
Settings
● 30組以上のsamplerとprunerの組み合わせ
● 170種類以上のproblem
● 1000trialを100study
● PFNの計算クラスタを用いて7000CPU並列
で3日程度かけて実験
Results
詳細はIssue #2964 や #2906
全ての設定で優れているアルゴリズムはありませんでした。
→ デフォルトは変更しないと結論
パフォーマンス検証: ベンチマーク実験の実施

48.
48
V3の開発当初では想定していなかった多くの新機能がコントリビュータの
協力によって導入されました。
● NSGA-IIの交叉オプション
● 準モンテカルロ法
● パレートフロント可視化の制約付き最適化サポート
● Shapley重要度評価器
● TPEの制約付き最適化サポート
● 複数のStudyを同時に考慮した最適化履歴の可視化
様々な新機能

49.
49
NSGA-IIとは
● 遺伝的アルゴリズム
● 多目的最適化向け
● NSGAIISamplerとして実装
目的
実数値変数に対する性能向上
結果
● crossover 引数の追加
● 関連ドキュメント
NSGA-IIの交叉オプション
Thanks @yoshinobc and @xadrianzetx!

50.
50
準モンテカルロ法とは
● 高次元の問題で強い
● 探索空間を比較的少数のサンプルでカバーできる
● ランダムサーチの代わりとなりうる
結果
● QMCSamplerとして実装
● 特に高次元の問題でランダムサーチ
を凌駕
準モンテカルロ法
Thanks @kstoneriv3!

51.
51
パレートフロント可視化とは
● 多目的最適化における可視化手法で、plot_pareto_frontとして実装
● "これ以上全目的関数値を同時によくすることはできない"というTrials
目的
● 制約を満たすTrialと満たさないTrial
を区別したい
結果
● constraints_func 引数の追加
パレートフロント可視化の制約付き最適化サポート
制約を満たす（色あり）
制約を満たさない（色なし）
Thanks @semiexp and @fukatani!

52.
52
変数重要度評価機能とは
● 最適化後にどの変数が重要だったかを分析する機能
● FanovaImportanceEvaluatorと
MeanDecreaseImpurityImportanceEvaluatorが存在
目的
● 機械学習コミュニティで有名なSHAPライブラリ
に基づく全く新しい重要度評価器の実装
結果
● ShapleyImportanceEvaluatorとして実装
● optuna.integrations下にあるのでご注意を
Shapley重要度評価手法
Thanks @liaison!

53.
53
TPEとは
● OptunaのデフォルトSampler
● TPESamplerとして実装
TPEの制約付き最適化サポート
結果
● constraints_func引数の追加
● 利用例
Thanks @knshnb!

54.
54
最適化履歴の可視化とは
● 横軸にTrial、縦軸に目的関数値をとったグラフ
● plot_optimization_historyとして実装
目的
● 複数のStudyどうしを比較したい
● 同一設定の複数のStudyの平均と分散を
分析したい
結果
● studyのリストが渡せるように
● error_bar引数の追加
複数のStudyを同時に考慮した最適化履歴の可視化
Thanks @knshnb, @TakuyaInoue-github, and @HideakiImamura!

55.
55
何に失敗したか

56.
56
V3の開発を進めて行く中で生じたいくつかの失敗についてお話しします。
開発体制についての難しさ
● 開発ペースの非一様性
● コミュニケーションの非対称性
開発アイテム個別の事情による失敗
● Storage関連アイテムの延期
● デフォルト引数/アルゴリズム変更の延期
何に失敗したか

57.
57
V3開発をはじめた当初は開発アイテムの方針も含めてGitHub Issue上で広
くユーザ/コントリビュータの意見を集めて決めていこうと考えていました
しかし、OSS特有の事情として以下がありました
● 開発ペースの非一様性
○ コントリビュータがいつどのタイミングで開発に参加するか、予測
することは難しい
○ 開発に参加してくれるコントリビュータは多様なバックグラウンド
を持っている
● コミュニケーションの非対称性
○ 比較的頻繁に議論し合えるコミッターと、モチベーションベースで
開発に関わるコントリビュータのバランスを取ることは難しい
開発体制についての難しさ

58.
58
V3ではStorageの様々な仕様を明確にして修正を行うことを目指しました。
しかし、
● 現状のStorage APIがあまりに複雑
● Storage APIの互換性に関するポリシーが曖昧
● スケジュールの関係上、大規模なリファクタリングは困難
といった事情から、V3ではいくつかのStorage関連アイテムは延期すること
にしました。
一方で、我々はユーザがStorageを直接触ることはないと考え、V3リリース
後も以下を進めています
● Storage APIの単純化
● 一部機能の切り出しなど部分的なリファクタリング
Storage関連アイテムの延期

59.
59
V3では大規模なアルゴリズムベンチマークを通して、デフォルト引数/アル
ゴリズムの変更を計画していました。
しかし、
● ベンチマーク問題はOptunaが適用可能な全ての設定を包含していない
● 得られた結果からは、引数/アルゴリズムごとに得意な設定と苦手な設
定がある
● デフォルトの変更によって影響を受けるユーザは非常に多い
● デフォルトを変更するにあたってのポリシーが曖昧
といった事情から、V3ではデフォルトを変更しないこととしました。
デフォルト変更は、今後のメジャーバージョン(V4, V5など)で行うことにし
ました。
デフォルト引数/アルゴリズム変更の延期

60.
Optunaのこれから
今後のリリースと開発体制について

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.
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.
Making the real world computable