PageIndex 评测：不建向量索引，用 LLM 在树状目录里推理的 RAG 方案

相似度不等于相关，这是 PageIndex 要解决的问题

向量 RAG 的检索逻辑是语义相似度。相似度高的片段不一定回答你的问题，回答问题的片段也不一定在语义上最接近查询。PageIndex 的 README 直接点破这一点：它把索引单位从固定大小的 chunk 换成文档的自然章节，检索时不再做 embedding 比对，而是让 LLM 在树状目录上推理。这个思路的适用对象很明确，长篇幅、结构化的专业文档，比如财报、法规、技术手册。对这类文档，问题往往需要跨章节组合信息，单靠相似度匹配确实容易漏。

两段式流程：先建树，再在树上推理

PageIndex 的检索分两步。第一步是索引，为每篇文档生成树状结构索引。README 特别提到，树结构本身从文档布局信息里启发式提取，不经过 LLM，LLM 只负责摘要和精炼。这意味着 PDF 自带的标题层级、目录结构被直接利用，省掉了大模型参与结构抽取的成本。第二步是检索，聊天模型在树上做代理式搜索，像人一样先看目录，再决定翻开哪一节。这个机制的关键在于，检索过程是可追踪的，答案能指向具体文档和页码，而不是向量检索那种说不清来源的模糊匹配。

本地模式与云端 API 两条路

仓库的更新日志显示，PageIndex SDK 现在支持本地模式，索引、检索和对话都在本机完成，只需要自己的 LLM key。同一个客户端也可以指向 PageIndex Cloud，用 API key 访问。安装命令是 pip install -U pageindex。初始化时用 PageIndexClient 指定两个模型，index_model 负责建树，chat_model 负责检索回答。README 的建议很直接：建树用基础模型就够，因为结构已由布局启发式提取，模型只做摘要；聊天模型则用你能负担的最好的，因为检索质量直接依赖它的推理能力。storage_path 参数控制本地索引的存放位置。

模型命名与成本结构，配置前要想清楚

模型名遵循 LiteLLM 的命名约定，OpenAI 模型直接写名字并设置 OPENAI_API_KEY。README 里给出的示例是 index 用 gpt-5.6-luna，chat 用 gpt-5.6-sol。这里有个值得注意的成本结构：每次查询，聊天模型都要在树上做多轮推理，而不是一次向量计算。README 专门有一节叫 Query cost and accuracy，暗示查询成本与精度之间存在权衡。如果你把最贵的模型用在 chat 上，单次查询的 token 消耗会明显高于向量 RAG。对于高频查询场景，这个成本差异可能比索引构建更值得关注。

PageIndex Flash 与文件系统层，扩展的方向

更新日志提到两个扩展。PageIndex Flash 用文档自身的布局信息启发式生成树结构，而不是让 LLM 构建，目的是把 PDF 的结构提取时间从秒级压缩到更短。另一个是 PageIndex File System，一个文件级树索引层，让 PageIndex 能推理整个语料库，而不只是单篇文档。这两个方向恰好补上了核心设计的两个短板：单文档建树的速度问题，以及多文档检索的缺失。不过 README 对这两块的细节描述不多，具体实现和效果只能等文档补充。

一个明显的局限：没有层级结构的文档怎么办

PageIndex 的整个机制建立在文档有可提取的层级结构之上。PDF 的章节标题、目录是树结构的天然来源。但很多文档并没有清晰的层级，比如聊天记录、邮件往来、非结构化的网页正文。对这些内容，启发式布局提取可能失效，只能退回让 LLM 建树，成本会上升，而且树的质量取决于模型的判断。另一个问题是，PageIndex 的检索路径依赖树的结构合理性，如果原始文档的章节划分本身很糟糕，推理式检索也会跟着出错。它解决的是相关性问题，但前提是文档结构本身可用。

与向量 RAG 的真实差异，不只是索引形式

向量 RAG 和 PageIndex 的区别不在索引格式，而在检索的决策方式。向量检索是静态的，一次 embedding 计算就得到结果，速度快但不可解释。PageIndex 的检索是动态的，LLM 每走一层树都要做一次判断，可以结合对话历史、领域知识这些上下文。README 的对比表把这一点说得很清楚：向量 RAG 的上下文只有查询 embedding，PageIndex 的上下文是完整的对话历史和领域知识。代价是每次检索都是一次推理过程，时延和成本都更高。如果你需要的是低延迟的纯事实查找，向量方案仍然占优；如果你要的是跨章节的、需要综合判断的答案，PageIndex 的路径更合理。

编辑结论

适合处理金融报告、法律文书、技术手册这类结构清晰、篇幅长且答案必须可溯源的文档。它不适合短文本、碎片化语料或对单次查询延迟极敏感的场景，因为每次检索都要 LLM 在树上做多轮推理，token 消耗和时延都高于向量相似度计算。采用前先验证三件事：你的文档是否自带可解析的章节层级，没有层级时 LLM 建树的成本是否可接受；你的查询是否真的需要跨章节推理，纯事实查找用向量 RAG 可能更便宜；以及你能否接受索引模型和聊天模型分开配置带来的两套成本。若这些条件成立，PageIndex 的 MIT 许可证和本地模式让它值得一试，但不要把它当成向量检索的通用替代品。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes