66 — Query Deconstruction / Expansion

Concept overview

Query deconstruction separates a compound question into answerable subquestions. Query expansion adds useful synonyms, abbreviations, or alternative phrasing to improve recall. They solve different problems: decomposition organizes dependencies, while expansion broadens the wording used to search. Both should remain traceable to the original request.

Unconstrained rewriting can change a date, erase a negation, invent an entity, or multiply searches without improving evidence. A retrieval planner should preserve hard constraints, cap fan-out, and distinguish exploratory terms from factual premises. The final answer must reconcile sub-results rather than concatenate potentially conflicting fragments.

Why it matters in production

Proof of concept

A prototype logs original questions and rewrites so an evaluator can identify intent drift.

Production

Production validates entities and constraints, caps subqueries, and tracks which evidence answers each original requirement.

Enterprise scale

At scale, cache safe expansions, allocate retrieval budgets by uncertainty, and evaluate multi-hop questions separately from simple lookups.

Architecture components

Intent parser

Extracts entities, dates, comparison dimensions, and hard constraints.

Retrieval planner

Chooses decomposition, expansion, or an unchanged query.

Budget controller

Caps subqueries, parallelism, and total retrieval cost.

Evidence matrix

Maps each requirement to retrieved supporting or conflicting passages.

Synthesis validator

Checks that the final response covers the original question without unsupported bridging claims.

The architecture, mapped

flowchart TD
 Q["Compare two retention policies"] --> P["Constraint-preserving planner"]
 P --> A["Policy A retention and exceptions"]
 P --> B["Policy B retention and exceptions"]
 A --> E["Evidence matrix"]
 B --> E
 E --> C["Resolve dates and contradictions"]
 C --> S["Answer original comparison"]

Runtime flow

1. 1

   Extract constraints

   Identify exact names, time periods, exclusions, and requested comparisons.

2. 2

   Choose transformation

   Decompose only when separate evidence needs exist; expand terminology when wording is the main obstacle.

3. 3

   Validate subqueries

   Check that each query retains relevant constraints and contributes a distinct evidence objective.

4. 4

   Retrieve within budget

   Run independent queries in parallel and dependent queries only after needed entities resolve.

5. 5

   Reconcile evidence

   Deduplicate passages and record missing or contradictory support by requirement.

6. 6

   Answer the original task

   Synthesize against the initial question and disclose unresolved portions explicitly.

Comparing regional retention rules

Records management · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A records team asks how two approved regional policies differ for the same document class.

The problem

One broad query retrieves general policy summaries but misses exceptions and effective dates.

Agent requirement

Build a comparison with separate support for each region and exception.

Architecture

A planner creates bounded region-specific queries and an evidence matrix keyed by retention, exceptions, and date.

Runtime

• The system retrieves each region’s active policy and exception section.
• A validator refuses to fill a missing comparison cell with a plausible model assumption.

Failure scenario

If a rewrite changes the document class, constraint validation rejects it before retrieval.

Operational impact

Measure requirement coverage, rewrite drift, and search fan-out; more queries are useful only when they close identifiable evidence gaps.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Rewriting every simple query

Use transformation only when evaluation shows benefit.

Unlimited recursive decomposition

Set depth, subquery, and token budgets.

Treating subanswers as independent truth

Reconcile sources and effective dates before synthesis.

When to choose this pattern

Choose it when

• Use for comparisons and multi-part evidence questions.
• Use when domain abbreviations reduce lexical recall.
• Use when retrieval misses can be traced to query wording.

Avoid it when

• Avoid transformations for exact identifiers already retrieving correctly.
• Do not let expansion modify authorization scope.
• Avoid decomposing inseparable mathematical or causal claims into unsupported pieces.

Architecture checklist

• Preserve hard constraints structurally.
• Limit subquery count and recursion.
• Record original-to-rewrite mappings.
• Deduplicate expanded results.
• Track evidence per requirement.
• Evaluate intent drift and coverage together.

Related concepts

• 2 — Directed Acyclic Graphs (DAGs)
• 13 — Sub-Goal Generation
• 62 — Hybrid Search (Dense + Sparse)
• 65 — Re-ranking (Cohere/Cross-Encoders)
• 67 — Graph RAG / Knowledge Graphs
• 74 — Hypothetical Document Embeddings (HyDE)

Primary references

• Milvus: Multi-vector hybrid search
• Precise Zero-Shot Dense Retrieval without Relevance Labels