Source Linking for RAG Answers Prompt

This prompt is designed for RAG application developers who need to produce citation-aware answers where every sentence or factual claim is linked back to a specific retrieved passage. It operates after retrieval and answer generation, taking a generated answer and a set of source passages as input, and producing an annotated answer with inline citation markers plus a faithfulness verification report. Use this prompt when your application must show users exactly which source supports each part of an answer, when you need to catch unsupported claims before they reach the user, or when you are building audit-ready Q&A systems.

This prompt assumes you already have a generated answer and a set of retrieved passages. It does not perform retrieval, rewrite queries, or generate the initial answer. The ideal user is an engineering lead or developer integrating this into a RAG pipeline where the answer generation step is already complete. You should have a clear mapping of source passage IDs to their full text, and your answer should be a coherent block of text ready for annotation. The prompt works best when passages are self-contained and have stable identifiers that can survive downstream rendering.

Do not use this prompt when you need to generate the answer itself, when your retrieval step is unreliable or returns empty sets, or when your source passages are too long to fit in context alongside the answer. This prompt is also not a substitute for retrieval quality evaluation—if your retriever is returning irrelevant passages, source linking will surface those failures but won't fix them. For real-time chat applications with strict latency budgets, consider running this prompt asynchronously after the answer is shown, or use a smaller model for the linking step. In regulated domains, always route the verification report through human review before the annotated answer reaches end users.

This prompt template takes a generated answer and a set of retrieved source passages, then produces a version of the answer where every factual claim is linked to a specific source passage with an inline citation marker. It also runs a faithfulness verification step that checks whether each linked source genuinely supports the claim it's attached to. Use this when you need auditable, traceable answers in customer-facing RAG applications, compliance workflows, or any system where users need to verify where information came from.

codeCopy
You are a citation-linking specialist. Your job is to take a generated answer and a set of source passages, then produce a version of the answer where every factual claim is linked to a specific source passage with an inline citation marker. You must also verify that each linked source actually supports the claim it's attached to.

## INPUT

**Generated Answer:**
[ANSWER_TEXT]

**Source Passages:**
[SOURCE_PASSAGES]

Each source passage has an ID, title, and text. Format:
[SOURCE_ID]: [SOURCE_TITLE]
[SOURCE_TEXT]

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "linked_answer": "The answer text with inline citation markers like [1], [2], etc.",
  "claim_source_map": [
    {
      "claim_text": "The exact claim text from the answer",
      "source_ids": ["SOURCE_ID_1", "SOURCE_ID_2"],
      "support_level": "fully_supported | partially_supported | unsupported",
      "explanation": "Why this source does or does not support the claim"
    }
  ],
  "verification_summary": {
    "total_claims": 0,
    "fully_supported": 0,
    "partially_supported": 0,
    "unsupported": 0,
    "overall_faithfulness": "high | medium | low"
  }
}

## CONSTRAINTS

[CONSTRAINTS]

Default constraints if none provided:
- Link every factual claim, not just the ones you're confident about.
- If a claim has no supporting source, mark it as unsupported and explain why.
- Do not invent source IDs. Only use IDs from the provided source passages.
- If multiple sources support the same claim, include all relevant source IDs.
- For partially supported claims, specify which part is supported and which is not.
- If the answer contains opinions, interpretations, or summaries not directly in the sources, flag those as unsupported.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

If risk level is high, require explicit confidence thresholds and flag borderline cases for human review.

How to adapt this template: Replace [ANSWER_TEXT] with the RAG-generated answer you want to link. Replace [SOURCE_PASSAGES] with your retrieved passages, each prefixed with a unique source ID. Use [CONSTRAINTS] to add domain-specific rules, such as requiring exact quotes for legal text or allowing paraphrasing for general knowledge. Add [EXAMPLES] with 2-3 input-output pairs showing correct linking behavior for your use case. Set [RISK_LEVEL] to high for regulated domains where unsupported claims must never reach users without review. For production systems, validate the output JSON against the schema before surfacing linked answers to users, and log verification summaries for monitoring faithfulness drift over time.

The Source Linking prompt operates as a post-generation verification step in a RAG pipeline. After the primary LLM generates an answer from retrieved context, this prompt takes the answer and the original source passages as input, then produces a sentence-level mapping with inline citation markers and faithfulness verification. The harness should call this prompt synchronously before returning the final answer to the user, blocking the response path until verification completes. For latency-sensitive applications, consider running verification in parallel with answer generation using a separate lightweight model, then merging results before display.

The implementation harness requires several components beyond the prompt itself. First, a sentence splitter must segment the generated answer into claim-level units before passing them to the prompt—use a deterministic splitter (spaCy, NLTK, or regex-based) rather than relying on the model to segment text, as inconsistent segmentation causes citation misalignment. Second, a source passage registry must maintain stable passage IDs and full text content so the prompt can reference passages by ID and the application can resolve citations back to original document spans. Third, a validation layer should parse the structured output and verify that every citation marker references a real passage ID present in the input context—hallucinated passage IDs are a common failure mode. Fourth, implement a faithfulness threshold: if the prompt flags any claim as unsupported or partially supported, route the output to a human reviewer or trigger a regeneration loop with expanded retrieval rather than surfacing unverified claims to users.

For model selection, use a capable instruction-following model with strong structured output performance. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all handle inline citation annotation reliably. For cost optimization, consider using a smaller model (GPT-4o-mini, Claude 3 Haiku) for the verification step when the primary answer generation uses a larger model—the verification task is more constrained and benefits from the smaller model's speed. Always set temperature=0 or very low values (0.0–0.1) for citation tasks to maximize positional consistency. Implement retry logic with exponential backoff for malformed outputs: if the response fails to parse as valid JSON or contains citation markers that don't match the expected format, retry up to 3 times with the error message appended to the prompt. After 3 failures, log the raw output and escalate to a human review queue rather than silently dropping citations.

Logging and observability are critical for citation-aware systems. Log every verification call with: the input answer text, the passage IDs and snippet lengths, the output citation mapping, any faithfulness flags raised, and the verification latency. Store these in a structured format (JSON or database rows) indexed by request ID so you can trace any user-reported hallucination back to the exact verification output. Implement a drift monitor that samples verification outputs and compares citation coverage rates over time—a sudden drop in citation density or a spike in unsupported-claim flags often indicates a retrieval pipeline regression or a model behavior change. For regulated domains, persist the full verification payload as an audit record and require human sign-off on any answer where more than 10% of claims are flagged as unsupported.

When integrating this prompt into a production system, avoid the common mistake of treating citation verification as optional or best-effort. If citations are shown to users, every displayed citation must have passed verification. Build the harness so that unverified answers are never surfaced—either the verification succeeds and produces valid citations, or the system falls back to a conservative response that acknowledges uncertainty and avoids making specific claims. Test the full harness with adversarial examples: answers that subtly rephrase source content, answers that combine facts from multiple passages in ways that change meaning, and answers that introduce plausible-sounding but unsupported details. These edge cases reveal gaps in your verification logic before users encounter them.