Contextual Spelling and Acronym Correction Prompt

This prompt is designed for production RAG operators and search engineers who need to clean user queries before they hit a retrieval index. Its primary job is to correct spelling errors and expand ambiguous acronyms in follow-up queries by using the conversation session as a disambiguation anchor. The ideal user is an engineer integrating this into a pre-retrieval pipeline where noisy, multi-turn user input—such as voice-to-text transcripts, hastily typed support chats, or domain-specific shorthand—would otherwise cause vector and keyword search to return irrelevant or empty results.

Use this prompt when a user's current query contains obvious orthographic errors or short-form acronyms that cannot be resolved in isolation. For example, a follow-up question like 'What about the TPS reports?' requires session context to determine if 'TPS' refers to 'Transaction Processing System' or 'Third-Party Security.' The prompt template requires two concrete inputs: the raw [CURRENT_QUERY] and a structured [SESSION_CONTEXT] containing prior turns, resolved entities, and the active domain. It is not a general-purpose spellchecker; do not use it for standalone queries without session history, for creative text generation, or for correcting grammar and style in long-form content. It is a surgical pre-retrieval correction tool.

Before wiring this into production, define the failure modes you will monitor. The most common failure is a false correction, where the model 'fixes' a domain-specific term or intentional shorthand into a common dictionary word, destroying retrieval precision. A second risk is acronym hallucination, where the model expands an acronym without sufficient session evidence. Implement a pre-retrieval validation harness that flags corrections with low confidence, logs the original and corrected query pairs, and routes high-risk changes for human review or fallback to the uncorrected query. Start with a strict threshold: if the model is not highly confident, do not rewrite. You can measure correction accuracy by running a golden dataset of misspelled queries with known correct resolutions through the prompt and comparing the output against expected rewrites.

This prompt template is designed to be dropped into a pre-retrieval step of a RAG pipeline. It takes the user's raw follow-up query and the conversation history, then produces a corrected, expanded query string. The model is instructed to resolve ambiguous corrections by referencing prior turns, ensuring that acronyms like 'TOS' are expanded to 'Terms of Service' only if the session context supports that interpretation. The output is a single corrected query, not a conversation or explanation, making it suitable for direct injection into a vector or keyword search call.

textCopy
SYSTEM:
You are a query correction engine for a retrieval system. Your only job is to fix spelling errors and expand acronyms in the user's latest query using the provided conversation history for context. Do not answer the query. Do not add punctuation or rephrase for style. Return only the corrected query string.

RULES:
- Fix obvious spelling and typographical errors.
- Expand acronyms and abbreviations to their full form ONLY when the conversation history provides a clear definition or strong contextual clue. If an acronym is ambiguous or undefined in the history, leave it as-is.
- Resolve ambiguous corrections using the most recent relevant turn in the history.
- Do not change the user's intent, add new concepts, or answer the question.
- If the query is already correct, return it unchanged.

CONVERSATION HISTORY:
[HISTORY]

USER QUERY:
[QUERY]

CORRECTED QUERY:

To adapt this template, replace [HISTORY] with the last N turns of the conversation, formatted clearly (e.g., User: ... Assistant: ...). Replace [QUERY] with the raw user input. For high-stakes domains like healthcare or legal, add a [CONSTRAINTS] block listing terms that must never be altered and require a human review step if the model's confidence is below a threshold. The output should be validated programmatically: if the corrected query is empty, identical to the input, or contains hallucinated expansions not present in the history, fall back to the original query and log the event for eval analysis.

This prompt is designed to sit immediately before retrieval in a RAG pipeline, correcting the user's raw follow-up query before it hits your vector or keyword index. The harness should receive the current turn's text and a session context object containing prior turns. The model call is a single-turn completion with no tools required. Choose a fast, low-cost model for this correction step—GPT-4o-mini, Claude Haiku, or a fine-tuned small open-weight model—since latency added here directly impacts end-to-end response time. The prompt expects a JSON output with corrected_query, corrections_applied (an array of objects describing each change), and confidence fields. Parse this JSON in your application layer before forwarding the corrected query to retrieval.

Validation is the critical harness component. After parsing the model's JSON response, check that corrected_query is a non-empty string and that each entry in corrections_applied contains original, corrected, and reason fields. Implement a false-correction guard: if the model's confidence score falls below a configurable threshold (start at 0.7), discard the corrections and use the original query. Log every correction event—including session ID, original query, corrected query, confidence, and the corrections array—to a structured logging system. This log becomes your evaluation dataset for tuning the confidence threshold and detecting systematic over-correction patterns. For high-stakes domains where a bad correction could surface wrong documents, add a human-review queue for low-confidence corrections or corrections involving domain-critical acronyms from a known watchlist.

Wire a retry path for malformed JSON responses. If the model returns unparseable JSON, retry once with the same prompt and a stronger format instruction appended. If the retry also fails, fall back to the original query and increment a correction_failure metric. Do not block the user's request on correction failures—the retrieval step should proceed with the uncorrected input. For latency-sensitive applications, set a strict timeout (200-500ms) on the correction call and skip it entirely if the timeout fires. Finally, build an offline evaluation loop that runs your golden set of spelling and acronym test cases against each prompt version, measuring correction accuracy, false-correction rate, and latency percentiles before promoting a new prompt to production.