超长文档的 RAG 策略：从整本书到整份报告的分治方案

一本书进 RAG：问题的形状决定了方案

两类问题：针尖型与全局型

企业知识库里总有一类「大件」：三百页的产品白皮书、上千页的行业标准、整本的制度汇编、一份百页的尽调报告。很多团队的的处理方式是把它们丢进普通的切块管线，结果就是「书进去了，但问不出书里的问题」。失败的原因要先从问题的形状说起——用户对超长文档的提问天然分成两型：

针尖型问题：答案是一处具体的局部内容。「第 5 章里对验收标准的定量要求是什么」「报告中提到的第二大风险敞口是多少」。这类问题和普通 RAG 的目标问题没有本质区别，难点只在超长文档的切块质量与结构还原——文档越大，噪声密度越高，普通切块在几百页的语料里找那根针，召回的 Top-K 里塞满了「沾边但不对」的段落。

全局型问题：答案需要综合全文档的视野。「这本制度的总体监管思路是什么」「报告里三个方案的优劣对比」「全书的核心论证链是什么」。这类问题在普通文档上少见，在超长文档上却是主诉——用户读不动几百页，才让系统替他读。而全局型问题恰恰是检索式方案的死穴：没有任何一个 chunk 装得下「全书的核心论证链」，检索什么都是错的。

两型问题的解法完全不同，混淆两型是超长文档 RAG 项目的第一死因。所以超长文档管线的第一个模块不是切块器，而是问题分流器：判断来的是针尖还是全局。

长上下文不是万能解药

「现在模型上下文都百万 token 了，直接把整本书塞进去不就行了？」——百万上下文确实改变了可行性边界，但它有三个现实约束让它不能独扛超长文档。成本：一本 30 万 token 的书每次全量过模型，费用是常规检索方案的几十倍，还叠加首 token 时延的显著增加；容量：书、报告之外还有丛书、多卷宗汇编，真实场景的「超长」经常超过单次上下文上限；有效性：Lost in the Middle（Liu 等，2023）以来的多项研究一致表明，长上下文的利用能力随信息在窗口中的位置衰减，中段信息容易被忽略——「针尖」埋在三十万 token 的中段，模型未必比检索器找得准。上下文窗口的正确用法在超长文档场景里是辅助角色：作为「精读单元」（把检索定位到的章节整章精读）和「小规模文档的全读」（几十页的报告可以全塞），而不是海量文档的默认入口。

分治的第一步：尊重文档结构

章节、标题与版式线索

超长文档和普通文档的第一个区别是自带结构：章、节、小节、附录、索引、脚注。这套结构是作者留给读者的导航系统，也是 RAG 管线最该复用的信息。结构化切块的第一原则：物理分页只是坐标，逻辑章节才是单元——切分边界优先对齐标题层级，而不是页边界或固定 token 数。

获取结构有两条路：版式完好的文档（Word、带书签的 PDF、HTML）直接读目录与标题样式；版式混乱的扫描件走解析器的标题层级识别（字号、加粗、编号模式的启发式 + LLM 复核）。超长文档里解析质量的重要性被放大：一个「第 4 章」标题识别失败，意味着后面几十页的切块全部失去章节语境。所以超长文档管线的解析验收标准要单独设——章节树还原完整率是第一指标，比单元格还原之类的常规指标更靠前。

结构之外还有三类常被丢弃的「导航资产」值得抢救：目录页（它就是天然的章节树金标，用它校验自动识别的章节树）、页眉页脚（携带章节名，跨页 chunk 的语境线索）、交叉引用（「见第 7.2 节」，把引用目标解析出来存为关联边，检索命中一处时可以把被引用的关键定义一起带上）。

逻辑切块 vs 物理切块

章节对齐的切块会遇到「单节太长」的问题——一章五十页怎么切。答案是两级切块：逻辑单元（章节，作为结构与摘要的粒度）与检索单元（节内按段落语义切分、目标几百 token，作为索引的粒度），两者用树关系连接：检索单元记挂父级章节 id。这套树结构后面每一步都用到——检索命中叶节点可以向上回溯带出兄弟段落，摘要自顶向下逐层生成，全局问题的 Reduce 阶段按章节分桶。树是超长文档 RAG 的中枢数据结构，切块阶段不建树，后面全是补丁。

多级索引：页、节、章的分层检索

自底向上的摘要索引

树建好之后，为每个层级生成摘要索引：每个检索单元一句内容摘要、每个小节一段百字摘要、每章一段千字摘要。摘要用 LLM 离线生成（成本可预算：一份两百页报告的全量摘要索引大约几十万 token），生成提示词的关键要求是摘要必须自包含——每层摘要都要带上章节编号与主题限定（「第 5 章：数据安全技术要求」），不能是「本节介绍了相关要求」这种挂在语境上才成立的空话。

多级索引的检索方式是瀑布式：查询先在高层摘要索引上检索（全书的章级摘要只有二三十条，检索又快又准），定位到相关章节后，再在章节内部的检索单元索引上做第二跳精检索。瀑布式比「全库平铺检索」的优势在信噪比：全库平铺时，一份两百页报告的检索单元有上千条，与查询主题相近的段落可能分散在七八个章节里，Top-K 装不下；瀑布式先压缩到章节粒度再展开，同样的 K 值，进上下文的段落集中在真正相关的章节里。

flowchart TD
    Q["用户问题"] --> R{"问题分流"}
    R -- "针尖型" --> W["瀑布检索：章摘要定位 → 节内精检"]
    W --> E1["整章/多段精读上下文"]
    R -- "全局型" --> MR["Map-Reduce：逐章提炼要点"]
    MR --> RD["Reduce：要点汇总成答案"]
    R -- "小文档" --> W2["长上下文全读"]
    E1 --> ANS["答案 + 出处"]
    RD --> ANS

这条「摘要索引 + 瀑布检索」的路线，与库里已有文章讨论过的 RAPTOR 层级索引思想同源——都是自底向上构建多层表示。工程取向上的差异在于：RAPTOR 的聚类层由嵌入聚类数据驱动，适合结构混乱的语料；而结构完好的超长文档，作者写好的章节树比聚类更可靠，摘要直接挂在章节树上，既省一次聚类、又让每层摘要可解释（用户能看到「这是第 5 章的摘要」）。结构差才退回聚类法。

检索到章节、阅读到页

瀑布检索的最后一步是「精读上下文」的构造：命中检索单元后，不要只取孤立的几百 token——向上取整，把命中的段落连同它所在小节完整取进上下文（小节通常一到两页，装得下）。超长文档的内容连续性强：一个定量要求的前半句在小节开头、后半句在中间，孤立段落读不懂，整节精读才完整。上下文预算的分配经验：整节精读占大头，命中段落的其他章节兄弟段落做辅助，章级摘要做导航头——三层信息让模型既见树木又见森林。

全局型问题的 Map-Reduce 与 Refine

递归摘要链

全局型问题走 Map-Reduce：Map 阶段把每章（或每节）的内容分别交给模型，带着全局问题提炼「本章与该问题相关的要点」；Reduce 阶段把所有章的要点汇总，生成最终答案。它的正确性建立在每章独立提炼上——每章一次调用，上下文只装一章的内容，模型不需要在几十万字里找重点，找重点的活儿被分解成了二十次「在一章里找重点」。

Refine 变体适合「综合论证」类问题：先处理第一章生成初步回答，逐章迭代，每次调用带着「已有回答 + 新章节」，让回答随章节累积逐步精炼。Refine 保留了跨章的论证连续性（后面的章节会修正前面的判断），代价是串行依赖（不能并行，时延高）。实践配比：列举型、对比型全局问题用 Map-Reduce（并行、快），论证链型问题用 Refine（准、慢）。

超大规模文档（多卷汇编、丛书）在 Map-Reduce 之上再加一层递归：章节要点先按篇汇总成篇级要点，再汇总成全书答案——递归摘要链。层次每深一层，信息压缩就多一次，细节损失也多一分，所以Reduce 提示词里要带上「保留关键数字与专有名词」的硬约束，防止递归过程把定量信息磨没。

成本账

全局型问题的单次查询成本要明码标价：一份两百页报告的 Map-Reduce 约等于「全文档 token 量过一遍 LLM」（每章都要提炼），加上 Reduce。这个成本是针尖型问题的十倍以上，也是长上下文全读的一半左右（Map 阶段每章独立调用反而比单次超长调用便宜）。两条省钱路径：预计算——高频全局问题（报告摘要、总体结论）的答案离线预生成并缓存，文档不变则答案不过期；裁剪 Map 范围——带主题限定的全局问题（「财务风险有哪些」）先用瀑布检索把无关章节筛掉，只对相关章节做 Map，成本能降一半以上。全局不是全读，能裁则裁。

工程实践：书与报告的差异

叙事文档与技术文档的不同病

两类超长文档的失败模式不同，管线侧重也要不同。技术报告、制度、标准：结构规整、术语密集、定量要求多，病根在解析（表格、附件、附录的处理）与交叉引用（条款互引）；对这类文档，结构树的还原质量决定一切，摘要索引反而是锦上添花。叙事性文档（传记、案例集、会议纪要汇编）：章节结构弱、时间线是隐组织轴、人物与事件贯穿全书——它的多级索引不能只挂章节树，要额外建实体与时间线索引（哪些章节涉及哪个主体、哪个时间段），全局型问题的 Map 也要按「主题相关章节」裁剪。一句话：结构强的文档信结构，结构弱的文档补索引。

版本与关联件

超长文档的工程尾款还有两笔。版本治理：报告一年一版、标准两年一修，多版本共存时检索必须按版本隔离（元数据过滤 doc_version），全局型答案缓存要跟着版本失效；用户没有显式指定版本时，默认最新版并在答案里注明「依据 2025 版」。关联件：报告的附件、勘误表、评审意见是独立的文档单元但语义上从属主文档，索引时挂到主文档的树节点下，检索主文档相关问题时要考虑附件——「报告说方案可行」与「附件勘误说有一处数据错误」分离检索是审计场景的高危错误。

小结

超长文档不是「更长的文档」，而是结构性的另一种问题：用户的问题分针尖型与全局型两型，解法完全不同，管线入口先分流。针尖型走「结构树 + 瀑布检索」：切块对齐章节逻辑、建树、生成自包含的多级摘要索引，章摘要定位、节内精检、整节精读；全局型走「Map-Reduce / Refine」：逐章独立提炼、汇总成答案，高频问题离线预计算，带主题限定时先裁剪 Map 范围。

长上下文模型在这个场景的定位是精读单元与小文档全读的助手，不是海量文档的默认入口——成本、容量与中段遗忘三重约束决定了检索为主、精读为辅的分工。工程尾款三件：结构树还原完整率作为第一验收指标、版本治理与缓存联动、附件与主文档的从属索引。超长文档 RAG 的本质，是把「替用户读完整本书」分解成「书自己告诉系统该往哪看」——作者留下的章节结构，就是最好的路标。