Configurer l’entraînement AutoML pour les données tabulaires avec l’interface CLI Azure Machine Learning et le SDK Python

S’APPLIQUE À :Extension Azure ML CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (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.

Prérequis

Pour utiliser les informations sur le Kit de développement logiciel (SDK), installez le kit de développement logiciel (SDK) v2 for Python Azure Machine Learning.

Pour installer le kit de développement logiciel (SDK), vous pouvez :

  • Créez une instance de calcul, qui a déjà installé le dernier SDK Python Azure Machine Learning et qui est préconfigurée pour les workflows ML. Consultez Créer une instance de calcul Azure Machine Learning pour plus d’informations.
  • Installez le kit de développement logiciel (SDK) sur votre machine locale

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 d’espace de travail 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 Azure Machine Learning 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. Dans cet exemple, nous partons du principe que les données sont stockées au niveau du chemin d’accès local, ./train_data/bank_marketing_train_data.csv

Vous pouvez créer un MLTable à l’aide du Kit de développement logiciel (SDK) Python mltable , comme dans l’exemple suivant :

import mltable

paths = [
    {'file': './train_data/bank_marketing_train_data.csv'}
]

train_table = mltable.from_delimited_files(paths)
train_table.save('./train_data')

Ce code crée un fichier, ./train_data/MLTable, qui contient le format du fichier et les instructions de chargement.

À présent, le dossier ./train_data contient le fichier de définition MLTable plus le fichier de données, bank_marketing_train_data.csv.

Pour plus d’informations sur MLTable, consultez l’article comment mltable

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 Machine Learning (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 paramètres training et limits.

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.

from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import automl, Input

# note that this is a code snippet -- you might have to modify the variable values to run it successfully

# make an Input object for the training data
my_training_data_input = Input(
    type=AssetTypes.MLTABLE, path="./data/training-mltable-folder"
)

# configure the classification job
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=["logistic_regression"], 
    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é). Pour plus d’informations, consultez notre article sur les types de tâches. Consultez notre guide de prévision des séries chronologiques pour plus d’informations sur la configuration des travaux de prévision.

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 configuration de la tâche AutoML training pour modifier davantage 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 TCNForecaster
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.

AutoML ne prend actuellement pas en charge les métriques principales qui mesurent la différence relative entre les prédictions et les observations. Les métriques r2_score, normalized_mean_absolute_erroret normalized_root_mean_squared_error sont toutes des mesures de différence absolue. Par exemple, si une prédiction diffère d’une observation de 10 unités, ces métriques calculent la même valeur si l’observation est de 20 unités ou de 20 000 unités. En revanche, une différence en pourcentage, qui est une mesure relative, donne des erreurs de 50 % et 0,05 %, respectivement ! Pour optimiser la différence relative, vous pouvez exécuter AutoML avec une métrique principale prise en charge, puis sélectionner le modèle avec le meilleur mean_absolute_percentage_error ou root_mean_squared_log_error. Notez que ces métriques ne sont pas définies lorsque les valeurs d’observation sont égales à zéro, donc elles ne sont pas toujours de bons choix.

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ée, vos données sont automatiquement transformées en nombres et en vecteurs de nombres, et également mises à l'échelle et normalisées pour aider les algorithmes qui sont sensibles aux caractéristiques qui se situent à différentes échelles. Ces transformations de données sont appelées 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.

Lors de la configuration de vos travaux ML automatisés, vous pouvez activer/désactiver les paramètres 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’hyper-paramè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 hyper-paramè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, une 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 configurationlimits. 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 hyper-paramè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âche AutoML à vos pipelines Azure Machine Learning. 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 la façon dont les entrées (données de formation et de validation) et les sorties (meilleur modèle) sont référencées dans 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_job = automl_classification(
    classification_train_data=Input(path="./training-mltable-folder/", type="mltable"),
    classification_validation_data=Input(path="./validation-mltable-folder/", type="mltable"),
)

# set pipeline level compute
pipeline_job.settings.default_compute = compute_name

# submit the pipeline job
returned_pipeline_job = ml_client.jobs.create_or_update(
    pipeline_job,
    experiment_name=experiment_name
)
returned_pipeline_job

# ...
# Note that this is 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.

AutoML à grande échelle : entraînement distribué

Pour les scénarios de données volumineuses, AutoML prend en charge l’entraînement distribué pour un ensemble limité de modèles :

Algorithme distribué Tâches prises en charge Limite de taille des données (approximative)
LightGBM Classification et régression 1 To
TCNForecaster Prévisions 200 Go

Les algorithmes d’entraînement distribué partitionnent et distribuent automatiquement vos données sur plusieurs nœuds de calcul pour l’entraînement du modèle.

Notes

La validation croisée, les modèles d’ensemble, la prise en charge d’ONNX et la génération de code ne sont actuellement pas pris en charge dans le mode d’entraînement distribué. En outre, AutoML peut faire des choix tels que la restriction des caractérisations disponibles et les données de sous-échantillonnage utilisées pour la validation, l’explicabilité et l’évaluation du modèle.

Entraînement distribué pour la classification et la régression

Pour utiliser l’entraînement distribué pour la classification ou la régression, vous devez définir les propriétés training_modeet max_nodes de l’objet de travail.

Propriété Description
training_mode Indique le mode d’entraînement; distributed ou non_distributed. La valeur par défaut est non_distributed.
max_nodes Nombre de nœuds à utiliser pour l’entraînement par chaque version d’évaluation AutoML. Ce paramètre doit être supérieur ou égal à 4.

L’exemple de code suivant montre un exemple de ces paramètres pour un travail de classification :

from azure.ai.ml.constants import TabularTrainingMode

# Set the training mode to distributed
classification_job.set_training(
    allowed_training_algorithms=["LightGBM"],
    training_mode=TabularTrainingMode.DISTRIBUTED
)

# Distribute training across 4 nodes for each trial
classification_job.set_limits(
    max_nodes=4,
    # other limit settings
)

Notes

L’entraînement distribué pour les tâches de classification et de régression ne prend actuellement pas en charge plusieurs essais simultanés. Les essais de modèles s’exécutent séquentiellement avec chaque version d’évaluation à l’aide de max_nodes nœuds. Le paramètre de limite max_concurrent_trials est actuellement ignoré.

Formation distribuée pour la prévision

Pour savoir comment l’entraînement distribué fonctionne pour les tâches de prévision, consultez notre article sur les prévisions à grande échelle. Pour utiliser l’entraînement distribué pour la prévision, vous devez définir les propriétés training_mode, enable_dnn_training, max_nodeset éventuellement les propriétés max_concurrent_trials de l’objet de travail.

Propriété Description
training_mode Indique le mode d’entraînement; distributed ou non_distributed. La valeur par défaut est non_distributed.
enable_dnn_training Indicateur pour activer les modèles de réseau neuronal profond.
max_concurrent_trials Il s’agit du nombre maximal de modèles d’essai à entraîner en parallèle. La valeur par défaut est de 1.
max_nodes Nombre total de nœuds à utiliser pour l’entraînement. Ce paramètre doit être supérieur ou égal à 2. Pour les tâches de prévision, chaque modèle d’essai est entraîné à l’aide de nœuds $\text{max}\left(2, \text{floor}( \text{max_nodes} / \text{max_concurrent_trials}) \right)$.

L’exemple de code suivant montre un exemple de ces paramètres pour un travail de prévision :

from azure.ai.ml.constants import TabularTrainingMode

# Set the training mode to distributed
forecasting_job.set_training(
    enable_dnn_training=True,
    allowed_training_algorithms=["TCNForecaster"],
    training_mode=TabularTrainingMode.DISTRIBUTED
)

# Distribute training across 4 nodes
# Train 2 trial models in parallel => 2 nodes per trial
forecasting_job.set_limits(
    max_concurrent_trials=2,
    max_nodes=4,
    # other limit settings
)

Consultez les sections précédentes sur la configuration et l’envoi de travaux pour obtenir des exemples de code de configuration complet.

Étapes suivantes