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

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

这个数字本身已经够震撼了。更震撼的是它背后的技术路线：没有向量数据库，没有文档分块，没有 embedding 模型。PageIndex 用 LLM 推理替代了向量搜索，用树状结构替代了 chunk，用"像人一样翻文档"替代了余弦相似度。

这是一个由 VectifyAI 团队在 2025 年 9 月推出的开源项目，灵感来自 AlphaGo 的树搜索策略。GitHub 上已经收获了超过 23,000 颗 Star。它不是对传统 RAG 的修补，而是对检索范式的重新定义。

向量 RAG 到底哪里不行？

如果你搭过 RAG 系统，对以下场景不会陌生。

用户问："2024 财年总净收入与 2023 年相比如何变化？"你的向量管线执行标准流程：把 200 页年报切成 500 token 的 chunk，做 embedding，存进向量数据库，查询时取 top-k 相似 chunk，喂给 LLM 生成答案。

短文档、非结构化内容，这套流程跑得很好。但面对专业长文档，它有五个结构性缺陷。

查询文本不像答案文本。向量检索假设与查询语义最相似的文本就是最相关的。但查询表达的是意图，不是内容。问"收入趋势"，被召回的是每一段"谈到收入"的文字，而不是第 47 页那个具体的表格行。

同一个词出现 60 次。在一份 200 页年报中，"营业利润"这个词出现在数十个不同上下文中。向量相似度给它们的排名几乎一样。真正回答问题的那个，可能永远进不了 top-3。

分块切碎了表格。表格的标题在 chunk 14，用户需要的数据行在 chunk 15。单独看任何一个 chunk 都毫无意义。

跨页引用完全丢失。第 12 页写着"详见附录 G"，附录 G 在第 87 页。附录里的文本与原始查询之间没有任何语义相似性。向量 RAG 永远不会跟随这个引用。

多轮对话没有记忆。用户上一条问了资产，这一条问"负债呢？"检索器把它当全新查询处理，不知道用户大概率要的是同一份报告的同一章节。

这些不是边界情况，而是向量检索范式的结构性缺陷。PageIndex 的创始人 Mingtian Zhang 说得很直接：检索真正需要的是相关性，而相关性需要推理。

核心架构：两步走，向量和分块都不要

PageIndex 的设计思路极其简洁。不搜索向量空间，而是让 LLM 像人类专家一样"看目录、找章节、读内容"。

整个系统分两步。

第一步：构建层次树索引

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

一份 50 页的 SEC 文件可能生成 30 到 50 个节点的树。整棵树是一个 JSON 对象，不存向量数据库，就在 LLM 的上下文窗口里。

{ "node_id": "0006", "title": "Financial Stability", "start_index": 21, "end_index": 22, "summary": "Covers the Federal Reserve's financial stability oversight...", "sub_nodes": [ { "node_id": "0007", "title": "Monitoring Vulnerabilities", "start_index": 22, "end_index": 28 } ]}

这里有一个关键的架构洞察：传统向量数据库在模型外部维护一个独立的静态索引，而 PageIndex 的 JSON 树在推理时驻留在 LLM 的上下文中。VectifyAI 称之为上下文内索引（in-context index）。模型不是在查询一个外部系统，而是在实时推理一个结构化文档地图。

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

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

LLM 读取节点标题和摘要，推理哪些章节可能包含答案，返回节点 ID 列表。系统再根据 ID 获取对应页面的原始内容。

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

这跟向量搜索是截然不同的范式。向量数据库对所有 chunk 并行计算余弦相似度，快但蠢。PageIndex 让 LLM思考答案在哪里。模型能跟随交叉引用（“详见附录 G”），识别多步推理需要跨两个章节取数据，每一步都留下推理痕迹。

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

树索引的质量决定整个系统的上限。PageIndex 深知这一点，因此在目录（TOC）提取环节设计了三层自修正机制。

从代码层面看，这是一条精心设计的 fallback 链，在page_index.py的meta_processor()函数中实现。

路径 A：有页码的 TOC

最理想的情况。PDF 有完整目录且带页码。PageIndex 提取 TOC 内容，转换为 JSON 结构，从页码推断物理页面偏移，然后验证准确性。

验证过程采用并发抽检：随机选取若干 TOC 条目，用 LLM 检查标题是否真的出现在指定页面。准确率 100% 直接通过，高于 60% 进入修正流程。

修正时会定位错误项前后的正确条目，缩小搜索范围，用 LLM 重新定位页码。修正后再次验证。

路径 B：无页码的 TOC

PDF 有目录结构但没有页码。PageIndex 先提取 TOC 结构，然后通过文档内容匹配逐步推断每个条目的物理页码。

路径 C：无 TOC

PDF 没有目录，或者前两条路径都失败了。PageIndex 把文档按 token 限制分块，用 LLM 从零生成层次结构，最后合并为完整 TOC。

这三条路径形成降级链：A 失败跳 B，B 失败跳 C。代码中通过递归调用meta_processor()并切换mode参数实现。每次切换都意味着更多的 LLM 调用和更长的处理时间，但保证了在任何文档上都能产出可用的索引。

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

PageIndex 的代码库出奇地小。6 个核心 Python 文件，总共约 2900 行代码。没有 PyTorch，没有 FAISS，没有向量数据库依赖。核心依赖只有四个：LiteLLM（多模型接口）、PyMuPDF（PDF 解析）、tiktoken（token 计数）、PyYAML（配置）。

模块职责划分

设计模式

代码采用了Pipeline + Strategy + Template Method混合模式。Pipeline 体现在从 PDF 输入到最终索引输出的多阶段流水线；Strategy 体现在三种 TOC 处理策略的灵活切换；Template Method 体现在page_index_main()定义了整体处理模板，可选步骤（添加摘要、添加文本等）通过配置开关控制。

LLM 调用层面通过 LiteLLM 做了统一抽象。核心函数llm_completion()和llm_acompletion()封装了同步和异步两种调用方式，内置最多 10 次重试和错误日志。支持 OpenAI、Anthropic 以及 LiteLLM 兼容的 100+ 模型提供商。

数据流全景

从 PDF 输入到最终查询结果，经过 10 个阶段：

PDF 解析 → TOC 页面检测 → TOC 内容提取 → 三策略处理 → 验证与修正 → 树结构构建 → 增强（可选摘要/文本） → JSON 格式化输出 → 持久化存储 → 查询接口

每个阶段的输出都是下一个阶段的输入，数据格式从原始文本逐步演变为结构化 JSON。整个过程的核心创新在于：把文档结构信息作为一等公民，而不是像向量 RAG 那样把结构信息在分块过程中丢弃。

附录 G 的故事：一个说服人的真实案例

这个案例来自 VectifyAI 的真实演示，比任何数字都有说服力。

有人问美联储年报中"递延资产总额"是多少。年报正文（第 75-82 页）讨论了递延资产的变化，但从未给出总额。但第 77 页有一句话：“表 5.3 总结了收入、支出和分配……本报告附录 G 提供了更详细的信息。”

向量 RAG 在这里彻底卡住。附录 G 是一张数字表格，与"递延资产"查询之间没有任何语义相似性，向量数据库直接忽略它。

PageIndex 的处理方式不同。LLM 读取树结构，导航到金融章节，遇到指向附录 G 的交叉引用，通过树结构跟随引用，从附录中检索到相关表格，返回精确数字。每一步都有推理痕迹可查。

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

FinanceBench 数据全景

FinanceBench 是金融文档问答的行业标准基准，使用真实 SEC 文件（10-K、10-Q、8-K），要求精确答案，不充许含糊其辞。

PageIndex 对传统向量 RAG 的领先幅度接近 49 个百分点。驱动这个差距的三个因素：

交叉引用跟随——通过树结构导航文档内部引用，向量相似度完全没有这个概念。结构保持——金融表格的标题、脚注、单元格关系作为树节点原封不动保留，分块会把它们切碎。多步推理——需要从两个不同章节取数据的问题（比如对比 FY2023 和 FY2024 在报告不同部分的数据），在迭代循环中被自然处理。

诚实面对局限

PageIndex 的 98.7% 是真实的，但它只测了 FinanceBench 这一个基准。FinanceBench 测试的是结构良好的 SEC 文件上的金融问答。在杂乱、多领域、高度模糊的查询场景下，还没有同等程度的独立验证。

速度是另一个问题。每次检索涉及多轮 LLM 调用：读取索引、推理节点、获取内容、判断是否足够、可能循环。向量 RAG 毫秒级返回，PageIndex 需要数秒。成本也更高——多轮 LLM 推理 vs 单次 embedding 查询，高并发场景下的费用差距很大。

PageIndex 是深度工具，不是广度工具。它在单份长文档的深度提取上表现卓越。但如果你需要同时搜索 10,000 份短文档，为每份文档建树再逐个推理是不现实的。向量数据库在这种场景下仍然不可替代。

还有一个容易被忽视的风险：垃圾进，垃圾出。树索引的质量完全取决于文档自身的结构。有清晰标题的 SEC 文件能产出优秀的树。格式混乱的扫描 PDF 没有逻辑章节？TOC 会退化，下游一切跟着退化。

混合方案可能是最有实践价值的路线：用向量搜索快速从大规模文档库中定位相关文档，再把单份文档交给 PageIndex 做深度提取。两全其美。

最新进展

自 2025 年 9 月发布以来，PageIndex 迭代迅速。

Agentic Vectorless RAG——与 OpenAI Agents SDK 集成的完整示例。Agent 获得三个工具：get_document()、get_document_structure()、get_page_content()，自主推理树索引，调用正确的工具获取内容，无需手动选择节点。

视觉无向量 RAG——跳过 OCR，直接把 PDF 页面图像发送给视觉 LLM，从模型"看到"的内容构建树。对金融文档中的图表、合并单元格表格、脚注注解特别有效，因为视觉布局中的信息从不被转换损失。

TypeScript SDK——面向 Node.js 开发者的pageindex-js-sdk，2026 年初发布。

MCP 桌面扩展——.mcpb格式的一键安装包，双击即可将 PageIndex 安装为 Claude Desktop 扩展，OAuth 自动处理。

ChatIndex——将同样的树索引思想应用到长对话历史而非文档上。独立仓库，2026 年 1 月发布。

何时选择 PageIndex

适合的场景：长篇幅、结构化专业文档（年报、法律合同、监管文件、技术手册）；准确率比速度更重要的场合；查询需要多步推理或跨章节导航；需要审计追踪（每个答案都附带完整推理痕迹和节点引用）。

不适合的场景：需要亚秒级响应的高并发查询；大规模短文档库的搜索；非结构化或对话型文档；90% 准确率够用的场景；单次查询成本是主要约束。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】