对于普通的RAG，也就是前面课程讲的RAG，它的原理是通过将文本进行切分和向量化，通过计算文本之间的向量相似度，从而得到两个文本之间的语义相似度，从知识库中找出跟问题语义相似的知识点，再送给LLM得出最终答案。

对于一般的问答类型知识库，普通RAG基本够用了，但是知识库类型如果更复杂一点，比如新闻报道、小说等文章类型，普通RAG就难以应付了，比如想针对《三国演义》做一个知识库，让用户能够搜索《三国演义》中的相关内容，比如“吴国有哪些大都督？”，那么普通RAG就比较难做了。

GraphRAG提出了一种新的RAG的方式，可以用来解决这种非结构化知识库的场景，它的做法如下。

第一步，先对文档进行切分，切分成多个TextUnit，也就是文本单元，默认一个文本单元最大长度为300个tokens，这里的token就是LLM中的token（一个字或一个词），可以通过配置进行修改，这一步没有其他目的，就是将长文档切短。

第二步，针对每个文本单元，利用LLM抽取出其中的实体信息，叫做Entity，所谓实体就是一个组织，或一个人，或一个地理位置等，你想让LLM从文本中抽取哪些类型的实体是可以配置的，实体信息包含实体名字、实体类型、实体描述，也就是Entity中有三个属性name、type、description，比如从文本单元中抽取出一个实体，类型为人，名字叫周瑜，描述为“三国时期的著名人物”。

不过需要注意，对于不同的文本单元，可能抽取的实体名字和实体类型相同，但实体描述不同，比如从文本单元A抽取了周瑜这个实体，但是得到描述信息是“周瑜长得非常帅”，但是从文本单元B中也抽取了周瑜这个实体，但是得到的描述信息是“周瑜技术非常厉害”，此时会把这两个描述信息都放在周瑜这个Entity的description属性中，description属性为一个list。

第三步，针对每个文本单元，利用LLM抽取其中实体之间的关系信息，一个文本单元可能包含多个实体，那么这一步就是抽取出这些实体之间的关系，比如文本单元中包含了一个人物和一个组织，比如周瑜和吴国，那么“周瑜属于吴国”，就是这两个实体之间的关系，关系信息叫做Relationship，包括两个实体的名字以及关系的描述信息，Relationship的三个属性为source、target、description。

同样，对于不同的文本单元，可能抽取出相同的两个实体，但是他们之间的关系不一样，比如文本单元A中发现“周瑜和孙策是兄弟关系”，但是文本单元B中发现“周瑜和孙策是君臣关系”，因此Relationship中的description属性也是一个list，用来存放一个关系信息的多种描述。

第四步，总结实体信息和关系信息，由于Entity和Relationship中的description属性都是一个list，都有可能对应多种描述，因此这一步所做的，就是通过LLM将多种描述信息进行总结，总结为一句话，比如将“周瑜和孙策是兄弟关系”和“周瑜和孙策是君臣关系”总结为"周瑜和孙策是亲如兄弟的君臣关系"，这样做的目的是为了方便查询，因为查询时需要根据问题匹配知识库中的实体信息和关系信息时，只需要根据总结后的实体描述和关系描述就可以进行匹配了，不然得遍历list进行匹配。

第五步，这一步默认是没有开启的，这一步解决的问题是，对于抽取出来的实体，可能实体名字不同，但其实对应的是同一个实体，比如一个叫周瑜，一个叫公瑾，名字不同，但是对应的是同一个人，因此这一步就是发现并统一实体名字，比如统一都叫做周瑜，一旦出现了这种情况，也就是原本实体名字叫公瑾，现在要改为周瑜，就需要更新前面步骤的信息，包括关系信息，代价还是比较大的，所以默认是不开启的。

第六步，针对每个文本单元，利用LLM抽取其中发生的事件，比如赤壁之战，就是一次事件，我们把事件叫做Claim，一个事件信息包括事件的发起者、事件的报告者（不一定有，比如新闻事件就有报告者）、事件类型（LLM自己提炼）、事件状态（TRUE表示事件已经得到证实，FALSE表示事件是假的，SUSPECTED表示不确定）、事件的开始日期、事件的结束日期、事件的描述（比如事件发生的原因）、事件来源。

第七步，社群检查，通过前面的步骤，可以从所有文本单元中抽取出所有的实体信息、关系信息、事件信息，社群检查就是利用这些信息将实体进行分类，比如周瑜和孙策属于吴国，曹操和司马懿属于魏国，刘备和关羽属于蜀国，而吴国、魏国、蜀国都属于东汉，其中东汉是一个大社群，魏蜀吴是三个小社群，当执行查询时，可以指定社区的级别，如果指定的是低级别社群，那么查找的结果就比较微观，比如问三国时期有哪些著名人物，如果指定的社群为吴国，那么匹配的就只有周瑜和孙策，如果指定的社群为东汉，那么就能找到更多的著名人物。

第八步，生成社群报告，社群叫做Community，社群报告叫做Community Report，社群报告相当于就是在描述社群的构成，一个社群报告包含了社群中的实体信息、关系信息、事件信息，最重要的是还包含了一份对于该社群的描述description信息，这个描述也是通过LLM生成的，后续根据问题匹配社群时，就需要用到社群描述信息。

第九步，向量化，不管是实体还是关系，还是社群，都有描述信息，这一步就是对各个描述信息进行向量化，比如Entity中除开有description属性，还有description_embedding属性，进行向量化的目的也是为了查询，能够更容易的根据问题找到语义相似的实体、关系、社群。

第十步，原始文本向量化，相当于做一次普通RAG的知识库创建动作，将文本单元直接进行向量化。

以上就是GraphRAG进行知识库创建（GraphRAG中叫做Indexing）的十大步骤，这十大步骤是我自己总结的，和官网教程并不完全相同，但大致相同，这样应该更容易理解，通过以上步骤能够将一些非结构化的知识转变为结构化的知识，知识图谱就是所谓的结构化知识，比如新闻报告、小说等非结构化知识，通过抽取实体、关系、事件、社群得信息从而得到知识图谱，而知识图谱就描述各个实体之间的关系，使得在查询时，能通过问题搜索到更加全面、存在关系的知识点，而不只是单纯的语义相似的知识点。

以上就是GraphRAG创建知识库的大致过程，接下来，我们来看看GraphRAG的查询过程，GraphRAG中查询分两种：Local Search和Global Search。

首先，GraphRAG也是一种RAG，在查询时也是根据问题从知识库出检索出知识点，然后把找到的知识点添加到提示词模版中输入给LLM得到答案，GraphRAG和普通RAG的区别除开知识库创建的方式不同，知识库查询的方式也不同。

所谓Local Search就是根据问题利用向量搜索，找出跟问题匹配的实体信息、关系信息、事件信息、社群信息、原始文本信息，然后分别取匹配度最高的前几条，作为检索结果输入给LLM，其中原始文本信息就相当于进行了一次普通RAG从知识库查询得到的结果，而其他信息就是GraphRAG额外查询出来的，也就相当于GraphRAG从知识库中找到了跟问题有关的更多信息，从而提高问题回答的质量，这种方式的核心仍然是向量相似度，是从左往右依次匹配知识点的过程，适合回答有特点实体的问题，比如“周瑜的老婆是谁？”。

所谓Global Search就是利用LLM来决定要回答该问题应该用哪几个社群的信息，这个过程涉及到map-reduce的思想，先让LLM分析每个社群对于解决该问题的重要程度，具体做法是利用每个社群的社群报告描述信息和当前问题组合成提示词，让LLM来分析这个社群和问题的匹配程度，这是map的过程，然后选择匹配度较高的几个社群以及社群中的实体信息、关系信息、事件信息，再让LLM根据这些信息回答问题，这是reduce的过程。总而言之，Global Search是先找社群，再得到社群里的知识点，是从上往下匹配知识点的过程，适合回答总结性的问题，比如“三国里有哪些著名人物？”。

好啦，以上就是我对GraphRAG的理解，十大步骤是我自己总结得出的，如有纰漏，请多指教，欢迎关注我的公众号：IT周瑜。