本文介绍上个月很火的微软开源的GraphRAG 项目, 当时出来时就只是简单看了看, 这等了快 1 月等有人落地验证后我再继续看, 这样效率会很高

根据之前的经验, 像我本来就不是技术出身, 面对新的技术的试错成本太大,刚出来的项目社区,教程都还不成熟

接下来看看 GraphRAG 的架构和目前用户的部署反馈

架构

背景是解决之前的 RAG文本回答,不能对整体文档的总结性内容进行回答, 只能回答文档里有的, 不能对文档的关系,大意进行总结

以前的 RAG 工具,即使总结,也是让 GPT模型自己生成总结generic,不是真的 question focused

这种LLM上传文档一个是容易受context Window 的限制, 另外在检索总结时 容易丢失部分信息"lost in the middle” of longer contexts, LLM 只会按照他的理解来总结内容, 跟我们想要的答案存在信息密度,准确性的差异

刚好最近才学到密度链 Chain of Density(4篇Prompt论文的提示词技巧, 3 个 GPTs 实例测试), 有个共同点都是强调解决大模型总结的信息密度, 总结内容的精准性, 总结出来我们真正需要的有效信息,而不是一些笼统问题

“

RAG fails on global questions directed at an entire text corpus, such as “What are the main themes in the dataset?”, since this is inherently a query- focused summarization (QFS) task, rather than an explicit retrieval task.

GraphRAG 的大致思路是先把用户上传的文档(目前仅支持 txt)生成知识图谱,并用 community detection 算法进行实例等级、关系分类, 用 LLM对关系密切的实体进行总结

最后根据用户问题, 对这些总结进行进一步摘要来回答用户问题, 这个更多是 Global Search/Answer 来做, 适合概括性的问题,比如"数据最主要讲了什么"

“

Our approach uses an LLM to build a graph-based text index in two stages: first to derive an entity knowledge graph from the source documents, then to pre-generate community summaries for all groups of closely-related entities

虽然也是让 LLM 进行总结, 但是在已经语义分类,等级分类,关系分类后的每一个小的模块进行预总结, 再整体总结, 相比以往直接塞给 LLM 文档让他总结确实要更具体一些

下面是国外的测试, 左侧就比较笼统, 右侧通过图谱搜索, 回答的实体更精准

下图是我从GraphRAG的论文截取的, 是我看过最清晰的解释图, 比二次加工的易懂得多,这些开源项目, 有论文的建议看论文, 论文说明的一般都是最易于理解, 最接近开发团队本身意图的一手资料

GraphRAG 的 community  detection算法(论文中是Leiden algorithm)会根据关系把实例分单元,分层级组织成知识图谱的节点(下面知识图谱中不同颜色代表不同community); 再用 LLM  预总结每个小的 community

在用户查询时, 先根据问题并行的组织相关 community的总结, 再把这些并行独立的总结进行再总结

“

first using each community summary to answer the query independently and in parallel, then summarizing all relevant partial answers into a final global answer.

community hierarchy 社区层级是指在知识图谱中，实体之间形成的层次化社区结构。这种结构反映了实体之间的关系和组织方式，通常包括：

顶层社区：代表最广泛的类别或主题root communities at level 0 中层社区：更具体的子类别或子主题sub-communities at level 1 底层社区：最细化的分类，通常直接包含具体实体

GraphRAG 支持自己生成 prompt, 并计算 prompt 会占用多少 token, 确保在 token 范围内, 用户也可以手动生成提示词

本地搜索Local Search方法在查询时将知识图谱的结构化数据与输入文档的非结构化数据相结合, 以相关实体信息增强 LLM 上下文。这种方法非常适合回答需要理解输入文档中提到的特定实体的问题(例如, "洋甘菊的治疗特性是什么?")

问题生成方法将知识图谱中的结构化数据与输入文档中的非结构化数据结合起来，生成与特定实体相关的候选问题,实现逻辑跟本地搜索类似

想要进一步了解 GraphRAG 的, 这里提供一些我查找到的 GraphRAG相应文档

“

https://microsoft.github.io/graphrag/posts/prompt_tuning/overview/ 

https://neo4j.com/blog/graphrag-manifesto/ https://www.jiqizhixin.com/articles/2024-07-15-13 https://github.com/microsoft/graphrag https://www.graphrag.club/indexgraph/prompt_tuning/auto_prompt_tuning

目前用户反馈

下面是我搜集的一些已经部署过 GraphRAG 的网友反馈

创建一个可靠的知识图谱本来也不是容易的事，并且知识图谱的维护和迭代也非常耗费资源。还有Token计算量变大，对LLM的响应速度也会有挑战

微软的GraphRag好多坑，他local Search和Gloabal Search回答的效果一般

至少70B参数的 LLM,模型参数太小了不行, 而且本地大模型有些吃力

graphrag暂时只支持txt文档，需要先把pdf转成txt;知识图谱是使用graphrag提取出来,而不是其他三元组; 提取出来后可以放到 neo4j 做可视化

GraphRAG 上传的txt 索引后能生成知识图谱这种结构文件, 可以进一步通过neo4j进行检索rag, (langchain neo4j)

代码中运行是以下形式

后记

GraphRAG 项目主要内容大致是这些, 之后还会有生成质量更好更方便的框架出来, 再等等看, 像GraphRAG 自己不带 neo4j,现在有的技术人员开始把 neo4j 放在里面,让知识图谱可视化更方便

昨天国内有个技术员做了修改版的 graphrag, 可以看看,对用户会更友好些