Feature store
Aussi : feature store, ML feature store, feature repository, magasin de features, entrepôt de caractéristiques
A centralised repository managing ML features, ensuring consistency between training and serving environments.
What it is
A feature store is a centralised system for defining, storing, and serving the features used by machine learning models. A feature is a single measurable input to a model, for example a customer's average purchase value over the last 30 days, or the number of days since their last login.
The core problem a feature store solves is consistency. Models are trained on historical data but make predictions on live data. If the feature is computed one way during training and a slightly different way during live serving, the model degrades silently. This mismatch is known as training-serving skew. A feature store enforces a single definition used in both places.
Why it matters
- Reuse: A feature built by one team (for example "customer lifetime value") can be shared across many models instead of being rebuilt each time.
- Consistency: The same transformation logic runs for training and for real-time prediction.
- Governance: Features are documented, versioned, and access-controlled, which supports audit and regulatory review.
- Speed: Data scientists spend less time on repetitive data plumbing and more on modelling.
How it is used in practice
A feature store typically has two sides:
- An offline store (large historical tables) used to build training datasets.
- An online store (low latency database) used to serve fresh feature values to live models in milliseconds.
A pipeline computes feature values from raw data and writes them to both stores. Teams register each feature with metadata: its name, owner, definition, and freshness. When a model needs data, it requests features by name rather than reimplementing the logic.
Worked example
A bank builds a fraud detection model. One feature is transactions_last_hour.
1. During training, the offline store returns the historical count of transactions in the hour before each past transaction.
2. When a card is swiped in production, the model calls the online store, which returns the same feature computed on live data within milliseconds.
3. Because both paths share one definition, the score the model produces in production matches what it learned in training.
If the marketing team later builds a churn model, they reuse the same feature without rebuilding it, and finance can trace exactly which inputs drove a decision.