在企业级文档检索场景中，向量相似度搜索长期以来是主流方案。然而，当处理财务报表、监管文件、学术教材等需要多步推理的专业文档时，相似度与相关性之间的鸿沟愈发明显。PageIndex 作为一种无向量（Vectorless）的推理式检索框架，通过构建层次化树形索引并结合大语言模型的推理能力，为长文档场景提供了一种高性价比的替代方案。本文将从工程实现角度，分析其核心技术机制，并给出可落地的参数配置建议。
向量检索的局限性：从相似度到相关性
传统向量 RAG 的核心流程是将文档切分为固定大小的块（Chunk），通过嵌入模型将每个块转换为高维向量，然后在向量空间中依据余弦相似度进行检索。这一范式在语义泛化场景下表现良好，但在专业文档领域面临两个根本性问题。其一是切分损失（Chunking Loss）：固定窗口的切分方式往往破坏原始文档的结构完整性，导致关键信息被割裂在不同的块中，模型难以捕捉跨段落、跨章节的语义关联。其二是相似度≠相关性：向量空间中的语义相似并不等同于用户查询所需的信息相关性。例如，在一份年报中，“净利润” 与 “营业利润” 在向量空间中可能非常接近，但针对 “2024 年第四季度净利润同比变化” 这一具体问题，两者的答案价值完全不同。
PageIndex 的设计理念正是针对这两个痛点。它放弃向量嵌入的方式，转而利用文档原有的层级结构 —— 标题、章节、段落 —— 构建一棵类似目录树（Table of Contents）的语义索引。在检索阶段，不是通过向量距离匹配候选块，而是让 LLM 在这棵树上进行 “推理式行走”，根据查询的语义意图判断哪些分支最可能包含答案。
树形索引的构建机制
PageIndex 的索引构建分为两个阶段。第一阶段是树结构生成：系统接收 PDF 或 Markdown 格式的原始文档，通过解析文档的标题层级和页面布局，自动生成一棵分层树。树的每个节点对应文档中的一个自然章节或段落，节点内容包含该章节的标题、摘要以及在原文档中的页码范围。这一过程完全基于规则解析与 LLM 的结构化理解，无需人工标注或训练。
第二阶段是索引摘要增强。在生成树结构时，系统默认为每个节点添加摘要信息（Node Summary），帮助后续的推理检索快速判断该分支与查询的相关性。用户可以通过参数控制是否添加节点 ID、节点摘要以及文档整体描述，这些元信息将直接影响后续检索的精度与 token 消耗。
推理式检索的工作流程
与传统向量检索的单轮召回不同，PageIndex 的检索是一个迭代式的树搜索过程。当用户提出查询时，系统首先将完整的问题与整棵树的根节点信息一并发送给 LLM，让模型判断应该沿着哪个分支向下探索。LLM 会根据节点摘要和查询意图，推理出最有可能包含答案的子节点路径。随后，系统逐层向下查询，直到定位到具体的页面内容。这种 “自顶向下” 的推理行走机制，模拟了人类专家查阅文档的行为 —— 先定位章节，再定位段落，而不是在全文范围内做无差别的相似度排序。
这种机制的优势在于：检索的每一步都带有明确的推理依据，开发者可以回溯模型选择了哪条路径、在哪个节点做出了判断。相较于向量检索的 “黑盒” 排序，PageIndex 提供了完整的可解释性。同时，由于检索范围随树深度逐层收敛，实际调用 LLM 进行内容提取的 token 总量远小于将整文档全部输入的方案。
关键工程参数与配置建议
在实际工程部署中，PageIndex 提供了多个可调节参数，开发者需要根据文档规模、延迟要求和成本预算进行权衡。以下是核心参数及其推荐配置。
模型选择（--model）：默认使用 gpt-4o-2024-11-20。对于对延迟敏感的场景，可考虑使用更轻量的模型进行树搜索，而在最终内容提取阶段使用高质量模型。金融文档等高精度要求的场景建议全程使用 GPT-4o 级别模型。
目录检查范围（--toc-check-pages）：默认值为 20，即系统默认文档前 20 页包含目录信息。如果文档结构较为特殊，可能需要调大此参数以确保完整识别章节层级。建议在使用前通过可视化工具检查树结构是否准确映射了原始文档的目录。
单节点最大页数（--max-pages-per-node）：默认值为 10。该参数控制每个树节点覆盖的页面范围。较大的值会减少树的总深度，但会增加单次推理的信息量；较小的值则相反。对于页面内容高度同质化的长文档（如连续的表格页面），可以适当增大此参数以减少节点数量。
单节点最大 Token 数（--max-tokens-per-node）：默认值为 20000。这是控制节点信息量的硬上限，直接影响树搜索阶段单次 LLM 调用的上下文长度。如果对成本极为敏感，可适当降低该阈值，但需注意可能影响节点摘要的完整性。
元信息开关（--if-add-node-id、--if-add-node-summary、--if-add-doc-description）：默认为全部开启。节点 ID 用于追踪检索路径，节点摘要是推理判断的核心依据，文档描述则帮助模型在根节点层面快速筛选。关闭这些开关可以显著减少索引构建阶段的 token 消耗，但会削弱检索精度。建议在生产环境中保持开启，仅在调试阶段关闭以对比效果差异。
成本效益分析与适用场景
从成本结构来看，PageIndex 的 token 消耗主要发生在两个环节：索引构建阶段和检索推理阶段。构建阶段需要将整个文档解析并生成树结构，token 消耗与文档长度成正比，但属于一次性投入。检索阶段的 token 消耗则取决于树的深度和每一步推理的上下文大小。由于树搜索天然具有范围收敛特性，实际推理 token 通常远低于将整文档直接输入的方案。根据官方在 FinanceBench 基准测试中的数据，PageIndex 在金融文档问答任务上实现了 98.7% 的准确率，同时保持了可接受的延迟和成本水平。
需要注意的是，PageIndex 特别适用于以下场景：长文档（超过 LLM 上下文窗口限制的专业文档）、结构化文档（年报、招股书、技术手册、学术论文）以及需要多步推理的复杂查询。对于短文本检索或结构松散的文档，传统向量检索仍然是更简单高效的选项。两者并非替代关系，而是针对不同数据特征和能力需求的互补方案。
落地实践的关键考量
在将 PageIndex 集成到生产系统时，开发者需要关注几个工程细节。首先是索引更新机制：当源文档发生变更时，需要重新生成树索引。建议建立版本管理机制，为每次更新生成新的索引版本，并通过指针切换实现无损切换。其次是混合检索的可行性：PageIndex 支持与向量检索进行混合使用 —— 可以用向量检索快速召回候选文档，再用 PageIndex 在文档内部进行细粒度的推理定位。这种混合模式能在保持召回速度的同时提升最终答案的准确性。最后是监控与回溯：树搜索的每一步都应记录详细的推理日志，包括模型选择了哪个节点、基于什么判断排除其他分支，这些信息对于调试和持续优化至关重要。
综合来看，PageIndex 为长文档检索提供了一种新的工程范式：放弃向量嵌入的 “模糊匹配”，转向结构化索引与推理式检索的 “精准定位”。通过合理的参数配置与系统设计，它能够在保证高精度的同时，有效控制 AI 推理的 token 消耗，是企业级文档智能场景下值得关注的技术选型。
资料来源：GitHub 仓库 VectifyAI/PageIndex 及官方文档。