The problem
Classic RAG pipelines often rank chunks by vector similarity but do not prove whether the source data changed after indexing, caching, or retrieval.
Symptoms
Signals that the issue is happening in production, not just in a benchmark.
Responses cite outdated docs even though a newer page exists.
The vector store still contains deleted or superseded records.
Cache reuse ignores document, tenant, namespace, or policy changes.
Operators cannot separate relevance misses from freshness misses.
How KyroDB solves
KyroDB solves this at the runtime boundary before prompt assembly.
KyroDB adds a freshness contract around RAG retrieval without replacing the vector store.
It tracks omissions such as stale-pruned, scope-filtered, filter-mismatch, and context-budget-exceeded records.
It returns explicit packet status: complete, partial, degraded, or stale-blocked.
Proof and replay workflows show whether a newer runtime path would have prevented the bad answer.
Implementation
Practical steps for teams already using an agent backend, vector store, or RAG pipeline.
- 01
Keep pgvector or Qdrant as the retrieval backend.
- 02
Use KyroDB to enforce the freshness and scope contract around the retrieval call.
- 03
Wire document upserts, deletes, and change events to update source generations.
- 04
Log trace ids alongside model outputs so RAG incidents can be diagnosed later.
When not to use it
If the RAG system only responds over archived, versioned material where staleness is impossible, KyroDB is less critical.
Is RAG freshness a vector database feature?
Vector databases can store and search embeddings, but freshness depends on source ownership, invalidation, scope, and runtime serving behavior across the whole retrieval path.
What is the difference between stale RAG and low relevance?
Low relevance means the retrieved content was not useful for the question. Stale RAG means the content may have matched the question but no longer reflected current truth.