Keep a RAG index fresh by tracking each source document's identity and revision, mapping its chunks back to that revision, and making updates and deletions visible through the same retrieval path users actually query. Replacing some text in storage is insufficient if old chunks, cached results, or delayed ingestion jobs can still return the previous version.
Freshness is a propagation problem. The source changes first; extraction, chunking, embedding, indexing, query replicas, and caches may observe that change at different times. Define when the new version becomes eligible for retrieval and how the old version stops being eligible.
Track a document, not only its chunks
A chunk record should include a stable source ID, source revision, chunk identity, extraction or chunking version, and an inspectable source location. Access-control metadata also needs a reliable update path. A permission change can matter even when the document's words stay identical.
Suppose policy p has revision 1 with three chunks: a 30-day rule, an exception, and an appendix. Revision 2 replaces it with one shorter seven-day rule. Upserting the new first chunk under the old key can leave the other two chunks searchable. Adding a new key for every version can leave all four searchable.
The owning source must tell the pipeline which revision replaces which. A content hash can identify bytes but does not provide an ordering rule by itself. Use source revision semantics or a controlled sequence; timestamps can collide or arrive out of order.
Choose how a revision becomes visible
One application design is to stage all chunks for a revision, validate their completeness, and switch an active-version manifest only after the new set is ready. Retrieval filters against that manifest. Old chunks can then be removed according to retention requirements.
This design needs an actual atomic visibility mechanism. A dictionary assignment in a prototype does not prove that a distributed search engine can atomically join a manifest with every query. Depending on the engine, a separate index and alias switch, generation filter, transactional store, or a brief controlled unavailability window may be more practical.
If updates happen incrementally, document the period in which readers can receive mixed versions. Decide whether that is acceptable for the information being served. A changelog archive and a current access policy do not have the same freshness tolerance.
Azure AI Search's index-projection documentation describes propagation from parent documents to child chunks, including removal of children when content shrinks. The behavior depends on the source's tracking capabilities and configured deletion policy. Treat it as a concrete implementation contract, not an automatic property of every vector index.
Deletion needs a durable signal
A deleted source can disappear before an incremental scanner learns that it existed. Keep a deletion event or tombstone long enough for every consumer to process it, including consumers delayed by an outage. Avoid storing the deleted sensitive text inside the tombstone; identity and ordering information may be sufficient.
Microsoft's Azure Storage change-and-delete guide distinguishes automatic change detection from deletion detection. It warns that adding a deletion policy later does not clean up previously orphaned documents, and that native blob soft deletion must remain observable until the indexer processes it. The configuration details are service-specific, but the missed-event problem is general.
A delayed update is another hazard. A worker may finish embedding revision 2 after a revision-3 deletion has already arrived. If it can activate its older result, it resurrects deleted content. Compare the update with the newest accepted revision or tombstone before making it visible.
What a local lifecycle fixture verified
A Python fixture modeled chunks, an active-revision manifest, and deletion markers in memory. It staged revision 2 while revision 1 remained active, switched to revision 2, rejected an older activation, deleted the document at revision 3, and rejected a late revision-2 activation.
| Boundary | Assertion checked |
|---|---|
| New revision staged | Retrieval still returned the complete old revision |
| New revision activated | Only the shorter seven-day revision was returned |
| Older update arrived | It could not replace the active revision |
| Deletion applied | Retrieval returned no chunks for the source |
| Late worker completed | It could not reactivate the deleted version |
The five lifecycle cases passed, and final cleanup left zero stored chunks for the source. These results demonstrate the proposed eligibility rules. The fixture has no embeddings, network, query replicas, cache, or concurrent transactions, so it establishes no search-service freshness latency or production atomicity.
Durable agent memory also needs validity and correction rules. A document index adds a one-to-many relationship: every derived chunk and retrieval representation must follow the source's lifecycle.
Measure visibility through the reader's path
A useful operational test records the source-change time, ingestion acknowledgment, index completion, and first verified query result. Query by source ID and version where supported, then use natural-language questions that previously returned the old rule. Test permission revocation and deletion independently of ordinary text updates.
Inspect caches and answer stores as well as the index. A fresh search result does not invalidate an answer cached from yesterday. If historical versions remain accessible, require an explicit historical mode and visible version labeling; do not mix them into current-policy answers by default.
Finally, rehearse rebuilds. A new index built from a stale export can reintroduce documents deleted from the live pipeline. Carry the source snapshot and deletion watermark through the rebuild, then verify query behavior before switching readers.
Choose a freshness objective that states what a user may observe and for how long. “The job runs every five minutes” describes scheduling. “An accepted deletion is absent from authorized retrieval within the defined window, including after recovery” describes behavior you can test.
Documentation and fixture date: October 28, 2026. Cloud documentation was reviewed; no Azure resource or live RAG system was created or modified.
