Query Relaxation with Explainability Output Prompt

This prompt is for search engineers and RAG developers who need to generate broader query variants when strict queries return zero or insufficient results, and who must communicate those changes transparently to end users. Use it when your retrieval pipeline requires not just a relaxed query, but also a human-readable explanation of what was changed, why it was changed, and a draft message the user can see. This is not a prompt for simple query rewriting. It is for systems where fallback transparency is a product requirement, such as enterprise search, legal research, clinical literature retrieval, or any domain where users need to understand why results were broadened.

The ideal user is a backend engineer or search relevance engineer building a multi-stage retrieval pipeline with explicit fallback paths. They have already implemented strict query execution and are now designing the degradation layer. Required context includes the original query that returned zero results, the specific constraints or filters applied, and the retrieval backend characteristics (dense, sparse, hybrid). The prompt expects you to define what constitutes an acceptable relaxation boundary—how far the system can broaden before the results become irrelevant. Without this boundary definition, the explainability output becomes meaningless because the model cannot distinguish between a justified relaxation and an arbitrary query rewrite.

Do not use this prompt when you only need a relaxed query without user-facing communication. For those cases, use the simpler Zero-Result Fallback Query Rewrite Prompt Template or Progressive Query Relaxation Prompt Template from this pillar. Do not use this prompt when your retrieval system operates in a fully automated backend with no user visibility into query modifications. Do not use it when latency budgets are extremely tight and the additional explanation generation adds unacceptable overhead. Do not use it when the domain is low-risk and users do not expect or need transparency about retrieval mechanics. For regulated or high-stakes domains, always pair this prompt's output with human review before surfacing the explanation to users—the model can draft the communication, but a domain expert must validate that the relaxation did not introduce misleading scope changes.

This template produces relaxed query variants when an initial strict query returns zero or insufficient results. It goes beyond simple rewriting by requiring the model to document each change, explain the reasoning, and provide a user-facing communication draft. Copy the template below into your prompt layer, replace the square-bracket placeholders with your application's values, and send it to the model. The output is designed to be parsed by your fallback retrieval harness and optionally surfaced to end users.

textCopy
You are a query relaxation engine for a retrieval system. Your job is to take an over-specified query that returned zero or insufficient results and produce one or more relaxed variants that broaden the search scope while preserving the original user intent.

## INPUT
Original Query: [ORIGINAL_QUERY]
Number of Results Returned: [RESULT_COUNT]
Corpus Description: [CORPUS_DESCRIPTION]
Relaxation Depth: [RELAXATION_DEPTH]

## CONSTRAINTS
- Do not change the core intent of the original query.
- Relax only the constraints that are most likely causing the empty result set.
- Prefer dropping filters, broadening terms, or removing temporal constraints before altering the central question.
- If [RELAXATION_DEPTH] is "conservative", relax only one constraint. If "moderate", relax up to two. If "aggressive", relax as needed.
- Do not invent entities, dates, or values not implied by the original query.

## OUTPUT_SCHEMA
Return a valid JSON object with this structure:
{
  "original_query": "string",
  "relaxation_plan": [
    {
      "step": number,
      "action": "dropped_filter" | "broadened_term" | "removed_temporal_constraint" | "replaced_entity_with_hypernym" | "relaxed_numerical_range",
      "original_constraint": "string",
      "relaxed_constraint": "string",
      "rationale": "string explaining why this constraint was chosen for relaxation",
      "intent_preservation_confidence": "high" | "medium" | "low"
    }
  ],
  "relaxed_query": "string",
  "alternative_relaxed_queries": ["string"],
  "user_communication_draft": "string suitable for display to the end user explaining that results were broadened",
  "expected_recall_change": "higher" | "unchanged" | "uncertain",
  "warnings": ["string describing any risks of intent drift or irrelevant results"]
}

## EXAMPLES
[RELAXATION_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

Adaptation notes: Replace [ORIGINAL_QUERY] with the user's query string. [RESULT_COUNT] should be the integer number of results the strict query returned (typically 0). [CORPUS_DESCRIPTION] is a short description of the document collection—this helps the model decide which constraints are likely too restrictive for your data. [RELAXATION_DEPTH] controls how aggressively the model broadens the query; wire this to a configuration parameter in your fallback pipeline. [RELAXATION_EXAMPLES] should contain 1-3 few-shot examples showing correct relaxation behavior for your domain. [RISK_LEVEL] should be set to "high" if the domain is regulated (healthcare, finance, legal) to trigger conservative relaxation and stronger warnings. In high-risk domains, always route the user_communication_draft through human review before display. Validate the output JSON against the schema before using the relaxed query in retrieval—malformed JSON should trigger a retry or fallback to a simpler relaxation strategy.

This prompt is designed to sit between your primary retrieval step and the user-facing response layer. When a strict query returns zero or insufficient results, invoke this prompt with the original query, the retrieval context (corpus description, available filters, domain), and any empty-result metadata. The model returns a structured payload containing relaxed query candidates, change explanations, confidence scores, and a user-facing communication draft. You should treat this as a synchronous pre-retrieval step—not an async background job—because the relaxed query must be executed immediately to produce results for the current user turn.

Integration pattern: Wrap the prompt call in a function with a strict schema validator. The expected output is a JSON object with fields like relaxed_queries (array of candidate strings), changes (array of objects describing what was modified and why), confidence (0-1 float), and user_message (string for display). Validate this schema before executing the relaxed query. If validation fails, retry once with the validation error appended to the prompt as a correction hint. If the second attempt also fails, fall back to a simpler relaxation strategy (e.g., dropping all metadata filters) and log the failure for review. Model choice: Use a model with strong instruction-following and JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may conflate the explanation with the query itself. Set temperature=0.1 to keep relaxation behavior deterministic and auditable.

Retrieval execution and stopping: After obtaining validated relaxed queries, execute them against your retrieval backend in priority order. Stop when a query returns results above your minimum relevance threshold. Log which relaxation level succeeded, the original and relaxed queries, and the explanation for each change. This trace is essential for tuning relaxation aggressiveness over time. User-facing communication: Display the user_message field when presenting relaxed results, so users understand why they're seeing broader matches. For high-stakes domains (healthcare, legal, finance), add a human review step before displaying relaxed results—the explainability output makes this review fast because the reviewer can see exactly what changed and why.

What to avoid: Do not execute all relaxed queries in parallel and merge results indiscriminately; this destroys the intent-preservation ordering. Do not cache relaxed queries across different user sessions without re-evaluating the original query context. Do not skip schema validation—malformed relaxation output can inject nonsense queries into your retrieval pipeline and produce irrelevant or misleading results. Next step: After implementing the harness, run eval queries with known over-specified inputs and verify that (a) the relaxation preserves core intent, (b) the explanation accurately describes each change, and (c) the user message is appropriate for your product's tone and transparency standards.