GraphRAG 与 LightRAG

GraphRAG 与 LightRAG

第一部分：什么是 GraphRAG？

1. 一句话定义

GraphRAG 可以理解为：先从文档中抽取实体和关系，构建一个由文本片段、实体、关系和社区摘要组成的检索结构，再让 大模型 基于这个结构回答问题。

它不是把所有文本简单塞进提示词，也不是传统意义上由专家预先设计本体的知识图谱。Microsoft GraphRAG 的重点是让 RAG 具备"跨文档组织、按主题聚合和全局总结"的能力。

2. 与普通 RAG 的核心区别

普通 RAG 通常是：

文档 -> 切分文本块 -> 向量化 -> 向量相似度检索 -> 拼接上下文 -> 大模型回答

它对"某个局部事实"很有效。例如：

"A 车型的轴距是多少？"

但当问题需要跨多个文档、多个段落或多个主题综合时，普通向量检索容易出现三个问题：只找到了关键词相似的片段；片段之间没有关系；上下文过长时无法组织全局答案。

GraphRAG 增加了几层结构：

原始文档
  -> 文本单元
  -> 实体与关系
  -> 图社区
  -> 社区摘要
  -> 向量索引

查询时不只是找相似文本，还可以沿实体、关系和社区摘要组织证据。因此它更适合回答"多个资料共同说明了什么""某个主题有哪些共性和差异""整个资料库的主要观点是什么"等问题。

3. 与传统知识图谱的区别

对比项	传统知识图谱	Microsoft GraphRAG
建模方式	通常先定义本体、实体类型、关系类型和约束	主要由模型从文档中抽取实体和关系
数据来源	结构化数据、人工标注或规则抽取	非结构化文档为主
核心产物	三元组、属性、规则和可验证关系	文本单元、实体关系图、社区摘要、向量索引
推理方式	图查询、规则推理、路径推理	图结构组织检索证据，再由 LLM 生成答案
适合任务	精确查询、约束校验、流程执行	文档问答、跨文档总结、主题发现
事实精度	结构化后可严格校验	依赖模型抽取和生成，需要引用与人工核验

因此，GraphRAG 的"图"更多是一种检索组织结构。它与项目中已有的"按固定 schema 抽取汽车美学知识或操作知识"的知识图谱不是同一个东西。

4. GraphRAG 与 LightRAG 的关系

两者都属于图增强 RAG，但设计重点不同：

• Microsoft GraphRAG：离线构建成本较高，强调实体关系、社区发现、分层社区摘要，以及Local/Global/Drift 等查询方式；适合文档库级别的全局总结和复杂主题检索。
• LightRAG：更强调轻量、快速更新和低成本检索，通常同时利用实体关系图和向量表示，查询路径更直接，适合交互式知识库和频繁增量更新。

可以把它们看成两种工程取舍：GraphRAG 偏"先构建高质量全局结构，再做深度检索"，LightRAG 偏"保持结构较轻，降低索引和更新成本"。实际选型要看资料规模、更新频率、回答是否需要全局总结，以及可接受的 token 和延迟。

5. 需要澄清的误解

1. GraphRAG 不是自动拥有真实世界知识，它只是把输入文档组织得更好。
2. GraphRAG 不会自动替代权限系统；workspace、用户、团队和文件权限必须在服务端过滤。
3. GraphRAG 不等于实时数据库。Microsoft GraphRAG 的经典索引流程在新增文件后可能需要重新计算大量内容。
4. GraphRAG 的实体和关系存在模型误抽、漏抽、别名未合并等问题，必须检查中间产物。

第二部分：GraphRAG 解决什么问题？

1. 普通 RAG 的典型痛点

痛点一：问题需要跨文档综合

用户问：

"我们收集的几代车型资料中，哪些设计趋势持续出现？它们分别由哪些车型或设计规范支持？"

单纯向量检索往往只返回若干相似段落，缺少跨文档聚合。GraphRAG 可以先找到相关实体和社区摘要，再把多个来源组织成一个有主题结构的回答。

痛点二：用户不知道资料中有哪些主题

用户问：

"这批汽车造型资料主要讨论了哪些方向？"

这不是一个明确的关键词查找问题，而是资料库的全局理解问题。GraphRAG 的社区报告可以提供主题级摘要，这正是 Global Search 的应用场景。

痛点三：长文档和多份文档导致上下文失控

把所有相关片段直接塞给模型会带来 token 成本高、上下文冗余和重点丢失。社区摘要把大量局部内容压缩成分层主题，查询时可以先使用高层摘要，再按需要回溯底层文本。

痛点四：相似关键词不代表同一语义关系

"轻量化""铝合金""车身结构"在多个文档中分别出现时，普通向量检索未必能说明它们之间的关联。实体和关系结构能帮助系统沿着主题、部件、工艺和车型之间的连接组织证据。

2. 适合回答的问题类型

A. 全局总结类问题：优先 Global Search

问题特征是"整个资料库""总体来看""主要趋势""共同观点"。

示例：

• "这批资料总结出的汽车前脸设计趋势是什么？"
• "不同文档对新能源车型造型的共同判断有哪些？"
• "现有资料中，影响车身比例的主要因素有哪些？"

回答依赖多个社区摘要和多个来源，不能只靠一个文本块。

B. 局部实体和关系问题：优先 Local Search

问题围绕具体车型、零件、人物、工艺或设计概念展开。

示例：

• "某车型的侧面比例与哪些设计元素相关？"
• "某种材料在资料中与哪些工艺或部件一起出现？"
• "这条设计建议由哪些文件支持？"

Local Search 会围绕命中的实体、关系和相关文本单元组织上下文。

C. 多跳探索和关联发现：可用 Drift Search

问题不是直接问一个事实，而是从一个概念逐步探索相关主题。

示例：

• "从隐藏式门把手出发，资料中还涉及哪些空气动力学和用户体验问题？"
• "从车身曲面质量出发，继续追踪相关的工艺约束和评审标准。"

D. 证据追溯和设计决策支持

GraphRAG 适合给出"结论 + 来源片段"的结果，用于设计评审、需求澄清和知识复用。但它不应直接替代几何计算、法规校验或最终工程决策。

3. 不适合直接交给 GraphRAG 的问题

• 要求严格数值计算、几何求解或 CAD 操作的问题；
• 要求实时数据库状态的问题；
• 需要强权限隔离但尚未注入权限条件的问题；
• 资料本身没有证据，却要求模型给出确定结论的问题；
• 需要稳定执行动作的任务，例如"把轮子摆正""将曲面变平"。这类任务应由工作流智能体和操作知识图谱负责，GraphRAG 可以提供背景资料和约束说明。

4. 对本项目的实际落地价值

第一阶段最适合把 GraphRAG 定位为"用户工作区的资料知识库"：上传一次的设计需求、参考车型资料和规范文档，在同一工作区内被反复检索和总结。它补足的是文件复用和跨文档理解，而不是替换现有工作流状态或操作知识图谱。

第三部分：GraphRAG 完整工作流

总览

原始文件
  -> 输入准备
  -> 文本切分
  -> 实体/关系抽取
  -> 图合并与去重
  -> 社区发现
  -> 社区报告
  -> 文本与图结构向量化
  -> 查询路由
  -> Local / Global / Drift 检索
  -> LLM 综合答案
  -> 引用和结果返回

第一步：原始文档输入

用户上传 PDF、Word、Markdown 或纯文本文件。系统先记录业务元数据：workspace_id、文件 ID、版本、来源、权限、上传时间和处理状态；原始文件应保存在对象存储或文件存储中。

这一步不要直接把文件视为知识。要先判断：文件是否解析成功、是否属于当前工作区、是否允许进入索引、是否需要 OCR，以及是否存在重复版本。

第二步：文本清洗与切分

GraphRAG 将文档转换成文本单元（text units）。切分需要保留顺序、来源文件、页码或段落信息，以便回答时引用原文。

切分过大，会造成抽取提示词过长、模型输出不稳定；切分过小，实体关系上下文不足。汽车资料中应尽量让一个文本单元保持完整的设计描述、参数说明或规范条款。

第三步：实体与关系抽取

模型读取每个文本单元，抽取实体和关系。例如：

文本：某车型采用短前悬和低车顶设计，以改善运动感和风阻表现。

实体：某车型、短前悬、低车顶、运动感、风阻表现
关系：
某车型 --采用--> 短前悬
某车型 --采用--> 低车顶
短前悬 --有助于--> 运动感
低车顶 --影响--> 风阻表现

实体类型可以根据领域定制，例如车型、零件、工艺、材料、标准、组织和人物。不要盲目使用过宽的"事件"类型，否则年份、动作和普通短语都可能被抽成实体。

这一步最容易出现"日志没有报错但结果不对"的问题：模型可能漏写关系强度、改变元组格式、输出 Markdown，或重复返回同一文本块 ID。因此必须检查原始模型输出、关系数量、权重分布和重复 ID。

第四步：图合并与实体关系归并

来自不同文本单元的同名实体会被合并，关系也会被聚合。系统同时保留实体出现在哪些文本单元中、关系由哪些来源支持，以及实体的频率和连接度。

需要注意，字符串相同才容易自动合并。"前脸""前脸造型""front fascia"可能仍被识别为不同实体。汽车领域可以在索引前增加术语表和别名归一化。

第五步：社区发现

GraphRAG 对实体关系图进行社区发现，把连接紧密的实体划分到不同社区。一个社区可能代表"某车型的外观比例"，另一个社区可能代表"轻量化材料与制造工艺"。社区通常具有层级关系：底层社区更具体，高层社区更综合。

社区的价值在于把"很多零散关系"变成"可总结的主题"。这也是 GraphRAG 与只做向量检索的普通 RAG 最明显的工程区别之一。

第六步：生成社区报告

系统针对每个社区生成摘要、关键实体、主要关系、重要发现和来源引用。高层社区报告可以回答资料库级别的问题，底层社区报告可以支持局部细节查询。

社区报告不是最终答案，而是查询时使用的中间知识。它会影响 Global Search 的质量，因此要检查摘要是否忠实、是否保留来源、是否把模型推测写成了事实。

第七步：建立向量索引

文本单元、实体描述、关系描述和社区报告会被向量化，写入向量存储。向量用于语义召回，图结构用于组织实体、关系和社区；两者是互补关系，不是二选一。

在当前项目中，BGE-M3 为 1024 维向量模型，索引配置必须与向量维度一致。向量库、图数据和原始文件还要保留 workspace 作用域，查询时不能只依赖前端隐藏结果。

第八步：接收查询并选择检索模式

查询请求进入服务端后，先完成用户、工作区和权限校验，再判断查询类型：

问题 -> 权限过滤 -> 查询模式选择
                 ├─ Global：跨社区、全局总结
                 ├─ Local：围绕实体的局部细节
                 └─ Drift：从一个主题向关联主题扩展

实际系统可以先使用规则或路由模型选择模式，也可以在产品界面上提供"资料概览"和"针对某个对象追问"两种入口。

第九步：检索和上下文组装

以 Local Search 为例，系统先从问题中识别或召回相关实体，再扩展相关关系、文本单元和社区信息，按相关度、连接度、来源和 token 预算进行筛选。

Global Search 则主要读取多个社区报告，分批交给模型生成局部答案，再对局部答案进行汇总。这样可以在不把整个资料库塞进上下文的情况下回答全局问题。

LightRAG 在这里通常会采用更轻量的实体/关系与向量联合召回路径，减少重复构建和更新成本；GraphRAG 则更依赖预先生成的社区摘要。

第十步：大模型生成带证据的答案

模型接收问题、检索上下文、回答规则和引用信息，生成最终结果。理想输出包括：结论、理由、来源文件或段落、无法确定的部分。

例如：

结论：资料显示，短前悬和较低车顶在多份车型分析中与运动化视觉和风阻表现同时相关。
依据：车型分析 A 第 3 页、造型规范 B 第 7 节、风阻评审记录 C。
限制：当前资料未提供统一的量化阈值，不能据此直接确定车身尺寸。

第十一步：结果返回与后处理

服务端返回答案、引用、检索模式、耗时、索引版本和必要的置信提示。前端可以展示答案、来源文件、社区或关系图，并允许用户继续追问。

对于汽车造型平台，答案还可以作为工作流智能体的输入：GraphRAG 提供设计资料和历史依据，操作知识图谱提供动作约束，工作流 state 提供当前任务状态。三者组合后，才适合进入自动化执行。

Global Search 与 Local Search 的详细流程

Global Search：回答"整个资料库怎么看"

Global Search 的目标不是找一段最相似的原文，而是从多个社区摘要中形成全局答案。一次典型请求可以拆成以下步骤：

1. 识别问题范围：判断问题是否包含"总体、趋势、共同点、主要主题、综合分析"等全局意图。
2. 准备社区报告：系统读取不同层级的社区摘要、关键实体、关系和来源信息。
3. 按 token 预算分组：不能把所有社区报告一次性放进上下文，因此会将报告分成多个 context batch。每批都尽量覆盖不同主题，同时控制上下文长度。
4. 生成局部答案：大模型分别阅读每一批报告，输出该批次的观点、证据和引用。
5. 汇总局部答案：系统收集各批次结果，去除重复观点，合并相互支持的结论，保留冲突观点。
6. 最终综合：大模型基于局部答案生成一份全局回答，并附上来源引用和不确定性说明。

例如问题是"这些资料总结出的前脸设计趋势是什么？"系统可能分别从"封闭式前脸""灯组形态""进气口比例""新能源品牌差异"等社区得到局部结论，最后综合成趋势分析。

Global Search 的优势是覆盖面广，适合资料库级总结；代价是需要读取多个社区报告，LLM 调用次数和 token 消耗通常高于 Local Search。它的准确性还取决于社区报告是否忠实，报告一旦遗漏关键证据，最终答案也会受到影响。

Local Search：回答"某个对象和细节是什么"

Local Search 的目标是围绕问题中的实体建立一个局部上下文。典型流程如下：

1. 问题向量化和实体识别：把问题转换为向量，同时识别其中的车型、零件、材料、工艺或设计概念。
2. 实体召回：从实体描述、别名和向量索引中找到候选实体。
3. 图邻居扩展：读取候选实体连接的关系、相邻实体、出现过的文本单元和所属社区。
4. 证据排序：结合语义相似度、关系连接度、实体频率、来源质量和权限过滤，对候选证据排序。
5. 上下文拼装：将最相关的文本片段、关系描述、社区摘要和来源信息放入有限 token 的上下文中。
6. 生成答案：大模型基于这个局部上下文回答，并返回引用。

例如问题是"某车型的侧面比例与哪些设计元素相关？"系统会先定位该车型，再扩展到"短前悬、车顶线、轮胎尺寸、运动感"等邻居实体，最后从原始段落中抽取证据。

Local Search 通常比 Global Search 更快、更省 token，适合具体对象、局部事实和证据追溯。但它依赖实体识别：如果问题中的关键概念没有被抽成实体，或者实体别名没有归一化，系统可能找不到正确的图邻居，即使原文中确实存在相关内容。

Global 与 Local 的截图演示对比

建议使用同一批资料提出两类问题：

查询	模式	重点展示
"这些资料总结出的前脸设计趋势是什么？"	Global	多个社区报告、分批答案、最终综合
"车型 A 的侧面比例与哪些设计元素相关？"	Local	命中实体、邻居关系、原文片段和引用

讲解时可以强调：Global 是"先看主题，再综合全局"；Local 是"先找对象，再沿图查证据"。

不同主题如何聚合成一个社区

社区不是人工创建的文件夹，也不是模型随意写出的标签，而是根据实体关系图的连接结构自动发现的结果。可以用一个简化例子说明：

车型 A --采用--> 短前悬 --增强--> 运动感
车型 B --采用--> 低车顶 --影响--> 风阻表现
车型 A --使用--> 铝合金 --降低--> 车身重量
铝合金 --对应工艺--> 一体化压铸

如果"车型 A、短前悬、运动感、铝合金、一体化压铸"在许多文本单元中互相连接，社区发现算法会把它们划入一个较紧密的子图。另一个由"灯组、贯穿式尾灯、品牌识别、夜间视觉"组成的子图，则可能形成另一个社区。

在实现层面，GraphRAG 通常先建立实体关系图，再根据边的连接和权重执行图聚类/社区发现。连接紧密的实体被放在同一社区，连接较弱或跨主题的边形成社区之间的联系。社区还可以分层：底层社区描述一个具体车型或工艺，高层社区把多个底层社区概括成"运动化设计趋势"或"轻量化技术路线"。

随后，系统对每个社区生成报告：社区主题、关键实体、主要关系、共同结论、冲突点和来源。查询时，Global Search 主要使用这些报告，Local Search 则可以从具体实体进入所属社区并回溯原文。

需要注意，社区的质量不等于视觉上图画得漂亮。实体抽取错误、关系漏抽、别名未合并，都会把本应属于一个主题的节点拆散，或者把无关概念错误聚在一起。因此演示社区图时，应同时展示社区报告和几个原始引用。

全量重建成本来自哪里

Microsoft GraphRAG 的全量重建成本主要来自以下环节：

1. 所有文本重新切分和向量化：新增一个文件时，若采用全量流程，旧文件也会重新处理；embedding 调用次数与文本量近似线性增长。
2. 所有文本块重新抽取实体和关系：这是最主要的 LLM 成本来源。每个文本块至少需要一次抽取请求，可能还有补漏（gleaning）请求。
3. 实体和关系合并：跨文件合并、去重、计算频率和连接度需要重新扫描全体中间结果。
4. 社区重新发现：图发生变化后，社区划分可能整体变化，不能只简单追加一个节点。
5. 社区报告重新生成：社区层级和成员变化后，受影响社区及其上层社区需要重新摘要。
6. 索引和缓存写入：文本、实体、关系、社区报告和向量需要重新写入存储，并产生本地磁盘 I/O。

因此，成本不仅是"多调用几次模型"，还包括模型输入 token、输出 token、网络/本地推理时间、显存占用、向量计算和磁盘读写。资料库越大、社区层级越多、启用的补漏次数越多，重建时间和费用越明显。

当前项目应把索引设计为离线任务：上传后进入队列，显示"待处理/处理中/完成/失败"，不要在用户请求线程里同步等待。后续再评估按工作区分区、增量索引、受影响社区局部重建，或采用更偏实时更新的 LightRAG。

中文抽取质量取决于什么

中文抽取质量不是由 GraphRAG 单独决定的，主要受以下因素共同影响：

• 基础模型能力：模型是否擅长中文理解、实体边界识别和结构化输出。模型太小可能语义理解尚可，但容易漏字段或破坏元组格式。
• 提示词语言和领域指令：英文提示词要求输出 English 时，中文实体可能被翻译或改写；实体类型定义过宽，也会产生大量噪声。
• 上下文长度和切分策略 ：文本块过长会触发截断，过短则缺少关系上下文；本地 Ollama 还需要显式设置合适的 num_ctx。
• 输出格式约束与解析容错：关系强度字段缺失、括号多一个字符、模型输出 Markdown，都可能导致静默丢失关系，因此解析器必须容错并检查中间产物。
• 领域术语和输入质量：扫描 PDF 的 OCR 错误、表格排版、缩写、车型代号和中英文混杂都会影响抽取。
• 并发、温度和重试策略：本地显存不足或并发过高会导致响应截断；请求失败后的重试和结果校验也会影响最终数据。

对本项目来说，不能只看"索引命令成功"。应统计实体数、关系数、每个文本块的关系数量、关系权重分布、重复 ID、孤立实体和原始模型输出格式，并抽样人工核对。

实体别名会产生什么影响

GraphRAG 常见的实体合并依据是字符串或规范化后的名称。如果"比亚迪海豹""海豹""BYD Seal"没有被统一，系统可能建立三个节点：

比亚迪海豹 --采用--> 隐藏式门把手
海豹       --采用--> 低风阻轮毂
BYD Seal   --定位--> 运动化轿跑

实际上它们指向同一车型，但图上被拆成三个实体，会产生连锁影响：

1. 关系被拆散：同一车型的设计特征分布在多个节点下。
2. 社区被拆散：本应形成一个车型主题的关系被分到不同社区，社区摘要不完整。
3. Local Search 召回下降：用户问"海豹"时，可能只命中一个别名节点，找不到其他来源。
4. 实体频率和连接度失真：每个别名的出现次数降低，排序和社区划分受到影响。
5. Global Search 结论重复或矛盾：同一对象可能被摘要成多个"不同对象"。

工程上可以在索引前建立汽车术语和别名表，在抽取后做实体归一化，也可以在查询时扩展别名。需要保留原始名称用于引用，同时保存一个规范实体 ID，例如将"海豹""比亚迪海豹""BYD Seal"映射到同一个 canonical entity。别名归一化属于业务层的约束注入，不应完全依赖大模型自行判断。

第四部分：LightRAG 论文第三章梳理

整理范围：从论文第 3 章开始，到第 3.4 节结束。
说明：论文原文用"论文原文"标记并保留；"通俗解释"对原回答做了少量术语和表述校正。

3.1 图索引与增量知识库

论文原文

LightRAG 通过将文档分割成更小、更易于管理的片段来增强检索系统。利用大语言模型来识别和提取各种实体以及它们之间的关系，创建一个全面的知识图谱，该图谱突出显示整个文档集合中的连接和见解。

最终生成的知识图谱可表示为：

D̂ = (V̂, Ê)

其中，节点集合和边集合由各个文档片段中的识别结果合并得到：

V, E = ⋃ Recog(Dᵢ)

LightRAG 识别并合并来自不同片段的相同实体和关系，以最小化图谱规模并降低图操作开销。随后，为 V 中的每个实体节点和 E 中的每个关系边生成文本键值对 (K, V)。实体使用其名称作为唯一索引键；关系可以通过大语言模型增强获得多个索引键，这些索引键包括来自连接实体的全局主题。

这种设计带来两个优势：全面的信息理解和更高的检索性能。同时，LightRAG 可以对新文档 D′ 使用相同的图索引步骤 φ，得到新图 (V′, E′)，再与已有图合并：

V_new = V ∪ V′
E_new = E ∪ E′

通俗解释

LightRAG 的建库过程可以记成：

文档 → Chunk → LLM 抽取实体/关系 → 知识图谱 → 去重 → Key-Value/向量索引

• 实体（Entity） 是图里的节点，例如"苹果""Tim Cook""Apple Silicon"。
• 关系（Relation） 是节点之间的连接，例如"苹果---CEO→Tim Cook"。
• 去重把"Apple""Apple Inc."和"苹果公司"等指向同一对象的节点合并。
• Key-Value 索引把图中的实体和关系转换成便于文本检索的内容。

LightRAG 不是只用知识图谱，也不是只用向量数据库，而是把"图结构、文本索引和 LLM"结合起来。向量检索负责找到语义相近的候选项，图结构负责把候选项之间的关联展开。

增量更新时只处理新增文档，再把新图与旧图合并；但新增文档中出现的旧实体仍然需要去重，否则同一实体会在图中重复出现。

3.2 双层检索范式

论文原文

为了从特定的文档片段及其复杂的相互依赖关系中检索相关信息，LightRAG 提出在详细和抽象两个层次上生成查询键。

• 特定查询注重细节，通常引用图中的特定实体，需要精确检索与特定节点或边相关联的信息。例如："《傲慢与偏见》是谁写的？"
• 抽象查询更具概念性，涵盖更广泛的主题、摘要或总体主题，例如："人工智能如何影响现代教育？"

LightRAG 在双层检索范式中采用两种不同的检索策略：

• 低级检索：关注特定实体及其相关属性或关系。
• 高级检索：处理更广泛的主题和总体主题，跨多个相关实体和关系聚合信息。

LightRAG 整合图和向量以实现高效检索。对于给定查询 q，算法首先提取局部查询关键词 kₗ 和全局查询关键词 k𝗀；随后使用向量数据库，将局部查询关键词与候选实体匹配，将全局查询关键词与关联到全局键的关系匹配。为增强高阶关联性，LightRAG 进一步在检索到的图元素的局部子图中收集一跳相邻节点：

{vᵢ | vᵢ ∈ V ∧ (vᵢ ∈ Nᵥ ∨ vᵢ ∈ Nₑ)}

其中 Nᵥ 和 Nₑ 分别表示检索到的节点 v 和边 e 的一跳相邻节点。

通俗解释

3.2 解决的是："用户提问后，应该从知识库里找什么？"

• 具体问题用低级检索，例如"《傲慢与偏见》的作者是谁？"重点是找到"傲慢与偏见---作者→Jane Austen"。
• 宏观问题用高级检索，例如"人工智能如何影响现代教育？"需要跨多个实体和关系综合主题。

可以把两者理解成：

低级检索 = 放大镜：看一个对象附近的细节
高级检索 = 广角镜：看一个主题涉及的整体关系

查询会被 LLM 拆成两类关键词：

局部关键词 → 找候选实体
全局关键词 → 找候选关系和主题

向量负责"找语义上像的东西"，知识图谱负责"找这些东西之间的结构关系"。命中一个实体或关系后，LightRAG 还会扩展一跳邻居，形成一个局部子图，避免只返回孤立节点。

完整流程是：

Query → 局部/全局关键词 → 向量匹配 → 实体/关系 → 一跳邻居扩展 → 局部子图

这里的"高级检索"并不是让 LLM 直接总结整个知识库，而是先用全局关键词找到相关关系，再结合图结构进行聚合。

3.3 检索增强答案生成

论文原文

利用检索到的信息 ψ(q; D̂)，LightRAG 采用通用型大语言模型基于收集的数据生成答案。这些数据包含由分析函数 P(·) 生成的相关实体和关系的连接值 V。它包括实体名称、实体和关系的描述，以及原始文本的摘录。

通过将查询与这些多源文本统一，大语言模型生成符合用户需求的、信息丰富的答案，确保与查询意图一致。这种方法通过将上下文和查询整合到大语言模型中，简化了答案生成过程。

通俗解释

3.2 是"搜索"，3.3 是"把搜索结果整理成证据包，再让 LLM 写答案"。

用户问题
  ↓
检索实体、关系和原文
  ↓
取出对应的文本 Value
  ↓
整理成 Context
  ↓
Query + Context → LLM → Answer

交给 LLM 的不是裸图结构，而是：

• 实体名称；
• 实体描述；
• 关系及关系描述；
• 支撑这些结论的原始文本摘录。

因此，LightRAG 用图找到"哪些知识相关"，再把这些知识翻译成自然语言上下文，让 LLM 负责组织和表达答案。

3.4 LightRAG 框架的复杂度分析

论文原文

LightRAG 框架的复杂度可分为两个主要部分。

第一部分是基于图的索引阶段。在此阶段，使用大语言模型从每个文本块中提取实体和关系。因此，LLM 需要被调用总 token 数块大小的次数。此过程没有额外的开销，使方法在管理新文本更新方面高度高效。

第二部分涉及基于图的检索阶段。对于每个查询，首先利用大语言模型生成相关关键词。检索机制依赖于基于向量的搜索；与常规 RAG 中检索文本块不同，LightRAG 专注于检索实体和关系。与 GraphRAG 中使用的基于社区的遍历方法相比，这种方法显著降低了检索开销。

通俗解释与校正

复杂度可以分成两部分：

1. 图索引阶段：每个文本块需要经过 LLM，成本大致随文档总 token 数增长。新增文档时可以只处理新增部分，因此适合增量更新。
2. 图检索阶段：对用户问题提取关键词，再通过向量搜索定位实体和关系，最后做局部图扩展。它不需要一开始就遍历整张大图。

更准确地说，论文中的"没有额外开销"应理解为：索引成本主要与需要处理的文本规模线性相关，并且新增文本可以增量处理；这并不意味着 LLM 调用完全没有成本。

LightRAG 的"Light"主要体现在检索阶段：

Query → 关键词 → 向量搜索 → 相关实体/关系 → 局部一跳扩展

相比需要社区级遍历和聚合的方法，这种方式通常更轻量。但实际成本仍取决于文档规模、LLM 价格、文本切分、关键词生成次数、向量数据库和存储实现。

第 3 章总览

离线建库：
文档 → Chunk → Entity/Relation → Knowledge Graph → Key-Value/Vector Index

在线查询：
Query → Local/Global Keywords → Vector Retrieval → Entity/Relation
      → 一跳邻居扩展 → Text Context → LLM → Answer

LightRAG 的核心可以概括为：

向量负责找到相关内容，图结构负责把内容连接起来，LLM 负责基于证据生成答案。