Your RAG index is quietly going stale, orphaned, and leaking data.

A vector goes stale the moment its source document changes and the embedding doesn't. A policy gets revised, a price changes, a support article gets rewritten — but the old embedding is still sitting in your RAG index, still being retrieved, still being handed to the model as ground truth. RAGproof compares every vector's embedding timestamp against its source document's last-modified date and flags exactly which ones have drifted.

Stale means the source document still exists but has changed since it was embedded. Orphaned means the source record is gone entirely — deleted, moved, or renamed — and the embedding is left behind with nothing to reconcile against. Both produce confidently wrong answers in retrieval; they just fail for different reasons, which is why RAGproof reports them as separate categories rather than one vague "drift" score.

Every re-run of an ingestion pipeline that doesn't dedupe against what's already indexed adds another near-identical copy of the same chunk. Once you have a few thousand of these duplicate clusters, they crowd your top-k results with redundant near-duplicates instead of genuinely relevant context, quietly degrading answer quality without throwing a single error. RAGproof groups duplicate clusters so you can collapse them with confidence instead of guessing.

Yes. If a document is deleted from your system of record under a GDPR Article 17 erasure request, but its embedding still surfaces in retrieval, that content hasn't actually been erased — it's leaking out through every query that touches the index. We cover a real 13-month case, including how a single deleted document kept resurfacing in production, in our RAG index decay teardown.

pgvector, Qdrant, Weaviate, Chroma, and Pinecone today, connected with read-only credentials scoped to a single index so we can never write, delete, or modify anything. If you're running something else, mention it on the discovery call — most audits generalize once we can query the index and its metadata, regardless of which vector database is underneath.

No. The scan itself is self-hosted and runs inside your environment end to end; RAGproof never exports raw vectors, embeddings, or source content anywhere. Only the finished report — freshness map, orphan list, duplicate clusters, and the erasure/leak check — leaves your infrastructure. Full details on what we do and don't collect are in our privacy policy.