传统的 RAG（检索增强生成）系统几乎离不开三件套：向量嵌入、文档切块、向量数据库。但碰到长专业文档——财报、SEC 文件、研究论文、法律手册——这套方案会暴露问题。相似度高不代表相关性强，切块会切断上下文，向量检索也容易丢失文档的结构信息。结果是召回不准、解释性差、幻觉增多。
PageIndex 由 VectifyAI 开发，走了一条不同的路。它不用向量数据库，也不做任意切块，而是把文档建成层次化树状索引，让 LLM 在树上推理导航，找到最相关的段落。
PageIndex 是怎么工作的
思路来自 AlphaGo 的树搜索，分两步：
第一步：生成树状索引
把 PDF 或 Markdown 文档转成类似目录的层次树结构。每个节点带着标题、摘要、页码范围和层级关系。文档的原始结构完整保留，不会被切成碎片。
第二步：推理搜索
用户提问后，LLM 作为代理在树上推理——判断哪些分支相关、要不要深入子节点、如何组合信息。整个过程可追溯，能看到模型走过了哪些路径、引用了哪些章节和页码。
这有点像人读厚书的办法：先翻目录和大纲，再有针对性地查具体章节。
和向量 RAG 的对比
| 维度 | 向量 RAG | PageIndex |
|---|---|---|
| 检索方式 | 向量相似度匹配 | LLM 在树状索引上推理导航 |
| 文档处理 | 需要切块（chunking） | 保留自然章节结构 |
| 存储依赖 | 需要向量数据库 | 无需向量数据库 |
| 可解释性 | 黑箱，难追溯 | 检索路径透明，精确到页码和章节 |
| 延迟 | 低（毫秒级） | 较高（秒级，需多次 LLM 调用） |
| 擅长场景 | 短文本、通用知识检索 | 长结构化文档、专业领域 QA |
基于 PageIndex 构建的 Mafin 2.5 在 FinanceBench 上达到了 98.7% 的准确率。同一类金融 QA 任务上，传统向量 RAG 通常在 30% 到 60% 之间。
实际使用中的优缺点
做得好的地方：
- 文档结构保留完整，适合金融、法律等专业领域的问答
- 检索路径人类可理解，审计和合规方面比较友好
- MIT 开源协议，支持本地 LLM，通过 LiteLLM 兼容多种模型
- 提供 Cookbook 和 Notebook 示例，上手不难
需要注意的地方：
- 索引构建和检索时 LLM 调用次数多，token 消耗和延迟都高于纯向量检索。单次查询可能要几秒，更适合精度优先的场景
- 对结构清晰的文档效果最好，内容极度杂乱的话可能需要额外处理
- 索引是一次性构建的，后续查询可以复用
快速上手
1. 克隆仓库：git clone https://github.com/VectifyAI/PageIndex
2. 安装依赖并设置 LLM API Key（支持 OpenAI 等多种模型）。
3. 生成树索引：python3 run_pageindex.py --pdf_path your_document.pdf
4. 用 Cookbook 或 Agentic 示例搭建 RAG 应用（包括与 OpenAI Agents SDK 结合的方案）。
仓库还支持 Markdown 直接处理和 Vision-based 管道（纯视觉页面图像，不需要 OCR）。
VectifyAI 还提供了云端 Chat 平台（chat.pageindex.ai）、MCP 和 API 服务，适合生产部署。企业用户有私有化方案可选。
我的看法
PageIndex 的核心主张很简单：对需要多步推理的专业文档，让 LLM "思考"比让它"匹配"更有效。这个方向有说服力，尤其是在 FinanceBench 上拿到的成绩。代价是 token 成本和延迟——如果你需要毫秒级响应，向量检索仍然更合适。但如果你在做财报分析、法规查询、论文检索这类精度优先的任务，PageIndex 值得试一下。
参考链接
- GitHub 仓库：github.com/VectifyAI/PageIndex
- 文档与 Cookbook：docs.pageindex.ai
- Chat 演示平台：chat.pageindex.ai