知识图谱 Graph Rag 方法横向对比

参考博文

基于图的 RAG 方法总结（GraphRAG、 GraphReader、LightRAG、HippoRAG和KAG）

HippoRAG

2024 nips HippoRAG (目前还在霸榜, 真的厉害)

2025 iclr HippoRAG2

论文地址：https://arxiv.org/abs/2405.14831

项目地址：https://github.com/OSU-NLP-Group/HippoRAG

HippoRAG 是一种受神经生物学启发的检索增强生成模型

文本 → 抽实体/关系 → 建知识图谱
query

→ 找 query 里的实体/概念作为 seed
→ 在图上做 PPR / 图扩散
→ 一步召回多跳相关证据
→ 给 LLM 生成答案

实现细节

HippoRAG 的核心创新是将人类海马体记忆机制引入 RAG。它利用 LLM 和 OpenIE 将文档转化为无模式知识图谱，并通过语义相似边连接不同文档中的相关实体，从而形成能够跨文档整合知识的长期记忆结构。

在检索阶段，HippoRAG 从问题中提取关键实体作为种子节点，并使用个性化PageRank (PPR)在知识图谱中传播相关性，一次检索即可发现多跳关联信息。相比依赖 LLM 反复检索和推理的方法，它能够以更低成本、更高效率完成多跳检索。

总体而言，HippoRAG 的主要贡献是将LLM 知识抽取、知识图谱和 PPR 图检索结合起来，实现具有联想能力的单步多跳检索。

无模式知识图谱

这里的“模式”指的是预先定义好的schema / ontology，也就是提前规定：

• 有哪些实体类型
• 有哪些关系类型
• 哪些实体之间可以建立哪些关系

例如，有模式知识图谱可能会规定：

Person
Company
University

Person --founded--> Company
Person --studiedAt--> University

无模式知识图谱（schema-free knowledge graph）**不会提前严格规定实体和关系类型。系统直接通过 OpenIE 从文本中抽取自然语言关系：

Steve Jobs --founded--> Apple
Steve Jobs --attended--> Reed College
Apple --released--> iPhone

* seed种子节点

用户 query 来了之后，它要先找 query 对应到图里的哪些 entity / phrase / passage。这个地方会用 embedding similarity 或实体链接。

问题 query
→ LLM 抽 named entities
→ 用embedding找 KG 里最像的 node，这些 node 就是 PPR 的 seed

比如：

Which Stanford professor works on Alzheimer’s?

它会先抽：

Stanford Alzheimer’s

然后映射到 KG 里的：

Stanford 节点 Alzheimer’s 节点

*图检索阶段:PageRank

retrieval core 是graph algorithm，不是 LLM decision-making

seed nodes → Personalized PageRank / graph diffusion → rank relevant nodes/passages

PageRank 最早用于网页搜索，核心思想是：

一个节点如果被许多重要节点连接，那么它本身也比较重要。

假设有网页 A、B、C：

A → B
C → B
B → D

因为 A 和 C 都指向 B，所以 B 的 PageRank 分数会比较高。

普通 PageRank 关注的是整个图中节点的全局重要性，与具体查询无关。

GraphRAG

因为确实有点繁琐，工程上不太想用， 所以这里主要留个流程

chunk → 抽实体/关系 → 建图 → community detection →每个 community 生成 report → query 时检索/读取 community reports→ 回答

红色的额外琐碎啊！

LightRAG

2025 emnlp

目前主播用的baseline 是这个, 主要是全套代码比较成熟

Light RAG 可以说是 GraphRAG 的工程优化版

LightRAG 的创新是把 GraphRAG 从“社区报告驱动的重型图检索”，改成“实体/关系 key-value 驱动的轻量图检索”，再加上 low-level / high-level 双层 retrieval 和增量更新。

→ LLM 抽两类关键词
local keywords：具体实体/细节
global keywords：主题/抽象概念
→ local keywords 去匹配 entity
→ global keywords 去匹配 relation
→ 找到相关 entities / relations
→ 再扩展一跳邻居
→ 拿 entity/relation 的 description + 原文 chunks 给 LLM

亮点如下 ↓

1. Graph-based text indexing：把文本 chunk 变成实体-关系图

它不是只把 chunk embedding 存进向量库，而是先让 LLM 从 chunk 里抽取：

实体
关系
描述
key-value：用于后续检索的关键词和对应内容

后处理： profiling / deduplication

2. Dual-level retrieval：低层 + 高层双层检索 (核心设计)

低层 retrieval：查具体实体和关系。比如问 “Who wrote Pride and Prejudice?”，它需要精确找到 Jane Austen 这个实体。

高层 retrieval：查主题、概念、全局关系。比如问 “AI 如何影响现代教育？” 它需要跨多个实体和关系综合。

所以它会先让 LLM 从 query 里抽两类关键词：

local / low-level keywords：具体实体、细节
global / high-level keywords：主题、抽象概念

然后用向量库去匹配实体和关系，再扩展一跳邻居节点，形成回答上下文。论文明确说它把 local keywords 匹配到实体，把 global keywords 匹配到 relation/global keys，并结合一跳邻居增强上下文。

3. 为什么叫 Light：主要是相比 GraphRAG 更省 token、更少 API call

GraphRAG 的重在于：它会把图划分成很多 communities，然后为每个 community 生成长 report。查询时还要处理很多 community report。

LightRAG 直接在实体和关系的 key 上检索，不需要遍历大量 community reports。

论文在 Legal dataset 上给的对比很直观：

GraphRAG retrieval 阶段用了 610 个 level-2 communities，每个 community report 平均 1000 tokens，所以大约是610,000 tokens；
LightRAG 用少于100 tokens做关键词生成和检索，而且只需要1 次 API call。

所以它的 “light” 主要体现在：

GraphRAG：query → 扫大量 community reports → token 多、调用多
LightRAG：query → 抽关键词 → 向量匹配实体/关系 → token 少、调用少

4. Incremental update：新增数据时不用重建整个图

GraphRAG 如果来了新数据，可能要重新构建 community structure 和 community reports。LightRAG 的思路是：新文档来了以后，只抽新文档里的实体和关系，然后和已有图做 union / merge，不用推倒重来。论文说这可以避免重建整个 index graph，降低计算成本并加快适应新数据。

KGGEN

论文: KGGen: Extracting Knowledge Graphs from Plain Text with Language Models

2025nips

细节参考我之前的笔记（好吧之前笔记是arxiv版本的)

KGGEN: 用语言模型从纯文本中提取知识图-CSDN博客

这个其实主要是在构建KG 上面进行创新的，并不是完整rag 系统, focus on 怎么从文本抽一个更 dense 的 KG。

它指出一个很实际的问题：自动 KG 抽取后节点/边太碎，导致图稀疏、embedding 不好学、RAG 也不好用。

旧版

草了，五个阶段都用LLM，谁用得起我请问了 ↓

Plain text
→ LLM 抽 entities
→ LLM 基于 entities + 原文抽 subject-predicate-object triples
→ 聚合多个 source 的小图
→ normalize lowercase
→ LLM 迭代聚类 entities
→ LLM 迭代聚类 predicates / edges
→ LLM-as-judge 验证 cluster
→ 输出更 dense / coherent 的 KG

先抽实体，再抽关系，形成 initial KGs，aggregate 成大图，然后反复用 LLM 做 node / edge clustering，最后得到 final KG。

新版

对所有 entity/edge 做 S-BERT embedding
→ k-means 分成每组 128 个 item
→ 每个 item 在小 cluster 内用 BM25 + embedding 找 top-16 相似候选
→ LLM 只判断这些候选里哪些是 exact duplicates
→ 选择 canonical representative / alias
→ 删除已处理项，继续

先用 S-BERT 和 k-means 聚成 128 item 的小簇，再用 BM25 + semantic embedding 召回 top-k=16，最后让 LLM 判断 exact duplicates 并选择 canonical representative。

所以这版其实就是在回应你刚才说的 expensive 问题：不要让 LLM 从全量列表里找 cluster，而是先用便宜的 embedding / BM25 缩小候选，再让 LLM 做 verifier。

GraphFlow

论文 Can Knowledge-Graph-based Retrieval Augmented Generation Really Retrieve What You Need?

nips2026

这个主要focus 在召回阶段

假设你已经有 text-rich KG，重点研究query 时怎么在 KG 上走，才能 retrieve 到又准确又多样的节点/文档。

Text-rich KG + query
→ 找 initial node
→ 把 KG retrieval 建模成多步决策过程
→ 每一步从当前节点的邻居中选下一个节点
→ 收集沿途节点对应的文本 documents
→ 直到找到支持 query 的目标节点/文档
→ 用 outcome reward 训练 retrieval policy

这里的 state 是当前 query 加上已经访问过的 documents；action 是从当前节点走到一个邻居节点；reward 是最终 trajectory 能不能到达支持 query 的目标文档。论文明确把 KG retrieval 形式化为 state / action / transition / reward 的多步决策过程。

不赖, 把召回这块按强化学习建模

1. 把 KG-RAG retrieval 从“找最相关路径”改成“采样高奖励、多样路径”

传统 KG-RAG 往往是最大化最相关结果，容易只找到一个强相关节点，导致结果不够 diverse。GraphFlow 的目标是：

P(trajectory) ∝ R(trajectory)

也就是：支持 query 越好的路径，被采样概率越高；但不是只取唯一最优路径，所以它天然鼓励多样 retrieval

2. 用 GFlowNet 思路做 retrieval policy

它借了 GFlowNet 的思想：学习一个 policy，让生成出来的 trajectory 概率和 reward 成比例。这样不是简单训练“下一步应该走哪里”，而是训练一个能够探索多个高质量 retrieval targets 的策略。

这对复杂 query 有意义，比如：

“找 University A 发表的、和 topic B 相关的论文”

答案不是一个节点，而是一组 paper。普通 top-1 / 单路径检索容易漏掉很多正确结果。GraphFlow 的核心就是为这种multi-target retrieval服务。

3. 用 flow estimator 做 reward factorization，避免 process-level supervision

PRM 需要每一步都有过程奖励，比如“这一步走得好不好”。但在 KG 上标每一步 reward 很贵。GraphFlow 只需要最终结果的 outcome reward，然后用 flow estimator 把最终 reward 分解到中间状态，相当于给 retrieval policy 提供“免费的过程监督”。论文说它联合训练 retrieval policy 和 flow estimator，用 detailed balance objective 来优化，并通过 local exploration 减少访问低价值区域。

Limitation：

第一，它不轻。它用 LLaMA3-8B-Instruct 做 backbone，加 LoRA、policy head、flow head；实验资源是 8/16 张 NVIDIA A800 80GB GPU，加 56 核 Xeon CPU。

第二，它依赖已有 text-rich KG 和 ground-truth retrieval targets。
训练时需要知道哪些 target document / entity 支持 query。实际开放域场景里，这种监督不一定容易拿到。