Configurer l’entraînement AutoML avec le SDK Python Azure ML v2

  • Article
  • 18 minutes de lecture

S’APPLIQUE À : Kit de développement logiciel (SDK) Python azure-ai-mlv2 (préversion)

Dans ce guide, vous allez découvrir comment configurer un travail d’entraînement de Machine Learning automatisé, AutoML, avec le SDK Python Azure Machine Learning v2. Le ML automatisé choisit pour vous un algorithme et des hyperparamètres, et génère un modèle prêt pour le déploiement. Ce guide fournit des détails sur les différentes options que vous pouvez utiliser pour configurer des expériences ML automatisées.

Si vous préférez une expérience sans code, vous pouvez également Configurer un apprentissage AutoML sans code dans Azure Machine Learning Studio.

Si vous préférez envoyer des travaux d’entraînement avec l’extension Azure Machine Learning CLI v2, consultez Effectuer l’apprentissage des modèles.

Prérequis

Pour cet article, vous avez besoin des éléments suivants :

Set up your workspace

Pour vous connecter à un espace de travail, vous devez fournir un abonnement, un groupe de ressources et un nom d’espace de travail. Ces détails sont utilisés dans le MLClient de azure.ai.ml pour obtenir un handle vers l’espace de travail Azure Machine Learning requis.

Dans l’exemple suivant, l’authentification Azure par défaut est utilisée avec la configuration de l’espace de travail par défaut ou à partir de n’importe quel fichier config.json que vous avez copié dans la structure des dossiers. Si aucun config.json n’est trouvé, vous devez spécifier manuellement l’ID d’abonnement, le groupe de ressources et l’espace de travail lors de la création de MLClient.

from azure.identity import DefaultAzureCredential
from azure.ai.ml import MLClient

credential = DefaultAzureCredential()
ml_client = None
try:
    ml_client = MLClient.from_config(credential)
except Exception as ex:
    print(ex)
    # Enter details of your AzureML workspace
    subscription_id = "<SUBSCRIPTION_ID>"
    resource_group = "<RESOURCE_GROUP>"
    workspace = "<AZUREML_WORKSPACE_NAME>"
    ml_client = MLClient(credential, subscription_id, resource_group, workspace)

Source et format des données

Pour fournir des données d’entraînement à AutoML dans le SDK v2, vous devez les charger dans le cloud par le biais d’une MLTable.

Configuration requise pour le chargement de données dans une MLTable :

  • Les données doivent être sous forme tabulaire.
  • La valeur à prédire, la colonne cible, doit figurer dans les données.

Les données d’entraînement doivent être accessibles à partir de la ressource de calcul distante. Le ML automatisé v2 (SDK Python et CLI/YAML) accepte les ressources de données MLTable (v2), bien qu’à des fins de compatibilité descendante il prenne également en charge les jeux de données tabulaires v1 (un jeu de données tabulaire inscrit) via les mêmes propriétés de jeu de données d’entrée. Toutefois, il est recommandé d’utiliser la MLTable disponible dans v2.

Le code YAML suivant est la définition d’une MLTable qui peut être placée dans un dossier local ou un dossier distant dans le cloud, avec le fichier de données (fichier .CSV ou Parquet).

# MLTable definition file

paths:
  - file: ./bank_marketing_train_data.csv
transformations:
  - read_delimited:
        delimiter: ','
        encoding: 'ascii'

Par conséquent, le dossier MLTable contiendrait le fichier de définition de MLTable plus le fichier de données (en l’occurrence, le fichier bank_marketing_train_data.csv).

Voici deux manières différentes de créer une MLTable.

  • R. Fournissez vos données d’entraînement et votre fichier de définition de MLTable à partir de votre dossier local, et elles seront automatiquement chargées dans le cloud (magasin de données d’espace de travail par défaut)
  • B. Fournissez une MLTable déjà inscrite et chargée dans le cloud.
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import automl, Input

# A. Create MLTable for training data from your local directory
my_training_data_input = Input(
    type=AssetTypes.MLTABLE, path="./data/training-mltable-folder"
)

# B. Remote MLTable definition
my_training_data_input  = Input(type=AssetTypes.MLTABLE, path="azureml://datastores/workspaceblobstore/paths/Classification/Train")

Formation, validation et test des données

Vous pouvez spécifier des données d’entraînement et des jeux de données de validation distincts, mais les données d’entraînement doivent être fournies au paramètre training_data dans la fonction de fabrique de votre travail de ML automatisé.

Si vous ne spécifiez pas explicitement un paramètre validation_data ou n_cross_validation, le Machine Learning automatisé applique les techniques par défaut pour déterminer la façon dont la validation est effectuée. Cette détermination dépend du nombre de lignes dans le jeu de données affecté à votre paramètre training_data.

Taille des données d’entraînement Technique de validation
Plus de 20 000 lignes Le fractionnement des données de formation/validation est appliqué. La valeur par défaut consiste à prendre 10 % du jeu de données d’apprentissage initial en tant que jeu de validation. Ce jeu de validation est ensuite utilisé pour le calcul des métriques.
Inférieur ou égal à 20 000 lignes L’approche de validation croisée est appliquée. Le nombre de plis par défaut dépend du nombre de lignes.
Si le jeu de données est inférieur à 1 000 lignes, 10 plis sont utilisés.
S’il y a entre 1 000 et 20 000 lignes, trois plis sont utilisés.

Capacité de calcul pour exécuter l’expérience

Les travaux de ML automatisé avec le SDK Python v2 (ou CLI v2) sont actuellement pris en charge uniquement sur un calcul distant Azure ML (cluster ou instance de calcul).

En savoir plus sur la création de calcul avec Python SDKv2 (ou CLIv2)..

Configurer les paramètres de votre expérience

Vous pouvez utiliser plusieurs options pour configurer des expériences de ML automatisé. Ces paramètres de configuration sont définis dans votre méthode de tâche. Vous pouvez également définir des paramètres d’entraînement du travail et des critères de sortie avec les fonctions set_training() et set_limits(), respectivement.

L’exemple suivant montre les paramètres requis pour une tâche de classification qui spécifie la justesse en tant que métrique principale et cinq plis de validation croisée.

# note that the below is a code snippet -- you might have to modify the variable values to run it successfully
classification_job = automl.classification(
    compute=my_compute_name,
    experiment_name=my_exp_name,
    training_data=my_training_data_input,
    target_column_name="y",
    primary_metric="accuracy",
    n_cross_validations=5,
    enable_model_explainability=True,
    tags={"my_custom_tag": "My custom value"}
)

# Limits are all optional

classification_job.set_limits(
    timeout_minutes=600, 
    trial_timeout_minutes=20, 
    max_trials=5,
    enable_early_termination=True,
)

# Training properties are optional
classification_job.set_training(
    blocked_training_algorithms=["LogisticRegression"], 
    enable_onnx_compatible_models=True
)

Sélectionnez votre type de tâche Machine Learning (problème ML)

Avant de pouvoir soumettre votre travail de ML automatisé, vous devez déterminer le type de problème Machine Learning que vous résolvez. Ce problème détermine la fonction utilisée par votre travail de ML automatisé et les algorithmes de modèle qu’il applique.

Le ML automatisé prend en charge les tâches basées sur des données tabulaires (classification, régression, prévision), les tâches de vision par ordinateur (telles que la classification d’images et la détection d’objet) et les tâches de traitement en langage naturel (telles que les tâches de classification de texte et de reconnaissance d’entité). Découvrez plus d’informations sur les types de tâches.

Algorithmes pris en charge

Le machine learning automatisé essaie différents modèles et algorithmes lors du processus d’automatisation et d’optimisation. En tant qu’utilisateur, vous n’avez pas besoin de spécifier l’algorithme.

La méthode de tâche détermine la liste des algorithmes/modèles à appliquer. Utilisez les paramètres allowed_training_algorithms ou blocked_training_algorithms dans la fonction Set set_training() pour modifier les itérations avec les modèles disponibles à inclure ou à exclure.

Dans la liste de liens suivante, vous pouvez explorer les algorithmes pris en charge par chaque tâche Machine Learning listée ci-dessous.

classification ; régression ; Prévision de séries chronologiques
Régression logistique* Elastic Net* AutoARIMA
Light GBM* Light GBM* Prophet
Boosting de gradient* Boosting de gradient* Elastic Net
Arbre de décision* Arbre de décision* Light GBM
K plus proches voisins* K plus proches voisins* K plus proches voisins
Linear SVC* LARS Lasso* Decision Tree
Support Vector Classification (SVC)* Stochastic Gradient Descent (SGD)* Arimax
Forêt aléatoire* Random Forest LARS Lasso
Arborescences extrêmement aléatoires* Arborescences extrêmement aléatoires* Arborescences extrêmement aléatoires*
Xgboost* Xgboost* Random Forest
Naive Bayes* Xgboost ForecastTCN
Stochastic Gradient Descent (SGD)* Stochastic Gradient Descent (SGD) Gradient Boosting
ExponentialSmoothing
SeasonalNaive
Moyenne
Naive
SeasonalAverage

Avec des algorithmes supplémentaires ci-dessous.

Suivez ce lien pour obtenir des exemples de notebooks de chaque type de tâche.

Métrique principale

Le paramètre primary_metric détermine la métrique à utiliser pendant l’entraînement du modèle dans un but d’optimisation. Les mesures disponibles que vous pouvez sélectionner sont déterminées par le type de tâche que vous choisissez.

Le choix d’une métrique principale pour l’optimisation du ML automatisé dépend de nombreux facteurs. Nous vous recommandons avant tout de choisir une métrique correspondant au mieux à vos besoins métier. Examinez ensuite si la métrique convient pour votre profil de jeu de données (taille des données, plage, distribution de classe, etc.). Les sections suivantes résument les mesures principales recommandées en fonction du type de tâche et du scénario d’entreprise.

Pour découvrir les définitions spécifiques de ces métriques, consultez Comprendre les résultats du Machine Learning automatisé.

Métriques pour les scénarios de classification multi-classe

Ces métriques s’appliquent à tous les scénarios de classification, notamment données tabulaires, images/vision par ordinateur et texte NLP.

Des métriques dépendant du seuil telles que accuracy, recall_score_weighted, norm_macro_recall et precision_score_weighted ne permettent pas d’obtenir une bonne optimisation pour des jeux de données de petite taille ou présentant une asymétrie (déséquilibre) de classe conséquente, ou lorsque la valeur de métrique attendue est très proche de 0.0 ou 1.0. Dans ces cas, AUC_weighted peut être un meilleur choix pour la métrique principale. Une fois l’opération de ML automatisé terminée, vous pouvez choisir le modèle gagnant en fonction de la métrique la plus adaptée à vos besoins métier.

Métrique Exemple(s) de cas d’usage
accuracy Classification d’images, analyse des sentiments, prédiction d’attrition
AUC_weighted Détection des fraudes, classification d’images, détection d’anomalies, détection de courrier indésirable
average_precision_score_weighted analyse de sentiments
norm_macro_recall Prédiction d’attrition
precision_score_weighted

Métriques pour les scénarios de classification multi-étiquette

  • Pour la classification de texte multi-étiquette, actuellement la « justesse » est la seule métrique principale prise en charge.

  • Pour la classification d’images multi-étiquette, les métriques principales prises en charge sont définies dans l’énumération ClassificationMultilabelPrimaryMetrics

Métriques pour les scénarios NER (Reconnaissance d’entité nommée) de texte NLP

  • Pour la NER (Reconnaissance d’entité nommée) de texte NLP, actuellement la « justesse » est la seule métrique principale prise en charge.

Métriques pour les scénarios de régression

r2_score, normalized_mean_absolute_error et normalized_root_mean_squared_error essaient tous de réduire les erreurs de prédiction. r2_score et normalized_root_mean_squared_error réduisent les erreurs quadratiques moyennes, tandis que normalized_mean_absolute_error réduit la valeur absolue moyenne des erreurs. La valeur absolue traite les erreurs de toutes les amplitudes, et les erreurs au carré ont une pénalité beaucoup plus importante pour les erreurs avec des valeurs absolues plus grandes. Selon que les erreurs de plus grande taille doivent être punies ou non, vous pouvez choisir d’optimiser l’erreur au carré ou l’erreur absolue.

La principale différence entre r2_score et normalized_root_mean_squared_error est la façon dont elles sont normalisées et leurs significations. normalized_root_mean_squared_error est l’erreur quadratique moyenne normalisée par plage et peut être interprétée comme l’amplitude moyenne des erreurs pour la prédiction. r2_score est une erreur carrée moyenne normalisée par une estimation de la variance des données. Il s’agit de la proportion de variation qui peut être capturée par le modèle.

Notes

r2_score et normalized_root_mean_squared_error se comportent également de la même façon que les métriques principales. Si un jeu de validation fixe est appliqué, ces deux métriques optimisent la même cible, l’erreur quadratique moyenne, et sont optimisées par le même modèle. Lorsque seul un jeu d’apprentissage est disponible et que la validation croisée est appliquée, elles sont légèrement différentes, du fait que la normalisation de normalized_root_mean_squared_error est fixe en tant que plage de l’ensemble d’apprentissage, alors que la normalisation de r2_score serait différente pour chaque pli, car il s’agit de l’écart pour chaque pli.

Si le classement, plutôt que la valeur exacte, vous intéresse, spearman_correlation peut être un meilleur choix, car il mesure la corrélation de classement entre les valeurs réelles et les prédictions.

Toutefois, actuellement, aucune métrique principale pour la régression ne porte sur la différence relative. r2_score, normalized_mean_absolute_error et normalized_root_mean_squared_error traitent chacun une erreur de prédiction de 20 000 $ de la même façon pour un employé avec un salaire de 30 000 $ que pour un employé gagnant 20 millions $, si ces deux points de données appartiennent au même jeu de données pour la régression ou la même série chronologique spécifiée par l’identificateur de série chronologique. Or, en réalité, prévoir seulement 20 000 dollars de réduction sur un salaire de 20 millions de dollars est insignifiant (petite différence relative de 0,1 %), tandis que 20 000 dollars de réduction sur un salaire de 30 000 dollars est tout à fait conséquent (grande différence relative de 67 %). Pour résoudre le problème de différence relative, vous pouvez effectuer l’apprentissage d’un modèle avec les métriques principales disponibles, puis sélectionner le modèle avec la meilleure valeur de mean_absolute_percentage_error ou root_mean_squared_log_error.

Métrique Exemple(s) de cas d’usage
spearman_correlation
normalized_root_mean_squared_error Prédiction de prix (maison/produit/pourboire), examen de prédiction de score
r2_score Retard de compagnie aérienne, estimation du salaire, temps de résolution des bogues
normalized_mean_absolute_error

Métriques pour les scénarios de prévision de séries chronologiques

Les recommandations sont similaires à celles indiquées pour les scénarios de régression.

Métrique Exemple(s) de cas d’usage
normalized_root_mean_squared_error Prédiction (prévision) de prix, optimisation de stocks, prévision de la demande
r2_score Prédiction (prévision) de prix, optimisation de stocks, prévision de la demande
normalized_mean_absolute_error

Métriques pour les scénarios de détection d’objet image

  • Pour la détection d’objet image, les métriques principales prises en charge sont définies dans l’énumération ObjectDetectionPrimaryMetrics

Métriques pour les scénarios de segmentation d’instance d’image

  • Pour les scénarios de segmentation d’instance d’image, les métriques principales prises en charge sont définies dans l’énumération InstanceSegmentationPrimaryMetrics

Caractérisation de données

Dans chaque expérience de ML automatisé, vos données sont automatiquement transformées en nombres et en vecteurs de nombres plus (autrement dit conversion de texte en texte numérique) également mis à l’échelle et normalisés pour aider certains algorithmes sensibles aux fonctionnalités qui sont à différentes échelles. Cette transformation des données, mise à l’échelle et normalisation est appelée « caractérisation ».

Notes

Les étapes de caractérisation du Machine Learning automatisé (normalisation des fonctionnalités, gestion des données manquantes, conversion de texte en valeurs numériques, etc.) font partie du modèle sous-jacent. Lorsque vous utilisez le modèle pour des prédictions, les étapes de caractérisation qui sont appliquées pendant la formation sont appliquées automatiquement à vos données d’entrée.

Lorsque vous configurez vos travaux de ML automatisé, vous pouvez activer/désactiver les paramètres featurization à l’aide de la fonction Set .set_featurization().

Le tableau suivant présente les paramètres acceptés pour la caractérisation.

Configuration de la caractérisation Description
"mode": 'auto' Indique que, dans le cadre du prétraitement, des étapes de garde-fous des données et de caractérisation sont automatiques. Paramètre par défaut.
"mode": 'off' Indique que l’étape de caractérisation ne doit pas être automatique.
"mode": 'custom' Indique que l’étape de caractérisation personnalisée doit être utilisée.

Le code suivant montre comment la caractérisation personnalisée peut être fournie dans ce cas pour un travail de régression.

from azure.ai.ml.automl import ColumnTransformer

transformer_params = {
    "imputer": [
        ColumnTransformer(fields=["CACH"], parameters={"strategy": "most_frequent"}),
        ColumnTransformer(fields=["PRP"], parameters={"strategy": "most_frequent"}),
    ],
}
regression_job.set_featurization(
    mode="custom",
    transformer_params=transformer_params,
    blocked_transformers=["LabelEncoding"],
    column_name_and_types={"CHMIN": "Categorical"},
)

Critères de sortie

Il existe quelques options que vous pouvez définir dans la fonction set_limits() pour mettre fin à votre expérience avant la fin du travail.

Critères description
Aucun critère Si vous ne définissez pas de paramètres de sortie, l’expérience continuera jusqu’à ce que votre métrique principale ne progresse plus.
timeout Définit la durée, en minutes, pendant laquelle votre expérience doit continuer à s’exécuter. Si la valeur n’est pas spécifiée, le délai d’expiration total par défaut du travail est de 6 jours (8 640 minutes). Pour spécifier un délai d’expiration inférieur ou égal à 1 heure (60 minutes), vérifiez que la taille de votre jeu de données n’est pas supérieure à 10 000 000 (lignes X colonne), ou une erreur se produira.

Ce délai d’expiration inclut la configuration, la caractérisation et les exécutions d’entraînement, mais n’inclut pas les exécutions d’ensembling et d’explicabilité du modèle à la fin du processus, car ces actions doivent se produire une fois que tous les essais (travaux enfants) sont terminés.
trial_timeout_minutes Durée d’exécution maximale en minutes de chaque essai (travail enfant) avant son arrêt. Si cette valeur n’est pas spécifiée, une valeur de un mois ou 43 200 minutes est utilisée
enable_early_termination Indique s’il faut arrêter le travail si le score ne s’améliore pas à court terme
max_trials Nombre maximal d’essais/exécutions chacun avec une combinaison différente d’algorithme et d’hyperparamètres à essayer pendant un travail AutoML. Si cela n’est pas spécifié, la valeur par défaut est 1000 essais. En cas d’utilisation de enable_early_termination, le nombre d’essais utilisés peut être inférieur.
max_concurrent_trials Représente le nombre maximal d’essais (travaux enfants) qui seraient exécutés en parallèle. Une bonne pratique consiste à faire correspondre ce nombre au nombre de nœuds de votre cluster

Exécuter une expérience

Notes

Si vous exécutez plusieurs fois une expérience avec les mêmes paramètres de configuration et la même métrique principale, vous constaterez probablement des variations dans chaque score de métrique finale d’expériences et de modèles générés. Les algorithmes utilisés par le ML automatisé présentent un fonctionnement aléatoire inhérent qui peut provoquer de légères variations dans la sortie des modèles par l’expérience et le score de métrique final de modèle recommandé, comme la précision. Vous verrez probablement également des résultats avec le même nom de modèle, mais des hyperparamètres différents.

Avertissement

Si vous avez défini des règles dans le pare-feu et/ou le groupe de sécurité réseau sur votre espace de travail, vérifiez que les autorisations requises sont accordées au trafic réseau entrant et sortant, comme défini dans Configurer le trafic réseau entrant et sortant.

Soumettez l’expérience pour qu’elle s’exécute et génère un modèle. Une fois le MLClient créé dans les prérequis, vous pouvez exécuter la commande suivante dans l’espace de travail.


# Submit the AutoML job
returned_job = ml_client.jobs.create_or_update(
    classification_job
)  # submit the job to the backend

print(f"Created job: {returned_job}")

# Get a URL for the status of the job
returned_job.services["Studio"].endpoint

Plusieurs exécutions enfants sur des clusters

Les exécutions enfants d’expérimentation ML automatisé peuvent intervenir sur un cluster exécutant déjà une autre expérience. Toutefois, le minutage dépend du nombre de nœuds du cluster et de la disponibilité de ces nœuds pour exécuter une expérience différente.

Chaque nœud du cluster fait office de machine virtuelle individuelle capable d’effectuer une seule exécution d’apprentissage ; en termes de ML automatisé, cela signifie une exécution enfant. Si tous les nœuds sont occupés, la nouvelle expérience est mise en file d’attente. Cela étant, si des nœuds sont disponibles, la nouvelle expérience procède à des exécutions enfants de ML automatisé en parallèle dans les nœuds/machines virtuelles disponibles.

Pour faciliter la gestion des exécutions enfants et le moment où elles peuvent intervenir, nous vous recommandons de créer un cluster dédié par expérience et de faire correspondre le nombre de max_concurrent_iterations de votre expérience avec le nombre de nœuds du cluster. Ainsi, vous utilisez tous les nœuds du cluster en même temps que les exécutions/itérations enfants simultanées de votre choix.

Configurez max_concurrent_iterations dans la fonction Set .set_limits(). S’il n’est pas configuré, par défaut, une seule exécution/itération enfant simultanée est autorisée par expérience. Dans le cas d’une instance de calcul, max_concurrent_trials peut être défini comme étant le même que le nombre de cœurs sur la machine virtuelle de l’instance de calcul.

Explorer les modèles et les métriques

Le ML automatisé offre des options pour surveiller et évaluer les résultats de l’apprentissage.

À partir de l’interface utilisateur Azure Machine Learning, dans la page du modèle, vous pouvez également afficher les hyperparamètres utilisés lors de l’entraînement d’un modèle, et afficher et personnaliser le code d’entraînement du modèle interne utilisé.

Inscrire et déployer des modèles

Après avoir testé un modèle et confirmé que vous souhaitez l’utiliser en production, vous pouvez l’inscrire pour une utilisation ultérieure.

Conseil

Pour les modèles enregistrés, le déploiement en un clic est disponible via Azure Machine Learning studio. Découvrez comment déployer des modèles enregistrés à partir de Studio.

AutoML dans les pipelines

Pour tirer parti d’AutoML dans vos workflows MLOps, vous pouvez ajouter des étapes de tâchel AutoML à vos pipelines AzureML. Cela vous permet d’automatiser l’intégralité de votre flux de travail en connectant vos scripts de préparation des données à AutoML, puis en inscrivant et en validant le meilleur modèle résultant.

Voici un exemple de pipeline avec un composant de classification AutoML et un composant de commande qui affiche la sortie AutoML résultante. Notez comment les entrées (données de validation d’apprentissage &) et les sorties (meilleur modèle) sont référencées en différentes étapes.

# Define pipeline
@pipeline(
    description="AutoML Classification Pipeline",
    )
def automl_classification(
    classification_train_data,
    classification_validation_data
):
    # define the automl classification task with automl function
    classification_node = classification(
        training_data=classification_train_data,
        validation_data=classification_validation_data,
        target_column_name="y",
        primary_metric="accuracy",
        # currently need to specify outputs "mlflow_model" explictly to reference it in following nodes 
        outputs={"best_model": Output(type="mlflow_model")},
    )
    # set limits and training
    classification_node.set_limits(max_trials=1)
    classification_node.set_training(enable_stack_ensemble=False, enable_vote_ensemble=False)

    command_func = command(
        inputs=dict(
            automl_output=Input(type="mlflow_model")
        ),
        command="ls ${{inputs.automl_output}}",
        environment="AzureML-sklearn-0.24-ubuntu18.04-py37-cpu:latest"
    )
    show_output = command_func(automl_output=classification_node.outputs.best_model)


pipeline_classification = automl_classification(
    classification_train_data=Input(path="./training-mltable-folder/", type="mltable"),
    classification_validation_data=Input(path="./validation-mltable-folder/", type="mltable"),
)

# ...
# Note that the above is only a snippet from the bankmarketing example you can find in our examples repo -> https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs/pipelines/1h_automl_in_pipeline/automl-classification-bankmarketing-in-pipeline

Pour plus d’exemples sur la façon d’inclure AutoML dans vos pipelines, consultez nos exemples de référentiel.

Étapes suivantes