Contextual Query Expansion with Negation Handling Prompt

This prompt is designed for retrieval pipelines in conversational AI systems where users issue follow-up questions containing negation. Standard query expansion techniques often strip or mis-scope negation terms like 'not', 'without', 'excluding', or 'never', causing retrieval to return precisely the documents the user wanted to avoid. The job-to-be-done is preserving user intent by expanding queries with synonyms and related terms while maintaining strict negation boundaries, detecting negated clauses from prior turns, and preventing false-positive retrieval that contradicts stated exclusions.

Use this prompt when your RAG system handles multi-turn conversations and you observe users complaining about results that contradict their stated exclusions. It is ideal for search relevance engineers who need to expand recall without sacrificing precision on negated constraints. The prompt requires conversation history as input and works best when your retrieval backend can process structured boolean clauses or weighted term exclusions. You should also use it when negation signals span multiple turns—for example, when a user says 'show me options without vendor lock-in' in turn one and then asks 'which of these are cheapest?' in turn two, the exclusion must carry forward into the rewritten query.

Do not use this prompt for single-turn search where no conversation history exists, or when your retrieval backend cannot handle structured boolean clauses. It is also inappropriate when negation is rhetorical rather than literal ('I don't suppose you have...'), when the user's exclusion is too vague to operationalize ('nothing boring'), or when latency budgets are too tight for the additional LLM call required for query rewriting. If your system already uses a deterministic query parser that handles negation correctly, adding an LLM-based expansion step may introduce unnecessary complexity and cost. Start by measuring your current false-positive rate on negated queries before deciding whether this prompt is needed.

This prompt template is designed to be pasted directly into your system. It instructs the model to act as a query rewriter that expands a user's search query for better recall while strictly preserving any negation signals. The template uses square-bracket placeholders like [CONVERSATION_HISTORY], [CURRENT_QUERY], and [DOMAIN_CONTEXT] that you must replace with your application's runtime values. The core instruction forces the model to output a structured JSON object containing the expanded query and a list of detected negation constraints, making it easy to parse and validate in a downstream retrieval pipeline.

textCopy
System: You are a precise query expansion assistant. Your task is to rewrite a user's search query to improve retrieval recall by adding relevant synonyms, related concepts, and common phrasings. Your most critical job is to identify and preserve any negation signals, such as 'not', 'excluding', 'without', or 'avoid', from both the current query and the conversation history. Never introduce terms that contradict a negation constraint. Output your response as a single, valid JSON object with the keys "expanded_query" (a string) and "negation_constraints" (an array of strings).

[DOMAIN_CONTEXT]

Conversation History:
[CONVERSATION_HISTORY]

User Query: [CURRENT_QUERY]

Output Schema:
{
  "expanded_query": "<rewritten query string with synonyms and related terms, preserving all negations>",
  "negation_constraints": ["<list of all active negation terms or phrases detected in the query and history>"]
}

To adapt this template, replace the placeholders with your application's data. [CONVERSATION_HISTORY] should be a formatted string of the last few user and assistant turns. [CURRENT_QUERY] is the raw user input. [DOMAIN_CONTEXT] is optional but highly recommended; use it to inject a glossary of domain-specific synonyms or a list of common entity names to guide the expansion. Before deploying, you must implement a post-processing validation step. Check that the output is valid JSON and that every term in the negation_constraints array is not present in the expanded_query string. A failure in this check should trigger a retry or fallback to the raw user query to prevent a hallucinated expansion from violating a user's explicit constraint.

This prompt is designed to sit between the user's conversational turn and your retrieval backend. It accepts the current query, conversation history, and optional metadata, and returns a rewritten query that expands concepts while preserving negation signals. The harness should treat this as a pre-retrieval transformation step in your RAG pipeline. The model call is stateless: your application must supply the relevant conversation window and any session-level filters. Do not rely on the model to remember prior turns across invocations.

Pipeline integration: Place this prompt after dialogue state tracking and before query execution. The application should construct the prompt payload by assembling [CURRENT_QUERY], [CONVERSATION_HISTORY] (last N turns, formatted as speaker-labeled lines), and [METADATA_FILTERS] (active date ranges, document scopes, or user permissions). On success, parse the model's output to extract the rewritten query string and any structured negation constraints. Validate the output before retrieval: check that the rewritten query is non-empty, that negation terms from the input are preserved or correctly transformed, and that no hallucinated entities appear. If validation fails, fall back to the original query and log the failure for analysis.

Model choice and configuration: Use a model with strong instruction-following and structured output capabilities. Set temperature low (0.0–0.2) to minimize creative drift in query rewrites. If your provider supports it, request JSON mode with a schema that includes rewritten_query, negation_terms_preserved, and expansion_terms_added fields. This makes downstream validation programmatic rather than regex-based. For latency-sensitive applications, consider a smaller, fine-tuned model deployed behind a dedicated inference endpoint. Cache frequent query patterns when session context is identical to reduce redundant API calls.

Retry and fallback strategy: Implement a single retry on parse failure or empty output. If the retry also fails, log the raw response and route the original query to retrieval without expansion. Do not retry more than once for the same input—diminishing returns and latency costs escalate quickly. For high-risk domains where negation mishandling could surface incorrect documents, add a negation verification step: after retrieval, check whether any returned documents contradict explicit negation constraints from the rewritten query. Flag contradictions for human review or automatic re-retrieval with stricter filters.

Observability and evaluation: Log every rewrite with the original query, conversation context window, rewritten output, validation status, and retrieval latency. This trace data feeds into offline evaluation. Run periodic eval suites that test negation boundary cases: queries like 'show me results excluding Q4' or 'find documents not related to Project Alpha' should produce rewrites where the exclusion is explicit and scoped correctly. Track false-positive expansion (adding terms that violate negation) and false-negative preservation (dropping negation signals). Use these metrics to decide when the prompt template needs updating or when the model should be swapped. Wire eval failures into your CI pipeline so prompt changes are gated before deployment.