长文本场景下多文档分析的Map-Reduce实践

上周一个做行业研究的朋友问我：你们那个知识库系统，能不能一次导入三百份行业报告，几分钟内给出一份“近三年政策变化趋势汇总”？我说能，但解法可能跟大多数人想的不一样——不是把文档一股脑塞给大模型让它“读完再回答”，而是把整个分析过程拆散成可并行的小任务，最后再合并成结论，我们内部管这套思路叫“LLM长文本场景下的多文档分布式分析”。这篇文章就把这套方案从设计动机到落地细节完整拆一遍，适合正在做知识库问答、文档自动分析、RAG类应用的工程师，也适合被“长文本上下文不够用”卡住的产品和技术负责人参考。

1. 为什么多份文档不能一股脑塞给大模型

1.1 上下文窗口不是唯一的坑

很多朋友遇到多文档分析的第一反应是：“那就拼Prompt啊，把文档全部塞进去”。这个思路在文档少的时候确实能跑通，但一旦进入真实的长文本场景——比如几十份到几百份文档——问题就会暴露出来。

第一层问题是上下文窗口装不下。以我当时用的一个64K上下文的商用模型为例，把300份报告直接拼接，总量超过千万字，折合token数远远超出窗口，这一步直接就堵死了。

第二层问题是，就算你硬塞到窗口之内，模型的注意力也会退化。业内把这种现象叫做“lost in the middle”——大模型对输入开头和结尾的内容记忆比较牢，但对中间部分的关注度明显下降。放到多文档分析场景里，意味着某一份文档的关键结论可能恰好落在模型的“盲区”，它没读到，或者读了也没往报告里写。

第三层问题是跨文档关系。多份独立文档拼接在一起之后，模型很难自动判断“文档A和文档B表达的是同一个趋势”“文档C的结论和文档D的数据冲突”。它更倾向把每段内容当成孤立信息处理，而你想要的恰恰是跨文档的共识、分歧和演进脉络。

1.2 成本、延迟与失败率一起涨

就算你硬着头皮把几十份文档强行塞进长上下文的API，你还会撞上三个工程问题。

成本。大模型是按token计费的，全量喂入意味着你做一次提问就要支付一份完整的输入费用，输出越长费用越高。一旦输出被截断、失败或重试，这笔费用还要翻倍甚至翻几倍。

延迟。长输入长输出单次请求时间很长，很容易触发平台侧的超时限制。我在项目里遇到最多的错误之一就是“llm request timed out. the model did not produce a response before the mod...”，这类报错在长文本场景下尤其常见，因为模型需要处理的内容越多，响应时间越长，超过网关等待时间就被切断了。

失败率。单次请求越复杂，失败率越高。整体来看，长文本单次分析是一个“高成本+高延迟+高失败风险”的组合，完全不适合作为生产环境的稳定方案。

所以结论很直接：多文档分析要解决的不是“怎么把更多字塞进去”，而是“怎么把一个大问题拆成很多个可以并行处理的小问题”。

2. 把分析过程拆成Map-Shuffle-Reduce三步

2.1 Map阶段：切片与局部结构化提取

这套架构的思路并不新鲜，直接借用了分布式计算里经典的MapReduce思想。整个流程分成三个阶段：Map、Shuffle、Reduce。

先看Map阶段。它的核心动作是“切片+局部提取”。

把文档库按一定粒度切分成多个分析单元，每个单元只喂给LLM一次，要求模型对这一段内容做结构化提取。注意，Map阶段不要求模型理解“全部文档”，只要求它读好自己负责的那一小块内容。这就像让一个调研团队分头行动，每个人只精读自己分配到的材料，在旁边写批注、摘录要点，而不是让一个人把几百份材料全部读完再写报告。

Map输出的格式最好固定为结构化JSON，比如：

• 文档编号
• 关键词列表
• 实体列表（公司、机构、人物）
• 结论性描述
• 指标数值
• 置信度
• 来源标记

有了统一的输出结构，后续Shuffle和Reduce才对得齐字段。这一步是整个方案的地基，输出格式设计得好，后面会省非常多力气。

2.2 Shuffle阶段：按主题把局部结果归堆

Map阶段产出的是一堆散乱的局部结果，Shuffle阶段负责把它们按业务维度归类。

这个阶段不调用L