LEANN 向量索引深度：188GB 压到 4GB 与 2.48 秒代价

一句话结论：加州大学伯克利分校 Sky Computing Lab 开源的向量索引 LEANN，用查询时重算嵌入加剪枝图结构的方式，把 76 GB 英文维基语料的 6000 万段落 RAG 索引从 HNSW 的 188 GB 压到 4 GB，下游问答准确率 25.5% 与未压缩的 HNSW 完全相同，代价是检索延迟从 0.05 秒涨到 2.48 秒，该论文拿到 MLSys 2026 最佳研究论文奖。

这项工作由 Yichuan Wang 与 Yongji Wu 领衔，作者名单里还有 Zhiying Xu、Yang Zhou，以及 Ion Stoica、Sewon Min、Matei Zaharia 等人，机构署名横跨 UC Berkeley、香港中文大学、亚马逊云科技与 UC Davis。论文编号 arXiv 2506.08276，最新版 v2 于 2025 年 11 月 25 日更新，代码以 MIT 协议放在 GitHub 的 StarTrail-org/LEANN 仓库，截至本轮发稿星标已超过 1.36 万。

这次 MLSys 2026 的最佳研究论文奖，是向量检索这条相对小众的工程线路上少见的系统性突破。它解决的是一个被长期回避的成本问题，索引本身比被索引的数据还大。

问题本身：索引比数据大一倍

论文从一组具体的数字切入。用 768 维 float32 嵌入给一份 76 GB 的英文维基快照做分段，6000 万个段落的稠密向量本身要占 173 GB，加上 HNSW 的图指针 15 GB，总体积落在 188 到 201 GB 之间，比原始语料本身还大出一倍。

这不是个别系统的实现问题。论文指出，现有近邻搜索方案的索引存储开销普遍可达原始数据规模的 2.5 倍。DiskANN 因为要对齐 4 KB 的 SSD 扇区做布局，每个节点的嵌入与邻居列表都要补齐到扇区边界，还需要额外 30 GB 存 PQ 嵌入，最终体积达到 270 GB，是所有对比方法里最大的。IVF 与 IVF-Disk 的开销同样由完整嵌入主导。PQ 压缩能把向量压到 5 GB，但需要约 35 倍的压缩比，这个比率下的量化误差足以让下游准确率掉到比 BM25 关键词检索还低的水平，而且它同样压缩不掉那 15 GB 的图索引。

这类开销直接决定了向量检索能不能落到个人设备上。在笔记本或工作站上跑语义检索，隐私与离线可用是主要动机，而设备存储容量往往装不下规模化的嵌入与索引。

解法：把向量存成图，查询时现算

LEANN 的核心思路是干脆不存稠密向量，改存剪枝后的图拓扑加一张轻量乘积量化查找表。查询时先用便宜的量化距离估计在图上导航，把得分最高的候选段落批量丢给 GPU 实时重算精确嵌入，用重算结果做最终判定。

这带来一个结构性差异，索引体积只跟图的边数有关，与向量维度无关。论文把它拆成三个关键机制。

第一是两级搜索。量化距离在压缩比很高时精度不够，但可以用来做剪枝，先用它排邻居顺序，只对排名靠前的候选做精确重算。消融实验显示，单这一项就把平均速度提升 1.4 倍，最高 1.6 倍。

第二是动态批处理。跨搜索跳数聚合嵌入计算请求，一次交给 GPU 处理，GPU 利用率上升后平均加速比推到 1.8 倍，峰值 2.0 倍。HotpotQA 这类多跳任务受益最明显，因为它的搜索路径更长，跨跳聚合的效果更好。

第三是保高阶剪枝。图索引里高阶的枢纽节点被访问频率远高于低阶节点，重要性也不同。LEANN 的剪枝只删低阶节点的冗余边，保留高阶枢纽节点的连接。这一项在消融实验里对比了两种基线，Random Prune 随机删掉一半边，Small M 在建图时限制出度让平均度从 18 降到 9，三种方法都把平均度减半的情况下，LEANN 的表现与未剪枝的原图相当，Random Prune 需要多算最多 1.8 倍的节点，Small M 需要多算最多 5.8 倍，而且 Small M 在 94% 与 96% 召回目标下直接达不到。

索引更新这条路径的优化幅度更大，加入缓存与批量追加机制后，相对朴素方法取得最高 63.3 倍的加速，与论文给出的理论分析一致。

精度与体积：四组方法同台

论文 Table 1 是全篇信息量最大的一张表。语料是 76 GB 的 RPJ-Wiki，问答数据集用 Natural Questions，生成模型是 Qwen3-4B，硬件是 RTX 4090。

准确率一列里 LEANN 与 HNSW 并列 25.5%，同为全场最高，比 BM25 的 18.3% 高出 7.2 个百分点。体积一列是 LEANN 与 HNSW 拉开差距的地方，4 GB 对 188 GB，接近 47 倍的差距。论文在四个数据集上给出的统一结论是，LEANN 相对常规索引能把体积压到原来的二十分之一以下，同时维持 SOTA 级别的准确率。

论文对不同方法的下游表现也做了量化。在 EM 指标上 LEANN 相对 BM25 最高提升 11.8%，相对 PQ 提升 11.3%，F1 最高提升 12.0% 与 11.1%。提升最明显的是 NQ 与 TriviaQA 这类事实型问答，语义检索在这里带来直接收益；在 GPQA 与 HotpotQA 上幅度较小，原因是这两类数据集分别依赖多跳推理与专业领域知识。

延迟代价：把检索慢 50 倍说清楚

体积省下来的时间从延迟里出。NQ 任务上检索 2.48 秒对 HNSW 的 0.05 秒，接近 50 倍差距。这笔账要放进端到端里看才公平，生成阶段占 20.86 秒，检索占比 10.6%，端到端从 20.95 秒涨到 23.34 秒，增幅约 11%。

论文给出的跨数据集检索延迟与流水线占比数据如下，检索延迟都在 90% 召回率下测得。

同属重算路线的 IVF-Recompute 提供了另一个对照。它也能把体积压到原始数据的 5% 以下，但检索要 300 秒往上，最高比 LEANN 慢 200 倍。原因是图结构的重算复杂度是 O(log N)，而 IVF 要做 O(根号 N) 次重算，在 6000 万段落的规模上差距被放大得很明显。LEANN 论文里明确把这条差异归因于图索引的结构优势。

延迟最难看的是 M1 Ultra 上的 HotpotQA，检索要 44.8 秒，占整条流水线一半时间。论文也确认了 CPU 延迟数据缺失这一空白，只有 Linux 的 CPU-only 安装方式可用，官方没给对应的耗时数字。这条限制在评估个人设备部署时需要留意。

个人数据与编码场景

仓库给的个人场景数字比论文场景更能说明用途。40 万条聊天记录从 1.8 GB 降到 64 MB，3.8 万条浏览器历史从 130 MB 降到 6.4 MB。论文 Table 3 在三个数据集上与 HNSW 对比，FinanceBench 节省 97%，Enron 节省 98%，LAION 节省 97%。

随包发布的应用覆盖文档、Apple 邮件、Chrome 历史、微信、iMessage，以及 ChatGPT 或 Claude 的导出记录，还有读取 Slack 与推特书签的 MCP reader，也能作为 Claude Code 的语义搜索 MCP 服务。MIT 协议，支持 Ubuntu、Arch、WSL、macOS 与 Windows。默认嵌入模型是 1.1 亿参数的 Contriever。仓库示例里有一份 60 万段落的维基索引从 201 GB 压到 6 GB 的数据，与论文 Table 1 的 4 GB 属于同一量级的两种语料设定。

编码智能体场景的收益更直接。SWE-Bench Pro 上首轮相关代码召回率 24.2%，BM25 只有 11.4%，智能体还少用了 8.4% 的 token。召回率翻倍与 token 消耗下降同时出现，这个组合对按 token 计费的智能体系统是双重利好。检索质量之外的重排取舍，站内这篇 Cohere Rerank 5 是另一条省钱路径；检索前端本身的工程实现可以看 腾讯元宝搜索开放 与 Mirendil Fern 0.1 的上下文检索。

索引之外：存储与本地化这条线

LEANN 之所以在这个时间点被关注，与向量检索之外的一批变化同步。智能体上下文管理的成本结构正在变化，站内这几篇可以连起来看：OpenAI Habitat 的 500 PB 存储与 10 毫秒读取 展示的是云端大规模存储的另一条路径，TokenGate 用门控剪枝把长上下文预填充提速 11.3 倍 走的是减少无效计算的路子，Recursive Flint 只激活 2.5B 参数在本地跑 131 token 每秒 则代表本地化推理的能力边界。

LEANN 补的是这三者之间的空白环节，检索侧的存储成本。当模型本身已经能在笔记本上跑，检索索引却还要几百 GB 时，端侧 RAG 依然做不到。

三个常见问题

LEANN 适合什么场景，不适合什么场景？

适合存储受限、延迟容忍的场景，个人设备上的语义检索与本地 RAG 属于典型用例。不适合延迟敏感的高并发在线服务，HotpotQA 在 M1 Ultra 上检索要 44.8 秒、占流水线一半时间，这个代价在交互式产品里是硬伤。

体积压到 4 GB，准确率真的会不掉吗？

在论文设定下不掉。NQ 上 25.5% 与未压缩 HNSW 完全一致，四个数据集上相对 BM25 的 EM 提升最高 11.8%。前提条件要说清楚，重算用的是与建索引时相同的编码器，换嵌入模型需要重建索引。另外官方没公布 CPU-only 部署的延迟数据。

这算重复造轮子吗，FAISS 生态里有没有现成方案？

LEANN 本身构建在 FAISS 之上，贡献在于图剪枝策略与两级搜索加动态批处理的组合。仓库的星标增速与论文获奖说明社区认可度不低，MIT 协议也便于二次开发。要注意与 IVF-Recompute 这类同样走重算路线的方案区分，二者在 6000 万段落规模上的检索耗时差了 200 倍量级，选型时不能只看存储数字。

小结

LEANN 证明了一件此前被当作不可能的事，向量索引的体积可以和向量维度脱钩。6000 万段落从 188 GB 到 4 GB，准确率一分不掉，代价是检索慢 50 倍但端到端只多 11%。这个交换成立的前提是生成阶段的耗时远大于检索阶段，而这恰好是当下大模型应用的常态。它带来的最实际变化是个人设备跑大规模语义检索成为可能，聊天记录、浏览器历史、代码库都能塞进笔记本。论文的四组数据与三份个人数据对比给出了完整的取舍边界，接下来要等的是第三方在真实生产负载下的复现结果。

相关阅读

• Cohere Rerank 5：BRIGHT 82.2 分，token 省 35%
• 腾讯元宝搜索开放：157 信源、8 毫秒检索如何接入 Agent
• OpenAI Habitat 深度：500 PB 存储与 10 毫秒读取延迟
• TokenGate 长上下文预填充提速 11.3 倍
• Recursive Flint 开源：40B MoE 激活 2.5B，本地跑 131 token 每秒
• Mirendil Fern 0.1 发布：1000 万 Token 上下文检索满分