在大语言模型应用领域，检索增强生成（Retrieval-Augmented Generation，RAG）已成为处理长文档的核心方案。传统 RAG 依赖向量嵌入（embedding）和向量数据库进行语义相似度检索，这种范式在简单场景下表现良好，但在处理结构化强、专业度高的长文档时暴露出明显瓶颈。PageIndex 作为新兴的无向量（vectorless）、推理驱动（reasoning-based）RAG 框架，提供了一种截然不同的技术路径：让 LLM 像人类一样 “阅读目录 — 定位章节 — 提取答案”，而非在向量空间中 “搜索最相似的文本块”。
向量 RAG 的结构性困境
理解 PageIndex 的设计思路，需要先正视传统向量检索的固有局限。当前主流的向量 RAG 流程是：将文档切分为固定大小的块（chunk），通过 embedding 模型将每个块映射为向量，存入向量数据库；查询时将用户问题同样转换为向量，在向量空间中寻找距离最近的块作为上下文输入。这种方案存在五个核心问题。
查询与知识空间的语义错配是最根本的挑战。用户问题表达的是 “意图” 而非 “内容”，例如询问 “公司去年的净利润增长了多少”，而向量检索寻找的是与该问题表面相似的内容，而非真正包含答案的财务数据段落。语义相似度无法等价于答案相关性，这在专业文档中尤为突出 —— 金融年报、法律合同、技术手册中大量段落语义相近，但对特定问题的相关程度截然不同。
固定切分破坏语义完整性是第二个痛点。以 512 或 1000 token 为单位硬性切分文档，往往切断了句子、段落乃至章节的逻辑连贯性。关键信息可能被拆分到两个不同的块中，导致 LLM 无法获得完整的上下文，增加了幻觉（hallucination）风险。
缺乏对话历史感知使得多轮问答场景下的检索效果大打折扣。每个查询都被独立处理，模型无法利用之前的问题和回答来缩小检索范围。此外，文档内部交叉引用（如 “详见附录 G” 或 “参见表 5.3”）也是向量检索的盲区 —— 引用文字与被引用内容在语义上毫无相似度，传统 RAG 无法自动追踪这些链接。
PageIndex 的推理驱动检索范式
PageIndex 的核心思路是将文档的结构信息 —— 尤其是目录（Table of Contents，ToC）—— 转化为 LLM 可直接推理的索引树，让模型在推理过程中主动决定 “下一步应该看哪里”。这模拟了人类阅读长文档的自然行为：先扫描目录定位相关章节，进入该章节后仔细阅读，如果信息不足则返回目录寻找其他可能相关的部分，如此迭代直到找到完整答案。
具体而言，PageIndex 的检索流程包含五个迭代步骤。首先是读取目录，LLM 理解文档的整体结构，识别可能相关的章节；其次是选择章节，基于问题意图选择最可能包含答案的章节；然后是提取信息，解析所选章节的内容；接着是判断是否充分，如果信息足够则进入答案生成，否则返回第一步继续搜索；最后是生成答案，基于收集到的完整上下文给出准确回答。
这套流程的关键在于将索引结构置于 LLM 的上下文窗口内，形成所谓的 “in-context index”。与存储在外部的向量数据库不同，JSON 格式的层级索引直接存在于模型的活跃推理上下文中，模型可以在推理过程中实时引用、遍历和推理这个结构，而非依赖预计算的相似度分数。
索引结构设计：JSON 层级树
PageIndex 采用 JSON 格式的层级树结构来表示文档目录，每个节点包含以下字段：node_id 作为唯一标识符用于定位原始内容；name 或 title 为人类可读的章节标题；description 为可选的详细说明，可用于向 LLM 描述该章节的内容概要；metadata 为任意键值对，存储文档类型、作者、时间戳等上下文信息；sub_nodes 为子节点数组，实现递归嵌套形成完整的目录树。
以金融文档为例，根节点可能代表 “年度报告”，其子节点分别对应 “资产负债表”“利润表”“现金流量表” 等主要章节，每个章节下又可细分为更具体的节和页。索引树中的每个节点通过 node_id 直接映射到原始内容（文本、图片、表格），LLM 可以根据推理结果精确拉取对应节点的内容，而非返回一堆语义相似但逻辑上碎片化的文本块。
这种设计的显著优势在于保留了文档的原始结构。向量检索把文档 “打散” 成扁平的向量，丢失了章节层级和逻辑关系；而 PageIndex 的索引树天然承载了这些结构信息，使得检索结果具有可解释性 —— 每个答案都可以回溯到具体的页码和章节，便于审计和验证。
对比向量方案的性能差异
根据官方和社区反馈，PageIndex 在特定场景下展现出明显优势。在金融文档基准测试 FinanceBench 中，PageIndex 报告达到约 98.7% 的准确率。传统向量 RAG 在该类文档上表现欠佳的核心原因在于：金融年报、法律合同等技术文档中，大量段落使用相似的专业术语，语义高度重叠但对特定查询的相关性差异巨大，向量相似度无法区分 “资产负债表中的资产项” 与 “现金流量表中的资产项” 对 “公司总资产是多少” 这一问题的不同相关性。
可解释性是另一个关键差异。向量检索返回的结果是黑箱的 —— 只显示相似度分数，无法说明 “为什么这个块相关”。PageIndex 的输出包含精确的页码和章节引用，开发者可以直观看到模型推理的路径，判断答案是否可信。这种可追溯性在金融、医疗、法律等高风险领域尤为重要。
当然，推理驱动方案并非没有代价。向量检索的检索延迟通常在毫秒级，而 PageIndex 需要在索引树上进行多轮 LLM 调用（每轮可能涉及 ToC 阅读、章节选择、内容提取），推理成本显著更高。在预处理阶段，构建层级索引需要对文档进行结构解析并生成节点描述，也需要额外的 LLM 调用。这意味着 PageIndex 更适合对精度和可解释性要求高、文档结构明确、查询量相对可控的专业场景，而非高频海量的通用搜索场景。
工程落地的关键参数与选型建议
对于希望在项目中评估 PageIndex 的工程师，以下参数和策略可作为初始参考。
索引构建阶段，建议使用支持结构解析的模型（如 GPT-4o 或 Claude-4）来生成节点描述，描述内容应包含该章节的核心主题和关键实体，以增强后续推理的准确性。对于 PDF 文档，需要先进行 OCR 识别和版面分析以保留原始层级结构。节点粒度的选择需要权衡 —— 过细会增加索引体积和推理轮次，过粗则可能遗漏细节信息，一般建议以 “页” 或 “节” 作为基本节点单位。
检索阶段，推荐将单轮检索超时控制在 30 秒以内，设置最大迭代次数（如 5 轮）防止无限循环，并通过 early stopping 策略在获取足够信息后提前终止。每轮迭代可以设置不同的 temperature 参数 —— 阅读 ToC 时可用较低的 temperature（如 0.3）确保选择稳定性，生成答案时可用较高的 temperature（如 0.7）提升回答多样性。
选型判断应基于以下标准：文档是否具有明确的层级结构（目录、章节、页码）？查询是否需要精确引用和可解释性？领域是否涉及大量专业术语和交叉引用？如果三个问题均为肯定，PageIndex 或类似的推理驱动方案值得投入；否则，传统向量 RAG 的低延迟和简单架构可能更为务实。
值得注意的是，PageIndex 并非要完全取代向量检索。实践中一种可行的混合方案是：用向量检索做第一阶段的粗筛，快速定位可能相关的章节，再用 PageIndex 的推理机制在候选章节内做精确定位和交叉引用追踪。这种组合既能利用向量检索的高效性，又能发挥推理驱动方案的精度优势。
参考资料
- PageIndex 官方博客：Next-Generation Vectorless, Reasoning-based RAG（pageindex.ai）
- VectifyAI/PageIndex GitHub 仓库