Language Detection and Query Routing Prompt Template

This prompt is for orchestration engineers building the dispatch layer of a multilingual RAG system. Its job is to accept a user query in any language, detect the source language, identify which target index languages are needed for retrieval, and route the query to the appropriate translation and expansion pipeline with a confidence score. Use this prompt when your retrieval indexes span multiple languages and you need a single entry point that decides where to send each query before any translation or expansion happens. This is a classification and routing prompt, not a translation prompt. It does not rewrite the query. It decides which downstream pipeline should handle it.

The ideal user is an engineer integrating this prompt into a server-side request path, such as an API endpoint that receives a user query and must dispatch it to language-specific retrieval workers. You should have a known set of available target index languages and a mapping of which downstream pipelines handle each language pair. The prompt expects a raw user query and a list of supported target languages as input. It returns a structured routing decision: the detected source language, one or more target languages, a confidence score, and a recommended pipeline identifier. This output should be validated programmatically before any downstream call is made—check that the target languages exist in your system and that the confidence score meets a minimum threshold before proceeding.

Do not use this prompt when you have only one retrieval language, when the query has already been translated, or when you need the prompt to perform the translation itself. This prompt is also inappropriate for real-time chat where per-message latency must be under 200ms and a lightweight, heuristic-based language detector would suffice. If your system already knows the user's language preference from their profile or session, bypass this prompt and route directly. The primary failure mode is misclassification of low-resource or code-switched queries; always pair this prompt with a fallback routing rule and log routing decisions for offline evaluation. After reading this section, proceed to the prompt template to copy and adapt it for your language coverage.

This prompt template is designed to sit at the entry point of your multilingual retrieval dispatch layer. It accepts a raw user query and returns a structured routing decision: the detected source language, the target index languages needed for retrieval, and a confidence score that your orchestration layer can use to decide whether to proceed, request clarification, or escalate. Replace each square-bracket placeholder with values from your system's configuration before deploying.

textCopy
SYSTEM:
You are a language detection and query routing dispatcher for a multilingual retrieval system. Your job is to analyze a user query, detect its primary language, determine which target index languages are needed to retrieve relevant documents, and output a structured routing decision with a confidence score.

INPUT:
User Query: [USER_QUERY]

AVAILABLE INDEX LANGUAGES:
[AVAILABLE_LANGUAGES_LIST]

ROUTING RULES:
[ROUTING_RULES]

OUTPUT_SCHEMA:
{
  "source_language": "ISO 639-1 code",
  "source_language_confidence": 0.0-1.0,
  "target_index_languages": ["ISO 639-1 codes"],
  "routing_confidence": 0.0-1.0,
  "requires_clarification": boolean,
  "clarification_reason": "string or null",
  "code_switching_detected": boolean,
  "code_switched_languages": ["ISO 639-1 codes or null"],
  "routing_strategy": "direct | translate | expand | decompose | clarify"
}

CONSTRAINTS:
- If source_language_confidence is below [MIN_CONFIDENCE_THRESHOLD], set requires_clarification to true.
- If the query contains multiple languages (code-switching), set code_switching_detected to true and list all detected languages.
- If the query language matches an available index language and no cross-lingual retrieval is needed, set routing_strategy to "direct".
- If the query language is not in the available index languages, set routing_strategy to "translate" and include all available index languages as targets.
- If the query contains domain-specific terms that may exist in multiple languages, set routing_strategy to "expand" and include the source language plus target languages.
- If the query is ambiguous or underspecified, set routing_strategy to "clarify" and provide a clarification_reason.
- Never guess a language if confidence is below [MIN_CONFIDENCE_THRESHOLD].
- For queries shorter than [MIN_QUERY_LENGTH] characters, lower the confidence floor by [SHORT_QUERY_PENALTY].

EXAMPLES:
[FEW_SHOT_EXAMPLES]

Respond ONLY with valid JSON matching the OUTPUT_SCHEMA. No additional text.

To adapt this template for your system, replace [AVAILABLE_LANGUAGES_LIST] with the ISO 639-1 codes your retrieval indexes support, such as ["en", "fr", "de", "ja", "ko"]. Define [ROUTING_RULES] with any business logic specific to your corpus—for example, "legal documents exist only in English and German, so route all legal-domain queries to en and de regardless of source language." Set [MIN_CONFIDENCE_THRESHOLD] to a value like 0.7 for production or 0.5 for a preview environment where you prefer attempted retrieval over clarification. The [MIN_QUERY_LENGTH] and [SHORT_QUERY_PENALTY] parameters prevent overconfident language detection on single-word or two-word queries, which are inherently ambiguous. Provide [FEW_SHOT_EXAMPLES] that reflect your actual query distribution—include at least one code-switching example, one ambiguous short query, and one domain-specific query that should trigger expansion across multiple languages.

Before wiring this into your orchestration layer, validate the output against your schema in a test harness. Confirm that the model returns parseable JSON, that source_language is always a valid ISO 639-1 code from your configured set, and that routing_confidence drops appropriately on short or ambiguous inputs. For high-stakes retrieval where incorrect routing causes user-visible failures, add a human review step when requires_clarification is true or routing_confidence falls below a second, stricter threshold. Log every routing decision with the query, detected language, confidence, and chosen strategy so you can audit routing accuracy over time and feed misrouted queries back into your few-shot examples.

This prompt is designed to be the first step in a multilingual retrieval pipeline. It should be called before any translation, expansion, or retrieval occurs. The application layer must capture the raw user query, inject it into the [USER_QUERY] placeholder, and provide the [AVAILABLE_INDEX_LANGUAGES] list from the system's configuration. The model's response is a structured JSON object that the application parses to decide which downstream translation and retrieval pipelines to invoke. Do not use this prompt as a standalone classifier without wiring its output into actual routing logic.

The application must validate the model's JSON output against a strict schema before acting on it. Check that detected_language is a valid ISO 639-1 code, confidence_score is a float between 0.0 and 1.0, and target_index_languages contains only languages present in the provided [AVAILABLE_INDEX_LANGUAGES] list. If validation fails, log the raw output and the validation error, then fall back to a default routing strategy—typically translating the query into all available index languages with a low-confidence flag. For high-risk domains where retrieval precision is critical, implement a confidence threshold: if confidence_score is below 0.7, route the query to a human review queue or a clarification prompt before proceeding. Model choice matters here; smaller models may produce malformed JSON or hallucinate language codes, so prefer a model with strong structured output capabilities and set the response_format to json_object if the API supports it.

Wire the validated output into a dispatcher that selects the appropriate translation and expansion prompts from the cross-lingual playbook library. For each language in target_index_languages, spawn a parallel retrieval job using the corresponding translation prompt. Log the full routing decision—including the original query, detected language, confidence, and selected target languages—as a structured trace for observability. This trace is essential for debugging retrieval failures and for evaluating whether the language detector is making correct routing decisions over time. Avoid the temptation to skip validation or to treat the model's output as trustworthy without checks; language detection errors at this stage compound into wasted retrieval compute and irrelevant results downstream.