在往期文章中，我们探讨了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页的大文档要处理半个小时，显然也是不合理的。也许这就是微软要开源的原因？依靠社群的力量去优化它。