LightRAG 图谱检索增强框架

它解决什么问题

传统 RAG 流水线通常把文档切成互不相关的片段，向量一存就结束。一旦问题需要跨段落、跨实体的关联推理，比如「某公司的收购对供应链产生了哪些连锁影响」，召回出来的结果很容易像拼凑的碎片，缺少统一的上下文支撑。

LightRAG 想用图谱来补上这一块：从原始文档中提取实体、关系和属性，形成一张可被检索的知识图。这样模型在回答问题时，既能拿到与实体直接相关的上下文，也能沿着图上相邻节点扩散，减少多跳推理时的断链问题。

这套技能如何工作

核心能力主要包括：

• 从文档中构建知识图谱，将实体、关系、属性以结构化形式保存，而不是只依赖无结构的向量库。
• 提供混合检索路径：既支持基于图的上下文检索，也支持常规向量检索，两者可以按实际任务组合使用。
• 支持多种存储后端和多种 LLM 提供商，便于在现有技术栈上做集成，不必强行绑定某一家方案。
• 提供 LightRAG Server，对外暴露 Web UI 和 API，可用于文档索引、图谱浏览和基础查询实验。

一个典型的使用流程大致是：先把待处理的文档接入索引流程，让系统抽取实体关系并写入存储后端；查询时从问题出发，在图谱上定位相关子图或关键实体，再把检索到的上下文片段送入大模型生成答案。从 SKILL.md 的片段来看，这套设计比较适合需要实体级可解释性的检索场景，而不是单纯的关键词召回。

适用边界与注意点

需要注意，这套技能的优势依赖于上游文档的质量和抽取效果。如果文档本身实体稀疏、关系模糊，生成的图谱也不会自动变得丰富，图谱检索能带来的收益会相应缩小。

另外，它更适合有一定工程基础、愿意花时间调索引和检索参数的团队。若只是想快速跑一个轻量问答原型，或者文档量很小、关系简单，传统向量检索往往已经足够，图谱带来的额外复杂度不一定划算。

离线或隔离环境也可以使用，但需要提前处理依赖和缓存文件，这部分在上游文档中已经有专门说明。整体上，LightRAG 的价值在于让检索结果有更清晰的结构支撑，代价是前期搭建和调优的投入会更高。