我们发现，实际上用一个简单的多路召回然后rerank的RAG范式，就能够很好的处理复杂的多跳KG-RAG场景，而并不需要过多的LLM开销和任何图算法。
Oursimplepipelineisnotmuchdifferentfromthecommonmulti-wayretrievalandrerankarchitecture,butitcanachievetheSoTAperformanceinthemultihopgraphRAGscenario.
尽管使用很简单的架构，但我们的方法显著超过目前state-of-the-art的解决方案，比如HippoRAG，并且仅仅需要用到向量存储和少量的LLM开销。我们首先引入我们方法的理论基础，然后介绍具体方法过程。
理论
我们观察到在实际的KG-RAG场景中，存在跳数有限性假设：在KG-basedRAG中，实际问的query问题的查询路由只需要在知识图谱中进行有限的，且很少的跳数（如少于4跳）的查询，而并不需要在其中进行非常多次跳数。
我们的跳数有限性假设基于两点很重要的观察：1.query复杂度有限性，2.“捷径”的局部dense结构。
query复杂度有限性
用户的一个提问query，不太可能涉及到非常多的entities，或者引入复杂的relationships。否则这个问题会显得非常奇怪和不切实际。
Normalqueryvs.Weirdquery
y
“捷径”的局部dense结构
知识图谱中是一个存在一些局部dense结构，对于有些query，有一些“捷径”，可以从一个entity通过捷径快速连接到多跳之外的entity。
"Shortcuts"structure
假设我们有一个家庭关系的知识图谱，包含以下实体和关系：Alex是Brian的孩子(Alex-child_of-Brian)Cole嫁给了Brian(Cole-married_to-Brian)Daniel是Cole的哥哥(Daniel-brother_of-Cole)Daniel是Alex的舅舅(Daniel-uncle_of-Alex)这是一个包含冗余信息的密集型的知识图谱。显然，可以通过前三条relationships推导出最后一条relationship。但知识图谱中往往存在一些这种冗余信息的捷径。这些捷径可以减少一些entities之间的跳数。
基于这两点观察，我们发现，有限次数的在知识图谱内的路由查找过程，只涉及到局部的知识图谱信息。因此，将query进行知识图谱内信息检索的过程可以用下面这两步来实现：
路由的起点，可以通过向量相似性查找来完成。可以涉及到query与entities或query与relationships的相似度关系查找。
从起点找到其它信息的路由过程，可以用一个LLM来代替完成。将这些备选信息放进prompt里，依托LLM强大的自注意力机制来挑选有价值的路由。由于prompt长度有限，所以只能将局部知识图谱的信息放入，比如起点附近限定跳数内的知识图谱信息，这一点是正好可以由跳数有限性来保证。
整个过程不需要其任何它的KG存储和复杂的KG查询语句，只需要使用vectordatabase和一次LLM的访问。而vectorretrieval+LLMrerank才是这个pipeline中最关键的部分，这也就解释了我们只用一个传统的两路召回架构，就可以达到远超基于图理论的方法（如HippoRAG）的表现。这也说明了，实际上不需要复杂的图算法，我们只需要将图结构的逻辑关系存储在向量数据库里，用一个传统的架构就可以进行逻辑上的子图路由，而现代LLM强大的能力帮助做到了这一点。
方法概览
我们的方法只涉及在RAG流程中检索passages的阶段，不涉及chunking或LLMresponsegeneration的创新和优化。我们假设已经得到了一组corpus的三元组信息，它包含一系列的entities和relationships信息。这些信息可以表示一个知识图谱的信息。
Overallpipelineofourmethod
方法详解
4.1.向量入库
我们准备两个向量存储collections，一个是entitycollection，另一个是relationshipcollection。将一系列的uniqueentities信息和relationships信息，使用embedding模型，转换成向量，存储在向量存储中。对于entities信息，直接将他们的字符描述转换成embedding。对于relationships的原始数据形式，它的结构是一个三元组：
(Subject,Predicate,Object)
我们启发性地直接将它们合并成一个句子
"SubjectPredicateObject"
比如：
(Alex,childof,Brian)->"AlexchildofBrian"(Cole,marriedto,Brian)->"ColemarriedtoBria"
然后直接将这个句子转换成embedding，然后存储在向量数据库里。这种做法方便且直接，虽然这样做可能存在少量的语法问题，但这不影响句子含义的表达，也不影响它在向量空间中的分布。当然，我们同样也鼓励在前期抽取三元组的时候，直接使用LLM生成简短的句子描述。
4.2.向量相似搜索
对于输入的Query，我们遵循常见的GraphRAG中的范式（如HippoRAG，MSGraphRAG），将query提取entities，对于每个queryentity，转换成embedding，分别对entitycollection进行vectorsimilaritysearch。然后将所有queryentities搜索得到的结果进行合并。
对于relationship的向量搜索，我们直接将querystring，转换成embedding，对relationshipcollection进行vectorsimilaritysearch。
4.3.扩展子图
Expandingsubgraphfromtworetrievedways,thenmergedthemtogether
我们以搜索到的entities和relationships为知识图谱里的起始，往外扩大一定的范围。对于起始entities，我们往外扩大一定的跳数后，取它们邻接的relationships，记为
对于起始relationships，我们往外扩大一定跳数，得到
我们将两个set取并集，
基于跳数有限性，我们仅需要扩大较小的度数（如1，2等），就能涵盖大部分可能有助回答的relationships。请注意，这一步扩展的度数的概念和回答问题总共需要的跳度的概念不同。比如，如果回答一个query问题涉及两个相差n跳的entities，那么实际上往往只需要扩展n/2度就可以，因为这两个entities是被向量相似召回后的两个起始端点。如图，向量召回到了两个红色的entities，只需要从它们开始，相向扩展2度，就能覆盖到4度的跳数，这足以回答涉及到这两个entities的4跳问题。
Infact,toanswerthequestionwith4degreehops,youonlyneedtoexpanditby2degreesfrombothendpointsinthesetting.
4.4.LLMRerank
这一步中，我们使用LLM强大的自注意力机制，完成对relationships候选集的进一步筛选。我们使用one-shotprompt，将query和relationships候选集放入prompt里，要求LLM从中选择出可能对回答这个query有帮助的relationships。考虑到有些query可能存在一定的复杂性，我们采用Chain-of-Thought的思想，让LLM的回答里写下思考过程，我们观察到，这一方法对一些偏弱的模型有一些帮助。我们规定LLM的返回为json格式，以便于解析格式。具体的prompt参考如下：
Oneshotinputprompt
这个prompt是一个展示的参考，实际上，如何把relationships中的三元组转成一个通顺的短句，是一个棘手的问题。但是，你完全可以用上文提到的启发性的方法，把三元组直接拼在一起。如：
(Eleanor,bornin,1122)可以直接转成Eleanorbornin1122
这种方式有时会带来一定的语法问题，但它是最快，最直接的方式，也不会对LLM带来误解。
4.5.获得最终passages
对于上面的例子，实际上可以在LLMrerank这个阶段直接返回最终的回答，比如在Oneshotoutputprompt的json字段里加上比如“finalanswer”的字段。但是，这一步的prompt里只有relationship的信息，不一定所有问题都可以在这个阶段返回最终答案，所以其它具体的信息应该要在原始的passsage里获得。
LLM返回精确排序后的relationships。我们只需要取出先前在存储中的对应relationship信息，从中获取相应的metadata，在那里有对应的passageids。这些passages信息就是最终被retrieved到的passages。后续生成回答的过程和naiveRAG一样，就是将它们放入prompt的context中，让LLM给出最后的回答。
结果
我们使用与HippoRAG中一致的denseembedding，facebook/contriever，来作为我们的embedding模型，可以看到，在三个multi-hop的数据集上结果比较上，我们的方法大幅超过naiveRAG和HippoRAG的结果。所有的方法使用相同的embedding模型设置。我们使用Recall@2作为我们的衡量指标，它表示，
Onthemulti-hopdatasets,ourmethodoutperformsnaiveRAGandHippoRAGinalldatasets,allofthemarecomparedusingthesamefacebook/contrieverembeddingmodel.
这一结果说明了，即使是最简单的多路召回然后rerank的RAG范式，应用在graphRAG的场景上，也能得到state-of-the-art的performance。这一结果也说明了，合理的向量召回和LLM设置，是应用在multi-hopQA场景中的关键。
回顾我们的方法，把entities和relationships转成向量，并进行搜索的作用就是寻找子图的起点，它像是破解刑侦案件中的现场发现的“线索”。而后面扩展子图和LLMrerank的过程像是具体通过这些“线索”进行分析的过程，LLM拥有“上帝视角”，可以在一众的候选relationships中，聪明地选择对破案有用的relationships。这两个阶段，回归本质，也就是对应朴素的vectorretrieval+LLMreranking范式。
作者介绍
张晨，Zilliz算法工程师
会议推荐
12月13日至14日（下周五至周六），AICon全球人工智能开发与应用大会将在北京盛大开幕！本次大会汇聚70+位AI及技术领域的顶尖专家，深入探讨大模型与推理、AIAgent、多模态、具身智能等前沿话题。此外还有丰富的圆桌论坛、以及展区活动，带你深入探索大模型的最新实践与未来趋势。年度最后一次AI盛宴，让我们一起见证AI未来。