📌 项目地址：VectifyAI/PageIndex | ⭐ 37,097 颗星 | 🔧 Python | 📜 未标注
向量 RAG 的老毛病
做 RAG 的人多半遇到过这种情况：问一份财报里的某个数据，检索回来的三段文字看着挺相关，就是不含答案；真正有答案的那张表格附注，因为措辞和问题完全不像，根本没被召回。
原因很简单。向量检索靠的是语义相似度，但相似不等于相关。README 里这句话说得非常直白：相似度搜索会漏掉“相关但不相似”的内容，也会返回“相似但不相关”的内容。它只做匹配，不做推理。文档越专业、越长，这个问题越严重。
PageIndex 的思路：把检索变成推理
PageIndex（VectifyAI 出品，37097 个 star）干脆扔掉了向量库和切块，换成两步：
- 建索引：给每份文档生成一个层级树状索引，结构类似书的目录
- 检索：让 LLM 在这棵树上逐层推理导航，找到该读的章节，就像一个行家翻长报告时直接翻到对的那一节
README 提到这个思路受 AlphaGo 启发：不暴力扫全文，而是用推理做选择性展开。
和向量 RAG 摆在一起看
README 的对比表值得原样转述：
| Vector RAG | PageIndex | |
|---|---|---|
| 索引 | 向量索引 | 树状索引 |
| 检索 | 语义相似度搜索 | LLM 在树上推理 |
| 结果 | 黑盒，README 原话叫 “vibe retrieval” | 可追溯到明确的引用位置 |
| 上下文 | 只有查询的 embedding | 完整上下文：对话历史、领域知识等 |
我觉得”vibe retrieval”这个说法挺准的。向量检索没法解释为什么返回这几段。PageIndex 的每条结果都能指回文档的具体位置，可审计、可解释。金融、法律、医疗这些对溯源有硬性要求的场景，这一点是实打实的优势，不是锦上添花。
上手
pip install -U pageindex
README 里的初始化代码：
import os
from pageindex import PageIndexClient
os.environ["OPENAI_API_KEY"] = "your-openai-key"
client = PageIndexClient(
index="gpt-5.6-luna",
...
README 的 Quickstart 到这里被截断了，完整的索引、检索、对话 API 用法要看官方 Docs（README 顶部有链接）。
几种使用形态：
- 本地模式：用自己的 LLM key，索引、检索、对话全在本机跑，数据不出本地
- 云模式：同一个客户端指向 PageIndex Cloud，换 API key 就行
- PageIndex Flash：针对文本型 PDF 的快速树索引生成，现在是本地模式的默认索引方式
- PageIndex File System：文件级树索引层，把索引从单份文档扩展到整个文档库，官方说可以到百万级
- PageIndex App：官方托管的文档分析应用，不写代码直接用
成本这笔账
别光看优点。这个架构把检索成本从向量计算换成了 LLM 推理：每次检索至少一次 LLM 调用，token 消耗和延迟都明显高于向量检索。精度和可解释性是用钱换的。
所以它不适合的场景很清楚：短文档、简单事实查询、高并发低延迟需求，这些向量 RAG 依然更合适。PageIndex 的甜区是 README 点名的那类文档：财报、法律文书、监管备案、技术手册、医学文献、学术教材。共同点是答案藏得深，需要多步推理和上下文理解才能定位。
我的建议
37k star 说明向量 RAG 在专业长文档上的痛点是普遍的。如果你的系统里已经调过 embedding 模型、调过 chunk 大小、调过 top-k，效果还是差口气，那问题可能不在参数，在架构。拿一两份你最头疼的文档，跑一下 PageIndex 本地模式和现有方案对比，是最快的验证方式。