结构化长文档的精准检索:PageIndex 原理、实践与边界

RAG 不止向量检索一条路。当文档自带清晰的逻辑骨架时，让 LLM 学会“翻目录”可能比“算相似度”更高效。

1. 缘起：当向量检索遇到结构化文档

检索增强生成（Retrieval-Augmented Generation, RAG）已经成为大语言模型（Large Language Model, LLM）落地的核心技术之一。主流的向量 RAG 将文档切块（chunk）、向量化(Embedding)，再通过相似度匹配召回相关内容。这套流程在开放域问答、客服等场景中表现稳健。

但在处理高度结构化的专业文档（如财报、法律合同、技术手册）时，一个需求逐渐凸显：用户常常需要精确定位到某个章节（“第三章第二节说了什么？”），或者需要理解文档的逻辑脉络（“报告对风险的结论性判断在哪一部分？”）。另一种情景是，用户需要对文档进行深入学习、分析或研判，这类需求早已超越了简单的语义相似性检索。

向量检索的本质是“语义模糊匹配”，它无法理解章节的父子关系、无法区分“正文”与“附录”，更无法执行“先看目录、再定位小节”这种人类直觉式的操作。

PageIndex 正是在这一背景下诞生的。它不再依赖向量，而是将文档转化为一棵结构树，然后让 LLM 在这棵树上做逻辑导航。本文将深入剖析其原理、适用场景、工程实践中的真实问题，以及它与向量技术的正确协作方式。

1. 两阶段流程：文档结构树 + LLM 推理导航

PageIndex 的整个工作流程分为离线和在线两个阶段。

1. 阶段一：离线索引构建（离线，一次性）

• 输入：PDF 或 Markdown 文档

• 处理：解析文档的目录（Table of Contents, TOC），提取章节标题及页码范围，形成一棵层次化的文档结构树（Document Structure Tree, DST）。树的每个节点包含：

• title：章节标题

• start_page / end_page：页码范围

• summary：由 LLM 为该章节生成的简短摘要（这是索引构建阶段唯一需要调用 LLM 的地方）

• children：子节点列表

• 输出：一棵 JSON 格式的结构树，总 token 数远小于原文。

1. 阶段二：在线推理检索（在线，每次查询）

• 用户提出问题后，系统将整个结构树（仅含标题和摘要） 发送给 LLM。

• LLM 通过一次推理（或少量几步推理）返回最相关的若干个节点 ID（支持多路径选择）。

• 系统根据这些节点 ID 提取对应的原文片段，再连同用户问题一起交给 LLM 生成最终答案。

整个过程中没有向量、没有 embedding、没有相似度计算。检索的依据完全来自 LLM 对文档逻辑结构的理解。

1. PageIndex vs. 向量 RAG：关键差异

1. 最佳适用场景

PageIndex 最擅长的文档必须同时满足两个条件：结构清晰 + 查询依赖章节定位。

已验证的高价值场景包括：

• 财务报告：年报、季报中的特定部分（如“管理层讨论与分析”）

• 法律合同：精准查找某一条款（“违约责任”章节）

• 技术手册：按功能模块定位操作说明

• 学术论文：根据 IMRaD 结构（Introduction, Methods, Results, and Discussion）定位方法或结论

在这些场景中，PageIndex 可以实现：

• 极高的定位精度：实测中，对于“找出第三章关于利润归因的段落”这类查询，根据 PageIndex 官方在财报类文档上的评测，章节定位准确率可达 95% 以上。

• 极低的检索延迟：一次树导航推理外加少量原文提取，端到端耗时通常在 2-5 秒（视 LLM API 延迟而定）。

• 无需向量基础设施：降低运维复杂度。

1. 不适用场景

• 文档结构缺失或混乱：如技术博客、会议纪要、聊天记录。此时 PageIndex 无法构建有意义的目录树。

• 需要跨文档隐式关联：如果问题需要整合多个不同文档中语义相近但位置分散的信息（例如“请总结所有提到‘数据隐私风险’的段落”），向量 RAG 更合适。

• 文档频繁变化：每次结构变更都可能需要重建索引，成本较高。

1. 综合工程实践

对于量少、核心且结构严谨的长文档（如年报、合同），建立 PageIndex 知识库；对于量大、非核心、频繁更新的文档，则接入向量知识库。检索时分别从两库召回候选，再通过 RRF 与 Cross-Encoder 融合排序，以实现更高召回率与精准度。

1. 总结：PageIndex 的价值定位

PageIndex 最大的贡献，是将“文档结构”重新放回了 RAG 系统的核心位置。如果你的文档本身就是一本逻辑严密、目录清晰的书，请给 PageIndex 一个机会——它会让你的 RAG 系统学会“翻书”，而不仅仅是“搜索”。

1. 进一步研究方向

PageIndex 是“结构化 RAG”浪潮中的一个具体实现。更广义的“树状检索”方向还包括：

1. 建设高质量的文档PageIndex

通常说的“高质量结构化长文档”多指语义内容层面的高质量，比如法律文献。然而，这些文档在技术上未必自带清晰的可解析目录，内容还可能包含图片、公式等 OCR 难点。因此，还需要从技术角度（而非仅内容角度）解决“结构化”问题。

如果 PDF 的目录提取不完整或层级混乱，可先用工具（如 MinerU、Marker）将 PDF 转换为 Markdown，再基于 Markdown 的标题层级构建结构树，必要时辅以人工校验。但这还远远不够，要达到理想的精度仍需大量探索。这是一个值得持续探索的基础问题，不仅对 PageIndex 重要，对任何内容理解与索引系统都至关重要。

1. 结构向量化与树检索的融合

将结构树中每个节点的 title 与 summary 向量化，构建层次化向量索引；查询时自上而下逐层精炼，兼顾结构先验与向量检索效率。

1. RAPTOR：递归语义聚类树

由斯坦福团队提出的 RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval）不依赖文档自带的目录，而是通过向量嵌入递归地对文本块进行聚类，再为每个聚类生成摘要，自下而上构建语义树。它适用于原本没有结构的大规模文档集（如论文库、新闻集合）。

与 PageIndex 的区别：

• PageIndex：利用给定的结构（显式）

• RAPTOR：发现潜在的结构（隐式）

参考资料

• PageIndex GitHub：https://github.com/VectifyAI/PageIndex

• PageIndex 官方文档：https://docs.pageindex.ai

• RAPTOR 论文：https://arxiv.org/abs/2401.18059

阅读更多 AI 文章，请访问飞书知识库：https://xicb4jffii7.feishu.cn/wiki/Khg2waqP6iSbh2kmculcMnrnnOg