How to evaluate a RAG application in production

Disclosure: Galtea publishes this guide. It is an educational framework for evaluating RAG systems, with product references linked to Galtea’s public documentation.

Last reviewed: October 2026

Production RAG evaluation means measuring both parts of the system that can fail: whether retrieval found the evidence needed to answer a question, and whether generation used that evidence accurately and appropriately. Start with the outcome a user experiences, then add separate retrieval and generation metrics to locate the cause of a failure. Continue the loop after release by evaluating traces from real interactions, reviewing difficult cases, and turning confirmed failures into regression tests.

A RAG application can return a fluent answer while the system behind it is already degrading. A knowledge-base update can create retrieval gaps. A change to chunking or embeddings can rank useful passages lower. A prompt change can cause the model to add unsupported claims even when the right context is present. An evaluation program should make those failure modes visible and tell the team what to change next.

Evaluate the answer before optimizing the pipeline

The first question is not whether the retriever has a good score. It is whether the final answer correctly addresses the user’s request.

For each test case, preserve:

• the user’s question;
• the retrieved documents or passages, in ranked order;
• the generated answer;
• citations or source references returned to the user;
• a trusted expected answer when one exists;
• the model, prompt, retrieval, and application version;
• the metric results and any human verdict.

This record lets the team separate an incomplete answer from an irrelevant one, and a retrieval miss from a generation error. It also gives reviewers the evidence behind a score. A single end-to-end number cannot do that.

For a RAG assistant, a useful first evaluation asks:

1. Did the answer address the question?
2. Is each material claim supported by the retrieved context?
3. Does it contain the information the user needed?
4. Did it follow the product’s safety, policy, and scope requirements?

Then use component metrics to explain why the answer failed.

Retrieval and generation are different failure surfaces

Retrieval evaluation checks the evidence supplied to the model. Generation evaluation checks what the model did with that evidence.

If the required fact never appears in the retrieved context, changing the generation prompt will not recover it reliably. Investigate document coverage, query construction, chunking, embeddings, filters, ranking, and the retrieval limit.

If the right evidence is present but the answer contradicts it or adds unsupported claims, retrieval is not the first place to look. Investigate the generation prompt, model, context formatting, citation instructions, and fallback behavior.

The same user-visible failure can therefore require opposite fixes. That is why retrieval and generation should have separate metrics and separate release gates.

The metrics that localize RAG failures

Use the smallest set of metrics that answers the questions your product must answer. The table below is a practical starting point. Thresholds are examples of decisions to calibrate, not universal numbers.

Galtea’s documentation defines contextual recall as coverage of the information needed for the expected output and contextual precision as the ranking of relevant context above irrelevant context. Its faithfulness metric checks the generated response against the retrieved context, while answer relevancy checks the response against the original input. Those dimensions should remain separate in the evaluation report.

Read metric combinations as diagnoses

A metric is useful when it changes the next engineering decision. Read the results in combinations rather than treating each score as an isolated grade.

Low recall and low faithfulness point to missing evidence

When the retriever misses information, the generator has little to work with. The answer may be incomplete, or it may fill the gap with a plausible claim. Review the retrieved passages first. If the needed evidence is absent, improve retrieval before tuning the answer prompt.

Good recall and low faithfulness point to a generation problem

If the right passages are present but the answer contradicts them or adds unsupported claims, the system is failing to use available evidence. Inspect the prompt, context order, model configuration, and whether the application asks the model to answer beyond the source.

Good faithfulness and low answer relevance point to an intent problem

An answer can accurately summarize a retrieved passage and still fail the user. This often indicates query interpretation, conversation-state, or response-format problems. Do not raise retrieval scores to fix an answer that is grounded but off topic.

Good retrieval metrics and poor citation quality point to an evidence handoff problem

The source may be present in the context, but the user-facing answer may cite the wrong document, cite a whole document when a precise passage is needed, or omit citations for material claims. Test citation selection and claim-to-source mapping separately from faithfulness.

Good quality scores and policy failures point to a control problem

An answer can be relevant and grounded while still violating a product boundary. Keep policy checks independent. A refusal rule, privacy rule, disclosure requirement, or tool-use restriction should not disappear inside a general quality score.

Build a dataset that reflects production risk

No single dataset is enough for a production RAG application. Combine three sources of test cases:

1. Reviewed cases: start with questions that represent common traffic, high-risk workflows, known edge cases, and every confirmed production failure. These form the regression backbone.
2. Synthetic cases: generate questions and scenarios from the actual knowledge base or product specifications to expand coverage. Review a sample before using a synthetic batch as a quality reference.
3. Production traces: sample real interactions, remove or protect sensitive data, and add confirmed failures to the permanent test set. These cases keep the evaluation connected to how people actually use the system.

Include cases for:

• direct questions with one authoritative answer;
• questions that require information from several documents;
• incomplete or conflicting source material;
• empty retrieval results;
• outdated or duplicated documents;
• ambiguous questions and requests outside the system’s scope;
• citation and source-display behavior;
• prompt injection attempts embedded in retrieved content;
• multilingual, long-context, and multi-turn interactions where relevant.

Keep a held-out set for calibration. If the same examples are used to write a judge prompt and to prove that the judge works, the reported agreement will be too optimistic.

Calibrate automated judges with human review

LLM-as-a-judge can score open-ended RAG behavior at scale, but its verdict is not ground truth. A judge can reward long answers, miss subtle contradictions, or apply a vague rubric inconsistently.

Calibrate the judge against a representative sample labeled by people who understand the product and its domain. Compare false passes and false failures, not only the overall agreement rate. Review the disagreement reasons and tighten the rubric when the evaluator is unclear about:

• what counts as a material claim;
• which source is authoritative;
• whether a paraphrase is supported;
• how missing evidence differs from a contradiction;
• how to score uncertainty, refusal, and partial answers.

For high-stakes use cases, route flagged cases and a regular sample to qualified reviewers. Human review is also the right path for requirements that depend on domain judgment, nuanced policy interpretation, or an outcome the automated evaluator cannot establish from the trace.

Galtea documents a human evaluation workflow for routing outputs to reviewers when domain expertise or a human quality gate is needed. The exact reviewer roles and approval process should match the organization’s own quality policy.

Put retrieval and generation gates in CI

Run the same evaluation suite when a team changes:

• the model or model version;
• the system or retrieval prompt;
• chunking or document parsing;
• embeddings, reranking, filters, or top-k;
• the knowledge base or index;
• citation formatting;
• policy or refusal behavior.

Gate retrieval and generation independently. An end-to-end score can hide a retrieval regression if the model happens to compensate on the current test set. Conversely, a retrieval improvement can be wasted if generation quality declines.

A practical pull-request gate has three layers:

1. Fast deterministic checks: validate schemas, required fields, citation presence, source identifiers, and policy-critical exact conditions.
2. Metric regression checks: compare retrieval, faithfulness, answer relevance, citation, and policy results with the current baseline.
3. Case-level review: block a release when a non-negotiable case fails, even if the average score remains stable.

Record the version, dataset revision, metric revision, threshold, and commit with every run. A passing score without its configuration is difficult to reproduce and weak evidence for a release decision.

Galtea’s GitHub Actions documentation describes running evaluations against a version and its linked specifications, datasets, and metrics. The existing RAG assistant page also describes re-running test suites across prompt, model, and pipeline changes. Whether a failed check blocks deployment remains a decision for the team’s CI configuration.

Monitor the same dimensions after release

Offline tests answer whether the system regressed on known cases. Production monitoring answers what is happening on inputs the team did not anticipate.

Keep enough trace data to inspect a failure:

• the question and conversation identifier;
• the retrieved passages and their ranking;
• the answer and citations;
• the model, prompt, retrieval, and product version;
• metric results, confidence or reason where available;
• reviewer decisions and user feedback.

Track trends by query type, document source, product version, language, and risk tier. An aggregate score can stay flat while one important segment deteriorates. Alert on changes against a baseline, not only on a fixed score copied from another application.

When an alert fires, follow the trace:

1. Confirm which segment changed.
2. Inspect the retrieved context.
3. Check whether the answer’s claims are supported.
4. Check whether the answer addressed the question and followed policy.
5. Classify the failure as retrieval, generation, citation, policy, or data quality.
6. Fix the responsible layer and add the confirmed failure to the regression set.

Galtea’s production monitoring documentation describes logging real user interactions, attaching retrieval context, evaluating sessions, and using Monitors to score closed production sessions automatically. Sampling, session lifecycle, and retention should be configured for the deployment’s data and operational requirements. The workflow does not imply that every production interaction is evaluated.

Do not use one threshold for every RAG application

There is no universal faithfulness, recall, or citation threshold. Scores depend on the metric implementation, judge model, rubric, dataset, query mix, and the cost of a missed failure.

Set thresholds by:

• labeling representative examples with domain reviewers;
• identifying which failures are unacceptable;
• measuring false passes and false failures;
• segmenting by use case and risk;
• comparing the current result with a versioned baseline;
• reviewing trend changes after releases and knowledge-base updates.

A high-stakes workflow may block on one policy violation even when its average quality score is strong. A lower-risk assistant may tolerate a small regression while the team investigates a broader retrieval change. The threshold is a product decision supported by evaluation evidence, not a number to copy from a blog post.

Frequently asked questions

How do I evaluate retrieval and generation separately in a RAG pipeline?

Score the retrieved passages with recall, precision, and relevance measures. Score the generated answer with faithfulness against the retrieved context and answer relevance against the user’s question. The combination tells you whether to investigate the index and ranking layer or the prompt and model layer.

How do I detect hallucinations in a production RAG application?

Preserve the retrieved context and evaluate the answer’s material claims against it. A claim-level faithfulness check can identify unsupported or contradictory claims without requiring a separate reference answer. Pair it with retrieval recall, because missing evidence can cause the generator to fill a gap with a plausible answer.

What should I do when RAG quality degrades after a knowledge-base update?

Compare the affected production traces with the previous version. Check retrieval recall and precision by document source and query type, then inspect whether chunking, metadata, freshness, or ranking changed. Add confirmed failures to the regression dataset before changing the index again.

What is the difference between faithfulness and answer relevance?

Faithfulness asks whether the answer is supported by the retrieved context. Answer relevance asks whether it addresses the user’s question. An answer can be faithful but irrelevant, or relevant but unsupported, so the two metrics should not be merged.

What threshold should I use for faithfulness in production?

Use a threshold calibrated against reviewed examples from your application. There is no safe universal value. Make the gate stricter when an unsupported claim could create material harm, and track regression against the calibrated baseline rather than relying on a single score.

Can an evaluator block a hallucinated answer before it reaches the user?

An evaluator that runs after generation is a detection and monitoring mechanism. If the application must block or transform an answer synchronously, implement that control in the request path and evaluate the control separately. Do not treat an asynchronous score as a real-time guardrail.

How does Galtea support production RAG evaluation?

Galtea’s RAG assistant workflow covers retrieval, groundedness, completeness, and citation accuracy before release, then monitoring of real interactions after deployment. Its public documentation also covers RAG metrics, versioned evaluations, human review, CI workflows, and production monitors.

If you are evaluating a RAG assistant for production, start by separating retrieval from generation, preserve the evidence behind each answer, and choose thresholds from reviewed cases rather than borrowed benchmarks. Explore Galtea’s RAG evaluation workflow.