Multi-Part RAG Context Assembly Prompt Template

This prompt is designed for RAG system builders who need to merge multiple retrieved context chunks into a single, coherent context block before generation. It addresses the common failure mode where fragmented retrieval results contain redundant passages, conflicting information, or irrelevant segments that degrade downstream answer quality. Use this prompt when your retrieval pipeline returns overlapping chunks from a vector database, keyword search, or hybrid retrieval system, and you need to deduplicate, reorder by relevance, and preserve source mapping before the context is passed to the answer-generation model.

This is a pre-generation assembly step, not a post-hoc repair of a generated answer. It belongs in the context engineering layer of your RAG pipeline, after retrieval and before the final LLM call. The prompt expects you to provide retrieved chunks with their source identifiers, relevance scores, and the original user query. It will produce a deduplicated, relevance-ordered context block with preserved source-to-content mapping. Do not use this prompt when you have a single retrieved chunk, when chunks are already non-overlapping and correctly ordered, or when you need the model to answer a question rather than assemble context. For those cases, skip directly to your answer-generation prompt or use a dedicated question-answering template.

Before deploying this prompt, validate that your retrieval pipeline actually produces overlapping or redundant chunks. If your chunking strategy already enforces non-overlapping boundaries and your retrieval returns a clean ranked list, this assembly step adds latency without benefit. Measure the overlap ratio in your retrieved context sets first—if less than 10% of tokens are redundant across chunks, you may not need this prompt. When you do use it, always log the input chunk count, output token count, and deduplication ratio to monitor whether the assembly step is providing value or introducing its own errors. Pair this prompt with a schema validation check on the output to ensure source mappings remain intact and no chunks were silently dropped.

The core of this playbook is a prompt template designed to take a set of retrieved text chunks—often overlapping, redundant, or in a suboptimal order—and transform them into a clean, coherent context block ready for a generation model. This template is built for direct integration into your RAG pipeline's context assembly step, sitting between retrieval and answer generation. It expects you to provide the raw retrieved passages and a set of constraints that define the desired output structure, such as a maximum token budget or a required ordering logic.

textCopy
You are an expert context assembly engine. Your task is to process a set of retrieved text chunks and produce a single, optimized context block for a downstream generation model.

## INPUT
<retrieved_chunks>
[RETRIEVED_CHUNKS]
</retrieved_chunks>

## ASSEMBLY RULES
1. **Deduplicate:** Identify and remove semantically redundant passages. If two chunks convey the same information, keep the most complete and well-formed version.
2. **Order by Relevance:** Reorder the remaining chunks from most to least relevant to the user's query. Place the strongest, most direct evidence first.
3. **Remove Noise:** Strip out any chunk that is clearly irrelevant, is a navigation fragment, or contains only boilerplate text.
4. **Preserve Source Mapping:** For every piece of information you keep, you MUST retain its original `source_id`. Do not merge content from different sources into a single paragraph.
5. **Respect Budget:** The final assembled context must not exceed [MAX_TOKENS] tokens in length. Prioritize the most relevant information to fit within this budget.

## OUTPUT FORMAT
Produce a JSON object with the following structure:
{
  "assembled_context": "A single string containing the deduplicated, ordered, and concatenated text chunks, separated by double newlines.",
  "source_map": [
    {"source_id": "original_id_1", "content_snippet": "first 50 chars..."},
    {"source_id": "original_id_2", "content_snippet": "first 50 chars..."}
  ],
  "dropped_chunks": [
    {"source_id": "original_id_3", "reason": "Redundant with source_id_1"},
    {"source_id": "original_id_4", "reason": "Irrelevant navigation text"}
  ]
}

## USER QUERY (for relevance context)
[USER_QUERY]

To adapt this template for your own system, start by replacing the [RETRIEVED_CHUNKS] placeholder with your actual retrieval results, ensuring each chunk is a string with a unique source_id. The [USER_QUERY] is critical for the relevance-ordering step; without it, the model cannot prioritize effectively. The [MAX_TOKENS] constraint should be set based on the context window of your final generation model, minus the tokens reserved for the system prompt and the user's question. If your application requires a different output format, such as a simple string without the source map, modify the OUTPUT FORMAT section accordingly, but be aware that removing the source_map will break downstream citation workflows. For high-stakes applications, always validate the output JSON schema and verify that the source_ids in the map match the original input.

This prompt operates as a pre-generation assembly step in a RAG pipeline. It receives multiple retrieved context chunks—potentially from different sources, with varying relevance scores and overlapping content—and produces a single coherent context block for the downstream generation model. The harness must manage chunk ordering, deduplication, source mapping preservation, and token budget enforcement before the assembled context ever reaches the generator.

Pipeline placement: Insert this prompt between retrieval and generation. The retriever returns N chunks with metadata (source ID, relevance score, retrieval query). The harness packages these into the [RETRIEVED_CHUNKS] placeholder as a structured list, each chunk carrying its source identifier. The prompt assembles them, and the output becomes the [ASSEMBLED_CONTEXT] for the generation prompt. Validation: After assembly, validate that every source ID referenced in the output exists in the input chunks. Reject assemblies that introduce hallucinated sources. Check that the assembled context does not exceed the target token budget—if it does, truncate the lowest-relevance passages and re-run assembly rather than silently overflowing. Retry logic: If validation fails (missing sources, budget overflow, empty output), retry once with explicit error feedback injected into [CONSTRAINTS]. If the second attempt fails, fall back to a simple concatenation of top-k chunks ordered by relevance score, bypassing the assembly prompt entirely.

Source mapping preservation: The assembled output must retain traceability. Implement a post-processing step that extracts every [SOURCE_ID] marker from the assembled context and cross-references it against the input chunk metadata. Store this mapping alongside the assembled context so the downstream generation prompt can cite sources accurately. Logging: Log the input chunk count, output token count, deduplication rate (chunks removed divided by total input), assembly latency, and validation pass/fail for every call. These metrics will surface retrieval quality degradation and assembly prompt drift over time. Model choice: Use a fast, instruction-following model for assembly (e.g., GPT-4o-mini, Claude Haiku) rather than the larger generation model. Assembly is a mechanical task—deduplication, ordering, merging—that does not require deep reasoning. Reserve the larger model for generation over the assembled context. Human review gate: For regulated domains, flag assemblies where the deduplication rate exceeds 50% (indicating highly redundant retrieval) or where source count drops below a minimum threshold. Route these to a review queue before generation proceeds.