Profile-Aware Cross-Lingual Query Expansion Prompt

This prompt is designed for global product teams operating retrieval-augmented generation (RAG) systems over multilingual corpora. The core job-to-be-done is expanding a user's query across multiple languages while respecting three critical constraints: the user's declared language preferences, their regional or locale scope, and their role-based terminology. A direct translation of a query often fails because it misses idiomatic expressions, domain-specific jargon, or regional variants. This prompt produces language-weighted query variants that improve recall in multilingual indexes without drowning the retrieval step in irrelevant translations.

Use this prompt when your retrieval index contains documents in multiple languages and your users have a known profile that includes a preferred language, an accepted locale list, and a role or department. The prompt requires these inputs as structured context: [USER_LANGUAGE_PREFERENCES], [USER_LOCALE], and [USER_ROLE_TERMINOLOGY]. It is not appropriate for anonymous users, single-language corpora, or scenarios where the user's language preferences are unknown. Avoid using this prompt when the retrieval system already performs independent translation at the document level, as double-expansion can introduce noise. The prompt is also not a replacement for a full machine translation system; it generates retrieval-oriented expansions, not publication-quality translations.

Before integrating this prompt into a production pipeline, ensure you have a mechanism to pass the user's profile context reliably. The output is a structured list of language-weighted query variants, which your application should parse and dispatch to the appropriate multilingual retrieval backends. Start by testing with a small set of known multilingual queries where you can measure recall improvements against a baseline of monolingual retrieval. Monitor for over-expansion, where too many language variants dilute precision, and for terminology drift, where role-specific terms are incorrectly translated into generic equivalents. If the user's role involves regulated or compliance-sensitive content, add a human review step or an automated check to ensure expanded queries do not inadvertently broaden the access scope beyond what the user is permitted to see.

The following prompt template is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It accepts a user query, a structured user profile, and a set of operational constraints, then produces a list of language-weighted query variants suitable for feeding into a multilingual retrieval pipeline. Every placeholder is enclosed in square brackets and must be replaced with concrete values at runtime. The template assumes the model has no prior knowledge of the user or the corpus languages; all necessary context must be supplied through the placeholders.

codeCopy
You are a cross-lingual query expansion engine for a multilingual retrieval system. Your task is to expand a user's query into multiple language-specific variants while strictly respecting the user's language preferences, regional scope, and role-based terminology.

## USER PROFILE
- Preferred Languages (in priority order): [USER_PREFERRED_LANGUAGES]
- Region/Locale: [USER_REGION]
- Role/Department: [USER_ROLE]
- Role-Specific Terminology Mapping: [ROLE_TERMINOLOGY_MAP]
- Access Scope Constraints: [ACCESS_SCOPE]

## INPUT QUERY
[USER_QUERY]

## CORPUS LANGUAGES
[CORPUS_LANGUAGES]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "original_query": "string",
  "expansions": [
    {
      "language": "ISO 639-1 code",
      "query_text": "expanded query in target language",
      "weight": 0.0-1.0,
      "rationale": "why this variant was generated",
      "terminology_sources": ["list of role-specific terms used"],
      "region_adaptations": ["list of locale-specific adjustments made"]
    }
  ]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Parse the user query and identify key concepts, entities, and intent.
2. For each language in [CORPUS_LANGUAGES], generate an expanded query variant that:
   - Translates the core query accurately while preserving intent.
   - Injects role-specific terminology from [ROLE_TERMINOLOGY_MAP] where applicable.
   - Adapts region-specific terms, units, formats, and entity references to match [USER_REGION].
   - Respects [ACCESS_SCOPE] by not introducing terms or concepts outside the user's authorized domains.
3. Assign a weight to each variant based on:
   - Match with [USER_PREFERRED_LANGUAGES] priority order (higher priority = higher weight).
   - Relevance of the language to the query's detected intent and entities.
4. If the user query contains terms that have no equivalent in a target language, preserve the original term and note it in the rationale.
5. If [ACCESS_SCOPE] prohibits expansion into certain terminology domains, omit those terms and document the omission in the rationale.
6. Return ONLY the JSON object. No additional commentary.

To adapt this template for your system, replace each placeholder with runtime data. [USER_PREFERRED_LANGUAGES] should be an ordered list of ISO 639-1 codes pulled from the user's profile settings. [ROLE_TERMINOLOGY_MAP] is a dictionary mapping generic terms to role-specific equivalents (e.g., {"customer": "client", "revenue": "ARR"}). [ACCESS_SCOPE] defines the document partitions, sensitivity levels, or topic domains the user is permitted to search. [CONSTRAINTS] can include additional rules such as maximum variants per language, forbidden terms, or required citation formats. [EXAMPLES] should contain one or two few-shot demonstrations showing correct expansion behavior for your domain. Before deploying, validate that the output JSON conforms to the schema and that no variant introduces terms outside the user's access scope. For high-risk domains, route outputs through a human review step before retrieval execution.

This prompt is designed to sit between the user's raw query and your multilingual retrieval backends. It should be called as a pre-retrieval step, receiving the user's original query, their language preferences, regional scope, and role-based terminology profile as inputs. The output is a structured set of language-weighted query variants that downstream retrievers can execute in parallel or sequence.

Wiring the prompt into your application requires a few concrete integration points. First, assemble the user profile context from your identity and personalization services: pull the user's preferred languages, their region or locale code, their department or role, and any team-specific terminology glossaries. Inject these into the [USER_LANGUAGE_PREFERENCES], [USER_REGION], [USER_ROLE], and [ROLE_TERMINOLOGY] placeholders. The [QUERY] placeholder receives the raw user input. For the model, prefer a fast, instruction-following model like GPT-4o-mini, Claude 3.5 Haiku, or Gemini 1.5 Flash to keep latency low in the retrieval path. Set temperature to 0 or very low to ensure deterministic expansion behavior. The output should be parsed as JSON and validated against a strict schema: expect an array of objects, each containing a query_variant string, a language code, and a weight float between 0 and 1. Reject any output where weights do not sum to at least 0.9 or where language codes don't match the user's allowed set.

Validation and retry logic is critical here. Implement a post-generation validator that checks: (1) the output is valid JSON, (2) every variant has a non-empty query string, (3) language codes are valid ISO 639-1 or BCP-47 tags, (4) weights are positive and normalized, and (5) no variant introduces terminology from outside the user's role glossary. If validation fails, retry once with the error message appended to the prompt as a correction hint. If the retry also fails, fall back to a simpler expansion strategy—such as direct translation of the original query into the user's preferred languages without terminology injection—and log the failure for review. For high-stakes domains like legal or medical retrieval, route any fallback outputs to a human reviewer before retrieval executes.

Observability and logging should capture the original query, the user profile snapshot used, the generated variants, validation results, and which variants were actually executed against which indexes. This trace data is essential for debugging relevance issues: if a user reports poor results, you can replay the exact expansion and see whether terminology injection failed, language weights were miscalibrated, or the user's profile was stale. Store these traces in your existing observability platform and set up alerts for sudden spikes in validation failures or fallback activations, which often signal profile data quality issues or model behavior drift.