Cross-Lingual Query Translation Prompt Template

This prompt is for global RAG teams who need to retrieve documents in a language different from the user's query. It translates a source-language query into a target retrieval language, then back-translates the result to verify semantic equivalence. The output includes a confidence flag and a drift warning, so your retrieval pipeline can decide whether to use the translated query, fall back to a pivot language, or escalate for human review. Use this when direct machine translation alone is not enough and you need a structured, evaluable translation artifact before retrieval execution.

The ideal user is a search engineer or RAG architect building a multilingual retrieval pipeline where recall and precision are critical. You should have the source query, the target index language, and optionally a domain glossary or controlled vocabulary. This prompt is most valuable when the cost of a bad translation is high—for example, in legal, medical, or financial domains where a mistranslated term can retrieve irrelevant or misleading documents. It is not a replacement for a production translation API; it is a pre-retrieval validation step that adds a semantic consistency check before the query hits your search index. Do not use this prompt for real-time chat translation, general-purpose language tasks, or when the retrieval corpus is monolingual.

Before implementing, confirm that your retrieval backend can consume a structured query object with a confidence score and a drift flag. If your pipeline cannot branch on these signals, the prompt's added value is limited. Also, avoid using this prompt for low-resource language pairs where the model's translation and back-translation quality is unreliable; in those cases, prefer the pivot language approach described in the sibling playbook. Start by testing the prompt on a golden set of 20–30 query pairs with known semantic drift cases, and measure whether the confidence flag correctly identifies queries that would retrieve bad results.

This prompt template is the core instruction set for a cross-lingual query translation step in a RAG pipeline. It accepts a user query in one language and produces a translated query in a specified target language, along with a back-translation into the source language and a confidence flag. The back-translation acts as a semantic consistency check, allowing downstream logic to decide whether to use the translation, request human review, or fall back to a broader retrieval strategy. Paste this template into your system or user message, wire the placeholders from your application, and treat the output as a structured signal—not a final answer.

textCopy
You are a precise cross-lingual query translator for a multilingual retrieval system. Your job is to translate a user's search query from [SOURCE_LANGUAGE] into [TARGET_LANGUAGE] so that it retrieves relevant documents from a [TARGET_LANGUAGE] corpus. Then, back-translate your result into [SOURCE_LANGUAGE] and compare it to the original query to detect semantic drift.

INPUT QUERY:
"""
[USER_QUERY]
"""

DOMAIN CONTEXT (optional):
"""
[DOMAIN_CONTEXT]
"""

CONSTRAINTS:
- Preserve the search intent, not just the literal words.
- If the query contains domain-specific terminology, use the equivalent term in [TARGET_LANGUAGE] as defined in the domain context.
- If the query contains named entities (people, products, organizations), do not translate them; keep them in their original form unless a canonical [TARGET_LANGUAGE] equivalent is provided in the domain context.
- If the query is ambiguous, choose the most likely interpretation for a search context and note the ambiguity in the confidence explanation.
- Do not add information or answer the query; only translate it for retrieval purposes.

OUTPUT SCHEMA (strict JSON):
{
  "translated_query": "string, the query translated into [TARGET_LANGUAGE]",
  "back_translation": "string, the translated query translated back into [SOURCE_LANGUAGE]",
  "semantic_drift_detected": boolean,
  "confidence": "high|medium|low",
  "drift_explanation": "string, brief explanation of any meaning shift detected, or 'None' if no drift"
}

To adapt this template, replace the square-bracket placeholders with values from your application context. [SOURCE_LANGUAGE] and [TARGET_LANGUAGE] should be ISO language codes or full language names. [USER_QUERY] is the raw input from the user. [DOMAIN_CONTEXT] is optional but critical for specialized corpora; supply a glossary of domain terms and their target-language equivalents, or leave it empty. The output schema is designed for programmatic consumption: use semantic_drift_detected and confidence to branch your retrieval logic. If confidence is low or drift is detected, route to a human review queue or fall back to a broader query relaxation strategy. Always validate the JSON structure before passing the translated_query to your retrieval engine.

Integrating the cross-lingual query translation prompt into an application requires treating it as a deterministic step in a retrieval pipeline, not a standalone chat interaction. The prompt expects a source query, a source language, and one or more target index languages. Before calling the model, the application layer should validate that the source language is detected or provided explicitly, that the target language list is non-empty, and that the query string is not blank. The model call should be wrapped in a function that accepts these parameters, injects them into the prompt template's [INPUT], [SOURCE_LANGUAGE], and [TARGET_LANGUAGES] placeholders, and parses the structured JSON output containing translated_query, back_translation, and confidence_flag. A thin client function in Python or TypeScript is sufficient; avoid embedding this prompt inside a larger monolithic system prompt where its specific output contract could be diluted by competing instructions.

The output must be validated before the translated query is sent to any retrieval backend. The application should check that translated_query is a non-empty string, that back_translation is present, and that confidence_flag is one of the expected enum values (e.g., high, medium, low). If the confidence flag is low or the back-translation shows significant semantic drift—detectable by a secondary similarity check against the original query—the system should either retry with a different temperature setting, fall back to a simpler direct translation API, or escalate for human review if the retrieval domain is high-stakes. Log the full prompt input, model response, validation result, and any retry attempts as structured events. This trace is essential for debugging retrieval failures where a poor translation, not a poor retriever, caused irrelevant documents to surface. For model choice, a fast instruction-tuned model like GPT-4o-mini or Claude Haiku is sufficient for most language pairs; reserve larger models for low-resource language combinations or when the confidence flag consistently returns low in production.

Avoid wiring this prompt directly to the user-facing answer generation step without an intermediate retrieval and evidence check. The translated query is an artifact for the retrieval system, not a response to the user. The downstream RAG answer prompt should receive the original user query, the retrieved documents, and optionally the back-translation for context, but it should not rely on the translated query as the sole representation of user intent. When deploying across many language pairs, build a lightweight evaluation harness that runs a golden set of queries through the translation prompt, retrieves documents, and checks that the top-N results overlap with expected relevant documents. This end-to-end eval catches translation drift that a back-translation check alone might miss. Finally, if the retrieval index is updated frequently or contains domain-specific terminology, periodically sample production queries and review translation quality manually to catch idiomatic or terminology shifts before they degrade answer quality at scale.