知识图谱 + 向量检索:手把手教你搭建高性价比的 RAG 系统
本文提出了一种基于多路召回和重排的简单高效知识图谱增强检索方法(GraphRAG),通过向量化检索和LLM重排两个关键步骤,显著提升了多跳问答任务的性能。该方法创新性地发现:1)知识图谱查询通常只需有限跳数(2-4跳);2)局部密集结构存在查询捷径。实验证明,仅使用向量数据库和少量LLM调用,该方法在三个多跳数据集上的Recall@2指标就大幅超越传统RAG和HippoRAG等图算法方案。这种轻量
前 言
随着大型语言模型(LLMs)在各类场景中的深度渗透与广泛应用,如何突破其在特定任务中的准确性瓶颈、强化回答与需求的强相关性,已成为当前技术落地的核心议题。检索增强生成(RAG)技术作为关键解决方案,通过动态整合外部知识库,为 LLMs 补充实时、专业的背景信息,成功缓解了模型 “幻觉生成”“领域知识滞后” 等核心痛点,成为连接模型与真实世界知识的重要桥梁。
然而,传统的基础 RAG 范式仍存在显著局限:其检索逻辑多依赖文本片段的浅层匹配,在面对需要深度解析的复杂任务时 —— 例如梳理多实体间的层级关联、解答需跨多个知识节点推导的 “多跳问题”,仅靠碎片化信息难以支撑模型构建完整的逻辑链条,导致回答准确率大幅下降、逻辑连贯性不足。
在此背景下,将知识图谱(KG)引入 RAG 系统,为突破这一技术瓶颈提供了全新路径。知识图谱以结构化的 “实体 - 关系 - 属性” 三元组形式,系统性地呈现知识网络,不仅能精准定位单个实体信息,更能清晰还原实体间的复杂关联(如因果、从属、协同等)。将这种结构化知识融入 RAG 的检索与生成环节,一方面可让检索过程从 “文本匹配” 升级为 “知识关联挖掘”,精准定位支撑复杂任务的关键知识节点;另一方面能为 LLMs 提供清晰的逻辑框架,助力模型在生成阶段构建严谨的推理路径,从而更高效地应对实体关系分析、多跳推理等复杂问答场景,进一步提升回答的准确性与逻辑性。

Comparision between Direct LLM, RAG, and GraphRAG.https://arxiv.org/pdf/2408.08921
然而,当前的 KG-RAG 还处在早期的探索阶段,行业对相关技术路线还未达成统一共识。比如,如何有效检索知识图谱中的相关 entities 和 relationships,如何将向量相似性搜索和图结构结合起来,目前没有形成统一的范式。
比如,微软的 From Local to Global 使用大量的 LLM 访问将子图结构以汇总成社区摘要,但这一过程消耗大量的 LLM tokens,使这一方法昂贵且不切实际。HippoRAG 使用 Personalized PageRank 重新更新图节点的权重,以找到重要的 entities,但这种以 entity 为中心的方法很容易受到 NER 遗漏的影响,而忽略了上下文中的其它信息。IRCoT 使用多步 LLM 请求来逐步推理得到最终的回答,但这种方法将 LLM 引入多跳查找过程,导致回答问题的时间过长,很难实际应用。
我们发现,实际上用一个简单的多路召回然后 rerank 的 RAG 范式,就能够很好的处理复杂的多跳 KG-RAG 场景,而并不需要过多的 LLM 开销和任何图算法。

Our simple pipeline is not much different from the common multi-way retrieval and rerank architecture, but it can achieve the SoTA performance in the multihop graph RAG scenario.
尽管使用很简单的架构,但我们的方法显著超过目前 state-of-the-art 的解决方案,比如 HippoRAG,并且仅仅需要用到向量存储和少量的 LLM 开销。我们首先引入我们方法的理论基础,然后介绍具体方法过程。
理 论
我们观察到在实际的 KG-RAG 场景中,存在跳数有限性假设:在 KG-based RAG 中,实际问的 query 问题的查询路由只需要在知识图谱中进行有限的,且很少的跳数(如少于 4 跳)的查询,而并不需要在其中进行非常多次跳数。
我们的跳数有限性假设基于两点很重要的观察:1. query 复杂度有限性, 2.“捷径”的局部 dense 结构。
query 复杂度有限性
用户的一个提问 query,不太可能涉及到非常多的 entities,或者引入复杂的 relationships。否则这个问题会显得非常奇怪和不切实际。

Normal query vs. Weird query
y
正常的query:"爱因斯坦获得诺贝尔奖的时间是哪一年?"
In which year did Einstein win the Nobel Prize?
知识图谱中的查询路径:
找到节点“爱因斯坦”。
跳转到与“爱因斯坦”相关的“诺贝尔奖”节点。
返回奖项颁发的年份信息。
跳数:2 跳
说明:这是一个常见的用户问题,用户想要知道的是与某个具体实体直接相关的单一事实。知识图谱在这种情况下只需要进行少量跳数的查询即可完成任务,因为所有相关信息都直接与爱因斯坦这个中心节点关联。这种查询在实际应用中非常普遍,例如查询名人背景信息、奖项历史、事件时间等。
古怪的query:"相对论的发现者获得诺贝尔奖的年份与他们在一个以银行保密法和阿尔卑斯山壮丽风景而闻名的国家发明的专利数量之间有什么关系?"
What is the relationship between the year the discoverer of the theory of relativity received the Nobel Prize and the number of patents they invented in a country famous for its bank secrecy laws and the magnificent scenery of the Alps?
知识图谱中的查询路径:
找到“相对论”的“发明者”是“爱因斯坦”。
跳转到与“爱因斯坦”相关的“诺贝尔奖”节点。
查找“诺贝尔奖”获奖年份。
通过“银行保密法和阿尔卑斯山”找到“瑞士”
跳转到与“爱因斯坦”相关的“专利”节点。
查找与瑞士期间相关的专利信息。
比较专利数量和获奖年份之间的关系。
跳数:7跳
说明:这个问题较为复杂,要求不仅仅是查询单一的事实,还涉及多个节点之间的复杂关联。这种问题在实际场景中不太常见,因为用户一般不倾向于在一次查询中寻求如此复杂的信息交叉。通常,这类问题会被分解为多个简单查询,以便逐步获取信息。
“捷径”的局部 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 查询语句,只需要使用 vector database 和一次 LLM 的访问。而 vector retrieval + LLM rerank 才是这个 pipeline 中最关键的部分,这也就解释了我们只用一个传统的两路召回架构,就可以达到远超基于图理论的方法(如 HippoRAG) 的表现。这也说明了,实际上不需要复杂的图算法,我们只需要将图结构的逻辑关系存储在向量数据库里,用一个传统的架构就可以进行逻辑上的子图路由,而现代 LLM 强大的能力帮助做到了这一点。
方法概览
我们的方法只涉及在 RAG 流程中检索 passages 的阶段,不涉及 chunking 或 LLM response generation 的创新和优化。我们假设已经得到了一组 corpus 的三元组信息,它包含一系列的 entities 和 relationships 信息。这些信息可以表示一个知识图谱的信息。
我们将 entities, relationships 信息分别进行向量化,并存储在向量存储里,这样存储了一个逻辑上的知识图谱。当进行 query 查询时,会先把相关的 entities 和 relationships 检索出来。通过这些 entities 和 relationships,我们在图结构上进行有限的拓展。将这些 relationships 与 query 问题组装进 prompt 内,使用 LLM 的能力对这些 relationships 进行 reranking。最后得到 topK 个重要的 relationships,在他们的 metadata 信息内获得与他们相关的 passages,作为最终的 retrieved passages。

Overall pipeline of our method
方法详解
4.1. 向量入库
我们准备两个向量存储 collections,一个是 entity collection,另一个是 relationship collection。将一系列的 unique entities 信息和 relationships 信息,使用 embedding 模型,转换成向量,存储在向量存储中。对于 entities 信息,直接将他们的字符描述转换成 embedding。对于 relationships 的原始数据形式,它的结构是一个三元组:
(Subject, Predicate, Object)
我们启发性地直接将它们合并成一个句子
"Subject Predicate Object"
比如:
(Alex, child of, Brian) -> "Alex child of Brian"
(Cole, married to, Brian) -> "Cole married to Bria"
然后直接将这个句子转换成 embedding,然后存储在向量数据库里。这种做法方便且直接,虽然这样做可能存在少量的语法问题,但这不影响句子含义的表达,也不影响它在向量空间中的分布。当然,我们同样也鼓励在前期抽取三元组的时候,直接使用 LLM 生成简短的句子描述。
4.2. 向量相似搜索
-
对于输入的 Query,我们遵循常见的 GraphRAG 中的范式(如 HippoRAG,MS GraphRAG),将 query 提取 entities,对于每个 query entity,转换成 embedding,分别对 entity collection 进行 vector similarity search。然后将所有 query entities 搜索得到的结果进行合并。
-
对于 relationship 的向量搜索,我们直接将 query string,转换成 embedding,对 relationship collection 进行 vector similarity search。
4.3. 扩展子图

Expanding subgraph from two retrieved ways, then merged them together
我们以搜索到的 entities 和 relationships 为知识图谱里的起始,往外扩大一定的范围。对于起始 entities,我们往外扩大一定的跳数后,取它们邻接的 relationships,记为

对于起始 relationships,我们往外扩大一定跳数,得到

我们将两个 set 取并集,

基于跳数有限性,我们仅需要扩大较小的度数(如 1,2 等),就能涵盖大部分可能有助回答的 relationships。请注意,这一步扩展的度数的概念和回答问题总共需要的跳度的概念不同。比如,如果回答一个 query 问题涉及两个相差 n 跳的 entities,那么实际上往往只需要扩展 ⌈n / 2⌉ 度就可以,因为这两个 entities 是被向量相似召回后的两个起始端点。如图,向量召回到了两个红色的 entities,只需要从它们开始,相向扩展 2 度,就能覆盖到 4 度的跳数,这足以回答涉及到这两个 entities 的 4 跳问题。

In fact, to answer the question with 4 degree hops, you only need to expand it by 2 degrees from both end points in the setting.
4.4. LLM Rerank
这一步中,我们使用 LLM 强大的自注意力机制,完成对 relationships 候选集的进一步筛选。我们使用 one-shot prompt,将 query 和 relationships 候选集放入 prompt 里,要求 LLM 从中选择出可能对回答这个 query 有帮助的 relationships。考虑到有些 query 可能存在一定的复杂性,我们采用 Chain-of-Thought 的思想,让 LLM 的回答里写下思考过程,我们观察到,这一方法对一些偏弱的模型有一些帮助。我们规定 LLM 的返回为 json 格式,以便于解析格式。具体的 prompt 参考如下:
One shot input prompt
I will provide you with a list of relationship descriptions. Your task is to select 3 relationships that may be useful to answer the given question. Please return a JSON object containing your thought process and a list of the selected relationships in order of their relevance.**Question:**When was the mother of the leader of the Third Crusade born?**Relationship descriptions:**[1] Eleanor was born in 1122.[2] Eleanor married King Louis VII of France.[3] Eleanor was the Duchess of Aquitaine.[4] Eleanor participated in the Second Crusade.[5] Eleanor had eight children.[6] Eleanor was married to Henry II of England.[7] Eleanor was the mother of Richard the Lionheart.[8] Richard the Lionheart was the King of England.[9] Henry II was the father of Richard the Lionheart.[10] Henry II was the King of England.[11] Richard the Lionheart led the Third Crusade.One shot input prompt{"thought_process": "To answer the question about the birth of the mother of the leader of the Third Crusade, I first need to identify who led the Third Crusade and then determine who his mother was. After identifying his mother, I can look for the relationship that mentions her birth.","useful_relationships": ["[11] Richard the Lionheart led the Third Crusade","[7] Eleanor was the mother of Richard the Lionheart","[1] Eleanor was born in 1122"]}
这个 prompt 是一个展示的参考,实际上,如何把 relationships 中的三元组转成一个通顺的短句,是一个棘手的问题。但是,你完全可以用上文提到的启发性的方法,把三元组直接拼在一起。如:
(Eleanor, born in, 1122) 可以直接转成 Eleanor born in 1122
这种方式有时会带来一定的语法问题,但它是最快,最直接的方式,也不会对 LLM 带来误解。
4.5. 获得最终 passages
对于上面的例子,实际上可以在 LLM rerank 这个阶段直接返回最终的回答,比如在 One shot output prompt 的 json 字段里加上比如 “final answer”的字段。但是,这一步的 prompt 里只有 relationship 的信息,不一定所有问题都可以在这个阶段返回最终答案,所以其它具体的信息应该要在原始的 passsage 里获得。
LLM 返回精确排序后的 relationships。我们只需要取出先前在存储中的对应 relationship 信息,从中获取相应的 metadata,在那里有对应的 passage ids。这些 passages 信息就是最终被 retrieved 到的 passages。后续生成回答的过程和 naive RAG 一样,就是将它们放入 prompt 的 context 中,让 LLM 给出最后的回答。
结 果
我们使用与 HippoRAG 中一致的 dense embedding,facebook/contriever,来作为我们的 embedding 模型,可以看到,在三个 multi-hop 的数据集上结果比较上,我们的方法大幅超过 naive RAG 和 HippoRAG 的结果。所有的方法使用相同的 embedding 模型设置。我们使用 Recall@2 作为我们的衡量指标,它表示,
Recall(召回率) = 检索到的相关文档总数 / 数据存储中相关文档总数

On the multi-hop datasets, our method outperforms naive RAG and HippoRAG in all datasets, all of them are compared using the same facebook/contriever embedding model.
这一结果说明了,即使是最简单的多路召回然后 rerank 的 RAG 范式,应用在 graph RAG 的场景上,也能得到 state-of-the-art 的 performance。这一结果也说明了,合理的向量召回和 LLM 设置,是应用在 multi-hop QA 场景中的关键。
回顾我们的方法,把 entities 和 relationships 转成向量,并进行搜索的作用就是寻找子图的起点,它像是破解刑侦案件中的现场发现的“线索”。而后面扩展子图和 LLM rerank 的过程像是具体通过这些“线索”进行分析的过程,LLM 拥有“上帝视角”,可以在一众的候选 relationships 中,聪明地选择对破案有用的 relationships。这两个阶段,回归本质,也就是对应朴素的 vector retrieval + LLM reranking 范式。
在实践中,我们推荐大家使用开源 Milvus,或它的全托管版本 Zilliz Cloud,来存储并搜索 graph 结构中大量的 entities 和 relationships。而 LLM 可以选择开源模型如 Llama-3.1-70B 或闭源的 GPT-4o mini,中等以上规模的模型都能胜任这些任务。
读者福利大放送:如果你对大模型感兴趣,想更加深入的学习大模型,那么这份精心整理的大模型学习资料,绝对能帮你少走弯路、快速入门
如果你是零基础小白,别担心——大模型入门真的没那么难,你完全可以学得会!
👉 不用你懂任何算法和数学知识,公式推导、复杂原理这些都不用操心; 👉 也不挑电脑配置,普通家用电脑完全能 hold 住,不用额外花钱升级设备; 👉 更不用你提前学 Python 之类的编程语言,零基础照样能上手。
你要做的特别简单:跟着我的讲解走,照着教程里的步骤一步步操作就行。
包括:大模型学习线路汇总、学习阶段,大模型实战案例,大模型学习视频,人工智能、机器学习、大模型书籍PDF。带你从零基础系统性的学好大模型!
现在这份资料免费分享给大家,有需要的小伙伴,直接VX扫描下方二维码就能领取啦😝↓↓↓ 
为什么要学习大模型?
数据显示,2023 年我国大模型相关人才缺口已突破百万,这一数字直接暴露了人才培养体系的严重滞后与供给不足。而随着人工智能技术的飞速迭代,产业对专业人才的需求将呈爆发式增长,据预测,到 2025 年这一缺口将急剧扩大至 400 万!! 
大模型学习路线汇总
整体的学习路线分成L1到L4四个阶段,一步步带你从入门到进阶,从理论到实战,跟着学习路线一步步打卡,小白也能轻松学会! 
大模型实战项目&配套源码
光学理论可不够,这套学习资料还包含了丰富的实战案例,让你在实战中检验成果巩固所学知识 
大模型学习必看书籍PDF
我精选了一系列大模型技术的书籍和学习文档(电子版),它们由领域内的顶尖专家撰写,内容全面、深入、详尽,为你学习大模型提供坚实的理论基础。 
大模型超全面试题汇总
在面试过程中可能遇到的问题,我都给大家汇总好了,能让你们在面试中游刃有余 
这些资料真的有用吗?
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理,现任上海殷泊信息科技CEO,其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证,服务航天科工、国家电网等1000+企业,以第一作者在IEEE Transactions发表论文50+篇,获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目,无论你是小白还是有些技术基础的技术人员,这份资料都绝对能帮助你提升薪资待遇,转行大模型岗位。
👉获取方式:
😝有需要的小伙伴,可以保存图片到VX扫描下方二维码免费领取【保证100%免费】
相信我,这套大模型系统教程将会是全网最齐全 最适合零基础的!!
火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。
更多推荐
所有评论(0)