type
status
date
slug
summary
tags
category
icon
password
聊聊 GraphRAG 和 LazyGraphRAG 的区别
posted on 2024-01-10 by Alex Chen
最近在研究 RAG 技术栈，今天看到微软发布的 LazyGraphRAG 论文。这让我想起之前捣鼓过的 GraphRAG，两相对比之下发现了一些有趣的差异，在这里和大家分享一下。
基本认识
先说说这两个东西的本质区别：
特征 | GraphRAG | LazyGraphRAG |
核心思路 | 预先建好知识图谱 | 需要时才处理 |
处理时机 | 提前准备好一切 | 能推迟就推迟 |
资源消耗 | 前期投入大 | 平摊到使用时 |
响应特点 | 查询快，但不灵活 | 灵活，但可能稍慢 |
这么说可能有点抽象，我们可以打个比方：GraphRAG 就像提前做好了详细的目录和索引的图书馆，而 LazyGraphRAG 更像是有一个聪明的图书管理员，需要什么资料时他现查现找，但找的过程中会积累经验，越找越快。
技术细节
这两个技术在实现上的差异还挺大的：
环节 | GraphRAG 的做法 | LazyGraphRAG 的做法 |
提取概念 | 用 LLM 仔细分析文本 | 简单提取名词短语 |
建立联系 | 生成详细的知识图谱 | 记录概念同现关系 |
理解文本 | 预先生成各种摘要 | 用到时再总结 |
回答问题 | 主要查已有的摘要 | 现找资料现总结 |
实际表现
在使用中，我观察到这样的差异：
场景 | GraphRAG | LazyGraphRAG |
常规问答 | 很稳定 | 还不错 |
新颖问题 | 可能不够灵活 | 表现更好 |
系统负载 | early高late低 | 比较均衡 |
维护成本 | 更新比较麻烦 | 较为轻松 |
选择建议
说说我的个人建议：
如果你的场景是：
- 数据变化不大
- 预算充足
- 响应速度要求高 => 可以考虑 GraphRAG
如果你的情况是：
- 数据经常更新
- 预算有限
- 对灵活性要求高 => LazyGraphRAG 可能更合适
趋势判断
从技术发展来看，我觉得这两种方案会朝着融合的方向发展。就像我们现在的数据库既有预先建立的索引，又有动态优化一样。可能未来会出现一种既保留了 GraphRAG 的系统性，又具备 LazyGraphRAG 灵活性的混合方案。
小结
这两种技术都很有意思，选择哪个主要看具体需求。不过从学习的角度，我建议两个都了解一下，因为它们代表了 RAG 技术的两个重要思路。
- 参考资料：
- 微软研究院的 LazyGraphRAG 论文
- GraphRAG 官方文档 https://github.com/microsoft/graphrag
- 个人在项目中的使用心得*
标签: #RAG #LLM #GraphRAG #技术对比
- 作者:Doiiars
- 链接:http://doiiars.com/article/lazygraphrag.vs.graphrag
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。