Back to the map

Module 09 · Measuring retrieval · Lesson 4 of 4

Diagnosing a badly rated RAG system

The interview classic as a procedure: from a 2.1 out of 5 rating to segmented traces, twenty classified failures, the metric that confirms the stage, one fix behind a flag, and the five real causes in order of frequency.

DeepMust-knowSenior 14 minPro Updated Nov 2026

Why it matters

"Our RAG assistant is rated 2.1 out of 5. What do you do?" is the interview question for this whole stage. The weak answer lists things that could be wrong. The strong answer is a procedure: start from evidence, narrow to a stage, measure that stage with the right metric, fix one thing, prove the fix. Interviewers use the question because it shows whether you treat a RAG system as a pipeline with observable stages or as a box that is sometimes bad.

The idea

Low ratings are a symptom. The procedure turns them into a ranked list of causes.

Start from the ratings and the traces

Pull the rated conversations with their traces: the query, the retrieved chunks with scores, the assembled prompt, the answer. If traces are not stored, storing them is the first fix. Then segment the ratings by question type, corpus area, user cohort and time. A 2.1 average is often a 4.0 on lookups and a 1.3 on comparisons. The segment that is both worst and largest is where you look first.

Sample twenty and classify

Take twenty of the worst-rated conversations from that segment and read each trace end to end. Classify each by failure point, in pipeline order:

  • Missing content: the answer is not in the corpus at all.
  • Retrieval miss: the right chunk exists but was not in the top k.
  • Cut by budget: retrieved, but ranked below the cut or dropped by the context limit.
  • Ignored by the model: in the prompt, but the answer did not use it or contradicted it.
  • Wrong format: right content, wrong shape; a wall of text where a table was wanted.
  • Stale: the answer was right last quarter.
  • Permission: the user could not see the document needed, or saw one they should not have.

Twenty is enough: the largest bucket is obvious at that size, and reading them takes an afternoon.

Ratings 2.1/5SegmentSample 20 badClassifybucketMeasure stageFix top bucketGolden setShip + watchrating moved?behind a flagno regressionone change at a timebuckets: missing content, retrieval miss, cut by budget,ignored by the model, wrong format, stale, permission
From ratings to a fix loop: segment, read twenty bad traces, classify by failure point, confirm the stage with its metric, fix the largest bucket, prove it on the golden set, ship behind a flag and watch the rating.

Measure the suspected stage

The bucket points at a stage; the metric confirms it. For retrieval misses, run recall@k and context recall on the golden set slice for that segment. For cut-by-budget, look at context precision and the rank of the reference chunk. For ignored-by-the-model, compare context recall (high) with faithfulness and answer correctness (low). For missing content, count how many questions the corpus cannot answer. The number is your before figure.

Fix the largest bucket first

One change at a time. Fix the largest bucket, re-run the golden set, and confirm the segment moved without the others regressing. Ship behind a flag to a fraction of traffic, watch the rating for that cohort for a week, then widen. Then take the next bucket. A system tuned by three simultaneous changes cannot be explained or rolled back one piece at a time.

The common real causes

In practice the buckets fill in a predictable order. Parsing loss comes first: tables flattened to word soup, PDF columns interleaved, so the chunk that should answer is unreadable. Chunking is next: chunks that split a procedure in half, or so large that the embedding averages three topics into none. No reranker: the right chunk comes back at rank seven and the budget cuts at five. The prompt does not bind to the sources: the model is given chunks but not told to answer only from them and cite, so it blends training memory with context. No handling of out-of-scope questions: the system answers everything, and the confident wrong answers to questions it should have declined are the ones users rate lowest. Four of the five sit before the model, which is why swapping the model rarely moves a 2.1.

 Parsing lossChunkingNo reranker
SymptomAnswers wrong on anything from a table or multi-column PDFHalf a procedure; answers that stop mid-stepRight chunk appears in traces at rank six to ten
TestOpen the stored chunk text for ten bad cases and read itContext recall by document type; chunk length histogramRecall@20 high while recall@5 low; MRR below 0.5
FixLayout-aware parser; tables to markdown; re-indexStructure-aware splitting with overlap; re-indexCross-encoder rerank of top 30 to top 5
EffortDays, plus a full re-indexDays, plus a full re-indexOne to two days, adds 50 to 200 ms per query

Narrating it in 45 minutes

Spend the first five minutes asking what is logged and what the rating is attached to. Spend ten on segmenting and sampling, saying out loud how you would classify the twenty. Spend fifteen on the top two buckets: the metric that confirms each, the fix, and the before-and-after number you expect. Spend ten on shipping: the golden set as the gate, the flag, the cohort rating. Keep five for follow-ups, and name the order of the real causes unprompted.

Diagnosing a badly rated RAG system · Backplane