53 lines
5.7 KiB
Markdown
53 lines
5.7 KiB
Markdown
# Cadre prédictif local
|
||
|
||
Objectif : poser les bases d’un modèle sur-mesure qui prédit, au pas local de la station, la température, la pluie et le vent à plusieurs horizons (T+10 min, +60 min, +6 h, +24 h).
|
||
On garde une approche expérimentale : on cherche à comprendre ce qui fonctionne ou échoue, non pas à atteindre une performance commerciale.
|
||
Il ne s'agit pas ici de venir concurrencer Météo France, mais de jouer avec nos données et avec l'IA.
|
||
|
||
## Cibles et horizons
|
||
|
||
- Température (continue) ; Vitesse du vent (continue) ; Précipitations binaires (pluie ou neige oui/non). Éventuellement : événements extrêmes (forte chaleur/froid, risque d’orage) vus comme des seuils.
|
||
- Horizons évalués : T+10, T+60, T+360 (~6 h), T+1440 (~24 h) minutes pour voir quand notre modèle montrera ses faiblesses.
|
||
|
||
## Métriques
|
||
|
||
- Température / vent : _MAE_ (_Mean Absolute Error_) = moyenne des écarts en valeur absolue, facile à lire en °C ou km/h ; _RMSE_ (_Root Mean Squared Error_) pénalise davantage les grosses erreurs pour mieux voir les limites du modèle lorsque des écarts importants apparaissent.
|
||
- Précipitations binaires : précision (part des annonces de pluie qui étaient justes), rappel (part des pluies réellement captées), _F1_ (compromis précision/rappel), _Brier score_ (qualité des probabilités, plus il est bas mieux c’est) et _calibration_ des probabilités (est-ce qu’un 30 % de pluie signifie vraiment ~30 % des cas).
|
||
- Événements extrêmes : même logique précision/rappel sur dépassement de seuils (chaleur/froid/rafale), avec suivi des fausses alertes pour rester prudent.
|
||
|
||
## Limites à garder en tête
|
||
|
||
- Pas d’hiver complet dans le jeu actuel (mars→novembre) : les régimes froids et la neige sont absents.
|
||
- Aucune info synoptique (pression régionale, nébulosité, vent en altitude) : le modèle reste “aveugle” au contexte large.
|
||
- Pluie rare (~4 % des pas), donc classes déséquilibrées pour la partie pluie/orage.
|
||
- Pas brut à 10 minutes : bon pour réactivité courte, mais bruité ; on testera aussi des features lissées.
|
||
|
||
## Données et découpes
|
||
|
||
- Source principale : `data/weather_minutely.csv` (pas 10 min), enrichissable au fil du temps. On peut réutiliser les CSV dérivés des chapitres précédents (matrices de lags/corrélations du chapitre 5, notamment) pour guider les lags utiles ou vérifier la cohérence.
|
||
- Découpe temporelle sans fuite : partie _train_ (début→~70 %), partie validation (~15 % suivant), partie test finale (~15 % le plus récent). Variante : _time-series split_ “en rouleau”, où l’on répète ce découpage plusieurs fois ; on appelle _fold_ chaque paire (train, validation) ainsi construite.
|
||
- Normalisation/standardisation : on calcule les paramètres (par exemple moyenne et écart-type) uniquement sur la partie _train_, puis on applique ces mêmes paramètres à la validation et au test. Cela évite d’introduire, par mégarde, des informations issues du futur dans les étapes de préparation des données.
|
||
|
||
## Variables dérivées de base (simples et explicables)
|
||
|
||
- Temps (_sin_/_cos_) : l’heure et le jour de l’année sont périodiques ; représenter l’heure avec _sin_/_cos_ évite un faux saut entre 23h et 0h ou entre 31 déc et 1er jan. On encode ainsi heure/minute sur 24 h et jour de l’année sur 365 j.
|
||
- Lags courts : valeurs à T-10, -20, -30 min pour chaque variable cible ; deltas (T0 − T-10) pour décrire la tendance récente (la “pente”) : est‑ce que la température, le vent ou la pression augmentent ou diminuent, et à quelle vitesse. Les lags analysés au chapitre 5 serviront d’inspiration.
|
||
- Moyennes glissantes : moyenne ou médiane sur 30–60 min pour lisser le bruit ; cumul de pluie sur 30–60 min pour connaître l’état “humide” récent.
|
||
- Composantes vent : (u, v) = (speed _ *sin*(direction), speed _ _cos_(direction)) pour représenter la direction sans discontinuité 0/360°.
|
||
- Drapeaux d’événements : pluie*en_cours (rain_rate > 0), vent_fort (seuil), chaleur/froid (seuils). Peuvent servir de \_features* et de cibles dérivées.
|
||
|
||
## Références simples (points de comparaison)
|
||
|
||
- Persistance : prédire que la valeur reste identique à T0 (par horizon).
|
||
- Climatologie horaire : moyenne/quantiles par heure locale (et éventuellement par saison) pour température/vent ; fréquence de pluie par heure pour la pluie.
|
||
- Moyenne mobile : prolonger la moyenne des 30–60 dernières minutes comme prédiction à court terme.
|
||
- Pluie rare : classifieur “toujours sec” comme référence minimale. Si un modèle ne fait pas mieux, il est probablement inutile.
|
||
|
||
## Modèles à introduire dans les chapitres suivants
|
||
|
||
- Modèles linéaires avec régularisation (_Ridge_/_Lasso_) pour températures/vents : même formule que la régression linéaire classique, mais avec un terme supplémentaire qui limite l’ampleur des coefficients pour réduire le sur‑apprentissage (_Ridge_ pénalise surtout les coefficients trop grands, _Lasso_ peut en forcer certains à zéro).
|
||
- Régression logistique pour la pluie : produit une probabilité de pluie plutôt qu’un oui/non brut, ce qui permet ensuite de choisir un seuil de décision adapté à l’usage (plutôt prudent ou plutôt conservateur).
|
||
- Si besoin de courbes plus flexibles : arbres peu profonds, _random forest_ ou _boosting_ légers pour capturer des relations non linéaires sans rendre le modèle complètement opaque.
|
||
- Évaluation multi-horizons avec _time-series split_, courbes d’erreur en fonction de l’horizon pour voir à partir de quand le modèle décroche.
|
||
- Pipeline d’inférence local (_pipeline_ de prédiction) : charger le dernier point, générer les variables dérivées, prédire T+10/+60/+360/+1440, journaliser l’erreur au fil du temps pour suivre la qualité du modèle.
|