How to Evaluate a RAG System in 2026 - A Practical Step-by-Step Guide

Retrieval-augmented generation looks simple from the outside. You fetch some documents, stuff them into the prompt, and the model answers. But when a RAG system gives a wrong answer, the interesting question is why - and there are two very different reasons, so you have to test for both.

A RAG pipeline can fail at retrieval or at generation, and the two failures need different metrics. Retrieval failure means your vector search pulled the wrong chunks, or missed the right ones. Generation failure means the model had the right context and still ignored it or made things up. If you only grade the final answer, you cannot tell these apart - and you will spend a week tuning your prompt when the real problem was your chunking. So the whole game is measuring each stage on its own.

Here is the workflow I use, the metrics that actually matter, and where each tool fits.

The metrics that matter

Before any tooling, get the vocabulary straight. RAG evaluation splits cleanly into two buckets.

Retrieval metrics grade the search step:

• Context relevancy - of the chunks you retrieved, how many were actually relevant to the question.
• Context precision - whether the useful chunks ranked near the top, not buried under noise.
• Context recall - whether you retrieved everything needed to answer, or missed a key passage.

Generation metrics grade the answer the model wrote from that context:

• Faithfulness (also called groundedness) - did the answer stick to the retrieved context, or did it invent facts. This is your hallucination detector.
• Answer relevancy - did the response actually address the question, or wander off.

Faithfulness and answer relevancy are reference-free - they only need the question, the context, and the answer, so you can run them without a labelled dataset. Context recall and answer correctness need a golden set. Start with the reference-free pair, add the golden set when you can. For a deeper breakdown of each one, I wrote a full RAG evaluation metrics guide.

Step by step

Here is the concrete process.

1. Capture real traces. Instrument your pipeline so every request logs the question, the retrieved chunks, and the final answer as one connected trace. You cannot evaluate retrieval if you are not recording which chunks came back. This is where an OpenTelemetry-native tracer earns its keep.

2. Build a small evaluation set. Pull 30 to 50 real questions from logs or write representative ones. If you can, label the expected answer and the source chunk. Even a tiny golden set beats eyeballing outputs.

3. Score retrieval first. Run context relevancy and recall against your eval set. If retrieval is broken, fix it before you touch anything else - no prompt tweak saves an answer built on the wrong documents. Bad retrieval usually means chunk size, embedding model, or top-k needs tuning.

4. Score generation. With retrieval solid, run faithfulness and answer relevancy. Low faithfulness with good context means the model is hallucinating despite having the facts - tighten the prompt or lower temperature.

5. Gate it in CI. Once you trust the metrics, run them on every change and block merges that regress. This is what turns a one-off audit into a safety net.

6. Re-run against production traffic. Offline scores drift. Sample live traces weekly and re-score, because real user questions are messier than your eval set.

The tools I reach for

Three tools cover this well, and the pick depends on how you work.

Arize Phoenix is my default for starting fast. It ships 50+ pre-built eval metrics, and reviewers single out its RAG evaluation as the best in the category - you get serious retrieval and answer scoring without writing your own judge prompts. It is built natively on OpenTelemetry, so the trace-capture step in the workflow above is clean, and the OSS build runs locally on a laptop in under a minute. The one caveat is the license - the Phoenix server is Elastic License 2.0, source-available rather than OSI open source, which only matters if you plan to resell it as a hosted service. For internal RAG eval, it is the quickest path to real numbers.

DeepEval fits teams that live in Python and CI. It is the closest thing to pytest for LLM apps - you write test cases, assert on RAG metrics like faithfulness and answer relevancy, and run deepeval test run in your pipeline. The OSS framework is Apache-2.0 and free. Watch the cost, though - nearly all its metrics are LLM-as-judge, so every RAG test case fires another model call, and big suites get slow (minutes, not seconds) and run up API bills. Cost-model the suite before you scale it.

Braintrust is the move if CI quality gates are the point. Its autoevals library gives you working scorers out of the box, and its CI/CD quality gates can block a merge on a statistically significant regression - not just log that RAG quality dropped. Evals, tracing and datasets share one system, so step 5 above is native. The gotcha is billing: it meters “processed data” by the byte with no hard spending cap, and RAG contexts are exactly the verbose payloads that burn the allowance fastest. Set billing alerts on day one.

So where do you start?

• You want the deepest RAG scoring, fastest - Arize Phoenix, running locally, as long as you are not reselling it.
• You want RAG evals inside a Python test suite - DeepEval, with the judge-call cost modelled up front.
• You want RAG evals that block bad merges automatically - Braintrust, with billing alerts on from day one.

Whatever you pick, the principle does not change: measure retrieval and generation separately, or you will fix the wrong half. If you want to compare more options side by side, the best RAG evaluation tools roundup ranks the full field.