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

参考博文基于图的 RAG 方法总结GraphRAG、 GraphReader、LightRAG、HippoRAG和KAGHippoRAG2024 nips HippoRAG (目前还在霸榜, 真的厉害)2025 iclr HippoRAG2论文地址https://arxiv.org/abs/2405.14831项目地址https://github.com/OSU-NLP-Group/HippoRAGHippoRAG 是一种受神经生物学启发的检索增强生成模型文本 → 抽实体/关系 → 建知识图谱query→ 找 query 里的实体/概念作为 seed→ 在图上做 PPR / 图扩散→ 一步召回多跳相关证据→ 给 LLM 生成答案实现细节HippoRAG 的核心创新是将人类海马体记忆机制引入 RAG。它利用 LLM 和 OpenIE 将文档转化为无模式知识图谱并通过语义相似边连接不同文档中的相关实体从而形成能够跨文档整合知识的长期记忆结构。在检索阶段HippoRAG 从问题中提取关键实体作为种子节点并使用个性化PageRank (PPR)在知识图谱中传播相关性一次检索即可发现多跳关联信息。相比依赖 LLM 反复检索和推理的方法它能够以更低成本、更高效率完成多跳检索。总体而言HippoRAG 的主要贡献是将LLM 知识抽取、知识图谱和 PPR 图检索结合起来实现具有联想能力的单步多跳检索。无模式知识图谱这里的“模式”指的是预先定义好的schema / ontology也就是提前规定有哪些实体类型有哪些关系类型哪些实体之间可以建立哪些关系例如有模式知识图谱可能会规定PersonCompanyUniversityPerson --founded-- CompanyPerson --studiedAt-- University无模式知识图谱schema-free knowledge graph**不会提前严格规定实体和关系类型。系统直接通过 OpenIE 从文本中抽取自然语言关系Steve Jobs --founded-- AppleSteve Jobs --attended-- Reed CollegeApple --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 节点*图检索阶段:PageRankretrieval core 是graph algorithm不是 LLM decision-makingseed nodes → Personalized PageRank / graph diffusion → rank relevant nodes/passagesPageRank 最早用于网页搜索核心思想是一个节点如果被许多重要节点连接那么它本身也比较重要。假设有网页 A、B、CA → BC → BB → D因为 A 和 C 都指向 B所以 B 的 PageRank 分数会比较高。普通 PageRank 关注的是整个图中节点的全局重要性与具体查询无关。GraphRAG因为确实有点繁琐工程上不太想用 所以这里主要留个流程chunk → 抽实体/关系 → 建图 → community detection →每个 community 生成 report → query 时检索/读取 community reports→ 回答红色的额外琐碎啊LightRAG2025 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 / deduplication2. 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 callGraphRAG 的重在于它会把图划分成很多 communities然后为每个 community 生成长 report。查询时还要处理很多 community report。LightRAG 直接在实体和关系的 key 上检索不需要遍历大量 community reports。论文在 Legal dataset 上给的对比很直观GraphRAG retrieval 阶段用了 610 个 level-2 communities每个 community report 平均 1000 tokens所以大约是610,000 tokensLightRAG 用少于100 tokens做关键词生成和检索而且只需要1 次 API call。所以它的 “light” 主要体现在GraphRAGquery → 扫大量 community reports → token 多、调用多LightRAGquery → 抽关键词 → 向量匹配实体/关系 → token 少、调用少4. Incremental update新增数据时不用重建整个图GraphRAG 如果来了新数据可能要重新构建 community structure 和 community reports。LightRAG 的思路是新文档来了以后只抽新文档里的实体和关系然后和已有图做 union / merge不用推倒重来。论文说这可以避免重建整个 index graph降低计算成本并加快适应新数据。KGGEN论文: KGGen: Extracting Knowledge Graphs from Plain Text with Language Models2025nips细节参考我之前的笔记好吧之前笔记是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 KGsaggregate 成大图然后反复用 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-k16最后让 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 加上已经访问过的 documentsaction 是从当前节点走到一个邻居节点reward 是最终 trajectory 能不能到达支持 query 的目标文档。论文明确把 KG retrieval 形式化为 state / action / transition / reward 的多步决策过程。不赖, 把召回这块按强化学习建模1. 把 KG-RAG retrieval 从“找最相关路径”改成“采样高奖励、多样路径”传统 KG-RAG 往往是最大化最相关结果容易只找到一个强相关节点导致结果不够 diverse。GraphFlow 的目标是P(trajectory) ∝ R(trajectory)也就是支持 query 越好的路径被采样概率越高但不是只取唯一最优路径所以它天然鼓励多样 retrieval2. 用 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 supervisionPRM 需要每一步都有过程奖励比如“这一步走得好不好”。但在 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。实际开放域场景里这种监督不一定容易拿到。