Clarification Request Prompt for Ambiguous Questions

This prompt is designed for a specific job-to-be-done: resolving user-facing ambiguity in a RAG assistant when the cost of a wrong answer is higher than the friction of a single clarification turn. The ideal user is an AI engineer or product developer building a copilot or chat assistant over a knowledge base where user questions can be interpreted in multiple, mutually exclusive ways. The required context is a user question that has already failed to produce a high-confidence answer from retrieved evidence, or where the retrieval results themselves reveal a fundamental ambiguity in the user's intent. The prompt's core mechanism is to identify the specific axis of ambiguity, explain why it matters for the answer, and offer 2-4 concrete, distinct options that force the user to resolve the uncertainty.

Concrete implementation requires strict gating. Before invoking this prompt, your application should check that the retrieved context does not already disambiguate the intent. If the top-ranked passages clearly support one interpretation, synthesize the answer directly. This prompt is not a replacement for better retrieval or query rewriting; it is a fallback for irreducible ambiguity. For example, a question like 'What are the fees?' in a banking RAG system is ambiguous between account maintenance fees, wire transfer fees, and overdraft fees. If the user's account type or recent activity in the conversation history doesn't resolve this, the prompt should generate options for each fee type. However, if the system policy requires immediate abstention for certain high-risk domains, do not use this prompt to solicit clarification on disallowed topics; instead, use a refusal prompt from the Safety Policy pillar.

Avoid this prompt when the question is a simple factual lookup that retrieval can answer with high confidence, when the ambiguity is trivial and any reasonable interpretation yields the same answer, or when the user is in a low-friction, exploratory mode where a best-guess answer with a confidence caveat is acceptable. Overusing clarification requests in a consumer chatbot, for instance, creates a frustrating, interrogative experience. The next step after deciding this prompt is appropriate is to wire it into your application's control flow: the model's output should be parsed as structured JSON, validated for mutually exclusive options, and rendered as a UI element like a set of tappable chips or quick-reply buttons that directly feed the user's choice back into the answer generation pipeline.

This prompt template instructs the model to detect ambiguity in a user's question and produce a single, targeted clarification request. Instead of guessing or answering incorrectly, the system identifies the specific dimension of ambiguity, explains why it matters for a correct answer, and offers 2-4 concrete, mutually exclusive options the user can select from. The template includes explicit rules for when to clarify versus when to abstain entirely, preventing the model from asking clarifying questions when the evidence is simply missing rather than ambiguous.

textCopy
You are a precise question-answering assistant with access to a knowledge base. Your primary directive is accuracy over speed. When a user's question is ambiguous, you must request clarification before answering. When the knowledge base lacks sufficient evidence to answer even after clarification, you must abstain.

## INPUT
User Question: [USER_QUESTION]
Conversation History: [CONVERSATION_HISTORY]
Retrieved Context: [RETRIEVED_CONTEXT]

## AMBIGUITY DETECTION RULES
A question is ambiguous if it contains any of the following:
- Underspecified entities (e.g., "the policy" when multiple policies exist in context)
- Temporal ambiguity (e.g., "recently" without a time window)
- Scope ambiguity (e.g., "all users" when the system has multiple user types)
- Comparative ambiguity (e.g., "better" without criteria)
- Pronoun reference ambiguity across conversation turns
- Multiple valid interpretations that would lead to materially different answers

A question is NOT ambiguous if:
- The knowledge base simply lacks the answer (this requires abstention, not clarification)
- The user is asking for an opinion or prediction outside the evidence
- The question is clear but the answer requires multi-step retrieval (proceed with retrieval)

## CLARIFICATION REQUEST FORMAT
When ambiguity is detected, produce a JSON response with this exact structure:
{
  "action": "clarify",
  "ambiguity_type": "[entity|temporal|scope|comparative|pronoun|multi_interpretation]",
  "ambiguous_element": "The specific phrase or term that is ambiguous",
  "clarification_question": "A single, clear question that resolves the ambiguity",
  "why_this_matters": "Brief explanation of how the answer changes based on the user's response",
  "options": [
    {"label": "Option A", "description": "What choosing this means for the answer"},
    {"label": "Option B", "description": "What choosing this means for the answer"}
  ],
  "default_assumption": "If you must proceed without clarification, state which interpretation you will assume and why"
}

## ABSTENTION RULES
Produce an abstention response when:
- The question is clear but no relevant evidence exists in [RETRIEVED_CONTEXT]
- The question requires information explicitly outside the knowledge base's scope
- The user has already clarified and the evidence is still insufficient

Abstention format:
{
  "action": "abstain",
  "reason": "Specific explanation of what information is missing",
  "partial_answer": "Any relevant information that CAN be provided with appropriate caveats",
  "suggested_next_step": "What the user could do to get an answer (e.g., rephrase, provide document, ask a different team)"
}

## ANSWER RULES (when no ambiguity exists)
- Ground every claim in [RETRIEVED_CONTEXT] with inline citations
- If [CONVERSATION_HISTORY] contains prior answers, do not contradict them without flagging the discrepancy
- If [CONVERSATION_HISTORY] contains a prior clarification, apply it to the current question

## CONSTRAINTS
- Ask at most ONE clarification question per response
- Never ask clarifying questions about things the context already disambiguates
- If the user ignores a clarification request and repeats the question, apply the [DEFAULT_ASSUMPTION] and answer with a caveat
- Do not fabricate options that aren't grounded in the retrieved context

Adaptation guidance: Replace [USER_QUESTION] with the current user message. [CONVERSATION_HISTORY] should contain prior turns formatted as User: ... Assistant: ... pairs, truncated to the last N turns based on your context budget. [RETRIEVED_CONTEXT] should contain the top-K retrieved passages with source identifiers. For high-stakes domains, add a [RISK_LEVEL] parameter that triggers mandatory abstention above a threshold. The JSON output schema can be extended with a confidence field for downstream routing logic. Test this prompt with ambiguous questions from your production logs before deploying—ambiguity detection boundaries vary by domain terminology.

The clarification request prompt is not a standalone component—it is a decision node in a larger RAG pipeline. Wire it as a pre-answer gate that fires when the system detects ambiguity before committing to a full answer. The typical flow: user message arrives, retrieval executes, the system assembles context, and then a lightweight ambiguity check (or direct invocation of this prompt) decides whether to answer, clarify, or abstain. If clarification is needed, the prompt produces a structured clarification question with concrete options. The user's response is then fed back into the pipeline as a new turn with the clarification context appended to the original question.

For production integration, wrap the prompt in a function that accepts [USER_QUESTION], [RETRIEVED_CONTEXT], and [CONVERSATION_HISTORY] as inputs. The output should be parsed as JSON with fields: action (one of clarify, answer, abstain), clarification_question (the text shown to the user), options (an array of 2-4 concrete choices), and ambiguity_reason (a short explanation of what is unclear). Validate this schema immediately after generation. If the model returns action: clarify but provides no options array, or returns action: answer without sufficient grounding in the retrieved context, reject the output and retry with a stricter constraint message. Log every clarification event with the original question, the ambiguity detected, and the options presented—this data is invaluable for improving retrieval precision and identifying knowledge base gaps.

Model choice matters here. Use a model with strong instruction-following and JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature low (0.0–0.2) to keep clarification options consistent across similar inputs. If your application has a human review queue for high-stakes domains, route any action: abstain output there immediately. For action: clarify outputs, consider a confidence threshold: if the model's logprob on the action token is below 0.85, escalate to human review rather than showing a potentially confusing clarification to the user. Implement a retry budget of 2 attempts for malformed outputs, then fall back to a safe default (a generic clarification like "Could you provide more detail about what you're looking for?") and flag the failure for investigation.

Avoid wiring this prompt directly into a customer-facing chatbot without testing against your actual retrieval pipeline. Common failure modes include: the model asking for clarification when the answer is clearly present in the retrieved context (over-clarification), offering options that are not actually answerable from your knowledge base (option hallucination), and failing to recognize that the user has already provided the disambiguating information in a prior turn. Build eval cases for each of these scenarios and run them as part of your prompt regression suite before deployment. If your system uses streaming responses, buffer the full clarification output before displaying it—partial clarification questions with incomplete option lists confuse users and break the interaction contract.