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 CLI v2 (actuelle)Kit de développement logiciel (SDK) Python azure-ai-ml v2 (version actuelle)
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
- Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer. Essayez la version gratuite ou payante d’Azure Machine Learning.
- Un espace de travail Azure Machine Learning. Si vous n’en avez pas, vous pouvez utiliser les étapes décrites dans l’article Créer des ressources pour démarrer.
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.
- Algorithmes multi-classes de classification d’images.
- Algorithmes multi-étiquettes de classification d’images
- Algorithmes de détection d’objet image
- Algorithmes multi-étiquettes de classification de texte NLP
- Algorithmes NER (Reconnaissance d’entité nommée) de texte NLP
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_error
et 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.
Pour obtenir des définitions et des exemples des graphiques et métriques de performances fournis pour chaque exécution, consultez Évaluer les résultats de l’expérience de Machine Learning automatisé.
Pour obtenir un résumé de caractérisation et comprendre les fonctionnalités qui ont été ajoutées à un modèle particulier, consultez Transparence de la caractérisation.
À 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_mode
et 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_nodes
et é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
- Découvrez plus d’informations sur comment et où déployer un modèle.
- En savoir plus sur la procédure pour configurer AutoML pour effectuer l’apprentissage d’un modèle de prévision de série chronologique.