PageIndex：扔掉向量数据库，RAG 准确率飙到 98.7%

📝

PageIndex 用 LLM 推理替代向量搜索，用树状结构替代 chunk，在 FinanceBench 上达到 98.7% 准确率。本文深度解析其核心架构、代码实现和适用边界。

没有向量数据库，没有文档分块，没有 embedding 模型——PageIndex 用”像人一样翻文档”的方式，把 RAG 准确率从 30% 拉到了 98.7%。

在金融文档问答领域最权威的基准测试 FinanceBench 上，一个开源项目交出了 98.7% 的准确率。排名第二的系统是 91%。传统向量 RAG？只有 30% 到 50%。

这个项目叫 PageIndex，由 VectifyAI 团队在 2025 年 9 月推出，灵感来自 AlphaGo 的树搜索策略，GitHub 上已经收获了超过 23,000 Star。

向量 RAG 到底哪里不行？

如果你搭过 RAG 系统，对以下场景不会陌生。用户问：”2024 财年总净收入与 2023 年相比如何变化？”你的向量管线执行标准流程：把 200 页年报切成 500 token 的 chunk，做 embedding，存进向量数据库，查询时取 top-k 相似 chunk，喂给 LLM。

短文档跑得很好。但面对专业长文档，有五个结构性缺陷：

查询文本不像答案文本。问”收入趋势”，被召回的是每一段”谈到收入”的文字，而不是第 47 页那个具体的表格行。
同一个词出现 60 次。”营业利润”散布在一份 200 页年报的数十个上下文中，向量相似度排名几乎一样。
分块切碎了表格。标题在 chunk 14，数据在 chunk 15，单独看哪个都毫无意义。
跨页引用完全丢失。第 12 页写着”详见附录 G”，附录 G 在第 87 页。向量计算不出任何语义相似性。
多轮对话没有记忆。上一条问资产，下一条问”负债呢？”，检索器把它当全新查询。

PageIndex 创始人 Mingtian Zhang 说得很直接：检索真正需要的是相关性，而相关性需要推理。

核心架构：两步走

PageIndex 不搜索向量空间，而是让 LLM 像人类专家一样”看目录、找章节、读内容”。

第一步：构建层次树索引

把 PDF 喂进去，不做 embedding，不做分块。分析文档结构，生成一棵层次化的 JSON 树——一个”LLM 优化版”的目录。每个节点包含：标题、摘要、页码范围、子节点。

一份 50 页的 SEC 文件可能生成 30-50 个节点的树。整棵树是一个 JSON 对象，不存向量数据库，就在 LLM 的上下文窗口里——VectifyAI 称之为上下文内索引（in-context index）。模型不是在查询外部系统，而是在实时推理结构化文档地图。

第二步：基于推理的树搜索

把树结构（只有标题和摘要，不含原文）交给 LLM，问：”这份文档的这个问题，应该去哪里找答案？”

检索循环：扫描目录 → 选择最可能相关的节点 → 读取原始内容 → 够了吗？够了就生成答案，不够就回上一步继续找。

跟向量搜索的范式差异：

向量数据库：对所有 chunk 并行计算余弦相似度，快但蠢
PageIndex：让 LLM 思考答案在哪里，能跟随交叉引用、识别多步推理

自修正目录提取：三条 fallback 路径

树索引的质量决定整个系统的上限。PageIndex 在 page_index.py 的 meta_processor() 中设计了三条降级路径：

路径 A：有页码的 TOC。提取 TOC → JSON 化 → 并发抽检验证（LLM 检查标题是否真在指定页）。100% 直接通过，60%+ 进入修正
路径 B：无页码的 TOC。提取结构 → 通过内容匹配逐步推断页码
路径 C：无 TOC。分块 → LLM 从零生成层次结构 → 合并

这三条路径形成降级链，保证在任何文档上都能产出可用的索引。

代码架构：2900 行 Python 的精简设计

6 个核心 Python 文件，总共约 2900 行代码。没有 PyTorch，没有 FAISS，没有向量数据库依赖。核心依赖只有四个：LiteLLM、PyMuPDF、tiktoken、PyYAML。

文件	行数	职责
`page_index.py`	1153	PDF 树索引生成核心
`utils.py`	710	LLM 调用封装、JSON 处理
`page_index_md.py`	341	Markdown 树索引生成
`client.py`	234	高级 API 客户端
`retrieve.py`	137	文档检索接口
`run_pageindex.py`	~60	CLI 入口

附录 G 的故事

有人问美联储年报中”递延资产总额”是多少。年报正文讨论了递延资产的变化，第 77 页有一句：”表 5.3 总结……本报告附录 G 提供了更详细信息。”

向量 RAG：彻底卡住。附录 G 是一张数字表格，与”递延资产”查询之间没有语义相似性。
PageIndex：LLM 导航到金融章节，遇到交叉引用，通过树结构跟随到附录 G，检索表格，返回精确数字。每一步都有推理痕迹。

这是推理检索和相似度检索的本质区别。

FinanceBench 数据全景

系统	准确率
Mafin 2.5（PageIndex）	98.7%
Dewey Agentic RAG	~91%
开源标准 RAG	~76%
传统向量 RAG	30-50%
Perplexity	~45%
GPT-4o（无 RAG）	~31%

诚实面对局限

PageIndex 的 98.7% 是真实的，但只在 FinanceBench 上验证过：

速度：每次检索多轮 LLM 调用，数秒 vs 毫秒
成本：多轮 LLM 推理 vs 单次 embedding 查询
广度：单份长文档的深度提取强，但 10,000 份短文档的广度搜索不适用
文档质量依赖：垃圾进，垃圾出

混合方案可能是最佳实践：向量搜索快速定位相关文档，PageIndex 做单份深度提取。

何时选择 PageIndex

适合：长篇幅结构化专业文档、准确率优先、需要审计追踪、多步推理查询

不适合：亚秒级高并发、大规模短文档库、90% 准确率够用、成本敏感

参考链接：GitHub · 官方文档 · API 平台