Price Range Expansion Prompt for E-Commerce Retrieval

This prompt is designed for the pre-retrieval stage of an e-commerce search pipeline. Its job is to intercept natural language queries that contain price intent—such as 'wireless headphones under $100', 'cheap standing desks', or 'premium leather boots'—and transform the user's price expression into a structured JSON object with explicit min_price, max_price, and currency_code fields. This structured output can then be directly translated into metadata filter clauses for vector databases like Pinecone, Weaviate, or Elasticsearch, enabling hybrid retrieval that combines semantic relevance with precise price constraints. The primary user is a search engineer, RAG developer, or platform architect who already has a product catalog indexed with price metadata and needs to bridge the gap between human price language and machine-readable filters.

Use this prompt when your system meets three conditions: (1) your product catalog contains numeric price fields and currency codes, (2) users express budget constraints in free-text search queries, and (3) your retrieval pipeline supports metadata filtering alongside vector or keyword search. The prompt handles explicit ranges ('between $50 and $200'), comparative expressions ('less than $30', 'above $500'), and symbolic price tiers ('affordable', 'budget', 'premium', 'luxury') by mapping them to configurable numeric thresholds. It also normalizes currency symbols and codes ($, USD, EUR, GBP) into ISO 4217 format. However, do not use this prompt for non-price numerical ranges (e.g., 'laptops with 16GB RAM', 'TVs over 65 inches'), temporal expressions ('released after 2023'), or queries that contain no pricing intent whatsoever. Running price extraction on every query wastes tokens and latency budget without adding value.

Before deploying, define your symbolic price tier mappings in the [TIER_DEFINITIONS] placeholder. What 'budget' means for electronics differs from what it means for furniture, so consider category-specific tier definitions if your catalog spans diverse product types. Also implement a pre-check: if the query contains no currency symbols, price-related keywords, or tier language, skip this prompt entirely and pass the raw query to retrieval. For production, pair this prompt with a lightweight classifier or keyword gate to avoid unnecessary LLM calls. The next section provides the copy-ready prompt template you can adapt and test against your own catalog's price distribution.

This template converts user-facing price language—such as 'under $50', 'between $100 and $200', 'affordable', or 'premium'—into structured price range outputs that your retrieval system can use as filter clauses. The prompt handles currency code extraction, symbolic pricing tiers, and boundary disambiguation. Replace each square-bracket placeholder with your application's specific values before sending the prompt to the model.

textCopy
You are a price range normalization engine for an e-commerce retrieval system. Your job is to convert natural language price expressions into explicit, machine-readable price ranges with currency codes and filter-ready boundary operators.

## INPUT
User query: [USER_QUERY]

## CONTEXT
- Default currency code: [DEFAULT_CURRENCY_CODE]
- Available symbolic pricing tiers: [SYMBOLIC_TIERS]
- Maximum allowed price value: [MAX_PRICE]
- Minimum allowed price value: [MIN_PRICE]

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "price_constraints": [
    {
      "currency": "string (ISO 4217 code)",
      "min_amount": number | null,
      "max_amount": number | null,
      "min_operator": "gte" | "gt" | null,
      "max_operator": "lte" | "lt" | null,
      "symbolic_tier": "string | null",
      "confidence": number (0.0 to 1.0),
      "source_phrase": "string (the original text that produced this constraint)"
    }
  ],
  "original_expression": "string",
  "detected_currency": "string | null",
  "requires_clarification": boolean,
  "clarification_question": "string | null",
  "assumptions": ["string"]
}

## CONSTRAINTS
1. If the query contains an explicit currency symbol or code (e.g., $, USD, EUR, £), use that currency. Otherwise, use the default currency code.
2. For symbolic expressions like 'affordable', 'cheap', 'premium', 'luxury', 'mid-range', or 'budget', map them to the provided symbolic pricing tiers. If no tier matches, set symbolic_tier to null and estimate numeric bounds with lower confidence.
3. For 'under X' or 'less than X', set max_amount to X and max_operator to 'lt'. Set min_amount to [MIN_PRICE] and min_operator to 'gte'.
4. For 'over X' or 'more than X', set min_amount to X and min_operator to 'gt'. Set max_amount to [MAX_PRICE] and max_operator to 'lte'.
5. For 'between X and Y' or 'X to Y', set both min_amount and max_amount. Use 'gte' for min_operator and 'lte' for max_operator unless the query explicitly says 'between X and Y exclusive'.
6. For exact prices like 'exactly $50' or '$50', set min_amount and max_amount to the same value with 'gte' and 'lte' operators.
7. If the query contains multiple price constraints (e.g., 'under $50 or over $200'), produce multiple entries in the price_constraints array.
8. If the price expression is ambiguous (e.g., 'around $100' without a tolerance), set requires_clarification to true and provide a clarification_question.
9. If no price expression is detected, return an empty price_constraints array and set requires_clarification to false.
10. List all assumptions you made in the assumptions array, including default currency application and symbolic tier mappings.
11. Set confidence based on how explicit the price expression is: explicit numbers with clear operators = 0.95+, symbolic tiers = 0.7-0.85, vague expressions = 0.5-0.7.

## EXAMPLES
Query: "show me headphones under $100"
Default currency: USD
Output:
{
  "price_constraints": [
    {
      "currency": "USD",
      "min_amount": 0,
      "max_amount": 100,
      "min_operator": "gte",
      "max_operator": "lt",
      "symbolic_tier": null,
      "confidence": 0.98,
      "source_phrase": "under $100"
    }
  ],
  "original_expression": "under $100",
  "detected_currency": "USD",
  "requires_clarification": false,
  "clarification_question": null,
  "assumptions": ["Applied default minimum price of 0"]
}

Query: "affordable running shoes"
Default currency: EUR
Symbolic tiers: {"budget": {"min": 0, "max": 50}, "affordable": {"min": 20, "max": 80}, "mid-range": {"min": 50, "max": 150}, "premium": {"min": 100, "max": 300}, "luxury": {"min": 200, "max": 9999}}
Output:
{
  "price_constraints": [
    {
      "currency": "EUR",
      "min_amount": 20,
      "max_amount": 80,
      "min_operator": "gte",
      "max_operator": "lte",
      "symbolic_tier": "affordable",
      "confidence": 0.8,
      "source_phrase": "affordable"
    }
  ],
  "original_expression": "affordable",
  "detected_currency": null,
  "requires_clarification": false,
  "clarification_question": null,
  "assumptions": ["Applied default currency EUR", "Mapped 'affordable' to tier with bounds 20-80 EUR"]
}

## RISK_LEVEL
Medium. Incorrect price range extraction can produce irrelevant search results and degrade user trust. Validate outputs before applying as database filter clauses.

To adapt this template, replace the placeholders with your application's runtime values. [USER_QUERY] should contain the raw user input. [DEFAULT_CURRENCY_CODE] is your store's primary currency in ISO 4217 format (e.g., 'USD', 'EUR', 'GBP'). [SYMBOLIC_TIERS] should be a JSON object mapping your pricing tier names to min/max bounds—this is critical for e-commerce sites that use tiered pricing language in navigation or filters. [MAX_PRICE] and [MIN_PRICE] define the absolute boundaries of your catalog to prevent nonsensical ranges. If your application supports multi-currency, ensure the detected_currency field is used downstream to select the correct price index. For production use, always validate the output JSON against the schema before constructing database filter clauses, and log any outputs where confidence falls below 0.7 for human review.

The price range expansion prompt is designed as a pre-retrieval transformation step. It takes a raw user query containing price language and normalizes it into a structured JSON object with explicit min_price, max_price, currency_code, and operator fields. This structured output is not the final answer to the user—it is a machine-readable filter clause that your application should inject into a downstream search or vector database query. The prompt should be called before any retrieval call, and its output should be validated before being used to construct filter predicates.

To wire this into a production pipeline, wrap the prompt call in a lightweight service function. The function should accept the user's raw query string and an optional default_currency parameter (e.g., 'USD'). On success, parse the JSON response and validate that min_price and max_price are non-negative numbers, that min_price <= max_price when both are present, and that currency_code is a valid ISO 4217 code. If the model returns a null range (indicating no price constraint was detected), skip the price filter entirely. If validation fails, log the raw output and fall back to an unfiltered retrieval rather than applying a broken filter. For multi-currency scenarios, your service should maintain a mapping of supported currencies and either convert the range to the catalog's base currency using current exchange rates or reject unsupported currencies with a clear user-facing message.

For observability, log every prompt call with the input query, the raw model output, the validated filter object, and whether the filter was applied or discarded. This trace data is essential for debugging retrieval failures—if a user complains about missing products, you need to know whether the price filter excluded them. Set up an eval harness that tests the prompt against a golden set of queries like 'under $50', 'between 100 and 200 euros', 'affordable headphones', and 'cheap'. For each test case, assert the correct min_price, max_price, and currency_code. Pay special attention to edge cases: queries with no price language should return null; symbolic terms like 'affordable' or 'premium' should map to reasonable ranges based on your product catalog's price distribution; and malformed inputs like 'between $50' should either be caught by validation or produce a conservative filter. Run these evals on every prompt change before deployment.