这个标题通俗易懂,并且符合中文的口语表达习惯。它清楚地表达了文章的主题是介绍Neo4j实验室新发布的LLM知识图谱构建器及其功能,同时指出了发布的时间节点,即2025年的首个版本。
新功能包括社区概要、并行检索工具以及扩展的模型支持,以便更好地从文本中构建知识图谱许多开发人员尝试仅通过向量搜索从非结构化数据中构建检索增强生成(RAG)体验,却发现难以达到预期结果。仅查看无上下文的文本片段只能帮助他们达到一定限度。在数据工程中,更高级的方法可用于处理数据和提取知识,其中一个方法是GraphRAG。因此,当您开始使用数据时,已经揭示了底层概念,可以通过这些概念连接各个部分,并为用户的提问提供相关背景。
基于专家建议,翻译如下:#
基于源文本的简洁性,翻译应保持简洁,使用更口语化表达为 "# 介绍"。我们构建、开源并托管了LLM 知识图谱构建器,让您尝试更好的方法来处理未结构化的数据。我们预处理文档、对话记录、网络文章等各种来源,将其分割成小块,计算文本嵌入向量,并将它们连接成词汇图。
但我们不会就此停止。我们还会提取实体及其之间的关系,这在面对多个文件时特别有用,因为你可以将分布在不同来源的信息片段关联起来(也称为实体关系图)。
这个综合知识图谱从而使得不同类型的检索器能够提取数据(见下文)。
自2024年6月我们推出LLM知识图谱构建器以来,我们收到了大量的使用反馈,并且用户好评如潮。现在它已成为AuraDB Free上第四受欢迎的用户互动来源,这让我们非常高兴。
我们在2024年秋天发布了一个版本,但那时有很多AI相关的活动,这占用了我写博客的大部分时间。过去几个月里,团队一直在开发一些很不错的功能——其中一些我们打算在2025年的首个版本中介绍给大家。
LLM知识图谱构建器是用来做什么的?注:LLM是指…(此处需根据具体背景定义LLM)
如果你还不知道这个工具是用来做什么的,我给你快速介绍一下。
如果你有多个文本文件、网文、维基页面或其他类似未结构化的信息,难道不希望把其中隐藏的知识以结构化的方式呈现出来,并利用这些实体及其关系来更好地与数据交流吗?
大规模语言模型 (LLM) 知识图谱构建工具:
- 导入您的文档
- 将它们分割成块并链接它们
- 生成用于向量搜索的文本嵌入,并将最相似的文本连接起来
- 使用各种大型语言模型(LLM)提取实体和它们之间的关系
- 您也可以使用您提供的图模式
- 将节点和关系存储在Neo4j中
- 当在支持图数据科学的Neo4j实例上运行时,还会进行主题聚类和摘要
快速了解一下流程并去试试https://llm-graph-builder.neo4jlabs.com。
唯一的要求是有这样一个公开可访问的 Neo4j 实例来存储您的数据。您可以在 AuraDB Free 上创建,也可以在包含 Graph Data Science 的 Aura Pro Trial 上创建。
幕后博客系列在接下来的几周里,我们将陆续发布一系列博客文章(https://medium.com/neo4j/tagged/knowledge-graph),探讨LLM知识图构建器的各个方面,并解释它们的内部工作原理,这样你可以从我们的经验中获益,并应用到自己的GenAI项目中。
新特性让我们来看看新的特性。主要的有生成社区概要,简称为“生成社区摘要”,以及为此设计的新本地及全球检索器,以及可以为你的问题并行运行多个检索器来处理并评估这些检索器的新功能。你还可以通过自定义提示来指导提取过程。
另外,我们还有一些用户体验方面的改进想跟大家分享一下。
多些模型在开发模式或自部署的过程中,我们测试并配置了大型语言模型知识图谱构建器,用于多种新模型。我们在生产版本中也提到了这些新模型。
- OpenAI GPT-4o(和 GPT-4o mini)
- Google Gemini 1.5 和 2.0 Pro 及 Flash
- Qwen 2.5 模型
- Amazon Nova 模型
- Groq
- Llama 3.x
- Ollama
- Claude 3.5 Sonnet
- DeepSeek 和 Microsoft Phi-4,即将上线
为了进行内部集成测试(integration testing)并检验它们在提取过程中的表现。
不同LLM提取的测试结果如下,包含实体数量和运行耗时
社区小结你可以通过运行图算法来挖掘隐藏在文档图中的信息,从而提高其丰富度。
去年,微软发表了一篇名为“从本地到全球——基于查询的摘要图RAG”的论文(From local to global — Query Focused Summarization GraphRAG)。他们使用了一种层次图聚类算法(Leiden)来处理从实体域图中提取的数据。该算法识别出紧密相关的实体簇。然后,一个大型语言模型(LLM)将这些实体的内容总结成摘要节点,这些节点代表社区。由于结果具有层次性,例如,可以在多个层次上进行总结,从非常细粒度到最高层次。
更详细的评估博客将在本系列的后面几篇中发布。
提取出来的社区会在你的文档的图形可视化中可见,因此你可以检查它们及其内容,并了解它们总结了哪些对象。
实体表示与社区汇总的图表可视化
那些社区摘要随后会被用于一个全球检索器,来回答关于文档的一般性问题,这些问题并不是针对任何单一实体,而是识别跨文档的主题。因此,这些摘要代表的是跨越多个文档的主题,而不是单个文档的内容序列。
使用图算法对跨文档的主题进行分类
在大型语言模型的知识图构建器中,我们使用了相同的集群算法(莱登算法),那么当你连接到一个支持图数据科学的Neo4j实例(AuraPro带GDS、AuraDS、Neo4j沙箱或自托管——我们在应用顶部将其标记为 ⚛ 图标),并在图增强的后处理部分启用社区总结功能时,我们可以运行该算法并生成摘要树。
后期处理任务
在我们的全球社区检索工具中,我们采取了与论文稍有不同的方法。我们不是简单地将所有社区摘要塞进几个大语言模型提示中来回答问题,而是生成社区摘要的向量嵌入,并使用相似度和全文搜索来找到与问题最相关的摘要,这类似于微软研究院最近提出的方法,然后用这些相关摘要来回答问题。
现在可以同时运行多个检索工具,你自己就能看出差别。比较一下全局和局部实体检索工具的比较。
全球社区检索工具
两者(检索器)和其他一样,可以展示用于生成答案的检索到的上下文图谱数据(社群、实体、片段),支持解释性。
全球社群检索工具的搜索详情
基于本地的实体检索器这个本地实体检索器将微软论文中用几千行Python代码实现的功能简化为大约50行的Cypher代码(使用真正图形数据库的好处之一),如下所示获取的内容:
- 具有嵌入式和全文搜索功能的实体
- 它们之间的关系
- 实体与初始集合之外其他实体之间最常见的关系
- 从哪些片段和文档中抽取出这些实体
- 实体所属的社区总结
// 先在实体上进行混合搜索,然后扩展图
WITH collect(node) AS nodes
WITH avg(score) AS score
WITH collect({id: elementId(node), score: score}) AS metadata
RETURN score, nodes, metadata,
collect {
UNWIND nodes AS n
MATCH (n)<-[:HAS_ENTITY]->(c:Chunk)
WITH c, count(distinct n) AS freq
RETURN c
ORDER BY freq DESC
LIMIT 3
} AS chunks,
collect {
UNWIND nodes AS n
OPTIONAL MATCH (n)-[:IN_COMMUNITY]->(c:__Community__)
WITH c, c.community_rank AS rank, c.weight AS weight
RETURN c
ORDER BY rank, weight DESC
LIMIT 3
} AS communities,
collect {
UNWIND nodes AS n
UNWIND nodes AS m
MATCH (n)-[r]->(m)
RETURN DISTINCT r
} AS rels,
collect {
UNWIND nodes AS n
MATCH path = (n)-[r]-(m:__Entity__)
WHERE NOT m IN nodes
WITH m, collect(distinct r) AS rels, count(*) AS freq
ORDER BY freq DESC
LIMIT 10
WITH collect(m) AS outsideNodes, apoc.coll.flatten(collect(rels)) AS rels
RETURN { nodes: outsideNodes, rels: rels }
} AS outside
本地实体查找工具
对于这个实体抽取器来说,我们不仅可以展示文本片段,还可以展示实体以及它们之间的关系。
本地实体检索结果
在本地实体检索器中使用的社区概要
多个检索器正如前面提到的,现在你可以并行运行一个或多个检索器来生成问题的答案,并直接切换以进行比较。
在每个答案后的详情链接中,检索器还提供了如下信息:从数据库检索的上下文事实,这些事实随后将被发送给大型语言模型,还包括有关模型、运行时间和令牌计数的额外信息。
在开发模式下或自托管时,你甚至可以使用更多检索器供您测试和比较。
为了方便起见,窄右侧对话栏可以被最大化,甚至可以弹出为一个独立窗口,还可以共享。这对于只读数据库连接配置尤其有用,我们现在也支持共享你生成的知识图。
你可以将对话数据下载成一个 JSON 文件,然后你可以根据自己的需求对它进行处理。
检索测试其中一个原因是增加生成评估指标的能力。
我们正在使用RAGAs框架来进行评估,目前,我们计算了以下这些指标,其中一些指标需要您提供准确的参考值。
- 相关性 — 回答多好地解决了用户的问题。
- 忠实度 — 回答多准确地反映了所提供的信息。
- 上下文相关性 — 生成的回答中提到的实体在检索到的上下文中有多好地被回忆起来。
- 语义相关性 — 理解参考答案的含义有多好地体现在生成的回答中。
- ROUGE — 与标准答案逐词相似度的衡量。
检索评估
稍后我们会更深入地讨论评估,届时会有一篇详细的博客文章。
提取指引:在最新版本里,我们增加了通过让用户提供额外提示来更精确地引导提取的功能。因此,你可以让它只关注文档的特定部分,或者特定主题,或者使用比如说特定的额外指令。
提供更多的提取指导
我通过从几篇关于阿尔伯特·爱因斯坦的文章中提取实体和关系来进行测试,但指示LLM不要提取任何与他的物理研究相关的内容。结果是——生活、人物、奖项、和平活动和其他成就,但几乎没有提及他在物理学领域的巨大贡献。
用户体验提升以下是快速改进的列表:
- 允许只读数据库访问,这样就只能进行读取操作了
- 将聊天体验弹出到一个单独的窗口
- 通过本地搜索和高亮功能改进图表的可视化效果
一个实验性功能是自动图合并,这个功能旨在为那些只需要快速查看从数据提取的知识图但不想事先定义图形模式的用户服务。
在这种情况下,LLM 通常会生成大量的实体类型和关系数据——数量可能达到数千个,如果你不限制它。我们的检索器并不介意,因为它们使用的是图的拓扑结构而非具体类型来遍历图结构(虽然它们会将这些信息与文本信息一并收集)。
这就是为什么我们建议在一开始就提供一个图模式,以构建一个语义约束更强的知识图谱。但在未能做到这一点的情况下,我们可以使用一个大型语言模型来将节点标签和关系类型分类到一个较小、更通用的集合中。由于我们对这种简化并不完全满意,因此我们没有默认开启它,非常希望得到你们的反馈。您可以在图增强的后处理作业中找到它。
简述开发这样一个开源工具是一段很有成就感的经历——特别是我们到现在为止收到了这么多的反馈,这真的很有帮助。我们已经解决了超过400个GitHub上的问题,包括我们内部计划的任务,并且还获得了超过2800颗GitHub星。
如果还没有试过的话,请尝试一下,并在评论中分享你的想法。我们也很期待你能分享一下你使用该工具处理不同领域文档的经验。
如果有任何疑问或反馈,请随时与我们分享;如果喜欢这个项目,请在Github给我们点个星标。
建得开心!