长文档

「塞得下」不等于「用得好」 模型标称 128K、甚至 1M 上下文，听上去一份 100 页文档直接整份喂进去就行。但实测打脸：上下文拉满时，模型对中间部分内容的注意力会明显下降——开头和结尾记得清，夹在中间的关键信息它常常视而不见，这就是所谓「lost in the middle」。同时，上下文越长，KV Cache 占用越大、推理越慢、成本越高。所以长文档处理的正确思路，从来不是「把窗口撑满」，而是「想办法只喂相关的那几段」。 两条成熟路线 路线一：切块 + 检索（回到 RAG）。 这正是前面几篇讲的 RAG 思路：把 100 页文档切成 500-800 token 的块，embedding 存库，用户提问时只召回最相关的 3-5 块喂给模型。上下文始终保持在几 K，又快又准。这是处理「要在文档里反复问答」的正解，别因为模型窗口大了就放弃它。 路线二：分层摘要。 当任务不是问答，而是「通读全文写总结」时，用分层摘要：先把文档切成段，每段让模型生成一段小结；再把这些小结拼成一份「中段文档」，让模型二次摘要；需要的话再叠一层。这样即便原文有几十 K，真正进最终模型上下文的只是层层浓缩后的精华，既省 token，又避免了中间内容被淹没。 方式 适合任务 上下文占用 准确度 整份塞进去 极短文档、整体浏览 巨大、慢 中间易丢 切块 + 检索 文档问答 小、快 高 分层摘要 长文通读总结 层层浓缩 较稳 三个实操要点 第一，别迷信标称窗口：官方标称 128K，实际稳定好用的可能只有一半，长上下文的有效利用率随长度衰减，按经验留足折扣。第二，关键信息放两头：如果必须把大段内容塞进去，把最重要的指令和结论放在提示词的开头和结尾，中间放次要材料——利用它对两头敏感的特性。第三，本地模型的长上下文更吃显存：前面算过，KV Cache 随上下文长度线性涨，本地跑 32K 以上要留足显存余量，否则不是「答不好」而是直接 OOM。 收束 长上下文是个好工具，但不是让你偷懒把文档一股脑塞进去的借口。真要在长文档上做问答，切块检索最稳；要通读总结，分层摘要最省。记住「lost in the middle」这个坑——窗口越长，越要克制喂进去的东西。会取舍上下文，才是用好大模型的真功夫。 去论坛讨论 关于「长上下文」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。