长文档处理（Long Document Processing）策略

长文档处理（Long Document Processing）策略

核心思想：

长文档处理并不是简单地按照固定 Token 数进行切块（Chunking），而是要保留文档的语义完整性和业务结构，既保证检索的准确性，又保证上下文的完整性。

随着 2025-2026 年 RAG 技术的演进，企业级长文档处理已经从单纯的文本切分，升级为包含文档解析、高级语义切分、上下文增强、多粒度索引以及树状抽象处理（如 RAPTOR）的综合性工程。

---

一、为什么不能固定长度切块？

在 RAG 系统的早期阶段，许多开发者采用最简单的固定长度切块策略：

文档
↓
每500 Token切一次
↓
Chunk1
Chunk2
Chunk3
...

这种方式虽然实现简单，但在处理长文档时会暴露出严重的缺陷：

问题一：语义被切断

固定长度切分无视文档的自然结构，容易将一个完整的语义单元（如一个章节、一个段落或一个法律条款）强行拆分。

例如：

第一块
员工请假制度如下：
（一）年假......
----------------------
第二块
（二）病假......
（三）婚假......

当 LLM 拿到"第二块"时，它完全不知道"病假"和"婚假"是属于"员工请假制度"的，导致上下文严重缺失。

问题二：检索准确率下降

由于语义被割裂，关键信息可能分布在不同的 Chunk 中。

例如，用户问："员工病假怎么算？"

Embedding 检索可能只命中包含"（二）病假..."的 Chunk，却没有命中包含"员工请假制度"的 Chunk。模型无法建立"病假"与"请假制度"之间的联系，导致回答不准确。

问题三：上下文丢失与逻辑断裂

在法律文档、技术手册或长篇研究报告中，后文往往依赖前文的定义或前提条件。

例如：

第一条：本制度适用于所有全职员工。
...
第三条：符合条件的员工可享受带薪病假。

如果切断，LLM 在处理"第三条"时，可能不知道"符合条件"具体指代什么（即第一条中的"全职员工"），从而产生理解错误。

---

二、企业级长文档处理核心步骤

现代企业级 RAG 系统处理长文档通常遵循以下核心步骤，形成一个从粗到细、从结构到语义的完整流水线：

原始文档
    │
    ▼
① 文档结构解析 (Structure Parsing)
    │
    ▼
② 高级语义切分 (Advanced Semantic Chunking)
    │
    ▼
③ 上下文增强 (Context Enrichment)
    │
    ▼
④ 多粒度与树状索引 (Multi-granularity & Tree Indexing)
    │
    ▼
    RAG检索

---

第一步：文档结构解析（Structure Parsing）

企业级系统不会将文档视为一整块无结构的文本。相反，第一步是识别并提取文档的内在结构，将其转化为一棵文档树（Document Tree）。

例如，一份《员工管理制度》会被解析为：

员工管理制度
├── 第一章 总则
│
├── 第二章 请假制度
│     ├── 年假
│     ├── 病假
│     └── 婚假
│
├── 第三章 考勤制度
│
└── 第四章 奖惩制度

通过解析一级标题、二级标题、段落、表格、图片和列表，系统能够理解文档的逻辑脉络，为后续的智能切块提供结构依据。

常见解析对象与方法：

文档类型	解析内容	常用工具/技术
PDF	标题、正文、页码、表格	PDFMiner, PyMuPDF, 视觉文档理解模型
Word	Heading、目录、样式	python-docx
Markdown	H1/H2/H3 标签	Markdown 解析器
HTML	DOM Tree	BeautifulSoup
Excel	Sheet、行列结构	Pandas, OpenPyXL

---

第二步：高级语义切分（Advanced Semantic Chunking）

这是长文档处理中最关键的一步。切分的原则是按照**信息单元（Information Unit）**进行，而不是固定的 Token 数量。

随着技术的发展，出现了多种高级切分策略：

1. 递归切分（Recursive Chunking）

按照文档的层级结构逐层切分：

标题 -> 段落 -> 句子 -> Token

系统会尽量在较高的层级（如段落）保持完整，只有当段落过长时，才会递归地向下切分到句子级别。这是 LangChain 等框架的默认推荐方式。

2. 语义切分（Semantic Chunking）

基于 Embedding 相似度来决定切分边界。系统计算相邻句子或段落的向量相似度，当相似度低于某个阈值时，认为话题发生了转换，从而在该处进行切分。这种方法能自动识别语义边界，是目前企业非常推荐的方法。

3. 自适应切分（Adaptive Chunking）

自适应切分创建大小可变的 Chunk，在保持在 Token 限制内的同时，尊重文档的自然边界（如条款、章节）。例如，在法律合同中，它会确保一个完整的条款（即使有 1150 个 Token）作为一个整体保留，而不是在中间截断。

4. 实体/主题切分（Entity/Topic-Based Chunking）

• 实体切分：利用 NER（命名实体识别）技术，将提及相同实体（如"马斯克"或"SpaceX"）的句子聚集在一个 Chunk 中，非常适合构建以实体为中心的知识库。
• 主题切分：使用聚类算法（如 K-means 或 HDBSCAN）将具有相似主题的段落组合在一起，即使它们在原文档中并不相邻。这对于研究论文或长篇报告的主题检索非常有效。

5. 混合切分（Hybrid Chunking）

结合多种策略，例如先进行递归结构切分，然后在每个结构块内进行语义分组，最后确保关键实体不被分割。这种流水线方式能生成结构化、连贯且完整的 Chunk。

---

第三步：上下文增强（Context Enrichment）

即使进行了完美的语义切分，单个 Chunk 脱离原文档后，往往也会丢失全局上下文。

例如，一个 Chunk 内容为："病假最长30天。"

如果单独检索，LLM 无法知道这是哪个公司的规定、属于哪一年的版本、或者是在哪个章节下。

因此，企业级系统必须对 Chunk 进行上下文增强（Context Enrichment）。

常见增强内容：

1. 标题与父章节注入 ：将文档标题和父级章节名称附加到 Chunk 前面。
   • 增强后 ：[员工管理制度 - 第二章 请假制度 - 病假] 病假最长30天。
2. 摘要注入：使用 LLM 为整个文档或父章节生成摘要，并将其作为元数据或前缀附加到 Chunk 中。
3. 关键词提取：提取 Chunk 的核心关键词（如"病假"、"医疗"、"住院"），增加检索命中率。
4. 元数据（Metadata）绑定：附加结构化信息，如部门、发布时间、版本号、作者等。这不仅有助于检索，还能在检索前进行硬过滤（Metadata Filtering），大幅减少误召回。

---

第四步：多粒度与树状索引（Multi-granularity & Tree Indexing）

用户的问题粒度是多变的。有时需要具体的细节（"病假怎么算？"），有时需要宏观的概览（"整个请假制度有哪些？"）。单一粒度的 Chunk 无法同时满足这两种需求。

1. 多粒度索引（Hierarchical Retrieval）

企业通常会建立多个层级的索引：

Document Level -> Chapter Level -> Section Level -> Paragraph Level

在检索时，系统可以根据查询的复杂度和范围，自动选择最合适的层级进行匹配，或者采用自顶向下的层级检索（Hierarchical Retrieval），逐层缩小范围，既保证了全局理解，又实现了细节的精准定位。

2. 父文档检索（Parent Document Retrieval）

这是一种非常实用的工程实践。在向量数据库中，系统索引的是较小的 Child Chunk（以保证检索的精准度），但在检索命中后，实际返回给 LLM 的是包含该 Child Chunk 的完整 Parent Document（父文档或整个章节）。这有效避免了 LLM 上下文不足的问题。

3. RAPTOR：树状组织的递归抽象处理

在 2024-2025 年，RAPTOR (Recursive Abstractive Processing for Tree-Organized Retrieval) 成为处理超长文档的前沿框架。

RAPTOR 突破了传统的扁平化检索，它通过自底向上的方式构建一棵抽象树：

1. 聚类：将基础的文本 Chunk 根据语义向量进行聚类（使用 UMAP 降维和 GMM 聚类）。
2. 摘要：使用 LLM 对每个聚类生成高层次的文本摘要。
3. 递归：将生成的摘要再次进行聚类和摘要，直到构建出涵盖整个文档全局视角的根节点。

在检索时，RAPTOR 可以在树的不同层级进行匹配，从而能够同时回答需要具体细节的问题和需要跨章节综合理解的宏观问题。

---

五、企业级长文档处理完整流程图

               原始长文档
                    │
                    ▼
          文档解析（Structure Parsing）
                    │
                    ▼
         文档结构树（Document Tree）
                    │
                    ▼
      高级语义切分（Adaptive/Semantic Chunking）
                    │
                    ▼
       上下文增强（Context Enrichment）
          (附加 Title, Parent, Summary)
                    │
                    ▼
        Metadata 补充 & 实体提取
                    │
                    ▼
      构建多粒度/树状索引（如 RAPTOR 结构）
                    │
                    ▼
         Parent Document Mapping
                    │
                    ▼
             Hybrid Retrieval (混合检索)
                    │
                    ▼
               Rerank 深度精排
                    │
                    ▼
                  输入 LLM

---

六、常见问题 (FAQ)

Q1：为什么不能固定长度切块？

回答：固定长度切块容易破坏文档的自然语义结构，导致一个完整的章节或条款被拆分成多个碎片。这不仅会造成上下文缺失，还会严重影响 Embedding 的质量和检索的准确率。现代 RAG 系统更倾向于基于语义边界和文档结构进行切分。

Q2：什么是自适应切分（Adaptive Chunking）？

回答：自适应切分是一种高级策略，它在保持 Token 限制的同时，尊重文档的自然边界（如段落、条款）。它不会在逻辑单元中间强行截断，而是动态调整 Chunk 的大小，以最大化保留语义完整性。

Q3：为什么需要上下文增强（Context Enrichment）？

回答：切分后的 Chunk 往往会丢失全局信息。如果不补充文档标题、父章节名称、摘要或元数据，LLM 在阅读该 Chunk 时会缺乏必要的背景知识，导致理解偏差。上下文增强确保了每个 Chunk 都是一个自包含的信息单元。

Q4：什么是 RAPTOR 框架？

回答：RAPTOR 是一种用于长文档处理的树状组织检索框架。它通过递归地对文本块进行聚类和摘要，构建出一棵从细节到宏观的抽象树。这使得 RAG 系统能够有效处理需要跨越整个长文档进行综合推理的复杂问题。

Q5：什么是 Parent Document Retrieval？

回答：这是一种检索策略。系统在底层索引较小的文本块以提高检索的精确度，但当某个小文本块被命中时，系统会向上追溯，将包含该文本块的整个父级文档或大章节返回给 LLM，从而为模型提供充足的上下文。

---

七、企业级长文档处理核心知识点总结

模块	作用	常见高级方案
文档解析	识别文档内在逻辑结构	PDF 视觉解析、Word/Markdown 结构树提取、HTML DOM 解析
高级切分	保证信息单元的语义完整性	Semantic Chunking、Adaptive Chunking、Entity/Topic-Based Chunking
上下文增强	丰富 Chunk 的背景信息	注入 Title/Parent 路径、LLM 摘要生成、Metadata 绑定
多粒度索引	满足宏观与微观的不同检索需求	Document/Chapter/Section 多级索引、Parent Document Retrieval
树状抽象	解决跨文档/长文档的全局推理	RAPTOR (递归聚类与摘要树)
检索优化	提高召回率与准确率	Hybrid Retrieval (混合检索)、Rerank (交叉编码器精排)、Metadata Filter