Drop Numerical Constraint Prompt for Range Queries

This prompt is designed for search engineers and RAG pipeline developers who need to recover from empty result sets caused by overly strict numerical filters. The core job-to-be-done is automated query relaxation: when a user asks for 'laptops under $500 with a 15-inch screen released after 2023' and your product catalog returns zero matches, this prompt generates a revised query that strategically drops or widens the numerical thresholds (e.g., 'laptops under $700 with a 14-16 inch screen') while preserving the original shopping intent. It is not a general synonym expander or a decomposition tool—it specifically targets quantitative constraints like prices, dates, measurements, ratings, and counts that create hard retrieval boundaries.

Use this prompt when your retrieval pipeline has already executed a strict query and received zero or critically low results, and you have confirmed that the failure is due to numerical over-specification rather than vocabulary mismatch or corpus gaps. The prompt requires you to supply the original user query, the numerical constraints that were applied, and the corpus statistics (e.g., available price ranges, date spans, or measurement distributions) so the model can make data-informed relaxation decisions. Do not use this prompt for queries where the numerical constraint is the primary intent (e.g., 'exactly 3 bedrooms' in a real estate search where the number is non-negotiable), for safety-critical thresholds (e.g., dosage limits, load ratings), or when the corpus genuinely lacks relevant documents regardless of constraint relaxation. In those cases, an empty result is the correct answer, and relaxation would produce misleading results.

The prompt outputs a structured relaxation plan that includes: the relaxed query text, a list of which numerical constraints were modified and by how much, a significance assessment indicating whether each relaxed constraint is likely to change the user's decision, and a justification for the relaxation boundaries chosen. This output is designed to be machine-readable so your application can either automatically execute the relaxed query or surface the fallback suggestion to the user with an explanation like 'We couldn't find exact matches, but here are results with slightly wider criteria.' Before deploying, wire the output through a validation step that checks the relaxed query still retrieves results and that the intent drift is within acceptable bounds. For high-stakes domains like financial compliance or medical equipment search, always require human review of the relaxation plan before executing it.

This template is designed to be copied directly into your RAG pipeline's fallback path. When a user query containing numerical thresholds, ranges, or value constraints returns zero results, this prompt instructs the model to identify which numerical constraints are blocking retrieval, assess their significance to the original intent, and generate a relaxed query variant with the least-important constraints removed or widened. The output includes both the relaxed query and a justification record you can log for observability.

textCopy
You are a query relaxation engine for a retrieval system. Your job is to analyze a user query that contains numerical constraints and returned zero results, then produce a relaxed query variant that removes or widens the least-important numerical constraints while preserving the core intent.

## Original Query
[ORIGINAL_QUERY]

## Retrieved Result Count
0 results

## Available Numerical Fields in Index
[INDEX_NUMERIC_FIELDS]

## Relaxation Rules
1. Identify every numerical constraint in the query (thresholds, ranges, exact values, comparisons like 'under', 'over', 'at least', 'more than', 'between').
2. For each constraint, assign a significance score from 1 (critical to intent) to 5 (incidental or decorative).
3. Drop or widen constraints starting from the lowest significance (score 5) first.
4. Widening strategy per constraint type:
   - Exact values: convert to a range of ±[DEFAULT_WIDENING_FACTOR]%
   - Lower bounds ('at least X'): reduce by [DEFAULT_WIDENING_FACTOR]%
   - Upper bounds ('under X', 'less than X'): increase by [DEFAULT_WIDENING_FACTOR]%
   - Ranges ('between X and Y'): expand both bounds outward by [DEFAULT_WIDENING_FACTOR]%
5. Stop when at least one numerical constraint has been relaxed. Do not remove all constraints unless none are significant.
6. If no numerical constraints exist in the query, return the original query unchanged with an explanation.

## Output Schema
Return valid JSON only:
{
  "original_query": "string",
  "has_numerical_constraints": boolean,
  "constraint_analysis": [
    {
      "constraint_text": "string",
      "constraint_type": "exact_value | lower_bound | upper_bound | range",
      "original_value": "string",
      "significance_score": number,
      "significance_rationale": "string",
      "action": "dropped | widened | kept"
    }
  ],
  "relaxed_query": "string",
  "relaxation_summary": "string",
  "intent_preservation_confidence": "high | medium | low",
  "expected_recall_impact": "string"
}

## Constraints
- Do not alter non-numerical parts of the query.
- Do not fabricate numerical constraints that aren't present.
- If relaxing a constraint would fundamentally change what the user is asking for, flag it as high significance and do not relax it.
- If the query contains no numerical constraints, set has_numerical_constraints to false and return the original query as relaxed_query.

To adapt this template, replace [ORIGINAL_QUERY] with the user's query string, [INDEX_NUMERIC_FIELDS] with a list of numeric fields available in your retrieval index (e.g., price, rating, year, distance_km), and [DEFAULT_WIDENING_FACTOR] with a percentage like 20 or 50 depending on how aggressive you want the initial relaxation to be. If your index supports different widening strategies per field, extend the Available Numerical Fields section to include per-field widening factors. The output JSON is designed to be machine-readable so your retrieval harness can parse it, execute the relaxed query, and log the constraint analysis for debugging and eval purposes.

This prompt is designed to sit inside a fallback retrieval path that activates only when the primary query returns zero or insufficient results. The implementation harness should intercept the original query and its strict numerical constraints, invoke the model to produce a relaxed variant, and then re-execute retrieval. The harness must never modify the user-facing answer directly—it only changes what the retriever sees. This separation keeps the relaxation logic auditable and prevents the model from silently dropping constraints that the user explicitly requested.

Integration pattern: Wrap the prompt in a relax_numerical_constraint function that accepts the original query string, the strict numerical filter parameters that were applied, and the count of results returned. The function should call the LLM with the prompt template, parse the JSON output, validate that the relaxed constraints are strictly broader than the original (e.g., a price range of $100–$200 must not become $150–$175), and return the relaxed query plus the new filter boundaries. If validation fails, log the mismatch and fall back to a simpler strategy such as dropping the numerical filter entirely with a warning flag. Model choice: Use a fast, cost-efficient model for this task (e.g., GPT-4o-mini, Claude Haiku) because the prompt is a structured transformation, not a reasoning-heavy generation. Latency matters here—this is on the critical path of a user-facing retrieval request.

Validation and safety checks: Before executing the relaxed retrieval, the harness must confirm that the new numerical bounds are a superset of the original bounds. For example, if the original query specified rating >= 4.5, a relaxed query with rating >= 4.0 is valid, but rating >= 4.7 is a regression. Implement a numeric comparator that checks each constraint independently. Additionally, verify that the relaxed query still contains the core entity or topic from the original query—if the model drops the subject entirely while widening a range, reject the output. Retry logic: If the relaxed query also returns zero results, the harness can invoke the prompt again with an explicit instruction to widen further, but cap retries at two attempts to avoid infinite loops. After two failures, escalate to a broader fallback strategy such as the Progressive Query Relaxation Prompt or return a controlled empty-result message to the user.

Observability and logging: Log every relaxation event with the original query, the strict constraints, the relaxed output, the validation result, and the retrieval count after relaxation. This data is essential for tuning the relaxation strategy over time—teams should monitor how often numerical constraints cause zero results, which constraint types are most frequently relaxed, and whether relaxed queries produce relevant answers. Attach a relaxation_applied flag and the relaxation depth to the trace so downstream answer-generation prompts can adjust their confidence language (e.g., 'Results shown without your exact price filter'). What to avoid: Do not use this prompt on the first retrieval attempt. Do not relax constraints silently without logging. Do not allow the relaxed query to be narrower than the original. And never expose the raw relaxed query to the end user without an explanation layer.