VectifyAI/PageIndex

解决什么问题

向量 RAG 把文档切块、做 embedding、按语义相似度召回。在 10-K 财报、合同、监管文件、技术手册这类长而结构复杂的文档上，相似不等于相关：召回的是措辞相近却答非所问的段落，真正相关但换个说法的内容反而漏掉。PageIndex 换了个思路：先给文档建一棵层级树索引，再让 LLM 像人类专家那样顺着目录逐层推理，翻到该读的那一节。

有什么不同

和 Chroma、pgvector 这类向量库相比，差别不在调参，而在检索机制本身：不切块、不做 embedding，返回结果可以追溯到具体的文档节点，天然便于给出引用和审计。和把整份 PDF 直接塞进长上下文模型相比，PageIndex 只读推理路径经过的节点，查询成本不随文档长度线性上涨——README 给出的数据是原生 PDF 输入在 52 页时贵 2.1 倍、420 页时贵 16.6 倍，805 页则根本放不进上下文窗口。代价是延迟和模型依赖：检索本身是一步步的 LLM 推理，聊天模型弱会直接拖累效果，这点比向量方案更敏感。

适合谁

适合在密集、结构化的长文档上做问答、尽职调查或研究工具的团队：金融科技和法务科技的工程师、分析师，语料是几十到几千份长 PDF，而不是几百万条短网页。反过来，对高 QPS、低延迟的短文本语义搜索，对多语言或模糊召回有明显依赖的场景，或者不愿意为每次查询支付 LLM token 的团队，它并不合适。

上手成本

Python 包，MIT 协议，需要自备 LLM API key（OpenAI，或装可选依赖后用 Claude 订阅额度）。建索引是一次性成本，README 称约 $0.001/页、耗时 13 秒到 4.5 分钟；但每次查询的开销取决于聊天模型在树上走多远，最好用自己的语料实测。项目很新（2025 年 4 月创建），README 明显偏向云端和 App，本地 SDK 细节、Agent 集成、多文档检索都在站外文档里，动手前先读文档。

点评

PageIndex 是一套真正不同的检索设计，不是又一层向量库包装；README 报告的 FinanceBench 成绩和 39.6k 星标说明关注度真实存在，HotRepo 记录的这个月它涨了约 3,867 星，月榜排到第 20。需要留意的是成熟度和成本结构：项目刚过一年，Hacker News 上的讨论不多（一条 192 分的 Show HN），而逐次查询的 LLM 推理和一次相似度查找完全不是一个计价方式。文档长、答案需要可追溯的话，值得认真做原型；想直接替换成熟的向量方案，还早了。