Tacnode™
Glossary
Machine Learning

What Is Embedding Drift?

Embedding drift is a change over time in the distribution of the embedding vectors a system produces, measured against a reference set. It has two causes: the input data shifts, so new items and queries land in regions of the vector space the reference barely covered, or the embedding function changes, through a new model, a new model version or different preprocessing. Similarity queries keep returning results with plausible scores when either happens, so drift can degrade retrieval and downstream models with no obvious failure. It is distinct from stale embeddings, where the model is unchanged but stored vectors were not recomputed after their source data changed.

Updated

What is embedding drift?

The term is most used in ML monitoring, where data drift is tracked on model inputs. Text and images have no simple columns to monitor, so teams monitor their embeddings instead. Evidently AI's 2023 study, Shift happens: we compared 5 methods to detect drift in ML embeddings by Olga Filippova and Elena Samuylova, tested Euclidean distance, cosine distance, a classifier model, the share of drifted embedding components and maximum mean discrepancy (MMD) on artificially shifted datasets. Its conclusion: "Model-based drift detection is a good default." It also cautions that "Data drift detection is a heuristic."

The second cause is a changed embedding function. Each model maps inputs into its own vector space, so distances between a vector from one model and a vector from another aren't meaningful, even when the dimension counts match. Version changes inside one model family matter too. Google's Cloud SQL embeddings guide warns that without a pinned version, "it's possible that a newly published model version could abruptly change the returned vector for a given input." Changes to chunking or text normalization also change the vectors the same content produces.

How embedding drift works

Input drift usually builds gradually. A product catalog adds a category the model saw little of, users start asking about a feature launched last week, or fraudsters change how they write. New embeddings cluster away from the reference, and nearest-neighbor results get worse at the margins.

Representation drift happens at once. A service upgrades its embedding model and new query vectors are compared against a corpus embedded with the old one. Results still come back with plausible scores, but the neighbors are close in the wrong space.

Two simple checks run in PostgreSQL with pgvector, which supports avg() over vectors and the <=> cosine distance operator:

sql
-- 1. Are vectors from more than one model in the same index?
SELECT embedding_model, count(*)
FROM   documents
GROUP  BY embedding_model;

-- 2. How far has this week's query centroid moved from a reference week?
WITH ref AS (
  SELECT avg(embedding) AS c FROM query_log
  WHERE  logged_at >= '2026-09-01' AND logged_at < '2026-09-08'
), cur AS (
  SELECT avg(embedding) AS c FROM query_log
  WHERE  logged_at >= now() - interval '7 days'
)
SELECT ref.c <=> cur.c AS centroid_cosine_distance
FROM   ref, cur;

The first check should return one row. The second is the centroid comparison behind the study's cosine-distance method. It is a coarse signal: the study notes that with distance metrics like Euclidean distance "you might need a few experiments to tune the alert thresholds since the values are absolute," and it recommends the classifier-based method as the default.

Why embedding drift matters in real-time systems

Systems that act on live data see input drift continuously. New merchants, new products, new attack patterns and new vocabulary appear daily, and a reference window from last quarter ages fast. Drift monitoring tells you when retrieval quality is likely slipping; it doesn't fix it. The fixes are a model better suited to the new data, fine-tuning, or a hybrid query that leans on exact predicates and keyword search where similarity is weak.

Representation drift is an operational hazard you control. Record the model and version with every vector, filter queries to the matching version, and treat an upgrade as a migration: embed the corpus into a new column or index, then switch queries over once it is complete. Mixing spaces during a backfill is an easy way to get confident, meaningless results. For how similarity search behaves in production generally, see similarity search.

FAQ

Related terms

Further reading