Debugging and Improving RAG Pipelines with Deepchecks

Using Deepchecks Root Cause Analysis to Detect and Fix Failures in LLM Applications

Large Language Models are famously known to hallucinate. RAG helps, but the retrieval accuracy and answer quality tend to be still fragile. Standard RAG evaluation protocols are often insufficient for understanding where your RAG is failing, and why. In this article, we discuss Deepchecks’ Root Cause Analysis-based approach to RAG evaluation and how to implement it.

Retrieval-augmented generation, or RAG, is a great way to increase the likelihood that your LLM’s outputs are based on data rather than hallucinated. However, designing RAG systems is complex. The process involves setting a significant number of hyperparameters. How do you chunk your texts before indexing? How large do you make these chunks? Should they overlap? If so, by how much? What kinds of metadata should be stored next to the embeddings? Don’t even get me started on retrieval and synthesis configuration. And beyond all that, there are the challenges that can arise at other stages of the application that interacts with the LLM, not just within the RAG pipeline itself.

With so many knobs to tune, the chance that something goes wrong is non-negligible, and the consequences are serious. Whenever retrieval fails to deliver the relevant data, we’re back to square one: a hallucinated answer. That is why it is crucial to evaluate RAGs properly.

Standard evaluation approaches tend to focus on aggregate accuracy. Based on a golden test set, they provide insights into how often the RAG is correct. However, it doesn’t tell us anything about why some of the answers fail: you can’t tell if failure is from poor retrieval, hallucination, or prompt weakness. This makes it hard to address the issues.

The Deepchecks’ Root Cause Analysis (RCA) approach that we discuss in this article answers the why-questions, guiding us through the process of improving our LLM application. In the following sections, we will walk through a baseline RAG example, diagnose its failures with Deepchecks RCA, and see how small changes suggested by the analysis improve the performance metrics.

We will work with a simple RAG pipeline using the BeIR/FiQA dataset. It is a small, RAG-friendly dataset containing fact-based queries on financial topics. It is fact-heavy and easy to run locally, which makes it a perfect candidate for this demonstration.

We use LlamaIndex to chunk the text, embed it with the bge-small-en-v1.5 model, and store the embeddings in an in-memory vector store. Then, we run the FiQA questions against our RAG. We deliberately keep this baseline simple to showcase the Deepchecks RCA features:

• At retrieval, we just take the first k hits without using any re-ranker.
• We keep the prompts basic. Our system prompt simply says: “You are a knowledgeable assistant. Answer user questions.”, while the user preamble simply states “Answer briefly.”.

You can review the implementation in this Python script (and run it yourself!). It builds the RAG pipeline on a chosen BEIR dataset with LlamaIndex, runs it in baseline and improved modes (see next sections for details on the improvements), and logs the questions, retrieved context, and answers to Deepchecks for root cause analysis.

Let’s examine our baseline run in the Deepchecks app.

Root Cause Analysis of a Q&A baseline RAG in Deepchecks. Image by author.

Three notable results stand out, highlighted with purple rectangles in the screenshot above. First, in the Q&A Summary section, we can see the “Grounded in Context” property flagged near the top of bad interactions: 9% of all answers produced by the LLM seem not to be based on the context data.

The groundedness concerns are justified further by the score available in the Q&A Properties section. The “Grounded in Context” property scores 0.69 on average, where 1 means that the LLM output is fully based on the input context, and 0 means that the LLM output is not based on the input context at all. It is not exactly a great score.

Let’s try to find out why that is the case. The property failure analysis feature provides some additional insights. In general, it summarizes the instances of bad scores of a given property. In our case, for “Grounded in Context”, it groups the hallucinations into categories like Personal Finance Advice, Investment Guidance, Real Estate Decisions, etc., and highlights those for which lack of groundedness is the most pressing issue.

Failure analysis for the “Grounded in context” property. Image by author.

This is crucial: without such a summary, we would just say that some answers are hallucinated. With it, we can see that our model tends to hallucinate advice on personal finance and investing, exactly the kind of content where unsupported claims are potentially very risky for the users.

Finally, the Q&A Insights section highlights another potential issue: the data retrieved from the vector store is poorly ranked for a great number of interactions.

Root Cause Analysis of a Q&A baseline RAG in Deepchecks. Image by author.

This can also exacerbate the hallucinations: if the ranking is poor, the top-k retrieved chunks might not always contain the relevant data, pushing the LLM to become creative with its answers.

Let’s see how to improve our RAG based on these insights.

Let’s start by summarizing what we learned through the Root Cause Analysis:

1. Groundedness is an issue, specifically due to unsupported advice-style answers.
2. The retrieved data seems to be poorly ranked.

Based on those observations, let’s try to improve our RAG pipeline. We will make two precisely targeted changes.

First, in an attempt to reduce hallucinations, we will update the prompts. Let’s explicitly ask the LLM to solely use the provided context to generate the answer while including quotes from the context in the response. Compare these new, strict prompts with the baseline prompts we used before.

Second, to alleviate the poor ranking problem, we add the reranker. We will use the BAAI/bge-reranker-base model to sort the retrieved chunks from the most to least relevant for the query (see this line in our Python script).

Let’s upload the data from the new version of the pipeline to Deepchecks and inspect the RCA features. Note that we have run the same set of inputs with the new, improved pipeline while creating a new app version for the new results.

Let’s see how our changes impact the Deepchecks RCA.

Root Cause Analysis of a Q&A improved RAG in Deepchecks. Image by author.

Notice how the “Grounded in Context” property score increased from a meh 0.69 to a near-perfect 0.98. At the same time, the groundedness issue vanished from Q&A Summary’s top bad interactions, and the “poor ranking” insight is gone from the Q&A Insights section.

Thanks to the Deepchecks RCA, we were able to isolate issues with our RAG and provide small, targeted fixes to address them.

In this walkthrough, we saw how easy it is for even a simple RAG pipeline to produce answers that are ungrounded in the retrieved data. By applying Root Cause Analysis in Deepchecks, we were able to actually understand why the model was failing, pinpointing systematic hallucinations in advice-style answers and poor retrieval ranking. With that knowledge, we applied small, targeted fixes: strengthening the prompts and adding a reranker. The result was a dramatic improvement in groundedness, with measurable gains visible in Deepchecks’ properties and insights.

While we used RAG as the running example, Deepchecks RCA is equally powerful across other types of LLM applications, from agents to custom pipelines, helping uncover and resolve the underlying causes of model failures. Deepchecks RCA constitutes the missing lens for debugging LLM applications, providing actionable patterns one can address. This is not limited to offline evaluations, too; Deepchecks can be plugged into production to continuously monitor user interactions, surface recurring failure modes, and guide ongoing improvements.

Crucially, small (or even elementary) adjustments, when guided by Deepchecks RCA, can make the difference between a system that hallucinates and one that reliably grounds its answers in evidence.