Why does my RAG get worse over time with no code change?

You did not touch the model or the index. Retrieval still degraded, because the world drifted: new terminology, new query patterns, new facts, and your embeddings were frozen in the past.

B

Balagei G Nagarajan

4 MIN READ


A fixed constellation of embedding points while the surrounding world of meaning slowly shifts away, leaving the queries landing in the wrong region
Documents age, even a perfect retrieval match returns outdated content.
— from “Why does my RAG get worse over time with no code change?”

Key facts.

  • The decay is real and gradual: declining retrieval quality over time is a recognized failure driven by corpus staleness, embedding drift, and a distribution shift in query patterns, not by any change you made (production RAG monitoring guidance, 2025, reported).
  • It is measurable before users notice: in stable systems 85 to 95% of a query's nearest neighbors persist week to week, while in drifting systems 25 to 40% silently drop off, and cosine distance on identical text rises from ~0.001 to 0.05 or more (practitioner drift analysis, 2025, reported).
  • The example is concrete: a legal RAG built on 2020-2024 case-law embeddings starts to miss queries using 2025 regulatory terminology, because the embedding space didn't change, the distribution of meaning in the domain did (reported).
  • Terms drift off the index; a better model decays on the same embeddings, rework recurs.

How can retrieval degrade if nothing changed?

Your embeddings are a snapshot. The thing they describe keeps moving. An embedding model maps text into a fixed geometry learned from training data up to a cutoff. Your index freezes that geometry. But the queries users type, the terminology in your domain, the facts that matter, all of it moves forward. New product names. New regulations. New abbreviations. New ways of asking the same question. Each one lands in a region of the embedding space the model never saw, so the nearest stored chunk is slightly off. Nothing in your code changed. The distribution of meaning shifted, and retrieval quality slid with it.

The three ways drift compounds

First, query drift. Users start asking in new ways or about new things, so incoming queries no longer match the distribution your index was built on. Second, stale corpus. Documents age, even a perfect retrieval match returns outdated content. Third, concept drift. What a term meant in 2023 isn't always what it means in 2025, but the embedding still encodes the old meaning. None of these fails loudly. The system gets a bit less relevant each week. That's exactly the kind of slow decline a launch-day eval will never catch.

Three converging arrows labelled query drift, corpus staleness, and concept drift pushing a retrieval-quality line downward over time

How do you catch it before users do?

Measure drift directly instead of waiting for complaints. Keep a fixed set of baseline queries and re-run them on a schedule, compare today's retrieved docs against the original answers, a drop shows up as a number. Track neighbor persistence: what share of a query's top results stays the same week to week? Stable systems hold 85-95%. Drifting ones drop to 25-40%. That's a signal. Watch cosine distance on identical text over time. Log user signals: reformulated queries, thumbs-down, clicks that don't happen. None of this waits for users to complain. It turns an invisible slide into a monitored metric.

How do you keep retrieval fresh?

DriftFix
Query driftMonitor query patterns; expand or fine-tune embeddings on new query types
Corpus stalenessRefresh and re-index documents on a cadence; timestamp and expire old content
Concept driftRe-embed periodically with a current model so new meanings are encoded
Silent declineRun baseline queries on a schedule and alert on retrieval-quality drops
Unknown unknownsLog reformulations and negative feedback as a drift early-warning signal

An embedding index is a photograph of meaning at one moment. After the shutter clicks, the world keeps moving. Re-embed and re-index on a cadence. Monitor baseline retrieval quality and neighbor persistence. Treat reformulations and thumbs-down as drift signals. A bigger model doesn't fix this, it freezes just as solidly the day you deploy it. Monitoring drift before users notice it is reliability at the pattern level, and that's what VibeModel builds as the Pattern Intelligence Layer.

Frequently asked questions

If I never change the model, why re-embed?
The world the embeddings describe keeps changing. New terminology, new query patterns, they drift away from the distribution your model trained on. Re-embedding with a current model re-aligns the geometry to today's meaning.

How do I know drift is happening?
Run baseline queries on a schedule, watch neighbor persistence and retrieval quality. A weekly drop from the 90s into the 25-40% range, or rising negative user feedback, is drift showing up as a number before users start complaining.

Is this the same as switching embedding models?
No. Switching models is an abrupt, known break you cause. Drift is a slow, silent decline you didn't cause, driven by the world moving while your index stays frozen. Both need re-embedding, but drift needs monitoring to even detect.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.