Google
Cloud Platform
Amazon Web Services
Microsoft AzureHyperopt のベスト プラクティスとトラブルシューティング
注：
Hyperoptのオープンソース バージョンはメンテナンスされなくなりました。
Hyperopt は、Databricks Runtime ML 17.0 以降にプレインストールされなくなります。 Databricks 、同様のエクスペリエンスと最新のハイパーパラメーターチューニングアルゴリズムへのアクセスのために、代わりに Optuna を使用することをお勧めします。
おすすめの方法
ベイジアンのアプローチは、グリッド検索やランダム検索よりもはるかに効率的です。 したがって、パルゼン推定量の Hyperopt Tree of Parzen Estimators (TPE) アルゴリズムを使用すると、より多くのハイパーパラメータとより広い範囲を探索できます。 ドメイン知識を使用して検索ドメインを制限すると、チューニングを最適化し、より良い結果を得ることができます。
hp.choice()を使用すると、Hyperopt は選択リストのインデックスを返します。したがって、MLflow に記録されるパラメーターはインデックスでもあります。 パラメーター値を取得するには、hyperopt.space_eval()を使用します。トレーニング時間が長いモデルの場合は、小さなデータセットと多くのハイパーパラメーターを使用してエクスペリメントを開始します。 MLflow を使用して、最もパフォーマンスの高いモデルを特定し、修正できるハイパーパラメーターを決定します。 このようにして、大規模なチューニングの準備をするときにパラメーター領域を減らすことができます。
条件付きディメンションとハイパーパラメータに対する Hyperopt サポートを活用します。 たとえば、勾配降下の複数のフレーバーを評価する場合、ハイパーパラメータ空間を一般的なハイパーパラメータだけに制限するのではなく、Hyperopt に条件付きハイパーパラメータ (フレーバーのサブセットにのみ適切なハイパーパラメータ) を含めることができます。 条件付きパラメーターの使用について詳しくは、 サーチ・スペースの定義を参照してください。
SparkTrialsを使用する場合は、CPU のみのクラスターと GPU 対応のクラスターに対して並列処理を適切に構成します。Databricks では、CPU クラスターと GPU クラスターは、ワーカー ノードごとに異なる数のエグゼキューター スレッドを使用します。 CPU クラスターは、ノードごとに複数のエグゼキューター スレッドを使用します。 GPU クラスターは、ノードごとに 1 つのエグゼキューター スレッドのみを使用して、同じ GPU を使用しようとする複数の Spark タスク間の競合を回避します。 これは一般的に GPU 用に記述されたライブラリに最適ですが、GPU クラスターでは最大並列処理が減少するため、GPU インスタンスタイプを選択するときは、各トライアルで使用できる GPU の数に注意してください。 詳細については、「 GPU 対応クラスター 」を参照してください。オートスケール クラスターでは
SparkTrialsを使用しないでください。 Hyperopt は、実行の開始時に並列処理の値を選択します。 クラスターが後でオートスケールの場合、Hyperopt は新しいクラスター サイズを利用できません。
トラブルシューティング
報告された NaN の損失 (数値ではない) は、通常、返された NaN に渡され
fmin()目的関数を意味します。 これは他の実行には影響しないため、無視しても問題ありません。 この結果を防ぐには、ハイパーパラメータ空間を調整するか、目的関数を変更してみてください。Hyperoptは確率的探索アルゴリズムを使用するため、損失は通常、実行ごとに単調に減少しません。 ただし、これらのメソッドは、多くの場合、他のメソッドよりも迅速に最適なハイパーパラメータを見つけます。
Hyperopt と Spark の両方でオーバーヘッドが発生し、短い試用期間 (数十秒前半) の試用期間が支配される可能性があります。 あなたが観察するスピードアップは小さいか、ゼロでさえあるかもしれません。