Multilingual Query Correction with Phonetic Similarity Prompt

This prompt is designed for production RAG operators who ingest noisy text from automatic speech recognition (ASR) systems, mobile keyboards, or multilingual users typing in a non-native script. The core job-to-be-done is to correct spelling errors in a source-language query by analyzing phonetic similarity before the query is translated and sent to a retrieval engine. Without this correction layer, a garbled transcription—such as 'shocolat' instead of 'chocolat'—propagates through the translation step and yields nonsense retrieval results, degrading the entire RAG pipeline. The ideal user is an engineer or ML operator who already has a translation step in their retrieval stack and observes error propagation from upstream noise.

Use this prompt when your retrieval pipeline includes a translation step and you can provide a source language label, a target retrieval language label, and the raw query string. The prompt expects these three inputs and returns a corrected query in the source language, a confidence score, and an explanation of the changes made. This output is designed to be passed directly to your translation model, not to the retrieval engine. The confidence score acts as a gating mechanism: you can route low-confidence corrections to a human review queue or log them for offline analysis. The explanation field provides an audit trail, which is critical for debugging retrieval failures in production.

Do not use this prompt for grammar correction, query expansion, or translation itself. Those are separate downstream steps with different failure modes and evaluation criteria. If your input is already clean text, this prompt adds latency without benefit. If your retrieval pipeline does not include a translation step, you should use a monolingual spelling correction prompt instead. This prompt is also not a substitute for improving your ASR model or keyboard language detection; it is a tactical fix for error propagation, not a strategic solution to input quality. For high-stakes domains like legal or medical retrieval, always route low-confidence corrections to human review before the query proceeds to translation.

This prompt template is designed to be dropped directly into your query preprocessing pipeline. It takes a potentially misspelled or phonetically ambiguous user query in a source language and produces a corrected version by reasoning about how the query would sound to a native speaker. The correction step happens before any translation or retrieval, preventing error propagation into downstream vector or keyword searches. The template uses square-bracket placeholders for all dynamic inputs, making it safe to template in code without accidental variable injection.

textCopy
You are a multilingual query correction engine. Your task is to correct spelling errors in a user query by reasoning about phonetic similarity in the source language. You must produce a corrected query that a native speaker would recognize as the intended input.

[INPUT]
Source Query: [USER_QUERY]
Source Language (ISO 639-1): [SOURCE_LANG]

[CONTEXT]
Domain: [DOMAIN]
Common Misspelling Patterns in [SOURCE_LANG]: [MISSPELLING_PATTERNS]
Phonetic Alphabet Reference: [PHONETIC_ALPHABET]

[OUTPUT_SCHEMA]
Return a valid JSON object with the following fields:
- corrected_query: The spelling-corrected query in the source language.
- corrections_applied: An array of objects, each with {original_token, corrected_token, confidence (0.0-1.0), reason}.
- phonetic_ambiguity_flag: Boolean indicating if multiple plausible corrections exist.
- alternative_corrections: An array of alternative corrected queries if phonetic_ambiguity_flag is true.

[CONSTRAINTS]
- Do not translate the query. Correction must remain in [SOURCE_LANG].
- Do not change the meaning or add information. Only fix spelling.
- If the query is already correct, return it unchanged with an empty corrections_applied array.
- For names, brands, or domain terms, prefer the canonical spelling from [DOMAIN] context.
- If confidence is below 0.7 for any correction, set phonetic_ambiguity_flag to true.

[EXAMPLES]
Input: "recieve pakage" (English)
Output: {"corrected_query": "receive package", "corrections_applied": [{"original_token": "recieve", "corrected_token": "receive", "confidence": 0.95, "reason": "common i-before-e error"}, {"original_token": "pakage", "corrected_token": "package", "confidence": 0.92, "reason": "phonetic substitution of k for ck"}], "phonetic_ambiguity_flag": false, "alternative_corrections": []}

Input: "shudule maintanance" (English)
Output: {"corrected_query": "schedule maintenance", "corrections_applied": [{"original_token": "shudule", "corrected_token": "schedule", "confidence": 0.88, "reason": "phonetic mapping of sh to sch"}, {"original_token": "maintanance", "corrected_token": "maintenance", "confidence": 0.85, "reason": "vowel sequence error"}], "phonetic_ambiguity_flag": false, "alternative_corrections": []}

To adapt this template, replace the placeholders with your runtime values. [USER_QUERY] and [SOURCE_LANG] are mandatory. [DOMAIN] should be a short string like "e-commerce" or "medical" to ground the correction in your vocabulary. [MISSPELLING_PATTERNS] is optional but highly recommended for non-English languages where you can supply known error patterns (e.g., common diacritic omissions in French or vowel confusions in Arabic transliteration). [PHONETIC_ALPHABET] can be set to "IPA" or a language-specific phonetic system to guide the model's reasoning. The [EXAMPLES] section is static in this template but you should extend it with 2-3 real examples from your production logs to improve few-shot accuracy. The output schema is strict JSON; validate it in your application layer before passing the corrected_query to your translation or retrieval step. If phonetic_ambiguity_flag is true, log the alternatives and consider routing to a human review queue or running parallel retrievals with each candidate.

This prompt is designed to sit immediately before query translation and retrieval in a RAG pipeline. It accepts a raw user query—often from voice-to-text or mobile input—and returns a corrected version with phonetic similarity annotations. The harness should treat this as a synchronous pre-processing step: the corrected query is passed directly to the next stage (translation, expansion, or retrieval) without persisting intermediate state unless audit logging is required. Because the prompt operates on potentially noisy input, the harness must enforce a strict timeout (2–3 seconds) and a maximum input length (typically 500 characters) to prevent runaway processing on garbled or excessively long voice transcripts.

Wire the prompt into your application as a typed function with a clear contract. The function signature should accept a source_query: str, source_language: str (ISO 639-1 code), and an optional phonetic_alphabet: str (defaulting to 'IPA' but supporting 'Soundex' or 'Metaphone' variants). The return type is a structured object containing corrected_query: str, corrections: list[dict] (each with original_token, corrected_token, phonetic_distance, and confidence), and a correction_applied: bool flag. Validate the output against this schema immediately after the model responds. If the model returns malformed JSON or missing required fields, retry once with a stricter output constraint appended to the prompt. After a second failure, log the raw response and fall back to the original uncorrected query to avoid blocking the retrieval pipeline.

For production observability, instrument the harness with three key metrics: correction rate (percentage of queries where correction_applied is true), average phonetic distance of applied corrections, and schema validation failure rate. Log every correction event with the original query, corrected query, and confidence scores to a structured logging system. This data is essential for tuning the confidence threshold at which corrections are accepted versus discarded. A practical starting threshold is confidence >= 0.7; corrections below this should be logged but not applied, and the original query should proceed unchanged. For high-stakes domains like healthcare or legal retrieval, route all corrections above a phonetic distance of 0.5 to a human review queue before they enter the retrieval step.

Model choice matters here. This prompt works best with models that have strong multilingual phonetic awareness—GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all perform well. Smaller or open-weight models may struggle with rare language pairs or produce hallucinated phonetic transcriptions. If using a local model, test extensively on a golden dataset of 200+ real misspellings across your target languages before deploying. The harness should support model routing: use a fast, cheap model for common language pairs (e.g., English-Spanish) and escalate to a more capable model for low-resource language pairs or when the initial correction confidence is below threshold. Avoid chaining this prompt with other LLM calls in sequence without caching the corrected query—re-running phonetic correction on the same input wastes tokens and adds latency.