GraphRAG:基于知识图谱的RAG,好用,贼贵!

转载请注明出处❤️

作者:测试蔡坨坨

原文链接:caituotuo.top/7d21f69b.html


你好,我是测试蔡坨坨。

在往期文章中,我们探讨了RAG的应用。然而,在实际使用过程中,我们发现传统RAG的表现并未完全满足预期(例如:在处理数据时,使用默认效果不佳,切片乱七八糟。因此需要花费很大精力去处理数据,比如编写文档时统一规范、使用一些工具/脚本对数据源进行预处理和清洗,这些比起AI本身的价值更大)。

为解决传统RAG的局限性,一种基于图结构的RAG应用应运而生,它被称为GraphRAG

本篇文章,我们就来探索GraphRAG的魅力,看它是否真的能带来意想不到的惊喜。

什么是GraphRAG?

官网:https://microsoft.github.io/graphrag

微软开源的一项结合了知识图谱检索增强生成技术

简单来说,它可以显著提升AI知识库的性能,让AI能根据你提供的文档,更准确地回答你提出的复杂问题。

为什么需要GraphRAG?

关于AI知识库,传统的RAG即使结合了私有知识库,但是在使用过程中还是有很多值得吐槽的点,比如:精确度不够、AI总是回答不到点上。

这个问题的根源之一其实是传统RAG的局限性,当我们用这套技术去搭建知识库时,整个索引和检索的过程,都是基于文本块的。简单来说,就是我们把一个大的文档给切碎,变成一个又一个小的文本块,当有请求过来的时候,就根据请求去寻找哪些文本块是最相关、最匹配的,最后把找到的文本块作为参考资料,连同请求一起给到大模型。

这套技术有两个局限性:

  1. 无法有效捕捉实体之间的复杂关系和层次结构
  2. 通常只能检索固定数量的、最相关的文本块

也就导致了传统RAG在面对复杂查询的时候特别吃力。

为了补上传统RAG的短板,微软推出并且开源了GraphRAG,它的优势就是全局性

Github:https://github.com/microsoft/graphrag

GraphRAG在对数据集建立索引的时候,会做两件事:

  1. 提取实体 Entity
  2. 提取实体之间的关系

从视觉上看,这些实体就是一个又一个的点,而有关联的两个实体,它会用线连接起来,于是一张庞大的知识图谱就形成了,这也是它名字里Graph的来源。

因为要表达复杂的关系,一个有效的手段就是利用图谱。

使用了知识图谱,GraphRAG能够把握复杂的、细微的数据关系,所以它才能构建一种全局性的优势,从而提升RAG的精确度。

如何使用GraphRAG?

官方文档:https://microsoft.github.io/graphrag/get_started

1. 安装GraphRAG

pip install graphrag

要下载的东西贼多,得耐心等待……

2. 创建目录

mkdir -p ./ragtest/input

3. 在ragtest/input文件夹中存入文档

在这里放入你的文档,目前只支持txt、csv。

官网给的示例文档查尔斯·狄更斯的《圣诞颂歌》:

curl https://www.gutenberg.org/cache/epub/24022/pg24022.txt -o ./ragtest/input/book.txt

PS:如果你用的OpenAI,不要跑这个文件,200页 11$ 贼贵…… 就…… 离谱

4. 初始化项目

graphrag init --root ./ragtest

运行完命令后会看到多了几个文件,其中最重要的两个文件:

  1. .env文件,在里面填上OpenAI API Key
  2. settings.yaml文件,用来设置encoding和embedding所需要的模型及各种参数,使用本地大模型的话就在这里配置

5. 开始创建索引

graphrag index --root ./ragtest

6. 开始进行问答

graphrag query \
--root ./ragtest \
--method global \
--query "What are the top themes in this story?"
graphrag query \
--root ./ragtest \
--method local \
--query "Who is Scrooge and what are his main relationships?"

使用本地大模型

settings.yaml文件中修改大语言模型和嵌入式模型:

本地大模型在配置上没什么问题,但是在运行时贼慢,一个是建立索引时提取时间非常漫长,另一个是嵌入时也非长漫长,相比于GPT4几分钟就完成了,本地llama3 8b体量上还是有点差距的。在实际应用中一个200页的大文档要处理半个小时,显然也是不合理的。也许这就是微软要开源的原因?依靠社群的力量去优化它。

posted @ 2024-12-14 14:54  测试蔡坨坨  阅读(23)  评论(0编辑  收藏  举报