Learn AI Create the Future — with Pranay
Main site

Question Answering

Diagnosing a wrong answer

A wrong answer can come from a retrieval failure, an ambiguous question, or a model reading the right passage badly — and fixing it starts with telling those three apart.

Read these first

On this page 5
  1. Why it exists
  2. How it works
  3. Where you have already seen it
  4. Remember this
  5. What to learn next

One lesson, three depths. Pick the one that fits you today — you can switch any time.

Beginner — No maths. Plain English.

Diagnosing a wrong answer means figuring out where a question-answering system actually failed, before trying to fix it.

Think about a call centre complaint that got the wrong answer. Was the person given the wrong file to look at? Or did they misread the right file sitting in front of them? Fixing the wrong problem wastes everyone's time.

Why it exists

A retrieval-augmented system has several moving parts — search, then reading, then answering. A wrong final answer could come from any one of them. The right fix depends entirely on which one failed.

If search never found the right passage, the model never had a chance, no matter how good it is at reading. If the right passage was found but misread, better search will not help at all.

Diagnosing correctly means checking each stage in order: was the right information retrieved? If yes, did the model use it correctly? Only after answering both questions does the real fix become clear.

How it works

Question asked -> was the wrong answer given?
       |
       v
  Was the RIGHT passage among what got retrieved?
       |
     NO ------------------> retrieval failure
       |                    (fix: search, chunking, embeddings)
    YES
       |
       v
  Did the model's answer match what that passage said?
       |
     NO ------------------> reading / synthesis failure
       |                    (fix: prompt, model, ambiguous question)
    YES
       |
       v
  The passage itself may be wrong, outdated, or ambiguous
  (fix: source data, conflict handling)

Where you have already seen it

  • "Why did my search return nothing useful?" debugging. Check what actually got matched, before blaming the ranking.
  • Customer support quality reviews. These check whether an agent had the right information, versus whether they used it correctly.
  • Bug triage in software. "The data was wrong" and "the code misread correct data" get the same two-stage treatment.

Remember this

  • A wrong answer can fail at retrieval, at reading, or in the source data itself.
  • Check whether the right information was even retrieved before blaming the model's reasoning.
  • The fix for each failure type is different — treating them the same wastes effort.

What to learn next

Developer — Code and libraries.

This walks through three real cases — a retrieval failure, a correct answer, and an ambiguous question — using the same extractive model throughout.

Setup

bash
pip install transformers torch

The first run downloads deepset/minilm-uncased-squad2, about 130 MB.

Telling failure types apart

diagnose.py
import torch
from transformers import AutoTokenizer, AutoModelForQuestionAnswering

name = "deepset/minilm-uncased-squad2"
tok = AutoTokenizer.from_pretrained(name)
model = AutoModelForQuestionAnswering.from_pretrained(name)
model.eval()

def answer(question, context):
    inputs = tok(question, context, return_tensors="pt")
    with torch.no_grad():
        out = model(**inputs)
    start = torch.argmax(out.start_logits)
    end = torch.argmax(out.end_logits) + 1
    if start == 0 and end == 1:
        return None
    return tok.decode(inputs["input_ids"][0][start:end]).strip()

question = "What was the revenue growth for the quarter?"

# Case 1: retrieval failure -- the retrieved chunk has nothing to do with revenue
wrong_chunk = "The company was founded in 2010 and is headquartered in Pune."
print("Case 1, retrieval failure:")
print(" answer:", answer(question, wrong_chunk))

# Case 2: correct retrieval, unambiguous question
right_chunk = "Wipro's revenue for the quarter was 22,000 crore rupees."
question2 = "What was Wipro's revenue for the quarter?"
print("Case 2, correct retrieval, clear question:")
print(" answer:", answer(question2, right_chunk))

# Case 3: correct retrieval, but the QUESTION is ambiguous -- two companies
# are mentioned, and the question does not say which one
ambiguous_chunk = (
    "TCS reported quarterly revenue growth of 4 percent. "
    "Infosys reported quarterly revenue growth of 6 percent for the same period."
)
print("Case 3, ambiguous question, both companies present:")
print(" answer:", answer(question, ambiguous_chunk))
Output
Case 1, retrieval failure:
 answer: None
Case 2, correct retrieval, clear question:
 answer: 22, 000 crore rupees
Case 3, ambiguous question, both companies present:
 answer: 4 percent

Line by line

Case 1 correctly returns None. This is retrieval failure, working as intended — the model honestly reports no answer, because the chunk it was given genuinely does not contain one. The fix here is upstream: better search, better chunking, or a better embedding model, not a different question-answering model.

Case 2 succeeds cleanly. Right chunk, unambiguous question, correct answer. This is the baseline everything else gets compared against.

Case 3 is the subtle one. The question never specifies which company, and the passage mentions two. The model picks "4 percent" — TCS's figure, the one that appears first — with no signal to the user that the question was ambiguous. This is neither a retrieval failure nor a model error in the usual sense. It is a question-ambiguity failure, and it looks exactly like a confident, correct-seeming answer.

Common mistakes

Blaming the model before checking what it was actually given. The single most useful first debugging step is printing the exact retrieved context, every time, and reading it yourself before assuming the model reasoned badly.

Never testing questions with more than one plausible referent. Case 3's failure is common in real data, especially numeric reports mentioning several similar entities, and it will not show up in testing unless you deliberately construct cases like it.

Assuming a "None" result is always a retrieval bug. Sometimes None is the model behaving correctly, on a genuinely unanswerable question. Check the retrieved context before assuming abstention itself is the problem.

Fixing the symptom instead of the stage that actually failed. Swapping in a bigger, more expensive model does not fix a retrieval failure. Rewriting the retrieval pipeline does not fix a badly worded, ambiguous question. Diagnose the stage first.

Try it yourself

Rewrite the Case 3 question to remove the ambiguity — "What was TCS's quarterly revenue growth?" — and re-run against the same ambiguous_chunk.

The model should now return "4 percent" with the target plainly specified this time, not by accident. Compare this to the earlier result: same passage, same underlying number returned, but now correctly and traceably, because the question itself no longer has two valid readings.

What to learn next

Researcher — Mathematics and papers.

Error taxonomy for retrieval-augmented QA

A useful decomposition of a wrong RAG answer distinguishes at least four failure loci, extending the three informal cases in the developer block:

  1. Retrieval failure. The correct passage was never returned by the search step, regardless of what the reader does with what it got.
  2. Reading / synthesis failure. The correct passage was retrieved, but the model failed to extract or compose the correct answer from it.
  3. Question ambiguity. The question itself has more than one valid reading, and the system silently resolves it one way with no signal to the user, as in the developer block's Case 3.
  4. Source failure. The retrieved passage is itself wrong, outdated, or misleading, so a technically correct read of it still produces a wrong real-world answer — the subject of When two documents disagree.

Isolating retrieval from reading in evaluation

The standard method for separating failure types 1 and 2 systematically, rather than case by case as in the developer block, is to evaluate with oracle retrieval: replace the retriever's output with the known-correct gold passage, and measure reading accuracy in isolation. The gap between full-pipeline accuracy and oracle-retrieval accuracy attributes error specifically to the retrieval stage; the remaining gap between oracle accuracy and 100% attributes error to the reading stage. This decomposition is standard practice in retrieval-augmented system evaluation and is one of the more informative single diagnostics available, since it directly answers "which half of the pipeline should we invest in improving."

Question ambiguity as a distinct, understudied failure mode

Case 3 in the developer block is not a bug in the model in any usual sense — it is a well-defined behaviour under an ill-defined question. Formally, an ambiguous question q has multiple valid interpretations q_1, ..., q_m, each with a potentially different correct answer, and a single-answer QA system necessarily collapses this to one output with no principled way to know it did so. Detecting ambiguity — recognising that a question has multiple defensible readings, before answering — is closer to the answerability problem covered earlier in this section than to standard span extraction, and remains comparatively under-addressed in mainstream QA system design relative to retrieval and reading quality.

Key references

Error decomposition for retrieval-augmented QA draws on practices established across the SQuAD (Rajpurkar et al., 2016, arXiv:1606.05250) and open-domain QA evaluation literature, and is discussed as a system-design concern throughout Gao et al. (2023), Retrieval-Augmented Generation for Large Language Models: A Survey (arXiv:2312.10997).

Current state and open problems

Automated failure-locus classification — a tool that takes a wrong answer and reliably reports "this was a retrieval failure" versus "this was a reading failure" versus "this was an ambiguous question," without a human manually checking the retrieved context each time, as the developer block does by hand — is not a solved or standardised part of most production RAG evaluation pipelines. Most teams still perform this diagnosis manually, on a sample of failures, rather than automatically across an entire evaluation set, which limits how quickly a genuine root cause can be found and fixed at scale.

What to learn next