Design and test a useful zero-result RAG response

Define the observable search states

Qdrant’s filtering documentation describes restricting results by conditions. An empty response after filtering does not tell you whether evidence exists outside the eligible set or whether a query was malformed. Record search status, filter expression, candidate count, and any backend error. Define which details the application may disclose to the user. An assistant should not reveal the existence of restricted documents merely to explain why the current authorized search produced no evidence.

Evidence: Filtering [1]

Author four empty-result causes

Create fictional cases for a genuinely missing policy, a misspelled product name, an overrestrictive date filter, and a simulated service timeout. Add an answerable control with a valid query and filter. The expected response differs: state the knowledge gap, clarify or correct the query, diagnose a recoverable scope issue through an authorized path, or explain temporary unavailability. The control prevents the system from appearing safe simply because it refuses all requests, including ones it can answer.

Check for unsupported completion

Inspect whether the model fills an empty context with plausible background facts. For a corpus-bounded policy assistant, an unsupported specific answer should fail even if it happens to match a real-world convention. Conversely, a simple restatement of “no results” may be unhelpful when a clarifying question could resolve an ambiguous entity. Score factual restraint and useful next action separately. Keep the original evidence state with each answer so a judge does not assume documents were available when none were supplied.

Test the recovery boundary

If the application retries, rewrites, or uses another source, record that branch and evaluate it under the same original intent and eligibility rules. A rewritten query that removes a required condition is not a valid fix for an empty result. A timeout retry should not be interpreted as evidence of absence. Set a work limit and inspect the final response when recovery remains unsuccessful. The user-facing explanation should reflect what was actually attempted without inventing a completed investigation.

Use empty-result trends diagnostically

Group recurring cases by missing corpus coverage, query-resolution failure, metadata defect, and service availability. Compare each group before changing retrieval thresholds or adding fallback search. A rising empty-result count may reflect newly enforced eligibility rules rather than worse semantic search. Retain representative positive controls and synthetic negatives in regression checks. The release decision should establish that the application handles known empty states correctly, not merely reduce the count by returning increasingly weak or inapplicable passages. Verify that the final response does not claim a human investigation or a completed support escalation unless the application actually performed and recorded that action.

Common questions