Categorical Facet Extraction Prompt Template

This prompt is designed for search engineers and platform teams who need to bridge the gap between natural language user queries and structured search APIs. The core job-to-be-done is extracting product attributes, content types, and categorical constraints—such as 'blue running shoes under $100' or '4K OLED TVs from Sony or LG'—and normalizing them into machine-readable facet key-value pairs. You should use this prompt when your hybrid search system already has a defined facet taxonomy and requires consistent, structured filter clauses that vector search alone cannot satisfy. The ideal user is someone integrating an LLM into a retrieval pipeline who needs deterministic, validated filter output to pass to a search backend like Elasticsearch, OpenSearch, or a custom API.

This prompt is not appropriate when you lack a defined facet taxonomy, as the model will hallucinate field names and values without a reference schema. It is also the wrong tool when the user query contains no categorical intent—for example, open-ended questions like 'tell me about running shoes' require query expansion or decomposition, not facet extraction. Do not use this prompt for generating SQL WHERE clauses directly against a production database without an intermediate validation layer, as the risk of injection or malformed syntax is high. If your use case involves extracting highly ambiguous attributes where multiple valid interpretations exist, pair this prompt with a disambiguation step or a confidence threshold to avoid silently applying incorrect filters.

Before implementing, ensure you have a well-defined facet schema with allowed field names, data types, and valid values. The prompt works best when you provide this schema as part of the [CONTEXT] placeholder, along with a few representative examples of query-to-filter mappings. In production, always validate the output against your schema before passing it to a search API, and log any extractions that fall below your confidence threshold for offline review. If your taxonomy changes frequently, version your schema and include the version identifier in the prompt context to prevent field name drift.

This prompt template is designed to be copied directly into your application code. It instructs the model to act as a facet extraction engine, parsing a natural language query and a provided taxonomy to output a structured JSON object. The template uses square-bracket placeholders for all dynamic inputs, such as the user's query, your specific taxonomy, and the desired output schema. Before using this in production, you must replace each placeholder with real data from your application's context.

textCopy
System: You are a facet extraction engine for a search application. Your only job is to analyze a user's search query and extract categorical constraints that match a provided taxonomy. Do not answer the query. Do not add commentary. Output only a valid JSON object.

User Query: [USER_QUERY]

Available Facets and Values:
[TAXONOMY_DEFINITION]

Instructions:
1. Identify any part of the user query that explicitly or implicitly refers to a category, type, or attribute defined in the Available Facets.
2. For each identified facet, extract the canonical value from the taxonomy that best matches the user's language. Normalize synonyms, abbreviations, and plural forms to the canonical value.
3. If the user specifies multiple values for a single facet (e.g., "Show me shirts and pants"), include all of them in a list. Assume an OR relationship between multiple values for the same facet unless the query explicitly states otherwise.
4. If a user's term does not clearly map to any taxonomy value, do not guess. Omit that facet from the output.
5. If no facets are found, return an empty object.

Output Format: Return a single JSON object. The keys are the facet names from the taxonomy. The values are either a single string or an array of strings representing the canonical values.

Output JSON:

To adapt this template, replace [USER_QUERY] with the raw input string from your search bar or voice interface. The [TAXONOMY_DEFINITION] placeholder should be populated with a structured representation of your product categories, content types, or any other filterable attributes. A robust format for this is a JSON object where keys are facet names and values are arrays of allowed strings. This prompt is the first step in a pipeline; its output must be validated against your taxonomy schema before being converted into actual database or search index filters. For high-stakes applications like medical or legal search, always route low-confidence extractions to a human review queue.

This prompt is designed to sit between the user's natural language query and your search backend's filter API. It should be called as a pre-retrieval step: the user query enters the system, the prompt extracts structured facet constraints, and those constraints are applied as filter clauses before vector or keyword search executes. The prompt's output is not the final answer—it is a structured metadata payload that your application must validate, normalize, and merge with other query components before retrieval begins.

Wire the prompt into an asynchronous or synchronous pre-processing function. After receiving the model's JSON output, validate it against your facet schema: check that every returned facet name exists in your taxonomy, that values match allowed enumerations or patterns, and that the operator field is one of include, exclude, equals, or range. Reject or repair malformed fields. If the model returns a facet not in your schema, log it as an unknown-facet event and either drop it or route it for human taxonomy review. For multi-select facets, verify that the conjunction field is explicitly AND or OR—if the model omits it, apply a safe default based on your product's UX conventions. Run a normalization pass: lowercase values, strip whitespace, and map synonyms to canonical terms using a lookup table. Only after validation should the extracted filters be merged into your search request.

Implement a retry strategy for malformed outputs. If JSON parsing fails or required fields are missing, send a repair prompt that includes the raw output and the validation error message. Limit retries to two attempts before falling back to a no-filter retrieval or escalating to a human reviewer. Log every extraction attempt with the original query, the extracted facets, validation results, and the final filters applied. This trace data is essential for debugging facet extraction failures and for building an eval dataset. Use a fast, cost-effective model for this extraction step—GPT-4o-mini, Claude Haiku, or a fine-tuned small model—since latency adds directly to the user's perceived search time. Avoid running this prompt on every keystroke in a typeahead interface; trigger it only on submitted queries or when the user pauses typing for at least 500ms.