长文档装不下怎么办

第一步：先算，不要猜

用分词工具算出材料的真实 token 数（见分词器）。 中文常按 1 字 ≈ 1 token 估，代码和 JSON 更费。

然后对比模型窗口，留出余量：

可用输入 = 窗口上限 − 系统提示 − 历史对话 − 预留输出（max_tokens）

余量留 20% 比较稳，因为模型对超长输入的处理不一定和你的估算一致。

第二步：按结构切

不要按字符数硬切，会切断句子、表格和代码块。按文档自身的结构切：

• Markdown：按标题层级切；
• 合同：按条款切；
• 代码：按文件与函数切；
• 聊天记录：按天或按会话切。

每一块保留来源标记（文件名、页码、条款号），后面引用要用。

第三步：选策略

策略	适合	代价
整篇塞	材料确实短、且每次都要全貌	贵；长上下文里中段容易被忽略
检索后注入	问题只涉及少数段落	要建索引；可能漏掉相关内容
分层摘要	要先看全局再细看局部	摘要有信息损失；多一次调用
分块逐段处理	抽取、分类这类可并行的任务	结果要合并；跨块关系会丢

顺序建议：先试检索，不行再分层摘要，最后才整篇塞。

第四步：分层摘要怎么做

1. 把文档按结构切成 N 块；
2. 每块单独摘要，保留关键数字、结论、来源标记；
3. 把摘要合成一份总览；
4. 回答问题时，先给总览，再按需取原文的某几块。

关键在保留来源标记：没有标记，摘要之后的引用无法核对。

第五步：验证没丢信息

准备 10 个只有原文某处才能回答的问题：

• 答案在文档开头、中间、结尾各放几个；
• 看你的方案能答对几个。

这一步能暴露两类问题：切分切丢了内容，或者长上下文下模型忽略了中段。

常见错误

• 按字数硬切：句子和表格被切断，模型读到半句。
• 只塞不检索：每次几万 token，成本和延迟都高。
• 摘要不留出处：出了问题无法回溯。
• 忽略中段：长上下文不等于均匀利用，关键信息放中间要格外验证。

自测

1. 你最长的材料有多少 token？现在的方案留了多少余量？
2. 你的切分是按结构还是按字符数？
3. 那 10 个定位问题，你的方案能答对几个？

下一步

• 窗口本身：上下文窗口
• 检索方案：搭一个最小可用的 RAG
• 省钱的缓存：用上下文缓存省钱