Incomplete Query Disambiguation Prompt

This prompt is designed for search and retrieval systems that receive partial or ambiguous queries from users who are still typing. It generates candidate disambiguations, ranks them by likelihood given the session context, and decides whether to retrieve against the best candidate or wait for more input. Use this when your application sends queries to a vector database, search engine, or knowledge base on every keystroke and you need to reduce wasted retrieval calls, latency spikes, and irrelevant results caused by incomplete input. This prompt belongs in a pre-retrieval decision layer, not in the retrieval step itself.

The ideal deployment is a thin gateway function that intercepts every streaming input event before it hits your retrieval pipeline. The prompt expects the current partial query, the last N turns of conversation history, and any active session slots or filters. It returns a structured decision: action: "retrieve" with a disambiguated query string, or action: "wait" with a reason code. Wire the output into a conditional branch—if retrieve, pass the disambiguated query to your search endpoint; if wait, buffer the input and re-evaluate on the next keystroke event. Set a maximum wait budget (e.g., 500ms of silence or 3 consecutive wait decisions) to prevent indefinite stalling on genuinely ambiguous input.

Do not use this prompt when the retrieval cost is negligible, when the user has already submitted a complete query (e.g., on Enter), or when your system lacks session context to ground the disambiguation. It is also inappropriate for voice-first systems where endpointing is handled by a separate ASR layer—use the Voice Input Stream Disruption Recovery Prompt instead. Before shipping, evaluate against a dataset of partial-to-complete query pairs to measure premature retrieval rate, unnecessary wait rate, and disambiguation accuracy. Log every decision with the partial input, the chosen action, and the disambiguated query for observability. If your application operates in a regulated domain, route retrieve decisions with confidence below your calibrated threshold to a human review queue rather than executing them automatically.

This prompt template is designed for search and retrieval systems that receive partial or ambiguous queries mid-typing. It instructs the model to analyze the incomplete input against the current session context, generate plausible completions or disambiguations, rank them by likelihood, and produce a structured decision object. The output tells your application whether to retrieve against the best candidate now or wait for more user input, preventing premature and wasteful retrieval calls.

textCopy
You are a query disambiguation engine for a search system. Your job is to analyze an incomplete user query and decide whether to retrieve results now or wait for more input.

## SESSION CONTEXT
[SESSION_CONTEXT]

## INCOMPLETE QUERY
[INCOMPLETE_QUERY]

## INSTRUCTIONS
1. Analyze the incomplete query against the session context.
2. Generate up to [MAX_CANDIDATES] candidate completions or disambiguations.
3. For each candidate, assign a likelihood score between 0.0 and 1.0.
4. Determine whether the top candidate's likelihood exceeds the retrieval threshold of [RETRIEVAL_THRESHOLD].
5. If the top candidate exceeds the threshold, select it as the best query for immediate retrieval.
6. If no candidate exceeds the threshold, recommend waiting for more input.
7. If the query is fundamentally ambiguous even with context, flag it for clarification.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "decision": "retrieve" | "wait" | "clarify",
  "top_candidate": {
    "completed_query": "string",
    "likelihood": number,
    "rationale": "string"
  } | null,
  "all_candidates": [
    {
      "completed_query": "string",
      "likelihood": number,
      "rationale": "string"
    }
  ],
  "ambiguity_assessment": "string",
  "recommended_action": "string"
}

## CONSTRAINTS
[CONSTRAINTS]

To adapt this template, replace [SESSION_CONTEXT] with a structured summary of the current conversation state, prior queries, and any known user intent. Set [MAX_CANDIDATES] to a number that balances latency against coverage—three to five candidates is typical for real-time typing scenarios. [RETRIEVAL_THRESHOLD] should be calibrated against your eval dataset; start at 0.7 and adjust based on observed premature retrieval rates. The [CONSTRAINTS] placeholder can include domain-specific rules, forbidden query patterns, or safety policies. After pasting, validate that the model reliably outputs the exact JSON schema by running a schema validator in your application layer before acting on the decision. For high-stakes retrieval where wrong results could mislead users, add a human review step when the ambiguity_assessment indicates fundamental uncertainty or when the top candidate's likelihood falls in a gray zone between 0.5 and your threshold.

The Incomplete Query Disambiguation Prompt is designed to sit between the user's input stream and your retrieval system. It should be called on every partial input event—typically a keystroke pause or a streaming chunk boundary—before any expensive vector or keyword search is executed. The prompt's job is to decide whether the current partial query is worth retrieving against or whether the system should wait for more input. This decision gates downstream retrieval costs, so the implementation harness must enforce strict latency budgets and provide clear logging for each disambiguation decision.

Wire the prompt into your application as a pre-retrieval gate. When a partial input arrives, construct the prompt with the [PARTIAL_QUERY] placeholder set to the current input buffer and [SESSION_CONTEXT] populated with the last N turns of conversation or the user's recent activity. The model should return a structured JSON object containing a decision field (retrieve or wait), a disambiguated_query string (only populated when decision is retrieve), and a confidence score between 0.0 and 1.0. Validate this output strictly: if decision is retrieve but disambiguated_query is empty or malformed, treat it as a wait decision and log a schema violation. If confidence is below your configured threshold (start with 0.7 and calibrate from production data), override the decision to wait to prevent low-quality retrievals. Implement a short-circuit rule: if the partial query is fewer than 3 characters or contains only stop words, skip the model call entirely and default to wait.

For production resilience, wrap the model call in a retry policy with a maximum of 2 attempts and a 200ms timeout per attempt. If the model call fails or times out, fall back to a conservative wait decision and log the failure for observability. Log every decision—including the partial query, the model's output, the final gated decision, and the latency—to a structured logging system. This data is essential for calibrating your confidence threshold and identifying query patterns where the model consistently makes poor disambiguation choices. Avoid calling this prompt on every keystroke if your input rate exceeds 10 events per second; instead, debounce inputs with a 150ms window and send the latest buffer state. Finally, never use the disambiguated query to overwrite the user's original input in the session history; retain the original partial query for audit trails and use the disambiguated version only for the retrieval call.