LeanRAG：知识图谱增强检索的轻量化突破

当大模型在专业领域"一本正经地胡说八道"时，你或许需要一套更可靠的检索增强生成方案。传统 RAG 把文档切成块、用向量相似度查找——简单高效，但信息碎片化严重，尤其面对"某公司CEO在2020-2023年间主导的三次并购案"这类多跳推理问题，往往顾此失彼。LeanRAG 正是为解决这一痛点而生，它用知识图谱把碎片黏合起来，让检索路径可追溯、答案更可信。

学术出身，AAAI-26 认证

LeanRAG 来自 KnowledgeXLab 团队，已被 AAAI 2026（人工智能顶会）正式接收为全文。论文 arXiv ID: 2508.10391，作者团队包括 Yaoze Zhang、Rong Wu、Pinlong Cai 等，研究方向聚焦知识图谱构建与检索增强生成的实际落地。

做研究的人通常不会花太多精力在工程化上，但这反而让 LeanRAG 的核心算法足够纯粹——没有为了"易用"而牺牲算法空间，每个设计决策背后都有消融实验支撑。

核心技术：从"撒网捕鱼"到"顺藤摸瓜"

传统 RAG 的检索方式是扁平的——用户问一个问题，系统找到最相似的 Top-K 文本块返回。问题在于，相关内容可能分散在多份文档中，单一文本块无法承载完整的语义关联。

LeanRAG 的解决思路是语义聚合 + 层级检索，分为五个阶段：

第一阶段：语义聚合（Semantic Aggregation）
将低层次实体（entity）聚类为语义一致的摘要节点（summary nodes），节点之间建立显式的邻接关系，形成可导航的聚合层知识网络。这一步借鉴了 HiRAG 的层次化实体聚合思路，但 LeanRAG 在聚合策略上做了改进——不仅按语义相似度聚类，还保留了实体到摘要的可追溯映射，便于后续溯源。

第二阶段：知识图谱构建（Knowledge Graph Construction）
基于两种方式提取三元组（triple）：

• CommonKG：基于 Wikipedia 实体的规则提取，适合有明确头部实体列表的场景
• GraphRAG：利用 LLM 的小样本（few-shot）能力，根据 prompt 示例从文本中自动抽取实体和关系

最终构建一棵多层级树结构知识图，叶节点是原始实体，上层是聚合摘要，边代表实体间和摘要间的关系。

第三阶段：层级检索（Hierarchical Retrieval）
这是 LeanRAG 最核心的创新。检索从最细粒度的实体开始（bottom-up），沿树结构向上遍历，每上升一层聚合更多上下文，直到收集到足够的相关证据。

第四阶段：去冗余合成（Redundancy-Aware Synthesis）
沿检索路径收集信息时，系统主动避免重叠内容，确保最终输送给 LLM 的 evidence 既全面又不冗余。论文数据显示，相比扁平检索基准，LeanRAG 的检索冗余度降低了约 46%。

第五阶段：答案生成（Generation）
将结构化的 evidence 输入 LLM（默认使用 DeepSeek qwen2.5 或 Qwen3 系列），生成最终答案。

图1：LeanRAG 整体架构 — 从文档切分、三元组抽取、知识图谱构建，到层级检索与生成的全流程。

技术栈方面，LeanRAG 围绕 Python 3.10+ 构建，依赖清晰：

• 向量数据库：Milvus Lite（轻量级本地向量检索）
• 关系数据库：MySQL（存储实体、关系、摘要元数据）
• Embedding：GLM 的 bge_m3 模型（国产高性能多语言 embedding）
• LLM 调用：OpenAI 兼容接口（支持 DeepSeek、Qwen、本地 Ollama 等）
• 分词/编码：tiktoken（cl100k_base）、jieba（中文分词）
• 聚类算法：UMAP + 层次聚类（_cluster_utils.py 中的 Hierarchical_Clustering）

实验数据：全面超越同类方法

LeanRAG 在四个跨领域 QA 基准数据集上与主流 GraphRAG 方法做了对比，包括 HiRAG、GraphRAG、LightRAG、FastGraphRAG、KAG 以及 NaiveRAG 基线，评测维度包括完整性（Comprehensiveness）、赋权性（Empowerment） 和 多样性（Diversity）。

Mix 领域（综合问题）：LeanRAG 全面领先，Overall 综合得分 8.59，显著优于 HiRAG（8.08）和 NaiveRAG（7.47）。在与 NaiveRAG 的胜率对比中，LeanRAG 在 97.3% 的问题上获得了更高评分。

Legal 领域（法律问答）：LeanRAG Overall 得分 8.49，在与 GraphRAG 的胜率中领先 51% vs 49%（几乎持平），但在胜率对比上 LeanRAG 在 76.5% 的问题上胜出。

Agriculture 领域（农业问答）：Overall 8.87，与 HiRAG 持平（8.87），但在与 FastGraphRAG 的对比中，LeanRAG 以 99%+ 的胜率碾压——FastGraphRAG 在农业领域的综合得分仅 3.17。

Token 消耗：这是 LeanRAG 最值得关注的优势之一。论文提供的 "Retrieval Information Tokens" 图表显示，LeanRAG 在达到相同甚至更高答案质量的前提下，消耗的 token 量大幅低于 FastGraphRAG 和 KAG 等竞品，推理成本显著更低。

部署门槛：不低，但有章可循

LeanRAG 的部署确实有一定门槛，官方未提供 Docker 容器化，也没有 Web 界面，是典型的"研究原型"风格。需要手动配置：

1. Python 3.10+ 环境 + pip install -r requirements.txt
2. MySQL 8.0+：存储实体关系数据，database_utils.py 中封装了建表和插入逻辑
3. Milvus Lite：本地轻量向量数据库，pymilvus + milvus-lite 组合
4. LLM API：默认 DeepSeek qwen2.5（通过 Ollama 本地服务 localhost:8001），或切换为 Qwen3-14b / Qwen3-32b
5. Embedding 服务：默认 GLM bge_m3（http://10.140.37.43:8001/v1），需自建或替换

代码结构清晰，核心脚本只有 5 个：

• file_chunk.py：文档分块（滑动窗口，chunk size 1024，step 128）
• build_graph.py：图谱构建（聚类 + 边关系生成）
• query_graph.py：检索执行（向量搜索 + 树遍历 + 路径生成）
• database_utils.py：数据库操作封装
• _cluster_utils.py：层次聚类算法

局限与思考

值得坦诚的是：LeanRAG 本质是一个研究框架，而非生产级产品。没有 API 服务、没有 Web 界面、没有成熟的文档和社区支持。对于希望快速集成的开发者而言，开箱即用体验欠佳。

此外，LLM API 依赖（DeepSeek/Qwen）和 Embedding 服务依赖（GLM）意味着整套系统实际运行需要访问外部服务，或自行部署兼容的 OpenAI 接口服务。对于有私有化部署需求的企业用户，改造工作量不小。

行业意义：GraphRAG 进化的重要节点

GraphRAG 自微软 2024 年开源以来，催生了大量变种（LightRAG、FastGraphRAG、HiRAG、KAG 等），但大多数方法在检索质量和推理成本之间难以两全。LeanRAG 用语义聚合层将这个问题向前推进了一步——不仅在多个基准上刷新 SOTA，还通过去冗余设计将 token 消耗降低了近一半。

251 颗 GitHub Stars 的体量不算大，但这与其"研究导向"的定位相符。对于做 RAG、知识图谱方向研究的团队，LeanRAG 是一个值得深入阅读源码的参考实现；对于想直接用于生产项目的团队，建议先评估好 API 依赖和部署成本。