ベスト プラクティス: Hyperopt を使用したハイパーパラメーターのチューニング
ベスト プラクティス
- ベイジアンのアプローチは、グリッド検索とランダム検索よりもはるかに効率的である場合があります。 そのため、Hyperopt の Tree of Parzen Estimator (TPE) アルゴリズムでは、より多くのハイパーパラメーターとより広い範囲を調べることができます。 ドメイン知識を用いて検索ドメインを制限すると、チューニングを最適化し、より良い結果を生み出すことができます。
hp.choice()を使用した場合、Hyperopt では選択リストのインデックスが返されます。 そのため、MLflow に記録されたパラメーターもインデックスです。hyperopt.space_eval()を使用して、パラメーター値を取得します。- トレーニング時間が長いモデルの場合、初めに小規模なデータセットと多くのハイパーパラメーターで試してみてください。 MLflow を使用して最適なモデルを特定し、どのハイパーパラメーターを修正できるかを判断します。 こうすることで、大規模なチューニングを準備する際に、パラメーター空間を減らすことができます。
- 条件ディメンションとハイパーパラメーターに対する Hyperopt のサポートを活用します。 たとえば、勾配降下の複数のフレーバーを評価するときには、ハイパーパラメーター空間を共通のハイパーパラメーターのみに制限するのではなく、Hyperopt に条件付きハイパーパラメーター (フレーバーのサブセットにのみ適しているもの) を含めることができます。 条件付きパラメーターの使用方法の詳細については、「検索スペースの定義」を参照してください。
SparkTrialsを使用する場合は、CPU のみのクラスターと GPU 対応のものに対して並列処理を適切に構成します。 Azure Databricks では、CPU と GPU のクラスターで使用されるワーカー ノードごとの Executor スレッドの数は異なります。 CPU クラスターでは、ノードごとに複数の Executor スレッドが使用されます。 GPU クラスターでは、ノードごとに 1 つの Executor スレッドのみが使用され、同じ GPU を使用しようとしている複数の Spark タスク間での競合が回避されます。 これは通常、GPU 用に記述されたライブラリに最適ですが、GPU クラスターで最大並列処理が削減されることを意味します。そのため、GPU インスタンスの種類を選択する際には、各試行で使用できる GPU の数を確認してください。 詳細については、「GPU 対応クラスター」を参照してください。SparkTrialsは自動スケーリング クラスターでは使用しないでください。 Hyperopt では、実行の開始時に並列処理の値が選択されます。 クラスターが後から自動スケーリングされる場合、Hyperopt では新しいクラスター サイズを利用できません。
トラブルシューティング
- NaN (数字ではありません) の損失が報告された場合は、通常、
fmin()に渡された目的関数によって NaN が返されたことを意味します。 これは他の実行には影響しないため、無視しても問題ありません。 この結果を回避するには、ハイパーパラメーター空間を調整するか、目的関数を変更してみてください。 - Hyperopt では確率的検索アルゴリズムが使用されるため、通常は、この損失が実行のたびに単調に減少することはありません。 ただし、多くの場合、これらの方法では、他の方法よりも迅速に最適なハイパーパラメーターが見つかります。
- Hyperopt と Spark ではどちらも、短い試行の試行期間 (数十秒未満) を上回るオーバーヘッドが発生します。 確認される加速の程度が小さい、またはゼロの可能性もあります。
ノートブックの例: さまざまなサイズのデータセットでのベスト プラクティス
SparkTrials では、Spark ワーカー ノードで試行されます。 このノートブックには、SparkTrials を使用する際に、さまざまな規模のデータセットをワーカー ノードに移動する方法についてのガイドラインが示されています。