微信扫码
添加专属顾问
探索未来知识图谱技术的新突破,无需向量数据库实现大语言模型的长期记忆。 核心内容: 1. RecallM:一种新型的适应记忆机制 2. 知识图谱构建与更新过程解析 3. 时间推理能力与局限性分析
在为大语言模型(LLM)提供长期记忆的过程中,主流方法通常涉及检索增强生成(RAG)方案,其中向量数据库充当长期记忆的存储机制。这引发了一个问题:我们能否在没有向量数据库的情况下实现相同的效果?
让我们来看看 RecallM: 一种具有时间理解能力的可适应记忆机制(https://arxiv.org/abs/2307.02738),该论文由 Brandon Kynoch、Hugo Latapie 和 Dwane van der Sluis 共同提出。论文提出了一种利用自动构建的知识图谱作为 LLM 长期记忆核心的方法。
本文将深入探讨 RecallM 的工作原理,重点介绍其知识图谱的更新方式及推理机制,并通过一系列示例进行说明。
我们将首先探讨知识图谱的更新机制,并通过两个具体示例来阐明该过程。接下来,我们将研究 RecallM 的推理机制,并通过示例展示它如何利用知识图谱生成回答。此外,我们还会讨论时间推理的示例,展示 RecallM 在理解和应用时间相关知识方面的能力。最后,我们将分析该方法的局限性,以全面评估其能力及未来改进方向。
假设我们想将以下句子添加到知识图谱中:
Brandon 喜欢咖啡
我们需要执行以下步骤:
概念通常是句子中的名词,它们可以与其他概念建立关系。
这些概念将成为知识图谱中的节点。
此外,为了避免重复,我们会将概念转换为小写,并使用词干提取(stemming)技术将其归一化。
所有这些操作可以使用 NLP 工具包 Stanza 来完成。
以下是 Stanza 对句子 "Brandon loves coffee" 进行标注的结果:
[
[
{
"id": 1,
"text": "Brandon",
"lemma": "Brandon",
"upos": "PROPN",
"xpos": "NNP",
"feats": "Number=Sing",
"head": 2,
"deprel": "nsubj",
"start_char": 0,
"end_char": 7,
"ner": "S-PERSON",
"multi_ner": [
"S-PERSON"
]
},
{
"id": 2,
"text": "loves",
"lemma": "love",
"upos": "VERB",
"xpos": "VBZ",
"feats": "Mood=Ind|Number=Sing|Person=3|Tense=Pres|VerbForm=Fin",
"head": 0,
"deprel": "root",
"start_char": 8,
"end_char": 13,
"ner": "O",
"multi_ner": [
"O"
]
},
{
"id": 3,
"text": "coffee",
"lemma": "coffee",
"upos": "NOUN",
"xpos": "NN",
"feats": "Number=Sing",
"head": 2,
"deprel": "obj",
"start_char": 14,
"end_char": 20,
"ner": "O",
"multi_ner": [
"O"
],
"misc": "SpaceAfter=No"
}
]
]在这个例子中,名词是 "Brandon" 和 "coffee"。
使用 Porter 词干提取器进行词干化,并转换为小写后,我们得到 "brandon" 和 "coffe"。
概念的邻居是与其存在关系的其他概念。我们可以使用依存句法分析(dependency parser)来确定概念之间的关系。然而,为了简化,我们可以仅根据概念在句子中的“距离”来确定它们的关系。
“距离”指的是概念在句子中出现的位置。因此,"brandon" 位于索引 0,而 "coffe" 位于索引 1。
以下代码片段可以帮助理解“距离”的概念:
# 默认距离设为 1
def fetch_neigbouring_concepts(concepts, distance=1):
concepts = sorted(concepts)
for i in range(len(concepts)):
concepts[i].related_concepts = []
for j in range(-distance, distance + 1, 1): # 如果当前概念的距离小于参数 distance
if 0 <= i + j < len(concepts): # 确保索引在范围内
if j == 0:
continue
if concepts[i].name < concepts[i + j].name: # 确保在 Neo4J 图数据库中仅创建一个连接
concepts[i].related_concepts.append(concepts[i + j])执行此步骤后,"brandon" 与 "coffe" 建立了关系,而 "coffe" 没有与 "brandon" 建立关系。
我们可以使用图数据库来存储概念及其关系。
在 Neo4J 中,最终的知识图谱如下所示:
红色节点表示概念,它们通过“RELATED”(白色箭头)关系相连。
蓝色节点是“全局时间步”(global timestep),在时间推理中起着重要作用。其值为 1,表示这是第一次更新知识图谱。
以下是创建该图的 Cypher 查询:
MERGE (c00:Concept {name: 'brandon'})
MERGE (c01:Concept {name: 'coffe'})
WITH c00, c01
MERGE (c00)-[rc00c01:RELATED]->(c01)
WITH c00, c01, rc00c01, COALESCE(rc00c01.strength, 0) + 1 AS rc00c01ic
SET c00.t_index = 1, c01.t_index = 1
SET rc00c01.strength = rc00c01ic
SET rc00c01.t_index = 1需要注意两点:
1. 节点和关系都有一个 t_index 属性,用于跟踪它们上次更新的时间步。
2. “RELATED” 关系有一个 strength 属性,用于跟踪该关系在知识图谱更新过程中被提及的次数。
概念的上下文是指它在句子中的使用情况。
因此,对于每个概念,我们首先从知识图谱中获取其上下文信息:
MATCH (n:Concept)
WHERE n.name IN ['brandon', 'coffe']
RETURN n.name, n.context, n.revision_count由于这是我们首次添加这些概念,查询结果将为空。
接下来,我们将当前上下文(即句子 "Brandon loves coffee")添加到概念节点,并更新知识图谱:
MATCH (n:Concept)
WHERE n.name IN ['brandon', 'coffe']
WITH n,
CASE n.name
WHEN 'brandon' THEN '. Brandon loves coffee'
WHEN 'coffe' THEN '. Brandon loves coffee'
ELSE n.context
END AS newContext,
CASE n.name
WHEN 'brandon' THEN 0
WHEN 'coffe' THEN 0
ELSE 0
END AS revisionCount
SET n.context = newContext
SET n.revision_count = revisionCount请注意,"brandon" 和 "coffe" 具有相同的上下文,因为它们出现在同一句话中,而我们目前仅处理这一句话。
最终的知识图谱如下所示:
现在,我们要将以下句子添加到知识图谱中:
Brandon 想去巴黎旅行
该句中的概念是 "Brandon" 和 "Paris"。
经过词干化和小写转换后,我们得到 "brandon" 和 "pari"。
将这些概念添加到知识图谱后,我们得到如下结构:
请注意:
• 全局时间步(global timestep)已更新为 2。
• 新概念 "pari" 已添加到知识图谱中。
• "brandon" 和 "pari" 通过 "RELATED" 关系相连。
• "brandon" 的 t_index 更新为 2,因为它在时间步 2 进行了更新。
以下是用于更新知识图谱的 Cypher 查询:
MERGE (c00:Concept {name: 'brandon'})
MERGE (c01:Concept {name: 'pari'})
WITH c00, c01
MERGE (c00)-[rc00c01:RELATED]->(c01)
WITH c00, c01, rc00c01, COALESCE(rc00c01.strength, 0) + 1 AS rc00c01ic
SET c00.t_index = 2, c01.t_index = 2
SET rc00c01.strength = rc00c01ic
SET rc00c01.t_index = 2首先,我们从知识图谱中获取概念的上下文信息:
{
"brandon": {
"context": ". Brandon loves coffee",
"revision_count": 0
},
"pari": {
"context": null,
"revision_count": null
}
}可以看到,"brandon" 已经有了上下文,而 "pari" 还没有。
然后,我们将新句子追加到已有的上下文中,并更新知识图谱:
MATCH (n:Concept)
WHERE n.name IN ['brandon', 'pari']
WITH n,
CASE n.name
WHEN 'brandon' THEN '. Brandon loves coffee. Brandon wants to travel to Paris'
WHEN 'pari' THEN '. Brandon wants to travel to Paris'
ELSE n.context
END AS newContext,
CASE n.name
WHEN 'brandon' THEN 1
WHEN 'pari' THEN 0
ELSE 0
END AS revisionCount
SET n.context = newContext
SET n.revision_count = revisionCount请注意,"brandon" 的上下文现在包含了之前的句子和新句子。此外,它的 revision_count 也更新为 1,因为它的上下文被更新了。
最终的知识图谱如下所示:
假设我们要回答以下问题:
谁想去巴黎旅行?
我们可以利用知识图谱来生成答案,具体步骤如下:
使用与更新知识图谱时相同的 NLP 处理流程,我们确定问题中唯一的概念是 "pari"。
我们在知识图谱中查找与 "pari" 相关的概念:
MATCH (startNode:Concept{name: 'pari'})
CALL apoc.path.spanningTree(startNode, {relationshipFilter: "", minLevel: 0, maxLevel: 2}) YIELD path
WITH path, nodes(path) as pathNodes, startNode.t_index as current_t
UNWIND range(0, size(pathNodes)-1) AS index
WITH path, pathNodes[index] as node, current_t
ORDER BY node.t_index DESC
WHERE node.t_index <= current_t AND node.t_index >= current_t - 15
WITH DISTINCT node LIMIT 800
MATCH ()-[relation]->()
RETURN node, relation该查询会找到从 "pari" 出发、深度最多为 2 的所有路径,并筛选出时间步范围在 current_t - 15 到 current_t 之间的概念。
查询结果如下:
{
"pari": ". Brandon wants to travel to Paris",
"brandon": ". Brandon loves coffee. Brandon wants to travel to Paris",
"coffe": ". Brandon loves coffee"
}我们根据 t_index(时间步)和概念之间的关系强度对相关概念进行排序。
以下代码片段用于计算排序分值 sort_val:
graph_concepts = graph_concept_nodes.values()
for concept in graph_concepts:
concept.sort_val = 0
for relation in concept.related_concepts:
concept.sort_val += (relation.t_index * 3) + relation.strength # 3 是一个超参数,可调整
graph_concepts = sorted(graph_concepts, key=lambda c: c.sort_val, reverse=True) # 按降序排列排序后,各个概念的 sort_val 如下:
我们首先获取问题中涉及的“核心概念”(essential concepts),即 "pari"。
其上下文为:
. Brandon wants to travel to Paris
然后,我们按照 sort_val 的降序依次添加相关概念的上下文:
. Brandon loves coffee # 相关概念:coffe
. Brandon loves coffee. Brandon wants to travel to Paris # 相关概念:brandon
. Brandon wants to travel to Paris # 核心概念:pari接下来,我们将构建的上下文作为提示词(prompt)传递给 LLM,并生成答案。
最终的提示词如下:
使用以下陈述(statements)来回答问题(question)。这些陈述按照时间顺序排列,每句陈述在其时间步内均为真实:
statements:
. Brandon loves coffee
. Brandon loves coffee. Brandon wants to travel to Paris
. Brandon wants to travel to Paris
question:
谁想去巴黎旅行?
Answer:由于提示词已经包含了足够的信息,GPT-3.5-Turbo 能够正确生成答案:"Brandon"。
论文作者设计了一项实验,以评估 RecallM 在时间理解和记忆更新方面的能力。
他们构建了一个包含按时间顺序排列的陈述的数据集,每个新陈述都会更新之前的事实。然后,他们在不同时间步对系统进行提问,以测试其时间推理能力。
实验包括两类问题:
1. 标准时间推理问题:测试系统对时间概念的理解,以及它是否能正确更新记忆。
2. 长距离时间推理问题:要求系统回忆数百个时间步之前的信息,并进行推理。例如,在 25 轮更新后,系统需要回忆 1500 多个更新之前的知识。
以下是论文提供的一些实验结果,展示了 RecallM 在时间推理方面的有效性,并与向量数据库进行了对比:
该方法的主要局限性在于知识图谱的构建,特别是缺乏指代消解(coreference resolution)。
例如,假设我们向系统输入以下文本:
Brandon 喜欢咖啡。他想去巴黎旅行。他喜欢猫。
理想情况下,知识图谱应如下所示:
但实际上,我们得到的是:
尽管如此,像以下问题:
• 谁想去巴黎旅行?
• 谁喜欢猫?
• 谁喜欢咖啡?
仍然能够得到正确答案,因为生成的上下文仍然包含 "Brandon loves coffee",这有助于 LLM 生成正确的回答。
但在某些情况下,可能会出现错误。
一种可能的解决方案是将文本转换为“命题”,然后将这些命题存入知识图谱,而不是直接存储原始文本。这一想法在论文 Dense X Retrieval: What Retrieval Granularity Should We Use?(https://arxiv.org/abs/2312.06648) 中有所探讨。
总的来说,RecallM 提出了一种仅使用图数据库就能为 LLM 提供长期记忆的方法。
该方法在知识更新和时间推理方面表现出色,但在构建精确知识图谱方面仍然存在挑战。
尽管如此,RecallM 代表了 AI 记忆机制的一项重要进展,未来的研究仍有很多改进和优化的空间。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-07-02
企业级知识图谱的实体架构治理实践
2026-07-02
一文讲清:“统一语义”、“构建本体”、“AI推理”这三者的关系
2026-07-02
graphify + claude 图谱关系
2026-07-01
把运维能力装进 Qoder,一句话就能定位根因
2026-07-01
Gbrain、GraphRAG、LLM Wiki、Graphify:4 种知识图谱方案怎么选
2026-07-01
一文讲清:本体(Ontology)与语义(Semantics)到底是什么关系?
2026-06-30
从 OOP 到本体:用形式语义支撑 AI 协作方法论
2026-06-29
从“领域描述”到“本体”——AI时代的系统设计模式探讨
2026-04-07
2026-04-19
2026-04-23
2026-04-22
2026-06-03
2026-04-23
2026-05-26
2026-05-07
2026-05-28
2026-05-23
欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。
在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。
一、 定义
本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。
会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。
知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。
二、 账号注册与登录
登录方式:本网站支持以下登录方式,您可根据实际情况选择:
微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。
手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。
账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。
实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。
未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。
三、 服务内容与规范
知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。
服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。
禁止行为:您在使用服务时不得实施以下行为:
利用技术手段批量爬取、下载、转存知识库内容;
将知识库内容用于商业目的或未经授权地向第三方传播;
干扰本网站正常运行或侵犯其他用户合法权益;
发布违法违规信息或从事违反公序良俗的活动。
四、 知识产权声明
权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。
有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。
侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。
五、 个人信息保护
我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。
您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。
您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。
六、 免责声明
内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。
不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。
第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。
七、 违约责任
如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。
如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。
八、 法律适用与争议解决
本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。
因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。
九、 其他
本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。
本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。
我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。