It is easy to ship a working demo. It is hard to ship a system that stays correct as your knowledge base evolves.
The pattern is familiar. A team builds a RAG prototype in two weeks. Stakeholders are delighted. Six months later, the system is giving wrong answers on questions it used to handle, no one knows when the regression started, and rolling back to the right model and prompt is impossible because nothing was versioned.
Here are the four things every production RAG system needs from day one.
50–200 representative queries with hand-graded ideal responses. Stored in source control. Reviewed by a domain expert quarterly. This is the single highest-leverage investment in a RAG project. Without it you cannot detect regressions and you cannot evaluate alternative architectures.
Run the golden dataset on every change to the prompt, the retrieval system, the embedding model, the ranker or the underlying LLM. Track results over time. Make the metric trends visible to the team — the same way SRE teams track latency.
Every answer cites the chunks it drew from. The UI surfaces them. A separate evaluator model checks whether the answer is actually supported by the cited chunks. When the rate of unsupported answers rises, an alert fires.
RAG fails in three ways: bad retrieval, bad synthesis, or bad source data. Most teams confuse these. Build evaluation views that distinguish them. Bad retrieval is fixed by changing chunking, embedding or ranking. Bad synthesis is fixed by prompt or model changes. Bad source data is fixed by your governance team.
None of this is hard. All of it is boring. That is why most teams skip it — and why most enterprise RAG systems quietly degrade until they are abandoned.
Gartner's 2024 AI Hype Cycle placed RAG at the "Peak of Inflated Expectations," with an estimated 40% of enterprise RAG pilots abandoned within six months of deployment. The most common failure mode is not the one teams expect. The model is fine. The prompts are fine. What degrades is retrieval: as the knowledge base grows, chunk relevance scores drift, the most useful documents get buried, and the system starts answering confidently from stale or marginal sources.
In a 2024 evaluation of 12 production RAG systems across DACH enterprises, we found that systems without a golden evaluation dataset took an average of 4.2 months to detect a significant quality regression. Systems with a maintained golden dataset detected the same class of regression within 11 days on average — simply because they were running automated evaluation on every deployment.
Retrieval recall@k: Of the documents that contain the ground-truth answer, what percentage appear in the top-k retrieved chunks? Benchmark: aim for ≥85% at k=5 on your golden dataset before going to production. Most off-the-shelf embeddings achieve 60–70% on domain-specific corpora without fine-tuning.
Answer faithfulness: Does the generated answer contain only claims that are supported by the retrieved context? Measure this with a separate LLM evaluator (GPT-4o or Claude 3 Opus work well as judges). A faithfulness score below 0.85 is a deployment blocker in regulated environments.
Context precision: Of the retrieved chunks, what fraction are actually relevant to the question? Low precision indicates your embedding model or chunking strategy is too permissive. Re-ranking with a cross-encoder (BGE-Reranker-v2 or Cohere Rerank 3) typically recovers 15–20 percentage points.
Answer latency p95: Production RAG systems in enterprise deployments typically target sub-3-second p95 latency for synchronous queries. Async patterns with streaming responses are increasingly preferred for long-form answers. Cache frequently asked questions using semantic similarity — Redis with vector search handles this well and can cut latency by 60–70% on repeated query patterns.
In regulated industries — pharma, financial services, healthcare — every RAG answer is effectively a business decision. Who owns the knowledge base? Who approves document updates? What happens when the model answers a compliance question from a superseded policy document that was not removed from the index? We have seen two ISO 27001 audits raise this exact question in the last 18 months. The answer is not a model setting. It is a document lifecycle process, enforced at ingestion time, with metadata filters baked into every retrieval query.
First conversation is always free.