在金融文档问答领域最权威的基准测试 FinanceBench 上一个开源项目交出了 98.7% 的准确率。排名第二的系统是 91%。传统向量 RAG30% 到 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 Reserves 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无页码的 TOCPDF 有目录结构但没有页码。PageIndex 先提取 TOC 结构然后通过文档内容匹配逐步推断每个条目的物理页码。路径 C无 TOCPDF 没有目录或者前两条路径都失败了。PageIndex 把文档按 token 限制分块用 LLM 从零生成层次结构最后合并为完整 TOC。这三条路径形成降级链A 失败跳 BB 失败跳 C。代码中通过递归调用meta_processor()并切换mode参数实现。每次切换都意味着更多的 LLM 调用和更长的处理时间但保证了在任何文档上都能产出可用的索引。代码架构2900 行 Python 的精简设计PageIndex 的代码库出奇地小。6 个核心 Python 文件总共约 2900 行代码。没有 PyTorch没有 FAISS没有向量数据库依赖。核心依赖只有四个LiteLLM多模型接口、PyMuPDFPDF 解析、tiktokentoken 计数、PyYAML配置。模块职责划分文件行数职责page_index.py1153PDF 树索引生成核心TOC 检测/提取/验证/修正utils.py710LLM 调用封装、JSON 处理、树操作、PDF 解析page_index_md.py341Markdown 文档的树索引生成client.py234高级 API 客户端、工作空间管理retrieve.py137文档检索接口run_pageindex.py~60CLI 入口设计模式代码采用了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要求精确答案不充许含糊其辞。系统准确率基准覆盖Mafin 2.5PageIndex98.7%100%Dewey Agentic RAG~91%部分开源标准 RAG~76%部分传统向量 RAG30-50%不定Perplexity~45%不定GPT-4o无 RAG~31%100%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-sdk2026 年初发布。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%免费】