RAG 的去向量化浪潮：向量索引正在被三路夹击

为什么值得关注

过去两年，“RAG = Embedding + 向量数据库"几乎是默认架构。到了 2026 年 9 月，这个等式正在被三个方向同时松动：

• graphify（Graphify-Labs，Apache-2.0，GitHub 119,800 stars，2026 年 4 月创建，5 个月冲到 12 万星）把"代码库变成可查询知识图谱”，核心卖点明确写着 no vector store；
• LEANN 拿下 MLSys 2026 Best Paper，用"不存向量、查询时重算 embedding"把索引体积压到原始数据的 5% 以下；
• PageIndex（35,771 stars）直接自我定位为 Vectorless, Reasoning-based RAG——不用向量库、不做分块，让 LLM 在层级树索引上推理式检索。

三个项目动机不同（成本/存储/精度），却在做同一件事：把向量数据库从 RAG 架构的必选项变成可选项。这不是某个项目的营销话术，而是三个独立证据源指向的同一趋势。对正在选型 RAG 技术栈的团队，现在值得重新审视"向量库是不是第一块要搭的积木"。

需要先划清边界：本文讨论的是"去向量化"这一架构路线之争，不是宣告向量数据库死亡。Milvus（46,161 stars）等向量库在传统语义检索场景依然是事实标准；“向量已死"和"向量万能"一样，都是过度简化。

问题定义：向量索引的三笔账

理解这波浪潮，先把向量索引的真实成本算清楚。传统 RAG 管线是：文档分块 → 每块算 embedding → 存入向量索引（HNSW 等）→ 查询时向量近邻搜索取 top-k。

第一笔账：存储放大。 LEANN 论文（arXiv:2506.08276）给了一组硬数字：76GB 文本语料，HNSW 索引要 188GB——其中向量本体 173GB、索引元数据 15GB，索引比原始数据大 2.5 倍。分块后的每条 1KB 文本，配上 768 维 float 向量加邻居表，膨胀是结构性的。这也是为什么向量检索一直难以下沉到端侧设备。

第二笔账：语义相似 ≠ 语义相关。 PageIndex 的立论直接戳这个点：向量检索按相似度召回，但"相似≠相关”——它漏掉"相关但不相似"的内容（比如问"这份财报里哪些风险因素互相冲突"，答案分散在文档不同章节，字面毫不相似），又召回"相似但不相关"的噪声。在金融报告、法律文书这类需要上下文推理的专业文档上，这个缺陷被放大。

第三笔账：黑盒性。 向量召回的结果无法解释"为什么是这条"——PageIndex 称之为 “vibe retrieval”（凭感觉的检索）。对需要引用溯源的合规场景，这是硬伤。

三条路线，正是分别对着这三笔账下刀。

路线一：树索引 + 推理式检索（PageIndex）

思路：不做向量、不做分块，为每份文档生成层级树索引（类似书的目录，多层可下钻），检索时让 LLM 像人类专家翻报告一样，在树上逐层推理、走向正确的章节。

关键数据（来自官方 benchmark，快照时点 2026-09-20）：

本质是用 LLM 推理换向量相似度：树索引是确定性的结构先验，推理路径可追溯（翻到哪一章、跳过哪一节都有记录），天然带页级引用。代价是每次检索都在消耗推理 token——查询成本与"模型读到哪里"挂钩，高频查询场景需要算这笔账。官方的对照是"整本 PDF 塞给模型"，PageIndex 大幅胜出；但没有给出与"向量召回 + 重排"这类成熟混合管线的正面对比，选型时要补这个对照。

适用边界：长而复杂的专业文档（财报/法规/手册/医学文献），文档数量相对少、单文档深读场景。它的 File System 层正在把能力扩到百万级文档，但成熟度待观察（待核实：大规模语料下的树索引维护成本与推理深度）。

路线二：不存向量，查询时重算（LEANN）

思路：来自 MLSys 2026 Best Paper（作者团队含 Ion Stoica、Matei Zaharia、Joseph Gonzalez 等伯克利系研究者）。核心洞察是：HNSW 这类邻近图索引每次查询实际只访问全部 embedding 的一小部分——既然查不到全量，为什么存全量？ LEANN 查询时用同一 encoder 现场重算 embedding，只存压缩后的粗粒度 PQ 向量 + 剪枝后的图结构。

关键数据（论文 Table 1，76GB 语料 + RTX 4090）：

4GB vs 188GB 是 47 倍压缩，精度不丢，代价是检索延迟从 0.05s 涨到 2.48s——但端到端只贵约 10%，因为生成阶段（20s+）本来就 dominates。这就是 LEANN 的赌注：用检索延迟换存储，在生成占大头的世界里这笔交易划算。

适用边界：存储受限场景的刚需——端侧/个人设备私有 RAG（LEANN 的 explicit 目标）、超大语料库、多租户场景每个租户一套索引的成本爆炸问题。不适用：要求毫秒级检索的在线服务（2.48s 的检索延迟不能接受）。

路线三：确定性 AST 知识图谱（graphify）

思路：把代码库（含文档、SQL schema、配置）解析成知识图谱。关键区分度在于代码部分零 LLM：tree-sitter AST 确定性解析约 40 种语言，提取 calls/imports/inherits/mixes_in 跨文件边，每条边标注 EXTRACTED（源码显式存在）或 INFERRED（推断得到），Leiden 算法做社区检测（基于图拓扑，无 embedding 参与聚类）。只有 docs/PDF/视频等非代码资产的语义 pass 才调 LLM。

关键数据（官方 README，快照时点 2026-09-20）：

• 混合语料（代码+论文+图片）上，单次查询 token 消耗比直接读原始文件少 71.5 倍；
• LOCOMO（n=300）QA 准确率 45.3%（对照 supermemory 49.7%、mem0 27.3%）；
• LongMemEval-S（n=50）QA 准确率 76%，与 dense RAG 持平；
• 图构建零 LLM 成本（代码部分），SHA256 缓存增量更新，--watch 模式保存即重建（AST 层无 LLM）。

本质是用"结构确定性"换"语义泛化"：调用关系、继承关系是 AST 能精确回答的，但"哪段代码实现了这个业务需求"这种语义问题，图谱天然答不好——官方数据也诚实：LOCOMO 上 45.3% 落后 supermemory。它的真正价值是把"AI 助手理解代码库"从每次全量读文件（贵且无结构）升级为查图谱（便宜且有跨文件导航能力），5 个月 12 万星说明这个痛点足够普遍。

适用边界：代码库/技术资产的结构化理解，配合 Claude Code 等编码智能体使用。不适合通用语料问答。

三条路线的共性：重新分配"贵"的东西

把三条路线放在一起看，真正的信号不是"向量库要死了"，而是成本结构正在被重新设计：

共同哲学：向量索引把"贵"前置到存储（embed 一遍全存着），三条路线各自把它挪到了别处——挪到查询时（LEANN 重算）、挪到推理时（PageIndex 树上推理）、挪到构建时（graphify AST 解析）。这与数据库领域"物化视图 vs 即时计算"的取舍完全同构，是经典的存储-计算权衡在新场景的重演。

另一个共性是可解释性都在变好：树索引的推理路径、图谱的 EXTRACTED/INFERRED 边标注、LEANN 保持的精确近邻语义，都比"黑盒相似度"更容易审计——这对 RAG 走进受监管行业是隐性但关键的收益。

工程建议：怎么判断自己该不该动

不是所有场景都该抛弃向量库。给一个决策框架：

继续用向量库的场景：查询模式是"语义相似召回"本身（推荐系统、去重、聚类）；语料通用非结构化；需要毫秒级检索延迟的在线服务；团队已有成熟向量运维经验。这些场景向量库依然是最优解，LEANN 这类存储优化方案也兼容（它本质仍是向量检索，只是索引形式变了）。

值得评估树索引/推理式检索的场景：单文档深读型问答（财报/合同/手册），输出需要页级引用溯源，“相关但不相似"型问题占比高。PageIndex 的自建 benchmark 覆盖了这类场景，但接入前建议用自己的文档跑一遍对照（它有 local 模式可以离线试）。

值得评估重计算索引的场景：端侧/嵌入式 RAG、个人设备私有知识库、每租户独立索引的 SaaS、语料大到向量存储成本成为主要开支。LEANN 论文的实验平台包含 M1 Mac，端侧路径是真实验证过的。

值得评估知识图谱的场景：核心语料是代码或强结构化资产，消费方是编码智能体。graphify 作为 skill 直接挂在 Claude Code/Cursor/Codex/Gemini CLI 里用，试错成本最低——一个下午就能在自己仓库上跑出对比感受。

三条通用建议：①任何"去向量"方案迁移前，先在自己语料上跑 A/B（检索质量对比向量基线，别只看官方 benchmark）；②注意索引构建成本与更新频率的匹配（graphify 的 SHA256 增量缓存设计值得抄，--watch 保存即重建只动 AST 层）；③向量库不必急着下线——混合架构（向量召回粗筛 + 树/图精读）在多个路线的官方对照里都是未被正面击败的基线。

常见误区

误区一：把"去向量化"读成"向量数据库已死”。 三条路线解决的是向量索引的三笔账（推理相关性/存储放大/结构理解），不是全盘否定语义检索。LEANN 本身还是向量检索，只是不存全量向量；Milvus 在通用场景的地位没有被这波浪潮动摇。

误区二：拿官方 benchmark 直接当家珍。 PageIndex 的 98.7% 是 FinanceBench（金融文档 QA），graphify 的 45.3% 是 LOCOMO（长对话记忆）——两者测试集完全不同，数字不能互相比较，更不能线性外推到自己的语料。所有迁移决策都应该以自有语料的 A/B 为准。

误区三：忽视延迟代价只看存储收益。 LEANN 检索 2.48s 在生成占主导的 RAG 端到端里可接受，但如果你做的是搜索框联想、实时推荐，这就是事故级延迟。读任何"X 倍压缩/X 倍省钱"的数字，先看它用什么换的。

误区四：以为树索引/图谱不需要维护。 graphify 的价值一半在图构建、一半在 SHA256 缓存的增量更新——如果你的语料高频变更而工具没有增量机制，重建成本会吃掉全部收益。

总结

2026 年 9 月的 RAG 生态出现了一个清晰信号：三个独立项目（119,800 星的 graphify、MLSys 2026 Best Paper 的 LEANN、35,771 星的 PageIndex）从成本、存储、精度三个不同动机出发，都在把向量数据库从必选项降级为可选项。它们的共同哲学是把"贵"从存储重新分配到查询时、推理时或构建时，顺带把可解释性做成了标配。

对开发者，这不是站队问题而是工具箱扩容：向量库仍是语义召回的默认解，树索引补推理型检索，重计算索引解端侧存储，知识图谱解代码理解。选型时先算清楚自己的三笔账——查询模式、存储预算、延迟容忍——再决定要不要动。

一句话记忆锚点：向量索引把"贵"存在磁盘上，新路线把"贵"挪到查询里——你的场景哪头便宜，就用哪头。

数据快照声明：本文 star 数与仓库状态核实于 2026-09-20（GitHub API live 查询）；LEANN 数据来自 arXiv:2506.08276 论文原文（MLSys 2026 Best Paper）；PageIndex/graphify benchmark 数据来自各自官方 README 与 benchmark 仓库，均为厂商自报口径，未独立复现。