Profile-Driven Synonym Expansion Prompt for Domain Search

This prompt is for enterprise search and RAG teams whose users speak different departmental languages. When a user in Finance searches for 'AR aging' and a user in Sales searches for 'unpaid invoices,' they are looking for the same documents. This prompt expands a raw user query with synonyms, jargon, and canonical terms drawn from the user's specific profile, role, department, and team-controlled vocabularies. The output is a structured list of expansion terms with source attribution, ready to be injected into a keyword, vector, or hybrid retrieval pipeline. Use this prompt when your retrieval system must bridge the gap between how users ask and how documents are written, without leaking terms from other departments that would cause irrelevant results.

The ideal user is a search engineer or RAG developer who already has a working retrieval pipeline and a maintained mapping of departmental vocabularies. The prompt requires three inputs: the raw user query, a structured user profile containing at minimum the user's department and role, and a controlled vocabulary or synonym map specific to that department. Without a maintained vocabulary source, the model will hallucinate plausible but incorrect synonyms that degrade precision. Do not use this prompt when the user's department is unknown, when the vocabulary is stale, or when the retrieval system lacks a mechanism to weight or filter by expansion source. In those cases, a generic synonym expansion or no expansion at all will produce safer results.

The primary failure mode is cross-department term collision. A term that means one thing in Engineering may mean something entirely different in Legal. The prompt mitigates this by requiring source attribution for every expansion term and by scoping expansion strictly to the user's declared department. Before deploying, test with queries that contain ambiguous terms shared across departments and verify that the expansion output does not include terms from unauthorized vocabularies. A secondary failure mode is over-expansion, where too many synonyms dilute the query intent and retrieve irrelevant documents. Set a maximum expansion term limit in your implementation harness and monitor retrieval precision after deployment.

This prompt is a pre-retrieval step. It does not replace query decomposition, metadata filtering, or permission enforcement. Wire it into your pipeline before the retrieval call, and ensure downstream components can consume the structured expansion output. If your system serves multiple tenants or requires strict data isolation, combine this prompt with a permission-aware metadata filter generation step to prevent expanded terms from crossing tenant boundaries. Start with a small set of well-defined departmental vocabularies, measure recall improvement against a baseline of unexpanded queries, and expand vocabulary coverage only after validating that precision remains within acceptable thresholds.

This prompt template is the core instruction set for profile-driven synonym expansion. It takes a user's raw query and their structured profile, then generates a list of expansion terms drawn from departmental terminology, role-specific jargon, and team-controlled vocabularies. The output is designed to be fed directly into a keyword or hybrid search engine to improve recall without losing domain precision. Before pasting this into your system, ensure you have a reliable source for the user profile fields referenced in the placeholders.

textCopy
You are a domain-aware query expansion engine for an enterprise search system. Your task is to expand a user's search query with synonyms, related terms, and canonical vocabulary drawn exclusively from the user's departmental and role-specific context.

## INPUT
- User Query: [USER_QUERY]
- User Profile:
  - Department: [USER_DEPARTMENT]
  - Role: [USER_ROLE]
  - Team-Controlled Vocabulary: [TEAM_VOCABULARY]
  - Domain Taxonomy: [DOMAIN_TAXONOMY]

## CONSTRAINTS
- Only generate terms that are valid within the provided [DOMAIN_TAXONOMY] or [TEAM_VOCABULARY].
- Do not invent terms. If no relevant expansion exists, return an empty list.
- For each expansion term, cite the specific source (e.g., "Taxonomy ID: FIN-142", "Team Glossary: Q3-OKR").
- Prioritize terms that disambiguate the query based on the user's department. For example, the term "pipeline" for a Sales user should expand to "sales pipeline" and "deal flow," not "data pipeline."
- Avoid cross-department term collisions. If a term has a different meaning in another department, flag it in the `collision_risk` field.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "original_query": "string",
  "expansions": [
    {
      "original_term": "string",
      "expanded_terms": ["string"],
      "source": "string",
      "collision_risk": "string | null"
    }
  ]
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with live data before sending it to the model. The [FEW_SHOT_EXAMPLES] placeholder is critical for teaching the model the difference between valid domain expansion and generic synonym generation. Include at least one example where a term has a high collision_risk and is correctly flagged. The [RISK_LEVEL] field should be set to "high" if the search results will be used for compliance, legal, or safety-critical decisions, which should trigger additional validation and human review of the expansion terms before retrieval. After generating the expansion, validate the output JSON against the schema and check that every source field references a real entry in your provided vocabulary or taxonomy.

This prompt is not a standalone chatbot interaction. It is a pre-retrieval expansion step that sits between the user's raw query and your search backend. The typical call pattern is: receive user query and user profile → assemble the prompt with [USER_QUERY], [USER_PROFILE], and [DOMAIN_TAXONOMY] → call the LLM → parse the structured output → append or inject the expansion terms into the retrieval query. The output should be a list of expansion terms with source attribution (e.g., "term": "churn rate", "source": "marketing_dept_taxonomy"), which you can use to boost recall in keyword search, add should clauses in Elasticsearch/OpenSearch, or generate additional vector query variants. Do not replace the user's original query with the expanded terms; always combine them to preserve user intent.

Validation and parsing are critical because a malformed expansion list can pollute retrieval with irrelevant terms. Implement a strict output parser that expects a JSON array of objects with term (string) and source (string) fields. Reject any output that does not conform to this schema and retry with a repair prompt. Add a term denylist to filter out generic, high-frequency terms that add noise (e.g., 'the', 'data', 'report'). Validate that each expansion term's source matches a known entry in your [DOMAIN_TAXONOMY]; discard unattributed terms. For high-stakes domains like legal or healthcare, route unattributed expansions to a human review queue before they enter the retrieval pipeline. Log every expansion request with the user ID, original query, expanded terms, and source attributions for auditability.

Caching and cost control are essential because user profiles and domain taxonomies change infrequently. Cache expansion results keyed on a hash of (user_query, user_department, user_role, taxonomy_version). Invalidate the cache when the taxonomy is updated or when a user's role changes. For latency-sensitive applications, run this prompt asynchronously: return initial results using the raw query while the expansion prompt executes, then re-rank or supplement results when the expansion terms arrive. Choose a fast, cost-efficient model for this task (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) because the prompt is a structured extraction task, not a reasoning-heavy one. Avoid over-expansion: cap the number of expansion terms per query (e.g., 5–10) to prevent query bloat and degraded retrieval performance.

Observability and eval should be built into the harness from day one. Track metrics: expansion latency, cache hit rate, term rejection rate (denylist and unattributed), and retrieval recall improvement with vs. without expansion. Run offline evals using a golden dataset of (query, user_profile, expected_expansion_terms) pairs. Measure precision and recall of the expansion terms against the expected set. Monitor for cross-department term collision—when the same term has different meanings in different departments (e.g., 'lead' in sales vs. marketing). If collision is detected, the harness should either disambiguate using the user's department context or flag the term for human review. Set up alerts for sudden spikes in unattributed terms or parser failures, which often indicate a prompt drift or taxonomy mismatch.

What to do next: Start by implementing the prompt with a strict JSON output parser and a basic denylist. Run it offline against a sample of 100 real user queries with known-good expansion terms to calibrate your parser and denylist. Then deploy it in shadow mode—log expansions without injecting them into retrieval—to measure term quality and collision rates before turning it on in production. Avoid wiring this directly into retrieval without first validating that the expansion terms actually improve recall for your specific domain and user base.