想要让大模型准确回答长文档里的问题,过去几乎离不开向量数据库。VectifyAI 开源的 PageIndex 直接绕开了这条路——它不用向量数据库、也不用把文档切块,而是先把文档建成一棵「目录树」,再让大模型像人翻书一样顺着树找答案。这个 MIT 许可的项目在 GitHub 已收获约 35.5k stars,在金融文档问答基准 FinanceBench 上达到 98.7% 的准确率,而且每个答案都能指回原文的具体位置。
它适合谁用?做文档问答、给智能体接检索能力、以及经常要处理财报、法律文书、技术手册这类长文档的开发者,都可以直接用。
传统做法在哪一步出了问题
先解释两个词。RAG(Retrieval-Augmented Generation,检索增强生成)是一种让大模型「先查资料、再回答」的技术:模型不凭记忆硬答,而是先从文档里检索相关片段,把片段塞进提示词再生成答案,能显著减少编造。向量数据库则是按「语义相似度」存储和查找文本的数据库:把文档切成小块、转成向量,提问时找语义最接近的块。
这套流程有两个公认的弱点。
一是「相似不等于相关」。向量检索找的是语义长得像的段落,但长文档里的答案往往表述和问题不一样——比如问「2023 年营业利润率」,文档里写的是「2023 年扣除所有成本后,每赚 100 元留下 18 元」,语义上相关,字面上不像,很容易漏掉。
二是分块会切断上下文。文档被切成固定大小的块后,一个结论和支撑它的数据可能被切到两个块里,模型只看得到其中一块,自然答不准;块切得越大,向量检索的精度越低,这是个两难。
PageIndex 的做法:先建树,再推理
PageIndex 把检索拆成两步,思路来自围棋 AI AlphaGo——不靠暴力搜索,靠结构和推理。
第一步是建索引:给每个文档生成一个树状结构,相当于一本书的详细目录,按文档自身的层级关系组织。关键在成本控制:树的结构是从 PDF 版面信息里启发式提取的,不靠大模型生成,索引模型只需要做总结和润色,所以用便宜的模型就够。
第二步是检索:让大模型在树上「推理」着找,像人拿到一本厚报告先翻目录、再翻到对应章节精读一样,一步步缩小范围,直到定位到相关章节。因为模型读的是自然章节而不是碎块,上下文完整;每步走到哪、引用了哪一节,都有迹可循。
成本数字说明问题
按官方公布的数据,本地建索引约为每页 0.001 美元(约合人民币不到一分钱),一份 1000 页的教科书建一次树,成本一美元出头、耗时几分钟,之后所有提问都复用这棵树。实测 9 到 1098 页的文档,建树耗时约 13 秒到 4.5 分钟。
查询阶段的对比更直观:把整份 PDF 直接塞给模型(不检索)在 52 页文档上成本是 PageIndex 的 2.1 倍,420 页时是 16.6 倍,到 805 页时文档已经超出模型的上下文窗口——根本塞不进去。检索方案的成本几乎不随文档长度增长,因为模型只读它推理路径上经过的节点。
评测结果
在 FinanceBench(金融文档问答的公开基准,共 62 道查找题、34 份 PDF、1945 页)上,PageIndex 达到 98.7% 的准确率,官方称显著超过向量 RAG 方案,评测脚本和数据都开源在单独的 benchmark 仓库里,可以自己复现。
怎么上手
安装和调用都很简单:pip install -U pageindex,之后用 Python 客户端提交文档、提问即可。两种用法:本地模式,用自己的大模型 API key,索引和存储都在自己机器上;或者用 PageIndex Cloud,把解析、OCR、建索引交给云服务,检索层仍可接自己选的大模型。它还提供 SDK,可以当作工具直接接入 OpenAI Agents SDK 或 Claude Agent SDK,给智能体加文档检索能力。
一个带得走的结论
对长文档、专业文档的问答场景,树状索引加模型推理已经是一条被验证的替代路线:检索结果可溯源、成本随文档长度增长缓慢、不需要维护向量数据库。它同样有自己的前提——每次检索都要调用一次大模型做推理,推理质量直接决定检索质量,所以更适合「要把问题答准」的场景,而不是毫秒级海量检索。如果你正在为财报、合同、技术文档做问答或智能体,值得把 PageIndex 作为向量方案之外的第二条路试试。