在专业文档检索场景中，向量相似性搜索长期占据主导地位，但一个根本性问题始终存在：相似性并不等于相关性。当用户查询「2024 年 Q3 净利润同比增长」时，传统向量检索可能返回所有包含「利润」「增长」「Q3」语义的段落，却无法定位到财务报表中真正包含该数据的具体位置。PageIndex 作为一种无向量的推理型 RAG 框架，通过构建结构化元数据与文档图谱相结合的混合索引，从根本上改变了这一困境。
混合索引的核心组成
PageIndex 的混合索引并非简单的全文索引替代品，而是将文档的结构信息、语义摘要与空间位置信息融合为一个可推理的树形图谱。该图谱由两类核心组件构成：结构化元数据层与文档图谱层。结构化元数据层负责捕获文档的层级关系，包括章节标题、页码范围、节点摘要等显式信息；文档图谱层则在此基础上建立节点间的语义关联，形成可遍历的推理路径。这种双层架构使得检索过程不再是盲目的相似性匹配，而是沿着预定义的语义路径进行精确导航。
在具体实现中，每个索引节点包含多个可选字段。节点编号（node-id）提供唯一标识，便于后续追溯；节点摘要（node-summary）用自然语言描述该节点的核心内容，作为推理判断的依据；文档描述（doc-description）则从全局视角概括整个文档的主题与结构。默认配置下，系统会自动生成所有可选字段，但工程实践中可根据性能需求选择性关闭以减少 token 消耗。值得注意的是，PageIndex 明确区分了 PDF 原生处理与 Markdown 转换两种路径：前者能够完整保留原始文档的层级结构，而后者由于依赖「#」符号识别标题层级，在从 PDF 或 HTML 转换而来时往往会出现结构丢失的问题。
索引构建参数与节点配置策略
索引构建的质量直接决定检索效果的上限。PageIndex 提供了多个可调参数，工程人员需要根据目标文档的特征进行针对性配置。--max-pages-per-node 参数控制每个节点最大覆盖的页数，默认值为 10 页。对于结构紧密的财务报告或法律文书，建议将该值降低至 5 至 7 页，以确保节点粒度足够精细；而对于章节划分明确的学术著作或技术手册，保持默认值甚至适度提升至 12 页可以减少节点数量，降低树搜索的深度。--max-tokens-per-node 参数限制每个节点的 token 上限，默认 20000 tokens，这一数值对应约 15000 至 18000 个英文单词或 8000 至 10000 个中文字符，超出限制的节点将被自动拆分。
--toc-check-pages 参数指定系统用于检测目录结构的页面范围，默认检查前 20 页。这一参数对于扉页较长或目录靠后的文档尤为重要，例如某些年度报告中管理层讨论分析（MD&A）部分可能从第 30 页才开始，此时需要将该参数扩展至 40 至 50 页以避免漏检目录信息。在批量处理场景中，建议先对样本文档进行人工分析，统计目录起始页面的分布规律，再确定统一的参数值。对于节点标识和摘要的生成选项，--if-add-node-id 和 --if-add-node-summary 默认启用，但在追求极致性能且查询场景相对简单的场景下，可考虑关闭摘要生成以节省约 30% 的索引构建时间和存储空间。
查询分解与路径推理的工作流程
当用户发起查询请求时，PageIndex 并非直接在各节点中寻找相似内容，而是首先进行查询分解。系统将复杂查询拆解为多个语义子问题，每个子问题对应树结构中的一条推理路径。例如，针对「对比 2023 年和 2024 年研发费用变化，并分析对毛利率的影响」这一查询，系统可能生成三条推理路径：第一条指向 2023 年财务报表中的研发费用明细，第二条指向 2024 年对应章节，第三条则指向成本结构分析部分。随后，LLM 在树结构中沿这些路径进行有向遍历，根据每个节点的摘要判断是否需要深入子节点或回溯至父节点。
这种推理机制的核心优势在于可追溯性。与向量检索的「黑箱」模式不同，PageIndex 的检索过程可以精确到具体的页码和章节节点，系统不仅返回检索结果，还能展示推理路径上的关键决策点。在金融文档分析等对准确性要求极高的场景中，这一特性使得审核人员能够验证每一条信息的来源，而非盲目信任模型输出。Path Index 的树搜索算法借鉴了 AlphaGo 的蒙特卡洛树搜索思想，但在实现上进行了简化，主要依赖启发式规则和 LLM 的语义判断来指导搜索方向。
工程实践中的参数调优建议
将 PageIndex 投入生产环境时，需要建立系统化的参数调优流程。首先，在索引构建阶段应建立文档分类机制，针对不同类型的文档采用差异化的节点配置。财务类文档建议降低 --max-pages-per-node 至 6 至 8 页，同时将 --toc-check-pages 扩展至 30 至 40 页以覆盖完整的目录结构；技术文档可保持默认参数，但应确保 Markdown 转换时保留原始层级标记；法律文书则需要在节点摘要中强化条款编号的识别，以便后续精准引用。
其次，在检索阶段需要关注延迟与精度的平衡。树搜索的深度直接影响响应时间，深度越大延迟越高但精度越好。对于实时性要求高的交互式场景，建议限制最大搜索深度为 3 至 4 层；对于离线分析任务可放宽至 6 至 8 层以获取更全面的上下文。模型选择同样关键，GPT-4o 系列在复杂推理任务中表现优异，但成本较高；GPT-3.5-turbo 或 Claude Haiku 适合对延迟敏感且查询复杂度适中的场景。实际部署中可建立模型路由层，根据查询复杂度自动选择合适的模型。
最后，监控指标体系应涵盖检索成功率、平均响应时间、token 消耗以及最重要的人工校验准确率。建议每周抽样 100 至 200 条查询进行人工标注，追踪准确率的变化趋势，及时发现参数配置或索引质量的问题。当准确率出现显著下降时，往往意味着新增文档的格式或结构偏离了历史分布，需要针对性地调整索引参数或增加文档预处理规则。
资料来源：GitHub 仓库 https://github.com/VectifyAI/PageIndex、PageIndex 框架介绍 https://pageindex.ai/blog/pageindex-intro。