Meilleures pratiques : Réglage des hyperparamètres avec Hyperopt
Meilleures pratiques
- Les approches bayésiennes peuvent être beaucoup plus efficaces que la recherche sur grille et la recherche aléatoire. Par conséquent, grâce à l’algorithme Tree of Parzen Estimators (TPE) d’Hyperopt, vous pouvez explorer davantage d’hyperparamètres et des plages plus larges. L’utilisation de la connaissance du domaine pour restreindre le domaine de recherche peut optimiser le réglage et produire de meilleurs résultats.
- Lorsque vous utilisez
hp.choice(), Hyperopt renvoie l’index de la liste de choix. Par conséquent, le paramètre enregistré dans MLflow est également l’index. Utilisezhyperopt.space_eval()pour récupérer les valeurs des paramètres. - Pour les modèles avec de longues périodes de formation, commencez à expérimenter avec de petits jeux de données et de nombreux hyperparamètres. Utilisez MLflow pour identifier les modèles les plus performants et déterminer quels hyperparamètres peuvent être corrigés. De cette façon, vous pouvez réduire l’espace des paramètres à mesure que vous préparez l’optimisation à grande échelle.
- Tirez parti de la prise en charge des dimensions et des hyperparamètres conditionnels par Hyperopt. Par exemple, lorsque vous évaluez plusieurs saveurs de la descente de gradient, au lieu de limiter l’espace des hyperparamètres aux hyperparamètres courants, vous pouvez demander à Hyperopt d’inclure des hyperparamètres conditionnels, ceux qui ne conviennent qu’à un sous-ensemble des saveurs. Pour plus d’informations sur l’utilisation des paramètres conditionnels, consultez Définition d’un espace de recherche.
- Lorsque vous utilisez
SparkTrials, configurez le parallélisme de manière appropriée pour les clusters avec UC uniquement et pour les clusters avec GPU. Dans Azure Databricks, les clusters UC et GPU utilisent un nombre différent de threads d’exécution par nœud Worker. Les clusters UC utilisent plusieurs threads d’exécution par nœud. Les clusters GPU utilisent un seul thread d’exécution par nœud pour éviter les conflits entre plusieurs tâches Spark essayant d’utiliser le même GPU. Bien que cela soit généralement optimal pour les bibliothèques écrites pour les GPU, cela signifie que le parallélisme maximal est réduit sur les clusters GPU. Vous devez donc connaître le nombre de GPU que chaque essai peut utiliser lors de la sélection des types d’instances GPU. Pour plus d’informations, consultez Clusters compatibles GPU. - N’utilisez pas
SparkTrialssur les clusters avec mise à l’échelle automatique. Hyperopt sélectionne la valeur de parallélisme au démarrage de l’exécution. Si le cluster se met à l’échelle automatiquement par la suite, Hyperopt ne pourra pas tirer parti de la nouvelle taille du cluster.
Résolution des problèmes
- Une perte signalée de NAN (n’est pas un nombre) signifie généralement que la fonction transmise à
fmin()a renvoyé NAN. Cela n’affecte pas les autres exécutions et vous pouvez l’ignorer sans risque. Pour éviter ce résultat, essayez d’ajuster l’espace des hyperparamètres ou de modifier la fonction objective. - Comme Hyperopt utilise des algorithmes de recherche stochastique, la perte ne diminue généralement pas de façon monotone à chaque exécution. Toutefois, ces méthodes trouvent souvent les meilleurs hyperparamètres plus rapidement que les autres méthodes.
- Hyperopt et Spark encourent tous deux des surcharges qui peuvent dominer la durée de l’essai pour les essais d’exécution courts (quelques dizaines de secondes). L’accélération que vous observez peut être faible, voire nulle.
Exemple de notebook : meilleures pratiques pour les jeux de données de différentes tailles
SparkTrials exécute les essais sur des nœuds Worker Spark. Ce notebook fournit des instructions sur comment déplacer les jeux de données de différents ordres de grandeur vers les nœuds Worker lorsque vous utilisez SparkTrials.