Ambiguity Resolution via Decomposition Prompt

This prompt is for search relevance engineers and RAG architects who need to handle ambiguous user queries before they hit a retrieval index. The job-to-be-done is detecting terms or phrases in a single user query that have multiple plausible meanings, then generating a separate set of disambiguated sub-questions for each interpretation. The ideal user is someone who already has a working retrieval pipeline and is now hardening it against a common failure mode: the user asks about 'jaguar speed,' and the system doesn't know whether to retrieve documents about animals, cars, or a vintage operating system. This prompt is not a general-purpose query rewriter. Do not use it when the query is already unambiguous, when you need a single best-guess expansion, or when the downstream system cannot handle multiple parallel retrieval branches.

The prompt requires the original user query, a description of the retrieval corpus or domain, and an output schema that captures each interpretation as a named cluster with its own sub-questions and a confidence score. You should wire this into a pre-retrieval stage where the output feeds a branching retrieval step: each interpretation cluster triggers its own set of searches, and the results are either merged with interpretation labels or routed to a disambiguation follow-up with the user. The confidence score is critical for deciding whether to run all branches silently or to surface the ambiguity to the user for clarification. A low-confidence interpretation cluster (below 0.6, for example) might be dropped or flagged for human review in high-stakes domains like legal or clinical search.

Before deploying this prompt, build a small eval set of ambiguous queries with known interpretations and verify that the model detects all plausible meanings without over-generating spurious ones. Common failure modes include missing a rare but valid interpretation, collapsing two distinct meanings into one cluster, or assigning high confidence to a hallucinated interpretation that has no corpus support. If your retrieval corpus is narrow and domain-specific, provide that domain context in the prompt to constrain the interpretation space. After retrieval, consider a downstream verification step that checks whether the retrieved documents actually support each interpretation before presenting results to the user.

This prompt template is the core of the ambiguity resolution workflow. It takes a user query that contains terms with multiple possible meanings—such as homonyms, domain collisions, or underspecified references—and produces a structured decomposition that separates each interpretation into its own set of sub-questions. The output includes a confidence score for each interpretation, allowing downstream retrieval logic to prioritize, merge, or present clarification options to the user before executing expensive search operations.

textCopy
You are an ambiguity detection and query decomposition specialist. Your job is to analyze a user query, identify terms or phrases that have multiple plausible interpretations, and generate separate sets of disambiguated sub-questions for each interpretation.

## INPUT
User Query: [QUERY]
Domain Context: [DOMAIN_CONTEXT]

## INSTRUCTIONS
1. Identify every term or phrase in the query that could reasonably be interpreted in more than one way within the given domain context.
2. For each ambiguous term, list the plausible interpretations. An interpretation is plausible if a reasonable user in this domain could intend it.
3. Generate a set of interpretations by combining the plausible meanings. Each interpretation set represents one coherent reading of the entire query.
4. For each interpretation set, generate 2-5 sub-questions that, when answered, would fully resolve the query under that interpretation. Each sub-question must be independently retrievable.
5. Assign a confidence score between 0.0 and 1.0 to each interpretation set, representing how likely this reading matches the user's original intent. Scores across all interpretation sets must sum to 1.0.
6. If the query has only one clear interpretation, return a single interpretation set with a confidence of 1.0 and explain why no ambiguity was detected.

## CONSTRAINTS
- Do not invent interpretations that are not supported by the query text and domain context.
- Sub-questions must be self-contained and not depend on answers from other sub-questions within the same interpretation set.
- Use the exact terminology from each interpretation to make sub-questions precise.
- If the domain context is insufficient to disambiguate, note this in the ambiguity_notes field.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "original_query": "string",
  "ambiguous_terms": [
    {
      "term": "string",
      "interpretations": ["string"]
    }
  ],
  "interpretation_sets": [
    {
      "id": "string",
      "reading": "string",
      "confidence": number,
      "sub_questions": [
        {
          "id": "string",
          "question": "string",
          "target_evidence_type": "fact|definition|procedure|comparison|list"
        }
      ]
    }
  ],
  "ambiguity_notes": "string"
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adapt this template by populating [DOMAIN_CONTEXT] with a description of the system's knowledge scope—such as 'enterprise HR policies' or 'programming language documentation'—to constrain plausible interpretations. The [EXAMPLES] placeholder should contain 2-3 few-shot demonstrations showing queries with genuine ambiguity and their correct decompositions. Set [RISK_LEVEL] to 'low', 'medium', or 'high' to adjust the model's caution; for high-risk domains like healthcare or legal, add an explicit instruction to flag interpretations that could cause harm if wrong. After generating the decomposition, validate the output JSON against the schema before passing interpretation sets to your retrieval layer. If the top confidence score is below 0.6, route the query to a clarification prompt that asks the user to pick the intended meaning rather than executing low-confidence retrievals.

The Ambiguity Resolution via Decomposition Prompt is designed to sit before your primary retrieval step. When a user query enters the system, this prompt acts as a pre-retrieval classifier and expander. It detects whether the query contains ambiguous terms—entity collisions, domain-specific jargon with multiple meanings, or underspecified constraints—and, if so, generates multiple sets of disambiguated sub-questions, one for each plausible interpretation. The downstream harness then decides whether to run all interpretation sets in parallel, present the user with a clarifying question, or route based on confidence scores. This prompt is not a retrieval step itself; it produces structured metadata that controls how retrieval executes.

Integration pattern: Wire this prompt into a pre-retrieval service that receives the raw user query and any available session context. The model call should use a low-latency model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) because this step adds latency before the main retrieval. The output must be parsed as strict JSON with a schema that includes: is_ambiguous (boolean), interpretations (array of objects with interpretation_label, confidence [0-1], and sub_questions [array of strings]), and original_query. If is_ambiguous is false, the harness passes the original query directly to retrieval. If true, the harness checks the highest confidence score: above a threshold (e.g., 0.7), it may auto-execute the top interpretation's sub-questions; below that, it should surface the interpretations to the user for disambiguation. Validation: Before routing, validate that each interpretation has at least one sub-question, that confidence values are within [0,1], and that no interpretation label is empty. Reject malformed outputs and retry once with a stricter schema reminder. Logging: Log the original query, the ambiguity flag, the number of interpretations, and the chosen routing path. This data is critical for tuning the confidence threshold and identifying query patterns that cause false positives or missed ambiguities.

Failure modes to handle in the harness: (1) The model fails to detect ambiguity when it exists—mitigate by maintaining a shadow evaluation set of known-ambiguous queries and periodically running them through the prompt to check recall. (2) The model over-decomposes a clear query into unnecessary sub-questions—mitigate by setting a minimum confidence threshold for the is_ambiguous flag and by capping the number of interpretations (e.g., max 5). (3) The generated sub-questions drift from the original intent—mitigate by including a post-retrieval evaluation step that checks whether retrieved evidence from each sub-question set is relevant to the original query. Tool integration: If your system has access to entity resolution APIs or knowledge graph lookups, pass resolved entity IDs as additional context into this prompt to reduce false ambiguity detections. Human review: For high-stakes domains (legal, medical, financial), always route ambiguous queries with confidence below 0.9 to a human-in-the-loop review queue before executing retrieval. Never auto-resolve ambiguity when the cost of wrong retrieval is high.

Next steps after implementation: Once the harness is live, monitor the ratio of ambiguous to unambiguous queries, the distribution of confidence scores, and the downstream retrieval quality metrics (recall@k, answer faithfulness) for queries that went through the disambiguation path versus those that didn't. Use this data to tune the confidence threshold and to build a regression test suite of ambiguous queries with expected interpretations. Avoid the temptation to remove the human-in-the-loop path prematurely—ambiguity resolution is a long-tail problem, and edge cases will surface in production that no eval set captures.