How do you handle document updates and versions in a RAG knowledge base?

Document updates and versions in a RAG knowledge base should be handled so the system can recognize what changed, keep the active index current, and avoid retrieving stale and current versions at the same time.

Versioning is important because simply adding every updated document as new content can leave old chunks in the index and create conflicting answers.

1. Give each logical document a stable ID

A document should have an identity that remains the same across updates.

Examples include:

• Document ID
• Canonical URL
• Repository path
• Database record ID
• Storage object key

The version can change while the logical document identity stays constant.

2. Track version information

Useful version metadata may include:

• Version number
• Last-modified time
• Effective date
• Source revision ID
• Content hash
• Ingestion time

This makes it possible to compare the incoming document with the currently indexed version.

3. Detect whether the document actually changed

Before reprocessing, compare the new source with the indexed version.

A content hash can quickly identify exact matches. If the content has not changed, unnecessary parsing, embedding, and indexing can be skipped.

4. Reprocess changed content

If the document changed, parse and prepare the new version using the normal ingestion pipeline.

For large documents, systems may optionally identify changed sections or chunks and re-index only those parts instead of rebuilding everything.

Incremental updates can reduce processing cost, but they require reliable chunk identities and change tracking.

5. Remove or deactivate stale chunks

When the new version becomes active, chunks belonging to the previous version should normally be:

• Deleted
• Marked inactive
• Superseded
• Moved to version history

The important point is that outdated chunks should not continue competing with current chunks during normal retrieval.

6. Keep historical versions when the use case requires them

Some systems need to answer questions about past policies, contracts, specifications, or regulations.

In that case, older versions can be retained with metadata such as:

• Valid-from date
• Valid-until date
• Version status
• Superseded-by version

Retrieval can then filter by the appropriate version or effective date.

7. Update related metadata

A document update may change more than its text.

Also review:

• Permissions
• Title
• Source URL
• Section hierarchy
• Tags
• Effective dates

Stale metadata can cause incorrect filtering even when the text itself is current.

8. Make updates atomic when possible

A production system should avoid a period where some chunks come from the old version and others from the new one.

One approach is:

Build new version
      ↓
Validate it
      ↓
Activate new version
      ↓
Deactivate old version

This reduces inconsistent retrieval during updates.

9. Validate after re-indexing

After an update, verify that:

• New content can be retrieved
• Removed content is no longer returned
• Old and new versions are not mixed unintentionally
• Citations point to the correct version
• Permissions still work correctly

For duplicate detection during ingestion, see “How do you handle duplicate documents during RAG ingestion?”.

In short, handle RAG document updates with stable document identities, explicit version metadata, change detection, controlled re-indexing, and clear activation or retirement of old chunks so retrieval uses the correct version of the knowledge.