一句话定义：Map-Reduce 摘要（Map-Reduce Summarization）是一种分治式的长文摘要策略：先把长文档切成若干段，每段各自生成摘要（Map 阶段），再把这些段摘要汇总、压缩成一份总摘要（Reduce 阶段）。
为什么需要它：模型一次能读进去的上下文（context window）是有限的。几十页的尽调报告、一本产品手册、几小时的访谈逐字稿，直接塞进去要么被截断，要么成本高得离谱。截断最省事，但后半本等于没读。Map-Reduce 的思路是不指望一口吃下，改成“分开嚼、再合并”。
打个比方：三天行业大会，几十个分论坛同时开。一个人记不全，于是每个分论坛派一位同事各写一页纪要——这一步是 Map，各段彼此独立、可以并行，所以快；散会后主持人拿这几十页再浓缩成一页总纪要——这一步是 Reduce。如果总纪要还是太长，就再往上叠一层，两页并一页，这叫分层 Reduce，也叫树状摘要。
代价：跨段信息会丢，这是最该记住的一点。
- 第一段写“项目预算 100 万”，第五段写“追加 30 万”，两段各自的摘要都看不出总预算是 130 万。
- 分段之后，“该公司”“上述方案”这类指代失去上下文，摘要容易变得含糊。
- Map 阶段的偏差会被 Reduce 继承并放大，而汇总稿里已经看不到原文，没法回查。
和相近方案的区别：AI 词典：检索增强生成">检索增强生成（Retrieval-Augmented Generation, RAG）是先捞出相关片段再回答，适合“问一个具体问题”；Map-Reduce 是通读全篇产出全局摘要，适合“告诉我这份材料整体讲了什么”。
| 方案 | 覆盖全文 | 保留细节 | 跨段关联 | 典型适用 |
|---|---|---|---|---|
| 直接截断 | 否 | 仅前半 | 无 | 只需开头信息 |
| Map-Reduce 摘要 | 是 | 弱 | 易丢失 | 全局摘要、长报告 |
| RAG 检索 | 部分 | 强 | 按查询组织 | 针对性问答 |
| 长上下文直读 | 是 | 强 | 强 | 窗口够、成本可接受 |
对从业者：Map-Reduce 是长文档流水线的默认基线。实现时注意几点：各段 Map 的提示词保持一致，输出长度留余量；Reduce 阶段很可能再次超长，提前设计分层或递归；把用户真正关心的问题一并下发给每个 Map，让它顺带标出相关段落，能明显缓解跨段丢失；保留每段摘要与原文位置的映射，方便溯源。评测时要专门构造跨段问题，只用单段问题测会高估效果。
对普通人：很多“上传 PDF 一键总结”的工具，背后就是这个套路。它擅长回答“这份材料整体讲了什么”，不擅长回答“第 47 页那个数字是多少”。摘要里没你要的细节，别急着怀疑工具坏了，回去翻原文更靠谱。窗口够大的模型直接通读通常质量更好，具体用哪种，以你所用产品的官方说明为准。