Question Answering › Limitations and Practical Considerations

Question answering systems have matured rapidly, but significant challenges remain in deploying them reliably. Understanding these limitations is essential for building systems that work in production and for interpreting research claims accurately.

Retrieval quality bottleneck. In retrieval-augmented QA, the quality of the final answer is bounded by what the retriever returns. If the relevant document is never fetched, even a perfect reader cannot help. Dense retrieval handles vocabulary mismatch better than sparse methods, but requires significant infrastructure: encoding millions of passages, maintaining a vector index, and keeping the index up-to-date as documents change. A retrieval pipeline that worked well on a static Wikipedia snapshot may degrade silently as the underlying corpus evolves. Index staleness is a real operational concern: a news QA system built on a snapshot from six months ago will give wrong answers to questions whose facts have changed. Keeping the index fresh requires either periodic full re-encoding (expensive) or incremental update strategies.

The retrieval bottleneck also manifests as a coverage gap. Dense retrieval models are trained on specific question-answer pairs and may generalize poorly to question types or topics outside their training distribution. A DPR model trained on Wikipedia QA may retrieve poorly on legal documents, medical literature, or code documentation, because the embedding space was shaped by general-domain training examples. Domain-specific fine-tuning of the retriever, or using hybrid retrieval that combines domain-tuned dense models with BM25, can mitigate this.

Hallucination in generative QA. Generative models can produce fluent, confidently stated answers that are factually wrong. This is particularly dangerous in high-stakes domains like medicine, law, and finance. Grounding answers in retrieved documents mitigates but does not eliminate hallucination. Models can misread passages, infer beyond what the text supports, or blend retrieved content with parametric memory. A model asked "What is the dosage of ibuprofen for adults?" may retrieve a correct passage but add an incorrect qualification not in the passage, mixing its parametric knowledge with the retrieved information in ways that produce errors invisible to a simple faithfulness check.

Calibration, making sure confidence scores correlate with accuracy, remains an open problem. Models typically give high confidence to wrong answers at the same rate they give high confidence to correct ones. Research on uncertainty quantification for language models continues, but no mature solution exists for production deployment. Practical mitigations include: always grounding answers in retrieved sources and telling users which source was used, using abstention thresholds calibrated on held-out data, and building human-in-the-loop review for high-stakes domains.

Evaluation gaps. Standard benchmarks like SQuAD measure a narrow slice of QA capability: single-passage, short-answer, well-posed questions with known answers. Real-world questions are messier: ambiguous, multi-hop, temporally sensitive, or subjective. Models that score well on benchmarks can still fail on practical queries. A model with 90 F1 on SQuAD may fail on 30% of real customer support queries because those queries involve domain-specific terminology, require multi-document synthesis, or are poorly formed. Developing evaluation suites that better reflect deployment conditions, including distribution shift from benchmark to production, is an active area of research. Teams building QA systems should maintain their own evaluation sets from real queries, not rely solely on public benchmarks.

Unanswerable questions and refusal. Knowing when not to answer is as important as knowing the answer. A model that always produces some answer is dangerous if the question cannot be answered from available information. Calibrated confidence scores and explicit "I don't know" outputs reduce downstream harm. SQuAD 2.0 and similar datasets help train models to abstain on unanswerable questions, but calibration under distribution shift is hard to guarantee. In practice, the frequency of unanswerable questions in deployment is often much higher than in training data, because deployed systems receive queries from users who don't know whether the system has the relevant information.

Multi-hop and temporal reasoning. Many real questions require combining information across multiple documents or reasoning about time. Current retrievers typically fetch passages relevant to the original question, not the chain of hops needed to answer it. Iterative retrieval and chain-of-thought prompting help but add latency and complexity. Temporal questions are particularly tricky: knowledge changes over time, but models are static. Combining a large static model with a frequently-updated document store is the practical solution, but requires careful engineering to ensure the model reads from the updated corpus rather than relying on stale parametric knowledge.

Domain adaptation. Models fine-tuned on Wikipedia-style passages may underperform on specialized domains: scientific literature, legal documents, medical records. The vocabulary, reasoning patterns, and answer formats differ significantly. Continuing fine-tuning on domain-specific QA data or using domain-specific retrievers can close this gap, but requires labeled data that may be expensive to collect. Active learning strategies, where the system identifies its most uncertain predictions in the target domain and requests human annotation for those examples, can make domain adaptation more data-efficient.

The combination of these limitations means that production QA systems require ongoing evaluation, monitoring, and iteration. A system that works well at launch will drift in quality as the document corpus changes, user query patterns shift, and the world changes in ways that make training-time knowledge stale. Treating QA system development as a product that requires sustained engineering rather than a one-time model deployment is the right mental model for practitioners.