Spelling Error Detection and Correction Prompt Template

This prompt is designed for the specific job of cleaning noisy user input before it reaches your retrieval system. It is ideal for RAG operators and search engineers who observe that typos, misspellings, and keyboard errors in user queries are causing poor recall or irrelevant results from vector and keyword search backends. The core workflow is a pre-retrieval gate: a raw user query enters, and a corrected query with per-token confidence scores exits. This allows your application to make a programmatic decision—use the corrected query, fall back to the original, or ask the user for clarification—before spending compute on a doomed retrieval round.

You should use this prompt when user input is short-form and noisy, such as in a search bar or a chatbot interface, and your downstream retrieval system lacks native fuzzy matching or robust spelling tolerance. It is particularly valuable in domains with a mix of common words and highly specific jargon, where a generic spellchecker would 'fix' a technical term into a common word. The prompt's explicit instruction to preserve intentional technical terms and flag low-confidence corrections is the key differentiator from a simple library call. For example, a query like 'k8s pod err' should be corrected to 'Kubernetes pod error' with high confidence, while 'k8s' itself should be flagged as a deliberate term, not a misspelling of 'kids'. The confidence score is not just a number; it is a signal for your application logic. A low-confidence correction on a domain term should trigger a lookup against your internal glossary, not a blind replacement.

Do not use this prompt as a general-purpose text polisher or for correcting grammar in long-form documents. It is tuned for short, retrieval-critical strings. Avoid it when your retrieval system already performs robust spelling correction natively, or when the latency of an additional LLM call is unacceptable for your real-time requirements. If the user's query is fundamentally ambiguous or nonsensical, this prompt is not a solution; pair it with a separate query disambiguation or gibberish detection prompt. The next step after understanding this use case is to copy the prompt template, plug in your domain glossary as part of the [CONTEXT], and run it against a golden dataset of 50-100 real user queries to calibrate your confidence score thresholds before production deployment.

This prompt template is designed to sit in front of your retrieval pipeline and clean user queries before they hit your vector database or search index. It corrects genuine spelling mistakes while preserving technical terms, product names, and proper nouns that might otherwise be flagged as errors by generic spellcheckers. The template outputs a corrected query string, a confidence score, and a list of changes made, giving you the audit trail needed for debugging retrieval failures.

textCopy
You are a spelling correction system for search queries in a [DOMAIN] application. Your job is to fix genuine spelling errors while preserving intentional technical terms, product names, acronyms, and proper nouns.

INPUT QUERY:
[USER_QUERY]

DOMAIN GLOSSARY (DO NOT CORRECT THESE TERMS):
[DOMAIN_TERMS]

INSTRUCTIONS:
1. Identify tokens that appear to be misspelled based on standard [LANGUAGE] spelling.
2. For each candidate correction, check whether the token matches a known domain term, product name, acronym, or proper noun from the glossary. If it matches, do NOT correct it.
3. For tokens not in the glossary, apply minimal-edit correction that preserves the likely intended word.
4. Do not change word order, add words, remove words, or alter punctuation unless it is part of a spelling fix.
5. If the query contains multiple plausible corrections for the same token, select the one with highest likelihood given the surrounding context.
6. If no corrections are needed, return the original query unchanged with confidence 1.0.

OUTPUT SCHEMA:
Return valid JSON matching this structure:
{
  "original_query": "string",
  "corrected_query": "string",
  "confidence": number (0.0 to 1.0),
  "corrections": [
    {
      "original_token": "string",
      "corrected_token": "string",
      "position": number (0-indexed token position),
      "rationale": "string (brief explanation)"
    }
  ],
  "uncorrected_domain_terms": ["string"]
}

CONSTRAINTS:
- Never correct terms listed in the domain glossary.
- Never alter casing of proper nouns or acronyms.
- If confidence is below [MIN_CONFIDENCE_THRESHOLD], set corrected_query to original_query and flag for human review.
- Return ONLY the JSON object, no markdown fences or additional text.

To adapt this template, replace [DOMAIN] with a short description of your application domain, [LANGUAGE] with the expected input language, and [MIN_CONFIDENCE_THRESHOLD] with your acceptable confidence floor. The [DOMAIN_TERMS] placeholder should be populated at runtime with your controlled vocabulary, product catalog, or entity list. The [USER_QUERY] placeholder receives the raw user input. Wire the output JSON into a validator that checks schema compliance before forwarding the corrected_query to your retrieval backend. For high-stakes domains, route corrections with confidence below your threshold to a human review queue rather than silently executing them.

This prompt is designed to sit as a pre-retrieval gate in your RAG pipeline. It receives the raw user query string and returns a corrected version before any embedding computation or vector search occurs. The primary integration point is a lightweight API endpoint or middleware function that intercepts the query, calls the LLM with this prompt template, validates the response, and then passes the corrected query downstream. You should never send the raw user query directly to your vector database or keyword index without first running it through this correction step—uncorrected typos produce near-zero cosine similarity to relevant documents and waste compute on irrelevant retrieval rounds.

Wire the prompt into your application with a validation wrapper that checks the LLM response before forwarding it. The expected output schema includes a corrected_query string, a confidence_score float between 0.0 and 1.0, and a corrections_applied array of before/after pairs. Your harness should: (1) parse the JSON response and reject malformed outputs, (2) verify the confidence score is within range, (3) compare the original and corrected strings—if they are identical, skip the correction step entirely to save a retrieval round, and (4) log the correction event with a trace ID for observability. For high-stakes domains like healthcare or legal search, add a confidence threshold gate: if confidence_score falls below 0.7, route the query to a human review queue rather than executing retrieval automatically. This prevents over-correction of domain jargon or proper nouns that the model is uncertain about.

Model choice matters here. Use a fast, inexpensive model for this gate because it runs on every user query before any other processing. GPT-4o-mini, Claude Haiku, or a fine-tuned small open-weight model are appropriate. Avoid large models for this step—the latency cost of a 70B+ parameter model on every keystroke will degrade user experience. Implement a retry strategy with exponential backoff (max 2 retries) for transient failures, but fail closed: if the correction service is unavailable after retries, pass the original query through with a correction_skipped flag rather than blocking the user. Finally, instrument this step with metrics: track correction rate, average confidence, over-correction complaints from users, and latency p95. These metrics will tell you when your prompt needs tuning or when your domain vocabulary has drifted beyond the model's correction capability.