Multilingual Metadata Filter Extraction Prompt

This prompt is for platform engineers and RAG architects who need to extract structured, language-agnostic filter objects from natural language queries written in any language. The core job is to parse a user's question—such as 'find PDF reports from last month about server outages' or 'buscar documentos de cumplimiento del año pasado'—and output a standardized JSON filter payload with fields like date_range, source_type, and category. This filter object is then passed directly to a retrieval backend's structured filtering layer, enabling hybrid search that combines vector similarity with precise metadata constraints without requiring the user to know the underlying schema or query language.

Use this prompt when your retrieval system supports structured metadata filtering alongside vector or keyword search and you serve a multilingual user base. It is appropriate when queries contain implicit or explicit constraints on document type, recency, author, region, or category that must be enforced at the index level. The prompt assumes the target filter schema is known and stable; you must supply that schema as part of the [OUTPUT_SCHEMA] placeholder. Do not use this prompt for generating the actual search query text, for translating the user's question into another language, or for answering the question itself—it is strictly a filter extraction step in a larger retrieval pipeline.

Avoid this prompt when your retrieval backend lacks structured metadata fields, when the query contains no filterable constraints, or when the user's language is so low-resource that the model cannot reliably parse entities and date expressions. It is also the wrong tool for queries that require deep semantic interpretation of the filter criteria—for example, 'show me the most influential papers'—because 'influential' is not a metadata field. In such cases, pair this prompt with an intent classifier that routes non-filterable queries to a different retrieval strategy. For high-stakes domains like legal discovery or compliance audits, always add a human review step before the extracted filters are applied to the retrieval index, as a misparsed date range or category can silently exclude critical documents.

This section provides the core prompt template for extracting structured metadata filters from a user query, regardless of the query's language. The prompt is designed to be dropped into a retrieval pipeline where a natural language query must be translated into concrete filter clauses—date ranges, source types, categories, and other facets—that a search backend can apply. The template uses square-bracket placeholders so you can swap in your own taxonomy, output schema, and examples without rewriting the instruction logic.

textCopy
You are a metadata filter extraction system. Your job is to read a user query in any language and extract structured, language-agnostic filter constraints. You output only valid JSON conforming to the schema below. Do not answer the query. Do not summarize. Only extract filters.

## INPUT QUERY
[QUERY]

## AVAILABLE FILTER FIELDS
[FILTER_SCHEMA]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "filters": [
    {
      "field": "string (must match an available filter field)",
      "operator": "eq | gte | lte | range | in | contains",
      "value": "string | number | array (depends on operator)",
      "confidence": 0.0-1.0
    }
  ],
  "unmapped_terms": ["string"],
  "query_language": "ISO 639-1 code or 'unknown'"
}

## RULES
1. Extract only filters that are explicitly stated or strongly implied in the query.
2. Map date expressions like "last month," "this year," "Q3" to concrete date ranges using the current date: [CURRENT_DATE].
3. Map category or type mentions to the exact values in the available filter fields. If no exact match exists, place the term in `unmapped_terms`.
4. Set `confidence` based on how clearly the filter is stated. Use 0.9+ for explicit mentions, 0.5-0.8 for strong implications, and below 0.5 for guesses.
5. If no filters are found, return an empty `filters` array.
6. Detect the query language and set `query_language` to the ISO 639-1 code.

## EXAMPLES
[EXAMPLES]

## CONSTRAINTS
[CONSTRAINTS]

To adapt this template for your system, replace [FILTER_SCHEMA] with your actual filterable fields, their types, and allowed values. For example, a documentation platform might define fields like product_area, doc_type, last_updated, and audience. Replace [CURRENT_DATE] at runtime with today's date in ISO format so relative time expressions resolve correctly. Populate [EXAMPLES] with 2-4 few-shot examples that show the mapping from queries in your most common languages to the expected JSON output. Use [CONSTRAINTS] to add domain-specific rules, such as "never extract PII" or "default to the current product version if unspecified." The output schema is intentionally flat and deterministic—avoid nesting or optional fields that complicate downstream parsing. If your retrieval backend expects a different filter DSL (e.g., Elasticsearch bool queries), add a post-processing step rather than complicating the prompt.

This prompt is designed to sit between the user's raw query and your retrieval backend. It is not a standalone chatbot. The typical integration pattern is: receive a user query in any language, call this prompt to extract a standardized JSON filter object, validate the output against your filter schema, merge the extracted filters with any user-session or application-level defaults, and then pass the combined filter to your vector, keyword, or hybrid search engine. The prompt expects a single user query string as [QUERY] and an optional [FILTER_SCHEMA] describing the valid filter fields, types, and allowed values for your system. The output is a JSON object with keys matching your schema and null values for any filter not present in the query.

In production, you should wrap the LLM call in a harness that handles three things: schema validation, retry with repair, and logging. First, validate the returned JSON against your expected filter schema. If a field contains an unexpected value type or an enum value outside your allowed set, reject it and either fall back to an empty filter or trigger a repair prompt. Second, implement a single retry: if validation fails, send the original query, the invalid output, and the validation error message back to the model with a repair instruction. If the retry also fails, log the failure and proceed with a safe default (e.g., no metadata filter, or a broad date range). Third, log every extraction attempt—query text, detected language, raw model output, validation result, and final filter applied—so you can monitor extraction accuracy and drift over time. For high-stakes use cases like legal or financial document retrieval, add a human review flag when the model's confidence appears low or when the extracted filter would significantly narrow the result set.

Model choice matters here. This prompt relies on instruction-following and structured JSON generation, so prefer models with strong function-calling or JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet, or fine-tuned open-weight models with grammar-constrained decoding). Avoid models that struggle with multilingual input or that frequently hallucinate enum values. If your retrieval backend uses Elasticsearch, OpenSearch, or a similar engine, map the extracted JSON directly to a bool query's filter clause. For vector databases that support metadata filtering (Pinecone, Weaviate, Qdrant), convert the JSON to the database's native filter syntax. Do not pass the raw prompt output to the retrieval engine without validation—an unexpected filter field can silently break your query or return zero results. Next step: build a small golden dataset of 20–30 multilingual queries with known expected filters and run this prompt against it before deploying, using exact-match and partial-match accuracy as your eval metrics.