Why feature stores extended into embeddings for LLM apps

Flashcard·Medium·4.0 · 0·~30s·Asked atEy Stability Ai Truera

Attempt it

Retrieval features (embeddings of customer documents, user preferences, product catalogs) carry the same lifecycle problems as tabular features: they need a single source of truth shared between offline training and online serving, point in time correctness so a backtest does not leak future data, freshness SLOs, and versioning when the embedding model changes.

Feature stores solve all of that for tabular features and the patterns carry over: an embedding feature view defines source, transformation (the embedding model call), TTL, and online and offline materialization. RAG pipelines call the feature store at request time to fetch the latest embedding for a user or item rather than re-embedding on the fly. The win is consistency (the same embedding everywhere), efficiency (no redundant embed calls), and version safety (when you upgrade the embedding model, the feature store backfills and the cutover is auditable). Teams without a feature store re-implement these patterns ad hoc in the vector-DB layer with worse versioning.

Your answer

Feature stores like Tecton and Feast originally solved a classical-ML problem: a model in training saw features computed one way, and a model in production saw features computed a slightly different way, which caused silent quality degradation. The store became the single source of truth for feature values across offline (training) and online (serving) paths. By 2026, RAG and LLM-augmented systems rediscovered the same problem in a new shape. Embeddings of customer documents, user preferences, and product catalogs are features. They share four lifecycle problems with tabular features. **Versioning.** When the embedding model upgrades (text-embedding-3-large to a newer model, or BGE-base to BGE-large), every downstream consumer needs to know which embedding model produced each vector. **Freshness.** Embeddings of mutable entities (user preferences, product descriptions) need a TTL and a re-embed cadence. **Point-in-time correctness.** Backtests of a RAG system on historical traffic should use the embedding values that existed at request time, not the embedding values today. **Offline-online parity.** The embedding used during eval-CI replay should match the embedding served at request time. Feature stores extended their feature-view abstraction to embeddings: an embedding feature view defines the source entity, the transformation (the embedding model call), the TTL, and the online and offline materializations. RAG pipelines call the feature store at request time rather than re-embedding on the fly.

Embeddings have the same lifecycle as tabular features and the same problems happen when you ignore that. **The four shared problems.** Versioning (which model produced this vector). Freshness (how stale is it). Point-in-time correctness (backtests must use the embedding that existed then, not the embedding now). Offline-online parity (eval uses what serving uses). **The feature-store solution carries over.** An embedding feature view in Tecton or Feast looks structurally like a tabular feature view: a source entity, a transformation (the embedding model call), a TTL, and online plus offline materialization. The store backfills, monitors freshness, and stamps version metadata on every value. **The runtime pattern.** The RAG pipeline does not re-embed user inputs or items on the fly. It calls the feature store with the entity id (user-id, document-id) and gets the latest valid embedding. The vector DB holds the index for similarity search; the feature store holds the source of truth for the embedding values themselves. **The win.** Consistency (same embedding everywhere it is consumed), efficiency (no redundant embed calls across services), version safety (an embedding-model upgrade backfills through the store with audit and cutover semantics, not by hand in the vector DB). **Without a feature store**, teams reimplement these patterns ad hoc inside the vector-DB layer. Versioning becomes a tag on the index, freshness becomes a manual re-embed script, point in time correctness is usually missing entirely, and the first embedding-model upgrade after a year of accumulated data turns into a multi-week migration project. The store removes the worst of that.

TL;DR

Embeddings carry the same lifecycle problems as tabular features (versioning, freshness, point in time correctness, offline-online parity), so feature stores extend cleanly to manage them with audit, backfill, and

Memory aid

Easy to grasp

Imagine a library where the cataloging system tracks every book with the same card. The same card tells you where to find it, when it was last checked, and what edition it is. Now imagine the library starts collecting audio recordings of the books too. The audio still needs a location, a freshness check, and an edition number. You could build a whole second cataloging system, or you can extend the existing card to track audio as well as text. Feature stores chose the second path for embeddings: same lifecycle plumbing, new data shape. Teams without a feature store end up building a parallel cataloging system inside the vector database and tend to do it less rigorously.

Key concepts

LLMOps Vector databases

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Feature stores solved a hard problem in classical ML: the training-serving skew that quietly degraded models when offline-computed features did not match the values produced at serving time. The abstraction (source plus transformation plus materialization plus TTL plus versioning) generalized cleanly. By 2026, LLM-augmented systems rediscovered the same lifecycle problems in a new shape: embeddings have all the issues tabular features have, and teams that ignore them pay the same prices in surprising places.

This card walks through why embeddings are features in the lifecycle sense, what the feature-store extension actually provides, how the runtime split with the vector DB works, and the version-upgrade hygiene that becomes possible once the store owns the embedding lineage.

Embeddings are features in the lifecycle sense

Four lifecycle problems define a feature. Embeddings have all four.

Versioning. Every embedding was produced by a specific model. When that model upgrades (BGE-base to BGE-large, text-embedding-3-large to a newer release, a fine-tuned in-house embedder going through a checkpoint bump), the new embeddings are not comparable to the old ones via the same similarity metric. A vector index with mixed versions returns nonsensical results. The version has to be tracked, and queries have to match version to version.

Freshness. Embeddings of mutable entities (user preferences that drift, product descriptions that get updated, document content that revises) need a re-embed cadence. Without a TTL, embeddings go stale and retrieval quality decays silently. Different entity types need different TTLs (a product description re-embeds on every edit; a user-preference embedding re-embeds nightly).

Point-in-time correctness. A backtest of last quarter's RAG traffic on today's embeddings is leaking the future. The eval looks better than reality because the embeddings have benefited from a quarter of content updates and model improvements the system did not have at request time. Honest backtests need the embeddings as they existed at request time.

Offline-online parity. The embedding used in eval-CI replay must match the embedding served at request time. Diverging paths produce surprising regressions that are hard to diagnose.

Feature stores already solve all four problems for tabular features. Extending the abstraction to embeddings is structurally the same plumbing on a new data shape.

The Tecton or Feast embedding feature view

Runtime split with the vector DB

Version-upgrade hygiene and the without-store reality

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Tecton's embedding feature views power personalization at large consumer apps where user embeddings refresh on a TTL and feed both an offline eval set and online RAG retrieval.
Feast extended its feature view abstraction to embeddings in 2024-2025 with first-class vector-store materialization to Pinecone, Milvus, and pgvector.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow do you handle the embedding-model upgrade migration without downtime?

Backfill the new embedding into a parallel index in the feature store, build a parallel vector-DB index, run shadow reads to compare quality, then flag-flip the read path with rollback capability.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Treating the vector DB as the source of truth for embeddings. The vector DB is the serving index; the feature store owns the lineage, versioning, and freshness contract.

60 second bullets to scan on the way to the call.

Why versioning matters when the embedding model upgrades
Freshness and TTL for mutable entities

Primary sources. Browse if you want the original framing.