Confidence Score Extraction Prompt for RAG Answers

This prompt is for API developers and AI engineers who need a machine-readable, calibrated 0-1 confidence score alongside every RAG-generated answer. The primary job-to-be-done is not just to get an answer, but to get a structured payload that quantifies the model's certainty, flags evidence sufficiency, and breaks down the sources of uncertainty. This is essential for any system where downstream logic—such as routing to a human, triggering a fallback model, or displaying a UI warning—depends on a reliable confidence signal rather than a fluent but potentially overconfident text response.

Use this prompt when you are building a production RAG system in a high-stakes domain like healthcare, legal, finance, or compliance, where a wrong answer presented with high confidence is worse than no answer. It is ideal when you need to log confidence scores for audit trails, perform A/B tests on retrieval quality, or implement a circuit breaker that halts responses below a certain threshold. The required context for this prompt includes the user's query, the full set of retrieved documents, and a clear output schema definition. Do not use this prompt for simple Q&A over static FAQs or in low-stakes, consumer-grade chatbots where the operational overhead of parsing a structured confidence payload outweighs the risk of an unqualified answer.

Before integrating this prompt, you must define your confidence thresholds and the actions they trigger. A score of 0.8 might mean 'auto-respond,' while 0.5 might mean 'show answer with a caveat banner,' and 0.3 might mean 'route for human review.' The prompt is designed to be a single, auditable step in your pipeline. The next step is to pair it with a validation harness that checks the output schema, normalizes scores across different model versions, and alerts on drift. Avoid using this prompt as a standalone quality gate without a regression test suite; its value is realized when its structured output controls product behavior and feeds into your observability stack.

The following prompt template is designed to be inserted after your RAG system has retrieved context and generated an initial answer. It instructs the model to act as a strict evaluator, producing a machine-readable JSON payload that decomposes uncertainty into actionable fields. This is not a prompt for generating the answer itself; it is a post-generation audit step that forces the model to confront evidence gaps, source conflicts, and factual grounding before the answer reaches a user or downstream system.

textCopy
You are a confidence evaluation engine for a Retrieval-Augmented Generation (RAG) system. Your sole task is to assess a generated answer against the provided retrieved context and output a structured JSON payload. Do not modify the answer. Do not generate a new answer. Only evaluate.

## INPUT
- Generated Answer: [GENERATED_ANSWER]
- User Query: [USER_QUERY]
- Retrieved Contexts: [RETRIEVED_CONTEXTS]

## EVALUATION RULES
1. **Factual Grounding**: For every factual claim in the Generated Answer, determine if it is directly supported, partially supported, or contradicted by the Retrieved Contexts. A claim is unsupported if no context addresses it.
2. **Evidence Sufficiency**: Assess whether the Retrieved Contexts collectively contain enough information to fully answer the User Query. Flag missing entities, time periods, or quantitative data.
3. **Source Conflict**: Identify any direct contradictions between different Retrieved Contexts. If conflicts exist, note the conflicting sources and the nature of the disagreement.
4. **Speculation Check**: Identify any statements in the Generated Answer that appear to be inferred, generalized, or reasoned beyond the explicit text of the Retrieved Contexts.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with the following structure. No markdown fences, no explanatory text.
{
  "confidence_score": <float between 0.0 and 1.0>,
  "score_rationale": "<brief explanation of the primary factors driving the score>",
  "evidence_sufficiency": {
    "is_sufficient": <boolean>,
    "missing_information": ["<list of specific missing facts or entities>"]
  },
  "source_conflicts": [
    {
      "claim": "<the disputed claim>",
      "source_a": "<source identifier or excerpt>",
      "source_b": "<conflicting source identifier or excerpt>",
      "nature": "<direct contradiction | temporal inconsistency | definitional conflict>"
    }
  ],
  "unsupported_claims": ["<list of claims from the Generated Answer with no contextual support>"],
  "speculation_flags": ["<list of statements that appear to be inferred rather than extracted>"],
  "recommended_action": "<publish | append_caveat | human_review | suppress>"
}

## SCORING GUIDELINES
- **1.0**: All claims are directly supported by consistent, sufficient context. No speculation or conflicts.
- **0.8-0.99**: Minor omissions or a single partially supported claim. No conflicts.
- **0.5-0.79**: Multiple partially supported claims, minor conflicts, or clear evidence gaps that don't invalidate the core answer.
- **0.2-0.49**: Major evidence gaps, significant unsupported claims, or unresolved source conflicts.
- **0.0-0.19**: The answer is contradicted by evidence, entirely speculative, or the context is irrelevant to the query.

## CONSTRAINTS
- Do not hallucinate source identifiers. Use exact text excerpts from the Retrieved Contexts.
- If the Generated Answer is empty or a refusal, set confidence_score to 0.0 and recommended_action to "suppress".
- The missing_information array must be empty if is_sufficient is true.

To adapt this template, replace the square-bracket placeholders with your application's runtime variables. [GENERATED_ANSWER] should be the raw text output from your primary generation step. [RETRIEVED_CONTEXTS] should be a formatted string containing each retrieved chunk with its source identifier, such as [Source: doc_42.md] The text of the chunk.... The output schema is the contract your application code should validate against. If the model returns malformed JSON, implement a retry with the error message fed back into the [CONSTRAINTS] block, or route to a simpler classification prompt as a fallback. For high-stakes domains, the recommended_action field should be wired to a human review queue, not used for automatic suppression without oversight.

Integrating the confidence score extraction prompt into a production RAG system requires treating it as a structured API call, not a free-text generation step. The prompt expects a [QUERY] and [RETRIEVED_CONTEXT] as inputs and must return a strict JSON payload containing a confidence_score (0-1), evidence_sufficiency flags, and an uncertainty_breakdown. The application layer is responsible for enforcing this contract. Before calling the model, validate that the retrieved context is not empty and has been deduplicated. After receiving the response, run a schema validator that checks for required fields, correct types, and score range compliance. If validation fails, implement a retry loop with a maximum of two attempts, appending the validation error to the prompt as a correction instruction. For high-stakes domains such as healthcare or legal, route any answer with a confidence score below your calibrated threshold to a human review queue before the answer reaches the end user.

Model choice significantly impacts score calibration. Proprietary models like GPT-4o and Claude 3.5 Sonnet produce more stable confidence distributions out of the box, but open-weight models such as Llama 3.1 70B require a calibration harness. Build a normalization layer that maps raw model scores to observed accuracy rates using a held-out calibration dataset of 200-500 query-context-answer triples with known ground truth. Store these calibration curves per model version and update them when you change prompts or models. For latency-sensitive applications, consider running the confidence extraction prompt in parallel with the answer generation prompt, using the confidence score as a post-hoc gate rather than a pre-generation blocker. Log every confidence score alongside the query hash, model version, prompt version, and final user-facing outcome to enable drift detection and A/B testing of prompt changes.

Avoid treating the confidence score as a standalone safety mechanism. A high score does not guarantee correctness, and a low score does not always indicate hallucination. Combine the score with other signals: citation verification, factuality checks, and user feedback loops. Implement a monitoring dashboard that tracks the distribution of confidence scores over time, alerting if the mean score shifts by more than 0.1 standard deviations or if the abstention rate changes significantly. When deploying to production, start with a conservative threshold that routes more answers to human review, then adjust based on observed accuracy and business risk tolerance. Never expose raw confidence scores to end users without contextual framing—a score of 0.8 means different things in different domains, and users will misinterpret numeric certainty.