超长文档怎么喂给模型：长上下文、分段与摘要的取舍
发布于 2026-09-30
超长文档怎么喂给模型：长上下文、分段与摘要的取舍
上下文窗口从几万涨到上百万 token，一个直觉是"那就全塞进去"。实际做下来，长文档处理有三种策略，各有明显边界。
策略一：直接使用长上下文
适合：单次任务、文档之间有强关联（如跨章节对照）、需要全局视角（如总结整本书的结构）。
代价：
成本：输入 token 随文档长度线性上涨，一份长报告的全文输入可能比"检索+摘要"贵一个数量级；
延迟：输入越长，首字节与总时长越长；
注意力稀释：内容越多，模型对中段细节的把握越弱——想让它精确引用第 37 页的一句话，效果往往不如把那一页单独给它。
结论：长上下文适合概览型任务，不适合精确定位型任务。
策略二：分段处理（Map-Reduce 式）
把文档按章节切开，每段单独产出中间结果，再汇总：
1. Map：每段独立摘要/抽取，输出结构化中间结果（要点、结论、数据）；
2. Reduce：把中间结果合成最终答案；
3. 好处：成本可控、可并行、长文档也能处理；代价：跨章节的关联容易丢。
适合：合同批量审阅、报告要点汇编、大批量日志归纳。
策略三：先检索再回答（RAG 思路）
如果问题是针对性的（"这份手册里差旅标准是多少"），最优解不是把文档给模型，而是先检索出相关片段再回答：
索引阶段：切分 + 向量化 + 关键词索引；
问答阶段：混合检索取前几段 → 拼上下文 → 生成并标注来源。
成本最低、精度最高，是问答型场景的首选。
怎么组合
任务 推荐
--- ---
全文概览、结构梳理 长上下文（或 Map-Reduce）
针对性问答 检索 + 片段上下文
跨章节对比 长上下文 + 结构化抽取
批量文档处理 Map-Reduce 并行
三个实用技巧
先压缩再提问：把无关段落（目录、版权页、附录）剔掉，能省下可观的输入；
把关键指令放在两端：长上下文里，开头与结尾的指令更容易被遵循；
要求引用：让模型标注结论来自哪一段，既方便核对，也能暴露"它其实没读到"的情况。
判断标准很简单：任务是"要全局理解"还是"要精确找一条"。前者用长上下文，后者用检索——选错了，成本与效果会同时变差。