· AI Engineers Editorial · RAG · 6 min read
RAG Document Freshness: Interview Answer Framework
A structured framework for RAG document freshness interview questions: temporal filtering, document expiry, incremental indexing, and staleness detection, with a comparison table and worked answers.
Why freshness questions separate real operators from theorists
Every RAG tutorial demo works on a static corpus. Production RAG systems don’t — pricing pages change weekly, policy docs get superseded, support articles get corrected mid-incident. Interviewers at companies running RAG over live internal knowledge bases (support, sales, legal, engineering docs) routinely ask a version of “how does your system know a document is stale?” because it’s one of the most common production failure modes, and it’s rarely covered in RAG tutorials. If your answer is “we re-embed everything nightly,” you’ve told the interviewer you haven’t operated this at scale — nightly full re-embedding doesn’t scale past a modest corpus size and doesn’t solve intra-day staleness.
The four mechanisms interviewers expect you to know
| Mechanism | What It Solves | Update Latency | Cost Profile | Key Risk |
|---|---|---|---|---|
| Temporal filtering (metadata-based) | Excludes or deprioritizes documents past a recency threshold at query time | Instant (query-time filter) | Low | Requires accurate, well-maintained timestamp metadata |
| Document expiry (TTL / versioning) | Explicitly marks documents as superseded or expired, removing them from the retrievable index | Depends on write-path trigger | Low-medium | Silent gaps if expiry isn’t tied to the actual source-of-truth update event |
| Incremental indexing | Re-embeds and re-indexes only changed documents, rather than the full corpus | Minutes (event-driven) | Medium (change-detection overhead) | Missed updates if change-detection misses partial edits |
| Staleness detection (active monitoring) | Flags documents whose content likely diverges from ground truth, even without an explicit edit event | Hours to days (batch scan) | Medium-high | False positives on documents that are old but still accurate |
Framework: how to structure your answer
Step 1: Distinguish “old” from “stale”
The single highest-signal move in a freshness question: state upfront that age and staleness are not the same thing. A two-year-old architecture doc can still be accurate; a document updated yesterday can already be wrong if it wasn’t the source of truth. Naive systems filter purely on created_at or last_modified timestamps and end up either excluding still-accurate old documents or including recently-touched-but-still-wrong ones. Your system needs a staleness signal that’s decoupled from raw age.
Step 2: Pick the enforcement layer — index time vs. query time
Temporal filtering is a query-time control: at retrieval, apply a recency-weighted score or a hard cutoff filter (e.g., “exclude documents not touched in 18 months unless no fresher document covers this topic”). This is cheap and instant to change, which makes it the right first lever to reach for. Document expiry is an index-time control: documents get marked expired or superseded at write time (ideally triggered directly by the source system — a CMS publish event, a policy doc versioning system — not by a separate freshness job guessing at staleness). State clearly that query-time filtering is reversible and cheap to tune, while index-time expiry is more reliable but requires integration work with the source system.
Step 3: Explain incremental indexing as the operational backbone
Full corpus re-embedding is the naive answer and interviewers will push back on it immediately if you propose it as your primary mechanism. The correct answer: subscribe to change events from the source system (webhook, CDC stream, or scheduled diff against a content hash) and re-embed only the changed documents. State the concrete mechanism you’d use to detect a “change” — content hash comparison is the standard, cheap approach; comparing raw text is wasteful, and comparing embeddings after the fact defeats the purpose. Name the latency trade-off: event-driven incremental indexing gets new content searchable in minutes; batch-based diffing (nightly cron comparing hashes) is simpler to build but leaves a staleness window of up to 24 hours.
Step 4: Address staleness detection as the safety net
Incremental indexing catches known changes. It does not catch documents that are quietly wrong without ever being formally updated — a support article referencing a deprecated API that nobody flagged. This is where active staleness detection earns its cost: periodically sample indexed documents, check them against an authoritative source (another system of record, or an LLM-as-judge comparing the document’s claims against a more current reference), and flag divergence for human review. Be explicit that this is a probabilistic safety net, not a real-time guarantee, and that it runs on a slower cadence (hours to days) because it’s the most compute-expensive of the four mechanisms.
Common interview traps
“What if the timestamp metadata is missing or wrong?” This happens constantly with documents ingested from legacy systems. State your fallback: when reliable timestamp metadata isn’t available, fall back to content-hash-based versioning (does this document’s content match a known-good snapshot) rather than trusting an unreliable date field, and flag untimestamped documents for a lower confidence score at retrieval rather than silently treating them as current.
“How do you handle conflicting documents — one fresh, one stale, both retrieved?” Don’t let this get resolved implicitly by generation. State that your retrieval layer should apply a recency-boost in the ranking function (not just a binary filter), so that when both an old and a new document surface, the ranker prefers the newer one, and ideally the generation prompt is instructed to explicitly prefer the more recent source when documents conflict, with the conflict itself surfaced to the user if material.
“How would you test this?” Reference a synthetic freshness benchmark: seed the corpus with documents at known ages and known staleness states (accurate-old, stale-old, accurate-new), then measure whether the system’s retrieval and final answers correctly prefer accurate-and-current documents. Most teams never build this test set and instead discover freshness bugs in production, which is exactly the anecdote that separates candidates who’ve operated this system from those who haven’t.
Sample answer to rehearse
For “how would you keep our support-doc RAG system from citing outdated pricing,” a tight answer: distinguish age from staleness upfront; apply a query-time recency filter or ranking boost as the cheap first lever; back it with index-time document expiry tied directly to the pricing system’s publish events, not a guessed TTL; run incremental indexing off change events with content-hash diffing so updates are searchable within minutes; and layer in periodic staleness detection as a safety net for documents that go quietly wrong without a formal edit event. That’s a four-layer answer that maps directly to the four mechanisms in the table, and naming all four in order is what separates a strong answer from a partial one.
Further preparation
Document freshness is one of the most commonly under-prepared RAG topics precisely because most public RAG tutorials never touch a corpus that changes. The 0-to-1 AI Engineer Interview Playbook (Amazon: https://www.amazon.com/dp/B0H2CML9XD?tag=sirjohnnymai-20) covers this freshness framework alongside retrieval, citation, and access-control questions that come up in the same 2026 interview loops, with worked answers structured the same way — mechanism, trade-off, failure mode, concrete test plan.