Query understanding and retrieval

At query time, the system must turn a user request into a search that is both meaningful and authorized. Normalize harmless formatting differences, resolve references such as “that policy” from the current conversation, and preserve the original wording for answer generation. A query rewrite should not introduce assumptions or remove a constraint such as a product version or date range. Apply filters such as tenant, user access, document status, and effective date before retrieved passages are sent to the model. Return source IDs, ranks, and useful metadata with each candidate. Limit the candidate count to fit the context budget, while allowing enough breadth for reranking. Query handling should preserve user intent rather than silently rewrite it into a different request. A retrieval pipeline can normalize spelling, expand known abbreviations, or create a standalone search query from conversation context, but keep the original question available for the final answer. Apply metadata filters for tenant, permissions, date, and document status before results reach the prompt. Retrieve a modest candidate set first, inspect relevance and diversity, and avoid sending redundant near-duplicates that crowd out complementary evidence. Log a safe query representation and filter decisions so retrieval failures can be diagnosed. Implementation drill: trace one representative request through the stages in the diagram. Write down what enters each stage, what output or evidence it produces, and which identity is allowed to perform it. Then test an empty input, an unauthorized request, a dependency timeout, and an unexpected result. For each case, state whether the application should retry, reject, abstain, or ask a person for help. Keep the observed failure as a regression example so changes to prompts, models, data, or code can be checked against the same behavior. Practice task: When should a user-specific filter be applied to retrieved passages?