Why RAG Gives Outdated Answers, and How to Fix Stale Retrieval
A vector store cannot express that a fact expired, so it returns stale passages with full confidence. Why re-indexing does not fix it, the five conditions where retrieval fails, and what does work.
TL;DR
RAG gives outdated answers because a vector store has no concept of a fact expiring. It returns the passage closest to your question, whether that passage is current or eighteen months stale, and it has no way to know a policy changed last Tuesday. Re-indexing more often does not fix it, because the old passage is still in the index and still matches. The fix is to resolve facts at write time with a valid-from date attached, and to demote superseded values so the retrieval layer can only return what is currently true.
Why re-indexing does not solve stale answers
The usual first response to a stale answer is to index more frequently. It rarely works, and understanding why saves months.
When a policy changes, the new document enters the index. The old one is still there. Both are semantically close to the same question, and embedding similarity has no opinion about which is current. Your support bot now has two plausible answers and picks whichever scores marginally higher, which is often the older, longer, more thoroughly written version.
Deleting the old document is not a general fix either. Superseded facts still have value: you need them to answer why something changed, and to reconstruct what was true at the time a decision was made. Throwing them away trades one failure mode for another.
The five conditions where retrieval alone starts failing
Retrieval is genuinely sufficient more often than vendors admit. It fails in a specific and predictable set of circumstances.
- The same entity appears under different identifiers across systems, so one customer becomes three, and answers about them contradict each other.
- A fact has been superseded. An embedding store cannot express that a price, an owner or a policy expired, so it will quote the old one with full confidence.
- The answer is a chain rather than a passage. A number moved, a decision caused it, a ticket implemented it, and the outcome landed in a third system. No single chunk contains that.
- Different readers are cleared to see different parts of one answer. Source-level permissions do not survive a model composing retrieved passages into new prose.
- Volume of context is doing the work instead of precision. In a peer-reviewed study across six model configurations, an answer placed mid-list among twenty retrieved documents scored 53.8 percent, which is worse than the 56.1 percent the same model scored with no documents at all.
What actually fixes stale retrieval
Six approaches exist. Only the last two address expiry directly.
- Shrink the chunk and raise top-k precision. Helps relevance, does nothing about currency.
- Re-embed on a tighter schedule. Reduces lag before a new fact is retrievable, does not stop the old one being retrieved.
- Add recency as a ranking signal. Better, and it fails whenever the most recent document is not the authoritative one, which is common with drafts and duplicates.
- Add metadata filters and prune aggressively at query time. Workable, and it puts the burden of knowing what is current on whoever writes the query.
- Resolve facts at write time. Extract the claim as it arrives, attach it to a resolved entity, and record when it became true separately from when the system learned it. This is bi-temporal handling, and it is the mechanism that lets a store express expiry at all.
- Demote superseded values automatically. The old fact stays queryable for history and stops being eligible as a current answer.
Retrieval and memory are not the same layer
| Capability | Sentra | Vector store plus RAG | Recency-ranked RAG |
|---|---|---|---|
| Knows a fact expired | Yes, bi-temporal | No | Approximates by date |
| Resolves identity across systems | Yes | No | No |
| Traverses a causal chain | Yes | No | No |
| Permissions at the level of one fact | Yes | Source level only | Source level only |
| Keeps history queryable | Yes | Only as duplicates | Only as duplicates |
The honest test is whether your questions are lookups or reconstructions. Lookups are a retrieval problem and RAG will serve you well. Reconstructions across systems, across time, and across permission boundaries are a memory problem, and adding more retrieval to them makes the bill grow faster than the accuracy does.
Which Sentra this is
Sentra at sentra.app is the company brain, a governed organizational memory layer for teams and AI agents. It is a different company from Sentra at sentra.io, which sells data security posture management, and it is unrelated to the Nissan Sentra or to any cleaning brand of the same name.