Monitoring de modèles et dérive

Un modèle de machine learning n’est pas une boîte noire que l’on déploie et que l’on oublie. Sa performance se dégrade inévitablement avec le temps. Cette dégradation est rarement soudaine ; c’est une dérive silencieuse, causée par des changements dans les données d’entrée (data drift) ou dans la relation entre les données et ce que l’on cherche à prédire (concept drift). Un monitoring efficace ne se contente pas de surveiller l’état du serveur, il traque la santé du modèle lui-même.

les types de dérive (drift)

Il est crucial de distinguer les deux types de dérive qui menacent la performance de votre modèle.

prérequis

Un historique des métriques de performance du modèle (ex: AUC, F1-score) stocké et versionné.
Un processus pour collecter régulièrement des échantillons de données labellisées (“ground truth”).
Un canal d’alerte pour notifier l’équipe propriétaire en cas de détection d’une anomalie.

idées clefs

Data drift vs. performance drift: La dérive des données est un indicateur avancé, mais seule la dérive de la performance (la métrique métier baisse) confirme un vrai problème.
Seuils avec hystérésis: Pour éviter le bruit et les fausses alertes, les seuils de détection doivent être assez larges et basés sur des moyennes mobiles.
Fermer la boucle avec le métier: Le monitoring n’est pas qu’une affaire technique. Il faut un processus pour que les experts métier puissent remonter des prédictions qui leur semblent étranges.

pas à pas

étape 1: suivre la distribution des données

La première ligne de défense est de comparer la distribution des données vues par le modèle en production à celle des données d’entraînement. Des outils statistiques comme le PSI (Population Stability Index) ou de simples comparaisons de moyennes et d’écarts-types peuvent être automatisés.

-- Requête pour comparer la moyenne et l'écart-type d'une feature
-- entre le jeu d'entraînement et les données de production récentes.
WITH training_stats AS (
  SELECT AVG(feature_x) AS avg_train, STDDEV(feature_x) AS std_train FROM training_dataset
),
production_stats AS (
  SELECT AVG(feature_x) AS avg_prod, STDDEV(feature_x) AS std_prod FROM production_logs WHERE ts >= NOW() - INTERVAL '24 hour'
)
SELECT * FROM training_stats, production_stats;
-- -> Alerte si l'écart entre les stats est supérieur à un seuil.

étape 2: évaluer la performance sans labels parfaits

Obtenir des labels en temps réel est souvent impossible. Il faut donc utiliser des “proxy metrics” pour estimer la performance.

Proxy métier: Pour un modèle de recommandation, le taux de clic sur les produits recommandés est un excellent proxy de la pertinence.
Sondages: Demander périodiquement à une équipe d’experts de labelliser un petit échantillon des prédictions.
Ré-entraînement programmé: Même sans signal de dégradation, planifier un ré-entraînement automatique (ex: tous les mois) sur des données fraîches est une bonne pratique d’hygiène.

étape 3: alerter et agir

Les alertes doivent être claires, actionnables et assignées à un propriétaire.

# Exemple de configuration d'alerte pour un modèle de churn
alert_rules:
  - model: "churn_prediction_v2"
    owner: "@team-crm"
    alerts:
      # Alerte si la distribution d'une feature clé a trop changé
      - metric: "psi_feature_age"
        threshold: "> 0.2"
        severity: "warning"

      # Alerte si la performance réelle du modèle a baissé significativement
      - metric: "weekly_auc_change"
        threshold: "< -0.05"
        severity: "critical"

le cycle de monitoring

Le monitoring n’est pas une action ponctuelle, c’est une boucle continue d’amélioration.

pièges frequents

Symptôme: Les alertes de drift sont constamment ignorées par l’équipe.
- Cause: “Alert fatigue”. Les alertes ne sont pas liées à un impact métier clair ou ne sont pas assignées à un propriétaire.
- Correctif: Chaque alerte doit être accompagnée d’un “runbook” (une procédure simple) et taguer l’équipe propriétaire du modèle.
Symptôme: Impossible de savoir si le modèle se dégrade car on n’a pas de “vérité terrain”.
- Cause: Aucun processus pour collecter des labels frais.
- Correctif: Mettre en place un processus de collecte de labels, même sur un petit échantillon. 100 prédictions labellisées par semaine valent mieux que rien du tout.
Symptôme: Le monitoring déclenche des alertes pour des fluctuations mineures.
- Cause: Seuils de détection trop serrés et basés sur des données trop volatiles.
- Correctif: Lisser les métriques sur une fenêtre de temps plus longue (hebdomadaire plutôt que journalière). Utiliser des seuils basés sur des écarts-types plutôt que des valeurs fixes.

faq

Quelle est la différence entre “data drift” et “concept drift” ? Le data drift, c’est quand les données d’entrée changent (ex: un nouveau type de client apparaît). Le concept drift, c’est quand la relation entre les données et la cible change (ex: à cause d’un changement de comportement des clients, les mêmes features ne prédisent plus le churn de la même manière). Le data drift est plus facile à détecter.
À quelle fréquence dois-je ré-entraîner mes modèles ? Il n’y a pas de règle unique. La meilleure approche est “ré-entraîner quand la performance baisse”. Si vous ne pouvez pas mesurer la performance en continu, une approche calendaire (ex: une fois par mois) avec des données fraîches est une bonne base.

Menu