Users forgive minor phrasing issues. They do not forgive stale answers. If your RAG system frequently cites outdated policies or old product guidance, trust collapses. Freshness must be designed into ingestion and operations.
Define freshness SLAs by content domain
Not all content has the same urgency. Treat freshness as an objective per domain:
- High-urgency. Policies, prices, or operational procedures.
- Medium. Product documentation and internal knowledge.
- Low. Historical references and evergreen material.
Make the SLA explicit and measurable (see knowledge base governance).
Prefer incremental ingestion over batch reindexing
Batch jobs hide staleness. Incremental ingestion provides predictable freshness:
- Use change detection (timestamps, checksums, event streams) to identify updated sources.
- Chunk deterministically so small edits do not require full reprocessing.
- Version your ingestion pipeline and metadata rules (see ingestion pipelines and metadata strategy).
Plan for re-embeddings and backfills
Freshness is not only source changes. If you change embedding models, chunking rules or permission models, you may need backfills. Treat backfills as planned operational work, not emergency jobs. Keep an explicit backlog for re-embedding and reindex initiatives.
Deletions must propagate everywhere
Freshness includes removal. Implement deletion workflows so retired content stops being retrieved and cached (see deletion workflows and retention and deletion).
Observe freshness in production
Freshness is observable if you capture the right metadata:
- Source publish/update timestamps.
- Ingestion timestamps and index version.
- Retrieved source age for each answer.
Dashboards that show "answer age" per workflow are often more useful than generic latency charts (see AI observability and RAG evaluation).
A fresh RAG system is not a better embedding model. It is an operational pipeline that keeps knowledge current and measurable.