Query decomposition is a technique that breaks a complex multi-part question into simpler sub‑queries, which are then processed sequentially or in parallel, improving retrieval accuracy by tackling each sub‑question individually.
Complex questions often require information from multiple sources or involve several conditions. Query decomposition splits the original question into smaller, more manageable sub‑queries. These sub‑queries can be executed sequentially (using the answer from one sub‑query to inform the next) or in parallel (aggregating independent answers). The approach mimics how a human would break down a complex problem, leading to more precise retrieval and better final answers.[reference:4][reference:5]
Sequential Decomposition: Sub‑questions are processed one after another, with each answer informing the next. Suitable for logical workflows.
Parallel Decomposition: Independent sub‑questions are processed simultaneously, reducing latency. Ideal for factual comparisons.
Agent-based Decomposition: Use a LangGraph agent to dynamically decide the decomposition and execution plan.
Self‑ask with Search: The LLM recursively asks itself sub‑questions and searches for answers until the original question is resolved.
Suppose you're building a simple FAQ bot with LangChain and a user asks, 'What are the pricing tiers and how do I upgrade my plan?' How would you decompose that question into sub‑queries before sending them to the vector store?
If you feed the whole multi‑part question directly into a single retriever and get no results, what steps would you take to break it down and improve retrieval?
You added query decomposition to your LangChain pipeline, but after deployment you notice that responses sometimes miss the second part of the user's request. Walk me through how you would debug the decomposition logic.
When deciding whether to split a question at punctuation versus using an LLM to generate sub‑queries, what trade‑offs would you consider for latency and relevance?
Design a LangChain component that automatically decomposes arbitrary user questions into optimal sub‑queries for a hybrid retriever (vector + keyword). What factors would you use to decide the number and granularity of sub‑queries, and how would you handle failures?
At scale, your decomposition step becomes a bottleneck. How would you redesign the system to maintain throughput while ensuring each sub‑query remains semantically meaningful?
Your organization is migrating from a monolithic retrieval system to a micro‑service architecture that includes a dedicated query‑decomposition service used by multiple LangChain applications. What architectural patterns would you employ to ensure consistency, versioning, and observability across teams?
Consider a legacy knowledge base that mixes structured data and unstructured docs. How would you evolve the query‑decomposition strategy to support both types without breaking existing clients, and what migration plan would you propose?