基于知识图谱的 RAG：固定实体架构实现方案

这里的建议是根据数据集的性质、控制需求和可用资源进行选择。结合两种方法的元素可能会优化性能。

本体鱼骨图

什么是本体？您是否曾考虑过您自己微观世界的本体？在工作中，您每天执行任务，而没有有意识地理解您的大脑如何识别这些'事物'以及如何在它们之间建立连接。试试这个练习：尝试创建一个'事物'的元模型，并绘制它们之间的连接。

本体是帮助我们理解周围世界的强大工具。'鱼骨图'隐喻鼓励我们深入探讨定义我们概念领域的基本构建块和连接。创建本体涉及仔细考虑要包含什么、元素之间的关系以及哪些是最重要的。鱼骨结构帮助我们识别核心元素，同时承认将我们的想法带入生活的复杂连接网。

现在，假设您在一个狭窄的领域内工作，并且对构成您工作的实体'鱼骨图'有清晰的理解。您如何轻松地将所有这些信息连接起来，并为任何 RAG 应用构建一个知识库？

创建基本的'鱼骨'结构：爱因斯坦示例

在许多组织中，主题专家可以轻松识别定义明确的领域内的关键实体和关系。这些基础知识对于构建有效的知识图谱至关重要。通过利用这些专业知识，可以在几天内建立一个关键实体及其关系的基本'鱼骨图'，为进一步丰富详细信息提供坚实的基础。

在创建鱼骨图时，请记住尽可能为您的实体包含描述。让我们考虑一个著名的示例来说明知识图谱的构建过程：句子'阿尔伯特·爱因斯坦发展了相对论，这彻底改变了理论物理学和天文学。'这个广为人知的句子展示了如何提取实体和关系。

Cypher 是一种声明式查询语言，用于与图数据库（尤其是 Neo4j）进行交互。它允许用户以直观的类似 SQL 的语法表达复杂的图模式和关系。

在我们的爱因斯坦示例中，我们有四个实体（阿尔伯特·爱因斯坦、相对论、理论物理学和天文学）以及三条具有两种类型的边（开发和革命化）。我们可以为每个实体添加简要描述。将其转换为 Cypher 代码，创建图的过程如下：

CREATE (a:Entity {label: 'Person', name: 'Albert Einstein', embeddings: $person_emb}), 
(b:Entity {label:'Theory', name: 'Theory of relativity', embeddings: $theory_emb}),  
(c:Entity {label:'Field', name: 'Theoretical physics', embeddings: $field1_emb }), 
(d:Entity {label:'Field', name: 'Astronomy', embeddings: $field2_emb })

// 创建边  
CREATE (a)-[:DEVELOPED]->(b),  
(b)-[:REVOLUTIONIZED]->(c),  
(b)-[:REVOLUTIONIZED]->(d)

请注意，我仅使用一个关联标签'Entity'创建节点，但为每个节点包含不同的标签作为属性。这是为了在后续搜索中保持清晰。所有节点在内部都称为实体，形成了后续操作的固定鱼骨结构。

这里的 embeddings 参数仅包含'label: name'值，但在实际操作中，我建议还包括实体的详细描述，并将其添加到您的嵌入向量中。

增加知识

现在，我们有了构建知识库用于 RAG 应用的'鱼骨图'。为了创建这个知识库，我们需要文档。对于阿尔伯特·爱因斯坦，我使用了维基百科文章。我使用维基百科 API 复制了文本，并将其拆分为 59 个块，每块大小为 2000。

将文档添加到图中

让我们以以下方式将文档块添加到图中：

prev_node_id = None # 在循环前初始化 prev_node_id
for i, chunk in enumerate(chunks):  
    # 创建文档节点  
    query = f'''  
    CREATE (d:Document {{  
    chunkID: "chunk_{i}",  
    url: "{url}",  
    docID: "{document_name}",  
    full_text: '{escaped_chunk}',  
    embeddings: {embeddings.embed_documents(chunk).tolist()}}}  
    )  
    RETURN ID(d)  
    '''  
    run_query(driver, query)  
    chunk_node_id = result[0]['ID(d)']

    # 如果不是第一个块，创建与前一个块的 NEXT 关系  
    if prev_node_id is not None:  
        query = f'''  
        MATCH (c1:Document), (c2:Document)  
        WHERE ID(c1) = {prev_node_id} AND ID(c2) = {chunk_node_id}  
        CREATE (c1)-[:NEXT]->(c2)  
        CREATE (c2)-[:PREV]->(c1)  
        '''  
        run_query(driver, query)  
    prev_node_id = chunk_node_id

这段代码将块作为标签为'Document'的节点添加。通过将文档块相互连接为节点，后续检索中将具有显著优势。您可以使用 Cypher 查询定义，如果找到相似的块，还可以检索前一个和下一个块。

将文档与固定实体连接

接下来，让我们将文本块连接到我们的固定实体'鱼骨图'。请注意，这种方法不使用任何昂贵的 LLM 技术，并避免在知识库中创建重复。此外，执行时间仅需毫秒。我们使用一种简单的数学公式，称为点积，它提供了每个块与固定实体之间的余弦相似度值。以下 Cypher 代码将实现这一点：

MATCH (e:Entity), (d:Document)
WHERE e.embeddings IS NOT NULL 
  AND d.embeddings IS NOT NULL 
  AND size(e.embeddings) = size(d.embeddings)
WITH e, d, 
     reduce(numerator = 0.0, i in range(0, size(e.embeddings)-1) | numerator + toFloat(e.embeddings[i])*toFloat(d.embeddings[i])) as dotProduct, 
     sqrt(reduce(eSum = 0.0, i in range(0, size(e.embeddings)-1) | eSum + toFloat(e.embeddings[i])^2)) as eNorm, 
     sqrt(reduce(dSum = 0.0, i in range(0, size(d.embeddings)-1) | dSum + toFloat(d.embeddings[i])^2)) as dNorm
WITH e, d, dotProduct / (eNorm * dNorm) as cosineSimilarity
WHERE cosineSimilarity > 0.8  
MERGE (e)-[r:RELATES_TO]->(d)  
ON CREATE SET r.cosineSimilarity = cosineSimilarity
RETURN ID(e), e.name, ID(d), d.full_text, r.cosineSimilarity
ORDER BY cosineSimilarity DESC

在此示例中，我们指示数据库使用向量索引从所有实体节点中提取，并通过计算它们与用户查询之间的向量角度来比较它们与每个文档块的相似度。如果余弦相似度超过给定的阈值（此处为 0.8），数据库将在实体节点和文档节点之间创建一个名为 RELATES_TO 的边。由于块未经过优化，并且固定实体缺乏详细描述，匹配可能不太高。此示例旨在说明该技术。

不仅实体'阿尔伯特·爱因斯坦'连接到了相关的文本块，'相对论'也是如此。随着更多文档的添加，'鱼骨图'实体将越来越多地作为元素之间的连接器。这是使用图的一个优势——几乎所有东西都是相互连接的。没有稀疏性的问题需要聚类。

为混合搜索构建不同类型的索引

Neo4j 的优势在于能够在您的图上创建各种类型的索引，更棒的是，您甚至可以使用单个 Cypher 查询执行混合搜索。让我们为我们的检索准备索引。

创建向量索引

首先，我们创建向量索引：

queries = [  
    "DROP INDEX test_index_document IF EXISTS;",  
    "DROP INDEX test_index_entity IF EXISTS;"  
]

for query in queries:  
    run_query(driver, query)

# 为文档嵌入创建向量索引
CREATE VECTOR INDEX test_index_document  
IF NOT EXISTS  
FOR (d:Document)  
ON (d.embeddings)  
OPTIONS {indexConfig: {  
    `vector.dimensions`: 768,  
    `vector.similarity_function`: 'cosine'  
}}  

# 为实体嵌入创建向量索引
CREATE VECTOR INDEX test_index_entity IF NOT EXISTS  
FOR (n:Entity)  
ON (n.embeddings)  
OPTIONS {indexConfig: {  
    `vector.dimensions`: 768,  
    `vector.similarity_function`: 'cosine'  
}}  

一旦在节点上创建了向量索引，您还可以在边上创建向量索引，如果您有它们的描述。由于此阶段我没有关系的任何文本，因此我将跳过此步骤。

创建文本索引

接下来，我将创建一个文本索引，这也将作为标准关键字索引添加到搜索中。

# 为实体描述创建全文索引
CREATE FULLTEXT INDEX text_index_entity FOR (n:Entity) ON EACH [n.name]  

# 为文档全文文本创建全文索引
CREATE FULLTEXT INDEX text_index_document FOR (d:Document) ON EACH [d.full_text]  

检索

现在我们的知识库已准备好进行检索，并可用于构建 RAG 应用，我们可以开始查询图数据库。

让我们从一个简单的查询开始。我们将要求数据库找到给定查询的最佳匹配答案。例如，我们使用查询：'阿尔伯特·爱因斯坦的研究领域'。

首先，我将使用基于实体的向量索引。查询涉及将原始用户查询嵌入到向量索引中和/或将其用作关键字索引的文本。我将从一个简单的查询（查询 1）开始：

CALL db.index.vector.queryNodes('test_index_entity', 10, $user_query)  
YIELD node AS vectorNode, score as vectorScore  
WITH vectorNode, vectorScore  
ORDER BY vectorScore DESC  
RETURN vectorNode.name AS label, vectorScore AS score

在这里，我仅查询固定实体，特别是使用建立在它们上的向量索引。结果有些可预测。仅提取实体，尤其是在此阶段缺乏描述时，为 RAG 应用提供的价值有限。为了增强我们的结果，我们需要提取与问题相关的文档。让我们更进一步，识别与找到的实体最相关的文档（查询 2）：

CALL db.index.vector.queryNodes('test_index_entity', 10, $user_query)  
YIELD node AS vectorNode, score as vectorScore  
WITH vectorNode, vectorScore  
MATCH (vectorNode)-[r]->(d:Document)  
WITH vectorNode.name AS label, vectorScore as score, d.docID as closest_document_name,  
     d.full_text as closest_document_text, r.cosineSimilarity as similarity  
ORDER BY similarity DESC  
RETURN label, closest_document_name, closest_document_text, similarity  
LIMIT 10

结果，如预期所示，与初始查询略有不同。这里，'天文学'首先返回。然而，而不是预期的'相对论'，出现了'阿尔伯特·爱因斯坦'。使用 GraphRAG 结合这种方法的优势在于其灵活性：您可以调整搜索以更好地适应应用的需求。让我们完善我们的查询，以优先考虑'天文学'和'相对论'作为此问题的顶级结果。

为了进一步提升结果，我们可以实施一个交叉编码器重新排序步骤。尽管我通常在描述上进行重新排序，但在这种情况下，由于缺乏描述，我将在标签上应用它。我将使用 sentence_transformers 库中的 cross-encoder/ms-marco-MiniLM-L-6-v2 模型。

如您所见，重新排序与查询结合并未产生预期的结果。为了改进结果，我们可以结合全文或关键字搜索（查询 3）：

CALL db.index.vector.queryNodes('test_index_entity', 10, $my_query_emb_list)  
YIELD node AS vectorNode, score as vectorScore  
WITH vectorNode, vectorScore  
MATCH (vectorNode)-[r]->(d:Document)  
WITH vectorNode.name AS label, vectorScore as score, d.docID as closest_document_name,  
     d.full_text as closest_document_text, r.cosineSimilarity as similarity  
ORDER BY similarity DESC  
RETURN label, closest_document_name, closest_document_text, similarity  
LIMIT 10

UNION

CALL db.index.fulltext.queryNodes('text_index_entity', $my_query)  
YIELD node AS textNode, score as textScore  
WITH textNode, textScore  
MATCH (textNode)-[r]->(d:Document)  
WITH textNode.name AS label, textScore as score, d.docID as closest_document_name,  
     d.full_text as closest_document_text, r.cosineSimilarity as similarity  
ORDER BY similarity DESC  
RETURN label, closest_document_name, closest_document_text, similarity  
LIMIT 10

这个查询的结果显示在表 7 中。之前的尝试，包括重新排序，并未产生预期的结果。现在，我将展示检索在图中的真正威力。为了避免 APOC 库的问题和与 Python 工具的兼容性问题，我专注于一种清晰、透明的方法。我将使用纯数学方法来说明图的搜索能力的有效性。下一个查询展示了我在工作中称之为'智能搜索'的方法（查询 4）。

CALL db.index.vector.queryNodes('test_index_entity', 10, $user_query_emb) 
YIELD node AS vectorNode, score as vectorScore 
WITH vectorNode, vectorScore 
MATCH (vectorNode)-[r]->(d:Document) 
WITH DISTINCT vectorNode as e, d, r, r.cosineSimilarity as cosineSimilarity 
ORDER BY cosineSimilarity DESC 
WITH ID(e) as id, e.label as title, 
     cosineSimilarity, 
     e.description as description, 
     head(collect(d.docID)) as document_id, 
     head(collect(d.chunkID)) as chunkID, 
     head(collect(d.full_text)) as document_text, 
     reduce(mDot = 0.0, i IN range(0, size($user_query_emb) - 1) | mDot + $user_query_emb[i] * e.embeddings[i]) / 
     (sqrt(reduce(mSq = 0.0, x IN $user_query_emb | mSq + x^2)) * sqrt(reduce(eSq = 0.0, y IN e.embeddings | eSq + y^2))) AS entity_similarity,  
     reduce(mDot = 0.0, i IN range(0, size($user_query_emb) - 1) | mDot + $user_query_emb[i] * d.embeddings[i]) /  
     (sqrt(reduce(mSq = 0.0, x IN $user_query_emb | mSq + x^2)) * sqrt(reduce(dSq = 0.0, y IN d.embeddings | dSq + y^2))) AS document_similarity  
WITH id, title, description, document_id, document_text, entity_similarity, document_similarity, chunkID,  
     (entity_similarity + document_similarity) / 2 AS similarity, cosineSimilarity  
WHERE similarity > 0.8  
RETURN id, title, document_id, document_text, similarity, chunkID  
ORDER BY cosineSimilarity DESC, similarity DESC

通过这个查询，我首先使用向量索引提取固定实体，然后识别最佳匹配的文档。接下来，我计算提取的实体与用户查询之间的点积，以及找到的文档与用户查询之间的点积。然后，我将这些结果结合起来，并根据 0.8 的阈值进行过滤。结合重新排序，这种方法产生了良好的结果。

通过这个实验，我旨在展示检索在图中的威力。通过完全控制固定实体和添加文档的过程，并灵活构建几乎任何检索 Cypher 查询，其潜力是巨大的。根据您的具体使用案例调整检索过程的自由几乎是无限的。在这个实验中，我们使用了一个有限的固定实体架构，缺乏广泛的描述和元素之间的关系。然而，通过结合更多的信息和连接，可以实现显著的结果。

总结

本文探讨了使用图构建和查询知识库，重点介绍了固定实体架构及其在检索增强生成（RAG）系统中的应用。固定实体架构依赖于预定义的实体和关系来构建知识图谱，具有较低的复杂性、高精度和降低的计算成本等优点。然而，它在灵活性和可扩展性方面可能面临限制。

本文展示了如何使用'鱼骨图'本体构建知识图谱并将文档集成到图中。通过利用向量索引和 Cypher 查询，文档根据余弦相似度与实体连接。这种方法增强了检索能力，但可能需要优化以获得更好的结果。

进行了一系列查询以评估基于图的检索方法的有效性。初始查询使用向量索引和关键字搜索来查找匹配的实体和文档。尽管存在一些挑战，如重新排序结果不理想，本文展示了图在强大且灵活的检索中的潜力。最终的智能搜索查询结合向量相似度和点积计算，展示了该方法在优化搜索结果方面的有效性。

未来方向和创新

• 改进机会：增强基于 LLM 的提取方法和扩展预定义本体可以进一步优化知识图谱的能力。在实际部署中，可以考虑引入 HNSW 索引以加速向量搜索，或使用子图遍历策略来处理多跳查询。
• 新兴趋势：知识图谱开发中的新技术和进展可能会增强 RAG 系统，为复杂的检索任务提供更强大的解决方案。例如，动态更新机制和本体自动演化将是未来的研究方向。

总体而言，本文强调了图灵活的搜索能力的优势，以及优化实体连接和文档集成以实现高质量检索结果的重要性。提取技术的未来发展和新兴技术有望进一步推进知识图谱在 RAG 应用中的能力。