Freigeben über

Best Practices und Problembehandlung für Hyperopt

  • Artikel

Hinweis

Die Open-Source-Version von Hyperopt wird nicht mehr gepflegt.

Hyperopt wird in der nächsten haupt-DBR ML-Version entfernt. Azure Databricks empfiehlt die Verwendung von Optuna für eine ähnliche Erfahrung und den Zugriff auf aktuellere Hyperparameter-Optimierungsalgorithmen.

Bewährte Methoden

  • Bayessche Ansätze können viel effizienter sein als Rastersuche und Zufallssuche. Daher können Sie mit dem TPE-Algorithmus (Hyperopt Tree of Parzen Estimators) mehr Hyperparameter und größere Bereiche untersuchen. Die Verwendung von Domänenwissen zum Einschränken der Suchdomäne kann die Optimierung optimieren und bessere Ergebnisse erzielen.
  • Wenn Sie verwenden hp.choice(), gibt Hyperopt den Index der Auswahlliste zurück. Daher ist der in MLflow protokollierte Parameter auch der Index. Verwenden Sie hyperopt.space_eval(), um die Parameterwerte abzurufen.
  • Beginnen Sie bei Modellen mit langen Trainingszeiten mit kleinen Datasets und vielen Hyperparametern zu experimentieren. Verwenden Sie MLflow, um die Modelle mit der besten Leistung zu identifizieren und zu bestimmen, welche Hyperparameter korrigiert werden können. Auf diese Weise können Sie den Parameterbereich reduzieren, während Sie die Optimierung im großen Stil vorbereiten.
  • Nutzen Sie die Hyperopt-Unterstützung für bedingte Dimensionen und Hyperparameter. Wenn Sie beispielsweise mehrere Varianten des Gradientenabstiegs auswerten, anstatt den Hyperparameterbereich auf die allgemeinen Hyperparameter zu beschränken, können Sie Hyperopt bedingte Hyperparameter einschließen lassen, die nur für eine Teilmenge der Varianten geeignet sind. Weitere Informationen zur Verwendung von bedingten Parametern finden Sie unter Definieren eines Suchbereichs.
  • Wenn Sie SparkTrials verwenden, konfigurieren Sie die Parallelität für CPU-fähige Cluster und GPU-fähige Cluster entsprechend. In Azure Databricks verwenden CPU- und GPU-Cluster eine unterschiedliche Anzahl von Executorthreads pro Workerknoten. CPU-Cluster verwenden mehrere Executorthreads pro Knoten. GPU-Cluster verwenden nur einen Executorthread pro Knoten, um Konflikte zwischen mehreren Spark-Tasks zu vermeiden, die versuchen, dieselbe GPU zu verwenden. Dies ist zwar im Allgemeinen optimal für Bibliotheken, die für GPUs geschrieben wurden, bedeutet jedoch, dass die maximale Parallelität in GPU-Clustern reduziert wird. Beachten Sie daher, wie viele GPUs jede Testversion bei der Auswahl von GPU-Instanztypen verwenden kann. Weitere Informationen finden Sie unter GPU-fähige Cluster.
  • Verwenden Sie SparkTrials nicht für Cluster mit automatischer Skalierung. Hyperopt wählt den Parallelitätswert aus, wenn die Ausführung beginnt. Wenn der Cluster später automatisch skaliert wird, kann Hyperopt die neue Clustergröße nicht nutzen.

Problembehandlung

  • Ein gemeldeter NaN-Verlust (nicht numerisch) bedeutet in der Regel, dass die Objective-Funktion an den fmin() zurückgegebenen NaN übergeben wird. Dies wirkt sich nicht auf andere Ausführungen aus, und Sie können sie problemlos ignorieren. Um dieses Ergebnis zu verhindern, versuchen Sie, den Hyperparameterbereich anzupassen oder die Objective-Funktion zu ändern.
  • Da Hyperopt stochastische Suchalgorithmen verwendet, verringert sich der Verlust bei jeder Ausführung in der Regel nicht monoton. Diese Methoden finden jedoch häufig die besten Hyperparameter schneller als andere Methoden.
  • Sowohl Hyperopt als auch Spark verursachen Mehraufwand, der die Testdauer für kurze Testläufe (niedrige Dutzende Sekunden) überdauern kann. Die Geschwindigkeit, die Sie beobachten, kann klein oder sogar 0 (null) sein.

Beispielnotebook: Bewährte Methoden für Datasets unterschiedlicher Größe

SparkTrials führt die Testversionen auf Spark-Workerknoten aus. Dieses Notebook enthält Anleitungen dazu, wie Sie Datasets verschiedener Größenordnungen bei Verwendung von SparkTrials auf Workerknoten verschieben.

Verarbeiten von Datasets mit unterschiedlichen Größenordnungen im Notebook

Notebook abrufen