What is an acceptable range of retriever recall for a RAG system aiming to answer questions correctly most of the time, and how might this vary by application domain?

An acceptable retriever recall range for a RAG (Retrieval-Augmented Generation) system typically falls between 80% and 95%, depending on the application domain. Recall measures how well the retriever finds all relevant documents needed to answer a question. A system aiming to answer questions correctly “most of the time” needs high enough recall to avoid missing critical information, but not so high that it retrieves excessive irrelevant content, which could confuse the generator. For example, a general-purpose QA system might target 85-90% recall, balancing coverage and noise. Lower recall (e.g., 80%) risks missing key details, while near-perfect recall (95%+) often requires trade-offs in latency or computational cost due to retrieving more documents.

Domain requirements heavily influence the ideal range. In high-stakes fields like healthcare or law, recall should lean toward the upper end (90-95%). For instance, a medical RAG system answering diagnostic questions must retrieve all relevant research or guidelines to avoid harmful omissions. Conversely, a customer support chatbot for a retail product might tolerate 80-85% recall, as missing minor product details is less critical and responses can default to fallback options like “Contact support.” In technical domains like software documentation, 85-90% recall is practical—ensuring most API references are found without overwhelming the generator with outdated or irrelevant code examples.

Implementation choices also affect achievable recall. A system using dense vector search alone might achieve 80-90% recall, but combining it with keyword search (hybrid retrieval) can push recall closer to 95% by compensating for cases where semantic similarity fails. The size and structure of the knowledge base matter: a small, well-organized corpus (e.g., a company’s internal docs) allows higher recall with fewer retrieved documents, while a vast, unstructured corpus (e.g., internet-scale data) may require tuning to balance speed and accuracy. Adjusting the number of documents retrieved (e.g., from 5 to 20) and using rerankers can further optimize the balance for specific use cases.