How do you deal with frequently changing data?

Frequently changing data creates a freshness problem in RAG.

If the source changes but the vector index is not updated, the retriever may keep returning stale information.

The solution is to update only what changed and make freshness part of retrieval.

1. Detect changes

Track whether a document or record has changed using fields such as:

• updated_at timestamp
• Version number
• Content hash
• Change event
• Source revision ID

This lets the ingestion pipeline identify new, modified, and deleted content.

2. Re-index incrementally

Do not rebuild the entire knowledge base every time one document changes.

A better flow is:

Source changes → identify affected document → re-parse changed content → regenerate affected chunks → create new embeddings → update the vector index

This is called incremental ingestion or incremental indexing.

3. Remove stale chunks

Updating content is not enough if the old vectors remain searchable.

Suppose a policy changes from:

"Refund period is 30 days."

to:

"Refund period is 45 days."

If both old and new chunks remain in the index, retrieval may return conflicting answers.

So the pipeline must replace or delete stale chunks when a document changes.

4. Store version and freshness metadata

Useful fields include:

• document_version
• updated_at
• effective_from
• effective_to
• status
• is_active

These fields help retrieval prefer current content and exclude outdated versions.

For policy or regulatory data, the effective date may be more important than the ingestion date.

5. Choose the right update frequency

Not all data needs real-time indexing.

Examples:

Employee handbook → nightly or on change

Product catalog → every few minutes

Breaking operational status → near real time

The update strategy should match how quickly stale information becomes harmful.

6. Event-driven vs scheduled updates

Scheduled ingestion periodically checks for changes.

Example:

Every hour → find modified documents → re-index them

Event-driven ingestion reacts immediately to a source event.

Example:

Database row updated → publish event → update corresponding vector record

Event-driven pipelines provide lower freshness lag but are more complex.

7. Consider direct retrieval for highly dynamic data

Some data changes so often that embedding and re-indexing it may not be the best design.

Examples:

• Current inventory
• Live account balance
• Real-time order status
• Current stock price

For these cases, the RAG system may retrieve stable background knowledge from the vector store but call a database, API, or tool for the live value.

Interview takeaway

For frequently changing data, use incremental ingestion instead of rebuilding the entire index. Detect changes, regenerate only affected chunks and embeddings, delete stale vectors, keep version and effective-date metadata, and choose scheduled or event-driven updates based on freshness requirements. For truly real-time data, querying the source directly may be better than embedding every change.