Feature store standardiser les variables

Un des échecs les plus courants du machine learning en production est la divergence entre l’entraînement et l’inférence. Les données utilisées pour entraîner un modèle ne sont pas calculées de la même manière que celles fournies au modèle pour une prédiction en temps réel. Un feature store est la solution pragmatique à ce problème : c’est une bibliothèque centralisée où la logique de calcul de chaque variable (feature) est définie une seule fois. Il se charge ensuite de la matérialiser pour l’entraînement (batch) et de la servir à faible latence pour l’inférence (online).

prérequis

Un entrepôt de données (data warehouse) capable de gérer des partitions temporelles.
Un orchestrateur (Airflow, Dagster) pour planifier les calculs en batch.
Un stockage clé-valeur rapide (Redis, DynamoDB) pour le service en ligne (online serving).

idées clefs

Un feature store est construit sur trois piliers fondamentaux.

pas à pas

étape 1: définir une feature

La feature est définie comme du code, généralement dans un fichier de configuration. C’est le contrat qui décrit la variable, son propriétaire et ses métadonnées.

# features/definitions/nb_commandes_30j.yml
- name: user_nb_commandes_30j
  owner: team-sales
  description: "nombre de commandes passées par un utilisateur sur les 30 derniers jours."
  entity: user_id
  value_type: int64
  freshness:
    offline: 24h
    online: 1h

étape 2: calculer pour l’entraînement (offline)

Un job, généralement en SQL, est orchestré pour calculer la valeur de cette feature sur tout l’historique des données et la stocker dans l’entrepôt de données (offline store). C’est ce que les data scientists utiliseront pour entraîner leurs modèles.

-- job orchestré quotidiennement
INSERT INTO feature_store.user_nb_commandes_30j
SELECT
    user_id,
    CURRENT_DATE AS feature_date,
    COUNT(DISTINCT order_id) AS value
FROM
    raw.orders
WHERE
    order_date >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY 1;

étape 3: servir pour l’inférence (online)

Un autre processus se charge de calculer la même feature à une fréquence plus élevée et de la “pousser” dans un stockage rapide (online store). Une API peut alors être interrogée par les applications pour obtenir la dernière valeur d’une feature pour une entité donnée.

# L'application appelle une API pour obtenir les features d'un utilisateur
GET /features?entity=user_id&id=xyz-789
Host: feature-store-api.internal

# Réponse JSON
{
  "user_nb_commandes_30j": 5,
  "user_panier_moyen_90j": 75.50
}

pièges frequents

Symptôme: Les performances du modèle en production sont bien pires que prévu.
- Cause: La logique de calcul des features dans l’API de production n’est pas exactement la même que celle du notebook de recherche.
- Correctif: Le feature store impose une définition unique. C’est son rôle principal.
Symptôme: Les features servies en ligne ne sont pas assez fraîches, ce qui cause des prédictions erronées.
- Cause: La fraîcheur de la feature n’est pas définie ni surveillée.
- Correctif: Chaque feature doit avoir un SLO de fraîcheur explicite (ex: “mise à jour toutes les 5 minutes”). Des alertes doivent se déclencher si ce SLO n’est pas respecté.
Symptôme: Risque de fuite de données car des features sensibles sont accessibles trop facilement.
- Cause: Pas de gestion des droits d’accès au niveau des features.
- Correctif: Le feature store doit intégrer une gestion des droits (RBAC). Une équipe marketing ne devrait pas pouvoir accéder aux features de risque crédit, par exemple.

faq

Est-ce qu’un feature store est juste une base de données ? Non. C’est un système complet qui gère la définition, le calcul, le stockage (offline et online), le service, la documentation et la gouvernance des features. La base de données n’est qu’un des composants.
Quand ai-je vraiment besoin d’un feature store ? Le signal est clair : lorsque plusieurs modèles commencent à réutiliser les mêmes variables, ou lorsque vous constatez des écarts de performance entre l’entraînement et la production. Si vous n’avez qu’un seul modèle simple, c’est probablement superflu.

Menu