在个人设备上部署检索增强生成（RAG）系统时，存储空间的限制往往是最棘手的工程挑战。传统向量索引将每个文本块转换为高维嵌入向量并完整存储，对于包含数十万条消息或邮件的个人数据集，索引体积可能达到原始数据的好几倍。LEANN 通过一套创新的图剪枝与选择性重计算算法，将这一存储开销压缩至原来的二十分之一。本文将从算法层面剖析其核心机制，重点探讨高度保持剪枝策略的实现逻辑、按需重计算的触发条件，以及工程实践中不同后端的选择依据。
传统向量索引的存储困境
理解 LEANN 的技术贡献，首先需要认清传统向量索引的存储瓶颈。以 Facebook AI 相似性搜索（FAISS）为代表的近似最近邻搜索系统，采用层次可导航小世界图（HNSW）或倒排文件（IVF）结构来加速向量检索。这些方法的核心思路是预先计算并存储所有数据点的向量表示，同时构建图结构或倒排索引来支持高效的相似度搜索。在包含六千万文本块的中等规模数据集上，每个维度为 1024 的 float32 向量需要占用约四 GB 存储空间；加上图结构的邻接表和元数据，完整索引的体积可能突破两百 GB。
这种存储开销对于云端服务器而言或许可以接受，但对于希望在笔记本电脑上构建个人知识库的用户来说几乎是不可行的。一个典型的使用场景是搜索自己的微信聊天记录：四百万条消息若使用传统方案，索引可能需要一点八 GB 空间；而浏览器历史、邮件归档等数据源叠加后，存储需求会迅速膨胀到难以管理的程度。更关键的是，这些索引一旦构建完成就与原始数据绑定，无法像传统数据库那样通过增量更新来控制体积增长。
LEANN 的核心洞察在于：并非所有嵌入向量都需要预先存储。向量搜索的本质是计算查询向量与候选向量之间的相似度，如果在搜索过程中能够实时计算某些候选节点的向量表示，就可以在不损失检索质量的前提下大幅削减存储体积。这一思路的实现需要解决两个关键问题：如何确定哪些节点需要预先存储、哪些可以按需计算；以及如何设计搜索算法来协调两种节点的访问。
高度保持剪枝的算法原理
LEANN 采用的图剪枝策略基于一个关键观察：在向量搜索图中，高度节点（即连接数众多的节点）往往承载着重要的导航功能。这些 Hub 节点虽然在数量上只占整体的一小部分，却连接了大量普通节点，使得搜索算法能够快速定位到目标区域。如果不加区分地删除节点，可能会导致图连通性受损，影响搜索路径的完整性。高度保持剪枝（High-Degree Preserving Pruning）的核心思想是：在删除冗余连接的同时，优先保留高度节点的完整连接信息。
具体而言，算法的剪枝过程可以分为三个阶段。第一阶段是图结构的静态分析，系统遍历整个 HNSW 图，统计每个节点的度数分布，并识别出度数超过预设阈值的高度节点。这个阈值由 graph-degree 参数控制，默认值为三十二，意味着任何连接数超过该值的节点都会被标记为 Hub。第二阶段是连接选择性删除，对于非高度节点，系统按照一定策略移除部分邻居连接，只保留最 "关键" 的若干条边。保留的数量同样由 graph-degree 参数决定，这样可以确保剪枝后的图仍然具有足够的局部连通性。第三阶段是邻接表的紧凑存储，LEANN 使用压缩稀疏行（CSR）格式来存储剪枝后的图结构，进一步降低存储开销。
值得深入理解的是剪枝阈值的工程意义。将 graph-degree 设置为较高值（如六十四）会保留更多连接，使搜索路径更加稳定但存储节约较少；设置为较低值（如十六）则能实现更高压缩比，但可能在某些查询上需要更多的图遍历步骤。LEANN 的默认值为三十二，这是一个在存储效率和搜索精度之间取得平衡的折中选择。在实际部署中，用户可以根据硬件条件和精度要求，通过 --graph-degree 参数进行微调。
搜索时嵌入向量的选择性重计算
剪枝后的图结构只包含节点间的邻接关系，缺失了最关键的向量嵌入数据。LEANN 通过在搜索过程中按需重计算这些向量来填补空白。这一机制的实现依赖于图遍历的层级特性：当搜索算法访问某个节点时，如果该节点的嵌入向量未被存储，系统会立即调用嵌入模型进行实时计算，然后将结果缓存在内存中供后续访问使用。
这种按需计算的策略之所以可行，源于向量搜索的访问模式特点。在典型的 K 近邻搜索中，算法从图的入口节点开始，逐层向下探索，每次只访问少量与当前节点直接相连的邻居。这意味着对于一次完整的搜索请求，实际需要计算向量嵌入的节点数量远小于数据集中的总节点数。LEANN 将这一观察量化：即使在最坏情况下，一次搜索也只需要计算搜索路径上的数十个节点，而非全部数据点。
为了优化重计算的性能开销，LEANN 实现了动态批处理机制。当搜索算法需要同时访问多个未缓存节点时，系统会将这些计算请求聚合成一个批次，调用底层框架（如 sentence-transformers 或 HuggingFace）的批量推理接口。这种方式能够充分利用 GPU 的并行计算能力，将单个节点的计算延迟分摊到整个批次上。值得注意的是，重计算功能默认开启，但如果用户更关注延迟而非存储，可以在构建索引时使用 --no-recompute 参数禁用此特性。
搜索复杂度的控制通过 search-complexity 参数实现，默认值为六十四。这个参数决定了图遍历的深度和广度：较高的值会让算法探索更多候选路径，提高召回率但增加计算开销；较低的值则能更快返回结果，但可能错过一些更远的匹配项。LEANN 还支持三种剪枝策略 —— 全局（global）、本地（local）和比例（proportional）—— 分别对应不同的邻居节点选择策略。全局策略在整个图中应用统一的筛选标准；本地策略根据每个节点的局部特征动态调整阈值；比例策略则按照预设比例保留排名最高的邻居。
双后端架构与工程选择依据
LEANN 提供了两种索引后端供用户选择，分别是默认的 HNSW 模式和可选的 DiskANN 模式，两者在存储结构和搜索算法上存在显著差异。HNSW 后端追求极致的存储压缩，完全依赖重计算机制来恢复缺失的向量信息，适合存储空间极为紧张的个人设备场景。DiskANN 后端则采用产品量化（Product Quantization）技术对向量进行压缩存储，在图结构中保存压缩后的向量副本，同时在搜索后期进行实时的解压缩和重排序。这种设计牺牲了一部分存储效率来换取更稳定的搜索延迟。
选择后端的决策依据主要是硬件条件和应用场景。如果用户的设备内存有限且主要关注存储节约，HNSW 是更合适的选择；如果用户需要处理大规模数据集且对搜索延迟有严格要求，DiskANN 能提供更好的性能保障。LEANN 的基准测试显示，在六十万文本块的数据集上，HNSW 后端的存储占用约为六 GB，而 DiskANN 后端约为十二 GB；但 DiskANN 的搜索延迟平均低百分之三十左右。对于个人邮件搜索（四百九十万封邮件缩减至七十九 MB）或聊天记录检索（四十万条消息仅需六十四 MB）这类典型场景，HNSW 后端已经能够提供足够的性能。
构建索引时的 --backend-name 参数用于指定后端类型，HNSW 和 DiskANN 的索引文件格式不兼容，因此切换后端需要重新构建索引。DiskANN 模式对底层库的依赖更为复杂，在 Linux 系统上需要额外安装 Intel oneAPI MKL 和 Boost 库；在 macOS 上则要求系统版本不低于十三点三以支持 DiskANN 的某些底层优化。
实践中的参数调优建议
在生产环境中部署 LEANN 时，有几个关键参数值得重点关注。build-complexity 控制索引构建的精细程度，默认值为六十四；提高这个值会延长构建时间但生成更高质量的图结构，适合对索引质量要求极高的场景。chunk-size 和 chunk-overlap 决定原始文本的切分粒度，较小的切分块（如二百五十六字符）适合细粒度检索，但会增加节点总数和索引体积；较大的切分块（如一千零二十四字符）则相反。
对于不同类型的数据源，LEANN 提供了针对性的默认参数。文档检索默认使用二百五十六字符的切分块和二十五字符的重叠；微信消息由于单条文本较短，默认切分块减小到一百九十二字符，重叠保持为二十五字符以确保跨消息的语义连贯性。这些预设值可以作为起点，但实际应用中应根据数据特点进行调整 —— 例如学术论文可以考虑增大切分块以保留更多的段落上下文，而代码文件则可以启用 AST 感知的智能切分模式。
监控索引构建和搜索过程的状态对于调优至关重要。LEANN 的命令行工具支持 --force-rebuild 参数来强制重建已有索引，这在调整参数后重新优化索引时很有用。搜索结果的返回可以通过 --top-k 参数控制返回结果数量，较高的值会返回更多候选但增加计算开销。在 Claude Code 集成场景下，还可以配置思维预算（thinking-budget）来控制推理深度，在低、中、高三档之间选择以平衡响应质量与延迟。
通过合理配置图剪枝参数、选择合适的后端架构，并针对具体数据源调整切分策略，LEANN 能够在个人设备上实现高效、私密的向量检索体验。这套技术方案的工程价值不仅体现在存储压缩的数字上，更在于它重新定义了边缘设备运行大模型应用的可能性边界。
参考资料
- LEANN GitHub 仓库：https://github.com/yichuan-w/LEANN
- LEANN 论文《LEANN: A Low-Storage Vector Index》：https://arxiv.org/abs/2506.08276