Question answering

Question answering (QA) sounds like one task but is really three, distinguished by where the answer comes from and how it’s produced: extract it from a given passage, retrieve the passage first and then extract, or generate it freely. The distinctions still structure how every modern QA system — including retrieval-augmented LLMs — is built.

Extractive QA: predict a span

The classic benchmark, SQuAD, gives a question and a passage known to contain the answer, and the answer is a contiguous span of that passage. The model predicts two things per token: how likely it is to be the start of the answer, and the end. The answer is the best valid span (start ≤ end):

passage = "the Eiffel Tower is in Paris France".split()
start = [0, 0, 0, 0, 0, 3, 0]        # per-token START scores the model predicts
end   = [0, 0, 0, 0, 0, 3, 1]        # per-token END scores

best = (-1, None)
for i in range(len(passage)):
    for j in range(i, min(i + 3, len(passage))):   # spans up to length 3, with i <= j
        if start[i] + end[j] > best[0]:
            best = (start[i] + end[j], (i, j))

i, j = best[1]
print("Q: where is the Eiffel Tower?")
print(f"answer span: {' '.join(passage[i:j+1])!r}  (score {best[0]})")

Q: where is the Eiffel Tower?
answer span: 'Paris'  (score 6)

The model is really doing token classification (span labeling): score each position as start/end, then pick the highest-scoring legal span. This is the canonical task you fine-tune BERT for, and because the answer is copied verbatim from the passage, it can’t hallucinate — its weakness is that it needs the answer to be present, as a literal span.

Open-domain QA: retrieve, then read

Extractive QA assumes you’re handed the right passage. Open-domain QA drops that: the question arrives alone (“Where is the Eiffel Tower?”), and the system must first find relevant text. The pipeline is retriever → reader: a retriever (BM25 or dense embeddings) pulls candidate passages from a large corpus, then a reader (extractive QA) pulls the answer span from them. This two-stage pattern is the direct ancestor of RAG — swap the extractive reader for a generative LLM and retriever-reader becomes retrieval-augmented generation.

Generative QA, and evaluation

Generative QA writes the answer in free text with a seq2seq model or LLM, rather than copying a span. It can synthesize across multiple passages and phrase naturally — but, being generation, it can hallucinate an answer that isn’t supported. Extractive QA is scored with Exact Match (is the predicted span exactly the gold answer?) and F1 (token overlap, for partial credit); generative answers need fuzzier or model-based scoring because many phrasings are correct.

In one breath

• QA has three flavors: extractive (answer is a span of a given passage), open-domain (retrieve the passage first, then extract), and generative (write the answer freely).
• Extractive QA (SQuAD) predicts per-token start/end scores and returns the best legal span (the demo: Paris) — really token classification, the canonical BERT fine-tune; it can’t hallucinate but needs the answer present verbatim.
• Open-domain QA is retriever → reader — find candidate passages (BM25/dense), then read the answer — the direct ancestor of RAG.
• Generative QA writes free-text answers (synthesize, paraphrase) but can hallucinate; evaluation uses Exact Match + F1 for spans, fuzzier scoring for generation.
• Modern QA = RAG (retrieve + generative reader); extractive span QA still wins when the answer must be provably grounded.

Quick check

Next

The retriever-reader pattern here grows directly into RAG; span prediction is sequence labeling over the passage; and the generative reader is seq2seq. Conversational QA continues in dialogue systems.