Synonym Expansion with Entity Recognition Boost Prompt

This prompt is designed for search engineers and RAG developers who need to improve keyword and vector recall without corrupting named entities. The core job is to take a user query and produce a set of expanded terms that includes synonyms, related concepts, and alternative phrasings, while strictly preserving recognized entities, product names, and proper nouns in their original form. This is not a general-purpose synonym generator; it is a precision tool for enterprise search pipelines where entity integrity is non-negotiable and inappropriate synonym replacement can cause catastrophic relevance failures.

Use this prompt when your retrieval system operates over a corpus with high entity density—product catalogs, technical documentation, legal contracts, or medical literature—and you have a defined entity recognition pipeline or a controlled vocabulary of protected terms. The prompt expects a list of protected entities as input alongside the query, and it will produce expansion candidates that respect entity boundaries. Do not use this prompt for open-domain web search, casual chatbot queries, or scenarios where entity boundaries are ambiguous and no entity list is available. In those cases, a simpler synonym expansion prompt without entity constraints will be more appropriate and less prone to false-positive entity tagging.

Before deploying this prompt, ensure you have a reliable upstream entity recognition step. The prompt's effectiveness depends entirely on the quality of the entity list you provide. If your entity detector misses a product name, the prompt may expand it into inappropriate synonyms. Conversely, if your detector over-tags common nouns as entities, you will lose legitimate expansion opportunities. Plan to pair this prompt with an entity recognition model, a controlled vocabulary lookup, or a regex-based product name matcher. In high-stakes domains like healthcare or legal search, always include a human review step for the expanded query before it hits production retrieval, and log every expansion decision with entity boundary evidence for auditability.

This template is designed to be dropped directly into your application code or prompt management system. It expects a user query, an optional domain context, and a list of recognized entities that must be preserved exactly as they appear. The prompt instructs the model to generate synonym expansions for non-entity terms while leaving proper nouns, product names, and technical identifiers untouched. Use square-bracket placeholders to inject dynamic values at runtime before sending the request to the model.

textCopy
You are a query expansion assistant for an enterprise search system. Your task is to expand a user query with synonyms and related terms to improve retrieval recall, while strictly preserving all recognized named entities, product names, and proper nouns exactly as they appear.

## Input
User Query: [USER_QUERY]
Domain Context: [DOMAIN_CONTEXT]
Recognized Entities (do NOT modify or expand these): [RECOGNIZED_ENTITIES]

## Constraints
1. Do NOT generate synonyms, alternatives, or expansions for any term listed in Recognized Entities. Preserve them verbatim.
2. For all other terms in the query, generate up to [MAX_SYNONYMS_PER_TERM] synonyms or related phrases that are relevant to the Domain Context.
3. If a term is ambiguous, prefer the sense most relevant to the Domain Context.
4. Exclude synonyms that would contradict any negation terms (e.g., "not," "excluding," "without") present in the query.
5. Do not introduce new entities, facts, or concepts not implied by the original query.
6. If no meaningful synonyms exist for a term, skip it rather than forcing low-quality expansions.

## Output Schema
Return a JSON object with this exact structure:
{
  "original_query": "string",
  "preserved_entities": ["string"],
  "expansions": [
    {
      "original_term": "string",
      "synonyms": ["string"],
      "confidence": 0.0
    }
  ],
  "expanded_query_variants": ["string"],
  "warnings": ["string"]
}

## Field Descriptions
- original_query: The user query exactly as provided.
- preserved_entities: The list of entities that were protected from expansion.
- expansions: Array of objects, one per expanded term.
  - original_term: The term from the query that was expanded.
  - synonyms: Array of synonym strings, ordered by relevance (most relevant first).
  - confidence: A score from 0.0 to 1.0 indicating confidence that each synonym is contextually appropriate.
- expanded_query_variants: Up to [MAX_VARIANTS] full query strings combining original terms with selected synonyms. Each variant should be a coherent, searchable query.
- warnings: Any concerns about entity boundary ambiguity, potential false-positive entity tagging, or terms that could not be confidently expanded.

## Examples
[FEW_SHOT_EXAMPLES]

## Risk Level
[RISK_LEVEL]

Adaptation notes: Replace [USER_QUERY] with the raw user input. [DOMAIN_CONTEXT] should describe the knowledge domain (e.g., "enterprise cloud infrastructure documentation"). [RECOGNIZED_ENTITIES] must be a pre-extracted list from your entity recognition pipeline—never rely on the model to identify entities without verification. [MAX_SYNONYMS_PER_TERM] and [MAX_VARIANTS] control output size and should be tuned against your retrieval system's query length limits. [FEW_SHOT_EXAMPLES] should include 2-3 worked examples showing correct entity preservation and domain-appropriate synonym selection. Set [RISK_LEVEL] to "low" for internal search, "medium" for customer-facing retrieval where entity errors cause confusion, or "high" for regulated domains requiring human review of expansions before retrieval execution. Always validate the output JSON against the schema before passing expanded queries to your search backend. If the warnings field is non-empty, route the output for human review or log it for offline evaluation.

This prompt is designed to sit between the user's raw query and your retrieval backends. It accepts a natural language query and a list of recognized entities, then returns expanded terms while protecting those entities from inappropriate synonym replacement. The harness should treat this prompt as a pre-retrieval transformation step: the output terms feed directly into keyword search clauses, vector embedding generation, or hybrid fusion logic. Because the prompt must respect entity boundaries, the harness must provide accurate entity annotations upstream—typically from a dedicated NER model, a product catalog lookup, or a knowledge graph traversal—before calling this prompt.

Wire the prompt into your application as an async function with a strict input contract. The function signature should accept query: string and entities: Array<{name: string, type: string, start_char: number, end_char: number}>. Validate that entity spans align with the query string before calling the model; mismatched spans cause the prompt to protect the wrong tokens. On the output side, parse the model response against a JSON schema that includes expanded_terms: Array<{term: string, weight: number, source: 'synonym' | 'concept' | 'entity_alias'}> and protected_entities: Array<{name: string, type: string}>. If the model returns malformed JSON, retry once with a repair prompt that includes the raw output and the expected schema. If the second attempt fails, log the failure and fall back to the original query terms without expansion—never block the user's search on a prompt failure. For high-recall use cases where missing a synonym is costly, implement a second retry with a lower temperature to reduce output variance.

Model choice matters here. Use a model with strong instruction-following and JSON output discipline, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Set temperature between 0.1 and 0.3 to balance creativity in synonym generation with entity boundary stability. Avoid models that frequently rephrase entity names or hallucinate entity types. Log every call with the input query, detected entities, expanded terms, model latency, and any validation errors. This trace data is essential for debugging entity boundary violations and measuring expansion recall in production. Before shipping, run the prompt against a golden set of 50–100 queries with known entities and expected expansions. Measure entity preservation rate (entities must appear verbatim in the output), term relevance precision, and recall improvement against your retrieval metrics. Set a release gate: entity preservation must exceed 98% before this prompt reaches users. If your domain includes regulated content, route any query containing flagged entity types to a human review queue before expansion terms are applied to retrieval.