Partager via

Concepts Hyperopt

  • Article

Remarque

La version open source de Hyperopt n’est plus conservée.

Hyperopt sera supprimé dans la prochaine version principale de DBR ML. Azure Databricks recommande d’utiliser Optuna pour une expérience similaire et d’accéder à des algorithmes d’optimisation des hyperparamètres à jour.

Cet article décrit certains des concepts que vous devez connaître pour utiliser Hyperopt distribué.

Dans cette section :

Pour obtenir des exemples illustrant l’utilisation de Hyperopt dans Azure Databricks, consultez la section Hyperopt.

fmin()

Vous utilisez fmin() pour exploiter une exécution de Hyperopt. Les arguments de fmin() sont présentés dans le tableau. Pour plus d’informations, consultez la documentation de Hyperopt. Pour obtenir des exemples d’utilisation de chaque argument, consultez les exemples de notebooks.

Nom de l’argument Description
fn Fonction objective. Hyperopt appelle cette fonction avec des valeurs générées à partir de l’espace d’hyperparamètres fourni dans l’argument space. Cette fonction peut renvoyer la perte sous la forme d’une valeur scalaire ou dans un dictionnaire (pour plus d’informations, voir la documentation de Hyperopt). Cette fonction contient généralement du code pour la formation de modèles et le calcul de la perte.
space Définit l’espace des hyperparamètres à rechercher. Hyperopt offre une grande flexibilité dans la façon dont cet espace est défini. Vous pouvez choisir une option catégorielle, telle que l’algorithme, ou une distribution probabiliste pour les valeurs numériques, telle que uniforme et journal.
algo Algorithme de recherche Hyperopt à utiliser pour effectuer une recherche dans l’espace des hyperparamètres. Les plus couramment utilisés sont hyperopt.rand.suggest pour Random Search et hyperopt.tpe.suggest pour TPE.
max_evals Nombre de réglages d’hyperparamètres à essayer (nombre de modèles à ajuster).
max_queue_len Nombre de réglages d’hyperparamètres Hyperopt devant être générés à l’avance. Parce que l’algorithme de génération de TPE Hyperopt peut prendre un certain temps, il peut être utile d’augmenter ce nombre au-delà de la valeur par défaut de 1, mais généralement pas plus grand que le paramètre parallelism de SparkTrials.
trials Objet Trials ou SparkTrials. Utilisez SparkTrials lorsque vous appelez des algorithmes à machine unique, tels que les méthodes scikit-learn dans la fonction objective. Utilisez Trials lorsque vous appelez des algorithmes de formation distribuée tels que les méthodes MLlib ou Horovod dans la fonction objective.
early_stop_fn Fonction d’arrêt anticipé facultative permettant de déterminer si fmin doit s’arrêter avant que max_evals soit atteint. La valeur par défaut est None. La signature d’entrée de la fonction est Trials, *args, et la signature de sortie est bool, *args. La valeur booléenne de sortie indique s’il faut arrêter ou non. *args est tout état, où la sortie d’un appel à early_stop_fn sert d’entrée à l’appel suivant. Trials peut être un objet SparkTrials. Lors de l’utilisation de SparkTrials, l’exécution de la fonction d’arrêt anticipé n’est pas garantie après chaque essai, et la fonction est interrogée à la place. Exemple de fonction d’arrêt anticipé

Classe SparkTrials

SparkTrials est une API développée par Databricks qui vous permet de distribuer une exécution Hyperopt sans apporter d’autres modifications à votre code Hyperopt. SparkTrials accélère le paramétrage d’une seule machine en distribuant les essais aux Workers Spark.

Notes

SparkTrialsest conçu pour paralléliser les calculs pour les modèles de ML à machine unique tels que scikit-learn. Pour les modèles créés avec des algorithmes de ML distribué, tels que MLlib ou Horovod, n’utilisez pas SparkTrials. Dans ce cas, le processus de création du modèle est automatiquement mis en parallèle sur le cluster, et vous devez utiliser la classe Hyperopt par défaut Trials.

Cette section décrit comment configurer les arguments que vous transmettez à SparkTrials et les aspects d’implémentation de SparkTrials.

Arguments

SparkTrials accepte deux arguments facultatifs :

  • parallelism : Nombre maximal d’essais à évaluer simultanément. Un nombre plus élevé vous permet d’effectuer un Scale-out des tests de plus de réglages d’hyperparamètres. Étant donné que Hyperopt propose de nouveaux essais basés sur les résultats passés, il existe un compromis entre le parallélisme et l’adaptabilité. Pour un max_evals fixe, un plus grand parallélisme accélère les calculs, mais un parallélisme plus faible peut conduire à de meilleurs résultats puisque chaque itération a accès à plus de résultats passés.

    Valeur par défaut : Nombre d’exécuteurs Spark disponibles. Maximum : 128. Si la valeur est supérieure au nombre de tâches simultanées autorisées par la configuration du cluster, SparkTrials réduit le parallélisme à cette valeur.

  • timeout : Nombre maximal de secondes qu’un appel fmin() peut prendre. Lorsque ce nombre est dépassé, toutes les exécutions sont terminées et fmin() se termine. Les informations relatives aux exécutions terminées sont enregistrées.

Implémentation

Lors de la définition de la fonction objective fn transmise à fmin(), et lors de la sélection d’une configuration de cluster, il est utile de comprendre comment SparkTrials distribue les tâches de paramétrage.

Dans Hyperopt, un essai correspond généralement à l’ajustement d’un modèle sur un réglage d’hyperparamètres. Hyperopt génère des essais, les évalue et répète l’action de manière itérative.

Grâce à SparkTrials, le nœud pilote de votre cluster génère de nouveaux essais, et les nœuds Worker évaluent ces essais. Chaque essai est généré avec un travail Spark qui a une tâche et est évalué dans la tâche sur une machine Worker. Si votre cluster est configuré pour exécuter plusieurs tâches par Worker, plusieurs essais peuvent être évalués simultanément sur ce Worker.

SparkTrials et MLflow

Databricks Runtime ML prend en charge la journalisation des Workers vers MLflow. Vous pouvez ajouter un code de journalisation personnalisé dans la fonction objective que vous transmettez à Hyperopt.

SparkTrials consigne les résultats du paramétrage en tant qu’exécutions MLflow imbriquées, comme suit :

  • Exécution principale ou parente : L’appel à fmin() est consigné comme l’exécution principale. S’il existe une exécution active, SparkTrials consigne les résultats dans cette exécution active et ne termine pas l’exécution lorsque fmin() revient. S’il n’y a pas d’exécution active, SparkTrials crée une nouvelle exécution, y consigne les résultats et met fin à l’exécution avant le retour de fmin().
  • Exécutions enfants : Chaque réglage d’hyperparamètre testé (un « essai ») est consigné comme une exécution enfant sous l’exécution principale. Les enregistrements de journal MLflow des Workers sont également stockés sous les exécutions enfants correspondantes.

Lorsque vous appelez fmin(), Databricks recommande une gestion active des exécutions MLflow, c’est-à-dire que vous devez inclure l’appel à fmin() dans une instruction with mlflow.start_run():. Cela garantit que chaque appel à fmin() est enregistré dans une exécution principale MLflow distincte et facilite l’enregistrement de balises, de paramètres ou de métriques supplémentaires dans cette exécution.

Notes

Lorsque vous appelez fmin() dans la même exécution MLflow active, MLflow journalise ces appels dans la même exécution principale. Pour résoudre les conflits de noms pour les balises et les paramètres enregistrés, MLflow ajoute un UUID aux noms en conflit.

Lors de la journalisation à partir de Workers, vous n’avez pas besoin de gérer les exécutions explicitement dans la fonction objective. Appelez mlflow.log_param("param_from_worker", x) dans la fonction objective pour consigner un paramètre dans l’exécution enfant. Vous pouvez consigner les paramètres, les métriques, les balises et les artefacts dans la fonction objective.