Cross-Lingual Acronym Expansion Prompt for Retrieval

This prompt is designed for a specific pre-retrieval task: detecting acronyms in a user's source-language query and expanding them into their correct full forms in the target retrieval language. The ideal user is a search engineer or RAG operator managing a multilingual corpus in a technical domain—such as engineering, finance, or medicine—where acronyms are pervasive and language-specific. The required context is a user query containing one or more acronyms, along with enough surrounding text to disambiguate their meaning. For example, a German engineer might query 'CPU Auslastung', where 'CPU' is the acronym. A direct translation of 'CPU' is useless; the system must know to expand it to 'Central Processing Unit' for an English-language index. The core job-to-be-done is resolving this ambiguity to prevent retrieval failure, not performing general translation or query expansion.

Use this prompt when your vector or keyword index is in a language different from the user's query and your domain contains acronyms that do not have a one-to-one mapping across those languages. It is a targeted surgical tool, not a general-purpose query rewriter. Do not use this prompt for queries without acronyms, for general synonym expansion, or when the source and target languages share identical acronym conventions. It is also inappropriate for low-risk, non-technical domains where acronym ambiguity is unlikely to cause retrieval failure. The prompt works best as a discrete step in a retrieval pipeline, placed after language detection and before query translation or execution. If your pipeline already includes a high-fidelity translation step, you may still need this prompt first, because a translator will often preserve the source acronym rather than expanding it into the target language's full form.

Before integrating this prompt, verify that your retrieval failures are genuinely caused by acronym mismatch. A common anti-pattern is applying this expansion to every query, which adds latency and can introduce errors when no acronym is present. Instead, use a lightweight classifier or simple pattern match to gate the prompt's execution. The next step after reading this section is to review the prompt template and understand the required input variables, which are detailed in the following section.

This prompt template is designed to be pasted directly into your orchestration layer. It instructs the model to detect acronyms in a user's query, disambiguate them based on the provided domain context, and expand them into the correct full form in the target language for retrieval. The core challenge it solves is that a direct translation of an acronym is often meaningless; the model must first resolve the acronym to its canonical meaning in the source language and then find the equivalent standard term in the target language's technical corpus.

textCopy
You are an expert technical translator and information retrieval specialist. Your task is to prepare a user query for a multilingual document search. You will receive a query in a [SOURCE_LANGUAGE] and must expand any acronyms it contains into their full, unambiguous forms in the [TARGET_LANGUAGE] to improve search recall.

Follow these steps:
1. Identify all acronyms in the [INPUT_QUERY]. An acronym is typically an all-caps abbreviation pronounced as a word or letter by letter.
2. For each acronym, determine its most likely full form in the [SOURCE_LANGUAGE] based on the provided [DOMAIN_CONTEXT]. If the acronym is ambiguous, choose the expansion most relevant to the context.
3. Translate the full form concept, not the acronym letters, into the precise, domain-appropriate term in the [TARGET_LANGUAGE]. Do not simply transliterate.
4. Construct a new query string in the [TARGET_LANGUAGE] where each acronym is replaced by its expanded target-language term. Keep all non-acronym words translated normally.

[DOMAIN_CONTEXT]: "[DESCRIPTION_OF_TECHNICAL_DOMAIN]"
[INPUT_QUERY]: "[USER_QUERY_TEXT]"

You must output a single JSON object with the following structure. Do not include any other text.
{
  "target_language_query": "The fully rewritten query with acronyms expanded.",
  "expansions": [
    {
      "source_acronym": "ACR",
      "source_expansion": "Full Form in Source Language",
      "target_expansion": "Full Form in Target Language"
    }
  ],
  "unresolved_acronyms": ["Any acronym you could not confidently resolve"]
}

To adapt this template, replace the square-bracket placeholders at runtime. [SOURCE_LANGUAGE] and [TARGET_LANGUAGE] should be standard language names or ISO codes. [DOMAIN_CONTEXT] is critical for disambiguation; a value like 'medical device regulatory affairs' will lead to a different expansion for 'CAPA' than 'software engineering'. [INPUT_QUERY] is the raw user string. Before deploying, test this prompt with a golden dataset of queries containing ambiguous acronyms (e.g., 'PCR' in a biology vs. manufacturing context) and validate that the target_language_query retrieves the expected documents from your target-language index. For high-stakes domains like legal or clinical retrieval, always log the expansions list for human auditability to catch incorrect disambiguations before they cause a critical miss.

This prompt is designed to sit as a pre-retrieval expansion step in your RAG pipeline. It takes a user's query in a source language, detects any acronyms, and expands them into their full forms in the target retrieval language. The output is a modified query string that you then pass to your vector, keyword, or hybrid search index. Because acronym expansion is inherently ambiguous—the same acronym can map to different terms across languages and domains—you must treat this step as a high-recall, precision-optional operation. The goal is to add candidate terms to the retrieval query, not to make a final disambiguation decision. The downstream retrieval and reranking stages will handle precision.

To wire this into your application, place the prompt inside a dedicated expansion service or a pre-retrieval hook. The service should accept the user's raw query, the source language code (ISO 639-1), the target retrieval language code, and an optional domain context string (e.g., 'medical', 'military', 'IT'). Construct the prompt by injecting these values into the [INPUT_QUERY], [SOURCE_LANGUAGE], [TARGET_LANGUAGE], and [DOMAIN_CONTEXT] placeholders. Call the LLM with a low temperature (0.0–0.2) to maximize deterministic behavior. Parse the response expecting a JSON object with an expanded_query field and an expansions array of objects, each containing acronym, expansion, and confidence. Validate the output schema strictly: if the JSON is malformed, retry once with a stronger schema constraint in the system prompt. If the expanded_query is identical to the input and the expansions array is empty, log this as a no-op and pass the original query through to retrieval unchanged.

For production observability, log every expansion decision: the input query, detected acronyms, proposed expansions, confidence scores, and the final expanded query. This log becomes critical for debugging retrieval failures. If a user reports missing results, you can trace whether an acronym was missed, expanded incorrectly, or expanded with low confidence. Implement a confidence threshold (e.g., 0.7) below which you either skip the expansion or append it with a lower weight in hybrid search. For high-risk domains like healthcare or legal, route low-confidence expansions to a human review queue before they affect retrieval. Never silently drop acronyms; always log the decision. Finally, build an eval harness that tests the prompt against a golden set of queries with known acronyms across your supported language pairs. Measure both acronym detection recall and expansion precision. Run this eval on every prompt version change before deployment.

When choosing a model, prefer one with strong multilingual performance and explicit JSON mode support. Models like GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro work well. Avoid models that struggle with code-switching or low-resource language pairs unless you've validated them on your specific language combinations. If you're operating in a low-resource language pair, consider adding a pivot-language fallback: expand acronyms in the source language first, translate the expanded query to English, then to the target language. This adds latency but improves coverage. Finally, never use the expanded query to modify the user-visible question in the UI; the expansion is an internal retrieval artifact. The user should see their original query, while the system uses the expanded form solely for search.