# TP02 - Synthèse : comparer et tracer des expérimentations ML

Fil rouge : prédiction de la consommation électrique (kWh). Datasets versionnés avec **DVC**
(remote S3 = Garage), expériences tracées avec **MLflow** (expérience `tp02_electricity_consumption`,
13 runs : 10 régressions linéaires + 3 Ridge).

Deux versions de dataset produites et versionnées (tags git + DVC) :

| Version DVC | Tag git | Train | Validation | Test |
|---|---|---|---|---|
| v1 `full_history` | `dataset-v1-full-history` | 2011-2012 | 2013 | 2014 |
| v2 `recent_history` | `dataset-v2-recent-history` | 2013 | jan-mai 2014 | juin-déc 2014 |

Métriques comparées : **RMSE** et **MAE** sur la **validation** (le test reste réservé).

---

## Partie 1 - Comparaison de stratégies de features (split `full_history`)

Stratégies testées (hypothèse -> features) :

| Stratégie | Hypothèse | Features |
|---|---|---|
| `short_memory` | la conso dépend surtout de la veille | lag_1d |
| `seasonality` | conso plus saisonnière que journalière | lag_7d, lag_30d |
| `tendency` | conso surtout tendancielle | rolling_mean_7d, rolling_mean_30d |
| `mixed` | mémoire courte + tendance | lag_1d, lag_7d, lag_30d, rolling_mean_30d |
| `full` | toutes les features | les 6 |

Résultats (validation, `full_history`) :

| Stratégie | RMSE | MAE |
|---|---|---|
| `full` | **7.41** | **4.07** |
| `mixed` | 7.53 | 4.11 |
| `short_memory` | 8.82 | 4.58 |
| `seasonality` | 9.14 | 5.04 |
| `tendency` | 20.79 | 14.66 |

**1.1 - Quelle stratégie obtient les meilleures performances ?**
`full` (6 features) puis `mixed` (4 features), quasi à égalité. Toutes deux combinent lags courts
et tendance. `tendency` (moyennes glissantes seules) est de loin la pire.

**1.2 - Ajouter davantage de features améliore-t-il systématiquement le modèle ?**
Non. `short_memory` (1 feature) fait 8.82 alors que `tendency` (2 features) fait 20.79 : c'est la
**pertinence** des features, pas leur nombre, qui compte. Et `full` (6) n'améliore `mixed` (4) que
marginalement (7.41 vs 7.53) : rendements décroissants, les features supplémentaires apportent peu.

**1.3 - Quelles hypothèses semblent validées ?**
- « La conso dépend de la veille » : validée, `lag_1d` est le prédicteur dominant (voir coefficients).
- « Plutôt tendancielle » (moyennes glissantes seules) : **invalidée** (pire modèle).
- La conso combine **mémoire court terme + tendance** : validée (mixed/full gagnants).

---

## Partie 2 - Comparaison des stratégies d'entraînement (split)

Chaque stratégie ré-entraînée sur `recent_history`. Matrice RMSE (validation) :

| Stratégie | `full_history` | `recent_history` |
|---|---|---|
| `short_memory` | 8.82 | 8.30 |
| `seasonality` | 9.14 | 7.60 |
| `tendency` | 20.79 | 18.56 |
| `mixed` | 7.53 | 6.67 |
| `full` | 7.41 | **6.58** |

La stratégie `full` a été relancée sur **la première version du dataset (v1) restaurée via DVC**
(`git checkout dataset-v1-full-history -- ... && dvc checkout`), illustrant la reproductibilité.

**2.1 - Quel split obtient les meilleures performances ?**
`recent_history` : RMSE plus bas pour **les 5 stratégies** (env. -12 %).

**2.2 - Davantage d'historique ou données plus récentes ?**
Ici, **données plus récentes**. Nuance importante : la comparaison n'est pas strictement iso car les
fenêtres de validation diffèrent (2013 pour `full_history` vs début 2014 pour `recent_history`).
Prédire début 2014 à partir de 2013 (année adjacente) est plus « facile » que prédire 2013 à partir
de 2011-2012. Enseignement : la **proximité temporelle train/validation** (moins de dérive) prime sur
le simple volume d'historique ancien.

**2.3 - Avantages / inconvénients de chaque approche ?**
- `full_history` : + capte les cycles longs (saisonnalité annuelle), robustesse au bruit ponctuel ;
  - inclut des données anciennes possiblement obsolètes (data/concept drift), plus coûteux, validation lointaine.
- `recent_history` : + colle au régime actuel (moins de drift), moins coûteux ;
  - moins de données (variance accrue), saisonnalités longues moins fiables (`lag_365d`), sensible aux
    événements récents atypiques.

**2.4 - Bonus : coefficients du modèle** (linéaire `full`, `recent_history`), par influence décroissante :

| Feature | Coefficient |
|---|---|
| lag_1d | +0.460 |
| lag_7d | +0.371 |
| rolling_mean_7d | +0.288 |
| rolling_mean_30d | -0.268 |
| lag_365d | +0.090 |
| lag_30d | +0.058 |

- Les plus influentes : `lag_1d` (la veille) et `lag_7d` (semaine dernière), puis la paire
  `rolling_mean_7d` (+) / `rolling_mean_30d` (-) qui agit en **différentiel de tendance** court/moyen terme.
- Les peu utilisées : `lag_30d` et `lag_365d` (mensuel/annuel apportent peu une fois les autres présentes).
- Cela **confirme les hypothèses de la Partie 1** : mémoire court terme + tendance courte dominent.

---

## Partie 3 - Influence des hyperparamètres avec Ridge

Sur le meilleur couple (features `full`, split `recent_history`), alphas `[1, 1e3, 1e9]` :

| alpha | RMSE (val) | MAE (val) | RMSE (train) |
|---|---|---|---|
| 1 | **6.576** | **3.677** | 7.397 |
| 1e3 | **6.576** | **3.677** | 7.397 |
| 1e9 | 7.059 | 4.185 | 8.115 |

Coefficients selon alpha :

| Feature | alpha=1 | alpha=1e3 | alpha=1e9 |
|---|---|---|---|
| lag_1d | 0.460 | 0.460 | 0.284 |
| lag_7d | 0.371 | 0.371 | 0.263 |
| lag_30d | 0.058 | 0.058 | 0.158 |
| lag_365d | 0.090 | 0.090 | 0.174 |
| rolling_mean_7d | 0.288 | 0.287 | 0.069 |
| rolling_mean_30d | -0.268 | -0.268 | 0.043 |

**3.1 - Quelle valeur d'alpha obtient les meilleures performances ?**
`alpha=1` (identique à `alpha=1e3`). `alpha=1e9` dégrade nettement (RMSE 7.06).

**3.2 - Que se passe-t-il sur les coefficients quand alpha augmente ?**
Ils sont **contraints vers zéro** (régularisation L2). À `alpha=1` et `1e3` : quasi identiques, car la
pénalité reste négligeable devant ~4,5 M d'échantillons. À `alpha=1e9` : forte contraction, les
coefficients dominants s'écrasent (`lag_1d` 0.46 -> 0.28, `rolling_mean_7d` 0.29 -> 0.07,
`rolling_mean_30d` -0.27 -> +0.04) ; le modèle devient plus « plat » (biais accru) -> RMSE augmente.

**3.3 - Pourquoi est-il indispensable de logger les hyperparamètres ?**
Pour la **reproductibilité et la comparabilité** : une métrique n'a de sens qu'associée à ses HP (alpha,
features, split). Sans, impossible de reproduire un run, d'expliquer un écart de performance ou de
comparer objectivement. MLflow lie chaque métrique à ses paramètres -> traçabilité complète.

**3.4 - Bonus : que représente le bruit ? Faut-il l'apprendre ?**
Le bruit = variations aléatoires non reproductibles (erreurs de mesure, aléas ponctuels). Il **ne faut
pas** l'apprendre : le modèle mémoriserait des accidents particuliers (overfitting) au lieu de la relation
générale, et généraliserait mal. Exemple : un pic de conso dû à une canicule exceptionnelle un 15 août
ne doit pas devenir une règle.

**3.5 - L'ordre de grandeur des coefficients a-t-il un effet ? Et avec du bruit ?**
Oui : de grands coefficients rendent la prédiction très sensible aux petites variations des features
(amplification). En présence de bruit, ils **amplifient ce bruit** -> prédictions instables, variance
élevée (overfitting). Des coefficients plus petits lissent la réponse.

**3.6 - Rôle de l'hyperparamètre alpha ?**
alpha règle le **compromis biais/variance** en pénalisant la magnitude des coefficients : alpha faible ->
modèle libre (variance élevée, risque d'overfitting) ; alpha élevé -> coefficients contraints (biais
élevé, risque d'underfitting). C'est le levier de régularisation pour améliorer la généralisation face
au bruit.

**3.7 - Comment utiliser un dataset de test dans le choix d'un hyperparamètre ?**
On ne choisit **jamais** alpha sur le test. On règle alpha sur la **validation** (comparaison des alphas),
puis on mesure **une seule fois** le modèle retenu sur le **test** (jamais vu) pour une estimation non
biaisée de la généralisation. Utiliser le test pour régler alpha revient à le « fuiter » -> estimation
trop optimiste.

---

## Partie 4 - Réflexion en production

**4.1 - Sur quelles données entraîner ?**
Sur une **fenêtre glissante de données récentes** représentatives du régime actuel (ici `recent_history`
l'emporte), en réintégrant régulièrement les dernières observations, tout en gardant assez d'historique
pour capter les saisonnalités utiles (semaine, éventuellement année si stable). Compromis récence/volume.

**4.2 - À quelle fréquence réentraîner ?**
Réentraînement **périodique** (hebdomadaire à mensuel selon le coût et la vitesse de dérive) **et**
déclenché **par événement** (dégradation des métriques ou détection de drift). La forte saisonnalité de
la conso justifie au minimum un rythme régulier accompagné d'une surveillance.

**4.3 - Quels indicateurs signalent un nouvel entraînement ?**
- **Dégradation des métriques** en production (RMSE/MAE qui remontent vs baseline).
- **Data drift** : la distribution des features d'entrée s'éloigne de celle d'entraînement.
- **Concept drift** : la relation features -> cible change (nouveaux usages, réglementation, météo extrême).
- Écart croissant entre distributions **train vs production** (surveillance type Evidently/Grafana).

---

## Livrables - synthèse finale

- **Stratégies de features testées** : `short_memory`, `seasonality`, `tendency`, `mixed`, `full`.
- **Résultats** : voir matrices ci-dessus (validation RMSE/MAE).
- **Meilleur run MLflow** : features `full` sur le split `recent_history` (RMSE **6.576**, MAE **3.677**) ;
  en linéaire comme en Ridge `alpha` ≤ 1e3 (résultats indistinguables ; run Ridge `alpha=1e3`
  `id 57cac1f5...`).
- **Impact du changement de split** : `recent_history` améliore **toutes** les stratégies (~ -12 % RMSE),
  résultat à nuancer (fenêtres de validation différentes -> proximité temporelle avantageuse).
- **Stratégie recommandée en production** : features **`mixed`** (parcimonie : quasi identique à `full`
  mais 4 features au lieu de 6, `lag_30d`/`lag_365d` contribuant peu), entraînée sur une **fenêtre de
  données récentes**, avec **Ridge `alpha` modéré (1 à 1e3)**.
- **Raisons** : meilleure performance en validation, modèle plus simple donc plus robuste et
  maintenable, données récentes = moins de dérive, régularisation légère = filet de sécurité contre le
  bruit sans coût de performance.