AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


使用Streamlit、LangChain、Neo4j和GPT-4o构建GraphRAG实战讲解及开源实现
发布日期:2024-07-21 10:30:41 浏览次数: 2684


面使用Streamlit、LangChain、Neo4j和GPT-4o构建GraphRAG

非结构化数据到可查询图谱

今天我要通过使用Neo4j、LangChain和Streamlit的GraphRAG示例来创建一个可以与您的转换为知识图谱的文档进行交谈的Chatbot。GraphRAG是由微软研究团队于2024年2月提出的重磅-微软发表GraphRAG论文并即将开源项目。他们最近基于这项工作发布了一个实现重磅 - 微软官宣正式在GitHub开源GraphRAG,您也应该去了解一下。

本文编译自

Build GraphRAG Using Streamlit, LangChain, Neo4j & GPT-4o - The Bright Journey with AI (brightjourneyai.com)

https://brightjourneyai.com/build-graphrag-using-streamlit-langchain-neo4j-gpt-4o/

开源代码在github

https://github.com/BrightJourneyAI/graph-rag

使用知识图谱的RAG

我们已经知道,RAG旨在帮助LLMs消化超出其原始训练数据的新知识。这使得更近期或以前被遮蔽的信息能够被纳入传递给用户的回答中。这也有助于减少幻觉,暂且称其为基本RAG。尽管这能够提供更好的结果,并具有其自身的优化,但它面临的一个挑战在于连接通过模糊关系分隔的不同知识的能力。

我们知道,信息通常是松散相关的,而上下文并非总是干净地相互关联的。知识图谱在代表和查询这些复杂关系方面表现出色。术语“多跳”用于描述这个概念,即答案可能跨越多个关系边缘。通过基本RAG实现,衍生的知识往往仅限于输入的内容。例如,在我们之前比较Garmin跑步手表的例子中,除非在新数据中明确说明了这一事实,否则它无法理解专业跑步者更青睐更先进的训练手表。

这就是知识图谱和RAG可以合作的地方。通过利用知识图谱在关系中映射和查询多跳的能力,我们可以构建更复杂和丰富的答案。它通过使用从新源文档中检索到的结构化和非结构化数据,提供与用户查询相关的更丰富的数据点。以前面的例子为例,它不仅可以返回专业跑步者更青睐更先进的训练手表这一事实,还可以返回这些手表到底是什么以及它们共享哪些独特特点。这正是RAG的真正力量发挥的地方。

工作原理

我们将在接下来的几节中讨论细节和代码,但我只想花一点时间概述GraphRAG实现背后的高级架构。采取的方法是创建既有向量化相似度搜索又有图查询的混合体,以返回结构化和非结构化数据。通过这种方式,我们可以利用从查询图和其关系中获取的上下文来增强基本RAG的益处。

下面是该过程的简单轮廓,分为两个阶段:

  • RAG数据存储 - 该组件负责建立用于在用户提出问题时检索背景的数据存储。与基本的RAG一样,我们将文档划分成块,使其与LLMs上下文窗口兼容。每个块都转换为一个图形文档,图形从每个连续文档中逐步构建。

      • 混合检索 - 由于此解决方案既使用图查询又使用向量相似度搜索,我们利用构建的图形存储原始文档块,并从中构建向量索引。

  • 检索器 - 在这里,我们接受用户问题提取问题中的实体,然后使用这些实体进行向量搜索和构建图查询。最终数据与原始问题一起发送到LLM,LLM返回一个上下文感知答案。

Components组件

  • LangChain - LangChain是一个开源框架,简化了构建、部署和管理大型语言模型(LLMs)的过程。它提供了强大的基础设施和丰富的集成和函数库,帮助快速原型设计和开发基于LLM的应用程序。

  • Neo4j - Neo4j是一个高性能的图形数据库管理系统。它利用Cypher查询语言进行高效的查询和操作,使其成为需要复杂数据关系的应用程序的理想选择,比如推荐引擎、欺诈检测、社交网络和IT基础设施管理。

  • GPT-4o - GPT-4o是OpenAI在撰写时发布的最新模型。借助令人印象深刻的训练数据集,并在连续模型的基础上构建,GPT-4o被视为其他模型试图匹敌的基准。对于这个应用程序,我们将使用LangChain内置的集成与我们的模型进行交互。您将需要提供自己的API密钥。

  • Streamlit - Streamlit是一个开源框架,使开发人员能够轻松创建和共享美观的自定义网络应用程序,用于机器学习和数据科学项目。通过使用简单的Python脚本,Streamlit允许用户构建交互式和视觉上吸引人的应用程序,而无需深入了解Web开发。

  • youtube-transcript-api - Python库,用于检索YouTube视频的剧本或字幕,包括自动生成的字幕。它支持多种语言和字幕翻译,无需使用无头浏览器。API可通过编程或命令行界面使用,提供批量提取、格式选项和代理支持等功能。

  • LLMGraphTransformer - 注:仍然是实验性功能。LangChain中的LLMGraphTransformer是一个工具,使用大型语言模型(LLM)将文档转换为基于图形的格式。它允许用户指定节点和关系类型,根据需要应用约束和筛选。转换器可以异步处理文档,并支持根据提供的模式和约束生成结构化输出,使其成为将文本数据转换为结构化图数据用于各种应用程序的理想选择。

示例案例–Garmin手表推荐

尽管我已经购买了我的新Garmin Forerunner 255,但我将继续以它作为我们示例的基础。由于拥有众多的变体、功能和价格档次,它提供了一个很好的工作基础示例。作为我最终要表达的一个小概要,它也是一个具有专业知识的代理人的良好基础,可以用一个小图表来代表—请留意。

我认为这已经足够了—让我们开始编写一些代码

应用概述

我们正在使用的示例应用程序有四个主要组件:

  1. 本地使用Docker托管的Neo4j

  2. 一种图形构建工具,可以提取非结构化文本并使用人工智能将其转换为知识图

  3. 从图中提取结构化和非结构化文本的混合检索器

  4. 一个Streamlit用户界面,允许用户与其图形化知识文档进行对话

使用 Docker 配置 Neo4j 环境

首先,我设置了一个本地运行的 Neo4j 实例,为了简单起见,使用了 Docker。首先要做的是下载 APOC JAR 并将其放入 $PWD/plugins 目录。这基本上可以放在任何你喜欢的地方,只需确保以下 Docker 命令知道你放置了 JAR 的位置。APOC 是 Neo4j 的一个附属库,包含有助于其操作的有用功能。这在这个示例中是必需的。

确保您已经安装了 Docker Desktop 并执行以下命令。

1

2

3

4

5

6

7

8

9

10

docker run `

    -p 7474:7474 -p 7687:7687 `

    -v ${PWD}/data:/data -v ${PWD}/plugins:/plugins `

    --name neo4j-v5-apoc `

    -e NEO4J_apoc_export_file_enabled=true `

    -e NEO4J_apoc_import_file_enabled=true `

    -e NEO4J_apoc_import_file_use_neo4j_config=true `

    -e NEO4J_PLUGINS='["apoc"]' `

    -e NEO4J_dbms_security_procedures_unrestricted="apoc.*" `

    neo4j:5.20.0


上述内容格式适用于 Powershell 环境,请根据您的系统/终端进行相应调整。

从非结构化数据构建图谱

为了演示合并多种来源类型,我创建了三个文档提取器。其中一个用于 YouTube,一个用于维基百科,另一个用于纯文本。

1

2

3

4

5

6

7

8

9

10

11

12

def extract_youtube_transcript(self, url) -List:

        """

        Uses the Langchain interface to extract YouTube transcript from

        the specified URL. Under the hood this uses youtube-transcript-api

 

        Args:

            url (str): URL of the YouTube video to fetch transcript for

 

        Returns:

            List: Extracted transcript documents

        """

        return YoutubeLoader.from_youtube_url(url).load()

1

2

3

4

5

6

7

8

9

10

def extract_wikipedia_content(self, search_query):

        """

        Uses the search query and LangChain interface to extract

        content from the results of a Wikipedia search

 

        Args:

            search_query (str): The query to search for Wikipedia content on

        """

        raw_docs = WikipediaLoader(query=search_query).load()

        self.chunk_and_graph(raw_docs)

1

2

3

4

5

6

7

8

9

10

11

def graph_text_content(self, path):

        """

        Provided with a text document, will extract and chunk the text

        before generating a graph

 

        Args:

            path (str): Text document path

        """

        text_docs = TextLoader(path).load()

        print(text_docs)

        self.chunk_and_graph(text_docs)

提取内容后,现在您需要对文本进行分块。有许多正在出现的策略可用于有效地为RAG实现拆分文档,在这种情况下,我坚持使用了一个简单的TokenTextSplitter。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

def chunk_document_text(self, raw_docs):

        """

        Accepts raw text context extracted from source and applies a chunking

        algorithm to it.

 

        Args:

            raw_docs (str): The raw content extracted from the source

 

        Returns:

            List: List of document chunks

        """

        text_splitter = TokenTextSplitter(chunk_size=512, chunk_overlap=24)

        docs = text_splitter.split_documents(raw_docs[:3])

        return docs

对于每个块,我们开始将其转换为图文档的过程,并将其持久保存到底层的Neo4j实例。这就是我利用LLMGraphTransformer将纯文本块转换为图节点和边的地方。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

1

def graph_document_text(self, text_chunks):

        """

        Uses experimental LLMGraphTransformer to convert unstructured text into a knowledge graph

 

        Args:

            text_chunks (List): List of document chunks

        """

        llm_transformer = LLMGraphTransformer(llm=self.llm)

 

        graph_docs = llm_transformer.convert_to_graph_documents(text_chunks)

        self.graph.add_graph_documents(

            graph_docs,

            baseEntityLabel=True,

            include_source=True

        )

这个过程会一直重复,直到所有来源文档中的所有块都被处理完。值得注意的一个有趣的点是**include_source=True**。这将在图中显示来源文档。这对后面的非结构化语义搜索步骤很有用。

最后,我在整个图中创建一个索引,以帮助进行高效的搜索。这一步必须在向图中添加所有新内容之后完成。

图检索器

图检索器是通过多个步骤构建的。以下是每个步骤的解释和代码。

首先要做的是提取用户问题中存在的实体。由于图是通过在边上将节点映射到彼此来运行的,按预期实体搜索是一种常见策略。用户的问题可能提到多个实体,可以像这样提取。注意:我们返回一个可运行的链以便稍后将此步骤与其他步骤链接起来。

接下来我将构建结构化数据检索器,它将生成一个图查询,以提取我们上面提取的实体的相关节点和关系。

这里发生的是,被识别的实体与图形查询合并,以便我们可以返回与这些实体相关的邻居和关系。这产生了一个非常精确的数据语料库,可用于回答用户的查询。

接下来,我将创建混合检索器的非结构化部分。记得我们在图中包含源文档的地方吗?现在我们可以利用这一点,直接从图中创建一个向量索引。

最后一步是将检索的两种方法合并在一起,并构建我们将发送给LLM的组合查询。组合查询将包括用户的混合检索器上下文和原始问题。


在构建混合GraphRAG实现方面,这就是它。要再进一步,我们应该真正添加一个可以以对话方式与图形交互的接口。

创建UI

由于Streamlit使得快速构建原型变得如此容易,让我们继续前进并做到这一点。用户界面分为两个部分:

  • 侧边栏 - 包含用于管理图形的控件 - 目前将从代码中包含的预填充 URL 读取

  • 主窗口 - 这是主要的聊天界面 - 用户可以提出问题,将模型的潜在知识与您提供的特定基于图形的知识相结合



Conclusion总结

让我们回顾一下:我们面临的主要问题是数据通常不是线性相关的,可能包含超越单个“跳跃”的有价值信息。解决这个“多跳”问题正是知识图谱的必要之处。它们提供了信息相互关联的更现实的表示,使我们能够相对容易地查询这种复杂性。手动构建这些图谱可能具有挑战性,但随着LLMs的出现,我们现在有能力有效地自动化这个过程。

通过开发混合检索器,我们可以有效地匹配和理解与用户查询相关的实体。这使我们能够提取相关节点和边,从而产生更丰富、更有见地的响应,捕捉到通常被基本RAG实现忽视的知识。完整的代码可在Github上找到。https://github.com/BrightJourneyAI/graph-rag


53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询