Aller au contenu principal

Module 5 — Tâches d'entraînement et suivi des exécutions

Espace de travail (module 1), calcul (2), données (3), environnement (4) : nous disposons de tout pour lancer la première tâche d'entraînement du fil rouge, un xgboost régresseur sur les ventes hebdomadaires. Une tâche Azure ML (job) est la brique élémentaire de tout ce qui suit — pipeline (module 9), déploiement (8), balayage (ce module).

La tâche commande : un script, ses entrées, ses sorties​

La forme la plus fréquente est la command job : Azure ML exécute une seule ligne de commande dans le conteneur de l'environnement, sur la cible de calcul indiquée.

$schema: https://azuremlschemas.azureedge.net/latest/commandJob.schema.json
code: ./src
command: >-
  python train.py
  --ventes ${{inputs.ventes}}
  --alpha ${{inputs.alpha}}
  --max-depth ${{inputs.max_depth}}
  --sortie ${{outputs.modele}}
environment: azureml:env-prev-demande:3
compute: azureml:cpu-cluster-32
inputs:
  ventes:
    type: mltable
    path: azureml:ventes_magasins:3
    mode: download
  alpha: 0.1
  max_depth: 8
outputs:
  modele:
    type: mlflow_model
experiment_name: prev-demande-xgb
display_name: xgb-baseline-2026-09-06

Trois éléments méritent une lecture attentive.

Le dossier code est empaqueté dans un instantané que la tâche voit sous . : le script train.py y accède comme sur un disque local. Il ne faut pas y placer les jeux de données — la limite est de 300 Mo et la lourdeur d'un snapshot ralentit chaque exécution.

Les entrées ${{inputs.ventes}} sont substituées par le chemin local où Azure aura monté ou téléchargé le MLTable ventes_magasins version 3. Le script travaille sur un chemin comme /mnt/azureml/cr/j/…/ventes/, sans jamais connaître le stockage sous-jacent.

La sortie modele de type mlflow_model déclare qu'un modèle enregistré au format MLflow doit être remonté à la fin. C'est le pont vers le registre du module 7.

Le script train.py : MLflow sans une ligne d'initialisation​

Dans un environnement Azure ML avec azureml-mlflow installé (module 4), MLflow est auto-configuré : mlflow.set_tracking_uri et mlflow.start_run sont automatiques dès l'entrée dans la tâche. Le script ne fait que journaliser :

import argparse, mlflow, pandas as pd
from mlflow.models import infer_signature
from sklearn.metrics import mean_absolute_percentage_error
from xgboost import XGBRegressor

parser = argparse.ArgumentParser()
parser.add_argument("--ventes")
parser.add_argument("--alpha", type=float)
parser.add_argument("--max-depth", type=int)
parser.add_argument("--sortie")
args = parser.parse_args()

df = pd.read_parquet(args.ventes)
X = df.drop(columns=["unites"])
y = df["unites"]

modele = XGBRegressor(learning_rate=args.alpha, max_depth=args.max_depth)
modele.fit(X, y)
predictions = modele.predict(X)

mape = mean_absolute_percentage_error(y, predictions)
mlflow.log_metric("mape", mape)
mlflow.log_params({"alpha": args.alpha, "max_depth": args.max_depth})

signature = infer_signature(X, predictions)
mlflow.sklearn.save_model(modele, args.sortie, signature=signature)

Aucune ligne du script ne connaît Azure — c'est du MLflow pur. C'est ce qui rend le code portable vers Databricks ou un MLflow autohébergé sans réécriture.

Le lancement et la lecture dans Studio​

az ml job create --file job.yml -g rg-prev-demande -w mlw-prev-demande

La commande imprime l'URL de la tâche dans Azure ML Studio. La page affiche l'état, les journaux stdout et stderr en temps réel, les entrées, les sorties, les métriques MLflow sous forme de courbes, et les balises. Elle expose surtout l'onglet Lignage qui remonte au MLTable version 3 et à l'environnement version 3 — c'est la matérialisation du travail des modules précédents.

Le balayage d'hyperparamètres : la sweep job​

Rien ne prouve encore que alpha=0.1 et max_depth=8 sont les bons choix. Le balayage est une tâche qui lance N variantes de la tâche commande selon un plan d'exploration.

$schema: https://azuremlschemas.azureedge.net/latest/sweepJob.schema.json
type: sweep
trial: ./job.yml
sampling_algorithm: bayesian
search_space:
  alpha:
    type: uniform
    min_value: 0.01
    max_value: 0.3
  max_depth:
    type: choice
    values: [4, 6, 8, 10, 12]
objective:
  primary_metric: mape
  goal: minimize
limits:
  max_total_trials: 40
  max_concurrent_trials: 8
  timeout: 3600
early_termination:
  type: median_stopping
  evaluation_interval: 5
  delay_evaluation: 10

Deux points de méthode :

  • max_concurrent_trials: 8 doit rester sous le plafond de nœuds de la grappe (module 2) et sous le quota régional de cœurs. Un dépassement transforme un balayage en file d'attente séquentielle.
  • early_termination stoppe les essais visiblement moins bons que la médiane, ce qui économise 30 à 50 % de calcul sans dégrader la qualité du meilleur essai retenu.

L'essai gagnant est identifié dans Studio par son plus faible mape ; ses sorties, dont le modèle MLflow, sont directement enregistrables au registre du module 7.

En résumé​

  • Une command job matérialise script, entrées, sorties, environnement et calcul dans un seul YAML
  • Le dossier code est un snapshot léger — jamais y déposer les données
  • Avec azureml-mlflow, les métriques et le modèle remontent sans configuration au workspace
  • Un balayage bayésien avec early_termination explore l'espace d'hyperparamètres à coût maîtrisé

Le module suivant confronte cette approche manuelle à AutoML — pour voir quand la machine bat l'humain et quand elle ne le fait pas.