LEANN
97%存储压缩！将笔记本变成支持亿级文档的私密RAG系统，数据永不离开设备
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
97%存储压缩！将笔记本变成支持亿级文档的私密RAG系统，数据永不离开设备
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：你在整理过去三年积攒的聊天记录、工作邮件、浏览器书签和 PDF 文献，发现总大小超过 10GB。 如果用传统方案建向量索引，这些数据的 embedding 存储就要吃掉 30GB 以上的空间——大多数个人设备根本跑不动，更别说还能流畅搜索。 LEANN 解决的就是这个问题：它让你在普通笔记本上，用原来 5% 的存储空间，完成同样的语义搜索任务。
向量搜索是 RAG（检索增强生成）系统的核心技术——将文本、图片、代码转为高维向量，通过「向量最近邻」找到最相关的内容，再喂给大模型生成答案。目前主流方案（Faiss、HNSW、DiskANN）都需要预先把所有文本的 embedding 计算好并存储下来，一条 512 维的 float32 向量占 2KB，100 万条文本就是 2GB。 加上图索引的边数据和元数据，实际存储通常是原始文本的 3-5 倍。对于个人设备和大规模数据集，这个开销难以接受。
LEANN 提出了一个巧妙的思路：不存 embedding，在搜索时实时重计算。
具体来说，LEANN 基于近邻图（proximity graph）构建索引，搜索时不是直接比较查询向量与所有已存向量，而是沿着图边逐步逼近目标节点。到达候选节点时，才临时计算该节点对应的文本 embedding，与查询向量做相似度比较。这种「图上按需重计算」的策略将存储开销大幅压缩。
为了避免搜索精度下降，LEANN 团队还引入了两个关键设计：
高阶保持剪枝（High-degree Preserving Pruning）：保留图中高度节点的连接关系，防止剪枝过程中丢失关键的拓扑结构。这对近邻图的搜索精度至关重要——高度节点往往是社区中心，连接它们是搜索路径的关键枢纽。
CSR 格式压缩图存储：用压缩稀疏行矩阵压缩图结构，进一步减少存储。
在论文 [LEANN: A Low-Storage Vector Index] 的实验中，LEANN 在 6000 万文本块上仅用 6GB 存储，传统方案需要 201GB，压缩比达到 97%，同时搜索精度和延迟与 SOTA 方案相当。该论文已被 MLSys 2026 接收。
图 1：LEANN 架构——图上按需重计算流程
LEANN 是一个 monorepo 结构，包含多个独立包：
图 2：LEANN vs 传统向量数据库存储对比——同样的数据，LEANN 仅用 6GB，传统方案需要 201GB
| 组件 | 技术选型 |
|---|---|
| 核心语言 | Python 3.9-3.13 |
| 嵌入模型 | sentence-transformers（默认）, OpenAI, Jina AI, HuggingFace |
| LLM 推理 | OpenAI API, Ollama, LM Studio, vLLM, SGLang, Anthropic |
| 索引后端 | HNSWlib, DiskANN, IVF, Faiss |
| 文档解析 | PyPDF2, pdfplumber, pymupdf |
| RAG 框架 | llama-index, langchain |
| 包管理 | uv（推荐）, pip |
| 构建工具 | setuptools + cmake |
LEANN 提供声明式 API，安装后三行代码即可完成索引构建和搜索：
from leann import LeannBuilder, LeannSearcher, LeannChat
from pathlib import Path
INDEX_PATH = str(Path("./demo.leann"))
# 构建索引
builder = LeannBuilder(backend_name="hnsw")
builder.add_text("LEANN saves 97% storage compared to traditional vector databases.")
builder.build_index(INDEX_PATH)
# 语义搜索
searcher = LeannSearcher(INDEX_PATH)
results = searcher.search("fantastical AI-generated creatures", top_k=1)
# 结合大模型聊天
chat = LeannChat(INDEX_PATH, llm_config={"type": "hf", "model": "Qwen/Qwen3-0.6B"})
response = chat.ask("How much storage does LEANN save?", top_k=1)
同时也支持丰富的命令行工具 leann，可对文档、邮件、微信、浏览器历史等数据源直接构建索引并搜索。
LEANN 并不只是一个向量索引库，而是一个面向个人数据管理的 RAG 全栈工具，覆盖场景极为广泛：
特别值得一提的是 leann-mcp，它将 LEANN 作为 MCP 服务端，实现了与 Claude Code 的深度集成——Claude Code 原本只支持 grep 风格的关键词搜索，接入 LEANN 后即可解锁语义搜索能力，对代码库的检索体验大幅提升。
图 3：Claude Code 通过 MCP 协议调用 LEANN 语义搜索
LEANN 是一个纯本地工具，所有数据处理都在本地设备完成，不上传任何内容到云端，真正实现「数据不出设备」。
部署方式灵活多样：
uv pip install leann，CPU-only 可用 leann[cpu]python:3.11-slim 基础镜像的 Dockerfile，版本 v0.3.6硬件需求：CPU 即可运行，GPU 可加速 embedding 计算但非必需。
实时重计算的开销：按需重计算虽然节省存储，但每次搜索都要重新计算候选节点的 embedding，在大批量并发查询场景下延迟可能高于预计算方案。
DiskANN 依赖复杂：在 Linux 上启用 DiskANN 后端需要安装 Intel oneAPI MKL、Boost、Abseil 等大量系统依赖，配置过程繁琐，与简洁的 PyPI 安装体验形成落差。
Ollama 兼容性问题：Ollama 本身迭代频繁，部分新模型与 LEANN 的兼容性需要手动调试。
LEANN 的核心贡献不仅在于 97% 的存储压缩，更在于重新定义了「个人 AI」的可行性边界——过去需要云端服务器才能运行的向量搜索 RAG 系统，现在可以完整跑在一部普通笔记本上。这对于重视数据隐私（不想把个人聊天、邮件、笔记发给第三方 API）的用户，以及在网络受限环境（离线、弱网）下工作的专业人士，都有重要价值。
该项目在 GitHub 上获得超过 11,700 颗星，论文被 MLSys 2026 接收，表明学术界对「存储高效的向量索引」这一方向的认可。可以预期，后续会有更多工作探索 embedding 重计算与硬件加速（如 GPU/NPU）的结合，进一步压缩推理延迟。
图 4：LEANN 项目 Logo