在本文中，我将重点介绍知识图谱（KG）与大型语言模型（LLM）结合使用的一种流行方式：使用知识图谱的检索增强生成（RAG），有时也称为Graph RAG、GraphRAG、GRAG或语义RAG。检索增强生成是指在向LLM发送提示以生成响应之前，检索相关信息来扩充该提示。其理念是，相较于直接将提示发送给未经过你特定数据训练的LLM，你可以通过补充LLM准确回答提示所需的相关信息来增强你的提示。在我前一篇文章中的示例是将职位描述和我的简历复制到ChatGPT中以撰写求职信。如果我提供我的简历和申请职位的描述，LLM就能对我的提示“为我写一封求职信”提供更相关的回应。由于知识图谱旨在存储知识，它们是存储内部数据并为LLM提示补充额外上下文以提高响应的准确性和情境理解的理想方式。

重要的是，我认为经常被误解的一点是，RAG及使用知识图谱的RAG（Graph RAG）是一种结合技术的方法论，并非产品或技术本身。没有人发明、拥有或对Graph RAG享有垄断权。然而，大多数人可以看到这两种技术结合的潜力，并且有越来越多的研究证明了结合它们的好处。

通常，使用知识图谱进行RAG中的检索部分有三种方式：

基于向量的检索：将你的知识图谱向量化并存储在向量数据库中。如果你随后将自然语言提示向量化，你就可以在向量数据库中找到与你的提示最相似的向量。由于这些向量对应于图中的实体，你可以根据自然语言提示返回图中最“相关”的实体。请注意，没有图你也可以执行基于向量的检索。这实际上是RAG最初实现的方式之一，有时被称为基线RAG。你会将SQL数据库或内容向量化，并在查询时检索。
提示到查询的检索：利用LLM为你编写SPARQL或Cypher查询，然后将查询应用于你的知识图谱，并使用返回的结果来扩充你的提示。
混合（向量+SPARQL）：你可以以各种有趣的方式组合这两种方法。在本教程中，我将展示一些你可以结合这些方法的方式。我将主要关注使用向量化进行初始检索，然后使用SPARQL查询来精炼结果。
然而，结合向量数据库和知识图谱进行搜索、相似度和RAG的方法有很多。这只是为了突出每种方法各自的优缺点以及共同使用它们的好处的一个说明性示例。我在这里结合它们的方式——使用向量化进行初步检索，然后使用SPARQL进行过滤——并非独有。我已在其他地方看到过这种实现。一个我道听途说的好例子来自一家大型家具制造商的员工。他说，向量数据库可能会向购买沙发的人推荐粘毛刷，但知识图谱会理解材料、属性和关系，并确保不会向购买皮质沙发的人推荐粘毛刷。

在本教程中，我将：

将数据集向量化到向量数据库中，以测试语义搜索、相似性搜索和RAG（基于向量的检索）
将数据转换为知识图谱，以测试语义搜索、相似性搜索和RAG（提示到查询的检索，尽管实际上更像是查询检索，因为我直接使用SPARQL而非让LLM将自然语言提示转化为SPARQL查询）
将带有知识图谱标签和URI的数据集向量化到向量数据库中（我将之称为“向量化知识图谱”）并测试语义搜索、相似性和RAG（混合方式）
目标是展示知识图谱和向量数据库在这些能力上的差异，并展示它们可以如何协同工作。以下是向量数据库和知识图谱如何共同执行高级查询的高级概述。

如果你懒得继续阅读，这里有一个简短总结：

向量数据库在运行语义搜索、相似度计算及一些基础形式的RAG（检索增强生成）方面表现良好，但有几个注意事项。首先，我使用的数据包含期刊文章摘要，即与实体关联有大量的非结构化文本。向量化模型主要针对非结构化数据进行训练，因此在处理与实体相关的文本块时表现优秀。
也就是说，将你的数据转化为向量数据库并准备查询所需的工作量非常小。如果你的数据集中包含一些非结构化数据，你可以在15分钟内完成向量化并开始搜索。
不出所料，仅使用向量数据库的最大缺点之一是缺乏可解释性。返回的结果中可能有三个合理，而第四个则不太合理，且无法知道为何会出现这个第四个结果。
对于搜索和相似度而言，向量数据库返回不相关内容的可能性是一种困扰，而对于RAG则是大问题。如果你用四篇文章来丰富你的提示，其中一篇却是完全不相关的主题，那么LLM（大型语言模型）的响应就会产生误导。这通常被称为“上下文污染”。
上下文污染尤其危险的地方在于，响应不一定事实错误，也不是基于错误的数据，只是用了错误的数据来回答你的问题。本教程中的一个例子是针对提示“口腔肿瘤的治疗方法”。检索到的文章之一是关于直肠癌治疗研究的总结，显然被送入LLM进行总结。我不是医生，但我很确定直肠不属于口腔。LLM准确地总结了研究及其对口腔和直肠癌不同治疗方案的影响，但并不总是提及癌症类型。因此，用户在询问口腔癌治疗方案后，可能会在不知情的情况下阅读LLM描述直肠癌的不同治疗方案。
知识图谱(KG)进行语义搜索和相似度搜索的能力很大程度上取决于元数据的质量以及其连接的受控词汇表。本教程中的示例数据集，所有期刊文章已经被标记了主题词。这些词属于一个丰富的受控词汇——美国国立卫生研究院的医学主题词表(MeSH)。正因如此，我们可以直接进行相对简单的语义搜索和相似度搜索。
直接将KG向量化并存储至向量数据库作为RAG的知识库可能有一定益处，但本教程并未这样做。我只是将表格格式的数据进行了向量化，并为每篇文章添加了一个URI列，以便将向量回连至KG。
使用KG进行语义搜索、相似度比较和RAG的一个最大优势在于可解释性。你可以始终解释为什么返回特定结果：它们被标记了某些概念或具有特定的元数据属性。
KG的另一个我没有预见到的好处是所谓的“增强数据丰富”或“图作为专家”——你可以利用KG来扩展或精炼搜索词。例如，你可以找到相似的术语、更具体的术语或以特定方式与你的搜索词相关的术语，以扩展或细化查询。比如，我可能从搜索“口腔癌”开始，但根据我的KG术语和关系，将搜索范围缩小到“牙龈肿瘤和腭肿瘤”。
开始使用KG的一个主要障碍是你需要构建一个KG。话虽如此，有很多方法可以使用LLM加速KG的构建（见上图1）。
仅使用KG的一个缺点是，你需要编写SPARQL查询来执行所有操作。这就是上述提示到查询检索之所以流行的原因。
使用Jaccard相似度在知识图谱中查找相似文章的结果不佳。如果不加限定，KG会返回那些标签重叠如“老年人”、“男性”和“人类”的文章，这些标签可能远不如“治疗方案”或“口腔肿瘤”相关。
我遇到的另一个问题是Jaccard相似度计算耗时极长（约30分钟）。我不知道是否有更好的方法来做这件事（欢迎建议），但猜测在一篇文章与其他9999篇文章之间寻找重叠标签可能本身就非常计算密集型。
由于本教程中使用的示例提示很简单，如“总结这些文章”——无论采用基于向量还是基于KG的检索方法，LLM响应的准确性更多地取决于检索而非生成。这意味着，只要你给LLM提供了相关上下文，它就极不可能在像“总结”这样简单的提示上出错。当然，如果我们的提示是更复杂的问题，情况就会大不相同。
最初使用向量数据库进行搜索，然后用KG进行过滤，提供了最佳结果。这不言自明——你过滤是为了得到更好的结果。关键在于，并不是KG本身必然改善了结果，而是KG为你提供了控制输出以优化结果的能力。
使用KG过滤结果可以根据提示提高准确性和相关性，也可以根据编写提示的人来定制结果。例如，我们可能想要使用相似度搜索来推荐相似文章给用户，但我们只想推荐他们有权限访问的文章。KG允许在查询时进行访问控制。
KG还可以帮助降低上下文污染的可能性。在上述RAG示例中，我们可以在向量数据库中搜索“口腔肿瘤的治疗方法”，但随后只筛选出标记有口腔肿瘤（或相关概念）的文章。
本教程中我只关注了一个简单实现，即将提示直接发送到向量数据库，然后用图进行结果过滤。还有更优的方法。例如，你可以从与你的受控词汇对齐的提示中提取实体，并利用图来丰富它们（包括同义词和更具体的术语）；你可以将提示解析为语义片段，分别发送到向量数据库；你可以在向量化之前将RDF数据转换为文本，以便语言模型更好地理解，等等。这些都是未来博客文章的主题。

步骤 1：基于向量的检索
下图从高层次展示了计划概要。我们的目标是将期刊文章的摘要和标题转化为向量形式，并存储在一个向量数据库中，以便执行不同的查询：语义搜索、相似性搜索，以及RAG的一个简化版本。对于语义搜索，我们将测试诸如“口腔肿瘤”这样的术语——向量数据库应当返回与该主题相关的文章。对于相似性搜索，我们将使用给定文章的ID在其向量空间中找到最近邻，即与该文章最相似的文章。最后，向量数据库还支持一种RAG（ Retrieval-Augmented Generation，检索增强生成）的形式，让我们可以在提示语句中加入如“请像解释给没有医学学位的人那样解释这个”这样的要求，并结合一篇文章来生成回答。

我决定使用来自PubMed数据库的这个包含50,000篇研究文章的数据集（许可CC0：公共领域）。该数据集包含了文章的标题、摘要以及元数据标签字段。这些标签来自于医学主题词表（MeSH）控制词汇表。为了本教程这一部分的目的，我们仅将使用摘要和标题。这是因为我们试图比较向量数据库与知识图谱，而向量数据库的优势在于其能够“理解”缺乏丰富元数据的非结构化数据。我只使用了数据的前10,000行，以加快计算速度。

from weaviate.util import generate_uuid5import weaviateimport jsonimport pandas as pd
#Read in the pubmed datadf = pd.read_csv("PubMed Multi Label Text Classification Dataset Processed.csv")

然后，我们可以建立与我们的Weaviate集群的连接：

client = weaviate.Client(url = "XXX",# Replace with your Weaviate endpointauth_client_secret=weaviate.auth.AuthApiKey(api_key="XXX"),# Replace with your Weaviate instance API keyadditional_headers = {"X-OpenAI-Api-Key": "XXX"# Replace with your inference API key})

在我们将数据矢量化到向量数据库之前，我们必须定义模式。在这里，我们定义要从csv文件中矢量化的列。如前所述，为了本教程的目的，作为开始，我只想对标题和摘要这两列进行矢量化。

class_obj = {# Class definition"class": "articles",
# Property definitions"properties": [{"name": "title","dataType": ["text"],},{"name": "abstractText","dataType": ["text"],},],
# Specify a vectorizer"vectorizer": "text2vec-openai",
# Module settings"moduleConfig": {"text2vec-openai": {"vectorizeClassName": True,"model": "ada","modelVersion": "002","type": "text"},"qna-openai": {"model": "gpt-3.5-turbo-instruct"},"generative-openai": {"model": "gpt-3.5-turbo"}},}

然后，我们将此架构推送到我们的

client.schema.create_class(class_obj)

你可以直接在你的Weaviate集群中检查以确认这一步操作成功。

既然我们已经建立了模式，接下来就可以将所有数据写入向量数据库中。

import loggingimport numpy as np
# Configure logginglogging.basicConfig(level=logging.INFO, format='%(asctime)s %(levelname)s %(message)s')
# Replace infinity values with NaN and then fill NaN valuesdf.replace([np.inf, -np.inf], np.nan, inplace=True)df.fillna('', inplace=True)
# Convert columns to string typedf['Title'] = df['Title'].astype(str)df['abstractText'] = df['abstractText'].astype(str)
# Log the data typeslogging.info(f"Title column type: {df['Title'].dtype}")logging.info(f"abstractText column type: {df['abstractText'].dtype}")
with client.batch(batch_size=10,# Specify batch sizenum_workers=2, # Parallelize the process) as batch:for index, row in df.iterrows():try:question_object = {"title": row.Title,"abstractText": row.abstractText,}batch.add_data_object(question_object,class_name="articles",uuid=generate_uuid5(question_object))except Exception as e:logging.error(f"Error processing row {index}: {e}")

为了检查数据是否已进入集群，您可以运行以下命令：

client.query.aggregate("articles").with_meta_count().do()

下篇文章将继续介绍文本召回的实现过程。