先把结论撂这儿:一份几十万字的文档想让大模型总结,别傻乎乎一次性怼进去。切成段,每段单独总结(map),再把这些小结果合并成一份(reduce)。这套法子比硬塞稳得多,我踩了大半个月坑才认这个理。

起因是上个季度,法务那边甩给我一个 300 多页的合规手册 PDF,让我整一份"给业务同学看的人话版摘要"。我当时心想这不简单,丢进模型让它读一遍不就完了。结果第一刀就崩了——上下文窗口塞不下,后半截直接被截走,模型还煞有介事地总结了它压根没读到的章节,编得有鼻子有眼。

为什么不能一次塞:窗口和注意力都在偷偷打折

大模型有个上下文窗口的硬上限,token 超了就报错或者悄悄截断,这是第一道墙。但更阴险的是第二道:就算塞得下,模型对超长文本的注意力也是不均匀的。业界有个被反复验证的现象叫"lost in the middle"——把关键信息藏在一长段文本的中间位置,模型的召回率会明显往下掉,头和尾记得牢,中间糊成一片。

所以我那份合规手册,哪怕窗口够大能整个塞进去,第 7 章那条"数据出境需双重审批"埋在正中间,八成也会被它读漏。这不是模型笨,是长序列注意力天然摊薄了。一次塞进去,等于赌它别在中间走神,赌赢赌输全看运气。

map-reduce怎么把这事掰稳了

思路是把"一次读完一本书"拆成"一页一页读,再把笔记汇总"。

map 阶段:文档切成 N 段,每段独立喂给模型,各出一份小摘要。每段都短,稳稳落在窗口里,注意力也集中,不存在中间走神的问题——因为每段都很短,没有"中间"。

reduce 阶段:把 N 份小摘要拼一块儿,再让模型总结一遍出终稿。这些小摘要加起来通常远小于原文,塞得下,模型也能通读。

对比一下两条路:

最后一行是真缺点,不藏着:map 阶段我那 300 页切了 40 多段,串行跑下来等了快两分钟,改成并发才压到 20 秒出头。还有个坑,切段别在句子中间硬切,我一开始按固定字符数切,把一句"禁止…除非满足以下条件"从"除非"那儿劈成两半,两段各自总结全跑偏了。后来改成按章节、段落这种语义边界切,留一点重叠,才正常。

一个偷懒做法:让搭好的智能体替你跑这套流程

手搓 map-reduce 要自己写切分、调 API、管并发、拼 reduce,一坨胶水代码。后来我换了个法子——找了个零代码就能拖拽配智能体的平台,把文档解析、分段、逐段总结、合并几个节点在画布上连成一条流水线,挂上现成大模型和一个私有知识库,没写一行后端代码,一个能吞超长文档吐摘要的小助手就跑起来了。

说实话第一版输出干得像账单,全是要点罗列没人话。我对着提示词调了三四轮,在 reduce 那步加了句"用业务同学能听懂的话讲,别堆术语",才像样。它也就老老实实干这点杂活,复杂判断还得我自己来——但合规手册那种又臭又长的活,丢给它确实省心,现在每次法务更新文档,我点一下就出摘要。

你们处理超长文档是手搓 map-reduce,还是有别的招?评论区聊聊,我那 40 段的切分阈值至今没调到最优,蹲个更好的思路。

(顺嘴一提,模型和 API 我走的讯飞星辰 MaaS,现成调用,没自己折腾部署算力。)