Partager via

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

  • Article

S’APPLIQUE À :Extension Azure CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (version actuelle)

Dans cet article, vous allez découvrir comment configurer un travail d’apprentissage de Machine Learning automatisé (AutoML), avec la V2 du Kit de développement logiciel (SDK) Python Azure Machine Learning. 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. Cet article fournit des détails sur les différentes options que vous pouvez utiliser pour configurer des expériences de Machine Learning automatisées.

Si vous préférez une expérience sans code, vous pouvez également Configurer l’apprentissage ML automatisé sans code pour les données tabulaires avec l’interface utilisateur 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éer une instance de calcul, qui dispose déjà du dernier Kit de développement logiciel (SDK) Python Azure Machine Learning et qui est préconfigurée pour les flux de travail ML. Pour plus d’informations, consultez Créer une instance de calcul Azure Machine Learning.
  • 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 renseigner un abonnement, un groupe de ressources et un 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.

L’exemple suivant utilise l’authentification Azure par défaut en se basant sur la configuration de l’espace de travail par défaut ou sur la configuration à partir d’un fichier config.json dans la structure des dossiers. Si aucun config.json n’est trouvé, vous devez saisir manuellement l’ID d’abonnement, le groupe de ressources et l’espace de travail lors de la création du 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)

Saisir le format et la source des données

Pour fournir des données d’apprentissage au Machine Learning automatisé dans la V2 du Kit de développement logiciel (SDK), vous devez les importer 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. La V2 du Machine Learning automatisé (le Kit de développement logiciel et l’interface de ligne de commande Python/YAML) accepte les ressources de données MLTable (v2). En ce qui concerne la compatibilité descendante, elle prend également en charge la V1 des jeux de données tabulaires à partir de la V1, un jeu de données tabulaire enregistré, via les mêmes propriétés de jeu de données d’entrée. Nous vous recommandons d’utiliser MLTable, disponible dans la v2. Dans cet exemple, les données sont stockées sur le chemin 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 nouveau fichier, ./train_data/MLTable, qui contient le format de fichier et les instructions de chargement.

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

Pour plus d’informations sur MLTable, consultez Utilisation des tables dans Azure Machine Learning.

Formation, validation et test des données

Vous pouvez renseigner différents jeux de données d’apprentissage et de validation. Les données d’apprentissage doivent être fournies au paramètre training_data dans la fonction d’usine de votre travail de Machine Learning 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 d’apprentissage et de validation s’applique. 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 Machine Learning automatisé qui utilisent la V2 du Kit de développement logiciel (SDK) Python v2 (ou de la V2 de l’interface de ligne de commande) sont actuellement pris en charge uniquement sur un cluster de calcul distant Azure Machine Learning ou sur une instance de calcul. Pour plus d’informations sur la création de calcul au moyen de la V2 du Kit de développement logiciel (SDK) Python ou de l’interface de ligne de commande, consultez Entraîner des modèles avec l’interface de ligne de commande, le Kit de développement logiciel (SDK) et l’API REST Azure Machine Learning.

Configurer les paramètres de votre expérience

Vous disposez de plusieurs options pour configurer votre expérience de machine learning 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 renseigne l’exactitude comme 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 de Machine Learning

Avant de pouvoir soumettre votre travail de Machine Learning automatisé, déterminez le type de problème de Machine Learning que vous souhaitez résoudre. Ce problème détermine la fonction utilisée par votre travail ainsi que les algorithmes de modèle appliqués.

Le ML automatisé prend en charge différents types de tâches :

  • tâches basées sur des données tabulaires ;

    • classification ;
    • régression
    • prévision

  • tâches de vision par ordinateur, notamment

    • Classification d’image
    • Détection d’objets

  • tâches de traitement du langage naturel, notamment

    • Classification de texte
    • Reconnaissance d’entité

Pour en savoir plus, consultez types de tâches. Pour plus d’informations sur la configuration des travaux de prévision, consultez Configurer le Machine Learning automatisé à l’entraînement d’un modèle de prévision de série chronologique.

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 ou modèles à appliquer. Utilisez les paramètres allowed_training_algorithms ou blocked_training_algorithms dans la configuration training du travail pour modifier davantage les itérations avec les modèles disponibles à inclure ou à exclure.

Le tableau suivant indique les algorithmes pris en charge par tâche de Machine Learning.

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 d’autres algorithmes :

Pour obtenir des exemples de notebooks de chaque type de tâche, consultez travaux automl-standalone.

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. Le type de tâche que vous choisissez détermine les métriques que vous pouvez sélectionner.

Le choix d’une métrique principale pour l’optimisation du Machine Learning 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, notamment en matière de taille des données, de plages horaires et de distribution de classes, 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 en savoir plus sur les définitions spécifiques de ces métriques, consultez Évaluer les résultats de l’expérience de Machine Learning automatisé.

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

Ces métriques s’appliquent à tous les scénarios de classification, y compris les données tabulaires, les images, la vision par ordinateur et le texte de traitement du langage naturel (NLP-Text).

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 Machine Learning 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 Exemples de cas d’utilisation
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, l’« Exactitude » 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 de reconnaissance d’entité nommée de texte NLP

Pour la NER (Reconnaissance d’entité nommée) de texte NLP, l’« Exactitude » 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évision. 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 de la même manière, et les erreurs au carré subissent une pénalité beaucoup plus importante pour les erreurs qui ont de grandes valeurs absolues. Vous pouvez choisir d’optimiser l’erreur au carré ou l’erreur absolue selon la nécessité ou non d’une plus grande sanction pour les erreurs plus importantes.

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 que le modèle peut traduire.

Remarque

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 carrée 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 rang, au lieu de la valeur exacte, est intéressant, spearman_correlation peut être un meilleur choix. Cette donnée mesure la corrélation de classement entre les valeurs réelles et les prévisions.

Le Machine Learning automatisé ne prend actuellement pas en charge les métriques principales qui mesurent la différence relative entre les prévisions 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 le Machine Learning automatisé 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. Elles ne constituent donc pas toujours de bons choix.

Métrique Exemples de cas d’utilisation
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 aux recommandations pour les scénarios de régression.

Métrique Exemples de cas d’utilisation
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’objets 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’instances 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 Machine Learning automatisé, vos données sont automatiquement transformées en nombres et vecteurs de nombres. Les données sont également mises à l’échelle et normalisées pour aider les algorithmes sensibles aux fonctionnalités qui se trouvent à différentes échelles. Ces transformations de données sont appelées caractérisation.

Remarque

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

Lorsque vous configurez des travaux de Machine learning automatisés, vous pouvez activer ou 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' Cela indique que, dans le cadre du prétraitement, des étapes de garde-fous et de caractérisation des données sont exécutées de manière automatique. Cette valeur est le paramétrage 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

Vous pouvez définir quelques options 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 six 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’apprentissage, 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 non spécifiée, une valeur de 1 mois ou de 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. Si cela n’est pas spécifié, la valeur par défaut est 1 000 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

Soumettez l’expérience pour qu’elle s’exécute et génère un modèle.

Remarque

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 dans les modèles générés. Les algorithmes utilisés par le Machine Learning automatisé présentent un fonctionnement aléatoire inhérent qui peut provoquer de légères variations dans la sortie des modèles dues à l’expérience et au score de métrique final du modèle recommandé, comme l’exactitude. 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.

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 agit comme une machine virtuelle individuelle qui peut accomplir une seule exécution d’apprentissage. Pour le Machine Learning 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. S’il existe des nœuds gratuits, la nouvelle expérience exécute des exécutions enfants en parallèle dans les nœuds ou machines virtuelles disponibles.

Pour faciliter la gestion des exécutions enfants et le moment où elles peuvent être effectuées, 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. En l’absence de configuration, le paramétrage par défaut consiste à autoriser une seule exécution/itération enfant simultanée par expérience. Dans le cas d’une instance de calcul, max_concurrent_trials peut être défini sur 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, vous pouvez utiliser un déploiement en un clic à l’aide d’Azure Machine Learning studio. Consultez Déployer un modèle.

Utiliser le Machine Learning automatisé dans les pipelines

Pour utiliser le Machine Learning automatisé dans vos flux de travail d’opérations d’apprentissage automatique, vous pouvez ajouter des étapes de travail de Machine Learning automatisé à vos Pipelines Azure Machine Learning. Cette approche vous permet d’automatiser l’ensemble de votre flux de travail en raccordant vos scripts de préparation des données au Machine Learning automatisé. Enregistrez et validez ensuite le meilleur modèle obtenu.

Ce code est un échantillon de pipeline contenant un composant de classification de Machine Learning automatisé et un composant de commande qui affiche la sortie obtenue. Le code répertorie les entrées (données d’apprentissage et de validation) et les sorties (meilleur modèle) lors des 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 le Machine Learning automatisé dans vos pipelines, consultez le référentiel d’exemples.

Utilisation du Machine Learning automatisé à grande échelle : apprentissage distribué

Pour les scénarios de données volumineux, le Machine Learning automatisé prend en charge l’apprentissage 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, le Machine Learning automatisé peut faire des choix tels que la restriction des caractérisations disponibles et des 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’apprentissage distribué pour la classification ou la régression, vous devez définir les propriétés training_modeet max_nodes de l’objet du travail.

Propriété Description
training_mode Indique le mode d’apprentissage : distributed ou non_distributed. La valeur par défaut est non_distributed.
max_nodes Nombre de nœuds à utiliser pour l’apprentissage ç chaque tentative. 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 fonctionne l’apprentissage distribué pour les tâches de prévision, consultez notre 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 Cette valeur est le 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 lasoumission de travaux pour obtenir des échantillons de code de configuration complet.

Contenu connexe