长文档 Map-Reduce 是什么
当单篇文档超出模型上下文窗口时，用 Map-Reduce 式两阶段处理：Map 阶段把文档切成片段，逐片生成要点或局部答案；Reduce 阶段把所有局部结果合并成最终答案。它适合整篇摘要、答案分散在多章、需要全局视角的问题。代价是模型调用次数随片段数线性增长，延迟与成本同步上升，因此需要并发控制与限流设计，并考虑缓存来避免重复计费。
基本信息
| 阶段划分 | Map 逐片段处理，Reduce 合并汇总 |
|---|---|
| 常见变体 | Refine 逐步把新片段并入已有答案 |
| 适用任务 | 整篇摘要、跨章节问答、长报告整理 |
| 主要代价 | 调用次数、延迟与成本随片段数上升 |
| 必备设计 | Map 并发与限流、失败重试、结果缓存 |
| 引用要求 | Reduce 阶段保留片段编号 |
典型使用场景
- 生成文档摘要：先分段提炼要点，再合并成结构化摘要
- 整篇问答：答案分散在多个章节，需要全部片段参与
- 长报告处理：按章节 Map，再按主题 Reduce 汇总
- 与检索式 RAG 互补：先定位相关章节，再在章节内做局部 Map-Reduce
- 批量离线任务：夜间跑全量文档摘要，对延迟不敏感
两阶段骨架
两阶段骨架
partials = [llm_summarize(chunk, query) for chunk in chunks_if_too_long] # Map
final = llm_answer(query, "\n\n".join(partials)) # Reduce
# 变体 refine：逐步把新片段并入已有答案，上下文更连续但只能串行
# Reduce 时保留片段编号与来源，引用才能回指原文段落
# Map 阶段并发执行并设并发上限，避免触发服务端限流长文档策略对照
| 策略 | 做法 | 代价 |
|---|---|---|
| Map-Reduce | 逐片段生成再统一汇总 | 片段多时调用次数最多，成本最高 |
| Refine | 逐步把新片段并入已有答案 | 串行执行延迟更高，但上下文连续 |
| 整段直塞 | 所有片段一次放进提示词 | 实现最简单，受上下文长度硬限制 |
| 检索式 | 先检索相关片段再生成 | 省上下文，但可能漏掉未命中的关键章节 |
Reduce 阶段必须保留片段编号：合并后的答案若没有编号映射，引用与溯源就断了，用户无法核对原文。
片段很多时串行调用会显著拉长响应，Map 阶段应并发执行并设置并发上限，Reduce 阶段再按顺序汇总。