长文档与长上下文怎么处理

长文档任务失败，往往不是模型不聪明，而是关键信息没有出现在它能看到的位置。窗口是容量上限，检索是选择机制，两者解决的不是同一个问题。

这个专题包含什么

专题分两段。第一段先把限制讲清楚：上下文窗口怎么计算、token 与字数为什么不能直接换算、上下文工程为什么要管理「放什么、放多少、放在哪」。第二段是动手：长文档怎么切分，切分后怎么做检索增强，召回结果怎么重排，关键词与向量为什么要混合使用。选择方案前先问三个问题：文档有多长、问题有多具体、错误代价有多高。专题不讨论具体向量数据库选型，也不给出固定分块大小；文档结构、语言和问题类型不同，合适的分块方式也不同，官方没有统一答案。

学习顺序

先读上下文窗口，确认输入、输出与历史共享同一个上限。再读 token，理解长度是按 token 计，不是按字数计；中文尤其不能拍脑袋换算。第三步读上下文工程，建立「按任务装配上下文」的思路。然后进入实操课：用一份真实长文档走完切分、检索、拼接、提问的流程。之后补切分与 RAG，弄清召回质量差时问题出在切分还是检索。最后读重排与混合检索：前者对候选片段做二次排序，后者把关键词与向量召回结合起来，适合专有名词多、语义又重要的材料。如果任务只是一次性总结，整篇放进窗口可能比搭一套检索更划算；检索适合反复问同一批材料。

全部相关词条

先搞清限制组：上下文窗口、token、上下文工程。动手做组：长文档处理课、切分、检索增强、重排、混合检索。两组的关系是「先量尺寸，再裁衣服」：不知道窗口和 token 的真实约束，切分策略就只能靠试；切分不是越细越好，片段太碎会丢上下文，太大又会稀释检索命中。另外要留出输出空间：输入塞得越满，留给回答的余量越小。反过来，只懂限制不动手，遇到长文档仍然只能整篇硬塞。先用一小批真实问题验证召回，再决定是否引入重排。文档更新后，索引也要跟着重建，否则检索到的是旧内容。