Query Variant Diversity Prompt for Ensemble Retrieval

This prompt is for infrastructure and search engineers who need to maximize recall in ensemble retrieval systems by generating a set of semantically diverse query variants from a single user question. The core job-to-be-done is to overcome the vocabulary mismatch problem: a user's single phrasing often fails to retrieve all relevant documents across dense vector, sparse keyword, and graph backends because each backend interprets language differently. The ideal user is a developer or platform engineer building a multi-stage retrieval pipeline who already has working retrieval infrastructure but observes that result sets from different backends overlap too much, missing relevant documents that use alternative terminology, different perspectives, or varied levels of abstraction.

Use this prompt when you have a retrieval system with multiple backends and you need to increase result set coverage without sacrificing precision in downstream reranking. It is appropriate when your pipeline includes a fusion or reranking stage that can handle a larger candidate pool, and when you have observability into per-backend recall metrics. The prompt requires a well-formed user question as input, and optionally accepts context about the domain, known entity names, or preferred terminology. Do not use this prompt when latency budgets are extremely tight and you cannot afford parallel retrieval calls, when your downstream answer generation model has a narrow context window that cannot accommodate diverse evidence, or when you lack a fusion mechanism to deduplicate and rank results from multiple query variants. It is also not a substitute for query decomposition—if the user question contains multiple independent sub-questions, use a decomposition prompt first, then apply diversity generation to each sub-query.

Before implementing this prompt in production, establish evaluation criteria for variant diversity: measure pairwise semantic similarity between generated variants and set a maximum acceptable overlap threshold. Track the number of unique documents retrieved across all variants versus a single-query baseline. Watch for failure modes where the model generates syntactically varied but semantically identical variants, or where it drifts so far from the original intent that precision collapses. Start with a small fixed number of variants (3-5) and increase only when recall metrics justify the added latency and compute cost. Wire the prompt into your application with a validation step that rejects variants below a minimum distinctiveness score, and log variant sets alongside retrieval metrics to enable continuous tuning.

This prompt template is designed to be copied directly into your application code or prompt management system. It instructs the model to produce a set of query variants that differ in phrasing, perspective, and term selection, ensuring broad coverage when the variants are executed in parallel against dense, sparse, and hybrid indexes. The square-bracket placeholders allow you to inject the user's original question, any available session context, and the specific output schema your retrieval pipeline expects.

textCopy
You are a query variant generator for an ensemble retrieval system. Your task is to produce a set of semantically diverse query variants from a single user question. The variants will be executed in parallel against multiple retrieval backends (dense vector, sparse keyword, hybrid).

## Input
User Question: [USER_QUESTION]
Conversation Context (if any): [SESSION_CONTEXT]

## Requirements
1. Generate exactly [VARIANT_COUNT] query variants.
2. Each variant must express the same core information need as the original question but use different phrasing, terminology, or perspective.
3. Maximize lexical diversity: avoid reusing the same keywords across all variants. Include synonyms, related terms, and alternative expressions.
4. Maximize structural diversity: some variants should be short keyword queries, others should be natural language sentences, and others should be question-form.
5. If the original question contains multiple facets, ensure at least one variant emphasizes each facet.
6. If [SESSION_CONTEXT] is provided, resolve any anaphora or implicit references before generating variants.
7. Do not introduce new constraints, entities, or assumptions not present in the original question.

## Output Schema
Return a JSON object with this exact structure:
{
  "original_query": "string",
  "variants": [
    {
      "variant_id": "string (v1, v2, ...)",
      "query_text": "string",
      "formulation_type": "keyword | natural_language | question",
      "primary_backend_target": "dense | sparse | hybrid",
      "diversity_notes": "string (brief explanation of how this variant differs from the original)"
    }
  ]
}

## Constraints
- All variants must be answerable from the same underlying evidence.
- Do not include variant_id values beyond the count specified.
- Ensure no two variants are near-duplicates.

To adapt this template for your pipeline, replace [VARIANT_COUNT] with the number of parallel retrieval calls your system can afford (typically 3–7). If your backends have distinct schemas, add a [BACKEND_CONSTRAINTS] placeholder that describes each backend's expected query format. For production use, wrap the model call in a validation layer that checks variant distinctiveness using a text similarity threshold and confirms the output matches the JSON schema before forwarding variants to your retrieval executors.

This prompt is designed as a pre-retrieval expansion step in a multi-stage RAG or hybrid search pipeline. It should be called after the user query is received but before any index is queried. The generated variants are then dispatched in parallel to one or more retrieval backends—dense vector, sparse keyword, or graph—and the results are fused downstream. Treat this prompt as a fan-out generator: its output is a list of query strings, not a final answer. The application layer is responsible for taking that list, executing the retrievals, and merging the result sets.

Implement a thin orchestration layer that calls the LLM with this prompt, parses the JSON array of query variants, and validates the output before retrieval. Validation checks should include: (1) the response is valid JSON, (2) the array contains at least [MIN_VARIANTS] and at most [MAX_VARIANTS] entries, (3) no variant is an exact duplicate of another or the original query, and (4) each variant is a non-empty string under [MAX_VARIANT_LENGTH] characters. If validation fails, retry once with the same prompt and an additional [CONSTRAINTS] note about the specific failure. After a second failure, fall back to using only the original user query to avoid pipeline stalls. Log every validation failure and fallback event with the raw LLM output for debugging.

For model choice, use a fast, cost-efficient model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) because this step is latency-sensitive and runs on every user query. Do not use a large reasoning model here; diversity generation benefits from breadth, not deep reasoning. If your pipeline already has a query classifier, route only complex or ambiguous queries through this prompt and skip it for simple factoid lookups. Wire the variant list into your retrieval dispatch layer with a source: 'query_variant_diversity' metadata tag so downstream fusion and ranking steps can weight or deduplicate results by provenance. Finally, track variant count, validation pass rate, and end-to-end recall improvement in your observability stack to detect drift in variant quality over time.