Multilingual Synonym Expansion Prompt for Retrieval

This prompt is for search engineers and RAG developers who need to improve recall across multilingual document corpora. The core job-to-be-done is taking a user query in one language and generating language-specific synonyms, including domain terminology, for each significant term. The output is a structured expansion map with source language annotations, ready to be consumed by a retrieval orchestrator that fires parallel keyword, vector, or hybrid searches. Use this when direct translation of a query misses idiomatic or domain-specific variants that exist in the target language indexes. For example, a user searching for 'car insurance' in English might need the German expansions 'Kfz-Versicherung' (formal) and 'Autoversicherung' (common) to hit all relevant documents in a German-language corpus.

The ideal user already has language detection and a target language list in place. This prompt assumes you know the source language of the query and the languages of the indexes you need to search. It does not perform language detection, decide which languages to search, or execute the retrieval itself. It is a pure expansion step in a larger pipeline. You should wire it after language identification and before the retrieval dispatch layer. The prompt works best when you provide domain context—such as 'legal,' 'medical,' or 'e-commerce'—so the model can prioritize domain-appropriate synonyms over generic ones. Without domain context, the expansions may be too broad or miss the specialized terminology that matters for your corpus.

Do not use this prompt for general text translation, for generating final answers, or when the retrieval index is monolingual. If your index only contains documents in the same language as the user query, a simpler synonym expansion prompt without cross-lingual mapping is more appropriate. Do not use this prompt when you need a single translated query string for a vector search—use a cross-lingual query translation prompt instead. This prompt is specifically for generating multiple expansion terms per concept to increase recall across languages. Avoid using it in latency-sensitive, real-time chat applications where the expansion step adds unacceptable delay; in those cases, pre-compute expansion mappings for common query patterns. Finally, always validate the output schema before sending expansions to your retrieval backend. A missing language tag or malformed term list can silently degrade recall without obvious errors.

This prompt template is the core instruction set for the Multilingual Synonym Expansion workflow. It takes a user's query in a source language and a target retrieval language, then produces a structured map of synonyms for each key term. The output is designed to be directly consumable by a search orchestrator, which can use the expanded terms to construct multiple retrieval queries against a multilingual index. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can programmatically inject variables before sending the request to the model.

textCopy
You are a multilingual search linguist. Your task is to expand a user's search query with language-specific synonyms and domain-relevant terminology to improve retrieval recall across a multilingual corpus.

[INPUT]
Source Query: [USER_QUERY]
Source Language: [SOURCE_LANGUAGE_CODE]
Target Retrieval Language: [TARGET_LANGUAGE_CODE]
Domain Context: [DOMAIN_DESCRIPTION]

[OUTPUT_SCHEMA]
Return a valid JSON object with the following structure:
{
  "original_query": "string",
  "source_language": "string",
  "target_language": "string",
  "expansions": [
    {
      "source_term": "string",
      "target_synonyms": [
        {
          "term": "string",
          "type": "direct_translation | conceptual_synonym | domain_specific | broader_term | narrower_term",
          "confidence": "high | medium | low"
        }
      ]
    }
  ],
  "composite_query_variants": ["string"]
}

[CONSTRAINTS]
1. Identify the key semantic terms in the source query. Ignore stop words and articles.
2. For each key term, generate 2-5 synonyms in the target language.
3. Prioritize domain-specific terminology based on the provided [DOMAIN_DESCRIPTION].
4. Classify each synonym's relationship type and assign a confidence score.
5. Generate 2-3 composite query strings in the target language that combine the highest-confidence synonyms for direct use in a search engine.
6. If a term has no meaningful synonyms, return an empty array for that term.
7. Do not hallucinate terms. If the domain is unknown, rely only on direct translation and general synonyms.

[EXAMPLES]
Source Query: "customer churn prediction models"
Source Language: en
Target Language: de
Domain: enterprise SaaS analytics
Output:
{
  "original_query": "customer churn prediction models",
  "source_language": "en",
  "target_language": "de",
  "expansions": [
    {
      "source_term": "customer churn",
      "target_synonyms": [
        {"term": "Kundenabwanderung", "type": "direct_translation", "confidence": "high"},
        {"term": "Kündigungsrate", "type": "domain_specific", "confidence": "high"},
        {"term": "Abwanderungsrate", "type": "conceptual_synonym", "confidence": "medium"}
      ]
    },
    {
      "source_term": "prediction models",
      "target_synonyms": [
        {"term": "Vorhersagemodelle", "type": "direct_translation", "confidence": "high"},
        {"term": "Prognosemodelle", "type": "conceptual_synonym", "confidence": "high"},
        {"term": "Machine-Learning-Modelle", "type": "broader_term", "confidence": "medium"}
      ]
    }
  ],
  "composite_query_variants": [
    "Kundenabwanderung Vorhersagemodelle",
    "Kündigungsrate Prognosemodelle SaaS",
    "Abwanderungsrate Machine-Learning-Modelle"
  ]
}

[RISK_LEVEL]
Low. This prompt generates search terms, not final answers. However, low-confidence synonyms can introduce noise and reduce precision. Always validate the composite queries against your retrieval metrics.

To adapt this template, replace the placeholders in your application code before each API call. The [DOMAIN_DESCRIPTION] is critical for shifting the model from generic translation to domain-aware expansion; a vague description like 'technology' will produce weaker synonyms than 'cybersecurity incident response for financial services'. The [OUTPUT_SCHEMA] is provided as a JSON schema within the prompt, but you should also enforce it in your application layer using a schema validator. If the model returns malformed JSON, use a retry recovery prompt from the Output Repair and Validation Prompts pillar rather than accepting a broken payload. For high-stakes search applications, log the confidence scores and set a threshold below which synonyms are discarded before query construction.

This prompt is designed to sit between the user's original query and your retrieval backend. The typical integration point is a pre-retrieval expansion step in a RAG or search pipeline. The application receives a user query in language A, calls the LLM with this prompt to produce a structured expansion map, and then uses the expanded terms to construct a richer retrieval request—either by generating multiple query variants for parallel execution or by boosting documents that contain the expanded synonyms. The prompt expects a single query string and a target language code as input, and it returns a JSON object mapping each source term to its language-specific synonyms and domain alternatives. You should treat this expansion step as a synchronous, blocking call before retrieval unless your latency budget demands an asynchronous cache-warming approach.

Integration pattern: Wrap the prompt in a service function expand_query(query: str, target_lang: str, domain: str | None) -> dict. The function should: (1) validate inputs (non-empty query, supported language code, allowed domain vocabulary); (2) inject the prompt template with [QUERY], [TARGET_LANGUAGE], and [DOMAIN] placeholders; (3) call the model with response_format set to json_object (OpenAI) or a structured output mode (Anthropic, Gemini) to enforce the expansion map schema; (4) parse and validate the returned JSON against an expected schema—each key must be a string, each value must be a list of strings with a source_language annotation field; (5) log the expansion map alongside the original query for observability; (6) pass the expanded terms to your retrieval layer. If the model returns malformed JSON, retry once with a stricter schema reminder. If it fails again, fall back to the original query without expansion and log the failure for later prompt debugging.

Model choice and latency: For most production use cases, a fast instruction-tuned model like GPT-4o-mini, Claude Haiku, or Gemini Flash is sufficient. The task is structured generation, not deep reasoning. If your domain terminology is highly specialized (e.g., legal, medical, engineering), test whether a larger model produces more accurate domain synonyms before defaulting to the smaller one. Cache expansion results by query+language+domain hash to avoid redundant LLM calls for repeated queries. Set a hard timeout (e.g., 2 seconds) on the expansion call; if it exceeds the timeout, proceed with the original query and flag the timeout in your observability dashboard. Validation checks: Before using the expansion map, verify that (a) the output contains the original query terms as keys, (b) no synonym list is empty, (c) the source_language field matches the expected target language code, and (d) the total number of expanded terms does not exceed a configured maximum (to prevent retrieval query bloat). If any check fails, discard the expansion and use the original query.

Observability and evals: Log the full prompt, response, latency, and validation status to your tracing system (e.g., LangSmith, Braintrust, or custom logging). For offline evaluation, build a golden dataset of 50–100 query+language+domain triples with expected synonym sets reviewed by a native speaker or domain expert. Run the prompt against this dataset weekly and measure precision (are the generated synonyms actually relevant?) and recall (did the prompt miss important domain terms?). Track semantic drift by back-translating expanded terms and comparing them to the original query using a sentence similarity model. If drift exceeds a threshold, flag the prompt for review. Human review gate: For high-risk domains (legal, healthcare, finance), route a sample of expansion outputs to a human reviewer who can flag incorrect or misleading synonyms. Use these flagged cases to update your few-shot examples or domain glossary. What to avoid: Do not use this prompt as the sole retrieval query—always combine expanded terms with the original query in a hybrid or weighted retrieval strategy. Do not expand queries that are already highly specific and technical without first checking whether expansion introduces noise. And do not skip the validation step; malformed expansion maps will silently degrade retrieval quality in ways that are hard to diagnose without structured logging.