Summarization Intent Query Rewrite Prompt Template

This prompt is for search engineers and RAG system designers who need to detect when a user query is asking for a condensed overview or synthesis of a topic, rather than a specific fact, comparison, or step-by-step procedure. The prompt rewrites the original query to favor broad-coverage passages that span multiple facets of the topic. Use this prompt as a pre-retrieval step in a RAG pipeline when your knowledge base contains long-form documents, reports, or articles and you need to ensure the retrieval step surfaces diverse, representative context instead of a single dense passage.

The ideal deployment point is immediately after query intake and before any vector or keyword search execution. The rewritten query should be passed to your retrieval backend, and the coverage breadth indicator can be used downstream to adjust retrieval parameters—for example, increasing the top_k value or enabling diversity reranking when the indicator signals a broad-coverage need. Do not use this prompt for factoid lookups, troubleshooting, or procedural how-to queries; those intents require different rewriting strategies that anchor on entities, error signatures, or sequential action language respectively. Misapplying this prompt to a factoid query will dilute retrieval precision and surface irrelevant overview passages when the user needed a single definitive answer.

Before integrating this prompt into production, build a small evaluation set of 20–30 queries with human-labeled intent (summarization vs. non-summarization) and verify that the prompt correctly classifies intent and produces rewrites that improve retrieval diversity metrics. Common failure modes include misclassifying comparison queries as summarization requests and producing rewrites that are too vague to retrieve useful content. If your knowledge base is primarily short-form or highly structured (e.g., API reference docs, database records), this prompt may add latency without improving retrieval quality—test on your actual corpus before committing to the pipeline.

This prompt template is designed to be placed in your system instructions or as a pre-retrieval rewriting step. Its job is to analyze a user's query, determine if they want a condensed overview or summary, and if so, rewrite the query to favor documents that provide broad, multi-faceted coverage rather than a single, dense fact. The output includes a rewritten query string and a coverage breadth indicator, which your application can use to adjust retrieval parameters like the number of documents fetched or the diversity threshold.

textCopy
You are a query rewriting agent for a retrieval system. Your task is to analyze the user's query and determine if the underlying intent is summarization: the user wants a condensed, high-level overview of a topic, not a specific fact, a step-by-step procedure, or a comparison.

If the intent is summarization, rewrite the query to optimize for broad-coverage retrieval. The rewritten query should:
- Use general, encompassing terms instead of narrow, specific ones.
- Target introductory, overview, or abstract-type content.
- Be structured to retrieve documents that cover multiple facets of the topic.
- Avoid terms that would bias retrieval toward a single, dense passage.

If the intent is NOT summarization, return the original query unchanged and set the coverage indicator to 'none'.

[INPUT]
User Query: [USER_QUERY]

[OUTPUT_SCHEMA]
Return a valid JSON object with the following fields:
{
  "intent_detected": "summarization" | "other",
  "rewritten_query": "string",
  "coverage_breadth": "broad" | "focused" | "none"
}

[CONSTRAINTS]
- Do not add information not present in the original query.
- Do not change the core subject of the query.
- The rewritten query must be a single, self-contained string.
- If intent is not summarization, rewritten_query must be the original [USER_QUERY].

To adapt this template, replace the [USER_QUERY] placeholder with your application's user input. The [OUTPUT_SCHEMA] is critical for your downstream parser; ensure your application code validates the JSON structure and handles the coverage_breadth field to dynamically set retrieval parameters. For high-stakes applications, log the intent_detected and rewritten_query for offline evaluation to monitor for intent drift. Next, you should pair this prompt with an evaluation harness that tests whether the rewritten queries actually retrieve a more diverse set of documents than the original query.

Integrating this prompt into an application requires treating it as a pre-retrieval transformation step, not a standalone chatbot. The prompt receives a raw user query and returns a rewritten query plus a coverage breadth indicator. The application harness must validate this output before passing it to the retrieval backend. A minimal harness accepts the user query, injects it into the [USER_QUERY] placeholder, calls the model, parses the JSON response, extracts the rewritten_query field, and forwards it to your vector or hybrid search index. The coverage_breadth field should be logged for observability but can also be used to dynamically adjust retrieval parameters—for example, increasing the top_k value when breadth is 'high' to ensure sufficient document diversity.

Validation is the first line of defense against production drift. The harness must confirm that the model returned valid JSON, that rewritten_query is a non-empty string, and that coverage_breadth is one of the expected enum values ('low', 'medium', 'high'). If validation fails, implement a retry with a stricter system instruction that emphasizes JSON-only output. For high-throughput systems, consider a lightweight regex or JSON Schema validator before the parsed output enters the retrieval path. Log every rewrite attempt—original query, rewritten query, breadth indicator, model used, and latency—so that query drift and intent misclassification can be diagnosed later. If the model consistently rewrites summarization queries as narrow factoid lookups, the eval harness should catch this and trigger a prompt revision.

Model choice matters for this task. The prompt requires intent detection and constrained generation, which most frontier models handle well, but smaller or older models may conflate summarization intent with factual lookup. Test across your candidate models using a golden dataset of summarization queries paired with expected breadth indicators. If using a model that does not reliably produce JSON, wrap the prompt output in a repair step or use structured output APIs (e.g., OpenAI's JSON mode, Claude's tool use with a defined schema). For latency-sensitive applications, consider routing only queries above a certain length or complexity threshold to this rewrite step, while passing short, unambiguous queries directly to retrieval. The coverage_breadth field can also feed into a downstream re-ranker that prioritizes diverse passages when breadth is high, closing the loop between intent detection and result quality.