在往期文章中，我们探讨了RAG的应用。然而，在实际使用过程中，我们发现传统RAG的表现并未完全满足预期（例如：在处理数据时，使用默认效果不佳，切片乱七八糟。因此需要花费很大精力去处理数据，比如编写文档时统一规范、使用一些工具/脚本对数据源进行预处理和清洗，这些比起AI本身的价值更大）。
为解决传统RAG的局限性，一种基于图结构的RAG应用应运而生，它被称为GraphRAG。
本篇文章，我们就来探索GraphRAG的魅力，看它是否真的能带来意想不到的惊喜。
什么是GraphRAG？
官网：https://microsoft.github.io/graphrag
微软开源的一项结合了知识图谱的检索增强生成技术。
简单来说，它可以显著提升AI知识库的性能，让AI能根据你提供的文档，更准确地回答你提出的复杂问题。
为什么需要GraphRAG？
关于AI知识库，传统的RAG即使结合了私有知识库，但是在使用过程中还是有很多值得吐槽的点，比如：精确度不够、AI总是回答不到点上。
这个问题的根源之一其实是传统RAG的局限性，当我们用这套技术去搭建知识库时，整个索引和检索的过程，都是基于文本块的。简单来说，就是我们把一个大的文档给切碎，变成一个又一个小的文本块，当有请求过来的时候，就根据请求去寻找哪些文本块是最相关、最匹配的，最后把找到的文本块作为参考资料，连同请求一起给到大模型。
这套技术有两个局限性：
无法有效捕捉实体之间的复杂关系和层次结构 通常只能检索固定数量的、最相关的文本块
也就导致了传统RAG在面对复杂查询的时候特别吃力。
为了补上传统RAG的短板，微软推出并且开源了GraphRAG，它的优势就是全局性。
Github：https://github.com/microsoft/graphrag
GraphRAG在对数据集建立索引的时候，会做两件事：
提取实体 Entity 提取实体之间的关系
从视觉上看，这些实体就是一个又一个的点，而有关联的两个实体，它会用线连接起来，于是一张庞大的知识图谱就形成了，这也是它名字里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
运行完命令后会看到多了几个文件，其中最重要的两个文件：
.env文件，在里面填上OpenAI API Key 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页的大文档要处理半个小时，显然也是不合理的。也许这就是微软要开源的原因？依靠社群的力量去优化它。
以上，完。
