探讨了将知识图谱融入向量数据库以提升检索增强生成（RAG）效果的技术方案。针对传统 RAG 在处理复杂实体关系和多跳问题时的局限性，文章提出了基于跳数有限性假设的简化架构。该方法通过将实体和关系三元组向量化存储，利用向量相似搜索定位子图起点，再结合 LLM 的重排序能力筛选关键关系，最终实现高效的检索。实验显示，该方案在 Multi-hop 数据集上表现优于 Naive RAG 和 HippoRAG，证明了简单的向量召回加重排序范式在图 RAG 场景下的有效性，且无需复杂的图算法和高昂的 Token 开销。
随着大型语言模型（LLMs）在各种应用中的广泛使用，如何提升其回答的准确性和相关性成为一个关键问题。检索增强生成（RAG）技术通过整合外部知识库，为 LLMs 提供了额外的背景信息，有效地改善了模型的幻觉、领域知识不足等问题。然而，仅依靠简单的 RAG 范式存在一定的局限性，尤其在处理复杂的实体关系和多跳问题时，模型往往难以提供准确的回答。
将知识图谱（KG）引入 RAG 系统为解决这一问题提供了新的路径。知识图谱通过结构化的方式呈现实体及其关系，能够在检索过程中提供更为精细的上下文信息。通过利用 KG 的丰富关系性数据，RAG 不仅能够更精准地定位相关知识，还能更好地处理复杂的问答场景，如对比实体间的关系或回答多跳问题。
然而，当前的 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 开销和任何图算法。
尽管使用很简单的架构，但我们的方法显著超过目前 state-of-the-art 的解决方案，比如 HippoRAG，并且仅仅需要用到向量存储和少量的 LLM 开销。我们首先引入我们方法的理论基础，然后介绍具体方法过程。
我们观察到在实际的 KG-RAG 场景中，存在跳数有限性假设：在 KG-based RAG 中，实际问的 query 问题的查询路由只需要在知识图谱中进行有限的，且很少的跳数（如少于 4 跳）的查询，而并不需要在其中进行非常多次跳数。
我们的跳数有限性假设基于两点很重要的观察：1. query 复杂度有限性，2. '捷径'的局部 dense 结构。
用户的一个提问 query，不太可能涉及到非常多的 entities，或者引入复杂的 relationships。否则这个问题会显得非常奇怪和不切实际。
正常的 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 结构，对于有些 query，有一些'捷径'，可以从一个 entity 通过捷径快速连接到多跳之外的 entity。
假设我们有一个家庭关系的知识图谱，包含以下实体和关系：
- 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 进行知识图谱内信息检索的过程可以用下面这两步来实现：
整个过程不需要其任何它的 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。
我们准备两个向量存储 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 Brian"然后直接将这个句子转换成 embedding，然后存储在向量数据库里。这种做法方便且直接，虽然这样做可能存在少量的语法问题，但这不影响句子含义的表达，也不影响它在向量空间中的分布。当然，我们同样也鼓励在前期抽取三元组的时候，直接使用 LLM 生成简短的句子描述。
from sentence_transformers import SentenceTransformer
import numpy as np
model = SentenceTransformer('all-MiniLM-L6-v2')
# 示例三元组
triples = [
("Einstein", "won", "Nobel Prize"),
("Nobel Prize", "year", "1921")
]
# 转换为字符串
sentences = [f"{s} {p} {o}" for s, p, o in triples]
embeddings = model.encode(sentences)
# 存入向量数据库的逻辑伪代码
# db.add(collection="relationships", vectors=embeddings, metadatas=[{"subject": s, "pred": p, "obj": o}])
我们以搜索到的 entities 和 relationships 为知识图谱里的起始，往外扩大一定的范围。对于起始 entities，我们往外扩大一定的跳数后，取它们邻接的 relationships，记为 $R_{start}$。对于起始 relationships，我们往外扩大一定跳数，得到 $R_{rel}$。
我们将两个 set 取并集，$R_{total} = R_{start} \cup R_{rel}$。
基于跳数有限性，我们仅需要扩大较小的度数（如 1，2 等），就能涵盖大部分可能有助回答的 relationships。请注意，这一步扩展的度数的概念和回答问题总共需要的跳度的概念不同。比如，如果回答一个 query 问题涉及两个相差 n 跳的 entities，那么实际上往往只需要扩展 ⌈n / 2⌉ 度就可以，因为这两个 entities 是被向量相似召回后的两个起始端点。
如图，向量召回到了两个红色的 entities，只需要从它们开始，相向扩展 2 度，就能覆盖到 4 度的跳数，这足以回答涉及到这两个 entities 的 4 跳问题。
这一步中，我们使用 LLM 强大的自注意力机制，完成对 relationships 候选集的进一步筛选。我们使用 one-shot prompt，将 query 和 relationships 候选集放入 prompt 里，要求 LLM 从中选择出可能对回答这个 query 有帮助的 relationships。考虑到有些 query 可能存在一定的复杂性，我们采用 Chain-of-Thought 的思想，让 LLM 的回答里写下思考过程，我们观察到，这一方法对一些偏弱的模型有一些帮助。我们规定 LLM 的返回为 json 格式，以便于解析格式。
具体的 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.
...
[11] Richard the Lionheart led the Third Crusade.
这个 prompt 是一个展示的参考，实际上，如何把 relationships 中的三元组转成一个通顺的短句，是一个棘手的问题。但是，你完全可以用上文提到的启发性的方法，把三元组直接拼在一起。如：(Eleanor, born in, 1122) 可以直接转成 Eleanor born in 1122。这种方式有时会带来一定的语法问题，但它是最快，最直接的方式，也不会对 LLM 带来误解。
对于上面的例子，实际上可以在 LLM rerank 这个阶段直接返回最终的回答，比如在 One shot output prompt 的 json 字段里加上比如'final answer'的字段。但是，这一步的 prompt 里只有 relationship 的信息，不一定所有问题都可以在这个阶段返回最终答案，所以其它具体的信息应该要在原始的 passages 里获得。
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（召回率） = 检索到的相关文档总数 / 数据存储中相关文档总数
这一结果说明了，即使是最简单的多路召回然后 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，中等以上规模的模型都能胜任这些任务。你也可以参考相关的 notebook 代码示例，以获得更多实现的细节。
本文提出了一种轻量级的知识图谱增强检索方法，通过将实体和关系转化为向量嵌入，结合向量数据库的高效检索能力和 LLM 的语义理解能力，实现了在无需复杂图算法的情况下达到 SOTA 性能。该方法的核心在于利用了实际查询中的跳数有限性和知识图谱的局部稠密结构特性，通过多路召回加重排序的架构，有效解决了传统 RAG 在多跳问答中的不足。实验结果表明，该方案在保持低计算成本的同时，显著提升了检索的准确率和召回率，为构建高效的大模型知识库系统提供了可行的工程化路径。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online