Knowledge staleness is a data-lifecycle problem

A retrieval system answers from what it indexed, not from what's true now. Everyone knows this, and almost nobody builds for it, because staleness is the one failure that's invisible at query time. The chunk comes back, similarity is high, the answer is fluent — and it describes the pricing policy you retired in March. Nothing errors. That invisibility is exactly why freshness has to be engineered as a lifecycle, with the machinery data engineers use for any decaying asset, rather than hoped for from the retriever.

The measurement work makes the size of the problem concrete. The FreshQA benchmark scores models two ways: relaxed credit for any answer that was ever correct, and strict credit only for answers correct now. The gap between the two — an operational staleness measure — runs 15 to 40 percentage points. That's the fraction of confidently delivered answers that are yesterday's truths. And models make it worse with the now-anchoring problem: they treat their training cutoff as the implicit present, so "the current version" silently resolves to whenever the data was captured — an anchoring failure your index inherits wholesale if documents carry no dates.

Freshness as lifecycle, not vibes

Treating this as lifecycle means four pieces of machinery, none of them exotic. First, temporal grounding: inject the current date into the system prompt, timestamp every chunk at ingestion, and make the generator cite source dates in answers — temporal attribution — so at least the user can see they're reading a 2024 document. Second, validity windows: facts have periods during which they're true, so retrieval should support date-range filtering (timestamp predicates are standard in the major vector stores) and recency weighting — exponential decay with half-lives typically tuned between 30 and 90 days for fast-moving corpora. Third, re-indexing triggers: staleness detection by hash, timestamp, or version comparison against sources, with refresh policies chosen deliberately — event-driven where sources emit changes, scheduled where they don't, lazy where queries are rare — plus cascade invalidation, because a changed document often invalidates derived summaries downstream. Fourth, contradiction handling: when retrieval returns chunks from different dates that disagree, the pipeline needs a precedence rule — usually newest-wins with the conflict surfaced — rather than letting the generator average two truths from different years.

None of this comes from a better embedding model. It's ingestion metadata, index maintenance, and invalidation policy — the same discipline as the rest of the RAG pipeline, applied to the time axis, and close kin to how warehouses handle slowly changing dimensions.

The honest caveat is that decay rates vary enormously by category — political and corporate facts go stale within months, while scientific and geographic knowledge barely moves — so uniform freshness machinery is wasteful. A legal archive or a mathematics corpus doesn't need 30-day half-life decay; aggressive recency weighting there actively hurts, down-ranking the authoritative older document in favour of a recent blog post. The lifecycle should be sized per corpus, and for genuinely static collections, "ingest once, verify occasionally" is a legitimate policy. The trap is arriving at that policy by default rather than by decision.

The test I apply to any retrieval system: can it tell me, for a given answer, when the supporting facts were last verified against their sources? If the answer is "we re-embedded everything at some point last quarter, probably," staleness isn't being managed — it's being amortised into user trust, and that account eventually overdrafts on the query that matters.