How do you keep a RAG index up to date when the source documents change?

Treat the index as a data pipeline, not a one-off load. Detect changes at the source, re-chunk and re-embed only what changed, delete chunks of removed or replaced documents, and track a version for every chunk (source version, chunking version, embedding model). Then monitor freshness like any other pipeline.

1. Detect changes

• Change events: webhooks or change feeds from the source (a CMS, Confluence, a ticket system), or change data capture from a database.
• Scheduled diffs: compare each document's modified time or content hash with what was indexed.
• Pick a frequency that matches how stale an answer may be. A price list may need minutes, a handbook a day.

2. Update incrementally

• Store a content hash per document. If it is unchanged, skip it.
• For a changed document, delete all its old chunks and insert the new ones in one transaction, or behind a version switch. Updating chunks in place leaves orphans when the chunk count changes.
• Re-embed only the new chunks. Embedding is often the slowest and dearest step.

3. Handle deletions properly

A deleted or unpublished document must disappear from the index quickly. Otherwise the system keeps quoting it. Deletions are the most commonly missed case. Run a periodic reconciliation of the ids in the source against the ids in the index.

4. Version everything

Each chunk stores the source document's id and version, the chunker version, and the embedding model and version. When you change the chunking or the embedding model, build a new index alongside the old one, evaluate it, then switch the application over. Vectors from different embedding models cannot be mixed in one index.

5. Prefer current information in answers

• Keep effective_date and updated_at in metadata. Filter or boost by recency where it matters.
• When two versions of a policy exist, retire the old one rather than leaving both to be retrieved.
• Show the source's date next to the answer.

6. Monitor

• Freshness lag: the time from a source change to an indexed change.
• Counts per source, compared with the source system.
• Failed parses and empty documents.
• Retrieval quality on the evaluation set after each large re-index.

OWASP also advises validating and auditing data before it enters a knowledge base. A pipeline is the right place to check for hidden text, malformed files and documents from untrusted sources.

Summary line for an interview: "Hash, diff, delete-and-replace per document, version every chunk, rebuild side by side when the model changes, and alert when the index falls behind the source."