RAG Evaluation: Metrics, Golden Datasets & Regression Tests

A RAG system can look convincing in a demo and still be unreliable in daily operation. RAG evaluation therefore means making retrieval, answer quality and business outcomes measurable with reproducible test cases instead of judging responses by feel.

The core rule is simple: before changing the model, identify which layer is failing. Did search retrieve the wrong documents, was the right chunk missing, did the LLM misuse the context, or did the overall workflow fail?

For the full pipeline, see Build a RAG system the right way. If a PoC already exists and the question is “is this reliable enough for production?”, the direct next step is AI Production Readiness.

RAG evaluation in one sentence

A robust RAG evaluation answers three separate questions:

1. Retrieval: Did the system find the right evidence?
2. Generation: Did it produce a correct, grounded answer from that evidence?
3. Task: Did it complete the real business task reliably?

Evaluating only the final answer mixes these failure classes. You then cannot tell whether embeddings, hybrid search, chunking, reranking, prompting or the LLM needs to change.

The RAG evaluation framework

| Layer | Core question | Typical measures | | --- | --- | --- | | Retrieval | Is relevant evidence found and ranked early enough? | Recall@k, Precision@k, MRR, nDCG | | Context | Is the supplied context relevant, complete and authorised? | Context relevance, coverage, permission correctness | | Generation | Is the answer correct and supported by sources? | Groundedness, correctness, relevance, citation accuracy | | Task | Does the answer solve the real task? | Task success, escalation rate, human acceptance | | Operations | Does quality remain stable under change? | Regression rate, latency, cost, failure classes |

NVIDIA's RAG Blueprint documentation uses dimensions such as Answer Accuracy, Context Relevancy and Response Groundedness. It is a useful example of why retrieved context and generated output should be assessed separately. Source: NVIDIA RAG Blueprint – Evaluate.

1. Measure retrieval first

An LLM cannot reliably answer from evidence that was never retrieved.

Recall@k

Recall@k asks: does the relevant information appear in the top-k results?

This matters when a system produces plausible but incomplete answers. Low recall points toward query processing, indexing, chunking, embeddings, filtering or retrieval strategy rather than the generation model.

Precision@k

Precision@k asks: how much of the retrieved evidence is actually relevant?

More context is not automatically better. Irrelevant chunks can displace useful evidence, increase cost and dilute generation.

MRR and nDCG

MRR is useful when the first truly relevant result should appear as high as possible. nDCG is useful when relevance is graded and several useful results need to be ordered well.

The goal is not to collect every information-retrieval metric. The goal is to choose metrics that reflect the task.

2. Evaluate generation separately

Good retrieval does not guarantee a good answer.

Groundedness

Is the answer supported by the supplied context?

A response can be factually correct yet unsupported by the authorised source set. In enterprise RAG, that is different from a correctly grounded answer.

Correctness

Is the answer factually right?

Correctness can be checked against reference answers, rules, structured expected values or human judgement. Many knowledge tasks do not have a single valid wording.

Answer relevance

Does the answer actually address the question, or is it merely correct in a related area?

Citation accuracy

Does each citation point to evidence that genuinely supports the associated claim?

A citation is not automatically correct because the document is topically similar.

3. Build a golden dataset instead of demo prompts

The most valuable asset for continuous RAG quality is not a dashboard. It is a versioned golden dataset.

A useful test case contains at least:

• a realistic user question or task,
• the user role and relevant permissions,
• the expected source or document group,
• expected key facts or scoring criteria,
• known difficult terms, IDs or exceptions,
• expected behaviour when no reliable answer is available.

Sensitive systems also need negative cases: questions whose answers a specific user must not see. That connects evaluation directly to RAG permissions and security trimming.

The golden dataset must represent reality

A test set made only of easy FAQ questions creates false confidence.

Include cases such as:

• ambiguous or abbreviated questions,
• domain terminology and synonyms,
• product numbers, IDs and exact codes,
• conflicting document versions,
• stale content,
• tables and structured data,
• questions requiring multiple sources,
• “no reliable answer” cases,
• role and tenant boundaries.

A 2026 paper on enterprise RAG makes the same broader point: generic single-turn metrics can miss operational failure modes in realistic multi-step enterprise workflows. Source: Case-Aware LLM-as-a-Judge Evaluation for Enterprise-Scale RAG Systems.

4. Use LLM-as-a-judge deliberately

LLM graders are useful when semantic quality matters and exact string matching is too rigid.

They are not a substitute for ground truth.

A stronger setup combines:

• deterministic checks for IDs, numbers, formats and rules,
• retrieval metrics for evidence discovery,
• LLM graders for semantic dimensions,
• human review for critical or ambiguous cases.

Version the grader prompt, grader model and scoring rubric. Otherwise the measurement method changes at the same time as the system under test.

5. Diagnose failure classes instead of chasing one score

A single “RAG score” is often too coarse for debugging.

Use a failure taxonomy instead:

| Symptom | Likely layer | Next test | | --- | --- | --- | | expected source missing | Retrieval | Recall@k, query, filters, index | | source found, passage missing | Chunking / parsing | inspect chunk boundaries and structure | | relevant passage ranks too low | Ranking | MRR/nDCG, hybrid search, reranking | | context correct, answer wrong | Generation | prompt, model, groundedness | | answer correct, citation wrong | Attribution | citation mapping | | user sees restricted evidence | Authorisation | permission-aware evaluation | | quality changes after update | Regression | rerun baseline suite |

This avoids treating every failure as a model or prompt problem.

6. Turn the golden dataset into regression tests

Once the golden dataset exists, it becomes your regression suite.

Rerun it when changing:

• embedding model,
• chunking,
• query rewriting,
• keyword/vector weighting,
• hybrid search,
• reranker,
• prompt,
• LLM,
• context size,
• source connector,
• permission logic.

The question changes from “does the new version feel better?” to: which failure classes improved, which regressed, and at what cost?

7. RAG evaluation and hybrid search belong together

There is no universal answer to whether vector search, keyword search or hybrid search is best.

Vector search is strong for semantic similarity. Exact IDs, product codes, names and rare domain terms often benefit from lexical matching. Hybrid approaches combine both signals and still need to be validated against the actual evaluation set.

See the technical decision guide: Hybrid Search vs Vector Search for RAG.

8. RAG evaluation and chunking belong together

If the relevant passage does not exist as a useful retrieval unit, the retriever cannot surface it cleanly.

Chunking should therefore be evaluated against the same real questions rather than tuned by generic rules of thumb. The best strategy depends on document structure, query type and the evidence unit users need.

See RAG chunking strategies for enterprise data.

RAG evaluation go-live checklist

Before production, you should be able to answer:

• Is there a versioned test set with realistic cases?
• Can retrieval and generation failures be diagnosed separately?
• Does the set include permission and negative cases?
• Are critical facts and citations verifiable?
• Are “no answer” cases tested explicitly?
• Is there a baseline before model, prompt or index changes?
• Are latency and cost reviewed together with quality?
• Are there explicit go/no-go criteria instead of demo feedback?

If these questions are unanswered, the system is not yet robustly evaluated.

Next step

If an existing RAG system produces plausible answers but quality, permissions or regressions cannot be measured reliably, another prompt-tuning cycle is usually not the right next move.

I help teams evaluate existing RAG and LLM systems using realistic test sets, failure analysis and explicit go-live criteria: AI system evaluation and production readiness.

For a new build or technical integration into existing systems, see RAG implementation & AI integration.