Inconsistency-Aware Query Rewriting Prompt

This prompt is for retrieval engineers and RAG pipeline builders who need to improve recall when the underlying knowledge base contains contradictory or dissenting sources. The core job-to-be-done is transforming a user's original question into one or more retrieval queries that explicitly surface conflicting evidence, alternative viewpoints, and minority positions—rather than letting a naive keyword or vector search return only the dominant or most semantically similar chunks. The ideal user is someone who already has a working retrieval system, has observed that contradictory documents exist in the corpus, and needs the retrieval step to actively seek out disagreement instead of collapsing it. Required context includes the user's original query, a description of the document domain, and optionally a list of known conflict dimensions or viewpoints to probe.

Do not use this prompt when the knowledge base is known to be internally consistent, when surfacing conflict would confuse downstream users without proper UI handling, or when the retrieval system lacks the capacity to return and rank a diverse set of results. This prompt is also inappropriate for single-source Q&A, factoid lookup where only one answer is acceptable, or real-time systems where query expansion latency is unacceptable. If your RAG pipeline already has a conflict-aware answer generation step, this prompt should be placed upstream in the retrieval phase—it rewrites queries before they hit the vector store or search index. The rewritten queries should be used alongside, not instead of, the original query to maintain baseline recall while adding conflict coverage.

Before deploying this prompt, establish eval criteria: compare retrieval recall for known contradictory document pairs with and without query rewriting, measure the diversity of sources in the top-k results, and check that rewritten queries do not introduce hallucinated entities or drift from the user's intent. Start with a small set of before/after query pairs that represent real conflict scenarios in your domain, and use those as a golden eval set. If the rewritten queries introduce noise or irrelevant tangents, constrain the prompt with domain-specific guardrails and limit the number of alternative queries generated. The next step is to wire this prompt into your retrieval harness with logging, latency budgets, and a fallback to the original query if rewriting fails or times out.

This section provides a copy-ready prompt template for inconsistency-aware query rewriting. The template transforms a user's original question into one or more retrieval queries explicitly designed to find contradictory evidence, alternative viewpoints, and dissenting sources. Use this when your retrieval pipeline returns one-sided results or when downstream answer generation must surface conflict rather than hide it. The template uses square-bracket placeholders that you replace with your application's specific inputs, constraints, and output schema before wiring it into your RAG pipeline.

textCopy
You are a retrieval query rewriter for a knowledge base that contains conflicting documents. Your job is to rewrite a user's question into multiple retrieval queries that explicitly surface contradictory evidence, alternative viewpoints, and dissenting sources.

## Input
Original user question: [USER_QUESTION]
Domain context: [DOMAIN_CONTEXT]
Known source types available: [SOURCE_TYPES]

## Rewriting Rules
1. Produce at least [MIN_QUERIES] and at most [MAX_QUERIES] rewritten queries.
2. Each query must target a distinct perspective, methodology, timeframe, or source type that could yield conflicting evidence.
3. Include at least one query that explicitly searches for dissenting or minority viewpoints.
4. Include at least one query that searches for temporal or version-based conflicts if [DOMAIN_CONTEXT] involves time-sensitive information.
5. Do not introduce claims not present in the original question. Expand the retrieval surface, not the question's scope.
6. Preserve the original question's intent while broadening the evidentiary net.

## Output Schema
Return a JSON object with this exact structure:
{
  "original_question": "string",
  "rewritten_queries": [
    {
      "query": "string",
      "target_perspective": "string explaining what kind of conflicting evidence this query targets",
      "source_type_preference": "string or null indicating preferred source type for this query"
    }
  ],
  "conflict_dimensions_covered": ["list of conflict types targeted across all queries"]
}

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with your application's concrete values. [USER_QUESTION] receives the end user's raw input. [DOMAIN_CONTEXT] should describe the knowledge domain, temporal sensitivity, and known areas of disagreement. [SOURCE_TYPES] lists the document categories available in your retrieval index. [MIN_QUERIES] and [MAX_QUERIES] control retrieval cost and breadth. [CONSTRAINTS] can specify forbidden query patterns, required terminology, or output length limits. [EXAMPLES] should include at least two before/after query pairs showing how a neutral question becomes conflict-aware retrieval queries. After adapting the template, validate outputs against your eval set using exact-match checks on the JSON schema, semantic similarity checks on query intent, and manual review of conflict dimension coverage for the first 50 rewrites. For high-stakes domains, route rewrites through human review before they enter the retrieval pipeline.

This prompt sits between the user's original question and your retrieval system. It rewrites the query to explicitly surface contradictory evidence, alternative viewpoints, and dissenting sources. The harness should treat the rewritten query as an augmented retrieval input—not a replacement for the original. Always run both the original and rewritten queries in parallel or as a multi-query fusion step, then deduplicate and rank results. The rewritten query is most valuable when your knowledge base contains documents from competing vendors, different time periods, or jurisdictions with conflicting rules.

Validation and retry logic. Before sending the rewritten query to retrieval, validate that the output is not identical to the input, contains at least one conflict-surfacing term (e.g., 'disagree', 'alternative', 'contrary', 'versus'), and does not hallucinate entities not present in the original query. If validation fails, retry once with a stricter instruction appended: 'The rewritten query must differ from the original and introduce conflict-aware language.' If the second attempt also fails, fall back to the original query alone and log the failure for review. For high-stakes domains, route validation failures to a human reviewer before retrieval proceeds.

Model choice and latency budget. This prompt is lightweight and works well with fast, cost-effective models like GPT-4o-mini, Claude Haiku, or Gemini Flash. Latency should be under 500ms for most queries. If you're using a multi-step retrieval pipeline, run the rewrite in parallel with other query expansion steps rather than sequentially. Logging and observability. Log every rewrite pair (original → rewritten) alongside the validator result, model used, and latency. This log becomes your eval dataset for measuring whether rewrites actually improve recall on conflict-bearing queries. Compare retrieval recall with and without rewriting on a golden set of known-conflict questions. If rewriting does not improve recall for your domain after 100+ logged pairs, consider disabling it or tuning the prompt's examples to match your source types.

Integration pattern. In a typical RAG pipeline, insert this prompt after query classification and before vector or hybrid retrieval. If your system already performs query decomposition, run this prompt on each sub-query independently. For systems using multiple retrievers (e.g., vector + keyword), apply the rewritten query to all retrievers and fuse results with the original query's results. What to avoid. Do not show the rewritten query to end users—it's an internal retrieval artifact. Do not use the rewritten query as the basis for answer generation; the original user question should anchor the final response. Do not skip validation: a rewrite that introduces hallucinated entities will poison retrieval and degrade answer quality.