目录

GraphRAG 核心原理学习笔记

在构建以大语言模型（LLM）为核心的智能体（Agent）系统时，外部知识检索与记忆组织始终是决定应用落地深度的核心命题。

从传统的向量 RAG（Naive / Advanced RAG）到融入拓扑关联的 GraphRAG（Graph Retrieval-Augmented Generation，图增强检索生成），知识召回与推理方式正在经历一场范式升级。

本文将从 Agent 与 RAG 的基本概念出发，系统剖析向量 RAG 的固有瓶颈、GraphRAG 的核心技术原理与主流生态，并介绍一个用纯原生 Go 语言打造的高性能、轻量级嵌入式 GraphRAG 核心引擎 —— StarGraph。

LLM Agent 与 RAG 基础

什么是 LLM Agent？

大语言模型本质上是一个基于海量语料训练出的概率文本生成器。然而在实际工程中，单靠 Prompt-Response 模式无法完成复杂的端到端任务。

LLM Agent（智能体） 是以 LLM 作为核心认知大脑（Reasoning Engine），结合以下关键模块协同工作的自主计算架构：

D2 Diagram
qtopie.github.io

为什么需要 RAG？

LLM 存在三大公认的天然缺陷：

  1. 知识截止期（Knowledge Cutoff）：无法获知训练集截断后的最新动态与实时信息。
  2. 私有域数据黑盒：无法直接掌握企业内部 Wiki、业务代码库或个人私有文档。
  3. 幻觉（Hallucination）：面对未见过的知识或模糊事实时倾向于“一本正经地胡说八道”。

RAG（Retrieval-Augmented Generation，检索增强生成） 的核心思想非常简洁：“开卷考试”。在让 LLM 回答问题前，先从外部专有知识库中检索出与提问最相关的文档片段（Context），将其与原始 Query 一并塞入 Prompt，交由 LLM 整合生成可溯源的事实性回答。

经典的向量 RAG 管道通常包含三个标准阶段：

  1. Index（索引）：文档切块（Chunking） → 文本嵌入（Embedding） → 存入向量数据库（Vector DB）。
  2. Retrieve（检索）：将用户查询向量化 → 计算余弦相似度 / 语义 Top-K → 召回最相近的 Chunk。
  3. Generate（生成）：将召回的 Context 拼装进 System Prompt → LLM 生成事实性回答。

传统向量 RAG 的痛点与为什么需要 GraphRAG

虽然向量 RAG 在点对点事实问答（如“查询某接口的入参格式”）中表现优异，但在复杂业务场景下，其“切块 + 语义相似度召回”的底层机理暴露出了致命的局限。

传统向量 RAG 的典型挑战

  1. 跨文档多跳推理失效（Multi-hop Reasoning Failure）
    • 向量检索依赖 Query 与 Chunk 之间的直接语义/关键词相似度。
    • 如果问题涉及链式实体关联（例如：A 依赖 B，B 属于 C，C 由 D 负责，请问 A 和 D 是什么协作关系？），由于 A 所在文档与 D 所在文档不存在直接字面关联，中间跳数超过 1 跳时，向量距离极远，导致关键线索无法被召回，LLM 只能回答“未提及相关信息”。
  2. 缺乏全景宏观总结能力（Global Summarization Blindspot）
    • 面对高层次宏观提问（如 “请总结当前数据中心在过去一年的核心风险主题有哪些？”），知识分散在成百上千个分块中，单一 Query 无法匹配所有相关分块，Top-K 机制直接失效。
  3. 信息碎片化与语境孤岛（Context Fragmentation）
    • 文本被硬性切分为 Chunk 后，跨分块的代词指代、前置背景、逻辑因果链被切断，导致检索出的上下文存在语义断层。

什么是 GraphRAG？

GraphRAG（Graph Retrieval-Augmented Generation，图增强检索生成） 是一种将知识图谱（Knowledge Graph）的拓扑结构与大语言模型（LLM）的自然语言理解能力深度融合的下一代检索增强架构。

GraphRAG 不再将文档视作互不相干的扁平文本切片，而是在索引阶段通过 LLM 抽取出结构化的实体（Entities）、关系（Relations）与事实主张（Claims），构建出一张全局拓扑语义网络；并在检索阶段借助子图遍历、图聚类社区报告（Community Summaries）与自适应图推理，完成局部精准多跳与全局宏观全景两类高阶检索任务。

D2 Diagram
qtopie.github.io

GraphRAG 适用场景与当前主流方案

典型适用场景

场景类别典型应用为什么需要 GraphRAG
企业级统一知识库
(Enterprise KB)		• 跨部门/跨系统文档穿透（Confluence, Notion, 飞书文档）
• 组织架构-业务领域-数据资产全景映射
• 跨产品线制度与流程规范多跳检索		企业知识通常分散在各个部门的文档孤岛中。传统向量检索仅能找到字面相关的单个段落，而 GraphRAG 能构建 部门-负责人-业务系统-技术文档-制度规章 的网状全景图，准确解答 “某业务规范变更会影响哪些部门的哪些系统和负责人” 等跨域连带问题。
DevOps & 研发项目管理
(DevOps & Project Management)		• 微服务依赖拓扑与变更影响面分析（Impact Analysis）
• 需求-Issue-PR-发布版本全链路追溯
• 线上事故（Incident）根因定位与排障建议
• 研发人员流动时的领域知识交接与专家寻找		软件研发流程本质上是高度结构化的图网络（Requirement ──> PRD ──> Jira Issue ──> Git Commit ──> CI/CD Pipeline ──> Service ──> Alert）。传统 RAG 无法关联链路；GraphRAG 沿拓扑链路可秒级回答 “修改 Service A 的某个 API 会间接影响哪些下游服务和待发布需求？” 或 “当前告警关联的历史故障有哪些？”。
复杂关系链挖掘金融反洗钱、企业股权穿透、供应链上下游风险传导依赖多层级跨实体、跨文档的显式因果图谱与拓扑可达性分析。
大型宏观全景总结财报全景解读、海量用户反馈主题聚合、代码仓库架构巡检依赖基于图聚类的多层次社区报告与 Map-Reduce 总结机制。
跨域知识图谱问答医疗诊断辅助（病症-药物-禁忌）、法律法规交叉引用消除实体歧义与长程逻辑链路断裂，要求回答具备严格的可溯源拓扑路径。

GraphRAG 的优势与局限性 (Pros & Cons)

在评估是否引入 GraphRAG 时，需要全面权衡其带来的收益与工程代价：

核心优势 (Pros)

  1. 确定性多跳推理能力：通过图的邻接边和 BFS 遍历，将跨文档隐含逻辑转化为显式拓扑路径，彻底解决向量检索跨跳丢失的问题。
  2. 全局宏观洞察与总结：借助层次化社区发现（Community Detection）与社区报告，能够对海量数据集进行全景式、主题式的 Map-Reduce 归纳。
  3. 高可解释性与严密溯源：知识以结构化三元组和子图呈现，回答的依据能够精准溯源到具体的实体、关系及对应来源 Chunk，显著降低大模型幻觉。
  4. 实体消歧与语义对齐：通过实体归一化将同义词、简称、别名合并至同一节点，避免向量检索因用词差异导致的信息割裂。

局限与挑战 (Cons)

  1. 索引成本高（Token & Time）：索引阶段需要调用 LLM 进行逐块实体关系抽取以及生成社区报告，初次建图耗费的 Token 和时间显著高于传统向量切块。
  2. 图谱动态更新与维护复杂：增量文档接入时，涉及实体合并、边权重更新、社区重新聚类及报告级联更新，写放大与并发维护成本较高。
  3. 抽取质量依赖 LLM 能力：如果上游 LLM 的抽取能力较弱或 Prompt 未针对垂直领域调优，图谱可能引入噪音实体和错误关系，影响下游推理。
  4. 架构复杂度增加：相比单一向量库，GraphRAG 往往需要同时维护向量检索、图邻接关系与社区缓存，对工程基础设施要求更高。

当前主流开源与商业方案概览

  1. Microsoft GraphRAG
    • 特点：微软官方开源的 GraphRAG 标杆项目，确立了“LLM 实体抽取 → Leiden 层次化社区检测 → 社区摘要报告 → Global/Local Search”的标准流水线。
    • 局限：基于 Python 构建，重度依赖外部重型图库与大量异步任务编排，全量索引耗费大量 Token 与算力，轻量级嵌入场景成本较高。
  2. NebulaGraph / Neo4j GraphRAG
    • 特点：以成熟图数据库为底座，结合 Cypher/nGQL 查询生成与图算法（PageRank、Louvain）提供高性能图检索。
    • 局限：系统运维成本高，需要部署独立且重量级的分布式图数据库实例。
  3. LlamaIndex Property Graph Index
    • 特点：在现有 Python 框架中引入属性图索引，支持向量与图结构混合检索。
    • 局限：依然受限于 Python 运行时生态，单二进制分发与边缘端支持较弱。

GraphRAG 的核心技术原理

GraphRAG 的工作流分为两个核心阶段：知识图谱构建与社区索引（Indexing Pipeline） 与 自适应多模式图检索（Search Pipeline）。

D2 Diagram
qtopie.github.io

索引管道（Indexing Pipeline）

递归语义分块（Recursive Semantic Chunking）

LLM 并发实体与关系抽取（Entity-Relation Extraction）

💡 深入理解：为什么这里的“三元组”看起来是 5 维结构？

经典知识图谱（如 RDF 规范）中的三元组严格由 3 个元素构成，即 S-P-O（主-谓-宾）：(Subject 主体, Predicate 谓词/关系, Object 客体)。

但在 GraphRAG 体系中，为了支撑大模型的深度语义推理，传统三元组被扩展为了属性图（Property Graph）中的一条富属性边（Edge）：

D2 Diagram
qtopie.github.io
  • Description（语义上下文）：直接沉淀关系发生时的具体语境和细节。在局部子图推理时，LLM 只读边的 Description 就能获取丰富背景，避免反复反查海量原始文档分块。
  • Weight（置信度/共现强度）：多处提及或高置信度的关系会被累加权重，供后续 Louvain / Leiden 等拓扑聚类算法计算紧密社区。

因此，业界口头沿用“三元组抽取”术语，本质上对应的是**“带属性的关系边抽取（Property Graph Edge Extraction）”**。

图拓扑聚类（Graph Clustering）

D2 Diagram
qtopie.github.io

社区报告自底向上生成（Hierarchical Community Summaries）

双通道检索引擎（Dual-Channel Search Engine）

在索引阶段构建好“底层实体关系图”与“上层分层社区摘要”后，检索阶段根据问题的粒度特征，提供了微观精准定位与宏观全局归纳的双通道检索范式：

D2 Diagram
qtopie.github.io

局部检索：Local Search（微观多跳与精准因果）

D2 Diagram
qtopie.github.io

全局检索：Global Search（宏观全景与主题聚合）

D2 Diagram
qtopie.github.io

自适应意图路由：Auto Intent Router

降本增效：GraphRAG 三大前沿技术优化与原理

早期 GraphRAG 方案（以初代微软 GraphRAG 为代表）在实际落地中常面临“建库 Token 消耗巨大、索引极其昂贵、高并发检索延迟高”的工程痛点。随着技术演进，工业界与学术界提出了三大关键优化范式，从索引建库顺序、三元组抽取方式到在线检索路由实现了全链路的降本增效：

D2 Diagram
qtopie.github.io

采用“推迟提取”架构（LazyGraphRAG / LightRAG）

用小模型或无模型提取法（AGRAG 架构）

查询阶段：使用 DRIFT Search 代替暴力全局搜索

StarGraph：纯原生 Go 的高性能 GraphRAG 核心引擎

在实际落地工程中，许多智能助理（如端侧 Agent、团队协作 CLI、私有部署网关）对运行环境、启动速度和内存占用有着严苛的要求。StarGraph (github.com/qtopie/stargraph) 正是在这一背景下诞生。

为什么选择 StarGraph？

快速上手示例

package main

import (
	"context"
	"fmt"
	"log"

	stargraph "github.com/qtopie/stargraph/pkg"
	"github.com/qtopie/stargraph/pkg/document"
	"github.com/qtopie/stargraph/pkg/llm"
	"github.com/qtopie/stargraph/pkg/search"
)

func main() {
	ctx := context.Background()

	// 1. 初始化 LLM 与 Embedding 客户端 (兼容 OpenAI / DeepSeek / Ollama)
	llmClient := llm.NewOpenAIClient("https://api.openai.com/v1", "your-api-key", "gpt-4o")
	embedClient := llm.NewOpenAIClient("https://api.openai.com/v1", "your-api-key", "text-embedding-3-small")

	// 2. 初始化 StarGraph 引擎
	engine := stargraph.NewEngine(llmClient, embedClient, stargraph.DefaultConfig())
	defer engine.Close()

	// 3. 索引具有跨文档隐含关系的文档集
	docs := []*document.Document{
		{
			ID:      "doc-1",
			Content: "Alice 是 CosmosStar 旗下 Project Phoenix 的架构负责人。",
		},
		{
			ID:      "doc-2",
			Content: "Project Phoenix 核心数据层深度依赖 Quantum DB 分布式图存储引擎。",
		},
		{
			ID:      "doc-3",
			Content: "Quantum DB 由基础架构团队的资深工程师 Bob 独立主导研发与维护。",
		},
	}

	if err := engine.Insert(ctx, docs...); err != nil {
		log.Fatalf("索引构建失败: %v", err)
	}

	// 4. Local Search 跨文档多跳关系推理
	localRes, err := engine.Query(ctx, &search.Request{
		Query:   "Alice 和 Bob 之间有什么隐式业务协作或依赖关系？",
		Mode:    search.ModeLocal,
		TopK:    3,
		MaxHops: 2,
	})
	if err != nil {
		log.Fatalf("查询失败: %v", err)
	}

	fmt.Printf("【Local Search 多跳推理结果】:\n%s\n", localRes.Answer)

	// 5. Global Search 宏观全景总结
	globalRes, err := engine.Query(ctx, &search.Request{
		Query: "请总结当前知识图谱中的核心组织结构与技术架构关系。",
		Mode:  search.ModeGlobal,
	})
	if err != nil {
		log.Fatalf("全局总结失败: %v", err)
	}

	fmt.Printf("\n【Global Search 宏观总结结果】:\n%s\n", globalRes.Answer)
}

跨文档多跳推理实测对比

提问场景传统向量 RAG (Naive RAG)StarGraph (GraphRAG)
“Alice 和 Bob 之间有什么协作关系？”❌ 召回失败。
由于 Doc 1（Alice）与 Doc 3（Bob）字面没有交集，向量距离远，无法召回。
回答：“未提及两者的关联。”		✅ 成功推理。
沿拓扑边打通：Alice $\rightarrow$ Phoenix $\rightarrow$ Quantum DB $\leftarrow$ Bob。
回答：“Alice 领导的 Project Phoenix 依赖 Bob 维护的 Quantum DB，两者存在上下游架构依赖。”
“总结系统的整体架构与核心责任人”⚠️ 局部缺失。
仅随机召回 Top-K Chunk，容易漏掉关键组件。		✅ 全局聚合。
利用分层社区报告通过 Map-Reduce 生成完整技术全景视图。

知识库双雄演进：Google Enterprise Knowledge Graph 与 GraphRAG 深度横向对比

在大模型知识增强（Knowledge-Augmented LLM）的演进道路上，业界形成了两种截然不同但高度互补的技术流派：

  1. 以 Microsoft GraphRAG / LightRAG 为代表的“非结构化文本语义抽取与社区发现范式”；
  2. 以 Google Cloud Enterprise Knowledge Graph (EKG) 为代表的“结构化主数据实体调和与本体 Grounding 范式”（Google AI Overviews 及 Gemini 核心知识增强基座）。
D2 Diagram
qtopie.github.io

核心维度多维横向对比

核心维度Microsoft GraphRAG / LightRAG / StarGraphGoogle Enterprise Knowledge Graph (EKG)
原生数据形态纯非结构化文本（海量研报、业务文档、代码仓库、维基百科）大规模结构化 / 半结构化业务数据（BigQuery、CRM、ERP、交易主表）
图构建与抽取机制LLM 语义驱动抽取：通过 Prompt 驱动 LLM 开放抽取三元组与文本摘要Schema.org 模式映射 + 规则 ETL：严格绑定业界本体标准（Organization、Person 等）
实体消歧与对齐 (Entity Resolution)弱 / 依赖 Prompt 模糊归一，跨文档重名或拼写变体容易造成重复实体节点强 / 核心杀手锏（实体调和 Recon）：利用 google_brasil 等专用 ML 识别同一实体的多种变体
底层聚类与分层算法Leiden 社区发现算法（基于模块度增量 $\Delta Q$ 与严格物理连通性保证）并行亲和聚簇（Parallel Affinity Clustering） 与连通分量，支持数亿级别的大数据批处理
查询与推理交互双通道检索（Local / Global / DRIFT Search）：拓扑多跳穿梭与 Map-Reduce 报告归纳精准图查询 + 语义对齐检索：通过 Entity Linking 注入精确上下文
LLM 协作定位动态推理与因果链打通：为生成模型提供结构化多跳上下文与全局宏观背景事实性真理底座（Grounding Source）：作为 Gemini 等模型的事实校验器，从源头消灭幻觉
建库算力与 Token 开销建库期重度依赖 LLM 推理（经 LazyGraphRAG/AGRAG 优化可大幅降低）零 LLM 抽取成本，完全依赖 BigQuery / CPU 算力集群进行批量特征工程与聚簇运算

Google EKG 核心技术原理解析

1. Schema.org 工业级标准本体映射

与 GraphRAG 让大模型自由提取开放实体与关系类型不同，Google EKG 强调企业级数据资产的可解释性与严谨一致性：

2. 企业级实体调和作业（Entity Reconciliation）

多源企业系统中对同一实体的记录通常分散且充满噪声（例如 CRM 系统中的 “Alphabet Inc.” 与 ERP 中的 “Google LLC 母公司”，或由于拼写缩写导致的冗余分块）。Google EKG 的处理流水线包含四个阶段：

  1. 知识提取（Knowledge Extraction）：从 BigQuery 数据集抽取字段并自动构建高维多模态特征。
  2. 调和预处理（Recon Preprocessing）：运用地理编码隔离（Geocoding Isolation）等硬性业务规则过滤不合理候选。
  3. 并行亲和聚簇（Parallel Affinity Clustering）：基于层次凝聚聚类的分布式并行优化，对亿级实体对进行相似度打分与聚类合并。
  4. 生成永久 Cluster ID 并导出（Exporting Clusters）：为每个聚类分配全局唯一的稳定 ID 并写回 BigQuery，形成高纯净度的统一主知识图谱。

3. 与大语言模型（Gemini）的 Grounding 协作机制

在 Google AI（如 Gemini、AI Overview）中，图谱的核心价值在于充当 Fact-Checking & Grounding（事实锚定）：

总结与展望

从传统的文本向量匹配到具备结构化图推理与多层次摘要的 GraphRAG，是构建复杂知识密集型 Agent 的必经之路。

  1. 向量检索解决了“语义相似匹配”，而 GraphRAG 解决了“结构因果关联与全局视野”。
  2. 通过 Local Search 与 Global Search 的双通道配合，无论是微观的跨跳路径推理，还是宏观的社区全局归纳，都能得到精准解答。
  3. StarGraph 证明了通过纯原生 Go 语言同样可以构建出轻量、极速且功能完备的 GraphRAG 核心引擎，为云原生微服务、桌面端及边缘嵌入式 Agent 提供了极佳的基础设施选择。

附录：核心图社区发现算法详解

在 GraphRAG 索引流程中，社区发现（Community Detection） 是连接微观实体关系抽取与宏观分层摘要报告的关键桥梁。本附录系统剖析其背后的数学度量指标（模块度）与两大经典算法（Louvain 与 Leiden）的具体实现机制。

D2 Diagram
qtopie.github.io

模块度优化（Modularity Optimization）

算法总体思想：分层迭代聚类

从一个原始图结构中划分出高模块度社区，主流算法（如 Louvain 或 Leiden）通常采用**“局部贪心移动 + 图折叠粗粒化”**的分层迭代过程：

D2 Diagram
qtopie.github.io

💡 注：在工业级常用的 Leiden 算法 中，还在两阶段之间加入了社区细化（Refinement）阶段，用于保证折叠后的每个超节点在物理拓扑上都严格连通。

模块度数学定义与核心原理解析

模块度（Modularity，$Q$） 是带权无向网络中用于衡量社区划分质量的标准标量指标。

对于带权无向图 $G=(V, E)$，标准模块度定义公式如下：

$$Q = \frac{1}{2m} \sum_{i,j} \left[ A_{ij} - \gamma \frac{k_i k_j}{2m} \right] \delta(c_i, c_j)$$

模块度增量计算（$\Delta Q$）

在算法迭代过程中，如果每次尝试移动节点都对全图重新计算全局模块度 $Q$，计算复杂度极高（$O(|V| \cdot |E|)$）。

因此，Louvain 与 Leiden 算法均采用局部增量更新（Delta Modularity Calculation）：将孤立节点 $i$ 移入社区 $C$ 时，除节点 $i$ 和社区 $C$ 之外的其他社区结构完全保持不变，只需在局部 $O(1)$ 或 $O(\text{deg}(i))$ 时间内计算模块度的增量 $\Delta Q$。

$$\Delta Q = \left[ \frac{\Sigma_{\text{in}} + 2k_{i,\text{in}}}{2m} - \left( \frac{\Sigma_{\text{tot}} + k_i}{2m} \right)^2 \right] - \left[ \frac{\Sigma_{\text{in}}}{2m} - \left( \frac{\Sigma_{\text{tot}}}{2m} \right)^2 - \left( \frac{k_i}{2m} \right)^2 \right]$$
$$\Delta Q = \frac{k_{i,\text{in}}}{m} - \gamma \frac{\Sigma_{\text{tot}} \cdot k_i}{2m^2}$$
$$\Delta Q_{\text{total}} = \Delta Q_{\text{remove}} + \Delta Q_{\text{insert}}$$
  1. 从旧社区移出（Remove $i$ from $C_{\text{old}}$）：计算将 $i$ 剥离为孤立节点的增量 $\Delta Q_{\text{remove}}$。
  2. 移入新候选社区（Insert $i$ into $C_{\text{new}}$）：计算将孤立节点 $i$ 并入 $C_{\text{new}}$ 的增量 $\Delta Q_{\text{insert}}$。 算法遍历节点 $i$ 的所有邻居所在社区，选择使 $\Delta Q_{\text{total}}$ 取得最大正值的目标社区进行迁移；若所有候选社区均满足 $\Delta Q_{\text{total}} \le 0$，则节点留在原社区。

Louvain 算法实现原理

Louvain 算法由 Blondel 等人于 2008 年提出，是一种基于贪心启发的两阶段迭代式层级聚类算法。

核心步骤

  1. Phase 1（局部贪心移动，Local Node Moving）：
    • 初始化时，图中的每一个节点都独立作为一个单独的社区。
    • 依次遍历图中的每个节点 $i$：
      • 计算将节点 $i$ 从当前社区移出、并移入其所有邻居节点所在社区时的模块度增量 $\Delta Q$。
      • 选择能带来最大正向 $\Delta Q$（$\Delta Q > 0$）的邻居社区将 $i$ 移入。
      • 若所有邻居社区均无法带来正向收益，则节点 $i$ 保留原社区。
    • 重复遍历所有节点，直到全图没有任何节点的移动能进一步提升模块度（达到局部最优收敛）。
  2. Phase 2（图折叠粗粒化，Graph Aggregation）：
    • 将第一阶段识别出的每个社区收缩（Collapse）折叠为一个单独的“超节点（Super Node）”。
    • 超节点内部节点之间的所有边权重累加为该超节点的自环（Self-loop）权重。
    • 两个不同社区之间的跨社区边权重相加，构成两个对应超节点之间的边权重。
  3. 分层递归迭代（Hierarchy Iteration）：
    • 在生成的粗粒化超节点图上，重新执行 Phase 1 和 Phase 2。
    • 逐层构建层次树（Dendrogram），直至整个图的拓扑无法再聚合出更高的模块度增益。

局限与病态缺陷

Leiden 算法实现原理与优化

为了彻底解决 Louvain 算法容易生成非连通社区及收敛慢的问题，Traag 等人于 2019 年在《From Louvain to Leiden: guaranteeing well-connected communities》中提出了 Leiden 算法。Leiden 证明了其生成的每一个子社区在拓扑上都具备**严格连通性（Well-connectedness）**与更高的模块度。

三阶段核心流水线

Leiden 将 Louvain 的两阶段循环重构为更加严谨的三阶段流水线：

算法对比总结

特性维度Louvain 算法Leiden 算法
拓扑连通性保证❌ 无保证，常产生非连通/断裂社区✅ 严格数学保证，所有社区物理连通
流水线阶段2 阶段（Local Move → Aggregate）3 阶段（Local Move → Refinement → Aggregate）
收敛速度遍历全节点，后期慢队列激活 + 局部计算，整体速度提升 2~5 倍
GraphRAG 适用性易产生散碎无因果关联的聚合报告工业级标准（Microsoft GraphRAG / StarGraph 默认推荐）

参考与扩展阅读

  1. Microsoft Research GraphRAG: From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Darren Edge et al., 2024)
  2. Microsoft Research DRIFT Search: DRIFT: Dynamic Reasoning and Inference over Flexible Topologies for Graph RAG (2024)
  3. LightRAG: LightRAG: Simple and Fast Knowledge Graph Retrieval-Augmented Generation (2024)
  4. StarGraph Engine: qtopie/stargraph - Ultra-lightweight Embedded GraphRAG Engine in Pure Go
  5. Leiden Community Detection Paper: From Louvain to Leiden: guaranteeing well-connected communities (Scientific Reports, V. A. Traag, L. Waltman, N. J. van Eck, 2019)
  6. Louvain Community Detection Paper: Fast unfolding of communities in large networks (J. Stat. Mech., Vincent D. Blondel et al., 2008)
  7. Modularity Optimization & Networks: Newman, M. E. J. (2006). Modularity and community structure in networks. PNAS, 103(23), 8577-8582.
  8. Google Cloud Enterprise Knowledge Graph: Enterprise Knowledge Graph Overview & Entity Reconciliation
  9. LlamaIndex Property Graph Index: Building Property Graph Index with LLMs
  10. NebulaGraph & Neo4j: Graph Database in GenAI & GraphRAG Architectures