Salut à tous !
Je bosse sur un pipeline de données qui alimente nos modèles de ML en production, et j’ai un vrai problème de dérive qualité que je n’arrive pas à détecter assez tôt.
Concrètement :
-
Pipeline ingère 50k+ records par heure depuis des APIs tierces
-
Les données peuvent dériver lentement (changement format date, nouveaux nulls, valeurs aberrantes)
-
Nos modèles commencent à déconner mais on s’en rend compte que quand les métriques business chutent
J’aimerais mettre en place un système d’alertes automatisées qui détecte ces dérives AVANT qu’elles impactent les prédictions.
Vous utilisez quoi comme approche ?
Great Expectations, Evidently, ou des solutions maison ?
Merci d’avance pour vos retours !
@data_ops_alex j’ai exactement le même use case !
Chez nous on a implémenté une approche hybride avec plusieurs couches de détection : Détection statistique basique :
-
Monitoring des distributions (KL divergence, chi
-square tests)
-
Alertes sur les pourcentages de nulls/valeurs manquantes
-
Détection d’outliers avec méthodes IQR Détection d’anomalies comportementales :
-
Isolation Forest pour détecter les patterns inhabituels
-
Monitoring des corrélations entre features
-
Suivi des cardinalités pour les variables catégorielles
python
# Exemple simplifié de notre détection KL divergence import numpy as np from scipy.stats import entropy def detect_distribution_drift(reference_data, current_data, threshold=0.1): # Calcul histogrammes normalisés ref_hist, bins = np.histogram(reference_data, bins=50, density=True) curr_hist, _ = np.histogram(current_data, bins=bins, density=True) # KL divergence kl_div = entropy(curr_hist + 1e-10, ref_hist + 1e
-10) return kl_div > threshold, kl_div
Pour les alertes, on utilise Grafana avec des webhooks vers Slack. Ça nous évite 80% des incidents en prod maintenant.
Tu as déjà une baseline de référence pour tes données ?
@ml_engineer_sara super intéressant ton approche !
En fait j’ai une baseline mais elle date de 6 mois, du coup elle est peut-être plus représentative…
Question pratique : comment tu gères le concept de « drift normal » vs « drift critique » ?
Parce que nos données évoluent naturellement (saisonnalité, nouveaux users, etc.) mais parfois c’est vraiment un bug côté source.
Et niveau fréquence, vous calculez les métriques de drift à quelle cadence ?
Toutes les heures, en temps réel ?
J’ai regardé Evidently AI aussi, ils ont l’air d’avoir des dashboards sympas pour ce genre de monitoring.
Salut les copains !
Je me permets de partager notre retour d’expérience chez nous sur ce sujet.
On a testé Great Expectations pendant 6 mois et franchement, c’est solide pour les règles business (format email, ranges de valeurs, etc.) mais moins optimal pour la détection de drift statistique.
Notre stack actuelle :
-
Evidently pour le monitoring de drift (distribution, target drift, data quality)
-
Custom alerting avec seuils adaptatifs basés sur rolling windows
-
MLflow pour tracker les métriques de drift dans le temps
Gestion du drift « normal » vs « critique » :
yaml
# Configuration alerting adaptative
drift_config:
features:
age:
alert_threshold: 0.15
rolling_window: 7d
seasonal_adjustment: true
transaction_amount:
alert_threshold: 0.08
rolling_window: 1d
seasonal_adjustment: false
On utilise des seuils adaptatifs qui prennent en compte l’historique récent.
Genre si le drift augmente progressivement sur 7 jours, on ajuste le seuil automatiquement.
Cadence de monitoring :
-
Calcul temps réel pour les features critiques
-
Batch horaire pour les analyses plus lourdes
-
Rapports quotidiens avec tendances
Le truc qui nous a vraiment sauvés, c’est d’avoir des alertes à plusieurs niveaux :
WARNING, CRITICAL, EMERGENCY avec des canaux différents.
EDIT: j’ai oublié de mentionner qu’on utilise aussi Evidently documentation qui est vraiment bien faite pour ce genre de setup !
Très bonne discussion !
Je vais ajouter quelques points qu’on a appris à nos dépens :
Performance et scalabilité :
Avec 50k records/heure, attention aux calculs coûteux en temps réel.
On utilise un sampling intelligent :
python
# Stratégie de sampling pour gros volumes
def smart_sampling(data, min_samples=1000, max_samples=5000):
if len(data) <= min_samples:
return data
# Sampling stratifié si variables catégorielles
if has_categorical_features(data):
return stratified_sample(data, max_samples)
# Random sampling sinon
return data.sample(n=min(max_samples, len(data)))
Alertes contextuelles :
Le game changer pour nous, ça a été d’enrichir les alertes avec du contexte métier :
-
Corrélation avec les événements business (campagnes marketing, etc.)
-
Impact estimé sur les prédictions
-
Suggestions d’actions correctives
Exemple d’alerte enrichie :
🚨 DRIFT DETECTED - transaction_amount
KL Divergence: 0.234 (threshold: 0.15)
Impact estimé: -12% accuracy modèle fraud_detection
Possible cause: Nouveau partenaire payment activé hier
Action suggérée:
Réentraîner avec données des 7 derniers jours
Ça évite les fausses alertes et ça aide les équipes à prioriser les actions.
Vous avez déjà eu des cas où le drift était en fait… positif ?
Genre amélioration naturelle de la qualité des données sources ?
Wow merci à tous pour ces retours détaillés ! 
@thomas_mlops ton approche avec les seuils adaptatifs me plaît beaucoup.
Je vais creuser Evidently du coup. @marie_data_sci excellent point sur les alertes contextuelles !
Et oui on a déjà eu du « drift positif », notamment quand une source externe a corrigé des bugs dans leur API.
Du coup nos modèles se sont améliorés mais nos alertes ont flippé pendant 2 jours…
Je pense que je vais partir sur cette architecture : 1. Evidently pour le monitoring principal 2. Seuils adaptatifs avec rolling windows 3. Sampling intelligent comme suggéré par Marie
- Alertes multi-niveaux avec contexte business Je vous tiens au courant de l’implémentation dans quelques semaines !
Encore merci pour tous ces conseils, cette communauté est vraiment top 