老实讲，向量数据库可能被高估了。
过去一年，搞大模型应用的人都在信奉一条铁律：RAG（检索增强生成）必须得有向量数据库。把文档切片、算 Embedding、存向量库，最后根据语义相似度捞出来。
这套流程听起来无比丝滑，但在面对真正的“硬骨头”时，它经常掉链子。
最近，一个叫 PageIndex 的开源框架横空出世，它在 FinanceBench 测试中拿下了 98.7% 的恐怖准确率。
更让人意外的是，它干了一件“离经叛道”的事：彻底抛弃了标准的“切片-嵌入”模式。
向量检索的“虚假繁荣”
先别急着反驳，我们来看看传统的 RAG 在干什么。
当你问一个关于“EBITDA”（税息折旧及摊销前利润）的问题时，向量数据库是怎么工作的？
它像个不知疲倦的搬运工，把文档里所有提到“EBITDA”的片段都搬到你面前。因为在语义相似度上，这些词长得太像了。
但这有个巨大的 Bug：用户要的不是“词”，是“逻辑”。
"Multiple sections may mention EBITDA with similar wording, yet only one section defines the precise calculation, adjustments, or reporting scope relevant to the question."
PageIndex 的联合创始人 Mingtian Zhang 举的这个例子很扎心。
财务报表里可能有十个地方提到 EBITDA，但只有一处定义了该季度的具体计算口径。向量检索傻眼了，它分不清哪个才是你真正想要的“意图”。
这就是 “意图 vs. 内容”的鸿沟。
传统的 Embedding 还有一个硬伤：它是有“失忆症”的。
为了迁就模型输入长度的限制，检索系统往往只能看到你当前问的那句话，把你之前的对话上下文扔在一边。
系统拿着一个被剥离了语境的短问题，去茫茫数据海里瞎蒙，这能准吗？
像 AlphaGo 一样去读文档
PageIndex 的思路非常清奇，它甚至不想把这件事当成“搜索”来做。
它把文档检索看成了一个 “导航”问题。
想象一下，人类是怎么在一本厚得像砖头的年度报告里找信息的？我们会从第一页读到最后一页吗？绝对不会。
我们会先看目录，找到章节，再看小节，最后翻到那一页。
PageIndex 强迫 LLM 模仿这种人类行为。它不再预先计算那些冷冰冰的向量，而是建立了一个 “全局索引”。
这就像是一棵树，节点代表章节、段落。当问题抛过来，LLM 不再去“匹配”，而是开始“爬树”。
"In computer science terms, a table of contents is a tree-structured representation of a document, and navigating it corresponds to tree search."
Zhang 说得很直白，这其实就是 AlphaGo 下棋的那套逻辑，只不过对手不是李世石，而是复杂的文档。
这种从“被动检索”到“主动导航”的范式转变，才是它准确率飙升的关键。
真正的杀手锏：多跳推理
光说不练假把式，来看看实战。
在 FinanceBench 的测试里，基于 PageIndex 构建的“Mafin 2.5”系统拿下了 98.7% 的分数。这不仅仅是数字游戏，它解决了一个传统向量检索根本搞不定的问题：多跳推理。
举个具体的例子。
假设你问美联储年报里一个关于“递延资产总价值”的问题。
报告正文里可能只描述了价值的“变化”，并没有列出总数。但在正文角落里有一行小字：“详见本报告附录 G……”
这时候，传统向量检索直接歇菜。
为什么？因为附录 G 里可能只有一堆枯燥的数字表格，从语义上看，它和你的问题“递延资产”八竿子打不着。没有语义匹配，向量库就会直接忽略它。
但 PageIndex 这种基于推理的检索器，能读懂那句“详见附录 G”。
它会顺着结构线索，一路摸到附录 G，找到那张表，然后把准确数字给你报上来。
这不仅是找数据，这是在“读”文档。
扔掉向量数据库？
听到这儿，架构师们可能要皱眉头了：让 LLM 去读目录、爬树，这延迟不得爆炸？
这确实是个好问题。向量检索通常只需要几毫秒，而让 LLM 思考可是要花时间的。
但 PageIndex 给出了一个很有意思的解法：流式传输。
在传统 RAG 里，检索是个“阻断”步骤，必须先搜完，才能开始生成答案。
但在 PageIndex 的架构里，检索是内联在推理过程中的。
"The system can start streaming immediately, and retrieve as it generates."
这意味着，首字生成时间（TTFT）和普通 LLM 调用几乎没区别。你在看它输出第一句话的时候，它可能还在后台疯狂翻目录。
更有意思的是，这种架构甚至简化了你的基础设施。
既然不用算 Embedding，那还要什么向量数据库？
PageIndex 的树形索引非常轻量，直接扔进 PostgreSQL 这种传统关系型数据库里就完事了。
这解决了一个大痛点：数据同步。
以前文档改了一个字，你可能得重新处理整个向量库。现在？只更新受影响的那根“树枝”就行。
并不是万能药，但方向变了
当然，我也得泼盆冷水。PageIndex 不是要革掉所有向量数据库的命。
对于那些短文档，比如邮件、聊天记录，或者纯粹找“感觉”的推荐任务（比如“给我找个类似风格的文章”），向量检索依然是王道。
PageIndex 搞定的是那些“深水区”的活儿。
比如长篇的法律合同、复杂的药企协议、需要严格审计的财务报表。在这些场景下，错误的代价是高昂的。
企业不仅需要答案，还需要 “路径”。
它必须能解释：“我看了 4.1 章节，顺着链接去了附录 B，最后综合算出来的。”
这种可解释性，是向量检索给不了的。
PageIndex 的崛起，其实揭示了一个更大的趋势：智能体 RAG（Agentic RAG）。
我们在代码领域已经看到了苗头，像 Claude Code、Cursor 这些工具，早就开始放弃简单的向量查找，转而让 AI 主动去探索代码库。
Zhang 的判断很犀利：向量数据库依然有用，但它们作为 LLM 默认数据库的历史地位，恐怕要动摇了。
数据库正在变“笨”，模型正在变“聪明”，这或许才是 AI 检索的未来。
参考链接：
https://venturebeat.com/infrastructure/this-tree-search-framework-hits-98-7-on-documents-where-vector-search-fails