TECHNIQUE
Retrieval & Grounding
Across five deployed systems, query transformation is implemented as a pre-retrieval or pre-execution step: operators rewrite, optimize, split, expand, route, or convert user questions before retrieval or structured query execution.
Put a query-transformation step between the user question and retrieval/execution: Uber uses a Query Optimizer, Dropbox delegates query construction to a specialized search agent, Wix divides complex questions into sub-questions, LinkedIn uses multi-query generation, and TraceIQ uses multi-step query expansion.
5 of 5 operators in the pool.Repair weak natural-language inputs before retrieval: Uber refines queries that lack context or are ambiguous; Dropbox rewrites queries for semantic matching and handles typos, synonyms, and implicit context.
2 of 5 operators in the pool.Break one user request into multiple retrieval instructions: Wix simplifies complex queries into smaller sub-questions; LinkedIn describes multi-query generation for transforming queries into actionable retrieval instructions; TraceIQ uses multi-step query expansion.
3 of 5 operators in the pool.Use the transformed query to narrow where retrieval runs: Uber’s Source Identifier processes the optimized query to choose a subset of policy documents and restrict search; LinkedIn routes queries to the most efficient knowledge graph or GraphQL backend.
2 of 5 operators in the pool.Transform natural-language questions into structured backend requests: LinkedIn has the LLM generate optimized Cypher queries for retrieval; Wix generates a structured API payload for Data Playground, which Cube translates into SQL.
2 of 5 operators in the pool.Keep query construction in a specialized component rather than the main planning/answering path: Dropbox’s main planning agent delegates query construction to a search agent; Uber separates Query Optimizer and Source Identifier from final answer generation; Wix separates Root, Validation, Divider, and Data Playground agents.
3 of 5 operators in the pool.Every observed operator transforms the user’s question before the final retrieval or execution step, rather than relying only on the raw user wording.
Operators differ on what the transformed query is meant to produce.
APPROACH 01
Produce better retrieval inputs over documents or indexed content: optimized queries, rewritten semantic queries, or expanded queries.
APPROACH 02
Produce executable structured retrieval or analytics requests: Cypher queries, API payloads, or SQL translated from a semantic model.
Operators differ on whether query transformation also selects the retrieval scope.
APPROACH 01
Transformation includes scope selection or routing: choose policy-document subsets or route to a knowledge graph/GraphQL backend.
APPROACH 02
Transformation focuses on rewriting, splitting, or expanding the query while retrieval is described separately through an index, vector DB, or hybrid retriever.
Ambiguous or under-specified user questions are a recurring reason for query transformation: Uber says Query Optimizer refines queries that lack context or are ambiguous, and Dropbox calls out typos, synonyms, and implicit context as query-rewriting edge cases.
Answer quality remains sensitive to the retrieved or supplied context: Uber frames accuracy and relevance as a significant challenge; Dropbox says precision in what is fed to the model is critical; Wix reports that an LLM may choose a completely unrelated dimension.
| Name | Kind | When | Maturity |
|---|---|---|---|
| LLM query rewriting on a fast model | pattern | conversational or underspecified queries need normalization before retrieval | commodity |
| Multi-query expansion | pattern | recall matters more than latency; fan out variants and merge | established |
| HyDE | pattern | short queries against long documents; embed a hypothetical answer instead | established |