Multi-Lingual Synonym Expansion Prompt Template

This prompt is designed for global product teams and RAG developers who need to expand a user query with synonyms and conceptual equivalents across multiple languages before retrieval. The core job-to-be-done is improving recall in multilingual search systems where a user may query in one language but relevant documents exist in others. Unlike simple translation or monolingual synonym generation, this prompt produces language-aware expansions that account for idiomatic differences, false cognates, and cross-lingual relevance. The ideal user is an engineer or search relevance specialist who already has a defined set of target languages for their retrieval index and needs to bridge the gap between how users express intent and how documents are written across those languages.

Use this prompt when your retrieval pipeline spans a multilingual corpus and you observe recall gaps that cannot be explained by poor indexing or embedding quality alone. Concrete signals that you need this prompt include: users reporting that relevant documents exist but are not surfaced, A/B tests showing lower recall for non-English queries against an English-heavy index, or manual inspection revealing that user terminology differs from document terminology in ways that direct translation fails to capture. The prompt requires you to provide the user's original query, the source language, a list of target languages for expansion, and optionally a domain context string to constrain expansions to relevant terminology. You should not use this prompt for simple monolingual synonym generation, when you lack a defined set of target languages, or when your retrieval index is effectively monolingual and translation alone would suffice.

Before adopting this prompt, verify that your retrieval infrastructure can accept multiple query variants and fuse results across languages. The prompt outputs structured expansion candidates per target language, but your application must handle the downstream work of executing parallel retrievals, merging result sets, and potentially re-ranking across languages. If your pipeline cannot support multi-query retrieval or cross-lingual fusion, start by addressing those architectural prerequisites. Also avoid using this prompt when latency budgets are extremely tight and you cannot afford the additional retrieval round-trips that multi-lingual expansion introduces. In those cases, consider pre-computing cross-lingual document embeddings or using a multilingual embedding model that aligns representations across languages without query-side expansion.

This prompt template generates multi-lingual synonym expansions from a user query. Unlike basic translation-based expansion, it accounts for idiomatic differences, false cognates, and language-specific conceptual equivalents that direct translation would miss. The prompt expects a source query, a target language, and optional domain context. It produces a structured output with expanded terms, confidence scores, language detection results, and explicit false cognate warnings. Use this when your retrieval system spans multiple languages and naive translation would produce misleading or irrelevant expansions.

textCopy
You are a multi-lingual query expansion specialist. Your task is to expand a user query with synonyms, related terms, and conceptual equivalents in the target language while accounting for idiomatic differences and false cognates.

## INPUT
- Source Query: [INPUT_QUERY]
- Source Language: [SOURCE_LANGUAGE]
- Target Language: [TARGET_LANGUAGE]
- Domain Context (optional): [DOMAIN_CONTEXT]
- Domain Glossary (optional): [DOMAIN_GLOSSARY]

## CONSTRAINTS
- Preserve the original query intent and scope.
- Do not expand negated terms or invert exclusionary intent.
- Flag any term that is a known false cognate between the source and target languages.
- If the source query contains named entities, product names, or proper nouns, preserve them without inappropriate synonym replacement.
- Respect the token budget: produce no more than [MAX_EXPANDED_TERMS] expanded terms.
- If domain context is provided, prefer domain-appropriate synonyms over generic alternatives.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "source_query": "string",
  "detected_source_language": "string",
  "language_confidence": 0.0,
  "target_language": "string",
  "expanded_terms": [
    {
      "original_term": "string",
      "expanded_terms": ["string"],
      "language": "string",
      "confidence": 0.0,
      "rationale": "string",
      "false_cognate_warning": "string or null",
      "source_attribution": "string or null"
    }
  ],
  "preserved_entities": ["string"],
  "negation_boundaries": ["string"],
  "warnings": ["string"]
}

## EXAMPLES
Source Query: "I need a prescription for pain relief"
Source Language: English
Target Language: Spanish

Expected output includes:
- "prescription" → "receta" (not "prescripción", which is a false cognate meaning statute of limitations)
- "pain relief" → "alivio del dolor", "analgésico"
- Preserved entity: none
- False cognate warning on "prescripción"

## RISK_LEVEL: [RISK_LEVEL]
If RISK_LEVEL is "high", include source attribution for every expanded term and flag low-confidence expansions for human review.

Adapt this template by replacing the square-bracket placeholders with your application values. [INPUT_QUERY] receives the user's original query string. [SOURCE_LANGUAGE] and [TARGET_LANGUAGE] should use ISO 639-1 codes or full language names consistently. [DOMAIN_CONTEXT] is optional but strongly recommended for specialized domains like legal, medical, or technical fields where generic synonyms cause relevance drift. [DOMAIN_GLOSSARY] accepts a mapping of canonical terms to accepted synonyms, which the model uses for source attribution. [MAX_EXPANDED_TERMS] prevents unbounded expansion that would bloat retrieval queries. [RISK_LEVEL] controls whether the output requires source attribution and human review flags. For production use, validate the output JSON against the schema before passing expanded terms to your retrieval backend. Run cross-lingual relevance checks by back-translating expanded terms and measuring semantic similarity to the original query.

The multi-lingual synonym expansion prompt is not a standalone utility; it is a pre-retrieval stage that must be integrated into a broader search or RAG pipeline. The typical call pattern is: detect the query language, route to the expansion prompt with the appropriate language context and domain glossary, validate the output against a schema contract, merge expanded terms into the retrieval query, and log the expansion trace for offline evaluation. This prompt should sit between the user's raw query and the retrieval backend, whether that backend is a sparse keyword index, a dense vector store, or a hybrid system. Because the prompt generates terms across languages, the harness must handle Unicode normalization, language tag propagation, and downstream index compatibility.

For production integration, wrap the prompt call in a function that accepts a [QUERY], [SOURCE_LANGUAGE], [TARGET_LANGUAGES] list, and an optional [DOMAIN_GLOSSARY]. The function should enforce a strict output schema: a JSON array of objects, each containing term, language, confidence, source (one of glossary, model, idiomatic), and exclude_reason (nullable). Validate this schema immediately after the model response. If validation fails, retry once with a repair prompt that includes the schema and the malformed output. If the retry also fails, log the failure and fall back to the original query without expansion. For high-recall use cases where missing synonyms degrade user experience, consider a secondary expansion model or a cached glossary lookup as a fallback path.

Language detection is a critical upstream dependency. Do not trust the expansion prompt to infer the source language implicitly; use a dedicated language detection step before calling the expansion prompt. Route queries with detected languages not in your supported set to a default expansion path or skip expansion entirely. For cross-lingual expansion, where the user queries in one language and documents exist in others, the harness must track which expanded terms belong to which target language so the retrieval layer can query the appropriate language-specific index shards. Store the full expansion trace—original query, detected language, expanded terms with confidence scores, and the final retrieval query—in your observability system. This trace is essential for debugging recall gaps, measuring expansion precision, and detecting term drift over time.

Model choice matters. For high-throughput, low-latency pipelines, use a smaller, faster model with strong multilingual performance and keep the prompt concise. For high-precision domains like legal or medical search, use a more capable model and add a human review step for expansions below a confidence threshold. Set a confidence floor (e.g., 0.7) and discard terms below it before retrieval. Monitor the discard rate; if it exceeds 20%, your glossary coverage or prompt instructions likely need adjustment. Also implement a term budget cap per query to prevent retrieval query bloat. If the expansion prompt returns more terms than your retrieval backend can handle efficiently, rank by confidence and truncate.

Finally, build an offline evaluation loop. Periodically run a golden query set through the expansion harness and compare outputs against known-good expansions. Track precision, recall, and term collision rates per language pair. Use this eval harness to detect regressions when you update the prompt, change models, or modify the domain glossary. For regulated domains, ensure every expansion trace is auditable with source attribution, and flag any expansion that lacks a glossary or model rationale for human review before it enters the retrieval path.