LLM evaluation frameworks expose the limits of RAG testing

At a glance

What this is: Descope compares three LLM evaluation frameworks and shows that DeepEval, RAGAS, and LangSmith solve different parts of the testing problem for RAG systems.

Why it matters: IAM and security teams building AI assistants need evaluation that matches how the system fails, because retrieval, grounding, and traceability are distinct governance concerns.

Context

RAG evaluation is the practice of checking whether an LLM application answers correctly, stays grounded in retrieved context, and behaves consistently across changes. In this article, the core problem is not model output alone but the extra failure surface created when retrieval and generation interact, which makes simple pass or fail thinking insufficient for production use.

For identity and access teams, the lesson extends beyond LLM quality. When AI assistants touch internal documentation, configuration data, or support flows, evaluation becomes part of governance, because bad retrieval, weak grounding, and poor observability can all affect trust, control, and operational risk.

Key questions

Q: How should teams implement RAG evaluation in production systems?

A: Start by measuring retrieval and generation separately, then connect live traces to replayable datasets so every failure becomes a test case. Put quality thresholds into CI/CD, and require prompt or model changes to clear the same regression checks before release. That approach turns evaluation into a control, not a one-off review.

Q: When should teams prioritise trace-based debugging over metric scoring?

A: Prioritise trace-based debugging when a failure could come from multiple steps in the pipeline and the score alone does not explain why. Traces show the documents retrieved, tools called, metadata captured, and output produced, which is essential when the problem is behavioural rather than purely statistical.

Q: What breaks when retrieval quality and answer quality are measured as one thing?

A: Teams lose the ability to tell whether the retriever failed, the generator ignored good context, or the system produced a fluent but unsupported answer. That makes remediation slower and can hide the real control gap, especially in RAG systems where each stage can fail independently.

Q: What is the difference between testing, measurement, and observability in LLM evaluation?

A: Testing checks whether a specific input produces the expected behaviour, measurement scores a system across a dataset, and observability shows how a particular run unfolded step by step. In production, teams usually need all three, but at different stages of the lifecycle and for different decisions.

Technical breakdown

Why RAG evaluation breaks simple pass or fail testing

RAG systems are harder to test than ordinary software because the answer depends on both the model and the retriever. A prompt can be valid, yet the retriever may return incomplete or irrelevant context, or the model may synthesise an answer that sounds plausible but is not grounded in the source material. That means the evaluation target is probabilistic behaviour, not a deterministic function. DeepEval responds to this by treating evaluation like unit testing, while RAGAS separates retrieval quality from answer quality, and LangSmith adds trace-based inspection so teams can see what actually happened across the pipeline.

Practical implication: evaluate retrieval, grounding, and final output as separate controls instead of relying on one score.

How DeepEval, RAGAS, and LangSmith differ in workflow

DeepEval frames evaluation as test cases with pass or fail assertions, which fits CI and regression control. RAGAS is dataset-first and metric-driven, making it useful when teams need to measure faithfulness, context precision, and context recall across many examples. LangSmith puts tracing first, so the central object is the run trace, not the score, and that makes it better for debugging and comparing experiments over time. The article’s key point is that these are not interchangeable labels for the same function. They support different stages of the delivery lifecycle and expose different classes of failure.

Practical implication: choose the workflow that matches whether your team needs gating, measurement, or trace-level debugging.

Why observability matters when evaluating AI assistants

Evaluation becomes more useful when it can explain why an answer failed. LangSmith’s trace-centric model is designed for that use case, linking inputs, outputs, retrieved documents, intermediate calls, and metadata into a single execution path. That matters for RAG and agentic workflows because a single metric rarely reveals whether the problem came from retrieval, prompt selection, tool use, or generation. In governance terms, this shifts evaluation from a static quality check to an evidence trail. Teams can inspect where behaviour diverged rather than treating the final answer as the only signal.

Practical implication: retain traces and metadata so quality issues can be investigated at the point of failure, not guessed after the fact.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RAG evaluation is really control-surface design, not framework shopping. The article shows that answer quality, retrieval quality, and observability are different control surfaces, and each needs a different measurement style. A pass/fail test, a dataset metric, and a trace review do not compete so much as cover different failure modes. Practitioners should stop asking which framework is best and ask which control surface they are actually trying to govern.

The named concept here is the retrieval-grounding gap. That gap appears when a system retrieves context correctly enough to look functional but still produces answers that are weakly supported, incomplete, or misleading. The article’s comparison makes clear that RAG-native metrics are useful precisely because they separate this gap from ordinary answer correctness. Practitioners should treat groundedness as its own governance problem, not as a side effect of accuracy testing.

Evaluation maturity depends on aligning the tool to the delivery stage. DeepEval is suited to regression gates, RAGAS to development-time diagnosis, and LangSmith to operational traceability. That sequence matters because teams often try to force a single framework to do all three jobs and then misread the results. The governance question is not whether evaluation exists, but whether it is usable at the stage where decisions are made.

AI evaluation programmes now need evidence, not just scores. A score without execution context tells you little about why a response failed or whether the issue will recur after a prompt or retriever change. Trace-linked evaluation creates the audit trail that production teams need when AI systems begin to influence support, knowledge access, or internal workflows. The practical conclusion is that observability is becoming part of evaluation governance, not a separate luxury.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Retrieval-grounding gap: LLM teams increasingly need to separate a system that finds context from one that uses it correctly. A trace or score that collapses both problems into one signal hides the control failure and slows remediation.

Production teams should expect evaluation tooling to become part of governance, not just engineering convenience. When AI systems begin touching internal knowledge and support flows, the evidence trail around why an answer was produced matters as much as the answer itself.

For practitioners

• Define separate checks for retrieval, grounding, and answer quality Stop treating one metric as proof that a RAG system is working. Use distinct checks for whether the retriever found relevant context, whether the answer is supported by that context, and whether the final response is correct for the user’s question.
• Use CI gates for regression-prone changes Apply test-style evaluation when prompts, retrievers, models, or orchestration logic change. That makes evaluation behave like a release control instead of a one-off experiment.
• Keep traces attached to evaluation results Store inputs, outputs, retrieved documents, intermediate calls, and metadata so failed runs can be investigated at the execution-path level. Without that evidence, teams are left guessing which stage introduced the error.
• Match the framework to the workflow stage Use dataset metrics when you are diagnosing RAG behaviour, use test cases when you need release gating, and use trace-first tooling when you need ongoing debugging and comparison across runs.

Key takeaways

• RAG evaluation is difficult because retrieval and generation can fail independently, so a single score rarely explains what went wrong.
• The article’s comparison shows that DeepEval, RAGAS, and LangSmith map to different jobs, from CI-style checks to RAG metrics to trace-level debugging.
• Production teams should align evaluation to the workflow stage and retain execution evidence so failures can be traced to the right control gap.

Key terms

• Retrieval-grounding gap: The difference between finding relevant context and using that context correctly in a generated answer. In RAG systems, a retriever can appear to work while the model still produces unsupported or incomplete output, so teams must measure both stages separately.
• Trace-Based Evaluation: An evaluation approach that records the full execution path of a run, including inputs, intermediate calls, retrieved context, and outputs. It helps teams debug multi-step AI systems by showing how a result was produced, not just whether it looked correct.
• Regression Gate: A regression gate is an automated quality check that blocks changes when agent performance falls below an acceptable threshold. Teams use it in CI/CD to prevent prompt edits, model swaps, or tool changes from degrading task completion, safety, or efficiency. It turns evaluation into a release control.
• Faithfulness: The degree to which an answer is supported by the retrieved context. In practice, it measures whether the model stayed grounded in supplied evidence rather than inventing details, which makes it a critical signal for high-trust AI workflows and audit-sensitive applications.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.