When a Passage Is Stale: Versioning and TTL for Retrieved Context

A freshness policy compares three timestamps and one identity per retrieved passage.

A content hash is the most reliable of the four because it does not depend on anyone remembering to increment a counter. The Oracle reconciliation checklist is a good starting point: does every active chunk point to an active source, did the source text change without the chunk hash changing, and did the chunk text change without a new embedding the Oracle engineering blog.

In practice you do not check every passage on every query. You check at retrieval time using cached values, and run a fuller reconciliation on a schedule. A simple per-request check looks like this:

def freshness_verdict(passage, source_record, now, ttl):
    # passage: chunk metadata; source_record: current source of truth
    if source_record is None or source_record.deleted:
        return "reindex"          # source is gone; chunk is orphaned
    if passage.source_hash != source_record.hash:
        return "re-retrieve"      # source changed; old chunk may be wrong
    if now - passage.ingested_at > ttl:
        return "warn"             # unchanged, but older than policy allows
    return "ok"

The decision rule is the point: identical hashes and a recent ingestion timestamp mean serve normally; a hash mismatch means the passage is suspect; a missing source means the chunk should not be served at all.

A single TTL for the whole corpus is the most common mistake. It either expires stable content constantly (wasting compute) or lets fast-moving content rot (producing wrong answers). Content classes decay at different rates, so TTLs should be set per class and reviewed against how often each class actually changes.

The TTL should be derived from observed change frequency, not guessed. Track two numbers per class: what share of documents in the class changed in the last window, and how often answers changed after re-ingestion. The freshness layer of a RAG evaluation separates this cleanly, tracking the share of indexed documents older than your freshness window and how often answers change after you re-ingest the sources the four-layer RAG evaluation framework.

Time-sensitive questions deserve their own place in the test set. Questions about prices, versions or policies whose correct answer changes over time should be labeled as time-sensitive, and their reference answers re-checked against current sources on a review date the four-layer RAG evaluation framework. That gives you a measurable signal when a TTL is too generous.

Chunk size interacts with TTL more than people expect. Smaller chunks (64 to 128 tokens) work best for concise, fact-based answers, while larger chunks (512 to 1024 tokens) improve retrieval where broader context is needed the chunk size study. A small chunk about a price moves on its own schedule and can expire fast. A 1,000-token chunk covering a whole section mixes stable and volatile facts, so its TTL is set by the fastest-moving sentence inside it. Either keep volatile facts in their own small chunks, or accept the shorter TTL for the whole section.

There are three actions, and each has a place. The mistake is choosing per incident instead of per content class.

Re-retrieve. Fetch the passage again from the source, re-chunk if needed, and replace the context in the prompt before generation. This is the cheapest fix and the right default for latency-sensitive paths. It works when the source system is fast and the document is small. It does not help when the chunk was never indexed correctly to begin with.

Reindex. Rebuild the chunk and its embedding from the current source. This costs an embedding call plus a write, so reserve it for scheduled jobs, for high-value classes, and for cases where the source changed structurally (sections added or removed, which shifts chunk boundaries). Duplicate embeddings from repeated ingestion are a known drift pattern, so reindexing must be idempotent, keyed on source id and chunk hash the Oracle engineering blog.

Serve with a warning. Return the passage and tell the reader it may be outdated, ideally with the source modification date. This is right for contractual or historical content where the older version is still legitimate evidence, and for any case where refusing to answer is worse than answering with a caveat. It is the wrong choice for prices and API references, where a confidently wrong number is worse than no answer.

A worked example makes the cost concrete. Suppose a support corpus has 40,000 documents, an average of 25 chunks each (one million chunks), and 3,000 queries a day. If every query retrieved 6 passages, that is 18,000 passage-level freshness checks daily, most answered from a cached source hash rather than a live read. Reindexing on demand for even 2 percent of retrievals means about 360 embedding writes a day. Nightly full reconciliation of one million chunk hashes against source records is a batch job measured in minutes, not a per-request cost. The design that survives scale is cached hashes with a scheduled reconciliation.

There is a security dimension too. Poor retrieval becomes a security problem when the system cites an obsolete policy, omits a critical warning, or selects a poisoned document, so authoritative and current documents must be identifiable and the system must show provenance for the evidence it used the RAG security audit guide. Freshness metadata is only useful if retrieval filters enforce it the Oracle engineering blog, which means the filter belongs in the query, not in the prompt.

Staleness needs its own detection layer because the usual metrics cannot see it. Retrieval quality metrics such as recall@k, MRR and nDCG measure whether the right passages rank near the top, and generation metrics such as faithfulness and answer relevance measure whether the answer uses them. Neither asks whether the passage is current the RAG evaluation metrics guide. Separating retrieval evaluation from generation evaluation turns a vague quality signal into a diagnosis the Braintrust RAG evaluation guide, and freshness is a third axis alongside them.

Concretely, log four fields per retrieval: passage version, source hash at retrieval, verdict (ok, re-retrieve, reindex, warn), and retrieval timestamp. Then track:

• Stale serve rate: share of served passages whose verdict was not ok.
• Hash mismatch rate per content class: tells you which TTLs are too long.
• Warning rate: how often users see the staleness caveat, which should be near zero for pricing content.
• Mismatch-to-correctness link: among answers built from stale passages, how often the reference answer changed. This tells you whether the TTLs matter at all.

Version your evaluation datasets, prompts, scorers and corpora alongside the pipeline, because a dataset built on older corpus content will silently pass after the sources change the RAG evaluation metrics guide. A versioned evaluation corpus plus a freshness check gives you both halves of the question: is the answer right, and was it right for the current version of the world.

Metadata carries the version and freshness fields you need to filter on. Structured metadata such as filing year, form type and section heading already holds the disambiguating signals retrieval needs, and integrating it into the index improves retrieval effectiveness by increasing intra-document cohesion and widening the separation between relevant and irrelevant chunks the metadata retrieval study. Version and hash are just two more metadata fields, but they must be enforced at query time: filtering by is_current and is_deleted is what stops superseded text from ranking the Oracle engineering blog.

One more trap: chunking changes shift what a version means. If you move from 512-token to 256-token chunks, the old chunks are not v4 of anything; they are a different cut. Treat re-chunking as a migration with its own version scheme, and backfill chunk hashes so the reconciliation job has something to compare.

Start with the cheap signals and add cost only where measurement justifies it.

1. Add source hash and ingestion timestamp to every chunk. No behavior change yet, just data.
2. Log the four retrieval fields for a week and compute the stale serve rate by content class.
3. Assign TTLs from observed change frequency, starting generous and tightening the classes where hash mismatches are common.
4. Wire the verdict into the retrieval query, excluding deleted and superseded chunks by default.
5. Define one action per content class (re-retrieve for policy and product, warn for legal) and test it with challenge queries that check stale and deleted evidence cannot appear in top-k results the Oracle engineering blog.
6. Add time-sensitive questions to the golden set with a review date, so staleness failures become visible in CI rather than in support tickets the four-layer RAG evaluation framework.

If you are evaluating several retrieval setups at once, for instance comparing a fast small model against a larger one for the re-retrieval step, routing all of them through one API key simplifies the comparison and keeps the cost accounting in one place. Quanta Inference exposes text, image, video, audio and embedding models behind an OpenAI-compatible, prepaid interface priced in US dollars.