在 RAGFlow 中实践 GraphRAG
RAGFlow 0.9 版本发布，正式引入了对 GraphRAG 的支持。GraphRAG 由微软近期开源【参考文献1】，被称作下一代 RAG，并且在更早时间发表了相干论文【参考文献2】。关于下一代 RAG，在 RAGFlow 体系的界说更加完备，就是如下图所示的 RAG 2.0， 这是一个以搜索为中央的端到端的优化系统，分为 4 个阶段，除了后边 2 个阶段——索引与检索，这个大部分是必要一个专用数据库来提供服务，前边 2 个阶段的分工如下：[*] 数据抽取：利用各类文档（大）模子包管被索引数据的高质量输入，避免 Garbage In，Garbage Out。
[*] 在抽取的数据被送到数据库之前，还可以选择性地加入一些预处理步调，包括文档预聚类，知识图谱构建等，这些预处理，主要是解决针对多跳问答，跨文档提问等情况做出处理。因此，GraphRAG 确实是面向下一代 RAG 的方案，但站在 RAG 2.0 的角度，它则是整个 Pipeline 当中的一个单位。
https://i-blog.csdnimg.cn/direct/2b786270df6c4d35ae19964bac0051b7.png
从 0.9 版本开始，这个单位已经被增补到了 RAGFlow 当中。那么下边先来介绍下，为何要加入这样一个单位，它跟微软的 GraphRAG 有什么区别和接洽。
知识图谱对于改进 RAG 的效果至关重要，因为简朴的 RAG ，只能提供根据提问检索答案的功能，可是这只能找到跟提问相似的结果，而未必是答案。比方一些总结性的问题，这种场景本质上是一种聚焦于查询的总结 QFS（Query Focused Summarization），采用知识图谱可以很方便的解决这类问题，通过知识图谱按照文字相干性把内容聚合，在对话的时候按照这些聚合后的文字天生总结，就可以很好的答复问题。现在的很多专用 AI 搜索，就是这样工作的。RAGFlow 在已往的版本所提供的 RAPTOR，就是对文本做聚类，实在也是雷同的原理，只不外相比 RAPTOR， 以知识图谱为中央的工作，可以形成以命名体实体节点为中央更有层次的结果，因此对于这种 QFS 查询，采用知识图谱的准确性和体系性更好。在其他一些场景中，采用知识图谱依然可以改善 RAG 的返回结果，因为它为返回结果添加了更多的知识图谱上下文，从而可以让 LLM 产生更有表明性的答复。采用知识图谱在 RAG 的有效性已经得到了很多研究工作的证实，因此从 GraphRAG 一推出，就迅速得到了社区的广泛关注。在已往，采用知识图谱进行问答的工作有很多，在 RAG 出现之前的 KGQA 就已经存在很多年。这些工作最大的瓶颈之一，就是怎样让知识图谱的构建自动化和标准化，这大大拦阻了基于知识图谱的工作在企业内大规模得到运用。随着 LLM 和 RAG 出现和广泛利用，用 LLM 来自动构建知识图谱成为一种可行的方案，GraphRAG 就是这些工作中最闻名的一个。近期另一个这方面比较知名的工作是所谓模拟人类大脑海马体的 HippoRAG【参考文献3】，GraphRAG 和 HippoRAG 有肯定的相似性：
在离线处理阶段，GraphRAG 和 HippoRAG 都将用户的文档首先送给 LLM 然后进行命名实体的自动抽取。但 GraphRAG 只抽取实体，而实体之间的关系并不做判断，仅仅用是否“相干”作为两者的接洽；而 HippoRAG 则按照标准知识图谱的界说抽取整个三元组——就是说在一个图的界说中，实体 1 和实体 2 之间的关系是何种范例。在整个 GraphRAG 过程中，都没有利用到三元组的关系范例这个信息，这大概是因为 LLM 针对该关系的抽取无法做到非常准确导致的。 在完成实体抽取后， GraphRAG 还用到了2个算法来补全这种关系： 一个是社区检测算法，一个是 Graph Embedding。社区检测是存在已久的一类应用算法，本质上是聚类，它递归地利用图谱当中的节点命名体信息补全图的社区结构，从而为更多的节点之间建立是否“相干”的关系。在建立了社区结构之后，再利用 LLM 根据社区内的节点形貌信息产生相应的择要内容。Graph Embedding 在 GraphRAG 中是一个可选项，采用的是 Node2Vec，这也是存在已久的算法，它在现有的图上利用随机游走（就是雷同 PageRank）结合节点命名体信息产生 Embedding ，因此这些 Embedding 可以看作是包罗了颠末了随机游走之后颠末的子图节点所包罗的语义信息。在查询时，可以利用这些 Graph Embedding 来返回更多的子图节点。
在线处理阶段，首先将用户的查询转成向量，然后找到知识图谱中最接近的节点，再根据该节点所在的社区，以及社区择要信息，共同返回给 LLM ，从而让 LLM 来根据这些上下文做最后的答案天生，如下图所示。在现实查询中，除了查询这些知识图谱数据，还针对原文进行查询，然后两路结果归并后共同作为上下文返回给 LLM 。所有这些查询，跟传统上采用图数据库来代表知识图谱截然不同，这里几乎没有必须依靠图数据库的地方。
https://i-blog.csdnimg.cn/direct/24816b87b66b47fa8dbcc1cd8d162f6b.png
HippoRAG 的离线阶段，在利用 LLM 抽取知识图谱三元组信息之后，再利用现成的知识图谱如 OpenIE，来补全抽取的知识图谱。在查询阶段，要同样利用雷同的随机游走算法（PageRank）在知识图谱上做子图遍历，从而根据返回的子图确定最终交给 LLM 的上下文。
可以看到， GraphRAG 和 HippoRAG ，都利用到了 PageRank 做子图遍历，只是前者放在离线阶段（只管现在还没有现实利用这些结果），后者是在线查询阶段。至于为何采用 PageRank，是因为一些认知科学家发现了人类回忆过程和 PageRank 算法的输出之间有相干性。
因此， GraphRAG 现实上对于知识图谱的抽象和构建做了相称的简化：三元组不要了，图抽象表达也不要了，正是这些简化，使得工程上推出标准产物的可行性大为增加。所以 RAGFlow 也借鉴了 GraphRAG 的实现，在文档预处理阶段，引入知识图谱构建作为可选项，服务于一些高级问答场景。在 GraphRAG 的根本之上， RAGFlow 做了这些改进：
[*] 引入了去重步调，原版的 GraphRAG 抽取出的命名实体，直接用于构建知识图谱，对于一些同义词实体，比方 “2024”和“2024年”，“IT”和“信息科技”，假如不做去重，会影响知识图谱的结构。命名实体去重在学术上叫做 Entity Resolution，现实上是一类复杂的算法，并且很难做到通用化。 RAGFlow 仍旧是借鉴了 LLM 自身的本领来去重，因为从广义上来看，LLM 实在就是一个超级大的知识图谱。
[*] 降低了 Token 消耗。GraphRAG 从它的工作原理上，就必要消耗大量的 Token，因为必要把用户本身上传的所有文档，都送到 LLM，乃至对于 GraphRAG 原版实现来说，这些文档被送了不止一次给 LLM ，对于利用一些 SaaS 服务的 RAG 系统来说，这里的 Token 消耗非常大。RAGFlow 主要通过一些流程上的优化，确保所有文档只会被提交给 LLM 一次，尽大概避免无效的 Token 消耗。固然，真正从根本上解决这个问题，可以利用一些较小的单独摆设的模子来做知识图谱构建，比方一个乐成的案例是 Triplex ，它是基于 Phi-3 做微调得到，参数量为 3B，相比采用 LLM 可以有数十倍的成本节约。 在未来，RAGFlow 也会提供雷同的解决方案，从而帮助降低 GraphRAG 的构建成本。
下边是 RAGFlow 中实现 GraphRAG 的产物效果展示：
在文档上传后的解析阶段，用户可以在知识库级的配置选择采用“Knowledge Graph”作为 Chunking 方案，并且用户必要自行界说必要 LLM 抽取的命名实体范例，如图中的 “organization”，“person”，“location” 等等：
https://i-blog.csdnimg.cn/direct/5847379c1eb7445cb4a421b395ba26db.png
针对知识库的特定文档，用户可以选择更改 Chunking 为其他方式，也可以更改该文档所要抽取的命名实体。假如一个知识库界说了采用 Knowledge Graph 作为 Chunking 方式，那么该知识库的所有文档，都会采用 GraphRAG 的方式召回：先召回知识图谱的实体和社区总结，再召回原文 —— 哪怕整个知识库大部分文档都采用的是其他 Chunking 方式。
https://i-blog.csdnimg.cn/direct/6b61d9adf52641a7ba306c5f55a94236.png
在选择完 Chunking 后，LLM 就会自动抽取并构建知识图谱，这些知识图谱在 RAGFlow 中可以提供可视化展现，包括节点名称，节点形貌，以及“社区”：
https://i-blog.csdnimg.cn/direct/46d8da8f4994452481ee01094f278799.png
https://i-blog.csdnimg.cn/direct/b4ac8f9c6b3d47b1a7ac6d4f0c40b5f1.png
还可以以头脑导图形式查察知识图谱：
https://i-blog.csdnimg.cn/direct/b95305a3ee3a49028d5bae199ef1cf00.png
知识图谱的可视化，对于用户调试对话有着重要意义。当前， RAGFlow 可以利用所有接入的 LLM 来天生知识图谱，然而这种较为复杂的信息抽取，在不同的 LLM 上本领表现差异较大，假如出现知识图谱抽取错误的情况，那么会导致最终对话结果的错误。在这种情况下，可以利用这些可视化工具查察图谱的结果分析对话天生。当前 RAGFlow 对知识图谱的天生，是文档级的，就是说现在没有针对整个知识库的所有文档统一构建知识图谱，因此现在的 GraphRAG 实现还无法对跨文档的知识图谱做关联。该特性必要更大的内存和计算资源，在未来 RAGFlow 会根据用户的利用反馈再决定是否添加这样的特性。
下图是一个以西游记第3-7回内容为根本的对话天生对比，左边是采用了 GraphRAG 的结果，可以看到在这些涉及到多跳或者嵌套逻辑的结果，GraphRAG 可以提供更加深入和全面的答复。
https://i-blog.csdnimg.cn/direct/069dec01bac243dd8fbad6667e4670b8.png
GraphRAG 是在 RAG 当中引入知识图谱自动构建的一个工程化有效实践，它的乐成得益于去除了传统知识图谱中大量复杂的部分，然而，这并不代表知识图谱在 RAG 应用的终点。在现实的企业应用中，适合拿来做知识图谱构建的数据，只是一小部分，有大量的数据或者并不适合构建知识图谱，或者出于成本思量，只在部分数据上构建知识图谱。因此，知识图谱的利用方式，还必要增补更多，比方怎样利用知识图谱改写查询等，这些都会在未来的 RAGFlow 版本中徐徐推出。
参考文献
[*] GraphRAG, https://github.com/microsoft/graphrag
[*] From Local to Global: A Graph RAG Approach to Query-Focused Summarization, https://arxiv.org/abs/2404.16130
[*] HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models , https://arxiv.org/abs/2405.1483
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]