知识图谱与向量数据库融合提升 RAG 检索效果的技术实践

知识图谱中的查询路径涉及多个节点跳转，跳数可达 7 跳以上。

说明：这是一个较为复杂的问题，要求不仅仅是查询单一的事实，还涉及多个节点之间的复杂关联。这种问题在实际场景中不太常见，因为用户一般不倾向于在一次查询中寻求如此复杂的信息交叉。通常，这类问题会被分解为多个简单查询，以便逐步获取信息。

'捷径'的局部 Dense 结构

知识图谱中是存在一些局部 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 进行知识图谱内信息检索的过程可以用下面这两步来实现：

1. 路由的起点，可以通过向量相似性查找来完成。可以涉及到 query 与 entities 或 query 与 relationships 的相似度关系查找。
2. 从起点找到其它信息的路由过程，可以用一个 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。

方法详解

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 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}])

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. 扩展子图

我们以搜索到的 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 跳问题。

4.4. LLM Rerank

这一步中，我们使用 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 带来误解。

4.5. 获得最终 Passages

对于上面的例子，实际上可以在 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 在多跳问答中的不足。实验结果表明，该方案在保持低计算成本的同时，显著提升了检索的准确率和召回率，为构建高效的大模型知识库系统提供了可行的工程化路径。