Map-Reduce Summarization: Breaking Long Texts into Parts
The pattern borrows its name from the distributed computing paradigm: divide a large problem into independent sub-problems (map), solve them in parallel, then combine results (reduce). For summarization, the sub-problems are chunk-level summaries, and the combination step is a synthesis that merges them into a unified narrative. Unlike the refine pattern (which processes sequentially), map-reduce allows full parallelization of the most expensive step, making it 5-10x faster for long documents.
Step 1: Split the Document into Chunks
The chunking strategy determines both processing efficiency and output quality. You are balancing three competing concerns: chunks must fit within the context window (hard constraint), chunks should be large enough to contain complete ideas (quality concern), and chunk count should be manageable for the reduce step (practical concern).
Optimal chunk size: 4,000-8,000 tokens. Smaller chunks (under 2,000 tokens) produce summaries that are too fragmented for the reduce step to work with effectively. Larger chunks (over 12,000 tokens) work fine technically but produce fewer, longer chunk summaries that are harder to combine without redundancy. The 4,000-8,000 range gives the model enough context per chunk to produce meaningful summaries while keeping individual calls fast (1-3 seconds each).
Boundary respect. Never split mid-sentence. Prefer splitting at paragraph boundaries. Best case: split at section or heading boundaries. A practical algorithm: accumulate paragraphs until the next paragraph would push the chunk past your target size, then close the chunk and start a new one. This ensures every chunk contains complete paragraphs and usually complete logical units.
Overlap between chunks. Adding 200-500 tokens of overlap between adjacent chunks costs 5-10% extra in processing but improves reduce quality for documents where ideas flow continuously across chunk boundaries. The overlap tokens appear in two adjacent chunk summaries, giving the reduce step enough signal to maintain continuity. Skip overlap for documents with clear section structure (each section is self-contained) and use overlap for flowing narrative text (novels, long-form journalism, transcripts).
Chunk ordering metadata. Tag each chunk with its position (chunk 1 of 12, chunk 2 of 12, etc.) and pass this to the map prompt. Position awareness helps the model understand that chunk 1 likely contains introductory material and the final chunk likely contains conclusions. This subtle context improves the relevance weighting in individual chunk summaries.
Step 2: Map, Summarize Each Chunk in Parallel
The map step processes all chunks through the same summarization prompt independently. Because chunks are independent, all API calls can fire simultaneously, limited only by your rate limit with the LLM provider.
The map prompt template:
"You are summarizing section [N] of [total] from a larger document. Produce a summary of 300-500 words that preserves all key facts, conclusions, names, numbers, and relationships mentioned in this section. This summary will be combined with summaries of other sections to create a complete document summary. Do not add conclusions or context not present in this section."
Compression target per chunk: 10-20% of chunk length. A 5,000-token chunk should produce a 500-1,000 token summary. This preserves enough detail for the reduce step to work with while achieving meaningful compression. If you target more aggressive compression at the map stage (3-5%), you lose details that cannot be recovered in the reduce step. If you compress too little (30-50%), your combined chunk summaries may still exceed the context window, requiring hierarchical reduction.
Consistency across chunks: Use identical prompt structure and compression targets for all chunks. Inconsistent map prompts (different compression ratios for different chunks) produce uneven summaries that make the reduce step's job harder. The exception: you may want to allocate slightly more summary budget to the first chunk (which often contains the thesis or abstract) and the last chunk (which often contains conclusions).
Parallelization in practice: Most LLM APIs support 50-200 concurrent requests. A 20-chunk document parallelized across all chunks completes the map step in the time of a single API call (2-5 seconds) rather than 20 sequential calls (40-100 seconds). Use async/await patterns in Python (asyncio + aiohttp) or Promise.all in JavaScript to fire all chunk requests simultaneously. Handle individual chunk failures with retry logic, allowing up to 3 retries per chunk before flagging the document as failed.
Step 3: Reduce, Combine Chunk Summaries into Final Output
The reduce step takes all chunk summaries (arranged in document order) and produces one coherent final summary. This is where the actual synthesis happens: identifying themes that span multiple chunks, eliminating redundancy where different chunks covered the same topic, and organizing information into a logical structure that may differ from the document's original order.
The reduce prompt template:
"Below are summaries of consecutive sections of a single document, presented in order. Synthesize these into one coherent summary of [target length]. Eliminate redundancy where multiple sections discuss the same topic. Identify the document's main argument or purpose. Highlight key conclusions and supporting evidence. Maintain logical flow rather than simply concatenating section summaries."
Output length for the reduce step: This is where you specify your final target. If you want a 500-word executive summary, say so here. If you want a structured output with sections, specify the structure. The map step preserves information; the reduce step shapes it into the desired final form.
Handling redundancy: When a document discusses the same topic in multiple sections (common in academic papers that reference earlier findings, reports that repeat executive summaries at section level), multiple chunk summaries will contain overlapping information. The reduce prompt should explicitly instruct: "If multiple section summaries mention the same fact or finding, include it only once in the final output, using the most detailed version."
Maintaining source order vs logical reordering: For most documents, maintaining the source order in the final summary produces the most natural result because the original author already organized information logically. For documents with poor structure (transcripts, unedited drafts), instructing the reduce step to "group related information by topic" produces a more readable summary than following the chaotic original order.
Step 4: Handle Hierarchical Reduction for Very Long Documents
When the combined chunk summaries exceed the context window, a single reduce step cannot process them all. This happens with very long documents (books, legal case files, multi-hundred-page reports) that produce dozens of chunk summaries totaling more than the context limit.
Hierarchical reduction pattern: Group chunk summaries into batches of 5-8. Apply a first-level reduce to each batch, producing meta-summaries. If the meta-summaries combined still exceed the context window, group and reduce again. Each layer compresses by 70-80%, so two layers handle up to 50-60 chunk summaries (equivalent to documents of 200,000-500,000 tokens), and three layers handle virtually unlimited length.
Information loss across layers: Each reduction layer loses some detail. A fact that appeared in one chunk summary has roughly 80% chance of surviving one reduction layer and 64% chance of surviving two layers (0.8 x 0.8). For critical information that must appear in the final summary regardless of document length, use explicit preservation instructions: "The following facts must appear in your summary regardless of other content: [list critical facts identified during the map step]."
Adaptive hierarchy: Rather than applying fixed layers, compute the hierarchy dynamically. If combined chunk summaries total 15,000 tokens and your context window is 128,000, no hierarchy is needed. If they total 200,000 tokens, one reduction layer (reducing 25 groups of 8 summaries each into 25 meta-summaries) brings you within budget. Only add layers as needed to stay within context limits.
Comparing Map-Reduce to Alternative Patterns
Map-reduce vs refine: Refine processes chunks sequentially, maintaining a running summary that incorporates each new chunk. Refine produces better cross-chunk coherence because each step sees all accumulated context. Map-reduce produces faster results (parallelizable) and avoids the recency bias inherent in sequential processing (where later chunks disproportionately influence the final output because they are processed last). Use map-reduce for speed and balanced representation; use refine for narrative documents where chronological coherence is critical.
Map-reduce vs stuff: "Stuff" means passing the entire document in a single context window (no chunking). When the document fits, stuff always produces the highest quality summary because the model sees everything simultaneously. Map-reduce is for when the document does not fit. Never use map-reduce for documents that fit in your context window, the quality will be lower due to information loss at chunk boundaries.
Map-reduce vs map-rerank: Map-rerank generates summaries for each chunk, then selects the best chunk summary rather than combining all of them. This is useful when you want to find the "most important section" of a document rather than summarize the entire thing. It is not a substitute for full-document summarization but works for use cases like "find and summarize the methodology section of this paper."
Optimization Strategies
Chunk size tuning: Run the same document through map-reduce with different chunk sizes (2K, 4K, 6K, 8K tokens) and evaluate output quality. Smaller chunks with more reduction often beat larger chunks with less reduction for complex documents, because the reduce step has more granular building blocks to work with. Larger chunks work better for simple documents with clear section boundaries.
Map prompt specialization: For domain-specific documents, add domain context to the map prompt. "You are summarizing a section of a clinical trial report. Preserve all mentions of sample sizes, p-values, adverse events, and primary endpoints." This domain guidance ensures the map step retains domain-critical details that a generic prompt might compress away.
Reduce prompt iteration: The reduce prompt has the most impact on final quality. Iterate on it using a test set of 10-20 representative documents. Evaluate each iteration using LLM-as-judge scoring for completeness, coherence, and faithfulness. Most teams go through 5-10 reduce prompt iterations before reaching production quality.
Cost optimization: The map step processes the most tokens (all chunks, full input length). Use a cheaper model for map (Haiku, GPT-4o-mini) and reserve a more capable model for the reduce step (Sonnet, GPT-4o), which needs stronger synthesis abilities but processes far fewer tokens. This hybrid-model approach cuts costs by 60-70% compared to using a frontier model for both steps, with minimal quality loss because map is a simpler task than reduce.
Map-reduce summarization splits documents into 4,000-8,000 token chunks, summarizes each to 10-20% of its length in parallel, then combines all chunk summaries in a single reduce call. For very long documents, apply hierarchical reduction in layers. Use a cheaper model for the map step and a more capable model for the reduce step to optimize cost without sacrificing final quality.