Handling multiple document versions and outdated content in RAG starts with metadata that explicitly tracks version status, such as an effective date, a superseded flag, and a pointer to the current replacement document, captured at ingestion time rather than inferred later from text content. Retrieval queries should filter to active, current-version documents by default, excluding drafts and superseded versions unless the user specifically asks about historical policy or document history, which prevents the common failure of a RAG system confidently citing a policy that a newer version has already replaced. When multiple versions must remain searchable, for example for audit or legal history purposes, tagging each chunk with its version number and validity date range lets the system either default to the current version or explicitly compare versions when asked, rather than blending content from different versions into one confused answer. Source systems like SharePoint and Confluence already track version history, so a well-built connector can propagate that version and superseded status into the RAG index automatically rather than requiring manual tagging. Periodic audits that check whether the most-cited documents in the system are still current help catch version drift before it causes a visible wrong answer. Nanobase AI builds version-aware metadata into ingestion pipelines specifically to prevent stale content from surfacing as current guidance.
The sync mechanism matters as much as the version tag
Tagging chunks with an effective date and a superseded flag only solves half the staleness problem; the other half is how quickly a document's real-world change reaches the index. A metadata field marking a document current is worthless if the underlying source has already been replaced but the re-index has not run yet, and that gap, not the absence of a version field, is where most stale-answer incidents actually originate. Teams that build a careful versioning schema but leave re-indexing on a slow or manual cadence often find their RAG system technically correct in design but wrong in practice for days after a real policy change. The re-indexing cadence determines how long a RAG system stays wrong after a source document actually changes, regardless of how good the version schema is.
Compare re-indexing strategies
| Strategy | How it triggers | Staleness window | Operational complexity |
|---|---|---|---|
| Nightly batch re-index | Scheduled job scans source systems for changes | Up to 24 hours | Low; simple to build and monitor |
| Webhook or event-driven sync | Source system pushes a change event immediately | Seconds to minutes | Moderate; needs reliable event handling and retries |
| Change-data-capture (CDC) polling | Frequent polling for changed records via API | Minutes | Moderate; API rate limits constrain frequency |
| Manual trigger | An admin re-runs ingestion after known changes | Unbounded, depends on human action | Lowest to build, highest risk of drift |
Key takeaway: nightly batch re-indexing is adequate for most policy and reference documents, but anything time-sensitive, such as active incident guidance, needs event-driven sync.
Building the version-aware retrieval path
- Capture effective date, superseded status and a pointer to the replacement document as explicit metadata fields at ingestion, sourced from the system of record's own version history where available, such as SharePoint or Confluence version metadata, rather than inferred from document text.
- Default every retrieval query to filter for active, current-version content only, excluding drafts and superseded versions unless the user's query explicitly asks about history or a specific past version.
- When a source document is replaced, mark the prior version's chunks as superseded rather than deleting them outright, preserving them for audit or historical queries while removing them from default retrieval.
- Re-embed and re-index only the changed sections where the source system supports section-level change tracking, rather than re-processing an entire large document for a one-paragraph edit, to keep re-indexing fast enough to run frequently.
- Run a periodic audit, ideally monthly, that checks whether the most-cited documents in query logs are still marked current in their source system, catching version drift that the automated sync missed.
Key takeaway: version-aware retrieval needs both metadata at ingestion and an ongoing audit, since sync pipelines occasionally miss a change the schema alone cannot catch.
Handling documents that change meaning rather than just wording
Some updates are substantive, such as a policy threshold changing from ten to fifteen days, and users who ask "did anything change" need the system to actually detect and surface that shift, not just serve the latest version silently. Storing a lightweight diff or change summary alongside each new version, either generated by the ingestion pipeline or pulled from the source system's own changelog, lets the system answer "what changed since last quarter" as a genuine capability rather than requiring a user to manually compare two full documents. This is a meaningfully different problem from ordinary metadata filtering, since it requires reasoning about the relationship between two versions rather than filtering to just one.
Key takeaway: surfacing what changed between versions is a distinct capability from serving only the latest version, and needs its own design if users ask about changes directly.
Frequently asked questions
Should old document versions be deleted from the index entirely?
Generally no, unless there is a specific data retention requirement to do so. Marking them superseded and excluding them from default retrieval preserves audit and historical query capability without risking that outdated content surfaces as current guidance, which deletion would prevent but at the cost of losing legitimate historical access.
How do we handle a document with no clear version history, like an emailed PDF?
Assign an ingestion timestamp as a fallback effective date and flag the document for manual review to confirm its currency, since a document without a source system's version metadata cannot be trusted to auto-update reliably and needs a human-in-the-loop step at least once.
Can users ask the system about a past policy version on purpose?
Yes, this should be supported as an explicit query mode rather than blocked, since compliance and legal use cases genuinely need historical answers. The default retrieval path should exclude superseded content, but a query that names a date or explicitly asks about history should widen the filter to include it.
What is a reasonable staleness audit frequency?
Monthly is a reasonable default for most enterprise knowledge bases, tightened to weekly for fast-changing domains like pricing or active incident response, and loosened to quarterly for stable reference material like historical contracts that rarely change.
How Nanobase AI helps
Nanobase AI builds version-aware metadata and event-driven re-indexing into ingestion pipelines from the start, matching the sync cadence to how fast each document type actually changes rather than applying one schedule to an entire corpus. This is part of the broader on-premise and hybrid RAG deployments we operate for clients who need their knowledge base to stay current without manual intervention. See our solutions for the full pipeline.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.