Weighted Query Variant Assembly Prompt for Ensemble Retrieval

This prompt is designed for relevance engineers and infrastructure teams operating a multi-backend retrieval architecture. The core job-to-be-done is not simple query expansion, but the calibrated generation of multiple query formulations, each paired with an explicit confidence weight. This weighted assembly is the direct input to a downstream result fusion or reciprocal rank fusion step. Use this when you have already committed to an ensemble retrieval design—where dense vectors, sparse keyword indexes, and graph traversals run in parallel—and you need the model to produce the variant-weight pairs that will govern how much each backend's results contribute to the final merged set.

The ideal user has already solved the orchestration layer: they can dispatch queries to multiple backends and collect results. Their current bottleneck is the lack of a principled, per-query weighting mechanism. This prompt fills that gap by forcing the model to reason about which formulation is most likely to succeed for each backend and to express that reasoning as a numeric weight. Do not use this prompt for single-backend query rewriting, for generating a flat list of synonyms, or for systems where result fusion is handled by a separate learned model. It is also a poor fit if your retrieval pipeline cannot consume or respect per-variant weights, as the calibration work will be wasted.

Before integrating this prompt, ensure your pipeline can accept a JSON payload of variant-weight pairs and pass the weights to your fusion algorithm. You should also have a baseline understanding of each backend's strengths: dense vectors for semantic similarity, sparse keywords for exact term matching, and graph traversals for relationship-based queries. The prompt's effectiveness depends on the model's ability to map a user's question to these backend characteristics. If your backends have overlapping or poorly differentiated capabilities, the model will struggle to assign meaningful, discriminative weights, leading to uncalibrated assemblies that degrade result quality. Start with a clear, documented mapping of backend capabilities to query types before deploying this prompt.

This prompt template produces a structured, weighted assembly of query variants optimized for different retrieval backends. Use it when you need to generate parallel query formulations for dense vector, sparse keyword, and graph traversal indexes, each with a calibrated confidence weight that downstream fusion logic can use to merge results. The template expects a user question, available backend descriptions, and optional retrieval objectives. It returns a JSON object containing variant objects with backend assignments, query text, and confidence weights.

textCopy
You are a retrieval query engineer designing weighted query variants for an ensemble retrieval system. Your job is to produce multiple query formulations optimized for different retrieval backends, each with a confidence weight reflecting how well that variant is expected to perform for the given backend and user intent.

## INPUT
User Question: [USER_QUESTION]
Available Backends: [BACKEND_LIST]
Retrieval Objectives: [RETRIEVAL_OBJECTIVES]
Context (optional): [CONTEXT]

## BACKEND LIST FORMAT
Each backend is described with its type, strengths, and schema constraints:
[BACKEND_LIST]

## INSTRUCTIONS
1. Analyze the user question to understand the core intent, entities, constraints, and expected answer type.
2. For each available backend, generate one or more query variants specifically formulated to exploit that backend's strengths.
3. Assign each variant a confidence weight between 0.0 and 1.0 based on:
   - How well the backend type matches the query intent.
   - How precisely the variant formulation captures the information need.
   - The expected precision and recall characteristics of the backend for this query type.
4. Ensure variants are complementary: different backends should cover different aspects or phrasings rather than duplicating the same formulation.
5. If the question is ambiguous, generate disambiguating variants that explore different interpretations, each with appropriately reduced weights.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "assembly": {
    "original_query": "[USER_QUESTION]",
    "variants": [
      {
        "variant_id": "v1",
        "backend_type": "dense_vector",
        "backend_name": "[BACKEND_NAME]",
        "query_text": "[FORMULATED_QUERY]",
        "confidence_weight": 0.85,
        "rationale": "[WHY_THIS_FORMULATION_AND_WEIGHT]"
      }
    ],
    "weight_sum": 1.0,
    "coverage_notes": "[HOW_VARIANTS_COLLECTIVELY_COVER_THE_INTENT]"
  }
}

## CONSTRAINTS
- All confidence weights must be between 0.0 and 1.0.
- The sum of all variant weights must equal 1.0.
- Generate at least one variant per available backend unless a backend is clearly unsuitable, in which case explain the exclusion in coverage_notes.
- Do not generate more than [MAX_VARIANTS_PER_BACKEND] variants per backend.
- Query text must be self-contained and executable against the target backend without additional rewriting.
- For dense vector backends, use natural language phrasing optimized for embedding similarity.
- For sparse keyword backends, include explicit terms, phrases, and Boolean operators where supported.
- For graph backends, specify entity types, relationship types, and hop constraints explicitly.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your specific inputs. The [BACKEND_LIST] should describe each available index with its type, schema, and performance characteristics so the model can make informed formulation decisions. The [RETRIEVAL_OBJECTIVES] field lets you bias the assembly toward recall, precision, or latency constraints. For high-stakes retrieval where incorrect weights could surface irrelevant or misleading results, set [RISK_LEVEL] to "high" and add a human review step before the weighted assembly is used in production. The [FEW_SHOT_EXAMPLES] placeholder should contain 2-3 worked examples showing correct variant generation, weight assignment, and rationale for your specific domain. After generating the assembly, validate that the weight sum equals 1.0 and that each variant's query text is executable against its target backend before passing the assembly to your result fusion layer.

This prompt is designed as a pre-retrieval planning step in a multi-backend ensemble architecture. It should be invoked after the user query is received but before any retrieval backend is called. The prompt produces a structured assembly of query variants, each tagged with a target backend type and a confidence weight. Your application must parse this output and dispatch each variant to the corresponding retriever (dense vector, sparse keyword, graph, or hybrid). The weights are then used during result fusion to control how much influence each backend's results have on the final ranked list.

Validation is critical before dispatching. Parse the model's JSON output and validate: (1) every variant has a non-empty query string, (2) every backend field matches one of your supported backend identifiers (dense, sparse, graph, hybrid), (3) all weight values are floats between 0.0 and 1.0, and (4) the weights sum to approximately 1.0 (within a tolerance of ±0.05). If validation fails, retry the prompt once with the validation error message appended as a [CORRECTION_HINT]. If the second attempt also fails, fall back to a default equal-weight assembly using a simpler query reformulation prompt. Log both the raw output and the validation result for offline analysis of weight calibration drift.

Result merging should use the confidence weights as linear interpolation coefficients. For each retrieved document, compute a weighted score across backends: final_score = sum(weight_backend * normalized_score_backend). Documents retrieved by multiple backends get their scores summed. Deduplicate by document ID before ranking. If a backend returns zero results, redistribute its weight proportionally among the remaining backends to preserve the total score mass. Monitor the variance of weights across queries in production—if the model consistently assigns near-equal weights, your ensemble may not be benefiting from the weighted approach and you should evaluate whether backend performance actually differs for your query distribution.

Model choice matters. This prompt requires structured JSON output with numeric calibration. Use a model that reliably produces valid JSON with consistent numeric reasoning—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable. Avoid smaller models that may hallucinate backend identifiers or produce weights that don't sum to 1.0. Set temperature=0 or very low (0.1) to minimize weight variance across identical inputs. If you observe weight instability in production, consider caching the assembly for identical queries or adding a lightweight post-processing step that normalizes weights to sum to 1.0 regardless of the model's raw output.

Do not use this prompt when the user query is a simple keyword lookup, a navigation query, or when you only have a single retrieval backend. The overhead of generating weighted variants is wasted when a direct query would suffice. Also avoid this prompt in latency-sensitive paths where the additional LLM call adds unacceptable delay—consider pre-computing backend weights per query type or using a lightweight classifier instead. For high-stakes domains where retrieval failure has compliance or safety implications, always log the full assembly, the per-backend result counts, and the final merged ranking for auditability.