ModelRefs / Feature Store — AI Glossary

Feature Store — AI Glossary

A centralized system for storing, serving, and sharing ML feature transformations consistently between training and inference.

Overview

Feature stores (Feast, Tecton, Vertex AI Feature Store, Databricks Feature Store) solve the training-serving skew problem by computing features once and serving them to both training pipelines and online inference. For LLMs: less critical for text input but essential for tabular/retrieval features injected as RAG metadata.

Reference details

Topic	infrastructure
Last reviewed	2026-06-24

How it works

A feature is registered once as a named transformation with an explicit entity key, a value type, and a declared time window.
That single definition is compiled into two execution paths: a batch job producing historical values for training, and a low-latency path serving current values at inference.
Training retrieval is point-in-time correct, joining each label to the feature values as they stood at the label's timestamp rather than as they stand now.
Online values are materialised into a key-value store keyed by entity, so inference is a lookup at single-digit milliseconds instead of a recomputation.
Both paths read the same definition, which is what makes training-serving skew a deployment error rather than an inevitable drift between two codebases.
Registered features become discoverable and reusable, so a second team consumes a definition rather than writing a near-identical one.

Example: Two implementations of one feature, and what the gap does

A model uses average order value as a feature. The training pipeline computes it in batch SQL over a 30-day window; the serving path computes it in a stream processor over a 7-day window, because that is what the stream retains. Consider a customer with 12 orders totalling $1,440 over 30 days, of which 2 orders totalling $310 fall in the last 7. Training saw 1,440 / 12 = $120. Serving supplies 310 / 2 = $155. The model was fitted against $120 and is asked to score $155, so the input it receives is 155 / 120 ≈ 1.29 times the value it was trained to interpret, an overstatement of about 29.2% — and nothing in either pipeline is broken. Both are correct implementations of different definitions, and no test fails. The maintenance arithmetic is the second half of the case. With two independent implementations, a catalogue of 180 features is 2 x 180 = 360 definitions that must agree, and every window change, null-handling rule and timezone assumption has to be made twice. A feature store makes it 180, which is not a 50% efficiency gain so much as the removal of an entire class of defect: the 180 pairs that could silently disagree no longer exist as pairs.

Commonly confused with

A feature store is not a database, though it is built on them, and the distinction is point-in-time correctness. Any warehouse can store feature values; what a feature store adds is the guarantee that a training query returns the values as of each label's timestamp rather than the current ones, which is the difference between a model that generalises and one that trained on information from after the event it was predicting. The second confusion is with a vector database, which the overlapping vocabulary of embeddings encourages. A vector database indexes embeddings for similarity search and answers nearest-neighbour queries; a feature store serves named values by entity key and answers point lookups. A retrieval system often needs both, for different parts of the same request.

When to use it

Reach for it when:

When the same feature is consumed by both training and online inference, which is the skew the architecture exists to remove.
Where point-in-time correctness is required, since reconstructing historical feature state ad hoc is the most common source of leakage.
At catalogue sizes where duplication is the real cost, as 180 features became 360 definitions to keep in agreement above.
For tabular or retrieval metadata feeding an LLM pipeline, where numeric features still need consistent computation.

Reach for something else when:

For pure text-in, text-out LLM applications, where there is no tabular feature surface for it to govern.
On a single offline model with no online serving path, where there are not two implementations to reconcile.
With a handful of features, where the registry and materialisation machinery costs more than the duplication it removes.
As a replacement for a vector index, which answers similarity queries a key-value lookup cannot.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Feature Store — AI Glossary.

Frequently asked questions

What is Feature Store?