Source-Answer Divergence Detection Prompt

This prompt is a post-generation guardrail designed for operators and QA engineers who need to detect semantic drift in Retrieval-Augmented Generation (RAG) pipelines. Unlike simple keyword-overlap checks, this prompt compares the generated answer to its source documents to catch subtle hallucinations—fabricated statistics, invented causal relationships, unauthorized tone shifts, or concepts entirely absent from the evidence. The primary job-to-be-done is automated quality monitoring: you run this prompt on a sample of production answers to detect when your system is 'making things up' in ways that evade string-matching heuristics. The ideal user is an MLOps engineer, a QA lead, or a product engineer responsible for maintaining factual accuracy before answers reach end users.

Use this prompt when you need a high-recall detector for semantic divergence. It excels at catching cases where the model introduces plausible-sounding but unsupported details—for example, claiming a product has a '30-day money-back guarantee' when the source only mentions a 'return policy,' or attributing a causal relationship ('the outage was caused by a database failure') when the evidence only notes a temporal correlation. The prompt is also effective for detecting unauthorized tone shifts, such as a marketing-style superlative ('best-in-class') injected into an answer sourced from neutral technical documentation. Do not use this prompt as a replacement for answer-grounding prompts during generation; it is a detection tool, not a prevention mechanism. It is also not suitable for real-time blocking of every response due to latency and cost—reserve it for offline batch auditing, pre-release gating, or sampling-based production monitoring.

Before implementing this prompt, ensure you have a reliable mechanism for passing both the generated answer and the full set of source documents as context. The prompt's effectiveness depends on the completeness of the evidence provided. If your retrieval pipeline already drops relevant documents, the divergence detector will flag legitimate synthesis as hallucination. Pair this prompt with an evidence sufficiency gate to verify that the context is adequate before running divergence detection. For high-stakes deployments, route flagged outputs to a human review queue rather than auto-blocking, as the model may occasionally mark faithful paraphrasing as divergence. The next section provides the copy-ready prompt template you can adapt to your specific divergence taxonomy and severity thresholds.

This prompt template is designed to be pasted directly into your evaluation harness or LLM orchestration layer. It instructs the model to act as a divergence auditor, comparing a generated answer against its source documents to identify concepts, tone, or details present in the answer but absent from the evidence. The output is a structured JSON report suitable for automated gating, logging, or triggering a human review queue. Replace every square-bracket placeholder with your actual data before execution.

textCopy
You are a semantic divergence auditor for a RAG system. Your task is to compare a generated answer against its source documents and detect any divergence where the answer introduces concepts, tone, details, or implications absent from the provided evidence.

## INPUTS
**Generated Answer:**
[ANSWER]

**Source Documents (with IDs):**
[SOURCES]

## TASK
1. Decompose the generated answer into discrete claims.
2. For each claim, search the source documents for supporting evidence.
3. Flag any claim that introduces information not present in the sources.
4. Assess overall semantic divergence, including tone shifts, unsupported inferences, and fabricated details.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "divergence_detected": boolean,
  "divergence_severity": "none" | "minor" | "moderate" | "critical",
  "divergent_claims": [
    {
      "claim_text": string,
      "claim_span": [start_char_index, end_char_index],
      "divergence_type": "unsupported_concept" | "fabricated_detail" | "tone_shift" | "unsupported_inference",
      "explanation": string,
      "nearest_source_id": string | null
    }
  ],
  "overall_assessment": string
}

## CONSTRAINTS
- Only flag divergence where the answer clearly goes beyond the sources.
- Legitimate paraphrasing is NOT divergence.
- If the answer stays faithful to the sources, divergence_detected must be false and divergent_claims must be an empty array.
- Base every divergence flag on specific evidence gaps, not vague impressions.

After pasting this template, replace [ANSWER] with the full text of the generated answer and [SOURCES] with a structured list of source documents, each including a unique ID and the full passage text. For high-stakes deployments, route any output with divergence_severity of "moderate" or "critical" to a human review queue before the answer reaches end users. Log every divergence report alongside the prompt version, model, and timestamp to support drift analysis over time.

This prompt is designed to operate as a post-generation guardrail, sitting between the answer synthesis step and the user delivery step. It is not a real-time user-facing prompt; it is an internal evaluation step that compares the final generated answer against the retrieved source documents. The harness should call this prompt for every answer generated, or on a sampled subset for cost control, and use the structured output to decide whether to block, flag, or release the answer. The primary integration points are your RAG orchestrator (e.g., LangChain, LlamaIndex, a custom Python service) and your observability stack.

The harness should pass three inputs to the prompt: the full generated answer, the concatenated source passages used for generation, and a structured output schema. Use a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) because the divergence detection task requires nuanced semantic comparison. Set temperature=0 to minimize variability in the divergence verdict. The output schema should include at minimum: a divergence_score (0-1 float), a divergence_detected boolean, a list of divergent_spans with exact text from the answer, and a rationale string. Parse this JSON response in your application code. If divergence_detected is true and the score exceeds your threshold (start with 0.3 and tune based on your tolerance), route the answer to a human review queue or trigger a regeneration with stricter grounding instructions. Log every verdict, including the score, rationale, and source-answer pair, to your observability platform for drift analysis over time.

Validation and retry logic are critical because this prompt itself can fail. Wrap the call in a retry loop (max 3 attempts) that catches JSON parse errors, missing required fields, or malformed divergent_spans that don't match text in the answer. If the model returns a refusal or an explanation without the structured object, retry with a stricter system instruction that demands JSON output. If retries are exhausted, fail open or closed based on your risk posture: for high-stakes domains (healthcare, legal, finance), fail closed by routing the answer to human review. For lower-stakes applications, fail open but log the harness failure as a high-severity alert. Implement a latency budget: if the divergence check adds more than 2 seconds to your pipeline, consider running it asynchronously after delivering the answer, with a mechanism to retract or annotate the answer if divergence is later detected. Finally, build an eval set of 50-100 source-answer pairs with known divergence labels (including subtle semantic drift, tone shifts, and concept introduction) to calibrate your threshold and monitor harness performance over time.