Your RAG Is Not Fresh Just Because the Index Is Online

A retrieval system can return a document that is highly relevant, correctly cited, and still wrong for the question being asked.

That happens when the document is obsolete, superseded, outside the requested date range, or no longer authoritative. The model may answer fluently because the retrieved passage looks plausible. Similarity scores remain healthy. Latency remains normal. The citation link works. Nothing in a conventional infrastructure dashboard necessarily says that the answer is unsafe.

Grounding is not only “which source supports this sentence?” It is also “which version was valid for this question, and how fresh is it allowed to be?”

This distinction matters for product documentation, pricing, internal policies, security advisories, regulations, operational runbooks, and any agent that acts on changing information.

Relevance and validity are different retrieval problems

Dense retrieval optimizes semantic similarity. It is good at finding passages that mean something similar to the query. It does not automatically know whether the passage is current, effective, superseded, or authoritative.

A deprecated API guide can be a perfect semantic match for “How do I authenticate?” A 2025 reimbursement policy can be the most similar result for “What can I claim this year?” A current legal article can still be the wrong answer when the user asks about a historical date.

Databricks describes production RAG as a pipeline of ingestion, embedding, retrieval, augmentation, and generation. Each layer can be optimized independently, but a strong generator cannot compensate for a weak retriever. Their guidance also recommends metadata such as document dates and source URLs, continuous updates, hybrid search, reranking, similarity thresholds, and separate evaluation of retrieval precision and generation faithfulness. 1

The operational consequence is simple: treat relevance, authority, freshness, and temporal applicability as separate attributes.

Put validity metadata on every chunk

Do not wait until answer generation to discover a document’s age. Store the metadata needed to make a retrieval decision next to the chunk at index time.

{
"chunk_id": "policy-claims-v5:p12:c03",
"document_id": "policy-claims-v5",
"source_uri": "https://intranet.example/policies/claims/v5",
"title": "Business Expense Claims Policy",
"document_type": "policy",
"authority_tier": 1,
"published_at": "2026-01-15T09:00:00Z",
"last_modified_at": "2026-03-04T11:30:00Z",
"valid_from": "2026-03-15T00:00:00Z",
"valid_until": null,
"supersedes": "policy-claims-v4",
"content_hash": "sha256:...",
"embedding_model": "embed-v4",
"pipeline_version": "ingest-2026-03-04.2",
"access_scope": ["employees"],
"freshness_class": "operational-policy",
"source_verified_at": "2026-03-05T08:00:00Z"
}

The distinction between published_at, last_modified_at, valid_from, and source_verified_at is intentional. A document can be edited before it becomes effective. It can be current but not recently verified. It can be historically correct but not applicable to today’s question.

The index should also know which document supersedes which. Deleting the old vector is not always correct: historical questions may require it. Instead, preserve historical versions and filter or rank them according to the query’s temporal intent.

Classify the query before ranking documents

A freshness policy cannot be one global “newer is better” multiplier. A historical question needs an as-of filter. A research query may want both the latest finding and earlier evidence. A timeless explanation may prefer authority and clarity over publication date.

Classify the query into an explicit temporal mode:

temporal_modes:
current:
require_effective_now: true
max_age_days_by_class:
operational-policy: 90
api-reference: 30
architecture: 730
as_of:
require_valid_at_query_date: true
allow_future_versions: false
latest:
prefer_latest_verified: true
preserve_authority_floor: true
historical:
rank_by_relevance: true
do_not_discard_superseded_versions: true
timeless:
freshness_weight: 0.0
authority_weight: 1.0

The classifier can be rules-first. Look for explicit dates, phrases such as “currently,” “latest,” “at the time,” or “what was the policy in 2024,” and the type of task. If temporal intent is ambiguous and the domain is high-risk, ask a clarification question or answer with an explicit uncertainty boundary.

For an as_of query, retrieval should first filter documents whose validity interval contains the requested date. For a current query, it should exclude superseded versions unless the user asks for history. This is more reliable than retrieving top-k semantic candidates and hoping a reranker notices the date.

Freshness must enter candidate selection

A common design is to retrieve the top 20 vectors and then add a recency bonus. That can fail before the recency calculation starts. The newest relevant item may not be in the semantic top 20.

A 2026 temporal retrieval study found exactly this behavior on vulnerability data: the newest relevant document was often outside the strongest cosine matches. A fused semantic-plus-temporal score improved the chance of surfacing current evidence, but the result was a tunable trade-off between freshness and relevance. The paper’s practical conclusion is important: freshness must influence candidate selection, not only the final reranking stage. 2

A production scorer can make the trade-off visible:

from datetime import datetime, timezone


def temporal_score(*, semantic, published_at, now, half_life_days,
authority, validity, freshness_weight=0.25):
age_days = max(0.0, (now - published_at).total_seconds() / 86400)
recency = 0.5 ** (age_days / half_life_days)
return (
0.60 * semantic
+ 0.15 * authority
+ 0.15 * validity
+ freshness_weight * recency
)


def eligible(doc, *, query_time, mode):
if mode == "as_of":
return doc.valid_from <= query_time and (
doc.valid_until is None or query_time < doc.valid_until
)
if mode == "current":
return doc.valid_from <= query_time and doc.valid_until is None
return True

The weights and half-life are not universal defaults. An API reference may decay in weeks. An organizational principle may remain useful for years. Tune by document class and validate on representative queries. A large recency bonus can promote a recent but low-authority blog post above an official, slightly older specification.

Separate source authority from source age

Freshness does not equal truth. A recently edited community page should not automatically outrank an official release note. Store authority as an explicit policy signal:

• Tier 1: source of record, such as an approved policy repository or signed release note.
• Tier 2: maintained internal documentation with an accountable owner.
• Tier 3: expert commentary or community material.
• Tier 4: unverified or transient sources.

Use the tier as a gate in high-risk domains. A current answer about compliance or access control should not be grounded solely in a low-authority source. Conversely, an emerging engineering topic may legitimately use community evidence, provided the answer says what it is and does not present it as policy.

Google’s grounding documentation describes the benefit of connecting model output to verifiable sources: grounding reduces hallucination risk, anchors answers to data, and provides auditability through source links. Its Gemini Search integration returns search steps and inline URL-citation annotations, including the URL and the text span that the citation supports. 3 4

That is a useful contract for internal RAG too. A citation should identify the source, version, effective date, and the claim it supports. A bare document link is not enough when several versions share the same title.

Make citations carry freshness information

A user should not have to open five PDFs to discover that the answer used an old one. Render citation metadata where it affects trust:

type Citation = {
sourceUri: string;
title: string;
documentId: string;
version?: string;
page?: number;
publishedAt?: string;
validFrom?: string;
validUntil?: string;
lastVerifiedAt?: string;
freshnessState: "current" | "stale" | "historical" | "unknown";
supports: string;
};

function citationLabel(c: Citation): string {
const date = c.validFrom ? `effective ${c.validFrom.slice(0, 10)}` : "date unknown";
const status = c.freshnessState === "current" ? "current source" : c.freshnessState;
return `${c.title} (${status}, ${date})`;
}

For a current policy answer, display something like: “Based on Business Expense Claims Policy v5, effective 15 Mar 2026, verified 5 Mar 2026.” If the best evidence is stale, say so before the answer instead of burying a warning after it.

Community builders describe the same operational pattern in practice: attach last_modified and doc_id to every chunk, surface the date in citations, warn for old policy documents, and use different citation rules for policies versus historical references. 5

Detect drift before users report it

Freshness monitoring should cover the full retrieval pipeline, not just ingestion success.

Track the age distribution of retrieved chunks by document class. Alert when an operational-policy query repeatedly retrieves material beyond its allowed shelf life. Compare weekly top-k document IDs for a canonical query set. Large changes may indicate source drift, chunking changes, embedding-model changes, or a broken filter.

Also track embedding and pipeline versions. If a team changes the embedding model or chunking logic and incrementally re-embeds only new files, the index can contain mixed-generation vectors. Tian Pan’s production analysis identifies source-document drift, embedding-model drift, and chunk-boundary drift as separate causes of silent retrieval degradation. It recommends embedding-distance checks, nearest-neighbor stability, freshness distributions, and retrieval-generation agreement. 6

Use blue-green indexing when a pipeline version changes:

# 1. Build a complete new index from the same corpus snapshot.
export INDEX_VERSION="rag-2026-10-16-v2"
python ingest.py --source-snapshot 2026-10-16 --index "$INDEX_VERSION"

# 2. Run retrieval and end-to-end answer evaluations.
python evaluate_retrieval.py --index "$INDEX_VERSION" --queries eval/current.jsonl
python evaluate_answers.py --index "$INDEX_VERSION" --queries eval/grounding.jsonl

# 3. Promote only after freshness, precision, and faithfulness gates pass.
python promote_index.py --candidate "$INDEX_VERSION" --require-gates

Change-data capture is appropriate when only a small part of a source changes, but every incremental write must use the same preprocessing and embedding versions as the active index. If not, rebuild rather than quietly mixing geometries.

Evaluate temporal grounding deterministically

A normal retrieval benchmark can say that a document is relevant while missing that it is the wrong version. Add temporal cases to the evaluation set:

1. Ask for the current state when both current and superseded versions exist.

2. Ask for a historical state when the current document contradicts it.

3. Ask an ambiguous question and check whether the system clarifies or discloses uncertainty.

4. Include conflicting documents with different authority tiers.

5. Include a recent but unofficial source and an older official source.

6. Include a source whose URL works but whose content has changed since indexing.

Score retrieval and generation separately. For retrieval, measure version applicability, authority-floor compliance, freshness-window compliance, citation precision, and newest-relevant recall. For generation, measure whether every material claim has support, whether the answer respects the requested date, and whether stale or conflicting evidence is disclosed.

For high-stakes domains, use deterministic atomic checks where possible. The temporal misgrounding benchmark for French tax law used expert-reviewed questions and scored answer “nuggets” rather than relying on an LLM judge. Its central result was striking: static current-version RAG cited a real source that was inapplicable to the requested date, while a version-aware retriever reached 98.3% mean strict accuracy. 7

A practical rollout order

Start with metadata, not a new vector database. Add document IDs, version IDs, effective intervals, authority tiers, last-verified times, content hashes, and pipeline versions. Then add query temporal classification and hard validity filters for the domains where stale information is dangerous.

Next, make citations explicit and monitor freshness distributions. Add a small canonical query set for every important document class. Only after those controls are observable should you tune temporal ranking or introduce a learned freshness classifier.

The final system should be able to answer four different questions about every response:

• Why was this source relevant?
• Why was this version applicable?
• Why was this source allowed to influence generation?
• When was the source last verified?

If the system cannot answer those questions, it may still be useful for exploration. It is not yet a trustworthy retrieval substrate for an agent that makes decisions or takes actions.

References & Community Insights

Production checklist

1. Every chunk has a source ID, version, effective interval, authority tier, content hash, and last-verified timestamp.
2. Query classification distinguishes current, latest, as-of, historical, and timeless intent.

3. Current and as-of queries use hard validity filters before semantic ranking.

4. Freshness enters candidate selection, not only post-retrieval reranking.

5. Authority and freshness are separate policy signals.

6. Citations expose the version and freshness state used for material claims.

7. Index rebuilds pin embedding and preprocessing versions.

8. Evaluation includes stale, conflicting, superseded, and date-specific questions.
9. Monitoring tracks retrieval age, top-k stability, citation support, and answer faithfulness.
10. The agent discloses uncertainty or stops when no source meets the required freshness and authority floor.

The goal is not to make every retrieved document new. It is to make every retrieved document appropriate: relevant to the question, valid for its time, credible for its domain, and visible enough to audit.