Configurer l’entraînement AutoML avec le SDK Python Azure ML v2
S’APPLIQUE À : Kit de développement logiciel (SDK) Python azure-ai-mlv2 (préversion)
Dans ce guide, vous allez découvrir comment configurer un travail d’entraînement de Machine Learning automatisé, AutoML, avec le SDK Python Azure Machine Learning v2. Le ML automatisé choisit pour vous un algorithme et des hyperparamètres, et génère un modèle prêt pour le déploiement. Ce guide fournit des détails sur les différentes options que vous pouvez utiliser pour configurer des expériences ML automatisées.
Si vous préférez une expérience sans code, vous pouvez également Configurer un apprentissage AutoML sans code dans Azure Machine Learning Studio.
Si vous préférez envoyer des travaux d’entraînement avec l’extension Azure Machine Learning CLI v2, consultez Effectuer l’apprentissage des modèles.
Prérequis
Pour cet article, vous avez besoin des éléments suivants :
Un espace de travail Azure Machine Learning. Pour créer l’espace de travail, consultez Créer des ressources d’espace de travail.
Le Kit de développement logiciel (SDK) Python Azure Machine Learning v2 installé. 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 AzureML et qui est préconfigurée pour les workflows ML. Consultez Créer et gérer une instance de calcul Azure Machine Learning pour plus d’informations.
Utilisez les commandes suivantes pour installer le SDK Python Azure ML v2 :
- Désinstallez la préversion précédente :
pip uninstall azure-ai-ml
- Installez le SDK Python Azure ML v2 :
pip install azure-ai-ml
Important
Les commandes python de cet article requièrent la dernière
azureml-train-automl
version du package.- Installez le dernier package
azureml-train-automl
dans votre environnement local. - Pour plus d’informations sur le dernier package
azureml-train-automl
, consultez les notes de publication.
Set up your workspace
Pour vous connecter à un espace de travail, vous devez fournir un abonnement, un groupe de ressources et un nom d’espace de travail. Ces détails sont utilisés dans le MLClient
de azure.ai.ml
pour obtenir un handle vers l’espace de travail Azure Machine Learning requis.
Dans l’exemple suivant, l’authentification Azure par défaut est utilisée avec la configuration de l’espace de travail par défaut ou à partir de n’importe quel fichier config.json
que vous avez copié dans la structure des dossiers. Si aucun config.json
n’est trouvé, vous devez spécifier manuellement l’ID d’abonnement, le groupe de ressources et l’espace de travail lors de la création de MLClient
.
from azure.identity import DefaultAzureCredential
from azure.ai.ml import MLClient
credential = DefaultAzureCredential()
ml_client = None
try:
ml_client = MLClient.from_config(credential)
except Exception as ex:
print(ex)
# Enter details of your AzureML workspace
subscription_id = "<SUBSCRIPTION_ID>"
resource_group = "<RESOURCE_GROUP>"
workspace = "<AZUREML_WORKSPACE_NAME>"
ml_client = MLClient(credential, subscription_id, resource_group, workspace)
Source et format des données
Pour fournir des données d’entraînement à AutoML dans le SDK v2, vous devez les charger dans le cloud par le biais d’une MLTable.
Configuration requise pour le chargement de données dans une MLTable :
- Les données doivent être sous forme tabulaire.
- La valeur à prédire, la colonne cible, doit figurer dans les données.
Les données d’entraînement doivent être accessibles à partir de la ressource de calcul distante. Le ML automatisé v2 (SDK Python et CLI/YAML) accepte les ressources de données MLTable (v2), bien qu’à des fins de compatibilité descendante il prenne également en charge les jeux de données tabulaires v1 (un jeu de données tabulaire inscrit) via les mêmes propriétés de jeu de données d’entrée. Toutefois, il est recommandé d’utiliser la MLTable disponible dans v2.
Le code YAML suivant est la définition d’une MLTable qui peut être placée dans un dossier local ou un dossier distant dans le cloud, avec le fichier de données (fichier .CSV ou Parquet).
# MLTable definition file
paths:
- file: ./bank_marketing_train_data.csv
transformations:
- read_delimited:
delimiter: ','
encoding: 'ascii'
Par conséquent, le dossier MLTable contiendrait le fichier de définition de MLTable plus le fichier de données (en l’occurrence, le fichier bank_marketing_train_data.csv).
Voici deux manières différentes de créer une MLTable.
- R. Fournissez vos données d’entraînement et votre fichier de définition de MLTable à partir de votre dossier local, et elles seront automatiquement chargées dans le cloud (magasin de données d’espace de travail par défaut)
- B. Fournissez une MLTable déjà inscrite et chargée dans le cloud.
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import automl, Input
# A. Create MLTable for training data from your local directory
my_training_data_input = Input(
type=AssetTypes.MLTABLE, path="./data/training-mltable-folder"
)
# B. Remote MLTable definition
my_training_data_input = Input(type=AssetTypes.MLTABLE, path="azureml://datastores/workspaceblobstore/paths/Classification/Train")
Formation, validation et test des données
Vous pouvez spécifier des données d’entraînement et des jeux de données de validation distincts, mais les données d’entraînement doivent être fournies au paramètre training_data
dans la fonction de fabrique de votre travail de ML automatisé.
Si vous ne spécifiez pas explicitement un paramètre validation_data
ou n_cross_validation
, le Machine Learning automatisé applique les techniques par défaut pour déterminer la façon dont la validation est effectuée. Cette détermination dépend du nombre de lignes dans le jeu de données affecté à votre paramètre training_data
.
Taille des données d’entraînement | Technique de validation |
---|---|
Plus de 20 000 lignes | Le fractionnement des données de formation/validation est appliqué. La valeur par défaut consiste à prendre 10 % du jeu de données d’apprentissage initial en tant que jeu de validation. Ce jeu de validation est ensuite utilisé pour le calcul des métriques. |
Inférieur ou égal à 20 000 lignes | L’approche de validation croisée est appliquée. Le nombre de plis par défaut dépend du nombre de lignes. Si le jeu de données est inférieur à 1 000 lignes, 10 plis sont utilisés. S’il y a entre 1 000 et 20 000 lignes, trois plis sont utilisés. |
Capacité de calcul pour exécuter l’expérience
Les travaux de ML automatisé avec le SDK Python v2 (ou CLI v2) sont actuellement pris en charge uniquement sur un calcul distant Azure ML (cluster ou instance de calcul).
En savoir plus sur la création de calcul avec Python SDKv2 (ou CLIv2)..
Configurer les paramètres de votre expérience
Vous pouvez utiliser plusieurs options pour configurer des expériences de ML automatisé. Ces paramètres de configuration sont définis dans votre méthode de tâche. Vous pouvez également définir des paramètres d’entraînement du travail et des critères de sortie avec les fonctions set_training()
et set_limits()
, respectivement.
L’exemple suivant montre les paramètres requis pour une tâche de classification qui spécifie la justesse en tant que métrique principale et cinq plis de validation croisée.
# note that the below is a code snippet -- you might have to modify the variable values to run it successfully
classification_job = automl.classification(
compute=my_compute_name,
experiment_name=my_exp_name,
training_data=my_training_data_input,
target_column_name="y",
primary_metric="accuracy",
n_cross_validations=5,
enable_model_explainability=True,
tags={"my_custom_tag": "My custom value"}
)
# Limits are all optional
classification_job.set_limits(
timeout_minutes=600,
trial_timeout_minutes=20,
max_trials=5,
enable_early_termination=True,
)
# Training properties are optional
classification_job.set_training(
blocked_training_algorithms=["LogisticRegression"],
enable_onnx_compatible_models=True
)
Sélectionnez votre type de tâche Machine Learning (problème ML)
Avant de pouvoir soumettre votre travail de ML automatisé, vous devez déterminer le type de problème Machine Learning que vous résolvez. Ce problème détermine la fonction utilisée par votre travail de ML automatisé et les algorithmes de modèle qu’il applique.
Le ML automatisé prend en charge les tâches basées sur des données tabulaires (classification, régression, prévision), les tâches de vision par ordinateur (telles que la classification d’images et la détection d’objet) et les tâches de traitement en langage naturel (telles que les tâches de classification de texte et de reconnaissance d’entité). Découvrez plus d’informations sur les types de tâches.
Algorithmes pris en charge
Le machine learning automatisé essaie différents modèles et algorithmes lors du processus d’automatisation et d’optimisation. En tant qu’utilisateur, vous n’avez pas besoin de spécifier l’algorithme.
La méthode de tâche détermine la liste des algorithmes/modèles à appliquer. Utilisez les paramètres allowed_training_algorithms
ou blocked_training_algorithms
dans la fonction Set set_training()
pour modifier les itérations avec les modèles disponibles à inclure ou à exclure.
Dans la liste de liens suivante, vous pouvez explorer les algorithmes pris en charge par chaque tâche Machine Learning listée ci-dessous.
classification ; | régression ; | Prévision de séries chronologiques |
---|---|---|
Régression logistique* | Elastic Net* | AutoARIMA |
Light GBM* | Light GBM* | Prophet |
Boosting de gradient* | Boosting de gradient* | Elastic Net |
Arbre de décision* | Arbre de décision* | Light GBM |
K plus proches voisins* | K plus proches voisins* | K plus proches voisins |
Linear SVC* | LARS Lasso* | Decision Tree |
Support Vector Classification (SVC)* | Stochastic Gradient Descent (SGD)* | Arimax |
Forêt aléatoire* | Random Forest | LARS Lasso |
Arborescences extrêmement aléatoires* | Arborescences extrêmement aléatoires* | Arborescences extrêmement aléatoires* |
Xgboost* | Xgboost* | Random Forest |
Naive Bayes* | Xgboost | ForecastTCN |
Stochastic Gradient Descent (SGD)* | Stochastic Gradient Descent (SGD) | Gradient Boosting |
ExponentialSmoothing | ||
SeasonalNaive | ||
Moyenne | ||
Naive | ||
SeasonalAverage |
Avec des algorithmes supplémentaires ci-dessous.
- 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.
Toutefois, actuellement, aucune métrique principale pour la régression ne porte sur la différence relative. r2_score
, normalized_mean_absolute_error
et normalized_root_mean_squared_error
traitent chacun une erreur de prédiction de 20 000 $ de la même façon pour un employé avec un salaire de 30 000 $ que pour un employé gagnant 20 millions $, si ces deux points de données appartiennent au même jeu de données pour la régression ou la même série chronologique spécifiée par l’identificateur de série chronologique. Or, en réalité, prévoir seulement 20 000 dollars de réduction sur un salaire de 20 millions de dollars est insignifiant (petite différence relative de 0,1 %), tandis que 20 000 dollars de réduction sur un salaire de 30 000 dollars est tout à fait conséquent (grande différence relative de 67 %). Pour résoudre le problème de différence relative, vous pouvez effectuer l’apprentissage d’un modèle avec les métriques principales disponibles, puis sélectionner le modèle avec la meilleure valeur de mean_absolute_percentage_error
ou root_mean_squared_log_error
.
Métrique | Exemple(s) de cas d’usage |
---|---|
spearman_correlation |
|
normalized_root_mean_squared_error |
Prédiction de prix (maison/produit/pourboire), examen de prédiction de score |
r2_score |
Retard de compagnie aérienne, estimation du salaire, temps de résolution des bogues |
normalized_mean_absolute_error |
Métriques pour les scénarios de prévision de séries chronologiques
Les recommandations sont similaires à celles indiquées pour les scénarios de régression.
Métrique | Exemple(s) de cas d’usage |
---|---|
normalized_root_mean_squared_error |
Prédiction (prévision) de prix, optimisation de stocks, prévision de la demande |
r2_score |
Prédiction (prévision) de prix, optimisation de stocks, prévision de la demande |
normalized_mean_absolute_error |
Métriques pour les scénarios de détection d’objet image
- Pour la détection d’objet image, les métriques principales prises en charge sont définies dans l’énumération ObjectDetectionPrimaryMetrics
Métriques pour les scénarios de segmentation d’instance d’image
- Pour les scénarios de segmentation d’instance d’image, les métriques principales prises en charge sont définies dans l’énumération InstanceSegmentationPrimaryMetrics
Caractérisation de données
Dans chaque expérience de ML automatisé, vos données sont automatiquement transformées en nombres et en vecteurs de nombres plus (autrement dit conversion de texte en texte numérique) également mis à l’échelle et normalisés pour aider certains algorithmes sensibles aux fonctionnalités qui sont à différentes échelles. Cette transformation des données, mise à l’échelle et normalisation est appelée « caractérisation ».
Notes
Les étapes de caractérisation du Machine Learning automatisé (normalisation des fonctionnalités, gestion des données manquantes, conversion de texte en valeurs numériques, etc.) font partie du modèle sous-jacent. Lorsque vous utilisez le modèle pour des prédictions, les étapes de caractérisation qui sont appliquées pendant la formation sont appliquées automatiquement à vos données d’entrée.
Lorsque vous configurez vos travaux de ML automatisé, vous pouvez activer/désactiver les paramètres featurization
à l’aide de la fonction Set .set_featurization()
.
Le tableau suivant présente les paramètres acceptés pour la caractérisation.
Configuration de la caractérisation | Description |
---|---|
"mode": 'auto' |
Indique que, dans le cadre du prétraitement, des étapes de garde-fous des données et de caractérisation sont automatiques. Paramètre par défaut. |
"mode": 'off' |
Indique que l’étape de caractérisation ne doit pas être automatique. |
"mode": 'custom' |
Indique que l’étape de caractérisation personnalisée doit être utilisée. |
Le code suivant montre comment la caractérisation personnalisée peut être fournie dans ce cas pour un travail de régression.
from azure.ai.ml.automl import ColumnTransformer
transformer_params = {
"imputer": [
ColumnTransformer(fields=["CACH"], parameters={"strategy": "most_frequent"}),
ColumnTransformer(fields=["PRP"], parameters={"strategy": "most_frequent"}),
],
}
regression_job.set_featurization(
mode="custom",
transformer_params=transformer_params,
blocked_transformers=["LabelEncoding"],
column_name_and_types={"CHMIN": "Categorical"},
)
Critères de sortie
Il existe quelques options que vous pouvez définir dans la fonction set_limits()
pour mettre fin à votre expérience avant la fin du travail.
Critères | description |
---|---|
Aucun critère | Si vous ne définissez pas de paramètres de sortie, l’expérience continuera jusqu’à ce que votre métrique principale ne progresse plus. |
timeout |
Définit la durée, en minutes, pendant laquelle votre expérience doit continuer à s’exécuter. Si la valeur n’est pas spécifiée, le délai d’expiration total par défaut du travail est de 6 jours (8 640 minutes). Pour spécifier un délai d’expiration inférieur ou égal à 1 heure (60 minutes), vérifiez que la taille de votre jeu de données n’est pas supérieure à 10 000 000 (lignes X colonne), ou une erreur se produira. Ce délai d’expiration inclut la configuration, la caractérisation et les exécutions d’entraînement, mais n’inclut pas les exécutions d’ensembling et d’explicabilité du modèle à la fin du processus, car ces actions doivent se produire une fois que tous les essais (travaux enfants) sont terminés. |
trial_timeout_minutes |
Durée d’exécution maximale en minutes de chaque essai (travail enfant) avant son arrêt. Si cette valeur n’est pas spécifiée, une valeur de un mois ou 43 200 minutes est utilisée |
enable_early_termination |
Indique s’il faut arrêter le travail si le score ne s’améliore pas à court terme |
max_trials |
Nombre maximal d’essais/exécutions chacun avec une combinaison différente d’algorithme et d’hyperparamètres à essayer pendant un travail AutoML. Si cela n’est pas spécifié, la valeur par défaut est 1000 essais. En cas d’utilisation de enable_early_termination , le nombre d’essais utilisés peut être inférieur. |
max_concurrent_trials |
Représente le nombre maximal d’essais (travaux enfants) qui seraient exécutés en parallèle. Une bonne pratique consiste à faire correspondre ce nombre au nombre de nœuds de votre cluster |
Exécuter une expérience
Notes
Si vous exécutez plusieurs fois une expérience avec les mêmes paramètres de configuration et la même métrique principale, vous constaterez probablement des variations dans chaque score de métrique finale d’expériences et de modèles générés. Les algorithmes utilisés par le ML automatisé présentent un fonctionnement aléatoire inhérent qui peut provoquer de légères variations dans la sortie des modèles par l’expérience et le score de métrique final de modèle recommandé, comme la précision. Vous verrez probablement également des résultats avec le même nom de modèle, mais des hyperparamètres différents.
Avertissement
Si vous avez défini des règles dans le pare-feu et/ou le groupe de sécurité réseau sur votre espace de travail, vérifiez que les autorisations requises sont accordées au trafic réseau entrant et sortant, comme défini dans Configurer le trafic réseau entrant et sortant.
Soumettez l’expérience pour qu’elle s’exécute et génère un modèle. Une fois le MLClient
créé dans les prérequis, vous pouvez exécuter la commande suivante dans l’espace de travail.
# Submit the AutoML job
returned_job = ml_client.jobs.create_or_update(
classification_job
) # submit the job to the backend
print(f"Created job: {returned_job}")
# Get a URL for the status of the job
returned_job.services["Studio"].endpoint
Plusieurs exécutions enfants sur des clusters
Les exécutions enfants d’expérimentation ML automatisé peuvent intervenir sur un cluster exécutant déjà une autre expérience. Toutefois, le minutage dépend du nombre de nœuds du cluster et de la disponibilité de ces nœuds pour exécuter une expérience différente.
Chaque nœud du cluster fait office de machine virtuelle individuelle capable d’effectuer une seule exécution d’apprentissage ; en termes de ML automatisé, cela signifie une exécution enfant. Si tous les nœuds sont occupés, la nouvelle expérience est mise en file d’attente. Cela étant, si des nœuds sont disponibles, la nouvelle expérience procède à des exécutions enfants de ML automatisé en parallèle dans les nœuds/machines virtuelles disponibles.
Pour faciliter la gestion des exécutions enfants et le moment où elles peuvent intervenir, nous vous recommandons de créer un cluster dédié par expérience et de faire correspondre le nombre de max_concurrent_iterations
de votre expérience avec le nombre de nœuds du cluster. Ainsi, vous utilisez tous les nœuds du cluster en même temps que les exécutions/itérations enfants simultanées de votre choix.
Configurez max_concurrent_iterations
dans la fonction Set .set_limits(). S’il n’est pas configuré, par défaut, une seule exécution/itération enfant simultanée est autorisée par expérience.
Dans le cas d’une instance de calcul, max_concurrent_trials
peut être défini comme étant le même que le nombre de cœurs sur la machine virtuelle de l’instance de calcul.
Explorer les modèles et les métriques
Le ML automatisé offre des options pour surveiller et évaluer les résultats de l’apprentissage.
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 hyperparamètres utilisés lors de l’entraînement d’un modèle, et afficher et personnaliser le code d’entraînement du modèle interne utilisé.
Inscrire et déployer des modèles
Après avoir testé un modèle et confirmé que vous souhaitez l’utiliser en production, vous pouvez l’inscrire pour une utilisation ultérieure.
Conseil
Pour les modèles enregistrés, le déploiement en un clic est disponible via Azure Machine Learning studio. Découvrez comment déployer des modèles enregistrés à partir de Studio.
AutoML dans les pipelines
Pour tirer parti d’AutoML dans vos workflows MLOps, vous pouvez ajouter des étapes de tâchel AutoML à vos pipelines AzureML. Cela vous permet d’automatiser l’intégralité de votre flux de travail en connectant vos scripts de préparation des données à AutoML, puis en inscrivant et en validant le meilleur modèle résultant.
Voici un exemple de pipeline avec un composant de classification AutoML et un composant de commande qui affiche la sortie AutoML résultante. Notez comment les entrées (données de validation d’apprentissage &) et les sorties (meilleur modèle) sont référencées en différentes étapes.
# Define pipeline
@pipeline(
description="AutoML Classification Pipeline",
)
def automl_classification(
classification_train_data,
classification_validation_data
):
# define the automl classification task with automl function
classification_node = classification(
training_data=classification_train_data,
validation_data=classification_validation_data,
target_column_name="y",
primary_metric="accuracy",
# currently need to specify outputs "mlflow_model" explictly to reference it in following nodes
outputs={"best_model": Output(type="mlflow_model")},
)
# set limits and training
classification_node.set_limits(max_trials=1)
classification_node.set_training(enable_stack_ensemble=False, enable_vote_ensemble=False)
command_func = command(
inputs=dict(
automl_output=Input(type="mlflow_model")
),
command="ls ${{inputs.automl_output}}",
environment="AzureML-sklearn-0.24-ubuntu18.04-py37-cpu:latest"
)
show_output = command_func(automl_output=classification_node.outputs.best_model)
pipeline_classification = automl_classification(
classification_train_data=Input(path="./training-mltable-folder/", type="mltable"),
classification_validation_data=Input(path="./validation-mltable-folder/", type="mltable"),
)
# ...
# Note that the above is only a snippet from the bankmarketing example you can find in our examples repo -> https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs/pipelines/1h_automl_in_pipeline/automl-classification-bankmarketing-in-pipeline
Pour plus d’exemples sur la façon d’inclure AutoML dans vos pipelines, consultez nos exemples de référentiel.
Étapes suivantes
- Découvrez plus d’informations sur comment et où déployer un modèle.