Entity Hypernym Expansion Prompt for Recall Improvement

This prompt is for search relevance engineers and RAG pipeline developers who need to recover from zero-result or low-recall queries caused by overly specific entity mentions. The job-to-be-done is widening the retrieval net by replacing a specific entity in a user's query with a broader hypernym or category term—for example, replacing 'Tesla Model 3' with 'electric vehicle' or 'sedan.' Use this when your retrieval system has access to a domain taxonomy, a knowledge graph, or a controlled vocabulary that defines entity-to-category relationships, and when you need a programmatic, repeatable way to generate broader query variants without manual rule curation.

Do not use this prompt when the query failure is caused by vocabulary mismatch rather than entity specificity. If the user searched for 'car' and got zero results, hypernym expansion to 'vehicle' is unlikely to help—the problem is a corpus gap or indexing issue, not over-specification. Similarly, avoid this prompt when you lack a reliable taxonomy or entity mapping. Asking the model to hallucinate hypernyms without grounding produces inconsistent expansions that drift from the original intent. This prompt also assumes you have already validated that the original query returned insufficient results; it is a fallback mechanism, not a primary retrieval strategy.

Before wiring this into production, ensure you have a defined expansion level control—conservative (one step up the taxonomy), moderate (two steps), or aggressive (top-level category). Pair the prompt with an evaluation step that compares the expanded query's retrieval results against the original intent. If the expansion level is too aggressive, you'll trade precision for recall in ways that degrade answer quality. Start with conservative expansion, measure recall improvement and precision loss on a golden query set, and only increase the expansion depth when the data supports it. Human review is required if the expanded query will be surfaced to users or used in regulated domains where intent drift carries compliance risk.

The following prompt template is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It accepts a user query, a domain taxonomy, and an expansion control level, and returns a set of rewritten queries where specific entities have been replaced by their broader categorical terms. The template uses square-bracket placeholders for all dynamic inputs—replace these with your application's variables before execution. No other modifications to the instruction structure are required for initial testing.

textCopy
You are a search query rewriter for a retrieval system. Your task is to improve recall by replacing specific entities in a user query with broader hypernyms or category terms. You must preserve the original search intent while widening the retrieval scope.

## INPUT
User Query: [USER_QUERY]
Domain Taxonomy (optional): [DOMAIN_TAXONOMY]
Expansion Level: [EXPANSION_LEVEL]

## EXPANSION LEVEL DEFINITIONS
- "conservative": Replace only the most specific named entities with their immediate hypernyms. Prefer terms that are one level broader.
- "moderate": Replace specific entities with hypernyms up to two levels broader. Include category-level terms.
- "aggressive": Replace all specific entities with broad category or class terms. Maximize recall at the cost of precision.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "original_query": "string",
  "expansion_level": "string",
  "expanded_queries": [
    {
      "query": "string",
      "replacements": [
        {
          "original_entity": "string",
          "hypernym": "string",
          "broadening_rationale": "string"
        }
      ],
      "estimated_recall_breadth": "narrow | moderate | broad",
      "intent_preservation_confidence": 0.0-1.0
    }
  ],
  "dropped_constraints": ["string"]
}

## INSTRUCTIONS
1. Identify all specific entities in the user query (products, people, locations, brands, model numbers, proprietary terms).
2. For each entity, determine the appropriate hypernym using the provided domain taxonomy. If no taxonomy is provided, use general world knowledge.
3. Generate [NUM_VARIANTS] query variants at the specified expansion level.
4. For each variant, document every entity-to-hypernym replacement with a brief rationale.
5. Score intent preservation confidence for each variant. A score below 0.7 indicates the variant may have drifted too far from the original intent.
6. List any original query constraints that were dropped during expansion.
7. If the query contains no expandable entities, return the original query unchanged with a note.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your system, start by replacing the placeholder variables. [USER_QUERY] should receive the raw search string from your application. [DOMAIN_TAXONOMY] can be a JSON object, a list of entity-to-hypernym mappings, or an empty string if you want the model to rely on its own knowledge. [EXPANSION_LEVEL] must be one of the three defined strings—validate this in your application layer before passing it to the model. [NUM_VARIANTS] controls how many rewritten queries the model produces; start with 3 for moderate expansion and adjust based on your latency budget. [CONSTRAINTS] is where you inject domain-specific rules, such as "never expand medication names" or "preserve all location entities." [EXAMPLES] should contain 2-3 few-shot demonstrations showing the desired entity-to-hypernym mapping style for your domain. [RISK_LEVEL] accepts "low", "medium", or "high" and should trigger downstream validation behavior—for high-risk domains, always route expanded queries through a human review step before executing them against your retrieval index.

Before deploying this prompt, wire the output through a JSON schema validator to catch malformed responses. Pay particular attention to the intent_preservation_confidence field: if any variant scores below your threshold (we recommend 0.7 as a starting point), either discard that variant or flag it for review. For production systems, log every entity replacement alongside the original query so you can measure whether hypernym expansion actually improves recall without degrading precision. Run an offline evaluation using a golden set of zero-result queries to calibrate your expansion level and confidence threshold before enabling this in a user-facing retrieval path.

This prompt is designed as a pre-retrieval rewrite step in a search or RAG pipeline. It should be invoked when an initial query returns zero or insufficient results, not as a replacement for the original query. The harness must pass the original query, the domain taxonomy, and the expansion level control to the model, then validate the output before executing the expanded query against your retrieval backend. The prompt is not a standalone solution—it is one stage in a multi-step fallback strategy that should also include synonym expansion, query decomposition, and metadata filter relaxation where appropriate.

To wire this into an application, wrap the prompt in a function that accepts [ORIGINAL_QUERY], [DOMAIN_TAXONOMY] (a dictionary or list of entity-to-hypernym mappings), and [EXPANSION_LEVEL] (an integer from 1–3 controlling how far up the abstraction ladder to climb). The function should call the LLM with a low temperature (0.0–0.2) to ensure deterministic hypernym selection. Parse the output as JSON and validate that: (1) the expanded_query field is a non-empty string, (2) the hypernyms_used array contains only terms present in your taxonomy, and (3) the specificity_loss score is within the acceptable range for your expansion level. If validation fails, retry once with the same parameters; if it fails again, fall back to a simpler keyword-dropping strategy rather than looping indefinitely. Log every expansion attempt—original query, expanded query, hypernyms applied, expansion level, and result count from the retrieval backend—so you can measure recall improvement and intent drift over time.

For model choice, a fast instruction-tuned model like GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight model is sufficient for this classification-and-substitution task. Do not use a large reasoning model for hypernym expansion; the latency cost outweighs the marginal accuracy gain. If your domain taxonomy is large, pre-load it into the system prompt or pass it as a structured tool definition rather than inlining it in every user message. For evaluation, build a golden test set of 50–100 zero-result queries with known relevant documents, measure recall@10 before and after expansion, and set a maximum acceptable specificity loss threshold (e.g., 0.3 on a 0–1 scale). If the expanded query's specificity loss exceeds this threshold, route it for human review or suppress the expansion entirely. The next step after implementing this harness is to integrate it into your fallback chain: try the original query, then hypernym expansion, then query decomposition, and only then return an empty result set to the user.