小白也能读懂的GraphRAG常识图谱全流程解析 多图预警！

当天，我要和你分享的是如何用GraphRAG从一个普通的txt文件中创立常识图谱，预备好了吗？那就让咱们开局吧！

GraphRAG处置了什么疑问

当你问：“这个数据集的主题是什么？”这类初级别、概括性的疑问时，传统的RAG或者就会一筹莫展。为什么呢？那是由于这实质上是一个聚焦于查问的总结性义务(Query-Focused Summarization，QFS)，而不是一个明白的检索义务。

我知道你如今或者在想，“那咱们该如何处置这个疑问呢？”好信息是，有人曾经找到了处置打算，而且还被详细地形容在论文中：

In contrast with related work that exploits the structured retrieval and traversal affordances of graph indexes (subsection 4.2)，we focus on a previously unexplored quality of graphs in this context: their inherent modularity (Newman，2006) and the ability of community detection algorithms to partition graphs into modular communities of closely-related nodes (e.g.，Louvain，Blondel et al.，2008; Leiden，Traag et al.，2019). LLM-generated summaries of these community descriptions provide complete coverage of the underlying graph index and the input documents it represents. Query-focused summarization of an entire corpus is then made possible using a map-reduce approach: first using each community summary to answer the query independently and in parallel，then summarizing all relevant partial answers into a final global answer.

繁难来说，就是应用社区检测算法（如Leiden算法）将整个常识图谱划分模块化的社区(蕴含相关性较高的节点)，而后大模型自下而上对社区启动摘要，最终再采取map-reduce方式成功QFS: 每个社区先并行口头Query，最终汇总成全局性的完整答案.

与其余RAG系统相似，GraphRAG整个Pipeline也可划分为索引(Indexing)与查问(Query)两个阶段。索引环节应用LLM提取出节点（照实体）、边（如相关）和协变量（如 claim），而后应用社区检测技术对整个常识图谱启动划分，再应用LLM进一步总结。

当你运转 "poetry run poe index" 命令时，它会口头 graphrag.index.cli 目录下的 index_cli 入口函数。在 GraphRAG 中，构建常识图谱被视为一个流水线（pipeline）环节，这个流水线蕴含多个上班流（workflow），例如文本分块、经常使用LLM来识别实体等。pipeline涵盖的workflow是经过 settings.yml 性能文件启动指定的。index_cli 的关键义务是创立 pipeline_config 对象，并应用 run_pipeline_with_config 函数来运转流水线。所以，咱们可以将整个流程概括如下：

整个环节表现了自上而下的编程思维——每个结果依赖于更底层函数的口头，从顶部开局调用，而后逐渐深化究竟层函数。这样的结构使得全体流程明晰明了，这也是咱们往常在名目开发中的编程思绪。

探讨workflow之前，先繁难了解下名目经常使用的另一个框架:>当你经过命令行口头完indexing之后，你会看到如下的输入内容:

从这个可以看出GraphRAG的indexing共教训了14个workflow:

基本的处置环节如下：首先，它会将输入文本启动拆分，而后提取实体与相关，生成摘要信息，并依据这些信息构建内存中的图（Graph）结构。接上去，它会从这个图中识别出各个社区，为每个社区创立报告，并在图中创立文本块节点和文档节点。

当然，以上只是些**步骤，但在实践的处置环节中还触及到许多细节处置，比如生成嵌入（embedding），耐久化到存储，以及运行不同的算法战略等等。当然这些并不是这篇文章的重点。假设感兴味，评论区留言我会独自开别的文章来解说。

这里可以多说一点，这14个workflow其实又可以进一步细分为四大类：

1.关于文档的document_workflows

2.关于文档单元的text_unit_workflows

3.构建图谱的graph_workflows

4.社区聚类的community_workflows

此外，各个上班流之间存在必定的依赖相关，构成了一个上班流流程图。输入数据为寄存在 input 目录下的 txt 或 csv 文件(目前只允许这两种，前面我会自己允许更多格式)，经过这些上班流组成的流程图处置后，输入的结果就是最终构建的常识图谱。

接上去，我将以一个蕴含 "海贼王" 的 txt 文件为例(摘自百度百科)，逐渐解析它教训的各个上班流，以及每个上班流的输入和输入是什么.

1. create_base_text_units

整个pipeline的入口输入在源码中是个叫dataset的变量，其存储的值Pandas，Pandas可以繁难看做是一张table, 这个table的每一行代表一个txt文件，text列是txt文件的内容：

create_base_text_units 是整个pipeline的第一个workflow, 它的作用是对txt的文件内容依照特定的战略启动切分(chunking)操作，目前只允许两种战略: 依照token和依照sentence，自动是依照token, chunk操作的输入是text:

关于一个text 经过chunking操作后会获取多个chunks:

Microsoft GraphRAG在索引构建的环节中其两边数据关键经常使用Pandas这种结构化类型启动替换, 可以繁难了解为Mysql中的table，对DataFrame的一些操作比如select、join等可以类比mysql的select, join等sql语句来了解。

2. create_base_extracted_entities

一旦咱们获取了相应的chunk，GraphRAG就会驳回特定的战略从每个chunk来 提取须要的实体entity 。

目前，GraphRAG允许两种抽取战略：

当处置多个数据块时，GraphRAG会并行调用LLM来抽取实体，而且自动状况下，它会选用经常使用多线程。不过，假设你想的话，也可以经过性能修正成asyncio形式。

在此流程中，GraphRAG会调用run_extract_entities启动实体抽取，该函数会应用目录下的entity_extraction.txt中的prompt来调用LLM成功实体提取。自动的 entity_extraction prompt 抽取的实体类型是 ['organization', 'person', 'geo', 'event']，你可以依据你的文件内容来修正settings.yml中entity_extraction，前面我会引见如何经过prompt tuning来智能适配prompt.

entity_extraction:## llm: override the global llm settings for this task## parallelization: override the global parallelization settings for this task## async_mode: override the global async_mode settings for this taskprompt: "prompts/entity_extraction.txt"entity_types: [organization,person,geo,event]max_gleanings: 1

我截取了其中一个chunk获取的LLM调用结果的局部内容：

("entity"<|>欧罗·杰克逊号<|>ORGANIZATION<|>欧罗·杰克逊号是罗杰海贼团的船只)##("entity"<|>白胡子<|>PERSON<|>白胡子是“顶上抗争”之前的四皇之一，悬赏金为50亿4600万)##("entity"<|>百兽<|>PERSON<|>百兽是“顶上抗争”之前和之后的四皇之一，悬赏金为46亿1110万)##("entity"<|>BIG MOM<|>PERSON<|>BIG MOM是“顶上抗争”之前和之后的四皇之一，悬赏金为43亿8800万)##("entity"<|>红发<|>PERSON<|>红发是“顶上抗争”之前和之后的四皇之一，悬赏金为40亿4890万)##("entity"<|>黑胡子海贼团<|>ORGANIZATION<|>黑胡子海贼团是黑胡子的权利)##("relationship"<|>弗兰奇<|>卡雷拉公司<|>弗兰奇设计的海贼船由卡雷拉公司协助制造<|>8)##("relationship"<|>草帽大船团<|>俊美海贼团<|>俊美海贼团是草帽大船团旗下的一个海贼团<|>7)##("relationship"<|>卡文迪许<|>俊美海贼团<|>卡文迪许是俊美海贼团的船长<|>9)##("relationship"<|>斯莱曼<|>俊美海贼团<|>斯莱曼是俊美海贼团的船员<|>8)

GraphRAG会对LLM的输入结果启动后处置post_processing，最终构成Graph对象的。咱们先看一下实体（entities），每一个实体都有四个关键的属性：name、description、source_id 和 type。

每个chunk都生成对应的实体后，会把这些实体减少到一个列表entities中，并把每段chunk对应的表白图形结构的也放到一个列表entity_graph中:

这里有个状况须要思考，不同的数据块（chunks）或者会抽取出相反的实体。比如说，第一个和第二个数据块都或者蕴含"草帽路飞"这个实体。这时刻，GraphRAG会驳回一种名为merge_graphs的操作，把多个子图兼并成一个新的大图。假设遇到相反的节点，那么GraphRAG就会口头concat操作，也就是将对应的属性和相关启动兼并。

比如关于一个实体：'哥尔·D·罗杰'， 经过merge之后会蕴含多个description的列表: ['哥尔·D·罗杰是罗杰海贼团的船长', '哥尔·D·罗杰是被称为“海贼王”的男人，他在被行刑受死之前说了一句话，开启了“大海贼时代”']

经过merge_graphs操作，GraphRAG能够有效地处置重复的实体，并把多个chunk对应的Graph整分解一个新的Graph，构成一个愈加完善和详细的数据图:

3. create_summarized_entities

经过merge_graphs的操作，将多个子图兼并到一个全新的大图之后，GraphRAG会进一步这个大图的节点(node)和相关(relationship)的形容(descriptions)启动总结。

这样做的目的是为了繁难查问，由于查问时须要依据疑问婚配常识库中的实体信息和相关信息时，只要要依据总结后的实体形容和相关形容就可以启动婚配了. 不然得遍历description list启动婚配。

GraphRAG目前允许的summarize的战略只要一种：graph_intelligence。

summarize经常使用的prompt中文翻译如下：

你是一位担任生成以下提供数据的综合摘要的有用助手。依据一个或两个实体，以及一系列形容，这些形容都与同一个实体或一组实体无关。请将一切这些形容兼并成一个繁多的、片面的形容。确保包括所无形容中搜集到的信息。假设提供的形容存在矛盾，请处置这些矛盾，并提供一个繁多的、连接的摘要。确保用第三人称写作，并包括实体称号，以便咱们领有完整的高低文。#######-数据-实体: {entity_name}形容列表: {description_list}#######输入:

口头summarize_descriptions操作后，原来图形中的 多个description 就被整合为了 一个 全新的、详尽的形容。可以说，summarize_descriptions是把前一步获取的Graph启动整顿的环节，使得Graph愈加明晰、准确。

经过summarize之后，上一个workflow create_base_extracted_entities 获取的Graph被更进一步完善了：

生成这种摘要的好处是：可以借助嵌入embedding向量更有效与准确的对这些实体与相关启动检索。

4. create_base_entity_graph

这一步是做社群审核的: 将实体启动分类，拿三国举例，比如周瑜和孙策属于吴国，曹操和司马懿属于魏国，刘备和关羽属于蜀国，而吴国、魏国、蜀国都属于东汉，其中东汉是一个大社群，魏蜀吴是三个小社群，当口头查问时，可以指定社区的级别，假设指定的是低级别社群，那么查找的结果就比拟宏观，比如问三国时间有哪些驰名人物，假设指定的社群为吴国，那么婚配的就只要周瑜和孙策，假设指定的社群为东汉，那么就能找到更多的驰名人物。

create_base_entity_graph这个workflow会对Graph运行运行档次聚类算法(对应源码中的cluster_graph方法)， 在Graph中识别出档次结构和社区结构：一个Level对应多个community。

GraphRAG在源码中借助了 Graspologic库 成功的Leiden算法: Leiden算法理论比许多其余的社区检测算法更稳固，能更牢靠地复现结果, 然而Leiden算法在某些状况下或者会比其余方法慢一些。

在这个workflow中先会启动run_layout 规划剖析，运行Leiden算法对nodes分社区，成功这些步骤后，每一个社区的节点都会被赋予以下属性：

经过create_base_entity_graph之后，Graph依照层级被划分出多个子图，每个子图对应一个level：

5. create_final_entities

create_final_entities这个workflow的性能是对节点做embedding，繁难启动之后的query。

在做embedding之前，为了更好地示意每个节点，咱们将节点的'name'和'description'字段拼接起来，构成一个新的'name_description'字段。这样，每个节点都将有一个深刻易懂，并且信息丰盛的标签。

而后，咱们把这个重生成的'name_description'字段经过嵌入环节转换成一个向量示意。这种方法能够捕捉和示意文本数据的复杂形式，也使得咱们可以针对这些节点启动高效的计算和剖析。

经过下面的一些图的修整之后，咱们还须要对entity做进一步的embedding操作。在这之前，会经过embedding操作，embedding会对node的 name和description 拼接的 name: description 组成name_description字段，对这个字段做embedding操作。

经过embedding之后，新增了一列description_embedding字段：

image-20240809153319632

6. create_final_nodes

Network Visualization 阶段，由于生成的图谱普通不是一个平面图（可以经过在平面上绘制其顶点和边而不出现边的交叉），经过经常使用降维技术操作将非平面图映射到平面上，可以更直观地观察和了解数据的结构和形式。

在图论和网络剖析中，图的规划算法（layout algorithm）用于将图中的节点和边在二维或三维空间中启动正当的陈列和可视化。其关键指标是使图的结构和相关尽或者明晰地展现进去，以便于人类了解和剖析。create_final_nodes会对Graph运行layout算法，GraphRAG目前允许两种算法：

workflow的输入是create_base_entity_graph的输入：

每个entity的一切属性如今长这样：

7. create_final_communities

这个workflow用于创立community table, 步骤如下：

咱们从第4步生成的create_base_entity_graph中抽取节点数据，构成一个名为graph_nodes的表：

而后，咱们雷同从create_base_entity_graph中提取边信息，生成另一个名为graph_edges的表：

而后，咱们将graph_nodes和graph_edges启动left_join操作，这个重生成的表命名为combined_clusters：

紧接着，咱们对combined_clusters进后退一步的聚合操作，雷同是依照cluster和level启动分组。在这个环节中，咱们会把edge的id_2去重后组分解一个数组，命名为relationship_ids；同时，也会把node的source_id_1去重后组分解另一个数组，命名为text_unit_ids：

最后，咱们还会对上述数据启动一次性处置，关键是生成每个社区的称号：

image-20240810214443777

8. join_text_units_to_entity_ids

join_text_units_to_entity_ids的作用是建设text_unit到entity的映射相关。

而后，咱们启动聚合操作。详细来说，咱们会依照"text_unit_id"对数据启动分类，并把相反类别的实体id聚分解一个数组，命名为"entity_ids"。

这样，在最终的结果中，每一条记载都会蕴含一个"text_unit_id"，以及一个与之关联的"entity_ids"数组:

image-20240810091048672

9. create_final_relationships

create_final_relationships用于创立relationship table, 步骤如下:

首先，咱们从create_base_entity_graph中获取的Graph提取出一切的边相关：

接上去，咱们会对edge和nodes经常使用left_join操作，在这个步骤中，咱们将新增两列：source_degree和target_degree。这两列区分示意源实体和指标实体的度数，也就是每个实体衔接的边的数量。

最后，咱们会创立一个新的列"rank"。这个列的值是经过将source_degree和target_degree相加获取的。这样，咱们就可以依据rank的值，了解每条边衔接的两个实体的总度数:

10. join_text_units_to_relationship_ids

这个workflow和咱们之前探讨过的join_text_units_to_entity_ids十分相似，关键区别在于，如今咱们是将text_unit_id映射到它所蕴含的relationship_id，而不再是entity_ids。

繁难来说，咱们的指标是了解每个text_unit_id（对应"chunk"）都蕴含了哪些相关（relationship）。为了成功这个指标，咱们会创立一种映射相关，把每个text_unit_id衔接到它所触及的一切relationship_id。结果将以相似于字典的方式出现，其中键是text_unit_id，值是一个列表，蕴含了一切相关的relationship_id：

image-20240810094149840

11. create_final_community_reports

这个workflow用于生成社区摘要：借助LLM生成每个社区的摘要信息，用来了解数据集的全局主题结构和语义。这也是Microsoft GraphRAG的**价值所在，也是回答QFS疑问的关键。详细步骤如下：

首先借助​ ​create_final_nodes​ ​​的输入，并减少了一个​ ​node_details​ ​列以存储更多关于节点的信息：

而后对这些nodes经常使用​ ​community_hierarchy​ ​来构建社区的档次结构，经过对(community, level) 的分组，将同一组内的节点title聚分解数组:

从上图咱们可以看到每个community蕴含了哪些entity。

接上去，GraphRAG开局剖析父子社区的结构状况，假设上一级的社区蕴含了所有下一级社区的成员，那么它们之间就构成了父子社区的相关，咱们发现社区1是个大社区，蕴含了12、13、14三个子社区，然而它们都属于同一个level：

紧接着GraphRAG会基于三个table: node_df、edge_df、claim_df 做聚合操作，生成每个社区的context_string: 蕴含社区的一切节点和relationships信息:

image-20240810122232624

为了繁难你看到context_string的内容，我摘取了某个社区的context_string内容：

'-----Entities-----\n' 'human_readable_id,title,description,degree\n' '2,蒙奇·D·路飞,蒙奇·D·路飞是“草帽一伙”的船长，外号“草帽小子”，幻想成为“海贼王”，悬赏金30亿贝里,11\n' '20,ONE PIECE,,1\n' '17,五老星,五老星以为蒙奇·D·路飞食用的橡胶果实实践上是人人果实·幻兽种·尼卡外形,1\n' '10,和之国事情,和之国事情是蒙奇·D·路飞击败原“四皇”之一的“百兽”凯多的事情,1\n' '19,尼卡,尼卡是五老星以为蒙奇·D·路飞食用的人人果实·幻兽种的外形,1\n' '9,恶魔果实,恶魔果实是一种奥秘的果实，食用后可以取得超人才干，但会失去游泳的才干,1\n' '11,百兽凯多,百兽凯多是原“四皇”之一，被蒙奇·D·路飞在和之国事情中击败,1\n' '\n' '\n' '-----Relationships-----\n' 'human_readable_id,source,target,description,rank\n' '0,蒙奇·D·路飞,草帽一伙,蒙奇·D·路飞是草帽一伙的船长和创立者,30\n' '7,蒙奇·D·路飞,东海,蒙奇·D·路飞的出身地是东海,16\n' '1,蒙奇·D·路飞,香克斯,蒙奇·D·路飞为了成功与香克斯的商定而出海,13\n' '6,蒙奇·D·路飞,香波地群岛,蒙奇·D·路飞是“极恶的世代”中登陆香波地群岛的11位超新星之一,13\n' '9,蒙奇·D·路飞,极恶的世代,蒙奇·D·路飞是“极恶的世代”中登陆香波地群岛的11位超新星之一,13\n' '2,蒙奇·D·路飞,ONE PIECE,蒙奇·D·路飞为了寻觅传说中的大秘宝ONE PIECE而扬帆起航,12\n' '8,蒙奇·D·路飞,五老星,五老星以为蒙奇·D·路飞食用的橡胶果实实践上是人人果实·幻兽种·尼卡外形,12\n' '4,蒙奇·D·路飞,和之国事情,蒙奇·D·路飞在和之国事情中击败了百兽凯多,12\n' '10,蒙奇·D·路飞,尼卡,五老星以为蒙奇·D·路飞食用的橡胶果实实践上是人人果实·幻兽种·尼卡外形,12\n' '3,蒙奇·D·路飞,恶魔果实,蒙奇·D·路飞因误食恶魔果实而成为了橡皮人,12\n' '5,蒙奇·D·路飞,百兽凯多,蒙奇·D·路飞在和之国事情中击败了百兽凯多,12\n'

接着LLM会经常使用community_report.txt中的prompt并把context_string作为输入， 对社区依照level启动自下而上的总结 ，经常使用的自动prompt中文翻译如下：

你是一团体工智能助手，协助人类剖析员启动普通的信息发现。信息发现是识别和评价与某些实体（例如，组织和团体）相关的相关信息的环节。# 指标在给定属于社区的实体列表及其相关和可选的相关申明的状况下，编写社区的片面报告。报告将用于通知决策者无关社区及其潜在影响的信息。报告内容包括社区关键实体的概述、他们的法律合规性、技术才干、声誉和值得留意的申明。# 报告结构报告应包括以下局部：- 题目：代表其关键实体的社区称号——题目应冗长但详细。尽或者在题目中包括具备代表性的命名实体。- 摘要：对社区全体结构、其实体之间的相关以及与其实体相关的严重信息的口头摘要。- 影响严重性评分：一个介于0-10之间的浮动评分，示意社区内实体所构成的影响的严重水平。影响是社区的关键性评分。- 评分解释：用一句话解释影响严重性评分。- 详细发现：关于社区的5-10个关键见地的列表。每个见地应有一个冗长的摘要，后跟依据以下基础规定启动的多段解释性文本。要片面。前往输入为格式良好的JSON格式的字符串，格式如下：```json{"title": <report_title>,"summary": <executive_summary>,"rating": <impact_severity_rating>,"rating_explanation": <rating_explanation>,"findings": [{"summary":<insight_1_summary>,"explanation": <insight_1_explanation>},{"summary":<insight_2_summary>,"explanation": <insight_2_explanation>}]}```# 基础规定允许数据的点应列出其数据援用，如下所示：“这是一个由多个数据援用允许的示例句子[数据: <dataset name> (记载ID); <dataset name> (记载ID)]。”在单个援用中不要列出超越5个记载ID。相反，列出最相关的前5个记载ID，并加上“+更多”以示意还有更多。例如：“Person X是Company Y的一切者，并且遭到许多不当行为指控[数据: 报告 (1), 实体 (5, 7); 相关 (23); 申明 (7, 2, 34, 64, 46, +更多)]。”其中1, 5, 7, 23, 2, 34, 46和64代表相关数据记载的ID（而不是索引）。不要包括没有提供允许证据的信息。# 示例输入-----------文本：实体id,entity,description5,VERDANT OASIS PLAZA,绿洲广场是勾搭游行的地点6,HARMONY ASSEMBLY,谐和集会是一个在绿洲广场举办游行的组织相关id,source,target,description37,VERDANT OASIS PLAZA,UNITY MARCH,绿洲广场是勾搭游行的地点38,VERDANT OASIS PLAZA,HARMONY ASSEMBLY,谐和集会在绿洲广场举办游行39,VERDANT OASIS PLAZA,UNITY MARCH,勾搭游行正在绿洲广场启动40,VERDANT OASIS PLAZA,TRIBUNE SPOTLIGHT,论坛焦点正在报道绿洲广场上的勾搭游行41,VERDANT OASIS PLAZA,BAILEY ASADI,Bailey Asadi在绿洲广场上就游行宣布演讲43,HARMONY ASSEMBLY,UNITY MARCH,谐和集会正在组织勾搭游行输入:```json{"title": "绿洲广场和勾搭游行","summary": "社区围绕绿洲广场倒退，该广场是勾搭游行的地点。广场与谐和集会、勾搭游行和论坛焦点都有相关，这些都与游行事情无关。","rating": 5.0,"rating_explanation": "由于勾搭游行时期或者出现的骚乱或抵触，影响严重性评分为中等。","findings": [{"summary": "绿洲广场作为中心肠点","explanation": "绿洲广场是该社区的中心实体，作为勾搭游行的地点。该广场是一切其余实体的共同咨询点，标明其在社区中的关键性。广场与游行的关联或者会造成如公共次第疑问或抵触等疑问，详细取决于游行的性质和它惹起的反响。[数据: 实体 (5), 相关 (37, 38, 39, 40, 41,+更多)]"},{"summary": "谐和集会在社区中的角色","explanation": "谐和集会是社区中的另一个关键实体，他们在绿洲广场组织游行。谐和集会的性质和他们的游行或者是潜在的要挟起源，这取决于他们的指标和惹起的反响。谐和集会和广场之间的相关关于了解该社区的灵活至关关键。[数据: 实体(6), 相关 (38, 43)]"},{"summary": "勾搭游行作为关键事情","explanation": "勾搭游行是一个在绿洲广场上出现的关键事情。该事情是社区灵活的关键要素，详细取决于游行的性质和它惹起的反响，或者是潜在的要挟起源。游行和广场之间的相关关于了解社区的灵活至关关键。[数据: 相关 (39)]"},{"summary": "论坛焦点的作用","explanation": "论坛焦点正在报道在绿洲广场上举办的勾搭游行。这标明该事情吸引了媒体的关注，或者会加大其对社区的影响。论坛焦点的作用或者在塑造群众对事情和相关实体的认识方面具备关键意义。[数据: 相关 (40)]"}]}```# 实在数据经常使用以下文本作为答案的依据。不要在答案中假造任何内容。文本:{input_text}报告应包括以下局部：- 题目：代表其关键实体的社区称号——题目应冗长但详细。尽或者在题目中包括具备代表性的命名实体。- 摘要：对社区全体结构、其实体之间的相关以及与其实体相关的严重信息的口头摘要。- 影响严重性评分：一个介于0-10之间的浮动评分，示意社区内实体所构成的影响的严重水平。影响是社区的关键性评分。- 评分解释：用一句话解释影响严重性评分。- 详细发现：关于社区的5-10个关键见地的列表。每个见地应有一个冗长的摘要，后跟依据以下基础规定启动的多段解释性文本。要片面。前往输入为格式良好的JSON格式的字符串，格式如下：```json{"title": <report_title>,"summary": <executive_summary>,"rating": <impact_severity_rating>,"rating_explanation": <rating_explanation>,"findings": [{"summary":<insight_1_summary>,"explanation": <insight_1_explanation>},{"summary":<insight_2_summary>,"explanation": <insight_2_explanation>}]}```# 基础规定允许数据的点应列出其数据援用，如下所示：“这是一个由多个数据援用允许的示例句子[数据: <dataset name> (记载ID); <dataset name> (记载ID)]。”在单个援用中不要列出超越5个记载ID。相反，列出最相关的前5个记载ID，并加上“+更多”以示意还有更多。例如：“Person X是Company Y的一切者，并且遭到许多不当行为指控[数据: 报告 (1), 实体 (5, 7); 相关 (23); 申明 (7, 2, 34, 64, 46, +更多)]。”其中1, 5, 7, 23, 2, 34, 46和64代表相关数据记载的ID（而不是索引）。不要包括没有提供允许证据的信息。输入:

咱们看下某个社区的报告内容：

{'findings': [{'explanation': '蒙奇·D·路飞是草帽一伙的船长和创立者，他的幻想是成为海贼王。他的出身地是东海，并且为了成功与香克斯的商定而出海。他还因误食恶魔果实而成为了橡皮人，这使他取得了超人才干但失去了游泳的才干 ''[Data: Entities (2, 9); Relationships (0, 7, 1, ''3)].','summary': '蒙奇·D·路飞的**肠位'},{'explanation': '和之国事情是蒙奇·D·路飞击败原“四皇”之一的百兽凯多的事情。这一事情标志着他在海贼环球中的位置进一步优化，并对环球格式发生了深远影响 ''[Data: Entities (10, 11); Relationships (4, ''5)].','summary': '和之国事情的关键性'},{'explanation': '五老星以为蒙奇·D·路飞食用的橡胶果实实践上是人人果实·幻兽种·尼卡外形。这一观念提醒了蒙奇·D·路飞的才干或者比之前以为的更为弱小和奥秘 ''[Data: Entities (17, 19); Relationships (8, ''10)].','summary': '五老星的观念'},{'explanation': '恶魔果实是一种奥秘的果实，食用后可以取得超人才干，但会失去游泳的才干。蒙奇·D·路飞因误食恶魔果实而成为了橡皮人，这使他在战役中具备共同的长处 ''[Data: Entities (9); Relationships (3)].','summary': '恶魔果实的影响'},{'explanation': '草帽一伙是由蒙奇·D·路飞创立的海贼集团，他们在海贼环球中表演着关键角色。蒙奇·D·路飞作为船长，率领着这支团队在寻觅传说中的大秘宝ONE ''PIECE的环节中教训了许多冒险 [Data: Entities (2, 20); ''Relationships (0, 2)].','summary': '草帽一伙的角色'},{'explanation': '蒙奇·D·路飞是“极恶的世代”中登陆香波地群岛的11位超新星之一。这一身份使他在海贼环球中备受关注，并进一步优化了他的影响力 ''[Data: Relationships (6, 9)].','summary': '极恶的世代'}], 'rating': 8.5, 'rating_explanation': '该社区的影响力很高，由于蒙奇·D·路飞在和之国事情中的胜利对整个环球格式发生了严重影响。', 'summary': '该社区围绕着蒙奇·D·路飞倒退，他是草帽一伙的船长，幻想成为海贼王。蒙奇·D·路飞与多个实体有着严密的咨询，包括和之国事情、五老星、百兽凯多等。和之国事情是他击败原“四皇”之一的百兽凯多的关键事情。五老星以为他食用的橡胶果实实践上是人人果实·幻兽种·尼卡外形。', 'title': '蒙奇·D·路飞与和之国事情'}

这份报告蕴含了社区的总体title、summary和发现等等，这个环节也是最消耗token的。

12. create_final_text_units

这个workflow很繁难，就是把对应的chunk和这个chunk有的document_ids, entity_ids, relationship_ids 做关联，成一张表

image-20240810028338

13. create_base_documents

这个流程也很繁难，关键是建设document和text_unit的对应相关表

image-20240810221714

14. create_final_documents

这个流程成功的上班基本和create_base_documents分歧，只是把text_units列名换成了text_unit_ids而已

image-20240810223341019

总结

当GraphRAG成功索引环节后，它自动会将构建常识图谱所需的一切数据耐久化。这些数据被存储在输入目录中，并驳回Parquet文件格式。Parquet是一种列式紧缩存储格式，专为高效的数据存储和剖析而设计。你可以将其视为DataFrame的一种耐久化方式。

在查问阶段，这些Parquet文件会被加载到内存和向量数据库中。这样做的好处在于，咱们可以间接从内存和数据库中检索信息，而无需再次从原始数据源抽取和处置数据。这大大提高了查问的效率和速度。

由于parquet是一种底层文件格式，咱们不可用来直观的了解与观察下面构建的常识图谱索引的细节，有什么方法可以做更直观的可视化、剖析与检索呢？

由于parquet文件可以很繁难的经过pandas库读取成DataFrame表，所以在了解其结构后，就可以经过Cypher语句导入成Neo4j图数据库中的节点与相关。在Github上曾经有人成功这样的上班：。你假设嫌费事，也可以把parquet转成csv格式启动检查，代码也十分繁难，不到20行左右，感兴味的可以评论区留言。下图是抽取的Entity的Neo4j展现：

image-20240811200959883

基于GraphRAG生成的数据导入到Neo4j之后，咱们齐全可以不再依赖于GraphRAG名目自带的Query性能，可以联合自己的名目需求在自己的Neo4j图数据库上定义自己的RAG运行检索与生成器，从而带来极大的灵敏性。

原文链接：​ ​​ ​