Conversation Repair Prompt After Model Error

This prompt is for RAG assistant builders who need a reliable mechanism to recover after the system produces a hallucinated, incorrect, or poorly grounded answer in a multi-turn conversation. The job-to-be-done is trust repair: the model must acknowledge the specific error without groveling, provide a corrected answer that is strictly grounded in retrieved evidence, and re-establish user confidence that the system can self-correct. The ideal user is an AI engineer or product developer integrating this into a chat copilot, customer-facing Q&A system, or internal knowledge assistant where factual accuracy is non-negotiable and users can challenge model outputs.

Required context includes the conversation history leading up to the error, the original incorrect answer, the user's correction or challenge, and the full set of retrieved evidence chunks with source identifiers. Without this context, the repair prompt cannot distinguish between a legitimate correction and a user who is mistaken, nor can it verify that the new answer is actually grounded. The prompt assumes the error has already been detected—either by the user explicitly pointing it out, by an automated hallucination detection step, or by a post-generation factual verification check that flagged unsupported claims. It does not handle cases where the model should independently discover its own error without external signal.

Do not use this prompt when the original answer was actually correct but the user disagrees. In that scenario, a clarification or evidence-presentation prompt is more appropriate than a repair prompt that assumes error. Do not use this prompt for real-time safety-critical corrections in healthcare, clinical decision support, or legal advice without routing the corrected answer through human review first. The repair prompt produces a corrected answer, but it does not guarantee the correction is itself error-free—a second verification pass against source evidence is strongly recommended before the corrected answer reaches the user. For high-stakes domains, pair this prompt with a mandatory human-in-the-loop approval step and log both the original error and the correction for audit and prompt regression testing.

This prompt is most effective when embedded in a structured recovery workflow: detect the error, retrieve fresh evidence if needed, run the repair prompt, validate the corrected answer against sources, and only then surface it to the user. Avoid using it as a standalone one-shot fix without validation, as the model can introduce new hallucinations during the correction attempt. The next section provides the copy-ready prompt template you can adapt into that workflow.

This template provides the core instruction set for a RAG assistant to issue a correction after it has produced a hallucinated or incorrect answer. The prompt is designed to force the model to explicitly acknowledge the error, provide the corrected answer with proper source grounding, and rebuild user trust without being defensive or evasive. Use this template as the foundation for a repair step in your conversation loop, triggered by user correction, an automated fact-checking eval, or a human reviewer flagging a previous turn as inaccurate.

textCopy
You are a correction module for a RAG assistant. Your task is to repair a previous conversation turn where the assistant provided an incorrect or unsupported answer.

[CONVERSATION_HISTORY]

[ERROR_DESCRIPTION]

[CORRECTED_EVIDENCE]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

Adapt this template by replacing each placeholder with concrete data from your application context. [CONVERSATION_HISTORY] should contain the full dialogue up to and including the erroneous assistant turn. [ERROR_DESCRIPTION] is a clear statement of what was wrong, which can be sourced from a user message ('That's wrong, the limit is 500') or an automated evaluator ('Hallucination detected: cited source does not contain claim about pricing'). [CORRECTED_EVIDENCE] must contain the verified source passages that support the corrected answer. [OUTPUT_SCHEMA] should define the exact structure you need, such as a JSON object with acknowledgment, corrected_answer, and supporting_citations fields. [CONSTRAINTS] is where you enforce tone ('Be direct, do not over-apologize'), citation format, and safety rules. After copying the template, wire it into a repair pipeline that validates the output against the corrected evidence before surfacing it to the user.

The conversation repair prompt is a recovery path, not a primary answer generator. It should only be invoked after a separate detection mechanism—such as user correction, an LLM judge, or a factual verification step—flags a prior answer as incorrect or hallucinated. The harness must pass the original user question, the flagged answer, the retrieved evidence used (if any), and the correction signal into the prompt. Do not call this prompt on every turn; doing so will degrade user trust by making the assistant appear perpetually uncertain.

Wire the prompt into an error-handling middleware in your RAG pipeline. When a correction event is detected, construct the prompt with [ORIGINAL_QUESTION], [INCORRECT_ANSWER], [RETRIEVED_CONTEXT], and [CORRECTION_SIGNAL]. Before sending the prompt, validate that all required fields are non-empty and that the correction signal contains actionable information (not just 'wrong'). After receiving the model's response, run a structured output validator to confirm the output contains the required sections: an acknowledgment of the error, the corrected answer, and explicit source citations. If validation fails, retry once with a stronger constraint message appended to the prompt. If it fails twice, escalate to a human reviewer and log the full trace for debugging.

For high-stakes domains, add a human-in-the-loop gate before the corrected answer is shown to the user. The gate should display the original answer, the correction signal, and the proposed repair side-by-side. Log every repair event—including the detection trigger, prompt version, model response, validation result, and reviewer decision—to your observability platform. This log becomes essential for measuring hallucination rates, repair success rates, and prompt drift over time. Avoid using this prompt with models that have known instruction-following weaknesses on structured output tasks; prefer models with strong JSON mode or function-calling support to enforce the output schema.