RAG Freshness: Faster Re-indexing Is the Wrong Fix

A RAG index goes stale in two different ways, and almost all of the 2026 advice fixes only one of them. Change lag is the gap between a document being edited and its vectors being updated, and event-driven re-indexing closes it. Version collision is the superseded document that is still present, still reads as correct and still scores well on similarity. No re-indexing schedule touches that one.

What does a stale RAG index actually look like?

The symptom is reported the same way every time. The assistant quotes a rate that was withdrawn in March. It cites a work instruction that was replaced after an incident. It answers a question about leave entitlement from a collective agreement that expired last year.

The engineer checks the pipeline, sees that last night's run completed, and concludes the index is healthy. The index is healthy. Retrieval worked correctly too. The chunk it returned is a real chunk of a real document that really is in the corpus. Nothing failed. The system simply has no concept of which of its documents is still true.

That is worth separating into two distinct problems, because they have different fixes and only one of them is fashionable:

• Change lag. A document changes at 10:00, the nightly job runs at 02:00, and for sixteen hours the index describes a world that no longer exists. Fixed by incremental or change-driven re-indexing: detect the change, re-embed only the affected chunks, invalidate the caches that touched them.
  - Version collision. Version 1, version 2 and version 3 of the same procedure are all in the corpus, all legitimately stored, all semantically almost identical. Fixed by nothing in the pipeline, because the pipeline is behaving correctly.

Most of the 2026 freshness writing is about the first. Streaming architectures, change-data-capture connectors, chunk hashing, embedding-model versioning: all correct, all worth doing, and none of them decide which of two surviving versions is the live one. The vendor guidance is starting to close that gap. Oracle's July 2026 note on index drift tells you to track chunk lifecycle state explicitly as current, superseded, deleted, failed or quarantined, and to exclude superseded chunks from retrieval by default. That is the right instruction. What it does not answer is the question a Dutch firm hits immediately afterwards: what do you do when the law requires the superseded version to stay?

Why doesn't faster re-indexing fix version collision?

Because an embedding encodes meaning, and validity is not meaning. The 2024 price list and the 2026 price list say close to the same thing in close to the same words. That near-identity is exactly what places them next to each other in vector space, and a similarity search has no reason to prefer one.

It gets worse the better run your company is. A firm that has used one quotation template for a decade, one procedure format across every department and one house style for customer letters has produced a corpus in which every version of every document is a close neighbour of every other version. Document discipline, which is a virtue everywhere else, is what makes this failure mode severe.

The research has now measured it. VersionRAG built VersionQA, a benchmark of 100 manually curated questions over 34 versioned technical documents, and reported naive RAG at 58% accuracy and GraphRAG at 64%, against 90% for a version-aware pipeline. On implicit change detection, where a modification was never documented, the baselines scored between 0% and 10% and the version-aware system reached 60%.

Read those numbers as a direction rather than a rate. A hundred questions over thirty-four documents is a small benchmark and the absolute figures will not reproduce on your corpus. The direction is not in doubt, and it matches what production teams report: the gap is not in the retriever, it is in the absence of any validity check after retrieval.

What do the 2026 enterprise benchmarks actually test?

Two papers published this year are more interesting for what they assume than for what they propose.

EnterpriseRAG-Bench, released in May 2026, is a synthetic corpus of roughly 500,000 documents across nine enterprise source types, including Slack, Gmail, Google Drive, HubSpot, GitHub, Jira and Confluence, with 500 questions over ten categories. The design decision that matters: the corpus is deliberately augmented with misfiled documents, near-duplicates and conflicting information, and the question set includes conflict resolution and recognising when information is simply absent. The dataset and harness are public, and the generation framework lets a team produce a variant matching its own source mix. That is a benchmark built on the premise that a real company archive contradicts itself.

ConflictRAG, from May 2026 and revised in June, states the premise outright: RAG systems assume mutual consistency among retrieved documents, and that assumption frequently fails. Its detection stage is worth copying even if you never adopt the rest: a lightweight embedding-based classifier runs first and a language model refines only the uncertain cases, which the authors measure at 90.8% detection accuracy for 62% lower API cost, with 88.7% F1 on conflict detection.

Put the three together and the frontier has moved. The question is no longer how to retrieve better. It is how to decide which of the retrieved things is still true.

What does re-embedding actually cost a Dutch SME?

The usual argument for streaming re-indexing is cost. It is worth doing that arithmetic in full, because at SME scale the conclusion inverts.

Assume a corpus of 40,000 documents: quotations, work orders, procedures, contracts and a mail archive, which is a plausible shape for a firm of 20 to 50 staff. Assume 1,200 words per document on average, and roughly 1.35 tokens per word for mixed Dutch and English business text. That is about 65 million tokens.

OpenAI's published prices on 18 September 2026 are $0.02 per million tokens for text-embedding-3-small and $0.13 for text-embedding-3-large. So:

• A full rebuild with the small model costs about $1.30. Run it every night for a year: about $470.
  - Re-embedding only 1% of documents per day costs about $0.013 a day, or roughly $4.70 a year.
  - With the large model the same two figures are about $3,075 and about $31.

The saving is real, it is roughly the hundredfold that the streaming case claims, and on the small model it is four hundred and sixty-five dollars. For a firm paying a developer 80 euro an hour, a year of nightly full rebuilds costs roughly six hours of that developer's time.

Two honest caveats. This covers embedding API calls only: parsing, chunking, storage and the vector database are excluded, and at millions of documents the absolute numbers stop being a rounding error. And a nightly rebuild still leaves change lag of up to a day, which for some document classes is genuinely unacceptable.

But if incremental indexing was chosen to save money, it optimised the least expensive line in the system. The expensive line is the quotation a salesperson sent from a withdrawn rate card.

Why can't Dutch companies simply delete the old version?

The obvious fix for version collision is pruning: keep one version, discard the rest. In many corpora that works. In a Dutch company it runs into the bewaarplicht.

The Belastingdienst requires the administration to be kept for seven years, and data relating to immovable property for ten, because of the VAT revision period. The retention clock starts when a document stops being current, not when it was created, which is precisely the moment your index most wants it gone.

So the superseded quotation, the withdrawn rate card and the previous set of terms and conditions all have to stay somewhere reachable. What follows is an architectural distinction that most SME retrieval builds never make: the retention archive and the retrieval index are not the same store and should not hold the same contents. Keeping everything is a legal duty. Retrieving everything is a design choice, and a poor one.

What is a staleness budget and how do you set one?

Before anything is embedded, decide two things per document class: how long an out-of-date answer is tolerable, and what happens to the version it replaced. The result is a short table, and for a Dutch firm most of its rows are set by a contract or a statute rather than by taste. That table determines the metadata schema everything else hangs off.

• Rate cards and price lists. Tolerance: minutes. Exactly one version live in the index, the rest archived out of it entirely.
  - Quotations and contracts. Tolerance: hours. All versions indexed, each stamped with validity dates and a status, with retrieval filtered to current by default.
  - Work instructions and procedures. Tolerance: a day. One current version, with a pointer to what it superseded so the assistant can say what changed and when.
  - Terms and conditions. Tolerance: immediate, but versioned by effective date, because for a customer who signed in 2024 the 2024 version is the correct answer.
  - Collective agreements and personnel rules. Tolerance: days, with effective-date filtering mandatory rather than optional.
  - Project folders and mail archive. No freshness guarantee at all. Index them, rank them below the governed sources, and have the assistant say which tier an answer came from.

How do you build version-awareness without a research framework?

Four moves, none of which needs a graph database, or the database features the vendor checklists assume you have.

Stamp validity at ingestion, not at query time. Every chunk carries source system, document id, version, valid-from, valid-to and status. If the source system cannot supply those fields, that is a finding about your document management rather than a reason to skip the column.

Make superseding explicit. A pointer from the old version to the new one costs nothing to store and converts "which of these is current" from a semantic judgement into a lookup.

Filter before you rank. Default the retriever to status equals current unless the query carries a date or asks about history. Most systems do this the other way round: retrieve everything, then hope the reranker holds opinions about time. It does not.

Put stale twins in the evaluation set. Take twenty real questions and make sure that for each one the corpus contains at least one plausible superseded answer. If the system cannot separate them in your evaluation, it certainly will not in production. This costs the least of the four and is the one most often skipped.

What this means if you are running an assistant on your own documents

For a Dutch company of 20 to 50 staff, the freshness question is not how often to re-index. It is whether the system knows which of its documents is still true, and whether it can say so in the answer.

There is often a shortcut. The most current version of a price, a customer record or an order status is usually not in a document at all, it is in Exact, AFAS or your bookkeeping package. Retrieving a document that describes a number is a worse answer than calling the system that owns it. Every field you can move out of the corpus and into a live API call is a field that cannot go stale.

For everything that genuinely has to live in documents, the fix is usually a metadata pass over the corpus you already have rather than a new pipeline, and it needs an owner after go-live. That is the same argument as the structural choice between RAG and GraphRAG and the same reason a private AI assistant is a governed system rather than a one-off project. Somebody has to own the staleness budget once the build team has left, which is what ongoing AI management is for.

Last updated: 18 September 2026.

Frequently asked questions