在之前的文章中，我们已经探讨过 RAG 的应用场景。然而，实际部署后你会发现，传统 RAG 的表现远不如预期——例如在默认配置下处理数据时，切片杂乱无章，效果难以令人满意。于是，你不得不投入大量精力去统一文档规范、借助脚本进行数据清洗，结果却发现这些琐碎付出的价值甚至超过了 AI 本身，这多少有些本末倒置。
正是为了弥补传统 RAG 的这些不足，一种基于图结构的检索增强生成方案——GraphRAG——应运而生。本文将深入剖析 GraphRAG 究竟有何神奇之处，是否真的能带来令人惊喜的效果。
什么是 GraphRAG？
官网：https://microsoft.github.io/graphrag
这是微软开源的一项融合了知识图谱的检索增强生成技术。简单来说，它能够显著提升 AI 知识库的表现——根据你提供的文档，更精准地回应那些相对复杂的提问。
为什么需要 GraphRAG？
关于 AI 知识库，传统 RAG 即使接入了私有数据，实际使用中依然存在不少问题：精确度不足，AI 经常答非所问。其根源在于传统 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
需要提醒的是，如果你使用的是 OpenAI，请谨慎运行这个文件——200 页的内容处理下来需要花费 11 美元，成本相当高昂……
4. 初始化项目
graphrag init --root ./ragtest
执行完命令后，你会看到多出几个文件。其中最重要的两个：一个是 .env 文件，用于填写 OpenAI API Key；另一个是 settings.yaml，用于配置编码和嵌入所需的模型及其参数——如果使用本地大模型，就在这里进行设置。
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 文件中修改大语言模型和嵌入式模型即可。
本地大模型在配置方面没有太多坑，但运行时确实非常缓慢——建立索引时实体提取耗时较长，嵌入过程也慢得离谱。相比之下，GPT-4 几分钟就能完成，而本地 llama3 8b 的性能差距明显。在实际场景中，一个 200 页的大文档需要处理半小时，这显然不太现实。或许这就是微软选择开源的原因——依靠社区的力量持续优化它吧。