How would you design retrieval for queries containing multiple intents?
- 1 min — why one embedding averages intents.
- 2 min — classify → decompose → parallel retrieve → merge with attribution.
- 2 min — dependent sub-queries and agentic retrieval.
- 1 min — coverage check and partial abstention.
Decompose. A single embedding of "compare the data-retention rules in Germany and Japan and tell me which is better for enterprise customers" averages three intents and lands between all of them. Use an LLM to split into sub-queries, retrieve for each independently, then merge with per-intent attribution so the generator knows which evidence answers which part.
Reserve a context budget per sub-query rather than taking a global top-k — otherwise one sub-query with strong matches crowds out the others entirely, and the answer silently drops a third of the question.
- Classify first. Most queries are single-intent. Running decomposition on everything doubles latency and cost for nothing. Gate it behind a cheap classifier.
- Handle dependent sub-queries. "What's the policy in the country where we have the most customers?" needs sequential retrieval, not parallel. That's agentic RAG and it has a different latency profile.
- Verify coverage. Check each sub-query got evidence before generating; a partial answer presented as complete is worse than an admission of partial coverage.
- Org scope. Decomposition is a shared query-understanding service owned by the platform, not re-implemented per product; each product supplies its own labelled multi-intent examples for the classifier.
What the answer sounds like at each level
Split the question into parts with an LLM and search for each part separately.
Gates decomposition behind a classifier, retrieves sub-queries in parallel with per-intent context budgets, and attributes evidence to each part.
Separates independent from dependent sub-queries (parallel vs agentic), verifies coverage before generation, and runs decomposition as a shared service with per-product eval sets.
Follow-ups the interviewer will push
1Decomposition adds 600ms. How do you claw it back?
Use a small fast model (or a fine-tuned classifier) for the gate so single-intent queries (typically 80–90% of traffic) skip it; run sub-query retrievals in parallel; and start retrieval for the original query in parallel with decomposition, using it if the classifier says single-intent.
2One sub-query returns nothing relevant. What does the answer say?
Answer the covered parts and say explicitly which part had no supporting evidence — partial abstention. Never let the generator fill the gap from parametric knowledge without marking it.
Red flags interviewers listen for
- Decomposes every query regardless of intent count.
- Uses a single global top-k across sub-queries.
- Runs dependent sub-queries in parallel.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Mechanism | Explains why a single embedding fails multi-intent queries. |
| Cost control | Gates decomposition and budgets context per sub-query. |
| Correctness | Verifies coverage and handles dependent sub-queries sequentially. |
Sources
- Least-to-Most Prompting Enables Complex Reasoning in Large Language Models — Zhou et al., 2022paper
- ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022paper