Reference Resolution with RAG Context Prompt Template

This prompt is designed for RAG-augmented chat systems where a user's pronoun, demonstrative, or implicit reference may point to an entity inside a retrieved document chunk rather than a prior conversation turn. The core job is to resolve the ambiguous reference and produce a self-contained, grounded utterance with a citation to either the dialogue turn or the specific retrieved chunk. The ideal user is an AI engineer or product developer building a multi-turn assistant that blends live retrieval with conversational memory, and who needs a deterministic, auditable resolution step before the resolved utterance is passed to a downstream answer generation or tool-calling model.

Use this prompt when your system retrieves documents mid-session and the user follows up with phrases like 'what about its warranty?' or 'summarize the second one' where the referent lives in a retrieved passage, not in the assistant's last response. The prompt requires three inputs: the current user utterance, a structured array of prior dialogue turns with speaker labels, and a structured array of retrieved chunks each with a unique chunk ID, source document title, and snippet text. Do not use this prompt for simple pronoun resolution that only involves dialogue history; the dedicated Pronoun Resolution Prompt Template is cheaper and faster for that case. Do not use it when the retrieval corpus is unavailable or when latency constraints prevent an extra model call before answer generation.

This prompt is not a substitute for a full entity linking system. It resolves references to surface-level mentions in retrieved text, not to canonical knowledge base IDs. If your application requires linking to a persistent KB entity across sessions, pair this prompt with the Cross-Turn Entity Linking Prompt Template. The output includes a source_type field set to either dialogue or retrieved_chunk, which makes the resolution auditable and enables downstream evaluation of source attribution accuracy. In high-stakes domains such as healthcare or legal review, always route outputs where source_type is retrieved_chunk and confidence is below your threshold to a human reviewer before the resolved utterance is used to generate a final answer or action.

This template is the core instruction set for a reference resolution step that sits between your RAG retrieval and your final answer generation. It forces the model to treat the dialogue history and the retrieved context as co-equal sources for grounding, and it requires an explicit citation for every resolution. The square-bracket placeholders let you inject the current user utterance, the recent dialogue turns, the top-k retrieved chunks, and your output schema without rewriting the logic each time.

textCopy
You are a reference resolution module in a RAG-augmented chat system. Your job is to resolve ambiguous references in the user's latest message by grounding them in either the dialogue history or the retrieved context.

## INPUTS
- Current user utterance: [USER_UTTERANCE]
- Recent dialogue history (oldest to newest): [DIALOGUE_HISTORY]
- Retrieved context chunks with IDs: [RETRIEVED_CHUNKS]

## TASK
1. Identify every pronoun, demonstrative (this, that, these, those), definite description (the invoice, the error we discussed), and implicit reference in [USER_UTTERANCE] that requires resolution.
2. For each reference, search for the most likely antecedent in [DIALOGUE_HISTORY] and [RETRIEVED_CHUNKS].
3. If a single clear antecedent exists, resolve the reference and produce a citation to either the dialogue turn number or the retrieved chunk ID.
4. If multiple plausible antecedents exist and none is clearly dominant, flag the reference as AMBIGUOUS and generate a single targeted clarification question.
5. If no antecedent is found in either source, flag the reference as UNRESOLVABLE.

## CONSTRAINTS
- Do not guess. If confidence is low, prefer flagging over resolving.
- A citation is mandatory for every resolved reference.
- Do not alter any part of [USER_UTTERANCE] that is not a reference.
- If [USER_UTTERANCE] contains no references, return an empty resolutions array.

## OUTPUT SCHEMA
Return valid JSON matching this schema:
{
  "resolutions": [
    {
      "reference_span": "string (exact text from utterance)",
      "reference_type": "pronoun | demonstrative | definite_description | implicit",
      "status": "resolved | ambiguous | unresolvable",
      "resolved_entity": "string | null (canonical entity name if resolved)",
      "antecedent_span": "string | null (exact text of antecedent)",
      "source": "dialogue_turn_<N> | chunk_<ID> | null",
      "clarification_question": "string | null (only if status is ambiguous)",
      "confidence": 0.0-1.0
    }
  ]
}

## EXAMPLES
[EXAMPLES]

To adapt this template, replace [EXAMPLES] with 2-3 few-shot demonstrations that show the model how to handle a resolved pronoun from dialogue, a resolved definite description from a retrieved chunk, and an ambiguous reference that triggers a clarification question. If your domain is high-stakes (healthcare, legal, finance), add a [RISK_LEVEL] constraint that forces the model to prefer flagging over resolving when confidence is below 0.9, and wire the output into a human review queue before any downstream action is taken. Always validate the output JSON against the schema before passing resolved entities to the answer generation step—schema violations here cascade into hallucinated answers downstream.

The Reference Resolution with RAG Context prompt operates at a critical junction in your pipeline: after retrieval but before answer generation. It must receive both the current user utterance and the retrieved document chunks as input. The harness should call this prompt on every user turn where the utterance contains a pronoun, anaphor, or implicit reference—not just when the downstream model flags ambiguity. A lightweight pre-check using a fast classifier or simple regex for pronouns (it, they, this, that, he, she, his, her, its, their) can gate the call and save latency on turns that don't need resolution. When the pre-check triggers, assemble the prompt with the current utterance in [CURRENT_UTTERANCE], the last N dialogue turns in [DIALOGUE_HISTORY], and the top-K retrieved chunks with their document IDs and positions in [RETRIEVED_CHUNKS]. The harness must preserve chunk metadata—source document, chunk index, retrieval score—so the resolved output can carry a traceable citation back to either a dialogue turn or a specific chunk.

Wire the resolved output into a structured validation step before it reaches the answer generation prompt. Parse the model's JSON output and validate that the resolved_reference field is non-empty, that source_type is exactly dialogue or retrieved_chunk, and that the source_id matches an actual turn index or chunk ID you provided in the input. If source_type is retrieved_chunk, confirm the source_id exists in your chunk metadata map. If validation fails, retry once with the same prompt plus the validation error message appended as a [CONSTRAINT]—but cap retries at one to avoid latency spirals. For high-stakes domains where an incorrect resolution could produce a wrong answer with compliance implications, route validation failures to a human review queue with the original utterance, retrieved chunks, and the failed resolution attempt. Log every resolution event—input utterance, resolved output, source attribution, validation result, and retry count—to your prompt observability store so you can compute source attribution accuracy over time and detect drift in the resolver's behavior.

Model choice matters here. This prompt requires strong instruction-following and structured output discipline, not creative generation. Use a model with reliable JSON mode and low refusal rates on constrained extraction tasks—Claude 3.5 Sonnet, GPT-4o, or a fine-tuned smaller model if you have sufficient resolution examples. Avoid models that tend to over-explain or add commentary outside the output schema. Set temperature to 0 or near-zero to maximize deterministic resolution. If you're using this in a streaming chat product, run the resolver synchronously before the answer generation stream begins; the added latency of one resolver call is negligible compared to the cost of a hallucinated answer that confuses the user and requires correction turns. For RAG systems with large retrieved context sets, trim [RETRIEVED_CHUNKS] to the top 5-10 chunks ranked by retrieval score before passing them to the resolver—the model doesn't need all 50 chunks to resolve a pronoun, and excess context increases both latency and the risk of selecting the wrong referent.