Language-Agnostic Intent Detection Prompt for Query Rewriting

This prompt is designed for RAG system architects and search relevance engineers who need to route multilingual user queries to different rewriting and retrieval pipelines based on the user's underlying intent. The core job-to-be-done is to classify a query—regardless of its source language—into a stable set of intent categories such as factual lookup, comparison, procedure, summary, or clarification. This classification then acts as a dispatch signal, ensuring that a query like 'compare the battery life of X and Y' is rewritten for a comparison retrieval strategy, while 'how do I reset X' triggers a procedural retrieval strategy. Without this step, a single, monolithic retrieval approach often produces poor results because the same surface question structure can demand fundamentally different evidence structures depending on what the user actually wants to accomplish.

Use this prompt when you operate a multilingual corpus where users query in multiple languages, and you have already built or plan to build distinct retrieval pipelines optimized for different intent types. The prompt requires no external context beyond the raw user query; it is designed to be stateless and language-agnostic. It is particularly valuable in global product support, enterprise search, or e-commerce settings where a query in Japanese, German, or Arabic should be routed with the same intent-detection accuracy as an English query. The output is a structured JSON object containing the detected intent label and a confidence score, which your application can use to select the appropriate downstream rewriting prompt and retrieval backend. You should validate the output against an allowed intent taxonomy and implement a fallback routing rule for low-confidence classifications.

Do not use this prompt when your application context already provides the user's intent through UI affordances, such as a dedicated 'troubleshooting' search box versus a 'product comparison' tool. It is also unnecessary if you have a monolingual corpus with highly uniform query patterns where a single retrieval strategy works well. Avoid this prompt if your latency budget cannot tolerate an additional classification step before retrieval, or if you lack the engineering capacity to build and maintain the separate retrieval pipelines that the intent labels are meant to route to. In high-stakes domains like healthcare or legal research, always route low-confidence classifications to a human review queue rather than allowing an uncertain intent to silently degrade retrieval quality.

This template provides the core system instructions for a language-agnostic intent classifier. Its job is to look past the surface language of a user's query and identify the underlying need—such as a factual lookup, a comparison, or a procedure. The output is a structured intent label, not a rewritten query. This classification is the critical first step in a retrieval pipeline, as it determines which rewriting, expansion, or decomposition strategy will be applied next. Before pasting this prompt, you must define your own intent taxonomy and provide representative examples for each class. A generic taxonomy will produce generic results; the model's performance is directly tied to the specificity of your labels and the quality of your few-shot examples.

codeCopy
You are an intent classifier for a multilingual retrieval system. Your task is to analyze a user's query and determine the single underlying intent, independent of the language in which the query is written. You will output a structured JSON object with the intent label and a confidence score.

# INTENT TAXONOMY
Classify every query into exactly one of the following intents:
[INTENT_TAXONOMY]

# CLASSIFICATION RULES
- Base your classification on the semantic need expressed by the query, not on keyword matching.
- If the query is ambiguous or could reasonably fit multiple intents, choose the most likely primary intent and set the confidence score accordingly.
- Do not use the query's language as a classification signal. A factual lookup in French and a factual lookup in Japanese should both map to the same intent label.
- If the query does not fit any defined intent, classify it as "[FALLBACK_INTENT]" with a low confidence score.

# OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "intent": "string (one of the defined intent labels)",
  "confidence": number (0.0 to 1.0),
  "rationale": "string (brief explanation of the classification in English)"
}

# FEW-SHOT EXAMPLES
[EXAMPLES]

# INPUT
[INPUT]

To adapt this template, start by replacing [INTENT_TAXONOMY] with your own list of intent labels and concise descriptions. A retrieval system might use labels like factual_lookup, comparison, procedural_how_to, summary_request, and troubleshooting. Next, replace [FALLBACK_INTENT] with a label like unknown or other to handle out-of-scope queries. The [EXAMPLES] placeholder is the most important to fill: provide at least 3-5 diverse few-shot examples per intent, covering multiple languages and edge cases. Each example should show the input query and the correct JSON output. Finally, [INPUT] is the runtime variable your application will inject before each model call. For high-stakes routing decisions, implement a post-processing check: if the confidence score falls below a threshold (e.g., 0.7), route the query to a human review queue or a default fallback strategy rather than proceeding automatically.

This prompt is designed to sit at the entry point of a multilingual retrieval pipeline, before any translation or expansion occurs. Its job is narrow: classify the user's underlying intent from the raw query text alone, independent of the query language. The output is a structured intent label and confidence score that downstream components use to select the appropriate rewriting strategy. Do not use this prompt to generate rewritten queries, translate text, or answer questions. It is a classification router, not a retrieval step.

Wire the prompt into your application as a synchronous pre-retrieval step. Accept the raw user query string as the [USER_QUERY] input. The model should return a JSON object with intent (one of the predefined labels such as factual_lookup, comparison, procedure, summary, opinion, or clarification) and confidence (a float between 0.0 and 1.0). Validate the output shape immediately: reject any response where intent is not in your allowed enum or confidence is outside range. If validation fails, retry once with a stricter system instruction that emphasizes the required schema. On a second failure, log the raw response and default to intent: factual_lookup with confidence: 0.0 so the pipeline degrades gracefully rather than blocking the user. For high-traffic systems, consider caching intent classifications for identical query strings to reduce latency and cost.

Model choice matters here. This is a classification task with a small output space, so a fast, cost-efficient model like GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight classifier is appropriate. Avoid using large reasoning models for this step unless you have evidence that intent boundaries are genuinely ambiguous. If you observe frequent misclassifications between comparison and factual_lookup, add few-shot examples to the prompt that illustrate the distinction in multiple languages. Log every classification alongside the downstream rewriting strategy chosen and the eventual retrieval quality metrics. This traceability lets you measure whether intent misclassification is a root cause of poor retrieval and adjust the prompt or routing map accordingly. Never send the raw user query to a retrieval index without first passing it through this intent router and the corresponding rewriting prompt that the intent selects.