Calibrated Uncertainty Expression Prompt for RAG Answers

This prompt is designed for customer-facing AI teams who need to generate answers from retrieved passages in a RAG (Retrieval-Augmented Generation) pipeline, but face a critical challenge: the evidence is often partial, ambiguous, or conflicting. The primary job-to-be-done is not just to answer a question, but to produce a response that honestly communicates the model's confidence level. The ideal user is an AI engineer or product developer building a system where user trust is paramount and a confident-sounding wrong answer is far more damaging than a well-explained 'I'm not sure.' You should use this prompt when your retrieval system returns a mix of relevant and tangential documents, or when the evidence supports multiple interpretations, and you need the model to calibrate its language accordingly.

To use this prompt effectively, you must provide a specific set of inputs. The [QUERY] is the user's original question. The [RETRIEVED_CONTEXT] is the raw, unsummarized text from your top-k retrieval results. Critically, you must also define an [UNCERTAINTY_PHRASING_TAXONOMY], which is a mapping of confidence bands (e.g., 'High Confidence', 'Moderate Confidence', 'Low Confidence', 'Insufficient Evidence') to specific, approved phrases the model is allowed to use. This ensures consistent uncertainty communication across all user interactions. Do not use this prompt for simple factoid lookups where a single retrieved passage definitively answers the question; in those cases, a standard RAG prompt with citation instructions is more efficient. Similarly, avoid this prompt when the user's query is a direct instruction to perform an action (like 'summarize this document'), as the uncertainty expression logic may interfere with task completion.

The primary constraint is that this prompt forces a trade-off between fluency and honesty. The model is instructed to prioritize calibrated uncertainty language over a smooth, authoritative tone. Before implementing, you must validate that your product stakeholders and user experience guidelines accept responses that include hedging, caveats, and explicit statements of low confidence. The next step is to pair this prompt with a rigorous evaluation harness that checks for phrasing consistency against your taxonomy and measures the correlation between the model's expressed uncertainty and the actual evidential support. A common failure mode is the model becoming overly cautious and expressing low confidence even when sufficient evidence exists, so your eval set must include clear-answer test cases to detect this over-refusal.

This prompt template instructs the model to answer a user query using only the provided retrieved passages, while expressing calibrated uncertainty when the evidence is incomplete, ambiguous, or insufficient. The template enforces a structured output schema that separates the answer from its confidence band, caveats, and evidence gaps. Use this template when you need consistent uncertainty phrasing across responses and want downstream systems to parse confidence signals programmatically.

textCopy
You are an assistant that answers questions using only the provided retrieved passages. Your answers must be faithful to the evidence and express calibrated uncertainty when the evidence is partial, ambiguous, or insufficient.

## INPUT

User Question:
[QUERY]

Retrieved Passages:
[PASSAGES]

## OUTPUT SCHEMA

Return a JSON object with the following fields:

{
  "answer": "string (the grounded answer, or a refusal if evidence is insufficient)",
  "confidence_band": "high" | "medium" | "low" | "insufficient",
  "caveats": ["string (list of specific limitations, hedging statements, or uncertainty qualifiers)"],
  "evidence_gaps": ["string (list of specific questions the evidence cannot answer)"],
  "supporting_passage_ids": ["string (IDs of passages that directly support the answer)"]
}

## CONFIDENCE BAND DEFINITIONS

- **high**: Multiple passages directly and consistently support the answer. No significant contradictions or gaps.
- **medium**: At least one passage supports the answer, but evidence is partial, indirect, or has minor inconsistencies.
- **low**: Evidence is weak, tangential, or only hints at the answer. Substantial inference required.
- **insufficient**: No passage provides usable evidence. Answer must be a refusal explaining what is missing.

## CONSTRAINTS

1. Never invent facts not present in the passages.
2. If confidence is "insufficient," set "answer" to a refusal explaining what evidence would be needed.
3. Every caveat must reference a specific limitation in the evidence, not a generic disclaimer.
4. Every evidence gap must describe a specific question the passages cannot answer.
5. If passages contradict each other, note the contradiction in caveats and downgrade confidence.
6. Do not use hedging language that implies certainty when evidence is weak.
7. Supporting passage IDs must reference only passages that directly support the claim made.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

Adaptation guidance: Replace [QUERY] with the user's question and [PASSAGES] with the retrieved context, formatted as numbered or ID-tagged passages. Populate [EXAMPLES] with 2-4 few-shot demonstrations showing correct confidence band assignment and caveat phrasing for your domain. Set [RISK_LEVEL] to high for regulated or safety-critical domains to trigger additional refusal strictness and human-review escalation language. For production use, validate the output JSON against the schema before releasing responses to users, and log confidence band distributions to monitor drift in evidence quality over time.

Integrating the Calibrated Uncertainty Expression Prompt into a production RAG pipeline requires treating it as a structured component with defined inputs, outputs, and failure modes. The prompt expects a [QUERY] and a [RETRIEVED_PASSAGES] block, and it returns an answer with embedded uncertainty signals. In practice, you'll call this prompt after retrieval and before the response reaches the user. The application layer should assemble the retrieved passages, inject them into the prompt template, and parse the model's response to extract both the answer text and the uncertainty metadata (confidence band, caveats, evidence gaps). This parsed output can then drive downstream decisions: display the answer with appropriate visual confidence indicators, route low-confidence responses for human review, or trigger a refusal flow if the confidence falls below a defined threshold.

For a robust implementation, wrap the model call in a validation layer that checks the output structure before releasing it. At minimum, validate that the response contains a recognizable confidence band (e.g., 'high', 'medium', 'low', 'insufficient') and that any caveats or hedging language is present when the band is below 'high'. Use a schema validator or a secondary LLM call with a strict rubric to confirm that claims marked as uncertain are actually tied to specific evidence gaps in the retrieved passages. If validation fails, implement a retry loop with a maximum of two additional attempts, each time appending the validation error to the prompt as feedback. Log every attempt, the raw model output, the validation result, and the final decision (released, repaired, or escalated) for observability. For high-stakes domains, add a human review queue that intercepts any response with a 'low' or 'insufficient' confidence band before it reaches the end user.

Model choice matters here. The prompt relies on the model's ability to express nuanced uncertainty without hallucinating confidence. GPT-4, Claude 3.5 Sonnet, and similarly capable models handle this well, but smaller or older models may produce inconsistent uncertainty phrasing or overconfident answers. Test your chosen model against a golden dataset of queries with known evidence sufficiency levels, and measure both the accuracy of the confidence band assignment and the faithfulness of the caveats to the actual evidence gaps. If you observe drift in uncertainty expression over time, consider pinning a specific model version and adding an eval step that compares uncertainty phrasing against your approved taxonomy. The next step is to build a monitoring dashboard that tracks confidence band distribution, validation failure rates, and human review escalation volume, so you can detect when retrieval quality degrades or the model's uncertainty calibration shifts in production.