Query rewriting, multi-query retrieval, and query decomposition

Overview

• Query rewriting restates a request for search, often resolving references from conversation.
• Multi-query retrieval searches alternative formulations.
• Query decomposition splits a compound question into smaller questions that may require separate evidence.

Why this matters

Users say “what about that one?” or combine several issues in one sentence, which can produce weak retrieval.

An everyday example

A librarian translates a vague question into searchable terms and checks two chapters for a two-part question.

A technical example

“Does it cover flooding and how do I report it?” becomes an applicability lookup, a coverage-evidence search, and a reporting-procedure search.

How it works

1. Read the original request and trusted context
2. Create bounded rewrites/subquestions
3. Preserve identifiers
4. Search
5. Merge and deduplicate
6. Answer the original question.

Architecture and flow

Original query → rewrite/subquestions → bounded parallel retrieval → merged evidence.

The insurance assistant example

Resolve “my policy” from authenticated account data, not from a model guess.

When to use it

Conversational follow-ups, vocabulary mismatch, and compound evidence questions.

When to avoid it

Exact ID queries may become worse if rewritten. Avoid uncontrolled multi-query fan-out.

Interview answer

“These methods improve search formulation and coverage. I keep the original intent and identifiers and cap the number of retrieval calls.”

Benefits, trade-offs, and production considerations

A rewrite can introduce an unsupported assumption, such as changing “water damage” to “flood coverage.” Log original and rewritten queries, evaluate intent preservation, and keep user-provided facts distinct from inferred search terms.