Multilingual Query Expansion with Back-Translation Prompt

This prompt is for RAG developers and search engineers who need high-fidelity query translation before retrieval. It takes a user query in a source language, translates it into a target retrieval language, back-translates the result to the source language, and compares the back-translation to the original. The output is a semantic consistency score that flags drift before the query hits your vector or keyword index. Use this when direct translation alone is not trustworthy enough, such as when idiomatic expressions, domain terminology, or ambiguous phrasing could silently corrupt retrieval results. This prompt belongs in the pre-retrieval pipeline, after language detection and before the query is sent to the search backend.

The ideal user is a backend engineer or ML platform developer integrating multilingual search into a production RAG system. You should have already detected the source language and identified the target index language. This prompt is not a replacement for a translation API; it is a verification gate. Do not use it when latency budgets are under 200ms, when the source and target languages share near-identical syntax and vocabulary, or when the retrieval corpus is small enough that recall loss from translation drift is acceptable. It is also inappropriate for real-time chat where users expect sub-second responses and can clarify ambiguity themselves.

Before deploying this prompt, you must define what semantic consistency score threshold triggers a halt, a retry, or a fallback strategy. A score below 0.7 typically indicates meaningful drift, but calibrate this against your own domain data. Wire the prompt into a pre-retrieval validation step that logs the original query, the translated query, the back-translation, and the score for every request. This trace data is essential for tuning thresholds and identifying recurring failure patterns. Avoid using this prompt for single-word queries or queries consisting only of named entities, as back-translation provides little signal when there is no syntactic structure to compare.

This prompt is the core of the multilingual query expansion with back-translation workflow. It takes a user query in a source language, translates it into a target retrieval language, back-translates the result into the source language, and then compares the back-translation to the original query. The output is a structured object containing the target query, the back-translation, and a semantic consistency score. This score acts as a gate: if it falls below a defined threshold, the system should route the query for human review or use an alternative expansion strategy instead of blindly retrieving documents that may be irrelevant due to translation drift.

codeCopy
SYSTEM:
You are a precise multilingual query translator and semantic validator for a RAG system. Your task is to translate a user query into a target language for document retrieval, then verify the translation's fidelity by back-translating it and comparing it to the original.

Follow these rules:
1. Translate the [SOURCE_QUERY] from [SOURCE_LANGUAGE] into [TARGET_LANGUAGE]. Prioritize domain terminology from [DOMAIN] if provided. The translation must be optimized for information retrieval, not literary quality.
2. Back-translate your [TARGET_LANGUAGE] query back into [SOURCE_LANGUAGE] literally.
3. Compare the back-translation to the original [SOURCE_QUERY] semantically. Score the consistency from 0.0 (completely different meaning) to 1.0 (identical meaning).
4. If the score is below [CONSISTENCY_THRESHOLD], set a `drift_flag` to true and provide a brief `drift_note` explaining what meaning was lost or altered.
5. Output ONLY a valid JSON object matching the schema below. Do not include any other text.

USER:
Source Query: [SOURCE_QUERY]
Source Language: [SOURCE_LANGUAGE]
Target Language: [TARGET_LANGUAGE]
Domain (optional): [DOMAIN]

Output JSON Schema:
{
  "source_query": "string",
  "source_language": "string",
  "target_query": "string",
  "target_language": "string",
  "back_translation": "string",
  "consistency_score": number,
  "drift_flag": boolean,
  "drift_note": "string or null"
}

Before wiring this prompt into production, replace the square-bracket placeholders with real values from your application context. [SOURCE_QUERY] is the user's original input. [SOURCE_LANGUAGE] and [TARGET_LANGUAGE] should be ISO 639-1 codes or full language names, but be consistent across calls. [DOMAIN] is optional but strongly recommended for specialized corpora (e.g., 'legal', 'medical', 'e-commerce') to guide terminology choices. [CONSISTENCY_THRESHOLD] is a tunable parameter; start with 0.85 and adjust based on your tolerance for semantic drift. The output JSON must be parsed and validated by your application code. If drift_flag is true, do not use the target_query for retrieval without human review or a fallback strategy. Always log the full response object for observability and debugging of retrieval quality over time.

This prompt is designed to be called as a pre-retrieval transformation step in a RAG pipeline. Before executing a search, the application sends the user's query, the target language, and any domain terminology to the model. The prompt returns a structured JSON payload containing the translated query, the back-translated query, and a semantic consistency score. The application should parse this JSON and use the target_language_query field as the input to the retrieval engine, while logging the back_translated_query and consistency_score for observability. Do not proceed with retrieval if the model fails to return valid JSON; instead, fall back to a simpler direct translation prompt or flag the query for human review.

Implement a strict validation layer immediately after the model response. The JSON output must be parsed and validated against a schema that requires target_language_query as a non-empty string, back_translated_query as a non-empty string, and consistency_score as a float between 0.0 and 1.0. If the consistency_score falls below a configurable threshold (start with 0.7 and tune based on your domain's tolerance for drift), the system should not use the translated query for retrieval. Instead, log the low-confidence event, capture the original query and the back-translation for offline analysis, and either route the query to a human reviewer or attempt a fallback strategy such as a direct translation without back-translation verification. For high-stakes domains like legal or medical retrieval, require a human to approve any query where the score is below 0.85 before retrieval proceeds.

Model choice matters here. This prompt requires strong cross-lingual reasoning and structured output discipline. Use a capable model like GPT-4o, Claude 3.5 Sonnet, or an equivalent that supports JSON mode or structured outputs. Avoid smaller or older models that may conflate the back-translation step with the translation itself or hallucinate consistency scores. For latency-sensitive applications, consider running the initial translation and the back-translation as separate, parallel calls to a faster model, then use a lightweight semantic similarity model (e.g., a sentence-transformer) to compute the consistency score outside the LLM. This reduces token costs and latency while keeping the drift check. Log every request with the original query, target language, translated query, back-translation, score, and the model version used. This trace data is essential for debugging retrieval failures and for periodically recalibrating the consistency score threshold against human-annotated relevance judgments.