Aller au contenu principal

Module 6 — AutoML : usages pertinents et limites

Le module 5 a laissé un xgboost manuel avec un mape que l'on suppose raisonnable. Une question légitime se pose : combien vaudrait-il de laisser Azure AutoML chercher à notre place ? La réponse tient rarement en oui ou non. Elle dépend du type de problème, de la maturité de l'équipe et du budget. Ce module montre où AutoML bat le fil rouge manuel, où il perd, et comment lire ses sorties sans se laisser piéger.

Ce qu'AutoML fait vraiment​

AutoML prend un jeu de données, une colonne cible et un budget, puis explore automatiquement trois axes :

  1. Prétraitement (featurization) : encodage des variables catégorielles, imputation, mise à l'échelle, détection de dérive de types, création de variables temporelles (jour de la semaine, indicateur de vacances, retards saisonniers)
  2. Choix d'algorithme : parmi LightGBM, XGBoost, RandomForest, Prophet, Auto-ARIMA, TCNForecaster (réseau causal temporel), et en fin de course un ensemble d'empilage (stacked ensemble)
  3. Réglage d'hyperparamètres de chaque candidat

Le tout dans un budget de temps (experiment_timeout_hours) et de calcul (max_concurrent_iterations) fixé à l'avance.

Une tâche AutoML de prévision pour le fil rouge​

Pour le fil rouge des ventes hebdomadaires, la tâche prend cette forme :

$schema: https://azuremlschemas.azureedge.net/latest/autoMLForecastingJob.schema.json
type: automl
task: forecasting
compute: azureml:cpu-cluster-32
experiment_name: prev-demande-automl

training_data:
  type: mltable
  path: azureml:ventes_magasins:3

target_column_name: unites
primary_metric: normalized_root_mean_squared_error

forecasting:
  time_column_name: date
  forecast_horizon: 4
  time_series_id_column_names: [magasin_id, produit_id]
  frequency: W-SUN
  target_lags: [1, 2, 4, 13, 52]

limits:
  timeout_minutes: 240
  trial_timeout_minutes: 30
  max_trials: 40
  max_concurrent_trials: 8

Deux paramètres portent presque toute l'intelligence de la tâche.

time_series_id_column_names dit à AutoML que le jeu contient une grille de séries (une série par couple magasin-produit) et non une série unique. Sans cette information, AutoML traite l'ensemble comme une seule séquence désordonnée et sort un score absurde. C'est le premier piège.

target_lags demande la génération automatique des retards de la cible (t-1, t-2, t-4, t-13, t-52). Sur les ventes hebdomadaires, le retard 52 capture la saisonnalité annuelle : sans lui, aucun candidat ne saura représenter le pic de Noël.

Lecture des résultats : ne pas confondre best_model et modèle utile​

Après quatre heures, AutoML retourne un meilleur essai selon la métrique choisie et un ensemble empilé qui combine les meilleurs candidats. Trois surprises à connaître.

  • L'ensemble empilé est presque toujours en tête sur la métrique — mais il est difficile à interpréter, deux à cinq fois plus lent en prédiction et plus fragile à maintenir. Sur le fil rouge, un LightGBM seul, quatrième au classement, peut être le vrai gagnant en production.
  • La comparaison avec le fil rouge manuel doit se faire sur le même découpage temporel, pas sur les splits internes d'AutoML. Sans quoi on compare des choux et des carottes.
  • Le normalized_root_mean_squared_error favorise les gros vendeurs et pénalise peu les erreurs sur les produits de faible volume. Si l'objectif métier est la rupture évitée, la bonne métrique est plutôt un weighted MAPE avec un poids marge — à calculer soi-même, AutoML n'expose pas ce choix.

L'explication automatique du modèle​

Chaque essai AutoML génère, en fin de course, une explication SHAP du meilleur modèle. Elle est consultable dans Studio, sous l'onglet Explanations, ou récupérable en Python :

from azure.ai.ml import MLClient
job = ml_client.jobs.get("prev-demande-automl-42")
best_run = ml_client.jobs.get(job.name + "_HD_0")
best_run.download(output_name="model_explanation", download_path="./explication")

Utile pour deux choses : vérifier que le modèle ne s'appuie pas sur une variable fuitée (le chiffre_affaires dans les entrées, par exemple, qui contient l'information de la cible) et présenter au métier les moteurs de la prévision (saisonnalité annuelle, promotions, prix concurrent).

Quand AutoML bat le fil rouge, quand il ne le bat pas​

AutoML gagne, en général, sur les problèmes tabulaires bien cadrés avec beaucoup de variables où l'ingénierie manuelle coûterait des semaines : un modèle de churn client sur 400 colonnes, une propension à l'achat, un scoring risque.

AutoML perd, en général, dans quatre configurations :

  • Jeu très déséquilibré avec une classe rare critique — les stratégies de suréchantillonnage internes sont peu configurables
  • Données textuelles ou images sans AutoML for Text / Vision explicite — la version tabulaire les ignore
  • Contrainte forte d'interprétabilité ou de latence d'inférence — l'ensemble empilé est disqualifié d'avance
  • Domaine où l'expertise est décisive — la fraude financière, la maintenance prédictive avec capteurs physiques, où un modèle simple avec les bonnes variables métier bat une exploration aveugle

Le coût, l'angle mort le plus fréquent​

Une tâche AutoML de prévision avec 8 essais simultanés sur des DS4_v2 pendant 4 heures coûte de l'ordre de \$25 par exécution. Ce n'est pas cher pour une exploration ponctuelle, cela devient significatif quand l'équipe la relance à chaque changement de jeu. Une bonne pratique : AutoML sert de baseline forte au démarrage du projet, puis on l'appelle une fois par trimestre en réévaluation, pas une fois par nuit.

AutoML mal utilisé

Trois signaux qui trahissent un mauvais usage : lancer AutoML sans avoir défini la métrique métier avec le sponsor, l'utiliser sur moins de 500 observations où l'ingénierie manuelle serait objectivement supérieure, et déployer l'ensemble empilé en ligne sans avoir mesuré sa latence — souvent 5 à 10 fois celle d'un modèle unique, ce qui fait exploser la file d'attente du point de terminaison du module 8.

En résumé​

  • AutoML explore prétraitement, algorithme et hyperparamètres dans un budget donné
  • Pour la prévision de séries multiples, time_series_id_column_names et target_lags sont non négociables
  • L'ensemble empilé gagne sur la métrique mais pas toujours en production ; envisager le meilleur modèle simple
  • AutoML est une baseline forte, pas un remplacement du fil rouge manuel dans les domaines à forte expertise

Le module suivant enregistre le modèle retenu — manuel ou AutoML — dans le registre partagé.