相似不等于相关：无向量 RAG 正在把检索交还给推理

2026-09-30T09:20:00+08:00 | 8分钟阅读 | 更新于 2026-09-30T09:20:00+08:00

@ William Yi

假设你给一个 RAG 系统丢进两份真实年报，然后问：2024 财年营业利润率的同比变化是多少，主要由什么驱动？

正确答案在第 47 页的一张表里，措辞是「net sales decreased by $2.1M」这种和你的提问几乎没有字面重合的句子。而系统返回的是 60 个提到「operating income」的段落，字面高度相似，一个都不含答案。

这不是段子。过去两年所有做过长文档问答的团队，几乎都撞过同一堵墙，而且撞完之后发现调 chunk size、换 embedding 模型、加 reranker 都只能小幅挪动，问题始终在那里。2026 年，有人选择从侧面绕过去，把向量数据库整个拆掉。

今天 PageIndex 冲上 GitHub 趋势 Python 榜第三名（835 stars/日，累计 3.5 万），值得把这条路线讲清楚：它凭什么、代价是什么、以及什么时候你不该用。

一、向量 RAG 的三条失效路径

先复盘标准流水线：把文档切成 300 到 500 token 的分块，逐块嵌入成稠密向量，存进向量库，查询时把问题也嵌入，取余弦距离最近的 top-k 塞进上下文让模型作答。这套流程对短文本、泛化问答、语义搜索非常好用，但一到长、结构化、专业文档上就崩，而且是结构性的崩。

第一条：分块把文档结构切碎。 财报表格有表头行、子表头、数据行、脚注，彼此是有关联的。固定长度分块会从中间切过去，表头落到第 14 块，你要的数据行落在第 15 块，两块单独都答不了问题，而检索系统没有机制理解它们本该在一起。

第二条：相似不等于相关。 一份 200 页年报里「operating income」可能出现 60 次。向量相似度把这 60 处按与提问的嵌入距离排序，它并不理解哪一处才是逻辑上承载答案的那一处。检索系统找的是措辞最像你问题的段落，不是包含答案的段落。在精度敏感的场景里，这两者经常不是同一个东西。

第三条：交叉引用失明。 真实文档布满内部引用。第 12 页写「see Appendix B for the complete methodology」，附录 B 在第 87 页。向量检索对「文档级引用」没有任何概念，因为这个引用和它的目标根本不在同一个块里，也没有结构联系。

还有两个不那么显眼但同样致命的问题。一是向量空间的几何特性：稠密嵌入存在各向异性，语义相似度会挤在一个窄锥里，导致「vendor onboarding approval」和「vendor offboarding approval」的余弦距离近到几乎重合，同族 reranker 还会继承这个偏差。二是每轮查询独立嵌入，检索器不知道前面问过什么答过什么，多轮文档分析因此格外别扭。

这些问题的共同点是：它们都不是调参问题，而是把文档当「一袋文本片段」这个前提带来的后果。

二、把目录树当成索引

VectifyAI 的 PageIndex（MIT 协议）提出的替代方案很利落：不要向量索引，用一棵树索引。

流水线只有两个阶段：

索引期：LLM 通读整份文档，产出一棵分层目录树。每个节点带标题、一段摘要、一个页码范围，以及指向子节点的指针。没有 chunk，没有 embedding，没有向量库，树的存储形式就是 JSON。
查询期：LLM 在这棵树上做搜索。它读节点摘要，判断哪个分支可能承载答案，逐层下降，直到定位到真正相关的章节，然后只取那几节的正文。返回的不再是匿名文本片段，而是页码和章节级引用。

最值得琢磨的设计细节是作者称之为 in-context index 的东西。向量库存的是一个外部的、静态的索引，模型只能拿到检索结果；而 JSON 目录树活在模型的推理上下文里，模型可以直接读它、导航它、对它推理。索引从「前置计算好的相似度表」变成了「推理过程中可操作的结构」。

这个思路的灵感来自 AlphaGo：不做穷举搜索，而是用一个学到的策略在网络里聪明地走。对应到文档上，就是放弃对每一块测量相似度，改为理解文档结构并直接推理出该读哪一节。框架在 2025 年 9 月发布，作者是 Mingtian Zhang 和 Yu Tang。

三、98.7% 这个数字值多少

PageIndex 最有冲击力的是 FinanceBench 上的成绩。这个基准用的是真实 SEC 文件（10-K、10-Q、8-K），要求精确数字、多步推理和跨章节引用，是生产级检索里最难的评测之一。

方案	FinanceBench 准确率
单一向量索引覆盖全部文档	约 30%
每份文档独立建向量索引	约 50%
GPT-4o 直接作答（无检索）	约 31%
Perplexity	约 45%
Mafin 2.5（基于 PageIndex）	98.7%

从 50% 到 98.7%，这不是量变。作者给出的解释集中在三个机制上：能跟随文档内引用（看到「see Appendix A」就去找那个节点）、结构保留（表格的表头、脚注、单元格关系作为章节留在树里而不是被切碎）、多跳推理（需要两个章节的数字再算一次的问题，能分别导航到两处）。

但跨行业的企业侧对照实验可能更有参考价值。一个 5.8 万份政策文档的语料（平均 40 页，覆盖九个受监管业务域，带版本、生效日期、被替代链这类权威语义）迁移前，团队并行跑了三周影子模式，抽样 1800 条真实查询由领域专家按准确性、grounding、版本正确性打分：

单跳问题：向量方案与无向量方案打平，都在 82% 左右
多跳与跨章节问题：向量 51%，无向量 79%
版本污染率（引用了已废止版本）：从 14% 降到 1% 以下
「不用回读原文就敢照着做」的比例：从 34% 升到 81%

这个拆分比 98.7% 更能说明问题：简单查表向量仍然很强，真正被拉开的是多跳和引用跟随，而这恰好是企业真实问题的形态。信任度那一项也值得注意，检索的可审计性不是锦上添花，它直接决定用户敢不敢用结果。

四、代价：成本没有消失，只是搬了家

看到「没有向量数据库、没有嵌入、不需要额外基础设施」，很容易得出「这套更省」的结论。这个结论是错的，成本只是换了科目。

索引期的 LLM 调用。 树不是白建的，大约每个节点要一次 LLM 调用。有技术分析算过，一份 131 页的报告建树大约需要 137 次调用。另外，把真实 PDF 变成一棵干净的语义树至今仍是主要瓶颈，因为 PDF 本质上是坐标指令，不是语义文档。

查询期的串行调用。 500 页文档的树搜索可能要 5 到 15 次串行 LLM 调用，而向量检索只是一次余弦距离计算。延迟的地板被整体抬高了，秒级以上是常态。

跨文档会退化。 无向量方案在单份结构化文档上最强，语料一旦放大到几万份异构 PDF，向量检索的召回更稳也更便宜。多份公开对比显示，多文档任务上向量方案的覆盖率优势可达约 40%。这个边界比很多人想象的低。

工程成熟度。 开源实现目前偏研究级：测试覆盖有限、处于 beta、缺企业级安全特性。真要上生产，要么用托管服务，要么自己补齐，这已经从「装个开源库」变成了供应商决策。

评测和观测要重写。 现有观测栈、评测框架（Ragas 之类）都是围绕向量流水线长出来的。换成树搜索，你需要的是能理解 tree-search trace 的评测器，而不是看 retrieval score。这是实打实的工程量。

一句话总结这笔账：把固定成本（向量库、嵌入用 GPU、ANN 索引、索引重建）换成了变动成本（建树调用 + 每次查询的多次推理调用）。对高频更新或高请求量的场景，变动成本会迅速反超。要不要换，应该按「每请求成本 + 索引成本 + 更新频率」在预期生命周期上算总账，而不是在演示日算。

五、为什么这个交易现在才划算

无向量检索的内核是一笔交易：多烧几次 LLM 调用，换更准的检索。这笔交易成不成立，几乎完全取决于 token 价格。

当便宜的前沿模型把输入价格压到每百万 token 十几美分这个量级时，多跑 5 到 15 次导航调用的开销，已经低于维护一套向量基础设施的固定成本与运维负担。推理越便宜，「用推理换检索精度」就越成立。反过来，如果推理价格回到 2024 年的水平，这个方案在很多场景下根本算不过账。

同一个逻辑也解释了为什么今年检索领域的讨论整体转向 agentic retrieval。不是因为向量错了，而是因为推理变便宜之后，被向量化预处理丢掉的文档结构信息，终于值回票价了。

六、怎么选：一张判断表

把无向量 RAG 当通用替代品是最常见的误用。按工作负载拆开看，边界其实很清楚：

维度	选无向量（树导航）	选向量检索
文档数量	少而长（1 到 100 份）	多而杂（千份以上）
文档结构	层级清晰（目录、条款、法规）	扁平或非结构化（聊天、笔记、网页）
查询类型	多跳推理、跟随文档内引用	单跳事实查找
延迟预算	秒级可接受，精度优先	要求亚秒级
引用要求	需要页码/章节可审计	尽力归因即可
典型领域	金融、法律、合规、医疗	客服、搜索、泛化问答

还有一类容易混淆的技术要澄清：SPLADE 这类学习稀疏表示、ColBERT 这类后期交互，本质仍然存储和计算向量，只是藏在更好听的名字后面。它们属于混合检索的重排泳道，有价值，但不算无向量。

七、我的判断：RAG 没死，只是变长了

把两条路线对立起来是个错误的框架。真正能打的架构通常是分层的：

第一跳，在语料级做高召回，把候选从几万份缩到几份。这一步用向量、BM25、知识图谱或者直接查 SQL 都行，关键是快且便宜。

第二跳，在单份文档内做精读。树导航负责跟随交叉引用、锁定真正含答案的章节，并在多跳问题上把不同章节的证据拼起来。

第三跳，生成答案时带页码或章节引用，让结果可审计、可回溯。

LlamaIndex 把这种形态叫做 agentic retrieval。它对应的产业现实是：向量 RAG 不是在消失，而是在变成一条更长流水线的第一跳。

所以更准确的结论不是「RAG 已死」，而是 RAG 变长了。检索从一个静态的相似度计算，变成了一个需要推理、需要分层、也需要重新算钱的工程问题。对正在踩这个坑的团队来说，2026 年的正确答案大概率不是二选一，而是先把语料级的召回做扎实，再在真正需要精读的长文档上引入树导航。

小结

相似不等于相关，这是向量检索的根问题，调参解决不了
无向量 RAG 用文档结构加 LLM 推理替代相似度计算，在长结构化专业文档上把准确率从 50% 量级推到 98.7%
代价是推理成本、延迟抬高，以及跨文档场景的明显退化，成本结构从固定挪到了变动
真正的分水岭是 token 价格：推理越便宜，文档结构越值钱
实践上最稳的是混合架构，向量做召回第一跳，树导航做精读第二跳

参考来源

下一页 📊 GitHub 趋势日报 — 2026-09-30