GitHub狂揽30k星标，别再死磕向量库！这个开源项目让长文档 RAG 准确率飙到 98.7%
VectifyAI（一家AI初创公司）做了一个开源项目叫 PageIndex，思路完全反过来：不做切块，不建向量库，让LLM像人一样读文档。
先说个真实场景。
你手里有一份300页的招股说明书，用户问了一个具体问题：”这家公司过去三年的应收账款周转天数是多少？”
用传统的向量RAG，它会怎么干？
先把这300页切成若干个小块——每块500字、每块重叠200字——然后全部向量化。用户问问题的时候，把问题也转成向量，在向量库里找”最相似”的内容块。
结果往往是这样：
- 找到了一堆提到”应收账款”的段落，但没有一个完整包含周转天数计算的
- 或者找到的数据是对的，但上下文断了，你看不出这个数字是怎么来的
- 最离谱的时候，它会给你返回一个看起来很相关、但实际是隔壁章节的内容
原因很简单：相似度不等于相关性。
向量搜索找的是”长得像”，不是”答案对”。
PageIndex想解决什么问题
VectifyAI（一家AI初创公司）做了一个开源项目叫 PageIndex，思路完全反过来：
不做切块，不建向量库，让LLM像人一样读文档。
怎么做到？
它的灵感来自AlphaGo——不是下棋的那个算法本身，而是它的树搜索思路。
人类拿到一本长文档，是怎么读的？
先看目录，找到相关的大章节，再逐级往下翻。这个”目录”就是一个天然的树状结构。
PageIndex就做了一件事：把文档的目录结构重建出来，变成一棵”语义树”，然后让LLM在这棵树上做推理式检索。
两步：
- 生成文档的树状索引（类似目录，但不是按页码而是按语义分节）
- 让LLM在这棵树上”走”，根据问题推理出哪条路径最相关
怎么工作的？
第一步：建树
给PageIndex扔一个PDF，它会分析文档结构，自动生成一棵树。
每个节点包含：
- 标题（章节名）
- 摘要（这个章节讲了什么）
- 页码范围（起始页到结束页）
- 子节点（下级章节）
举个例子，你扔一份美联储年报进去，它会生成这样的结构：
1 | - `{` |
每棵树的根节点就是整份文档，子节点是章节、孙节点是子章节——跟真实目录的结构完全一致。
第二步：树搜索
用户提问了，比如”美联储对金融稳定性的监控框架是什么？”
这时候LLM不再是去向量库里捞”相似片段”，而是在这棵树上一边推理一边走：
- 从根节点开始，看这个问题应该往哪个子分支走
- 走到子节点，继续判断是否相关
- 找到相关节点后，提取对应页码范围的内容
整个过程是可追溯的——你能看到它走到了哪个节点、看了什么内容、为什么认为这个部分相关。
不像向量搜索，你只知道”第37个向量最接近”，但不知道为什么。
为什么比向量RAG好？
1. 不破坏文档结构
传统RAG的切块是暴力的——500字一刀、重叠200字。一句话可能被切成两半，意思就变了。
PageIndex按文档原生结构分节，不破坏段落的完整性。
2. 上下文感知
向量搜索每次检索是独立的，跟对话历史没什么关系。
PageIndex的检索是上下文驱动的——它在树上走的时候，会结合你的完整问题（包含对话历史和领域知识）来判断哪个分支最相关。
而且它能轻松整合新的上下文。你补充一句”我关注的是科技公司”，它下一次推理的权重就会变。
3. 可解释性强
向量搜索是个黑箱——你只知道”这个chunk的相似度是0.87”。
PageIndex告诉你的是：”我找到了’Monitoring Financial Vulnerabilities’这一章，它在第22到28页，摘要显示它覆盖了美联储的监控框架……”
有页码、有章节名、有摘要，随时可以核对。
4. 人一样的导航方式
PageIndex的设计理念是模拟人类专家读长文档的方式：
- 先扫目录定方向
- 再进具体章节找内容
- 中途发现走错了就折返
这不是什么花哨的技术，但它是真正符合人类认知习惯的。
效果怎么样？
用数据说话。
他们把这个方法用在一个金融文档分析系统（Mafin 2.5）上，在 FinanceBench 基准测试里跑了，结果是：
98.7%准确率
这个benchmark考的就是让AI从真实金融文档（SEC文件、年报、财报电话会记录）里提取具体数据——比如毛利率、现金流、债务条款之类的。
对比传统向量RAG，差距非常明显。
他们把完整的测试代码和数据都开源了，放在这个仓库里：github.com/VectifyAI/Mafin2.5-FinanceBench
怎么用？
自托管（开源免费）
1 | - `# 安装依赖` |
可选参数：
--model：用哪个模型，默认GPT-4o--max-pages-per-node：每个节点最多几页，默认10页--toc-check-pages：从文档前多少页提取目录结构，默认20页--if-add-node-summary：是否生成节点摘要，默认是
还支持Markdown文件：
1 | - `python3 run_pageindex.py --md_path /path/to/your/document.md` |
云服务（API + MCP）
不想自己搭，可以直接用他们的云服务：
- Chat平台：直接上传文档对话
- API：集成到自己系统里
- MCP：接Claude Desktop等支持MCP的工具
Agentic Vectorless RAG
这是最近更新的一个用法。
结合OpenAI的Agents SDK，可以做一个完全无向量、无切块的Agentic RAG：
1 | - `# 完整示例在 examples/agentic_vectorless_rag_demo.py` |
每个检索步骤都是LLM在树上推理的结果，不是向量相似度匹配。适合需要多轮对话、多步推理的复杂场景。
PageIndex File System（大规模扩展）
这是另一个最近的更新亮点。
标准用法是对单份文档建索引，但如果你的文档库有上百万份呢？
PageIndex File System在索引层之上加了一层文件树——它把整个文档库组织成一个更大的树结构，让你能在整个语料上做推理式检索，而不只是单份文档内部。
相当于文档库级别的”目录”。
适合什么场景？
场景
适不适合
长文档问答（年报、招股书、法规文档）
✅ 非常适合
需要可追溯的检索结果
✅ 每个答案都有页码和章节
金融/法律/学术文档分析
✅ 98.7%准确率不是吹的
短文档、FAQ类问答
⚠️ 杀鸡焉用牛刀
对实时性要求极高
⚠️ 建索引需要一次预处理
完全没有技术背景
⚠️ 还是有点门槛
说点缺点
建索引需要预处理
向量RAG是”来一个问题，搜一次”。PageIndex是”先建索引，再无限复用”。
对于单次查询来说，PageIndex多了一步。但如果同一份文档要回答很多问题，索引建一次就够了，后续查询反而更快。
对复杂PDF的解析还有挑战
开源版本用的是标准PDF解析。对于扫描件、图片型的PDF，解析质量会打折扣。他们的云服务有增强OCR，但自托管版暂时没有。
生态还在早期
相比Pinecone、Weaviate这些已经比较成熟的向量数据库，PageIndex的周边工具（监控、备份、可视化）还比较少。
写在最后
PageIndex给我的最大启发，不是某个具体的技术细节，而是它重新定义问题的方式。
向量RAG解决的是”怎么快速找到相似的内容”这个问题。但我们真正想要的，是”怎么找到真正相关的内容”。
这两个问题不一样，答案也不一样。
PageIndex选择了一条更难的路——不用向量相似度，而是让LLM在文档结构上做推理。效果确实好，但代价是实现更复杂、对LLM能力要求更高。
这是不是一个更通用的方向？我觉得是。
至少在金融、法律、医疗这些长文档密集的行业，”相似度”和”相关性”的差距是真实存在的，PageIndex解决的是一个真正的问题。
项目地址：github.com/VectifyAI/PageIndex
💬 本文评论区已开启，但暂无读者留言。
本文转载自微信公众号，如有侵权请联系删除。
- 标题: GitHub狂揽30k星标，别再死磕向量库！这个开源项目让长文档 RAG 准确率飙到 98.7%
- 作者: lxiol
- 创建于 : 2026-05-08 21:48:50
- 更新于 : 2026-06-30 17:05:34
- 链接: https://blog.lxiol.cn/2026/05/08/GitHub狂揽30k星标别再死磕向量库这个开源项目让长文档-RAG-准确率飙到-987/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。