RAG 系统的存储成本，可能大部分花在了那些“其实可以不存”的向量上。UC Berkeley 开源的 LEANN 给出的答案是：把 60M 块的索引从 201 GB 压到 6 GB。

发生了什么

LEANN 是一个开源的向量索引方案，核心思路是“不存全量向量”。它只保存一张经过剪枝的近邻图，查询时再按需重新计算嵌入，而不是从磁盘读取预先算好的向量。

据 MarkTechPost 报道，在 90% 召回率这一档，LEANN 用约 4 GB 就达到了 HNSW 需要约 188 GB 才能实现的精度；对应到 60M 块的 RAG 索引，整体规模从 201 GB 降到 6 GB。代价同样明确：检索延迟从毫秒级上升到秒级。

为什么重要

向量数据库过去几年的默认假设是“用空间换时间”：把嵌入全部落盘或常驻内存，换取毫秒级近邻检索。这个假设在百万级规模下成立，但 RAG 的语料一旦涨到千万、上亿块，索引体积就会成为比模型本身更重的负担——它决定了你能不能在一台普通机器上跑起来，也决定了云上存储和内存账单的量级。

LEANN 走的是相反的方向：用计算换空间。剪枝图保留了拓扑结构，嵌入在查询时现算，因此省掉了绝大部分存储。这在工程上并非全新思想，但把它做成可直接替换的索引、并给出与 HNSW 可比的召回数据，让它具备了实际落地价值。

影响与看点

对开发者而言，最直接的变化是个人设备或单机部署大型 RAG 变得可行：原本需要多台高内存机器扛住的索引，现在可能落在一个量级小得多的存储预算里。对成本敏感的团队，这意味着检索层的支出结构从“内存/存储为主”转向“算力为主”，而算力可以按查询量弹性伸缩，存储却不能。

需要冷静看待的是秒级延迟。它适合离线问答、批量分析、个人知识库这类对响应不敏感的场景；实时对话、高并发在线检索仍会倾向 HNSW 一类方案。真正的看点在于混合策略——热数据用传统索引，冷数据用 LEANN 这类重算索引，按访问频率分层。

一个独立判断：向量检索的竞争焦点正在从“召回率小数点后的比拼”转向“单位召回的成本”，LEANN 是这个转向的一个清晰信号。