Ambiguous Query Clarification Prompt Before Refusal

This prompt resolves query ambiguity before triggering a refusal. In RAG and evidence-grounded systems, a user query that is too vague, underspecified, or polysemous will fail to retrieve useful evidence. A premature refusal frustrates users and erodes trust. This prompt instructs the model to detect ambiguity, generate a targeted clarification question, and defer any refusal decision until the user disambiguates. Use this prompt when your system must distinguish between 'no evidence exists' and 'the query is too ambiguous to search.' It belongs in the clarification layer of a conversational AI pipeline, before retrieval, before answer generation, and before any refusal or abstention logic fires.

The ideal user is a conversational AI engineer or RAG pipeline architect who has observed false refusals in production logs. The required context includes the raw user query, the system's retrieval capability description, and optionally the previous turn in the conversation. This prompt is not a replacement for retrieval failure handling. Do not use it when the query is clear but the knowledge base genuinely lacks evidence—that scenario requires an evidence insufficiency refusal prompt instead. Do not use it when the user has already clarified the query in the same turn. Do not use it when latency constraints prohibit a clarification round-trip, such as in synchronous API responses where the caller cannot handle a follow-up question.

Before deploying, define the ambiguity detection threshold for your domain. A query like 'What about the report?' is unambiguously ambiguous and should trigger clarification. A query like 'What were Q3 earnings?' may be ambiguous if multiple companies are in context but clear if only one is active. Test with a golden set of ambiguous and unambiguous queries, measuring the clarification rate against human judgments. Monitor for over-clarification, where the model asks unnecessary questions and annoys users, and under-clarification, where it proceeds to retrieval with a fatally ambiguous query. Wire the prompt into your pipeline before the retrieval step, and ensure the clarification response is surfaced to the user as a conversational turn, not as an error. Log every clarification event to identify patterns in ambiguous queries that may indicate gaps in your retrieval design or user education.

This prompt template instructs the model to treat ambiguity as a recoverable state rather than a terminal failure. Instead of refusing to answer when a query is unclear, the model must generate a targeted clarification question that resolves the ambiguity. Refusal is deferred until the user fails to disambiguate after a configurable number of attempts. The template is designed to be placed in the system prompt or as a pre-retrieval instruction block in RAG pipelines where retrieval quality depends on query specificity.

textCopy
You are an assistant that answers questions using only retrieved evidence. Your primary directive is to avoid answering when the query is ambiguous, but you must attempt to resolve ambiguity before refusing.

## Ambiguity Resolution Protocol
1. Analyze the user's query for ambiguity. A query is ambiguous if it:
   - Contains pronouns without clear referents (e.g., "it," "they," "that one")
   - Uses vague terms that could map to multiple entities or concepts
   - Lacks necessary constraints (e.g., time range, location, domain, product name)
   - Could be interpreted in multiple materially different ways
2. If the query is ambiguous, do NOT refuse. Instead, generate exactly ONE clarification question that:
   - Identifies the specific ambiguity
   - Offers 2-3 concrete disambiguation options when possible
   - Is answerable in a single user response
   - Does not introduce new topics or assumptions
3. After receiving the user's clarification, re-evaluate. If still ambiguous, you may ask up to [MAX_CLARIFICATION_ROUNDS] total clarification questions.
4. Only refuse to answer when:
   - You have exhausted [MAX_CLARIFICATION_ROUNDS] without resolution
   - The user explicitly declines to clarify
   - The query remains fundamentally unanswerable even after disambiguation

## Refusal Format
When refusal is necessary, respond with:
"I'm unable to answer this question because [SPECIFIC_REASON]. [WHAT_WOULD_BE_NEEDED]."

## Clarification Format
When asking for clarification, respond with:
"I want to make sure I understand your question correctly. [SPECIFIC_AMBIGUITY_IDENTIFIED]. Could you clarify [SPECIFIC_CLARIFICATION_NEEDED]? For example: [OPTION_A], [OPTION_B], or [OPTION_C]?"

## Constraints
- Never guess the user's intent when the query is ambiguous
- Never retrieve evidence or generate an answer until ambiguity is resolved
- Do not ask clarification questions for queries that are specific but simply difficult
- Do not refuse prematurely when one round of clarification could resolve the ambiguity

To adapt this template, set [MAX_CLARIFICATION_ROUNDS] based on your user experience tolerance—2 is a safe default for most applications, while 1 is appropriate for low-friction chat interfaces. Replace the clarification and refusal format strings with your product's voice and tone guidelines. If your system uses function calling, wrap the clarification question in a structured output schema so the application layer can render it consistently. For high-stakes domains, add a [RISK_LEVEL] parameter that reduces [MAX_CLARIFICATION_ROUNDS] to zero and escalates directly to human review when risk is elevated. Test the prompt against a golden set of ambiguous queries to verify that clarification questions are specific and actionable, not generic or evasive.

This prompt is designed as a pre-retrieval gate or an early step in a conversational agent loop. Instead of immediately searching a knowledge base with an ambiguous query and risking irrelevant results or a premature refusal, the application should first call this prompt. The model's output is a structured decision: either a clarification question or a proceed signal. The application harness must parse this output and branch accordingly. If a clarification question is returned, it should be surfaced to the user, and the user's response should be appended to the original query before re-running the clarification check or proceeding to retrieval. If the proceed signal is returned, the application should use the disambiguated query for downstream retrieval and answer generation.

To implement this reliably, wrap the LLM call in a function that enforces a strict output contract. Define a JSON schema with two mutually exclusive fields: clarification_question (a string) and disambiguated_query (a string). Use structured output or tool-calling features to guarantee valid JSON. The application logic should then follow a simple rule: if clarification_question is not null, pause the workflow and ask the user; if disambiguated_query is not null, replace the original user input with this string and continue the RAG pipeline. Implement a retry loop with a maximum of 2-3 clarification rounds to prevent infinite loops with persistently ambiguous queries. After the limit is reached, fall back to a refusal prompt from the Evidence Insufficiency Refusal family, informing the user that the query could not be disambiguated. Log every clarification round, including the original query, the model's clarification question, and the user's response, to build a dataset for evaluating the prompt's precision and recall over time.

For model choice, a fast, cost-effective model like GPT-4o-mini, Claude Haiku, or Gemini Flash is appropriate for this classification and generation task, as it does not require deep reasoning. Set temperature=0 to ensure deterministic, repeatable decisions. Validation should check that the output contains exactly one of the two fields and that the disambiguated_query is substantially different from the original input if the proceed signal is given. In high-stakes domains, add a human review step in the clarification loop where a support agent can override the model's clarification question or manually disambiguate the query before retrieval. Avoid wiring this prompt directly into a customer-facing chatbot without first testing it against a golden set of ambiguous queries to measure the clarification rate and the quality of the generated questions.