TP5 : monitoring, derive Evidently (2011 vs 2014) + impact perfs 2012-2014

SYNTHESE_TP05.md

@@ -0,0 +1,178 @@
+# TP05 - Synthèse : monitoring, dérive et redéploiement
+
+Fil rouge : prédiction de la consommation électrique (kWh, 128 clients portugais, pas de 15 min).
+
+Scénario : un modèle a été **entraîné sur 2011** et tourne toujours en production plusieurs années plus
+tard. En ingénieur MLOps, on vérifie si les données **2014** observées en production ont **dérivé** par
+rapport à l'entraînement, on analyse cette dérive avec **Evidently**, puis on mesure son **impact sur les
+performances** (2012 -> 2014) pour décider d'une stratégie de maintenance.
+
+## Ce qui a été construit
+
+- **`tp_module5_monitoring_derive.ipynb`** (notebook exécuté) : Partie 1 (moyennes + histogrammes de
+  `lag_30d` 2011 vs 2014), Partie 2 (rapport de dérive Evidently `DataDriftPreset`), Partie 3 (modèle
+  linéaire entraîné sur 2011, évalué sur 2011-2014). Réutilise `lab/constants.py` (chemins, cible, features).
+- **`tp05_evidently_drift_2011_vs_2014.html`** : rapport Evidently interactif complet (à ouvrir dans un
+  navigateur).
+- **Choix technique** : la feature `lag_365d` (consommation 365 jours plus tôt) est **exclue** car elle
+  est indéfinie (NaN) sur **toute** l'année 2011 (première année, pas d'historique 2010). On travaille donc
+  sur les 5 features définies sur les deux périodes : `lag_1d, lag_7d, lag_30d, rolling_mean_7d,
+  rolling_mean_30d`. Cet ensemble sert à la fois au rapport de dérive et au modèle entraîné sur 2011.
+
+---
+
+## Partie 1 - Observer une dérive
+
+Feature `lag_30d`, sur les années complètes 2011 (train) et 2014 (production) :
+
+| Année        | Moyenne `lag_30d` | Effectif   |
+|--------------|-------------------|------------|
+| 2011 (train) | **62.041 kWh**    | 4 116 352  |
+| 2014 (prod)  | **54.054 kWh**    | 4 485 120  |
+| Écart        | **-7.986 kWh**    | **-12.9 %** |
+
+**1.1 - Les deux distributions semblent-elles similaires ?**
+Non. Elles gardent la même **forme** générale (distribution asymétrique étalée vers la droite : beaucoup de
+petites consommations, une longue queue de fortes valeurs), mais l'histogramme 2014 est **décalé vers les
+valeurs plus faibles** et sa moyenne est nettement plus basse. Visuellement, le décalage est net.
+
+**1.2 - La moyenne a-t-elle évolué entre 2011 et 2014 ?**
+Oui, franchement : de **62.04 kWh** à **54.05 kWh**, soit **-7.99 kWh (-12.9 %)**. La consommation moyenne
+(observée via `lag_30d`) a **baissé d'environ 13 %** entre l'entraînement et la production.
+
+**1.3 - Cette évolution paraît-elle suffisamment importante pour parler de dérive ?**
+Une baisse de ~13 % de la moyenne est un signal **fort et cohérent** d'un changement de distribution : c'est
+un indice sérieux de dérive des données. Attention toutefois : la moyenne seule ne **prouve** pas une dérive
+statistique (deux distributions peuvent avoir des moyennes proches et des formes différentes, ou l'inverse).
+Il faut confirmer avec une analyse sur toute la distribution, avec un test et un seuil objectifs (Partie 2).
+
+**1.4 - Cette première analyse est-elle suffisante pour conclure sur l'état du modèle ? Pourquoi ?**
+Non. Elle ne porte que sur **une** feature (`lag_30d`), via un **seul** indicateur (moyenne + comparaison
+visuelle), **sans test statistique ni seuil**, et elle ne dit **rien** des autres features ni de l'**impact
+réel sur la performance** du modèle. C'est un premier indice, pas une conclusion. Il faut (a) un outil de
+monitoring qui teste toutes les features (Partie 2) et (b) mesurer la performance dans le temps (Partie 3).
+
+---
+
+## Partie 2 - Analyse avec un outil de monitoring (Evidently)
+
+Rapport `DataDriftPreset` comparant 2011 (référence) et 2014 (courant), échantillon de 200 000 lignes par
+période (seed fixe). Test choisi automatiquement par Evidently pour de grands échantillons numériques :
+**distance de Wasserstein normalisée**, seuil **0.1**.
+
+| Feature            | Test                          | Drift score | Seuil | Dérive ? |
+|--------------------|-------------------------------|-------------|-------|----------|
+| lag_1d             | Wasserstein distance (normed) | 0.165       | 0.1   | Oui      |
+| lag_7d             | Wasserstein distance (normed) | 0.167       | 0.1   | Oui      |
+| lag_30d            | Wasserstein distance (normed) | 0.167       | 0.1   | Oui      |
+| rolling_mean_7d    | Wasserstein distance (normed) | 0.188       | 0.1   | Oui      |
+| rolling_mean_30d   | Wasserstein distance (normed) | 0.191       | 0.1   | Oui      |
+
+Verdict global : **`dataset_drift = True`**, **5 / 5 features en dérive (100 %)**.
+
+**2.1 - Combien de features présentent une dérive ?**
+**Les 5** features analysées présentent une dérive (5 / 5, soit 100 %). Toutes dépassent le seuil de 0.1.
+
+**2.2 - Toutes les features évoluent-elles de la même manière ?**
+Toutes dérivent, mais **pas avec la même intensité**. Les distances de Wasserstein vont de **0.165**
+(`lag_1d`) à **0.191** (`rolling_mean_30d`). Les **moyennes glissantes** (`rolling_mean_7d` 0.188,
+`rolling_mean_30d` 0.191) dérivent un peu **plus** que les **lags bruts** (0.165-0.167) : les indicateurs
+lissés/tendanciels captent davantage la baisse durable du niveau de consommation.
+
+**2.3 - Identifiez deux métriques ou indicateurs du rapport. À quoi servent-ils ?**
+- **Le drift score par feature** (ici la distance de Wasserstein normalisée) : il **quantifie** l'écart
+  entre la distribution de référence (2011) et la distribution courante (2014) pour chaque variable, et le
+  compare à un **seuil** (0.1). Il sert à **détecter et localiser** la dérive, feature par feature.
+- **Le verdict global "Dataset Drift" + la part de colonnes en dérive** : il **agrège** les décisions par
+  feature (nombre / pourcentage de colonnes dérivées, ici 5/5 = 100 %) en une conclusion **au niveau du
+  dataset entier**. Il sert à **trancher globalement** (le dataset a-t-il dérivé, oui/non).
+  (Le rapport affiche aussi, par feature, les **histogrammes de distribution référence vs courant**, utiles
+  pour visualiser la nature du décalage.)
+
+**2.4 - Le rapport conclut-il à une dérive globale du dataset ? Justifiez.**
+**Oui.** `dataset_drift = True`. Le critère par défaut d'Evidently (déclarer une dérive du dataset quand la
+**part de colonnes en dérive dépasse 50 %**) est **largement** franchi : **100 %** des colonnes dérivent.
+Le rapport conclut donc sans ambiguïté à une dérive globale des données d'entrée.
+
+---
+
+## Partie 3 - Mesurer l'impact sur les performances
+
+Modèle (régression linéaire) entraîné **sur 2011 uniquement**, évalué sur chaque année complète :
+
+| Année | Rôle              | RMSE (kWh) | MAE (kWh) |
+|-------|-------------------|------------|-----------|
+| 2011  | train (référence) | 7.904      | 4.450     |
+| 2012  | évaluation (prod) | 7.595      | 4.178     |
+| 2013  | évaluation (prod) | 7.486      | 4.095     |
+| 2014  | évaluation (prod) | **7.101**  | **3.911** |
+
+**Résultat marquant : l'erreur ne se dégrade pas, elle diminue légèrement d'année en année.**
+
+**3.1 - Peut-on comparer 2011 vs 2012 au même titre que 2012 vs 2013 ?**
+Non. **2011 est l'année d'entraînement** : l'erreur y est mesurée **in-sample** (le modèle a déjà vu ces
+données), donc **optimiste**. Comparer 2011 (in-sample) à 2012 (hors échantillon) mélange deux régimes
+différents, alors que 2012 vs 2013 compare **deux années hors échantillon** entre elles (comparaison
+homogène). De plus, le **niveau de consommation change** d'une année à l'autre : comparer des **RMSE bruts**
+est biaisé par l'échelle de la cible (voir 3.3). 2011 doit donc être traité comme **référence de train**,
+pas comme un point de comparaison équivalent aux années de production.
+
+**3.2 - Observe-t-on une dégradation progressive ?**
+**Non.** En valeur absolue, la performance **s'améliore** légèrement : RMSE 7.90 -> 7.60 -> 7.49 -> 7.10 et
+MAE 4.45 -> 4.18 -> 4.10 -> 3.91 de 2011 à 2014. Aucune dégradation observée sur ces métriques.
+
+**3.3 - Cette (absence de) dégradation est-elle cohérente avec la dérive détectée ?**
+À première vue c'est surprenant (dérive nette en Partie 2, mais pas de perte de performance), et c'est
+**instructif** : **une dérive des données ne signifie pas automatiquement une dégradation du modèle**.
+Explication : la consommation a **baissé** (~-13 % sur `lag_30d`, Partie 1), donc la **cible** (kWh) est plus
+petite en 2014 ; comme RMSE et MAE sont des erreurs **absolues** en kWh, elles **diminuent mécaniquement**
+quand l'échelle de la cible diminue. Pendant ce temps, la **relation features -> cible** (les lags prédisent
+la consommation courante) est restée **stable**. On a donc une dérive des données **sans** dérive de la
+relation. Pour comparer rigoureusement les années, il faudrait une métrique **indépendante de l'échelle**
+(MAPE, R², RMSE normalisé).
+
+**3.4 - Peut-on conclure que le modèle 2011 est encore fiable en 2014 ?**
+Sur la base des erreurs absolues, il **ne s'est pas dégradé** (il fait même un peu mieux en kWh). Mais on ne
+peut pas **conclure** à sa pleine fiabilité sur ces seuls chiffres : (1) les métriques absolues sont
+**trompeuses** quand l'échelle de la cible change ; (2) on n'a mesuré que l'**amplitude** de l'erreur, pas un
+éventuel **biais systématique** (sur/sous-estimation) ni la performance par segment (client, saison).
+Verdict prudent : **pas de signe de dégradation**, mais à **confirmer** avec des métriques relatives et une
+analyse des résidus avant de déclarer le modèle fiable.
+
+**3.5 - Que faudrait-il faire ensuite : surveiller, réentraîner, ou redéployer ?**
+**Surveiller.** La dérive des données est réelle, mais **sans impact mesuré** sur la performance : rien
+n'impose un réentraînement ou un redéploiement immédiat (ce serait du travail et du risque pour un gain non
+démontré). On met en place un **monitoring continu** (dérive des features + performance suivie avec une
+métrique relative + dérive des prédictions et de la cible dès que la vérité terrain arrive) et on **déclenche
+un réentraînement seulement si/quand** la performance se dégrade réellement ou qu'un concept drift apparaît.
+
+**3.6 - Quel type de dérive semble en jeu ? Quelles analyses préconisez-vous ?**
+Type : **data drift** (dérive des covariables / *covariate shift*). Les distributions des features d'entrée
+ont changé (baisse durable du niveau de consommation), tandis que la **relation** features -> cible semble
+**stable** (pas de perte de performance) : **pas de concept drift évident**. Analyses préconisées :
+- suivre une **métrique de performance indépendante de l'échelle** (MAPE, R², nRMSE) dans le temps, plutôt
+  que le RMSE brut ;
+- monitorer aussi la **dérive des prédictions** et de la **cible** (*target drift*), pas seulement des
+  features en entrée ;
+- **analyser les résidus** (biais moyen, hétéroscédasticité) et **segmenter** (par client, par saison) ;
+- surtout, dès que la **vérité terrain** est disponible (avec délai), **recalculer la performance réelle en
+  production** pour détecter précocement un éventuel **concept drift** : c'est la fermeture de la *feedback
+  loop* MLOps (surveiller -> alerter -> réentraîner -> redéployer).
+
+---
+
+## Reproduire
+
+Sur la VM, dans `~/tp` (venv `/opt/venvs/mlops`). Le TP05 est **100 % local** (données `/data/modelling`) :
+aucun secret réseau (MLflow, S3) n'est nécessaire.
+
+```bash
+# Ré-exécuter le notebook (régénère les sorties + le rapport HTML)
+/opt/venvs/mlops/bin/jupyter nbconvert --to notebook --execute --inplace tp_module5_monitoring_derive.ipynb
+```
+
+Consultation interactive (service `jupyter-tp`, token `mlops`) :
+
+```
+https://jupyter.192-168-122-143.nip.io/lab/tree/tp_module5_monitoring_derive.ipynb?token=mlops
+```