Meridian Line's maintenance-triage agent occasionally queries the index with a filter combination that matches no rows, such as a decommissioned crane at a port it never served. Retrieval returns an empty list and the chain currently passes an empty context string to the model. What is the appropriate handling?
Select an answer to reveal the explanation.
Short Explanation
An empty retrieval is information, not an error to paper over. Catch it in the chain and say so. Handing the model an empty context and hoping for the best is how you get a confidently invented maintenance history.
Full Explanation
Empty retrieval is an explicitly named failure mode and it deserves an explicit branch in the chain. Detecting the empty result set and returning a defined response — no matching maintenance records for that equipment and port — is correct, cheap, and honest; it also avoids paying for a generation call that cannot succeed. Falling back to an unfiltered search is the most tempting distractor because it guarantees non-empty context, but the filter was there for a reason, and passages about a different crane at a different port are exactly the material that produces a plausible wrong answer in a safety-adjacent workflow. Allowing the model to answer from parametric knowledge defeats the purpose of a retrieval-grounded system: the model has never seen Meridian Line's maintenance logs, so anything it produces is invention. Blind retries assume a transient cause; the described query is deterministically empty, so retries add latency and cost without changing the outcome. Worth carrying into the exam: an empty result and a low-relevance result are different conditions with different handling, and both should be caught in application code before the generation step rather than left for the prompt to manage.