个人主页 for_ever_love__ 欢迎各位大佬莅临其他栏目: 大模型开发从0到1 其他栏目: iOS项目总结大全 其他栏目: 我想学python了 其他栏目: iOS UI 文章目录长文档分层检索实战父子索引、摘要索引与章节树一、长文档为什么是 RAG 的特大困难二、范式一父子索引Parent-Child三、范式二摘要索引树RAPTOR 式四、范式三章节结构索引顺着文档天然层级五、三种范式的组合拳六、评估长文档 RAG 的测试集怎么建七、常见坑八、落地检查清单九、小结长文档分层检索实战父子索引、摘要索引与章节树三百页的产品手册、几百页的标书、动辄几十万字的小说——当单篇文档的长度超过 embedding 模型的处理窗口、超过 LLM 的上下文上限一把切成 512 字块的策略就开始崩检索命中的是碎片答案要的大局在碎片里拼不出来。这篇文章讲三种长文档处理范式父子索引大块拆小块、摘要索引自底向上建摘要树、章节结构索引顺着文档天然层级走以及它们各自的适用场景和组合用法。一、长文档为什么是 RAG 的特大困难先量化困难。一篇 20 万字的技术手册切分即碎按 512 字切 ≈ 400 个 chunk一个故障排查主题可能散在 15 个 chunk 里语义查询召回其中 1~2 个答案缺胳膊少腿上下文放不下20 万字 ≈ 20 万 token主流模型上下文 128K 顶天全文塞进去不现实而且塞了也贵结构信息全丢原文档的第 5 章 → 5.3 节 → 图 5-7层级硬切之后 metadata 只剩页码。三种范式就是对着这三个痛点来的父子索引解决检索粒度摘要索引解决宏观视角章节树解决结构丢失。二、范式一父子索引Parent-Child核心思想用小块检索用大块生成。小 chunkchild256 字负责被向量检索——粒度细、语义聚焦、命中准命中后把它所属的大块parent2000 字取出来喂给 LLM——上下文完整、不用拼碎片。文档 └─ 切大块parent2000 字按语义边界切 └─ 每块再切小块child256 字 ├─ child-1 → embedding → 入库带 parent_id ├─ child-2 → embedding → 入库带 parent_id └─ ... 检索索引优化怎么做 → 命中 child-3parentP7 → 返回 P7 全文给 LLM代码骨架parents,children[],[]forp_idx,parent_textinenumerate(semantic_split(doc,size2000)):pidf{doc_id}_p{p_idx}parents.append({id:pid,text:parent_text})forc_idx,child_textinenumerate(split(parent_text,size256)):children.append({id:f{pid}_c{c_idx},text:child_text,parent_id:pid,})# 只给 child 建向量索引parent 走 KV 存储vs.add([embed(c[text])forcinchildren],metadataschildren)kv.put_bulk(parents)# 检索hitvs.search(embed(query),top_k5)parent_idsunique([h[parent_id]forhinhit])context[kv.get(pid)[text]forpidinparent_ids]关键细节去重5 个 child 命中可能同属一个 parent取 parent 前先去重上下文别重复塞parent 大小平衡太大超过上下文、太小不完整。1500~2500 字是甜点区child 之间重叠按语义边界切的话重叠会制造重复命中按固定 256 字切建议 10%~20% 重叠防断句parent 也建索引粗粒度还可选给 parent 建摘要级向量索引让章节主题类查询先命中 parent 再定位 child——这是父子 摘要的混合后面讲。三、范式二摘要索引树RAPTOR 式核心思想自底向上递归摘要建一棵文档语义树。RAPTORRecursive Abstractive Processing for Tree-Organized Retrieval的流程Level 0: 原始 chunks叶子 按相似度聚类每组过 LLM 生成摘要 → Level 1 节点 Level 1: 摘要节点 再聚类再摘要 → Level 2 节点 ... 根节点 整篇文档的一句话/一段话摘要 检索所有层级的节点全部向量化入库 查询 → 命中哪层算哪层 索引优化怎么做 → 命中 Level 0 具体 chunk 这本手册讲了什么 → 命中 Level 2/根摘要摘要树的检索哲学查询不再只面对碎片而是面对一棵从细节到全局的语义树——细节问题命中叶子宏观问题命中根一个索引同时服务两种查询。defbuild_summary_tree(chunks,llm,sim_threshold0.7,max_group10):level[{id:fL0_{i},text:c,level:0}fori,cinenumerate(chunks)]treelist(level)whilelen(level)1:groupscluster_by_similarity(level,sim_threshold,max_group)next_level[]forg_idx,groupinenumerate(groups):iflen(group)1:# 聚不起来的单节点上升到上层next_level.append(group[0]);continuesummaryllm(f用 200 字概括以下文本的共同主题和关键信息\n\n---\n.join(n[text]forningroup))node{id:fL{level[0][level]1}_{g_idx},text:summary,level:level[0][level]1,children:[n[id]forningroup]}next_level.append(node)tree.append(node)levelnext_levelreturntree成本账必须算每个非叶子节点一次 LLM 摘要调用。400 个 chunk 的文档树高 2~3 层大约 200~400 次摘要——建库成本比父子索引高一个量级纯 embedding vs 纯 LLM。只对高频查询的长文档建别全库开。检索时的层级加权宏观问题的答案在高层细节问题在低层。默认全层级混排可按查询类型先探测短查询偏细节、长查询偏宏观再选层——或者干脆全层级检索后靠 rerank 自然排序多数场景够用。四、范式三章节结构索引顺着文档天然层级核心思想文档本身就有层级别重新发明切分。技术手册的第 3 章 → 3.2 节 → 3.2.1 小节是作者写好的大纲比任何算法聚类都准。做法# 1. 解析阶段保留标题层级Docling/Unstructured 天然支持treeparse_with_headings(manual.pdf)# → [(第3章 索引优化, 1), (3.2 B树结构, 2),# (3.2.1 节点分裂, 3), (正文..., 3), ...]# 2. 按叶子标题下的内容为单元切块块带完整标题路径chunks[]forsectioninextract_leaf_sections(tree):chunks.append({text:section.content,title_path: .join(section.heading_ancestors),# 第3章 3.2 B树结构 3.2.1 节点分裂heading:section.heading,})标题路径进 chunk 文本不仅是 metadataembed(第3章 索引优化 3.2 B树结构 3.2.1 节点分裂正文查询节点分裂或3.2.1 讲了什么都能命中而且命中后上下文自带完整结构。目录页特判长篇文档开头常有目录3 章 47 节一页全列单独成块入库查询这本手册有哪些章节直接命中目录页——这是最容易被漏掉的高价值 chunk。五、三种范式的组合拳生产上不是三选一是按文档类型组合文档类型推荐组合结构化手册/标书标题清晰章节树为主 父子索引叶子节内再切长篇纯文本小说、连续叙事父子索引语义切分 parent 上下文超长研究报告查询偏宏观摘要索引树 父子索引宏观走摘要细节走父子法规条文按条组织章节树按条切条号就是 ID一个组合实现章节树切大块 → 大块内切小块父子 → 对大块生成一级摘要只一层不建全树——三层结构覆盖从这条怎么规定的到整体框架是什么的全部查询。成本的增量只有一级摘要可控。六、评估长文档 RAG 的测试集怎么建长文档场景的评估必须专门建测试集通用问题集测不出问题# 三类探针probes{# 细节型答案在某一小节里detail:[节点分裂的具体条件是什么,3.2.1 提到的触发阈值是多少],# 跨节型答案要综合两节cross:[索引分裂和页合并的关系,第 3 章和第 5 章的配置参数怎么联动],# 宏观型答案在摘要层global:[这本手册的核心主题是什么,手册推荐的整体优化思路],}三类问题的召回率分开统计——只测细节型是自欺欺人那正是传统切分擅长的跨节和宏观的命中才是长文档方案的增量价值。七、常见坑父子索引的 child 切得太碎128 字以下embedding 语义不足命中率反而降。256 起步摘要失真累积RAPTOR 高层摘要的错误会向上传染L1 摘要错了L2 基于错误的 L1 再摘要摘要节点要标注由 LLM 生成——答案引用时优先引原文层章节树的标题层级识别失败扫描件、非规范排版文档没有干净标题Docling 的版面识别也不是 100% 准——复杂文档先跑标题识别准确率抽样不够就退化为父子索引parent 上下文超限LLM 上下文 32K 时塞 10 个 2000 字 parent 就危险了——按模型上下文动态调 top_k × parent_size别硬编码忘了给图表留位置长文档里的图哪怕已有 VLM 描述在章节树里应该挂在所属节下而不是漂浮在文档级。八、落地检查清单文档分类结构化手册 / 长篇连续文本 / 研究报告各走对应组合父子索引child 256±、parent 2000±、命中 parent 去重章节树标题路径进文本、目录页单独入库、图表挂到所属节摘要树只在高频查询的长文档上建成本评估先于建设三类探针评估集细节/跨节/宏观分开统计top_k 与 parent size 按模型上下文联动调整不硬编码摘要节点标注生成方式引用优先原文层。九、小结长文档检索的四句话父子索引是基座小块检索、大块生成解决检索粒度 vs 上下文完整的根本矛盾通用性最强摘要索引树服务宏观查询细节命中叶子、全局命中根一份索引两种服务但 LLM 摘要成本高只给高频长文档建章节结构索引最被低估文档自带的大纲比算法聚类准标题路径进 chunk、目录页单独入库两行改动大幅提升结构化文档表现组合 分类评估按文档类型组合三种范式评估必须分细节/跨节/宏观三类探针——跨节和宏观的命中率才是长文档方案的真实价值。下一篇讲 Map-Reduce 式处理当单文档彻底超出上下文怎么分而治之地做全文级问答。