SQL avancé pour les features

La feature est une requête

Une feature, c'est une colonne calculée qui aide le modèle : « total dépensé sur 30 jours », « nombre de connexions cette semaine », « écart au panier moyen ». Autrement dit : des agrégats, des fenêtres temporelles, des jointures. Ton SQL est déjà l'outil n°1 du feature engineering — il te manque surtout les window functions si tu les pratiques peu.

Window functions : l'agrégat qui ne réduit pas

GROUP BY réduit à une ligne par groupe. La window function calcule l'agrégat et garde toutes les lignes — exactement le transform de pandas que tu as vu :

SELECT
  client_id,
  montant,
  created_at,
  -- panier moyen du client, répété sur chaque ligne
  AVG(montant) OVER (PARTITION BY client_id)                    AS panier_moyen,
  -- rang de la commande dans l'historique du client
  ROW_NUMBER() OVER (PARTITION BY client_id ORDER BY created_at) AS nieme_commande,
  -- total glissant sur les 5 dernières commandes
  SUM(montant) OVER (PARTITION BY client_id ORDER BY created_at
                     ROWS BETWEEN 4 PRECEDING AND CURRENT ROW)   AS total_5_dernieres
FROM commandes;

Trois features prêtes pour un modèle anti-churn, en une requête.

Le piège mortel : la fuite temporelle

Règle absolue du feature engineering : une feature calculée au moment T ne doit utiliser que des données antérieures à T. Si ta feature « total 30 jours » inclut des événements postérieurs à la prédiction, ton modèle est excellent en test et nul en prod — il a « vu le futur ». C'est le data leakage temporel, la cause n°1 des modèles miraculeux qui s'effondrent au déploiement.

-- ❌ fuite : agrège TOUT l'historique, y compris après la date de prédiction
-- ✅ correct : borne temporelle explicite
SUM(montant) FILTER (WHERE created_at < :date_prediction
                       AND created_at >= :date_prediction - INTERVAL '30 days')

OLTP vs OLAP : où calculer

Tes features s'entraînent sur des années d'historique : ne fais jamais ça sur la base de prod (OLTP). Le pattern standard : répliquer vers un entrepôt analytique (BigQuery, Snowflake, ClickHouse, ou un simple Postgres réplica + parquet) et y calculer les features. La séparation lecture analytique / écriture transactionnelle que tu connais — appliquée systématiquement.