Query Term Weight Relaxation Prompt

This prompt is for search engineers and RAG developers who need a structured, auditable fallback path when keyword or hybrid retrieval systems return zero results or low recall due to over-specified queries. The core job-to-be-done is term-level relaxation: the model analyzes a user query, scores each term by its restrictiveness, and generates relaxed query variants by down-weighting or removing the most restrictive terms. This is not a general query rewriting tool. It is a targeted instrument for partial-match fallback when specific terms act as blockers that eliminate otherwise relevant documents. Use it when you need a salience-scored relaxation plan with retrieval breadth estimation, not when you need synonym expansion, vector similarity tuning, or full semantic rewriting.

The ideal user is a search infrastructure engineer or RAG pipeline developer who already has a primary retrieval path in place and needs a fallback layer that preserves search intent while broadening the retrieval net. Required context includes the original user query, the retrieval backend type (keyword, hybrid, or vector), and any known corpus characteristics such as domain specificity or document density. This prompt is appropriate when you can afford a second retrieval round and need an explainable relaxation artifact—the term salience scores and breadth estimates it produces are designed to be logged, audited, and potentially shown to users. It is not a replacement for upstream query validation, spelling correction, or intent classification. Those should happen before this prompt is invoked.

Do not use this prompt when the root cause of zero results is a vocabulary mismatch rather than over-specification. If the user's terminology simply does not appear in the corpus, dropping terms will not help—you need synonym expansion or embedding-based retrieval instead. Do not use it when latency budgets prohibit a second retrieval round, or when the application requires a single-pass query formulation. Do not use it for queries where every term is essential to intent and relaxation would produce misleading results. In regulated or high-risk domains, always route relaxed queries through human review or confidence thresholds before surfacing results to users. The next step after reading this section is to examine the prompt template and understand the required input shape, then review the implementation harness for wiring this into a production retrieval pipeline with validation and evals.

This prompt template is designed to be copied directly into your prompt library or orchestration layer. It accepts an over-specified query that returned zero or insufficient results and produces a structured analysis of which terms are most restrictive, along with ranked relaxed query variants. The template uses square-bracket placeholders that you replace with your application's inputs before sending the request to the model. Each placeholder maps to a specific input your retrieval pipeline should supply at runtime.

textCopy
You are a search query relaxation specialist. Your job is to analyze a query that returned zero or insufficient results and identify which terms are causing the restriction. You will produce a term salience analysis and generate relaxed query variants ordered by retrieval breadth.

## INPUT
Original Query: [ORIGINAL_QUERY]
Search Backend Type: [BACKEND_TYPE]
Corpus Domain: [DOMAIN]
Number of Results Returned: [RESULT_COUNT]
Relaxation Depth: [RELAXATION_DEPTH]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "original_query_analysis": {
    "detected_intent": "string",
    "constraint_count": number,
    "estimated_restrictiveness": "low|medium|high|critical"
  },
  "term_salience": [
    {
      "term": "string",
      "term_type": "entity|concept|modifier|filter|temporal|numerical|qualifier",
      "salience_score": number,
      "restrictiveness": "low|medium|high|critical",
      "droppable": boolean,
      "relaxation_candidates": ["string"]
    }
  ],
  "relaxed_variants": [
    {
      "variant_query": "string",
      "relaxation_strategy": "term_drop|hypernym|synonym|filter_removal|range_widening|abstraction",
      "terms_relaxed": ["string"],
      "estimated_recall_increase": "low|moderate|significant|dramatic",
      "intent_preservation_score": number,
      "retrieval_breadth_estimate": "narrow|moderate|broad|very_broad"
    }
  ],
  "recommended_fallback_order": [number],
  "warnings": ["string"]
}

## INSTRUCTIONS
1. Parse the original query and identify every term that acts as a constraint.
2. Classify each term by type and score its salience (1-10, where 10 means essential to intent).
3. Score each term's restrictiveness based on how likely it is to cause zero results in the specified backend type and domain.
4. Generate relaxed variants by applying strategies in this priority order: drop low-salience qualifiers, replace entities with hypernyms, expand synonyms, remove metadata-style filters, widen ranges, abstract concepts.
5. For each variant, estimate recall increase and score intent preservation (1-10, where 10 means identical intent).
6. Rank variants in recommended fallback order, preferring variants that maximize recall while keeping intent preservation above [MIN_INTENT_THRESHOLD].
7. Include warnings for any variant where intent preservation drops below 6 or where relaxation may introduce ambiguity.
8. If [RESULT_COUNT] is greater than 0, note that partial results exist and adjust relaxation aggressiveness accordingly.

## EXAMPLES
[EXAMPLES]

To adapt this template for your system, replace each bracketed placeholder with values from your application context. [ORIGINAL_QUERY] should receive the exact user query that failed. [BACKEND_TYPE] accepts values like keyword, vector, hybrid, or graph to help the model understand which term types cause the most restriction in your infrastructure. [DOMAIN] provides corpus context such as legal, medical, technical_documentation, or ecommerce. [RELAXATION_DEPTH] controls how aggressively the model generalizes—use conservative, moderate, or aggressive. [CONSTRAINTS] lets you inject domain-specific rules like 'never drop medication names' or 'preserve date ranges for compliance.' [MIN_INTENT_THRESHOLD] sets the floor for acceptable intent preservation, typically 7 for high-stakes domains and 5 for exploratory search. [EXAMPLES] should contain 1-3 few-shot examples showing correct term salience scoring and variant generation for your domain. Wire the output into your retrieval pipeline by iterating through recommended_fallback_order and executing each variant until sufficient results are found. Validate each variant's intent_preservation_score before execution, and log the warnings array for operational visibility. For high-risk domains, route variants with intent scores below your threshold to a human review queue before retrieval execution.

This prompt is designed to sit inside a fallback retrieval path, not the primary retrieval flow. It should only be invoked when the initial strict query returns zero or insufficient results. The harness must capture the original query, the result count, and any metadata filters before calling the model. The model's output—a list of terms with salience scores and relaxed variants—is then used to construct a new, broader query for a second retrieval attempt. Do not call this prompt on every request; it adds latency and cost and is only valuable when the primary path fails.

The implementation should follow a validate-then-execute pattern. After the model returns JSON, validate that every term in the original query appears in the output, that salience scores are numbers between 0 and 1, and that at least one term has a relaxed variant. If validation fails, retry once with a stronger constraint in the prompt: [CONSTRAINTS]: You must return valid JSON with all original terms present. If the second attempt also fails, log the failure and fall back to a simpler relaxation strategy, such as dropping all stop words and re-running the query. For high-stakes search applications, add a human review queue for relaxation outputs where the top salience term is dropped—this indicates the model may be discarding the user's core intent.

Model choice matters here. This task requires strong instruction-following and structured output discipline. Use a model that supports JSON mode or structured outputs natively (e.g., GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro with response_schema). Avoid smaller or older models that may struggle with the dual task of scoring term importance and generating valid relaxed variants simultaneously. Set temperature=0 or very low to get deterministic salience scores. Log every relaxation attempt with the original query, the model's term analysis, the relaxed query that was executed, and the number of results returned. This trace data is essential for tuning the relaxation strategy over time and detecting when the model starts over-relaxing queries.

Tool integration is straightforward: this prompt is a pure text-to-JSON transformation with no external tool calls required. However, the harness should expose the salience scores to downstream systems. If you're using a hybrid retrieval system (vector + keyword), use the salience scores to adjust keyword boost weights—terms with high salience keep their boost, while relaxed terms get reduced or zero boost. For vector search, construct the relaxed query by concatenating the relaxed variants and use it as the search text. Do not replace the original query in your observability stack; always retain the user's raw input for debugging and relevance judgment.

What to avoid: Do not use this prompt as a real-time query suggestion tool shown to users without review. The relaxed variants are optimized for recall, not user readability. Do not chain multiple relaxation calls—if the relaxed query also returns zero results, escalate to a broader fallback strategy (e.g., dropping all metadata filters, or signaling 'no results found' to the user). Finally, set a latency budget: this prompt plus the second retrieval should complete within your application's p95 latency target. If it doesn't, consider pre-computing common relaxation patterns or caching relaxed queries for frequent zero-result terms.