第一次在这里和大家分享我们团队最近的一个新作品——LEANN 🎉
仓库地址在这 👉 GitHub Repo（顺手点个 Star，感激不尽 🙏），paper也已经上传到arxiv了
LEANN 的核心是一个世界上最“瘦”的语义搜索后端：
相较于传统的 semantic search backend，我们能做到 97% 的存储节省，而且依然保持高精度、高性能。
在它的基础上，我们还做了很多开箱即用的应用，让你的本地设备直接变成 RAG（检索增强生成）神器。
这篇文章，我会带你看看：
- 我们的 RAG Everything 前端应用能解锁哪些超实用场景
- LEANN 在后端的技术细节与一些有趣的观察
- 一些未来的vision
（看到这儿，其实你已经可以退出去执行一句命令——uv pip install leann——然后立刻在你的 MacBook 上对微信聊天记录开 RAG 了 🔥）
LEANN支持什么应用（RAG Everything）
大家最近聊 RAG（Retrieval-Augmented Generation，检索增强）都聊得很热，因为它几乎是 LLM 时代第一个真正意义上的 “杀手级应用” —— 能把那些没进过训练集的私有数据，直接接入到大模型的推理链路里。
所以在我看来，隐私场景绝对是最重要的落地方向（尤其是你自己的私人数据，以及医药、金融公司这种对数据敏感度极高的领域）。
而** RAG everything** 这个概念，就是从「个人笔记本电脑最刚需」出发的。我们原生支持了一堆开箱即用的场景（先友情提示一下，目前支持 macOS 和 Linux，Windows 党暂时需要配合 WSL）：
- 文件系统 RAG→ 替代掉 Spotlight Search。Spotlight 不仅吃硬盘，还只能关键词匹配，我们直接让它变成语义搜索神器。
- Apple 邮件 RAG → 想找到私人问题的答案轻轻松松（比如 “伯克利 EECS 新生第一学期建议修几门课？”）。
- Google 浏览记录 RAG → 追踪你那天突然遗忘的、模糊到只有印象的搜索记录。
- 微信聊天记录 RAG → 🔥 这个我自己用得最多！我用 LEANN 总结过和朋友的聊天，再提炼成 research idea + slides。我们做了一点小hack绕过微信加密数据库，把聊天记录提取出来——放心，全程本地，不会有任何泄漏。
- Claude Code 语义搜索增强 → Claude Code 最大的槽点之一是它总在 grep，grep 半天啥也没找到。据我所知，他们也在想办法改进，以及claude正在积极和某些公司合作解决这些。LEANN 是第一个开源项目之一让 Claude Code 真正做语义搜索的，通过加一个 MCP server，一行代码就能在 Claude Code 里启用（如果大家感兴趣，我可以单开一篇详解我们集成的各种细节以及也可以从头介绍最近非常火爆的claude code）。
这些只是目前我们觉得最「有潜力」的几个场景，后面还会不断融入更多玩法。我们收到了很多用户反馈，会优先把呼声高的功能加进来，直到它变成一个为你量身定制的本地 Agent，能记住你的 LLM memory，也能掌握你的全部私人数据。
接下来，我就要回答一个灵魂问题——为什么 LEANN 是个人 MacBook 上跑这些应用的最佳后端？
什么是 LEANN？为什么需要它？
（如果不想看技术细节，可以直接跳到最后，LEANN后端反正开箱即用，只需要知道他很轻量化就行，这里主要讲 vector database 一些实现的细节）
我们分成背景和结论在介绍LEANN，包括在academic和enginner上的细节，以及一些动机
背景
现在的主流向量数据库，在延迟（latency）方面已经做得很优秀了。在百万级数据量下，大多数查询都能稳定在 10ms–100ms 完成。在 RAG 这种 search + generation 的模式下，搜索的时间几乎是“远低于”生成时间的——尤其是现在流行的 reasoning model，在长 chain-of-thought 下，生成时间越来越长（而且 RAG 的输入往往更长，这也让生成时间水涨船高）。换句话说，retrieval latency 在 RAG 中根本不是最大瓶颈。
但另一面，RAG 最重要的落地场景——是隐私。尤其是个人电脑上的隐私场景，资源天然稀缺（想想我们还需要存储空间去打游戏看视频，而不是存一些人看不懂的embedding）。我刚开始做这个项目时，老板就提醒我：
“个人场景下的存储压力是个挑战，我们得想办法解决。”
随着我进一步 profile，我发现一个很现实的问题：如果想在文本领域的 RAG 里追求高 recall（也是最常见的需求），就得用很细的 chunk size。这会导致 embedding 存储的体积是原文本的 3–10 倍——因为你得存所有的高维向量，还要存复杂的 HNSW graph。举个真实例子：70GB 的原始数据 → 220GB+ 的索引存储。
所以我们开始思考：
在一个延迟不是那么关键的场景下，能不能在 存储 和 延迟 之间做一次 trade-off？
解决方案
于是就有了 LEANN。LEANN 基于 HNSW graph（其实可以替换成任意 proximity graph，例如 NSG、Vamana），但我们做了一个大胆的设计：用 recompute 代替存储。
核心观察很简单： 在 graph-based 索引中，一个查询实际访问的节点数量是极少的->那为什么要存下所有 embedding？HNSW graph很复杂->是否有进一步prune的可能？
首先想我们能否仅仅保留graph structure而去除embedding的存储来做vector search, 这样的pipeline就是我们先正常build一个vector store。然后删除所有的embedding仅仅保留Proximity Graph来记录data chunk之间的relation，然后在inference的时候我们把正常的从内存load转换为recompute，这样就能节省storage和memory开销，我们发现现在的embedding model都是比较lightweight的这种高效的graph based recompute的方法其实没有太大的overhead，这样我们就完全不用存储任何的embedding。
接下来我们再处理graph structure prune的问题，我们的观察就是keep high degree node as much as possible来保证连通性,我们发现在RNG之后的graph都有很大的visit skewness的pattern，所以我们的策略是通过一定的heuristic来只保留这些高度数节点（对于原来低度数节点限制out edge数量，但是不限制in come egde数量）
从结果来看，我们实现了：索引体积缩小 97% 以上,在 3090 级别硬件上检索时间低于 2 秒,真实 RAG 基准测试中 Top-3 召回率超过 90%,并且完全不存储任何向量,这都是在200G以上embedding空间中达成的效果。值得注意的是在这种高压缩率下，PQ，OPQ以及最sota的rabbitq都完全不能保证高的accuracy（当然这里也有很多细节可以讨论），这点在paper里面也有证明。 Note:如果你本地本地部署ollma跑qwen以及最近的gptoss generation时间都是10s+的因为很多的thinking pattern
当然其中还有很多细节的优化比如在latency上我们采用了一种adaptive的结合coarse grained search和accurate search的pipeline(这个的edge case就是diskann的recompute 版本-用PQ粗搜然后在整个cannidate set上做rerank)，高效利用GPU的batch方案来提升GPU的利用率以及在ipc之间使用distance而不是embedding的高效zmq通信，CPU/GPU overlapping，有选择的cache high degree nodes之类。 更多细节我们可以参考arxiv paper,以及repo,如果有需求的话我可以再开一个帖子讲下所有实现细节。
我们希望LEANN这个idea能inspire更多vector search的reasearcher来从另一个角度思考vector database。特别是在一个比较受欢迎的RAG的setting下，也比较幸运在今年开SIGMOD/ICML vector search workshop的时候也有很多人一起讨论当时刚release的LEANN的arxiv paper，也感谢大家的认可。
结尾
我们会在 Berkeley SkyLab 持续维护这个开源项目(欢迎参与, star 或者 贡献 或者加入)
从算法、应用到系统设计、向量数据库、Kernel加速，全栈优化。
我们的愿景是 RAG Everything：
- 无缝对接你的所有私有数据
- 构建长期的本地 AI 记忆以及AI Agent
- 零云依赖，低成本运行
