Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’APPLIQUE À :
Extension Azure ML CLI v2 (actuelle)
Kit de développement logiciel (SDK) Python azure-ai-ml v2 (préversion)
Le Machine Learning automatisé (AutoML) dans Azure Machine Learning utilise des modèles Machine Learning standard avec des modèles de série chronologique connus pour créer des prévisions. Cette approche intègre les informations historiques concernant la variable cible aux fonctionnalités fournies par l’utilisateur dans les données d’entrée, ainsi qu’aux fonctionnalités générées automatiquement. Les algorithmes de recherche de modèles permettent d’identifier les modèles présentant la meilleure précision prédictive. Pour en savoir plus, consultez la méthodologie de prévision ainsi que le balayage et la sélection de modèles.
Cet article explique comment configurer AutoML pour la prévision de série chronologique avec Machine Learning à l’aide du Kit de développement logiciel (SDK) Python Azure Machine Learning et d’Azure CLI. Le processus inclut la préparation des données pour l’apprentissage et la configuration des paramètres de série chronologique dans un travail de prévision (référence de classe). Vous entraînez ensuite les modèles, effectuez l’inférence et les évaluez en utilisant des composants et des pipelines.
Pour une expérience low-code, consultez Didacticiel : Prévoir la demande avec le Machine Learning automatisé. Cet article fournit un exemple de prévision de série chronologique qui utilise AutoML dans Azure Machine Learning Studio.
Prérequis
- Un espace de travail Azure Machine Learning. Pour plus d’informations, consultez Créer des ressources d’espace de travail.
- Possibilité de démarrer des travaux d’apprentissage AutoML. Pour en savoir plus, consultez Configurer l’entraînement AutoML pour des données tabulaires avec l’interface CLI d’Azure Machine Learning et le SDK Python.
Préparer les données d’entraînement et de validation
Les données d’entrée pour la prévision AutoML doivent contenir une série temporelle valide au format tabulaire. Chaque variable doit avoir sa propre colonne correspondante dans la table de données. AutoML requiert au moins deux colonnes : une colonne de temps pour représenter l’axe temporel et une colonne cible pour indiquer la quantité à prévoir. D’autres colonnes peuvent servir de prédicteurs. Pour en savoir plus, consultez Comment AutoML utilise vos données.
Important
Lorsque vous entraînez un modèle pour la prévision de valeurs futures, assurez-vous que toutes les fonctionnalités utilisées dans l’entraînement peuvent également être utilisées lors de l’exécution de prédictions pour votre horizon prévu.
Envisagez une fonctionnalité pour le prix actuel des actions, ce qui peut augmenter la précision de l'apprentissage. Si vous prévoyez avec un horizon long, il se peut que vous ne puissiez pas prédire avec précision les valeurs futures des actions qui correspondent aux futurs points de série chronologique. Cette approche peut réduire la précision du modèle.
Les tâches de prévision AutoML exigent que vos données d’entraînement soient représentées sous la forme d’un objet MLTable. Un objet MLTable spécifie une source de données ainsi que les étapes de chargement de ces données. Pour plus d’informations et de cas d’usage, consultez Utilisation des tables.
Pour l’exemple suivant, supposons que vos données d’apprentissage sont contenues dans un fichier CSV dans un répertoire local : ./train_data/timeseries_train.csv.
Vous pouvez créer un MLTable objet à l’aide du membre du Kit de développement logiciel (SDK) Python mltable :
import mltable
paths = [
{'file': './train_data/timeseries_train.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.
Pour démarrer le travail d’apprentissage, définissez un objet de données d’entrée à l’aide du Kit de développement logiciel (SDK) Python :
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import Input
# Training MLTable defined locally, with local data to be uploaded.
my_training_data_input = Input(
type=AssetTypes.MLTABLE, path="./train_data"
)
Vous spécifiez les données de validation de la même manière. Créez un objet MLTable et spécifiez une entrée de données de validation. Sinon, si vous ne fournissez pas de données de validation, AutoML crée automatiquement des fractionnements de validation croisée à partir de vos données de formation à utiliser pour la sélection du modèle. Pour plus d’informations, consultez les ressources suivantes :
- Sélectionner des modèles de prévision
- Définir les exigences de longueur des données d’entraînement
- Empêcher le surajustement avec la validation croisée
Créer un calcul pour exécuter l’expérience
AutoML utilise le calcul Azure Machine Learning, qui est une ressource de calcul entièrement managée, pour exécuter le travail d’entraînement.
L’exemple suivant crée un cluster de calcul dénommé cpu-cluster.
from azure.ai.ml.entities import AmlCompute
# specify aml compute name.
cpu_compute_target = "cpu-cluster"
try:
ml_client.compute.get(cpu_compute_target)
except Exception:
print("Creating a new cpu compute target...")
compute = AmlCompute(
name=cpu_compute_target, size="STANDARD_D2_V2", min_instances=0, max_instances=4
)
ml_client.compute.begin_create_or_update(compute).result()Configurer l’expérience
L’exemple suivant montre comment configurer l’expérience.
Vous utilisez les fonctions factory AutoML pour configurer les tâches de prévision dans le SDK Python. L’exemple suivant montre comment créer une tâche de prévision en définissant la métrique principale et en imposant des limites à l’exécution de l’entraînement :
from azure.ai.ml import automl
# Set forecasting variables.
# As needed, modify the variable values to run the snippet successfully.
forecasting_job = automl.forecasting(
compute="cpu-compute",
experiment_name="sdk-v2-automl-forecasting-job",
training_data=my_training_data_input,
target_column_name=target_column_name,
primary_metric="normalized_root_mean_squared_error",
n_cross_validations="auto",
)
# Set optional limits.
forecasting_job.set_limits(
timeout_minutes=120,
trial_timeout_minutes=30,
max_concurrent_trials=4,
)
Paramètres de la tâche de prévision
Les tâches de prévision ont de nombreux paramètres propres à la prévision. Les paramètres les plus basiques sont le nom de la colonne temporelle dans les données d’entraînement et l’horizon de prévision.
Utilisez les méthodes ForecastingJob pour configurer ces paramètres :
# Forecasting-specific configuration.
forecasting_job.set_forecast_settings(
time_column_name=time_column_name,
forecast_horizon=24
)
Le nom de la colonne temporelle est un paramètre obligatoire. Vous devriez généralement définir l’horizon de prévision en fonction de votre scénario de prédiction. Si vos données contiennent plusieurs séries chronologiques, vous pouvez spécifier le nom des colonnes d’ID de série chronologique. Lorsque ces colonnes sont groupées, elles définissent les séries individuelles. Par exemple, supposons que vous disposiez de données constituées de ventes horaires provenant de différents magasins et différentes marques. L’exemple suivant montre comment définir les colonnes d’ID de série chronologique, en supposant que les données contiennent des colonnes nommées magasin et marque :
# Forecasting-specific configuration.
# Add time series IDs for store and brand.
forecasting_job.set_forecast_settings(
..., # Other settings.
time_series_id_column_names=['store', 'brand']
)
AutoML tente de détecter automatiquement les colonnes d’identifiant de série temporelle dans vos données si aucune n’est spécifiée.
D’autres paramètres sont facultatifs et décrits dans la section suivante.
Paramètres optionnels de la tâche de prévision
Les configurations facultatives sont disponibles pour les tâches de prévision, telles que l’activation du deep learning et la spécification d’une agrégation de fenêtres propagées cible. Une liste complète des paramètres est disponible dans la documentation de référence.
Paramètres de recherche de modèle
Il existe deux paramètres facultatifs qui contrôlent l’espace du modèle où AutoML recherche le meilleur modèle : allowed_training_algorithms et blocked_training_algorithms. Pour restreindre l’espace de recherche à un ensemble donné de classes de modèle, utilisez le allowed_training_algorithms paramètre, comme indiqué ici :
# Only search ExponentialSmoothing and ElasticNet models.
forecasting_job.set_training(
allowed_training_algorithms=["ExponentialSmoothing", "ElasticNet"]
)
Dans ce scénario, le travail de prévision recherche uniquement les classes de modèle ExponentialSmoothing et ElasticNet. Pour supprimer un ensemble donné de classes de modèle de l’espace de recherche, utilisez blocked_training_algorithms, comme indiqué ici :
# Search over all model classes except Prophet.
forecasting_job.set_training(
blocked_training_algorithms=["Prophet"]
)
Le travail recherche toutes les classes de modèle à l’exception de Prophet. Pour obtenir la liste des noms de modèles de prévision acceptés dans allowed_training_algorithms et blocked_training_algorithms, consultez les propriétés d’entraînement. Vous pouvez appliquer soit allowed_training_algorithms, soit blocked_training_algorithms à une exécution d’entraînement, mais pas les deux.
Activer l’apprentissage pour les réseaux neuronaux profonds
AutoML est livré avec un modèle personnalisé de réseau neuronal profond (DNN) nommé TCNForecaster. Ce modèle est un réseau convolutionnel temporel (TCN), qui applique des méthodes couramment utilisées pour les tâches d’imagerie à la modélisation de séries temporelles. Des convolutions unidimensionnelles « causales » constituent l’ossature du réseau et permettent au modèle d’apprendre des motifs complexes sur de longues durées dans l’historique d’entraînement Pour plus d’informations : reportez-vous à la rubrique Présentation de TCNForecaster
TCNForecaster obtient souvent une précision plus élevée que les modèles de série chronologique standard lorsqu’il y a des milliers d’observations ou plus dans l’historique de formation. Toutefois, former et passer en revue les modèles TCNForecaster prend également plus de temps en raison de leur capacité plus élevée.
Vous pouvez activer TCNForecaster dans AutoML en définissant l’indicateur enable_dnn_training dans la configuration d’entraînement, comme suit :
# Include TCNForecaster models in the model search.
forecasting_job.set_training(
enable_dnn_training=True
)
Par défaut, l’entraînement de TCNForecaster est limité à un seul nœud de calcul et à un seul GPU, si disponible, par essai de modèle. Pour les scénarios impliquant de grandes quantités de données, il est recommandé de répartir chaque essai TCNForecaster sur plusieurs cœurs/GPU et plusieurs nœuds. Pour obtenir plus d’informations et consulter des exemples de code, voir la formation distribuée.
Pour activer DNN pour une expérience AutoML créée dans Azure Machine Learning Studio, consultez les paramètres de type de tâche dans l’article de l’interface utilisateur de Studio.
Remarque
- Lorsque vous activez DNN pour les expériences créées avec le Kit de développement logiciel (SDK), les meilleures explications des modèles sont désactivées.
- La prise en charge de DNN pour la prévision dans l'apprentissage automatique automatisé n'est pas disponible pour les exécutions lancées dans Azure Databricks.
- L’approche recommandée consiste à utiliser des types de calcul GPU lorsque l’entraînement DNN est activé.
Fonctionnalités de décalage et de fenêtre glissante
Les valeurs récentes de la cible sont souvent des fonctionnalités impactantes dans un modèle de prévision. En conséquence, AutoML peut créer des caractéristiques décalées dans le temps ainsi que des caractéristiques d’agrégation basées sur des fenêtres glissantes afin d’améliorer potentiellement la précision du modèle.
Envisagez un scénario de prévision de la demande d’énergie dans lequel des données météorologiques et une demande historique sont disponibles. Le tableau montre l’ingénierie de caractéristiques obtenue qui se produit lors de l’application de l’agrégation de fenêtres sur les trois dernières heures. Les colonnes pour minimum, maximum, et somme sont générées sur une fenêtre glissante de trois heures en fonction des paramètres définis. Par exemple, pour l’observation valide le 8 septembre 2017, 4:00, les valeurs maximales, minimales et de somme sont calculées à l’aide des valeurs de demande pour le 8 septembre 2017, 1:00 - 3:00 AM. Cette fenêtre de trois heures se déplace de façon à remplir les données des lignes restantes. Pour obtenir plus d’informations et voir des exemples, consultez les Caractéristiques de décalage pour la prévision de séries temporelles dans AutoML.
Une table avec des données qui montre la fenêtre glissante cible. Les valeurs de la colonne Demande sont mises en surbrillance.
Vous pouvez activer les caractéristiques de décalage et d’agrégation par fenêtre glissante pour la variable cible en définissant la taille de la fenêtre glissante et les ordres de décalage que vous souhaitez créer. La taille de la fenêtre est de trois dans l’exemple précédent. Vous pouvez également activer les latences pour les fonctionnalités en utilisant le paramètre feature_lags. Dans l’exemple suivant, tous ces paramètres sont définis sur auto afin d’indiquer à AutoML de déterminer automatiquement les paramètres en analysant la structure de corrélation de vos données :
forecasting_job.set_forecast_settings(
..., # Other settings.
target_lags='auto',
target_rolling_window_size='auto',
feature_lags='auto'
)
Gestion des séries courtes
AutoML considère une série chronologique comme une série courte si le nombre de points de données est insuffisant pour mener les phases d’apprentissage et de validation du développement du modèle. Pour en savoir plus, consultez les exigences de longueur des données d’entraînement.
AutoML a plusieurs actions qu’il peut effectuer pour les séries courtes. Vous pouvez configurer ces actions à l’aide du short_series_handling_config paramètre. La valeur par défaut est auto. La table suivante décrit les paramètres :
| Réglage | Descriptif | Remarques |
|---|---|---|
auto |
Valeur par défaut pour la gestion des séries courtes. | - Si toutes les séries sont courtes, complétez les données. - Si toutes les séries ne sont pas courtes, supprimez les séries courtes. |
pad |
Si le paramètre short_series_handling_config = pad est utilisé, AutoML ajoute des valeurs aléatoires à chaque série courte détectée. AutoML complète la colonne cible avec du bruit blanc. |
Vous pouvez utiliser les types de colonnes suivants avec le remplissage spécifié : - Colonnes d’objet, remplir avec des NaN. - Colonnes numériques, remplir avec 0 (zéro). - Colonnes booléennes/logiques, complétez avec False. |
drop |
Si le paramètre short_series_handling_config = drop est utilisé, AutoML supprime les séries courtes, qui ne sont alors utilisées ni pour l’entraînement ni pour la prédiction. |
Les prédictions de ces séries retournent NaN. |
None |
Aucune série n’est remplie ou supprimée. |
L’exemple suivant définit la gestion des séries courtes afin que toutes les séries courtes soient ajustées à la longueur minimale :
forecasting_job.set_forecast_settings(
..., # Other settings.
short_series_handling_config='pad'
)
Attention
Le remplissage peut affecter la précision du modèle obtenu, car il introduit des données artificielles pour éviter les échecs d’entraînement. Si la plupart des séries sont courtes, vous pouvez également constater un impact sur les résultats de l’explicabilité.
Fréquence et agrégation des données cibles
Utilisez les options de fréquence et d’agrégation de données pour éviter les défaillances causées par des données irrégulières. Vos données sont irrégulières si elles ne suivent pas une cadence définie dans le temps, par exemple toutes les heures ou tous les jours. Les données de point de vente sont un bon exemple de données irrégulières. Dans ces scénarios, AutoML peut agréger vos données à la fréquence souhaitée, puis construire un modèle de prévision à partir de ces agrégats.
Vous devez définir les paramètres frequency et target_aggregate_function pour gérer les données irrégulières. Le paramètre de fréquence accepte les chaînes Pandas DateOffset comme entrée. La table suivante présente les valeurs prises en charge pour la fonction d’agrégation :
| Fonction | Descriptif |
|---|---|
sum |
Somme des valeurs cibles |
mean |
Moyenne des valeurs cibles |
min |
Valeur minimale d’une cible |
max |
Valeur maximale d’une cible |
AutoML applique l’agrégation aux colonnes suivantes :
| Colonne | Méthode d’agrégation |
|---|---|
| Prédicteurs numériques | AutoML utilise les fonctions sum, mean, min et max. Elle génère de nouvelles colonnes. Chaque nom de colonne inclut un suffixe qui identifie le nom de la fonction d’agrégation appliquée aux valeurs de colonne. |
| Prédicteurs catégoriels | AutoML utilise la valeur du paramètre forecast_mode pour agréger les données. C’est la catégorie la plus représentée dans la fenêtre. Pour plus d'informations, consultez les descriptions des paramètres dans les sections du pipeline 'Many-models' et du pipeline HTS. |
| Prédicteurs de données | AutoML utilise la valeur cible minimale (min), la valeur cible maximale (max) et les paramètres forecast_mode pour agréger les données. |
| Cible | AutoML agrège les valeurs selon l’opération spécifiée. En général, la fonction sum convient à la plupart des scénarios. |
L’exemple suivant définit la fréquence sur toutes les heures et la fonction d’agrégation sur la somme :
# Aggregate the data to hourly frequency.
forecasting_job.set_forecast_settings(
..., # Other settings.
frequency='H',
target_aggregate_function='sum'
)
Paramètres de validation croisée personnalisés
Deux paramètres personnalisables contrôlent la validation croisée pour les tâches de prévision. Personnalisez le nombre de plis à l’aide du paramètre n_cross_validations et configurez le paramètre cv_step_size pour définir le décalage temporel entre les plis. Pour en savoir plus, consultez la sélection des modèles de prévision.
Par défaut, AutoML définit automatiquement ces deux paramètres en fonction des caractéristiques de vos données. Les utilisateurs avancés peuvent souhaiter les définir manuellement. Par exemple, supposons que vous disposez de données de ventes quotidiennes et que votre configuration de validation se compose de cinq replis avec un décalage de sept jours entre les replis adjacents. L’exemple de code suivant montre comment définir ces valeurs :
from azure.ai.ml import automl
# Create a job with five CV folds.
forecasting_job = automl.forecasting(
..., # Other training parameters.
n_cross_validations=5,
)
# Set the step size between folds to seven days.
forecasting_job.set_forecast_settings(
..., # Other settings.
cv_step_size=7
)
Caractérisation personnalisée
Par défaut, AutoML augmente les données de formation avec des fonctionnalités développées pour augmenter la précision des modèles. Pour plus d’informations, consultez l’ingénierie automatisée des fonctionnalités. Vous pouvez personnaliser certaines étapes de prétraitement à l’aide de la configuration de caractérisation du travail de prévision.
La table suivante répertorie les personnalisations prises en charge pour la prévision :
| Personnalisation | Descriptif | Paramètres |
|---|---|---|
| Mise à jour de l’objectif de la colonne | Remplacer le type de caractéristique détecté automatiquement pour la colonne spécifiée. |
categorical, dateTimenumeric |
| Mise à jour des paramètres du transformateur | Mettez à jour les paramètres du processeur d’imputation spécifié. |
{"strategy": "constant", "fill_value": <value>}, {"strategy": "median"}{"strategy": "ffill"} |
Par exemple, supposons que vous ayez un scénario de demande dans le commerce de détail où les données incluent les prix, un indicateur on sale et un type de produit. L’exemple suivant montre comment définir des types personnalisés et des méthodes d’imputation pour ces caractéristiques :
from azure.ai.ml.automl import ColumnTransformer
# Customize imputation methods for price and is_on_sale features.
# Median value imputation for price, constant value of zero for is_on_sale.
transformer_params = {
"imputer": [
ColumnTransformer(fields=["price"], parameters={"strategy": "median"}),
ColumnTransformer(fields=["is_on_sale"], parameters={"strategy": "constant", "fill_value": 0}),
],
}
# Set the featurization.
# Ensure product_type feature is interpreted as categorical.
forecasting_job.set_featurization(
mode="custom",
transformer_params=transformer_params,
column_name_and_types={"product_type": "Categorical"},
)
Si vous utilisez Azure Machine Learning Studio pour votre expérience, consultez la section Configurer les paramètres de caractérisation dans le studio.
Envoyer le travail de prévision
Après avoir configuré tous les paramètres, vous êtes prêt à exécuter le travail de prévision. L’exemple ci-dessous illustre ce processus.
# Submit the AutoML job.
returned_job = ml_client.jobs.create_or_update(
forecasting_job
)
print(f"Created job: {returned_job}")
# Get a URL for the job in the studio UI.
returned_job.services["Studio"].endpoint
Après avoir soumis la tâche, AutoML provisionne les ressources de calcul, applique la caractérisation et les autres étapes de préparation aux données d’entrée, puis commence à explorer différents modèles de prévision. Pour plus d’informations, consultez la méthodologie de prévision dans AutoML et Le balayage et la sélection du modèle pour la prévision dans AutoML.
Orchestrer l’apprentissage, l’inférence et l’évaluation à l’aide de composants et de pipelines
Votre flux de travail Machine Learning nécessite probablement plus qu’une simple formation. L’inférence, c’est-à-dire l’obtention des prédictions du modèle sur de nouvelles données, et l’évaluation de la précision du modèle sur un jeu de test comportant des valeurs cibles connues sont d’autres tâches courantes que vous pouvez orchestrer dans Azure Machine Learning en complément des tâches d’entraînement Pour prendre en charge les tâches d’inférence et d’évaluation, Azure Machine Learning fournit des composants, qui sont des éléments de code autonomes exécutant une étape dans un pipeline Azure Machine Learning.
L’exemple suivant récupère le code du composant à partir d’un registre client :
from azure.ai.ml import MLClient
from azure.identity import DefaultAzureCredential, InteractiveBrowserCredential
# Get credential to access azureml registry.
try:
credential = DefaultAzureCredential()
# Check if token can be obtained successfully.
credential.get_token("https://management.azure.com/.default")
except Exception as ex:
# Fall back to InteractiveBrowserCredential in case DefaultAzureCredential fails.
credential = InteractiveBrowserCredential()
# Create client to access assets in azureml-preview registry.
ml_client_registry = MLClient(
credential=credential,
registry_name="azureml-preview"
)
# Create client to access assets in azureml registry.
ml_client_metrics_registry = MLClient(
credential=credential,
registry_name="azureml"
)
# Get inference component from registry.
inference_component = ml_client_registry.components.get(
name="automl_forecasting_inference",
label="latest"
)
# Get component to compute evaluation metrics from registry.
compute_metrics_component = ml_client_metrics_registry.components.get(
name="compute_metrics",
label="latest"
)
Définissez ensuite une fonction factory qui crée des pipelines orchestrant l’entraînement, l’inférence et le calcul des métriques. Pour plus d’informations, consultez Configurer l’expérience.
from azure.ai.ml import automl
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml.dsl import pipeline
@pipeline(description="AutoML Forecasting Pipeline")
def forecasting_train_and_evaluate_factory(
train_data_input,
test_data_input,
target_column_name,
time_column_name,
forecast_horizon,
primary_metric='normalized_root_mean_squared_error',
cv_folds='auto'
):
# Configure training node of pipeline.
training_node = automl.forecasting(
training_data=train_data_input,
target_column_name=target_column_name,
primary_metric=primary_metric,
n_cross_validations=cv_folds,
outputs={"best_model": Output(type=AssetTypes.MLFLOW_MODEL)},
)
training_node.set_forecasting_settings(
time_column_name=time_column_name,
forecast_horizon=max_horizon,
frequency=frequency,
# Other settings.
...
)
training_node.set_training(
# Training parameters.
...
)
training_node.set_limits(
# Limit settings.
...
)
# Configure inference node to make rolling forecasts on test set.
inference_node = inference_component(
test_data=test_data_input,
model_path=training_node.outputs.best_model,
target_column_name=target_column_name,
forecast_mode='rolling',
step=1
)
# Configure metrics calculation node.
compute_metrics_node = compute_metrics_component(
task="tabular-forecasting",
ground_truth=inference_node.outputs.inference_output_file,
prediction=inference_node.outputs.inference_output_file,
evaluation_config=inference_node.outputs.evaluation_config_output_file
)
# Return dictionary with evaluation metrics and raw test set forecasts.
return {
"metrics_result": compute_metrics_node.outputs.evaluation_result,
"rolling_fcst_result": inference_node.outputs.inference_output_file
}
Définissez les entrées de données d’entraînement et de test qui se trouvent dans les dossiers locaux ./train_data et ./test_data.
my_train_data_input = Input(
type=AssetTypes.MLTABLE,
path="./train_data"
)
my_test_data_input = Input(
type=AssetTypes.URI_FOLDER,
path='./test_data',
)
Enfin, construisez le pipeline, définissez son calcul par défaut, puis soumettez la tâche :
pipeline_job = forecasting_train_and_evaluate_factory(
my_train_data_input,
my_test_data_input,
target_column_name,
time_column_name,
forecast_horizon
)
# Set pipeline-level compute.
pipeline_job.settings.default_compute = compute_name
# Submit pipeline job.
returned_pipeline_job = ml_client.jobs.create_or_update(
pipeline_job,
experiment_name=experiment_name
)
returned_pipeline_job
Après avoir soumis la requête d’exécution, le pipeline effectue successivement l’entraînement AutoML, l’inférence avec évaluation glissante et le calcul des métriques. Vous pouvez surveiller et inspecter l’exécution dans l’interface du studio. Lorsque l’exécution est terminée, vous pouvez télécharger les prévisions glissantes et les métriques d’évaluation dans le répertoire de travail local :
# Download metrics JSON.
ml_client.jobs.download(returned_pipeline_job.name, download_path=".", output_name='metrics_result')
# Download rolling forecasts.
ml_client.jobs.download(returned_pipeline_job.name, download_path=".", output_name='rolling_fcst_result')
Vous pouvez consulter la sortie aux emplacements suivants :
- Métriques : ./named-outputs/metrics_results/evaluationResult/metrics.json
- Prévisions : ./named-outputs/rolling_fcst_result/inference_output_file (format lignes JSON)
Pour plus d’informations sur l’évaluation glissante, consultez la section Inférence et évaluation des modèles de prévision.
Prévision à grande échelle : de nombreux modèles
Les composants de plusieurs modèles dans AutoML vous permettent d’entraîner et de gérer des millions de modèles en parallèle. Pour plus d’informations, consultez De nombreux modèles.
Configuration d'entraînement de modèles multiples
Le composant d'entraînement multi-modèles accepte un fichier de configuration au format YAML pour les paramètres d’entraînement AutoML. Le composant applique ces paramètres à chaque instance AutoML qu’il démarre. Le fichier YAML a la même spécification que la commande de prévision, ainsi que les paramètres partition_column_names et allow_multi_partitions.
| Paramètre | Descriptif |
|---|---|
partition_column_names |
Noms de colonnes dans les données qui, lorsqu’elles sont groupées, définissent les partitions de données. LLe composant d’entraînement multi-modèles lance une tâche d’entraînement indépendante sur chaque partition. |
allow_multi_partitions |
Un indicateur optionnel permettant d’entraîner un modèle par partition lorsque chaque partition contient plus d’une série temporelle unique. La valeur par défaut est false. |
Voici un exemple de configuration YAML :
$schema: https://azuremlsdk2.blob.core.windows.net/preview/0.0.1/autoMLJob.schema.json
type: automl
description: A time-series forecasting job config
compute: azureml:<cluster-name>
task: forecasting
primary_metric: normalized_root_mean_squared_error
target_column_name: sales
n_cross_validations: 3
forecasting:
time_column_name: date
time_series_id_column_names: ["state", "store"]
forecast_horizon: 28
training:
blocked_training_algorithms: ["ExtremeRandomTrees"]
limits:
timeout_minutes: 15
max_trials: 10
max_concurrent_trials: 4
max_cores_per_trial: -1
trial_timeout_minutes: 15
enable_early_termination: true
partition_column_names: ["state", "store"]
allow_multi_partitions: false
Dans les exemples suivants, la configuration est stockée sur le chemin ./automl_settings_mm.yml.
Pipeline multi-modèles
Ensuite, vous allez définir une fonction de fabrique qui crée des pipelines pour l’orchestration de nombreux modèles d’apprentissage, d’inférence et de calcul de métriques. La table suivante décrit les paramètres pour cette fonction factory :
| Paramètre | Descriptif |
|---|---|
max_nodes |
Nombre de nœuds de calcul à utiliser pour la tâche d’entraînement. |
max_concurrency_per_node |
Nombre de processus AutoML à exécuter sur chaque nœud. La concurrence totale d’une tâche multi-modèles est max_nodes * max_concurrency_per_node. |
parallel_step_timeout_in_seconds |
De nombreux modèles disposent d'un délai d’expiration du composant, spécifié en nombre de secondes. |
retrain_failed_models |
Indicateur permettant d’activer le réentraînement pour les modèles ayant échoué. Cette valeur est utile si vous avez effectué des exécutions de plusieurs modèles précédents qui ont entraîné l’échec des travaux AutoML sur certaines partitions de données. Lorsque vous activez cet indicateur, de nombreux modèles exécutent uniquement des travaux d’entraînement pour les partitions ayant échoué précédemment. |
forecast_mode |
Mode d’inférence pour l’évaluation du modèle. Les valeurs valides sont recursive (valeur par défaut) et rolling. Pour en savoir plus, consultez Inférence et évaluation des modèles de prévision et la référence classe ManyModelsInferenceParameters. |
step |
Taille de pas pour la prévision glissante. La valeur par défaut est 1. Pour en savoir plus, consultez Inférence et évaluation des modèles de prévision et la référence classe ManyModelsInferenceParameters. |
L’exemple suivant illustre une méthode factory permettant de construire des pipelines d’entraînement multi-modèles et d’évaluation de modèles :
from azure.ai.ml import MLClient
from azure.identity import DefaultAzureCredential, InteractiveBrowserCredential
# Get credential to access azureml registry.
try:
credential = DefaultAzureCredential()
# Check whether token can be obtained.
credential.get_token("https://management.azure.com/.default")
except Exception as ex:
# Fall back to InteractiveBrowserCredential if DefaultAzureCredential fails.
credential = InteractiveBrowserCredential()
# Get many-models training component.
mm_train_component = ml_client_registry.components.get(
name='automl_many_models_training',
version='latest'
)
# Get many-models inference component.
mm_inference_component = ml_client_registry.components.get(
name='automl_many_models_inference',
version='latest'
)
# Get component to compute evaluation metrics.
compute_metrics_component = ml_client_metrics_registry.components.get(
name="compute_metrics",
label="latest"
)
@pipeline(description="AutoML Many Models Forecasting Pipeline")
def many_models_train_evaluate_factory(
train_data_input,
test_data_input,
automl_config_input,
compute_name,
max_concurrency_per_node=4,
parallel_step_timeout_in_seconds=3700,
max_nodes=4,
retrain_failed_model=False,
forecast_mode="rolling",
forecast_step=1
):
mm_train_node = mm_train_component(
raw_data=train_data_input,
automl_config=automl_config_input,
max_nodes=max_nodes,
max_concurrency_per_node=max_concurrency_per_node,
parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
retrain_failed_model=retrain_failed_model,
compute_name=compute_name
)
mm_inference_node = mm_inference_component(
raw_data=test_data_input,
max_nodes=max_nodes,
max_concurrency_per_node=max_concurrency_per_node,
parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
optional_train_metadata=mm_train_node.outputs.run_output,
forecast_mode=forecast_mode,
step=forecast_step,
compute_name=compute_name
)
compute_metrics_node = compute_metrics_component(
task="tabular-forecasting",
prediction=mm_inference_node.outputs.evaluation_data,
ground_truth=mm_inference_node.outputs.evaluation_data,
evaluation_config=mm_inference_node.outputs.evaluation_configs
)
# Return metrics results from rolling evaluation.
return {
"metrics_result": compute_metrics_node.outputs.evaluation_result
}
Construisez le pipeline à l’aide de la fonction factory. Les données d’entraînement et de test se trouvent dans les dossiers locaux ./data/train et ./data/test. Enfin, définissez le calcul par défaut et soumettez la tâche comme illustré dans l’exemple suivant :
pipeline_job = many_models_train_evaluate_factory(
train_data_input=Input(
type="uri_folder",
path="./data/train"
),
test_data_input=Input(
type="uri_folder",
path="./data/test"
),
automl_config=Input(
type="uri_file",
path="./automl_settings_mm.yml"
),
compute_name="<cluster name>"
)
pipeline_job.settings.default_compute = "<cluster name>"
returned_pipeline_job = ml_client.jobs.create_or_update(
pipeline_job,
experiment_name=experiment_name,
)
ml_client.jobs.stream(returned_pipeline_job.name)
Une fois la tâche terminée, vous pouvez télécharger localement les métriques d’évaluation en suivant la procédure décrite dans le pipeline d’exécution d’entraînement unique.
Pour obtenir un exemple plus détaillé, consultez la prévision de la demande à l’aide de plusieurs modèles notebook.
Considérations relatives à l’apprentissage pour une exécution de plusieurs modèles
Les composants d’apprentissage et d’inférence de plusieurs modèles partitionnent conditionnellement vos données en fonction du
partition_column_namesparamètre. Ce processus a pour résultat que chaque partition se retrouve dans son propre fichier. Le processus peut être lent ou défaillant lorsque vous avez beaucoup de données. Nous vous recommandons de partitionner vos données manuellement avant d’exécuter une formation ou une inférence de plusieurs modèles.Lors de l’apprentissage de plusieurs modèles, les modèles sont automatiquement inscrits dans l’espace de travail. L’inscription manuelle des modèles n’est donc pas nécessaire. Les modèles sont nommés en fonction de la partition sur laquelle ils ont été formés, et ces noms ne sont pas personnalisables. Les balises ne sont pas personnalisables. Ces propriétés sont utilisées pour détecter automatiquement les modèles pendant l’inférence.
Le déploiement de modèles individuels n’est pas évolutif, mais vous pouvez l’utiliser
PipelineComponentBatchDeploymentpour faciliter le processus de déploiement. Pour obtenir un exemple, consultez le notebook Prévision de la demande à l’aide de plusieurs modèles.Pendant l’inférence, les modèles appropriés (la dernière version) sont automatiquement sélectionnés en fonction de la partition envoyée dans les données d’inférence. Par défaut, lorsque vous utilisez
training_experiment_name, le dernier modèle est utilisé, mais vous pouvez remplacer ce comportement pour sélectionner des modèles à partir d’une exécution d’entraînement particulière en fournissanttrain_run_idégalement .
Remarque
La limite de parallélisme par défaut pour exécuter de nombreux modèles dans un abonnement est de 320. Si votre charge de travail nécessite une limite plus élevée, vous pouvez contacter le support Microsoft.
Prévision à grande échelle : séries temporelles hiérarchiques
Les composants de série chronologique hiérarchique (HTS) dans AutoML vous permettent d’entraîner un grand nombre de modèles sur des données qui se trouve dans une structure hiérarchique. Pour plus d’informations, consultez Prévision de séries chronologiques hiérarchiques.
Configuration de l’entraînement HTS
Le composant d’entraînement HTS accepte un fichier de configuration au format YAML contenant les paramètres d’entraînement AutoML Le composant applique ces paramètres à chaque instance AutoML qu’il exécute. Ce fichier YAML a la même spécification que le travail de commande Forecasting, mais inclut d’autres paramètres liés aux informations de hiérarchie :
| Paramètre | Descriptif |
|---|---|
hierarchy_column_names |
Une liste de noms de colonnes dans les données qui définissent la structure hiérarchique des données L’ordre des colonnes de cette liste détermine les niveaux de hiérarchie. Le degré d’agrégation diminue avec l’index de liste. Cela signifie que la dernière colonne de la liste définit le niveau feuille c’est-à-dire le niveau le plus détaillé de la hiérarchie. |
hierarchy_training_level |
Le niveau de hiérarchie à utiliser pour entraîner le modèle de prévision. |
Voici un exemple de configuration YAML :
$schema: https://azuremlsdk2.blob.core.windows.net/preview/0.0.1/autoMLJob.schema.json
type: automl
description: A time-series forecasting job config
compute: azureml:cluster-name
task: forecasting
primary_metric: normalized_root_mean_squared_error
log_verbosity: info
target_column_name: sales
n_cross_validations: 3
forecasting:
time_column_name: "date"
time_series_id_column_names: ["state", "store", "SKU"]
forecast_horizon: 28
training:
blocked_training_algorithms: ["ExtremeRandomTrees"]
limits:
timeout_minutes: 15
max_trials: 10
max_concurrent_trials: 4
max_cores_per_trial: -1
trial_timeout_minutes: 15
enable_early_termination: true
hierarchy_column_names: ["state", "store", "SKU"]
hierarchy_training_level: "store"
Dans les exemples suivants, la configuration est stockée sur le chemin ./automl_settings_hts.yml.
Pipeline HTS
Ensuite, définissez une fonction factory qui crée des pipelines pour l’orchestration de l’entraînement HTS, de l’inférence et du calcul des métriques. La table suivante décrit les paramètres pour cette fonction factory :
| Paramètre | Descriptif |
|---|---|
forecast_level |
Le niveau de la hiérarchie pour lequel récupérer les prévisions. |
allocation_method |
Méthode d’allocation à utiliser lorsque les prévisions sont désagrégées. Les valeurs valides sont proportions_of_historical_average et average_historical_proportions. |
max_nodes |
Nombre de nœuds de calcul à utiliser dans le travail d’entraînement. |
max_concurrency_per_node |
Nombre de processus AutoML à exécuter sur chaque nœud. La concurrence totale d’un travail HTS est max_nodes * max_concurrency_per_node. |
parallel_step_timeout_in_seconds |
Délai d’expiration du composant multi-modèles, spécifié en secondes. |
forecast_mode |
Mode d’inférence pour l’évaluation du modèle. Les valeurs valides sont recursive et rolling. Pour en savoir plus, consultez Inférence et évaluation des modèles de prévision et la référence classe HTSInferenceParameters. |
step |
Taille de pas pour la prévision glissante. La valeur par défaut est 1. Pour en savoir plus, consultez Inférence et évaluation des modèles de prévision et la référence classe HTSInferenceParameters. |
from azure.ai.ml import MLClient
from azure.identity import DefaultAzureCredential, InteractiveBrowserCredential
# Get credential to access azureml registry.
try:
credential = DefaultAzureCredential()
# Check whether token can be obtained.
credential.get_token("https://management.azure.com/.default")
except Exception as ex:
# Fall back to InteractiveBrowserCredential if DefaultAzureCredential fails.
credential = InteractiveBrowserCredential()
# Get HTS training component.
hts_train_component = ml_client_registry.components.get(
name='automl_hts_training',
version='latest'
)
# Get HTS inference component.
hts_inference_component = ml_client_registry.components.get(
name='automl_hts_inference',
version='latest'
)
# Get component to compute evaluation metrics.
compute_metrics_component = ml_client_metrics_registry.components.get(
name="compute_metrics",
label="latest"
)
@pipeline(description="AutoML HTS Forecasting Pipeline")
def hts_train_evaluate_factory(
train_data_input,
test_data_input,
automl_config_input,
max_concurrency_per_node=4,
parallel_step_timeout_in_seconds=3700,
max_nodes=4,
forecast_mode="rolling",
forecast_step=1,
forecast_level="SKU",
allocation_method='proportions_of_historical_average'
):
hts_train = hts_train_component(
raw_data=train_data_input,
automl_config=automl_config_input,
max_concurrency_per_node=max_concurrency_per_node,
parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
max_nodes=max_nodes
)
hts_inference = hts_inference_component(
raw_data=test_data_input,
max_nodes=max_nodes,
max_concurrency_per_node=max_concurrency_per_node,
parallel_step_timeout_in_seconds=parallel_step_timeout_in_seconds,
optional_train_metadata=hts_train.outputs.run_output,
forecast_level=forecast_level,
allocation_method=allocation_method,
forecast_mode=forecast_mode,
step=forecast_step
)
compute_metrics_node = compute_metrics_component(
task="tabular-forecasting",
prediction=hts_inference.outputs.evaluation_data,
ground_truth=hts_inference.outputs.evaluation_data,
evaluation_config=hts_inference.outputs.evaluation_configs
)
# Return metrics results from rolling evaluation.
return {
"metrics_result": compute_metrics_node.outputs.evaluation_result
}
Construisez le pipeline en utilisant la fonction factory. Les données d’entraînement et de test se trouvent dans les dossiers locaux ./data/train et ./data/test. Enfin, définissez le calcul par défaut et soumettez la tâche comme illustré dans l’exemple suivant :
pipeline_job = hts_train_evaluate_factory(
train_data_input=Input(
type="uri_folder",
path="./data/train"
),
test_data_input=Input(
type="uri_folder",
path="./data/test"
),
automl_config=Input(
type="uri_file",
path="./automl_settings_hts.yml"
)
)
pipeline_job.settings.default_compute = "cluster-name"
returned_pipeline_job = ml_client.jobs.create_or_update(
pipeline_job,
experiment_name=experiment_name,
)
ml_client.jobs.stream(returned_pipeline_job.name)
Une fois la tâche terminée, vous pouvez télécharger localement les métriques d’évaluation en suivant la procédure décrite dans le pipeline d’exécution d’entraînement unique.
Pour un exemple plus détaillé, consultez le notebook "Prévision de la demande à l’aide de HTS".
Considérations relatives à l’entraînement pour une exécution HTS
Les composants d’apprentissage et d’inférence HTS partitionnent conditionnellement vos données en fonction du hierarchy_column_names paramètre afin que chaque partition se trouve dans son propre fichier. Ce processus peut être lent ou défaillant lorsque vous avez beaucoup de données. Nous vous recommandons de partitionner vos données manuellement avant d’exécuter l’apprentissage ou l’inférence HTS.
Remarque
La limite de parallélisme par défaut pour une exécution HTS dans un abonnement est 320. Si votre charge de travail nécessite une limite plus élevée, vous pouvez contacter le support Microsoft.
Prévision à grande échelle : entraînement DNN distribué
Comme décrit précédemment dans cet article, vous pouvez activer l’apprentissage pour les réseaux neuronaux profonds (DNN). Pour découvrir comment fonctionne l’entraînement distribué pour les tâches de prévision DNN, consultez Entraînement des réseaux neuronaux profonds distribués (version préliminaire).
Pour les scénarios nécessitant de grandes quantités de données, l’entraînement distribué avec AutoML est disponible pour un ensemble limité de modèles. Vous trouverez plus d’informations et d’exemples de code dans AutoML à grande échelle : entraînement distribué.
Explorer des exemples de notebooks
Des exemples de code détaillés démontrant des configurations avancées de prévision sont disponibles dans les notebooks d’exemples AutoML Forecasting du référentiel GitHub. Voici quelques exemples de notebooks :
- Créer un pipeline de prévision de la demande (HTS et de nombreux modèles)
- Entraîner le modèle TCNForecaster (DNN) sur le jeu de données GitHub
- Prévision avec détection des jours fériés et caractérisation (jeu de données bike-share)
- Configurer manuellement les décalages et l’agrégation par fenêtre glissante