几百页的长文档怎么做 RAG？直接塞长上下文行不行

先这样答

先答能不能塞。几百页文本大约几十万 token，对放得下的长上下文模型，偶尔查一次是可以直接塞的：一次性分析一份合同或报告，直接塞比搭检索管道快得多。但要清楚两个代价。一是中间内容利用率下降：模型对超长上下文中段信息的召回弱于开头和结尾，关键内容恰好在中段就可能答错。二是成本随每次查询线性增长：同一份文档每次提问都要重付一遍全量 token 的钱，高频场景下这笔账很快超过建索引的成本。

高频的生产场景要回到索引，但针对长文档调整做法。切片顺着文档结构走：按章节切，把标题层级存成元数据，让每个块自带位置信息。可以加一层摘要索引：每章先做摘要，检索先命中章节摘要，再取出对应章节的原文块，先粗后细两层。对手册、规范这类结构化文档，保留目录树，支持把检索范围限定在某些章节内。

总结：长上下文和 RAG 不是二选一。长上下文解决「能不能一次读完」，RAG 解决「每次只读需要的部分」。生产系统常见组合是检索先缩小范围，长上下文保证缩完的范围一次装得下。

面试官会怎么追问

• 「中间内容利用率下降怎么验证？」 自测：把关键事实分别放在长文档的开头、中段、结尾，对比回答正确率。不同模型对中段信息的衰减程度不同，选型前自己跑一遍比看宣传可靠。
• 「长文档切块切多大？」 顺着结构切比按固定字数硬切好：按章节切大块保证语义完整，命中后可以扩展取相邻块补语境。块太大占上下文，太小丢上下文，标题结构就是现成的切分依据。
• 「文档更新频繁怎么办？」 按章节增量更新：只重新处理变化的部分，配版本号标记。全量重建只在目录结构大改时才值得做。

回答的坑

• 断言「长上下文模型出来了，RAG 要被淘汰」。两者面对的是成本和精度结构问题：长上下文每次付全量成本，也解决不了跨文档检索和权限过滤。
• 只答「切小一点」。长文档的关键是利用自身结构做分层索引，固定字数硬切恰恰把章节这些现成信息全丢了。