Evaluate retrieval before you blame the model

When a RAG answer is wrong, the model is the obvious suspect. It is also usually innocent. The first thing to measure is whether the passage that held the answer ever made it into the set the model was given to read.

Define done before you start blaming

A CTO whose firm ships software across healthcare and fintech runs quality from the front. Discovery sessions before the build. Every step documented. A clear definition of what done means before a sprint begins. That habit is the missing piece in most RAG debugging. Teams ship a retrieval system with no definition of what good retrieval even is, so when the output is wrong they have no measurement to point at, and the argument defaults to the part everyone can read: the model.

You cannot debug a two-stage system by staring at the second stage. Retrieval finds passages. The model writes from them. If you have not measured whether retrieval found the right passage, you have no idea which stage failed, and you will spend your effort on whichever one is easier to poke. That is almost always the prompt, because the prompt is text you can edit in a second, and the retrieval quality is a number nobody computed.

Recall at k is the number that settles it

There is a simple, boring metric that resolves most of these arguments. Recall at k. For a set of real questions where you know which document holds the answer, run retrieval and check how often that document appears in the top k results the model actually receives. If recall is low, the model is being asked to answer from a set that frequently does not contain the answer. No prompt fixes that. The model cannot ground a response in a passage it never saw.

Run that measurement first and the whole investigation changes. High recall and wrong answers means the right passage was there and the model mishandled it, so now model and prompt work is justified. Low recall means the answer was missing from the input, so the work is in retrieval: chunking, embeddings, filters, ranking. Same wrong answer, two completely different fixes, and the only way to know which one you are looking at is to have measured whether the passage was present. Skip the measurement and you are guessing, and the guess reliably points at the wrong stage.

Non-determinism makes eyeballing useless

There is a second reason to measure rather than eyeball. GenAI is non-deterministic. The same question can produce different outputs on different runs, so trying a few prompts by hand and judging the results tells you almost nothing. You saw a handful of samples from a distribution and drew a conclusion the distribution does not support. Evaluating a non-deterministic system needs a different mindset than testing ordinary code, one built on measuring properties across many samples rather than checking one output and calling it correct. Even using a model to judge the outputs carries the same catch, because the judge is non-deterministic too. The usual move is to sample it several times and take the most frequent verdict rather than trusting a single pass.

Recall at k sidesteps all of that noise, because it does not ask the model to judge anything. It asks a factual question with a factual answer. Was the right document in the retrieved set, yes or no. That is a stable measurement you can compute over hundreds of questions and actually trust, and it tells you where to look before the non-determinism of the generation step muddies everything.

The order that saves the quarter

The lesson is about sequence. Measure retrieval, then decide whether the model is even in scope. The failure that strands most RAG projects is not a weak model. It is a team that spent a quarter tuning generation for a retrieval problem, because they never ran the one check that would have pointed them upstream. Studies put the share of pilots that stall on integration and trust rather than model quality around 95 percent, and answering the wrong question about which stage failed is how a lot of them get there.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two week, $2,500 engagement, we measure recall at k on real questions before we say a word about the model. We build a small set of questions with known answers, check how often retrieval delivers the right passage into the top results, and only then decide whether the model is the problem worth solving. It is far cheaper to learn in week one that the answer was never retrieved than to spend three months tuning a model that was fed the wrong page.

Do not tune the writer until you know the writer had the right notes.