Context Prioritization Prompt for Dense Retrieval Results

This prompt is for AI engineers and RAG pipeline builders who need to turn a noisy, redundant set of retrieved passages into a ranked, coverage-maximizing context window that fits within a token budget. The job is not to generate an answer—it is to select and order the evidence that will be passed to a downstream answer-generation prompt. Use it when your dense retrieval returns dozens or hundreds of chunks, many of which overlap, repeat the same facts, or contribute no unique information to the query. The prompt expects you to supply the original user query, the raw retrieved passages with their metadata, a target top-k count, and a maximum token budget. It returns a ranked list of selected passages, each annotated with a selection rationale covering relevance, uniqueness, and authority.

Do not use this prompt when the retrieval set is already small (fewer than 10 passages), when all passages are known to be non-overlapping, or when you have already applied a separate deduplication step that guarantees uniqueness. It is also the wrong tool when you need an answer directly—this prompt produces a curated context list, not a final response. If your downstream answer prompt has strict citation requirements, pair this prioritization step with a citation-preserving context assembly so that source provenance survives the selection cut. In high-stakes domains such as clinical or legal Q&A, add a human review gate after prioritization to confirm that no answer-critical evidence was dropped during the top-k selection.

Before wiring this into production, define your evaluation criteria: measure whether the selected passages preserve answer recall compared to the full retrieval set, and track the token savings achieved. Common failure modes include over-prioritizing highly relevant but redundant passages at the expense of unique supporting evidence, or dropping a low-relevance passage that contains a critical date or figure. Start by running this prompt against a golden dataset of query–retrieval pairs where you know which passages are essential, and tune the uniqueness and authority weighting in the template until the top-k set consistently includes those essentials.

This prompt template is the core instruction set for a context prioritization step in your RAG pipeline. It expects a set of retrieved passages, a user query, and a token budget. The model ranks each passage on three axes—relevance to the query, information uniqueness relative to other passages, and source authority—then selects a final set that maximizes coverage without exceeding the budget. The output includes the selected passages, their rank scores, and a brief rationale for each selection decision. Use this template when dense retrieval returns more passages than your context window can hold and you need a principled, auditable way to choose what to keep.

codeCopy
You are a context prioritization engine for a retrieval-augmented generation system. Your job is to rank retrieved passages and select a top-k set that maximizes information coverage within a strict token budget.

## INPUT
- Query: [QUERY]
- Retrieved Passages (each with a unique ID, source title, and text):
[RETRIEVED_PASSAGES]
- Token Budget: [TOKEN_BUDGET]
- Top-K Target: [TOP_K]

## RANKING CRITERIA
For each passage, assign a score from 0.0 to 1.0 on each axis:
1. **Relevance**: How directly the passage addresses the query intent. Penalize keyword matches without semantic alignment.
2. **Uniqueness**: How much new information this passage contributes beyond higher-ranked passages already selected. A passage repeating known facts scores low.
3. **Authority**: Source credibility based on recency, publication type, and author expertise. Flag passages from deprecated or unofficial sources.

## SELECTION RULES
- Select passages in descending order of a composite score: (Relevance * 0.5) + (Uniqueness * 0.3) + (Authority * 0.2).
- After each selection, recompute Uniqueness scores for remaining passages against the growing selected set.
- Stop when adding the next passage would exceed [TOKEN_BUDGET] or when [TOP_K] passages have been selected.
- If two passages have identical composite scores, prefer the one with higher Authority.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "selected_passages": [
    {
      "passage_id": "string",
      "source_title": "string",
      "text": "string (full passage text)",
      "relevance_score": number,
      "uniqueness_score": number,
      "authority_score": number,
      "composite_score": number,
      "selection_rationale": "string (one sentence explaining why this passage was chosen)"
    }
  ],
  "excluded_passages": [
    {
      "passage_id": "string",
      "exclusion_reason": "string (one of: 'below_relevance_threshold', 'redundant_information', 'budget_exhausted', 'low_authority')"
    }
  ],
  "coverage_assessment": "string (brief summary of what the selected set covers and any known gaps)",
  "total_tokens_used": number
}

## CONSTRAINTS
- Do not modify or paraphrase passage text. Return the original text exactly.
- If no passage exceeds a relevance score of 0.3, return an empty selected_passages array and set coverage_assessment to 'No sufficiently relevant passages found.'
- If the token budget cannot accommodate even the single most relevant passage, select no passages and explain in coverage_assessment.

To adapt this template, start by tuning the composite score weights. The default 0.5/0.3/0.2 split prioritizes relevance heavily; if your domain has highly redundant retrieval results, increase the Uniqueness weight to 0.4 and drop Relevance to 0.4. If source credibility is paramount—for example, in regulatory or clinical contexts—push Authority to 0.3 or higher. The relevance floor of 0.3 is a safety threshold; lower it for exploratory search use cases and raise it for high-stakes Q&A where wrong answers are costly. Always validate the output JSON against the schema before passing selected passages to your answer generation step. For production, wrap this prompt in a retry harness that catches malformed JSON, missing required fields, or empty selections when the query clearly has relevant results available.

The context prioritization prompt is designed to sit between retrieval and answer generation in a RAG pipeline. It consumes a list of retrieved passages and a user query, then produces a ranked, filtered set of passages that fit within a specified token budget. In production, this prompt should be called as a dedicated preprocessing step—not bundled into the final answer-generation call—so that its output can be validated, logged, and inspected before downstream consumption. The typical call pattern is: retrieve N passages from your vector or hybrid search index, pass them through this prompt with a token budget derived from your model's context window minus space reserved for the system prompt, user query, and answer-generation instructions, then forward only the selected passages to the answer-generation model.

Validation and retry logic is critical because the prompt's output schema includes a ranked list with selection rationale. Implement a post-processing validator that checks: (1) the output is valid JSON matching the expected schema, (2) the total token count of selected passages does not exceed the specified budget, (3) every selected passage exists in the input set, and (4) the ranking is monotonic (no duplicate ranks). On validation failure, retry once with the same input and an explicit error message appended to the prompt instructing the model to correct the specific violation. If the second attempt also fails, fall back to a simpler truncation strategy (e.g., take the top-k passages by retrieval score) and log the failure for investigation. For high-stakes domains, route validation failures to a human review queue rather than silently degrading.

Model choice matters for this prompt. It requires strong instruction-following and structured output capabilities. Use a model that reliably produces valid JSON with complex schemas—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may drop fields, hallucinate passage content, or ignore the token budget constraint. If latency is a concern, consider running this prompt on a fast, mid-tier model and validating aggressively, with a slower, more capable model as the retry fallback. Logging should capture: the input passage count, the token budget, the number of passages selected, the rationale strings, and the validation result. This data feeds directly into eval pipelines that measure whether prioritization improves downstream answer quality or reduces hallucination rates.

Tool use and RAG integration: This prompt does not call external tools itself, but it should be wired into a pipeline where retrieval scores, source metadata, and passage timestamps are available as input fields. If your retrieval system already provides relevance scores, include them in each passage object so the model can use them as a ranking signal. For compliance-sensitive deployments, preserve source provenance through the prioritization step—the output must retain document IDs or URLs so that downstream answer-generation prompts can cite original sources even after passages are filtered or merged. Wire the prioritization output directly into your answer-generation prompt's [CONTEXT] placeholder, and ensure your observability stack traces which passages were selected for each user query so you can debug answer quality regressions to specific prioritization decisions.

What to avoid: Do not set the token budget to the full context window—reserve at least 20-30% for the system prompt, user query, and answer-generation instructions. Do not skip validation in production; malformed prioritization output will silently corrupt downstream answers. Do not use this prompt for real-time streaming applications without measuring the added latency; the prioritization step adds one full model round-trip before answer generation begins. If latency is unacceptable, consider caching prioritization results for repeated queries or using a lightweight embedding-based reranker as a faster alternative, reserving this prompt for offline batch processing or high-value queries where accuracy justifies the cost.