Aller au contenu principal

Module 9 — Surveillance de la qualité des variables

Le cours de MLOps (cours 20) a introduit la dérive du modèle : sa précision baisse, la distribution des sorties s'éloigne de la référence. Ce module montre pourquoi surveiller en amont, au niveau des variables du magasin, est presque toujours plus rapide et moins coûteux que de surveiller en aval, au niveau du modèle — et comment le faire concrètement.

Pourquoi surveiller en amont​

Une variable dégradée est une cause. La chute de la métrique du modèle est un symptôme. Attendre le symptôme peut prendre des semaines, parce que la métrique aval demande beaucoup d'échantillons pour être statistiquement significative, et que le retour d'étiquettes (« cette transaction était-elle vraiment frauduleuse ? ») a souvent 30 à 90 jours de latence. Une alerte au niveau de la variable se déclenche à la journée, parfois à l'heure.

Trois classes d'incidents ne se voient que côté variable : perte totale d'une source, décalage subtil de l'échelle après une mise à jour de l'ETL, apparition massive de valeurs manquantes. Ni la latence ni le taux d'erreur du service ne les signalent — la variable est simplement fausse, le service continue à répondre.

Quatre axes de surveillance​

1. Fraîcheur. Déjà rencontrée au module 6. Mesurée sur chaque vue, comparée à un seuil dérivé de l'intervalle de matérialisation nominal. Alerte quand la fraîcheur dépasse trois fois cet intervalle. Cause typique : panne du pipeline de matérialisation, ordonnanceur bloqué.

2. Valeurs manquantes. Proportion de NULL par variable, par jour. Un porteur sans transaction dans les 24 h renvoie légitimement NULL — mais si la proportion passe de 3 % à 40 % du jour au lendemain, quelque chose s'est brisé en amont. Alerte sur variation relative (par exemple, +100 % en 24 h). Cause typique : nouvelle catégorie non gérée par le calcul, colonne renommée dans la source.

3. Distribution. Comparer la distribution actuelle à une distribution de référence (l'entraînement le plus récent, une fenêtre glissante). Métriques utiles :

  • Pour les variables numériques : moyenne, écart-type, percentiles 5/50/95. Un décalage supérieur à 2σ persistant est suspect.
  • Pour les variables catégorielles : proportion des top-k catégories. Une nouvelle catégorie majoritaire est un fort signal.
  • Test statistique : indice de stabilité de population (PSI) ou Kolmogorov-Smirnov, seuil courant PSI > 0,2.

4. Cohérence hors ligne / en ligne. Sur un échantillon d'entités, lire la variable en ligne à l'instant t et la comparer à la valeur produite hors ligne pour valid_at = t. Écart > 0,1 % : alerte. Ce contrôle attrape les régressions de matérialisation sans lever de faux positif sur la dérive naturelle.

Un exemple concret​

from feast import FeatureStore
from datetime import datetime, timedelta
import pandas as pd

store = FeatureStore(repo_path=".")

# Échantillonner 10 000 porteurs actifs sur les 24 dernières heures
paiements_recents = pd.read_parquet("data/paiements_24h.parquet")
echantillon = paiements_recents["card_id_hash"].drop_duplicates().sample(10_000)

# Lecture hors ligne au dernier `valid_at`
snapshot_hl = store.get_historical_features(
    entity_df=pd.DataFrame({
        "card_id_hash": echantillon,
        "event_timestamp": [datetime.utcnow() - timedelta(seconds=5)] * len(echantillon),
    }),
    features=["porteur_transactions_recentes:nb_transactions_24h"],
).to_df()

# Lecture en ligne
snapshot_en = store.get_online_features(
    features=["porteur_transactions_recentes:nb_transactions_24h"],
    entity_rows=[{"card_id_hash": c} for c in echantillon],
).to_df()

# Comparaison
merged = snapshot_hl.merge(snapshot_en, on="card_id_hash", suffixes=("_hl", "_en"))
desaccord = (merged["nb_transactions_24h_hl"] != merged["nb_transactions_24h_en"]).mean()
print(f"Désaccord hors ligne / en ligne : {desaccord:.3%}")
# Cible : < 0,1 %

Ce script tourne toutes les heures, publie la métrique sur le tableau de bord, alerte au-delà du seuil.

Où placer les alertes​

Le placement des alertes suit une règle simple : plus près de la cause, plus tôt on la voit. Placer une alerte sur la métrique aval (rappel, précision, revenu perdu) est indispensable — mais tardif. On place donc, en cascade :

  • Alerte de niveau 1 : fraîcheur du pipeline. Se déclenche en minutes.
  • Alerte de niveau 2 : valeurs manquantes et distribution. Se déclenche en heures.
  • Alerte de niveau 3 : cohérence hors ligne / en ligne. Se déclenche en heures.
  • Alerte de niveau 4 : métrique aval du modèle. Se déclenche en jours ou semaines.

Un incident bien géré est détecté au niveau 1 ou 2. Un incident détecté au niveau 4 signifie qu'on a raté trois niveaux plus tôt.

Lien avec la dérive du cours 20​

La dérive au sens du cours de MLOps est un cas particulier de ce qu'on surveille ici : la distribution des variables s'écarte de la distribution d'entraînement, même si les pipelines fonctionnent parfaitement. Le monde a bougé, pas le code.

La différence est dans l'action. Une régression de pipeline (module 6) se corrige : on répare, on rematérialise, on repart. Une dérive naturelle du monde ne se répare pas — elle appelle un réentraînement. La confusion des deux est un piège : réentraîner sur des variables cassées ne fait qu'aggraver le mal, et corriger un pipeline ne suffit pas si la population a effectivement changé. La surveillance en amont sépare les deux causes automatiquement : un pic sur les valeurs manquantes signale la première, un décalage progressif de la distribution signale la seconde.

Une alerte n'est utile que si elle réveille quelqu'un

Un tableau de bord surveillé une fois par trimestre n'attrape rien. Chaque niveau d'alerte doit avoir un destinataire nommé et une action documentée : qui prévenir, comment couper, comment revenir à un état sain. Sans cela, la surveillance est décorative.

En résumé​

  • Surveiller en amont (variables) détecte plus tôt et plus précisément qu'en aval (modèle) ; le retour d'étiquettes est trop lent pour être le premier signal.
  • Quatre axes : fraîcheur, valeurs manquantes, distribution, cohérence hors ligne / en ligne.
  • Les alertes sont en cascade ; un incident détecté au niveau modèle signifie qu'on a raté trois niveaux plus tôt.
  • Régression de pipeline et dérive du monde ont des signatures différentes ; la surveillance en amont sépare les causes automatiquement.

Module suivant : le projet complet — chaîner tout ce qu'on a vu sur un cas de scoring, mesurer l'écart avant et après, comparer à ce qu'il aurait fallu pour s'en passer.