Multilingual Query Disambiguation Prompt

This prompt is designed for search relevance engineers and RAG developers who are responsible for retrieval pipelines that span multiple languages. The core job-to-be-done is resolving semantic ambiguity in a user's source query before it is translated and executed against a multilingual corpus. A direct translation of a polysemous word like 'apple' or 'jaguar' will propagate the ambiguity into every target language, polluting the retrieval candidate set with documents about fruit, technology companies, animals, and automotive brands. This prompt intervenes at the pre-retrieval stage to detect such entity collisions and polysemous terms, generating multiple candidate disambiguated rewrites in each required target language, each annotated with a confidence score. The ideal user is a technical practitioner who can integrate the structured output into a retrieval dispatch layer, not an end-user performing manual translation.

You should use this prompt when your retrieval index contains documents in multiple languages and query ambiguity is measurably degrading downstream answer quality. The prompt expects a source query string, a list of target retrieval languages, and optional domain context to constrain the disambiguation space. It returns a structured payload containing the original query, detected ambiguous terms, and an array of disambiguation candidates per target language. Each candidate includes a rewritten query, the resolved sense, and a confidence score. This output is designed to be consumed programmatically by a retrieval orchestrator that can execute parallel searches for each candidate and fuse or rank the results. Do not use this prompt for simple one-to-one translation tasks where ambiguity is not a concern, or when your retrieval index is monolingual and the only task is language translation. In those cases, a direct translation prompt is cheaper, faster, and less prone to over-disambiguation.

Before deploying this prompt, ensure you have a clear evaluation rubric that measures both disambiguation accuracy and retrieval recall improvement. Common failure modes include over-disambiguation, where the prompt splits a term that was already clear in context, and under-disambiguation, where it misses a collision that a native speaker would catch. You should also define a maximum number of candidate rewrites per language to control retrieval fan-out costs. If your application operates in a regulated domain such as legal or medical search, the disambiguation candidates must be logged and auditable, and a human-in-the-loop review step should be considered before the rewrites are used to retrieve evidence that informs a final answer. The next section provides the copy-ready prompt template you can adapt to your specific languages and domain.

This prompt is designed to be placed in the system message of a capable instruction-following model. The user's raw query is sent as a separate user message. The model's job is to act as a search relevance pre-processor: it identifies polysemous words, entity collisions, or underspecified constraints in the input query and produces a structured set of candidate rewrites that resolve each ambiguity. Each rewrite is paired with a target retrieval language and a confidence score, enabling the downstream retrieval orchestrator to execute parallel searches and fuse results.

textCopy
You are a multilingual query disambiguation engine for a search system. Your task is to analyze a user query, detect ambiguous terms or entity collisions, and generate multiple candidate disambiguated rewrites in the specified target retrieval languages.

## INPUT
User Query: [USER_QUERY]
Source Language: [SOURCE_LANGUAGE]
Target Retrieval Languages: [TARGET_LANGUAGES]
Domain Context: [DOMAIN_CONTEXT]

## INSTRUCTIONS
1. Identify every term or phrase in the user query that is ambiguous. Ambiguity includes:
   - Polysemous words (one word with multiple meanings).
   - Entity collisions (e.g., "Apple" the company vs. "apple" the fruit; "Jordan" the country vs. "Jordan" the athlete).
   - Underspecified constraints (e.g., "recent" without a time boundary, "best" without criteria).
2. For each ambiguity, enumerate the plausible interpretations given the domain context.
3. Generate one disambiguated rewrite per interpretation per target language. Each rewrite must resolve exactly one interpretation path.
4. Assign a confidence score between 0.0 and 1.0 to each rewrite, where:
   - 0.9-1.0: The interpretation is highly likely given the domain context.
   - 0.7-0.89: The interpretation is plausible but less certain.
   - 0.5-0.69: The interpretation is possible but speculative.
   - Below 0.5: Do not include; the interpretation is too unlikely.
5. Preserve the user's original intent. Do not add constraints the user did not imply.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "original_query": "string",
  "source_language": "string",
  "detected_ambiguities": [
    {
      "term": "string",
      "possible_interpretations": ["string"],
      "position_in_query": "string"
    }
  ],
  "disambiguated_rewrites": [
    {
      "rewrite": "string",
      "target_language": "string",
      "resolved_interpretation": "string",
      "confidence": 0.0
    }
  ]
}

## CONSTRAINTS
- If no ambiguity is detected, return an empty `detected_ambiguities` array and a single rewrite identical to the original query with confidence 1.0.
- Do not fabricate interpretations. Only include interpretations that are linguistically and contextually plausible.
- For entity collisions, prefer the interpretation most relevant to the domain context when assigning confidence.
- Output only valid JSON. No markdown fences, no commentary.

To adapt this template, replace the square-bracket placeholders with your runtime values. [USER_QUERY] is the raw text from the user. [SOURCE_LANGUAGE] should be an ISO 639-1 code or a language name the model understands. [TARGET_LANGUAGES] is a list of languages into which the rewrites should be translated for retrieval against multilingual indexes. [DOMAIN_CONTEXT] is a short string describing the knowledge domain—for example, "enterprise IT support tickets" or "biomedical research papers"—which helps the model resolve entity collisions correctly. If your system does not have a domain context, replace it with "general" and expect lower confidence scores on ambiguous terms. For high-risk domains such as legal or clinical search, add a [RISK_LEVEL] placeholder and instruct the model to flag low-confidence rewrites for human review before retrieval execution.

This prompt is designed to sit between the user's raw query and the retrieval engine. It should be invoked before any translation or expansion step, acting as a pre-retrieval disambiguation gate. The application layer must capture the original query string, the user's detected language, and the target retrieval languages, then pass them into the prompt template. The model returns a structured list of candidate disambiguated rewrites, each with a confidence score and a target language. The calling service must then decide how to use these candidates: typically by routing the top-N candidates above a confidence threshold to parallel retrieval pipelines, or by presenting the candidates to the user for clarification if no candidate exceeds the threshold.

Wiring the prompt into an application requires a thin orchestration layer. First, validate the model's output against a strict JSON schema that expects an array of objects, each containing rewritten_query, target_language, confidence_score, and disambiguation_rationale fields. Reject and retry any response that fails schema validation. Second, implement a confidence gate: if the highest confidence_score is below a configurable threshold (e.g., 0.7), route the query to a clarification UI instead of proceeding to retrieval. This prevents low-confidence disambiguations from polluting search results. Third, log every disambiguation decision—including the original query, the selected candidate, and the rejected alternatives—for offline evaluation and prompt improvement. For high-stakes domains like legal or medical search, require a human reviewer to confirm the selected disambiguation before retrieval executes.

Model choice and latency considerations are critical here. This prompt performs a classification-plus-generation task that benefits from models with strong multilingual reasoning. Use a fast, instruction-tuned model (e.g., GPT-4o, Claude 3.5 Sonnet, or a fine-tuned open-weight model) and set a low temperature (0.0–0.2) to maximize deterministic, repeatable outputs. Because this prompt runs on every user query, latency must be kept under 500ms in interactive search systems. If the model is too slow, consider caching disambiguation results for high-frequency ambiguous queries, or using a smaller distilled model for the initial disambiguation pass and escalating to a larger model only when confidence is borderline. Do not use this prompt in streaming mode; the full structured output is required before the application can make a routing decision.

Integration with downstream retrieval requires the application to map each disambiguated rewrite to the correct retrieval index. If the prompt returns a German rewrite and an English rewrite for a polysemous query, the orchestrator must send each to the corresponding language-specific index. Merge and deduplicate results from parallel retrieval calls before passing them to the answer generation step. Include the disambiguation_rationale in the retrieval metadata so downstream RAG prompts can explain to the user why a particular interpretation was chosen. Finally, instrument the entire path with tracing: record the original query, the disambiguation candidates, the confidence scores, the selected threshold, the retrieval calls made, and the final answer. This trace data is essential for tuning the confidence threshold and identifying failure patterns where the prompt consistently picks the wrong interpretation.