LEANN 用查询时重算换取向量索引瘦身

向量索引比原始资料还大，是本地 RAG 经常遇到的尴尬。UC Berkeley 的 Sky Computing Lab 做了一个取舍：LEANN 不再长期保存完整向量，而是在查询时按需重算。仓库报告，6000 万个文本块的索引由 201 GB 缩到 6 GB。

代价也很明确：省下磁盘空间，要用检索时间补回来。它值得关注的地方，是让个人资料检索有机会装进普通工作站；但「能装下」和「用起来够快」，需要分开判断。

少存向量，为什么还能找到相关内容

LEANN 是基于 FAISS 的近似最近邻索引（ANN），不是大模型，因此没有上下文长度这个指标。默认嵌入模型是 110M 参数的 Contriever，代码采用 MIT 许可，可用 uv pip install leann 安装。

论文给出的存储账单很直观：76 GB 原始语料，需要 173 GB 嵌入向量，再加 15 GB HNSW 图。索引合计 188 GB，已经超过原始资料的两倍。

LEANN 保留经过剪枝的图和紧凑的乘积量化（PQ）表，丢掉完整向量。查询沿图搜索时，只为路径上需要的节点重新计算嵌入。

它能这样做，是因为图检索通常只访问少量节点，不必重新处理全部语料。为控制重算成本，团队用了三种办法：

• 先用便宜的 PQ 距离筛选邻居，只有排名靠前的候选才精确重算。
• 将多个搜索跳数产生的候选动态组批，例如一次处理 64 个，提高 GPU 利用率。
• 剪枝时让多数节点少留边，但给连接度最高的 2% 枢纽节点保留更多连接。

消融实验中，两级搜索平均提速 1.4 倍，加上批处理后达到 1.8 倍。不过，嵌入重算仍占查询延迟约 76%。

LEANN 的核心取舍，是用查询时的计算换取更小的索引。

这里还要区分两组数字：仓库的 6000 万块测试是 201 GB 降至 6 GB；论文的 76 GB Wikipedia 语料配置是索引降至 4 GB。不能把它们当成同一组实验。

准确率能追平，等待时间却差很多

论文在 6000 万段 RPJ-Wiki 数据上测试了 NQ、TriviaQA、GPQA 和 HotpotQA，检索延迟按 90% Recall@3 衡量，即考察前三个检索结果的召回表现。以下都是团队自报结果。

在 RTX 4090 上搭配 Qwen3-4B，LEANN 和 HNSW 的 NQ 下游准确率都是 25.5%，但索引分别占 4 GB 和 188 GB。BM25 为 18.3%，PQ 压缩方案为 17.9%。

检索时间的差距更明显：LEANN 为 2.48 秒，HNSW 为 0.05 秒。由于生成阶段本身约需 20 秒，完整流程从 20.95 秒增加到 23.34 秒。

因此，原文中「体验仍可接受」的依据，依赖于一个前提：生成本来就慢。如果业务只做语义搜索，或者生成已经很快，这两秒多就很突出。

在 RTX 4090 上，LEANN 的检索耗时从 GPQA 的 1.12 秒到 HotpotQA 的 7.12 秒不等。到了 M1 Ultra Mac，HotpotQA 检索达到 44.80 秒，占完整流程的 50.1%。原文提到 CPU-only Linux 安装方式，但没有公布纯 CPU 延迟。

其他方案也各有账单。论文中的 DiskANN 占 270 GB，NQ 和 HotpotQA 检索分别只需 0.03 秒、0.11 秒；20 GB 的 PQ 方案则未达到 90% 召回率。受 EdgeRAG 启发的 IVF 重算基线，两项耗时分别为 307.61 秒、429.46 秒，文章称 LEANN 相比该基线最高快 200 倍。

这些结果说明它解决了存储压力，也说明「本地可运行」不能直接等同于「即时响应」。

它已经接到了个人资料和编程助手里

仓库提供文档、Apple Mail、Chrome 历史、WeChat、iMessage，以及 ChatGPT、Claude 导出记录的应用。MCP 读取器可以接入 Slack 和 Twitter 书签，也能作为 Claude Code 的语义搜索 MCP server。

个人数据的存储结果同样来自仓库：40 万条聊天消息的索引从 1.8 GB 缩到 64 MB，3.8 万条浏览记录从 130 MB 缩到 6.4 MB。但这些例子没有配套的延迟和准确率数据。

编程场景有一组更直接的测试：在 ContextBench 的 30 个 SWE-Bench Pro 任务上，团队报告初始相关代码召回率为 24.2%，BM25 为 11.4%，agent 使用的 token 减少了 8.4%。这支持继续验证代码检索价值，却还不足以证明复杂工程任务的完成率会提高。

默认后端是 HNSW，也可选择 DiskANN 加快搜索。这里并不矛盾：LEANN 改的是向量保存与重算方式，图搜索仍可依托这些后端。生成侧可接 Ollama、Hugging Face、Anthropic 或任何 OpenAI-compatible API。

系统支持 Ubuntu、Arch、WSL、macOS 和 Windows，但 Apple Mail 搜索等应用仅限 macOS。

我的判断

我认可它优先解决「装不下」的问题。对于个人资料库，磁盘和内存往往比极限检索速度更先成为障碍。论文的 32 GB RAM 工作站能运行 LEANN，而对应 HNSW 配置发生 OOM，这个差别有实际意义。

但不能把它理解成 HNSW 的全面替代品。需要低延迟时，原文中的 HNSW 和 DiskANN 明显更快；资料规模不大、关键词很明确时，BM25 也值得保留为简单基线。论文称 LEANN 相比 BM25 的 exact match 最高提升 11.8%，仍需看具体数据集。

最该验证的是自己的查询等待时间，而不是只看索引压缩比例。

这些数据来自论文 v2 的 Tables 1、2 和 Section 7.2，以及仓库报告，没有独立复现对照。MLSys 2026 Best Research Paper 奖项能说明研究受到认可，不能替代部署评估。原文也没给出并发查询、持续更新和长期维护成本的数据。

能拿来做什么

• 做本地文档或聊天记录 RAG 时，先选一批代表性资料，对比 LEANN 与现有方案的索引体积、召回表现和完整问答耗时，再决定是否替换。
• 给 Claude Code 接代码检索时，可以用它的 MCP server 做小范围验证，同时保留 BM25 对照，观察相关文件是否更早出现，以及任务完成情况是否改善。
• 部署在 Mac 或纯 CPU 机器上时，先测试真实硬件。原文的 Mac 多跳检索已达到几十秒，纯 CPU 性能则没有公开数字。
• 已有 Node 应用可先把检索作为独立能力接入现有流程；生成侧继续使用兼容接口，并分别记录检索和生成耗时，避免慢生成掩盖检索成本。