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.

10 KiB Raw Permalink Blame History