当前位置：首页 > news >正文

点创网站建设长春模板建站代理

news 2025/7/15 23:20:57

点创网站建设,长春模板建站代理,wordpress 支付可见,福清seo随着微软已经开源了GraphRAG项目的代码，基于图数据库的RAG 热度迅速升温。关注基于大语言模型与图模型数据库相结合的技术的人多了起来。本文提出了一种类似人工搜索的“顺藤摸瓜”方法，实现图数据库的智能搜索方法。本地私有数据存储和查询本地私有…

随着微软已经开源了GraphRAG项目的代码，基于图数据库的RAG 热度迅速升温。关注基于大语言模型与图模型数据库相结合的技术的人多了起来。

本文提出了一种类似人工搜索的“顺藤摸瓜”方法，实现图数据库的智能搜索方法。

本地私有数据存储和查询

本地私有数据的存储和查询主要包括：

历史对话（Hostory chat）

又称为长期记忆。通常就是将历史对话存储在内存或者数据库中，但是，这种方式不分青红皂白一股脑地存下来，造成了各种幻觉，例如问：我是谁？LLM 将这个问话也存储起来了，再次问我是谁？ LLM 则回答：我是谁。显然错了。

上传的文档（upload documents）

又称为RAG。

历史对话和RAG 不同，历史对话是零星输入的，相同的内容不会集中在一起，而RAG 是从上传的文本中提取信息，相同的内容是相对集中在一起的。我们曾经尝试将历史数据存储在一个TEXT 文本中，然后定期地通过embedding 存储到vector 数据库中，效果并不会，例如 X 的儿子是Y，Y 的儿子是Z ，有时候LLM 会回答X 的儿子是Z。对应关系复杂的内容，RAG 的效果并不好。如果询问 X 的孙子是谁？LLM 也经常回答错误。

基于图数据库的RAG 方法的基本过程

将内容分成块（ chunks.）
将块存储到图数据库中，并且连接到文档节点
高度相似的块通过SIMILAR 关系连接成为邻近节点。
通过Embeddings生成矢量索引（vector index）
使用lm-graph-transformer 或者 diffbot-graph-transformer,提取块的主体和关系
将主体存储到图中，并且连接到原始的块

查询的结果是通过实体查询到 chunks节点。进一步通过SIMILAR 关系查询相似的chunks节点。

本文重点讨论如何使用图数据库实现长期记忆。

历史对话存储的方法

历史对话使用memory 模块来实现，最简单的是将所有的对话都存储在内存（短期记忆），或者存储在数据库中（长期记忆）。

图数据库适合存储复杂关系的信息，例如对话者的家庭关系。个人简历。

普通数据库适合存储对话者的活动，备忘录等信息。

LLM 与图数据库结合

LLM 与图数据库结合关键在两点

利用大模型将非结构化数据转换成为图数据库的结构化数据
利用大模型智能搜索图模型中的相关数据

数据存入图数据库

首先通过LLM判断陈述语句中的实体和关系。并且输出json 格式

{
startNodeName:"姚家湾"
relationship:"儿子“
endNodeName:"姚大为"
}

通过图数据库的语句将实体和关系存储到图数据库中。

下图是根据对话存储的个人信息。

数据查询

通过LLM 实现图数据库看起来是十分简单的事情，许多的大模型能够直接产生图模型的查询语句。事实上并没有想象的简单，首先是LLM 提取实体和关系的名称是不确定的。有时候存储和查询对话产生的实体和关系的类型不能够对应。对于复杂的提问，LLM 也无法生成完整的查询语句。这就需要LLM具有智能（或者说是模糊的）查询的图数据库的能力。

网络上有一些关于图模型查询的介绍，

比如找出与实体连接的的一部分节点，搜索N跳以内的局部子图比如4层。

另一种方法是利用vector 数据库构建图数据库中所有节点，关系的vector 通过vector数据库查询相关的节点内容，这似乎失去了图模型的意义。

这些方法基本上是简单粗暴法。

我们尝试模仿人类查询的方式，根据实体的属性和所有的关系顺藤摸瓜地检索图数据库的信息。姑且称之为“顺藤摸瓜法”。

顺藤摸瓜法

所谓顺藤摸瓜法就是模仿人工搜索图的方法，通过LLM 来逐步确定图数据库的搜索路径。

提取询问中的实体（Entity），实体对应于图数据库中的节点名称。
在图数据的查询实体节点的所有属性，与该节点连接的相邻节点，以及所有的关系集（relationships）。
将读出的信息添加到对话的上下文信息（Context Information）中。
LLM 尝试回答问题，如果已经得到了答案，就直接输出答案，如果没有获得答案，就推荐下一步查询的子节点重复（2），如果无法进一步推荐合适的子节点就退出。

这个过程类似迷宫站在一个节点上，看哪个方向的节点更接近目标，然后选择一个或者几个方向尝试。每前进一步，都需要思考。

下图是一个例子。

询问：

姚远的岳父是谁？

大模型首先提取出询问中的实体-“姚远”，然后通过neo2J 数据库查询出“姚远”节点，已经临近节点，这是并不能回答“姚远的岳父是谁”，但是他会回答“通过查询”刘素霞节点进一步查询。

通过第二次查询“刘素霞节点以及它相邻的节点，能够读取 ”刘亚敏“节点。

终于，LLM 回答：

姚远的岳父是刘雅敏。

一些例子：

实验

基于NodeJS 平台
基于neo4J 图数据库
基于零一万物大模型yi-large

实现该技术的难点

设计LLM 的提示信息十分重要。编写提示类似于辅导中学生做应用题，不断地提示大模型如何正确的思考。

判断实体的提示

const Prefix = "请列出下列语句中的实体，实体的属性以及实体之间的关系 。"const Suffix = `请使用下列json 格式输出:{entities:[{name:name of entity,attributes:{name of attribute:Value of attribute}}],relashichips:[{source:source_node_name,target:target_node_name,type:relationship_type}]}json格式中的名称使用英文表示。关系使用中文表达。`const Prompt = Prefix + Message + Suffix

判断下一个实体的提示

const Prefix = "根据提供的信息(来自于neo4j 图数据库,包括关系和节点的属性)，回答下列问题：\n"const Suffix =`提示:如果你已经有了答案，请简单地以字符串给出答案。否则，请提示通过哪个节点能够进一步查询到相关信息(JSON 格式)。JSON 格式为：{entities:[{name:name of entity]}json格式中的名称使用英文表示`const Prompt = Prefix + Message + ContextMessage+Suffix

使用迭代函数实现

路径搜索程序使用迭代函数实现会使程序十分简洁。

代码（PathSeach）

async function PathSerch(entities,Message) {console.log("PathSerch....")for (let i = 0; i < entities.length; i++) {const Result= await graphDB.ReadNode(entities[i].name)ContextMessage=ContextMessage+JSON.stringify(Result)}//const Prefix = "根据提供的信息(来自于neo4j 图数据库,包括关系和节点的属性)，回答下列问题：\n"const Suffix =`提示:如果你已经有了答案，请简单地以字符串给出答案。否则，请提示通过哪个节点能够进一步查询到相关信息(JSON 格式)。JSON 格式为：{entities:[{name:name of entity]}json格式中的名称使用英文表示`const Prompt = Prefix + Message + ContextMessage+Suffixconsole.log(Prompt)const completion = await openai.chat.completions.create({messages: [{"role": "user","content": Prompt,}],model: "yi-large",});const Content = completion.choices[0].message.contentconsole.log(Content)let p= Content.indexOf("```json\n")console.log("p="+p)if (p>0){let ContentB=Content.replace("```json\n", "")let e= ContentB.indexOf("```")const JSonContent =ContentB.substr(p,e-p)//console.log("JSonContent:"+JSonContent)const entities = JSON.parse(JSonContent).entitiesconsole.log("entities:"+entities)const Result=await PathSerch(entities,Message)return Result} else return Content
}