Query expansion improves retrieval by supplementing an original query with related expressions that may appear in relevant documents. A user might ask about “recovering accidentally deleted files,” while operational documentation describes “object version recovery” or “restoring previous versions.” Searching these related formulations can uncover evidence that a single keyword query misses. Expansion can use curated synonym dictionaries, domain taxonomies, relevance feedback, or a foundation model that generates alternative search expressions.
In retrieval-augmented generation, expansion occurs before or during evidence retrieval, not as a substitute for retrieving evidence. An application can generate several intent-preserving variants, submit the original query and its variants to a search backend, merge the results, remove duplicate chunks, and rerank the candidates. The answer-generating model then receives selected source passages. Generated expansion terms are retrieval aids, not verified facts and not authoritative answer context.
Consider an engineering assistant receiving the question “Why do requests fail when our API gets busy?” An expansion step might produce queries containing “request throttling,” “rate limits,” and “HTTP 429.” These formulations help locate documentation written in technical language. However, overload can also cause timeouts or server errors, so the application should avoid treating one generated interpretation as an established diagnosis. Preserve the original query, generate a bounded set of alternatives, and ask for clarification when ambiguity materially affects the answer.
Expansion is related to, but distinct from, query decomposition and query transformation. Decomposition splits a complex question into independently searchable subquestions, such as separating retention requirements from recovery procedures. Transformation is the broader category of adapting a query, including normalization, rewriting, and translation into a backend-specific format. An effective workflow may decompose a question first and expand each subquestion afterward, but these operations solve different retrieval problems.
In a cloud implementation, an application can invoke a foundation model through Amazon Bedrock to produce structured query variants. AWS Lambda functions can validate the generated output, apply terminology mappings, decompose compound questions, and prepare retrieval requests. AWS Step Functions can coordinate these operations with parallel searches, timeouts, retries, and fallback paths. A search engine such as Amazon OpenSearch Service can execute lexical, vector, or hybrid retrieval. These services provide building blocks; a custom expansion workflow still requires application logic, appropriate model instructions, and evaluation.
Expansion commonly improves recall, but it can reduce precision through query drift: added terms may change the topic or introduce unsupported assumptions. More searches also increase retrieval work, model token consumption, and potentially latency. Limit the number and length of variants, retain exact identifiers and explicit constraints, and consider rank fusion rather than directly comparing raw scores from different retrieval methods. Reranking and deduplication help keep the final context focused, but they cannot guarantee that missing evidence will be recovered.
Security boundaries must remain independent of generated text. Derive tenant and document-access filters from authenticated application context, and apply them consistently to every expanded search. Do not allow model-generated variants to remove authorization constraints or modify trusted filters. Treat user queries and retrieved documents as untrusted inputs, minimize sensitive information sent to models, and protect query logs. Evaluate expansion against an original-query baseline using representative questions, recall at a fixed retrieval depth, ranking quality, grounded answer quality, latency, and cost. Enable it selectively when the measured gains justify the additional complexity.