CLOUD CONCEPT

Query Rewriting

Query rewriting transforms a user's request into one or more retrieval queries that better express the intended information need.

Cloud Concepts Hub →

What is Query Rewriting

Query rewriting bridges the gap between how users ask questions and how information is indexed and searched. In retrieval-augmented generation, it can resolve conversational references, align terminology, and break complex questions into searchable parts, improving the evidence supplied to a foundation model while introducing additional latency, cost, and validation requirements.

Query rewriting changes the representation of a request before retrieval so that the search system can find more useful evidence. A user's natural-language question may contain ambiguous references, unfamiliar abbreviations, unnecessary wording, or several independent information needs. A rewriting layer converts that request into search-oriented text or structured queries while preserving its intent and constraints. In retrieval-augmented generation, the objective is better supporting context for the answering model, not a more polished version of the user's wording.

Common techniques include deterministic preprocessing, terminology normalization, conversational reformulation, query expansion, and decomposition. For example, after a user asks about database backups, the follow-up question “How long are they kept?” can become a standalone query about backup retention for the previously identified database. The rewriting component must retain the correct database, environment, and time period. If those details are missing or genuinely ambiguous, asking for clarification can be safer than inventing them.

Expansion adds relevant alternative terms to improve recall. A support question containing an internal abbreviation might be expanded with its approved full name and related terminology from a controlled glossary. Decomposition instead separates a question such as “Compare backup retention and restore procedures for production and development” into targeted subqueries. Those searches can run concurrently, with their results merged and deduplicated before context selection. However, adding synonyms indiscriminately can dilute precision, and decomposing a question can lose relationships that require joint reasoning.

In a cloud application, an API handler can first apply inexpensive normalization, then invoke a foundation model only when conversational resolution or complex transformation is needed. Amazon Bedrock can provide model inference for generating query variants. AWS Lambda can implement preprocessing, validate structured rewrite output, and dispatch subqueries. AWS Step Functions can coordinate conditional branches, parallel retrieval, retries, and fallbacks. Treat model-generated queries as untrusted data: validate their structure, constrain their operators, and use parameterized requests rather than concatenating generated text into executable query expressions.

Rewritten queries can feed keyword search, vector search, or hybrid retrieval. Keyword search benefits from exact identifiers and domain terminology, while vector search can benefit from a self-contained description of the information need. A hybrid system may deliberately produce different representations for each path rather than use one expanded string everywhere. In Amazon OpenSearch Service, application and search-pipeline logic can combine lexical and vector results, normalize or fuse scores, and apply supported scoring mechanisms. Raw lexical and vector scores should not be assumed to share a comparable scale.

Query rewriting complements index optimization; it does not replace it. Appropriate text analyzers, metadata mappings, chunk boundaries, embedding choices, and vector-index settings still determine what retrieval can find and how quickly. Similarly, reranking is a separate operation that reorders retrieved candidates rather than transforming the request. Traditional database query rewriting often aims to preserve exact result equivalence; natural-language retrieval rewriting instead aims to preserve information intent and therefore requires empirical relevance testing.

Performance improvements are workload-dependent. A focused rewrite may reduce irrelevant candidates or downstream context size, but model inference and multiple searches can increase end-to-end latency and cost. Bound the number of variants, retrieval depth, execution time, and total context budget. Cache only where identity, tenant, conversation context, and freshness requirements permit, and retain the original query as a fallback when rewriting fails validation or exceeds its deadline.

Evaluate the complete retrieval and answer pipeline against representative labeled questions. Track recall at a chosen retrieval depth, ranking quality, answer correctness, groundedness, tail latency, and cost per request. Preserve exact product codes, negations, date ranges, and jurisdictional requirements. Enforce authorization and tenant filters independently of generated text on every retrieval path; a rewrite must never broaden access. Restrict sensitive query logging and treat instructions embedded in user text as untrusted input to the rewriting model.

Key aspects of Query Rewriting

Effective query rewriting preserves user intent, adapts requests to the retrieval system, and improves measured relevance within explicit security, latency, and cost limits.

Intent and constraint preservation

Keep entities, identifiers, negations, dates, and scope intact when changing query wording. Resolve conversational references only when the available context supports a clear interpretation.

Selective expansion and decomposition

Add controlled terminology variants to improve recall, or split compound requests into independently searchable questions. Bound the number of generated queries and preserve relationships needed to answer the original request.

Retrieval-aware transformation

Tailor query representations to keyword, vector, and hybrid retrieval rather than assuming one formulation works equally well everywhere. Preserve exact terms for lexical matching and sufficient semantic context for embedding-based search.

Secure execution boundaries

Validate generated query structures and keep authorization filters outside model control. Apply the same tenant and document-access restrictions to every expanded or decomposed query.

Latency and cost controls

Use deterministic preprocessing for simple cases and reserve model-based rewriting for requests likely to benefit. Apply deadlines, bounded parallelism, retrieval budgets, and original-query fallbacks.

Measured relevance improvement

Compare rewritten retrieval against an original-query baseline using representative questions and relevance judgments. Measure answer quality, retrieval ranking, tail latency, and cost together rather than optimizing recall alone.

Cloud services for Query Rewriting

A practical implementation uses Lambda for lightweight normalization and validation, then invokes a model through Amazon Bedrock when the request requires conversational reformulation, expansion, or decomposition. Step Functions can coordinate these tasks and run bounded parallel searches. OpenSearch Service retrieves candidates using lexical, vector, or hybrid search, with application or search-pipeline logic combining results before context selection. Authorization filters must accompany every retrieval request independently of generated query text. End-to-end evaluation determines whether the extra rewriting and orchestration improve relevance enough to justify their latency and cost; simple requests can bypass model-based rewriting entirely.

Amazon Bedrock

Applications can invoke foundation models through Amazon Bedrock to reformulate conversational questions, expand terminology, or generate structured subqueries. Prompts and output validation should constrain transformations to the user's information need rather than allow unsupported assumptions.

Open Amazon Bedrock →

AWS Lambda

Lambda functions can implement deterministic preprocessing, glossary lookup, decomposition logic, and validation of model-produced rewrites. They can also enforce query budgets and attach authorization-derived metadata filters before retrieval.

Open AWS Lambda →

AWS Step Functions

Step Functions can orchestrate conditional rewriting, parallel subquery execution, result aggregation, and fallback paths. Its workflow controls help bound retries and timeouts, but the transformation logic resides in invoked models or application tasks.

Open AWS Step Functions →

Amazon OpenSearch Service

OpenSearch Service can execute lexical and vector searches over rewritten queries and combine retrieval signals through supported hybrid-search and scoring capabilities. Index configuration, filtering, score normalization, and candidate limits must be tuned alongside rewriting.

Open Amazon OpenSearch Service →