RAG Answer Faithfulness Gate Prompt

This prompt is for teams shipping search-augmented generation (RAG) features who need an automated, binary gate to verify that generated answers are faithful to the retrieved source material. The primary job-to-be-done is preventing hallucinated or unsupported statements from reaching end users by checking every sentence in a model's answer against the provided evidence. The ideal user is an AI engineer, evaluation lead, or platform developer embedding this check into a CI/CD pipeline, a pre-release QA step, or a real-time guardrail before a response is returned to the user. You should use this prompt when your application's risk profile demands a hard go/no-go signal per sentence, not just a floating-point faithfulness score that requires a human to interpret a threshold.

This gate is designed for scenarios where the retrieved context is the single source of truth for the answer. It works best when the input evidence is a set of discrete, chunked passages with stable identifiers. The prompt requires a clear [INPUT] containing the user's question, the model's [ANSWER], and a [RETRIEVED_CONTEXT] array with source IDs. It produces a structured [OUTPUT] with a binary faithful verdict per sentence and a citation mapping. Do not use this prompt when the answer is expected to synthesize information across many documents without direct quotation, when the task is creative generation, or when the user has explicitly asked for an opinion or analysis that goes beyond summarization. It is also inappropriate for evaluating multi-turn conversations where faithfulness depends on dialogue history not present in a single context window.

Before deploying this gate, you must calibrate it against human judgments on your specific data distribution. The prompt is sensitive to the granularity of sentence splitting and the definition of 'supported' versus 'inferred.' A common failure mode is flagging reasonable paraphrases as unfaithful because the wording differs from the source. Another is missing cross-sentence contradictions where two individually faithful sentences become unfaithful when combined. Your implementation should include a validation harness that logs every unfaithful verdict with the specific source evidence that was checked, enabling rapid human review of edge cases. For high-stakes domains like healthcare or finance, this gate should be a signal for human review, not an automatic block, until you have measured and accepted its false-positive and false-negative rates on your production traffic.

The following prompt template is designed to be wired directly into a RAG evaluation pipeline. It instructs the model to act as a strict, evidence-only judge, decomposing a generated answer into individual claims and verifying each against the provided source context. The output is a structured JSON object containing a binary faithful verdict for each sentence, along with the specific evidence used or a flag for unsupported inference. This template is not a suggestion; it is a contract. The placeholders must be populated by your application before the prompt is sent to the model.

textCopy
You are a strict faithfulness auditor for a Retrieval-Augmented Generation (RAG) system. Your sole task is to verify if every factual claim in a generated answer is directly supported by the provided source context. You must not use any outside knowledge.

**INPUT**
[USER_QUESTION]

**SOURCE CONTEXT**
[RETRIEVED_CONTEXT]

**GENERATED ANSWER**
[GENERATED_ANSWER]

**TASK**
1.  Break the GENERATED ANSWER down into individual, verifiable factual sentences.
2.  For each sentence, determine if it is fully supported by the SOURCE CONTEXT.
3.  A sentence is 'faithful' only if all its factual content can be directly inferred from the SOURCE CONTEXT without adding any outside information.
4.  A sentence is 'unfaithful' if it introduces new facts, contradicts the SOURCE CONTEXT, or makes an unsupported inference.

**OUTPUT_SCHEMA**
You must respond with a valid JSON object conforming to this exact schema:
{
  "overall_faithful": boolean, // true only if ALL sentences are faithful
  "sentence_verdicts": [
    {
      "sentence": string, // the exact sentence from the GENERATED ANSWER
      "faithful": boolean, // true or false
      "evidence": string | null, // the direct quote from SOURCE_CONTEXT that supports the sentence, or null if unfaithful
      "failure_reason": string | null // if unfaithful, a brief explanation (e.g., 'contradiction', 'unsupported_inference', 'new_fact'). null if faithful.
    }
  ]
}

**CONSTRAINTS**
- If the GENERATED ANSWER is empty or states it cannot answer the question, `overall_faithful` must be true and `sentence_verdicts` must be an empty array.
- If the SOURCE_CONTEXT is empty, all factual sentences in the GENERATED ANSWER must be marked as unfaithful.
- Do not penalize stylistic choices, grammar, or fluency. Only check factual alignment.
- If a sentence is a direct quote from the SOURCE_CONTEXT, it is faithful.

To adapt this template, replace the square-bracket placeholders with your application's data. [USER_QUESTION] should be the original query, [RETRIEVED_CONTEXT] the raw text chunks from your vector store or search index, and [GENERATED_ANSWER] the final string produced by your LLM. The OUTPUT_SCHEMA is critical for downstream automation; your application code should parse this JSON to log verdicts, trigger retries, or flag answers for human review. For high-stakes domains, always log the failure_reason and evidence fields to create an audit trail that justifies why an answer was blocked or accepted.

The RAG Answer Faithfulness Gate is designed as a synchronous pre-release check in a CI/CD pipeline or an asynchronous guard in a streaming application. In a CI/CD pipeline, the gate runs after answer generation and before the response is returned to the user or committed to a dataset. The prompt expects a generated answer and the retrieved context that was used to produce it. You must split the answer into individual sentences before calling the gate, as the prompt operates at the sentence level. The output is a JSON object mapping each sentence to a faithful or unfaithful verdict with a specific citation or a reason for the failure. This binary structure makes it straightforward to integrate with automated release gates: if any sentence is marked unfaithful, the entire answer is blocked, flagged for review, or sent to a repair loop.

For a CI/CD integration, wrap the prompt call in a function that parses the JSON output and enforces a strict pass/fail policy. A typical harness in Python would: (1) split the answer into sentences using a reliable sentence tokenizer like nltk.sent_tokenize; (2) call the LLM with the prompt template, passing the sentence list and the retrieved context; (3) parse the JSON response and validate that every sentence from the input is present in the output; (4) check for any unfaithful verdicts. If any sentence fails, the harness should log the full payload—including the answer, context, and gate output—to an observability system and either block the release or route the answer for human review. For streaming applications, you can run the gate on the complete answer after the stream ends, or on buffered chunks if latency allows. In high-throughput systems, consider batching multiple answers into a single gate call to reduce API overhead, but ensure the prompt's output schema can handle an array of answer objects.

Validation and retries are critical because the gate itself can produce malformed JSON or miss sentences. Implement a JSON schema validator that checks for the required structure: a list of objects, each with sentence_index, sentence_text, verdict, and evidence. If validation fails, retry up to two times with a stricter prompt variant that emphasizes JSON-only output. If the gate consistently fails on the same input, log it as a gate evaluation failure—distinct from a faithfulness failure—and escalate to a human reviewer. For high-risk domains like healthcare or legal applications, always route unfaithful verdicts to a human review queue. The gate's output provides the specific sentence and the missing or contradictory evidence, which gives the reviewer a clear starting point. Never automatically rewrite or regenerate an answer that fails the faithfulness gate without human approval in regulated contexts.

Model choice matters for this gate. Use a model with strong instruction-following and JSON output capabilities, such as gpt-4o or claude-3.5-sonnet. Avoid smaller or older models that may struggle with the structured output format or hallucinate citations. If cost is a concern, you can use a faster, cheaper model for the initial answer generation and reserve the more capable model for the faithfulness gate. Tool use is not required for this prompt, as it operates entirely on provided text. However, if your RAG system uses multiple retrieval sources, ensure all source text is included in the [CONTEXT] placeholder, clearly labeled by source. The gate cannot verify faithfulness against sources it cannot see. Finally, integrate the gate's pass/fail signal into your CI/CD dashboard with metrics on faithfulness pass rate, failure reasons, and gate evaluation errors. This visibility lets you detect retrieval degradation, prompt drift, or model behavior changes before they impact users.