Agentic AI:构建长期记忆

发布于 2025-10-16 07:14
浏览
0收藏


Agentic AI:构建长期记忆-AI.x社区

如果你用过大型语言模型(LLMs),你就会知道它们是无状态的。如果没用过,可以把它们想象成没有短期记忆的东西。

举个例子,就像电影《记忆碎片》(Memento)里的主角,他总是需要靠便利贴上的信息来提醒自己发生了什么,拼凑出下一步该做什么。

要和LLMs对话,我们每次互动时都需要不断提醒它们之前的对话内容。

实现我们所说的“短期记忆”或状态其实很简单。我们只需要把之前的几组问答对抓出来,包含在每次调用里就行。

但长期记忆完全是另一回事。

为了让LLM能调取正确的事实、理解之前的对话并连接信息,我们需要构建一些相当复杂的系统。

Agentic AI:构建长期记忆-AI.x社区

这篇文章会深入探讨这个问题,而不是堆砌一堆术语,分析构建一个高效系统需要什么,讨论不同的架构选择,并看看有哪些开源和云服务供应商能帮上忙。

思考解决方案

让我们先来梳理一下为LLMs构建记忆的思路,以及要让它高效需要些什么。

首先,我们需要LLM能调取旧消息,告诉我们之前说了什么。比如,我们可以问它:“你之前推荐我去斯德哥尔摩的那家餐厅叫什么名字?”这就是基本的信息提取。

如果你完全没接触过LLM系统的开发,你可能首先会想到把所有对话直接塞进上下文窗口(context window),让LLM自己去理解。

但这种策略会让LLM很难分辨哪些信息重要、哪些不重要,可能会导致它“幻觉”(hallucinate)出答案。而且一旦对话量变大,你还得限制对话的长度。

你的第二个想法可能是存储每条消息,连同摘要一起,然后用语义搜索(比如RAG里的检索)在有查询时提取信息。

Agentic AI:构建长期记忆-AI.x社区

这跟构建标准的简单检索系统差不多。

但问题在于,如果只是简单地存储消息(不做任何额外处理),一旦规模扩大,你会遇到内存膨胀、事实过时或矛盾、以及不断需要清理的向量数据库(vector database)的问题。

你可能还需要知道事情发生的时间,这样才能问:“你什么时候跟我提过第一家餐厅?”这意味着你需要某种程度的时间推理(temporal reasoning)。

这可能会促使你加入带有时间戳的元数据(metadata),甚至实现一个自我编辑系统(self-editing system),来更新和总结输入内容。

虽然更复杂,但一个自我编辑系统可以在需要时更新事实并使其失效。

如果你继续深入思考,你可能还希望LLM能连接不同的事实(执行多跳推理,multi-hop reasoning)并识别模式。

比如,你可以问:“我今年去了多少场音乐会?”或者“根据这些,你觉得我的音乐品味怎么样?”这可能会让你尝试使用知识图谱(knowledge graphs)。

组织解决方案

这个问题变得如此复杂,促使人们更好地组织它。大多数团队似乎把长期记忆分成两部分:小型事实(pocket-sized facts)和之前的对话的长期记忆(long-span memory)。

Agentic AI:构建长期记忆-AI.x社区

对于第一部分,小型事实,我们可以看看ChatGPT的记忆系统作为一个例子。

要构建这种记忆,他们可能会用一个分类器(classifier)来判断一条消息是否包含需要存储的事实。

Agentic AI:构建长期记忆-AI.x社区

然后,他们会把事实分类到一个预定义的类别(比如个人资料、偏好或项目),如果这个事实和已有的事实类似就更新,否则就创建一个新的。

另一部分,长期记忆,意味着存储所有消息并总结整个对话,以便之后可以参考。这在ChatGPT里也有,但和小型事实记忆一样,你得手动启用。

如果你自己来构建这个,你需要决定保留多少细节,同时注意之前提到的内存膨胀和不断增长的数据库问题。

标准架构解决方案

如果我们看看其他人在做什么,这里有两个主要的架构选择:向量(vectors)和知识图谱(knowledge graphs)。

我一开始提到了一种基于检索的方法。这通常是大家开始时的首选。检索使用向量存储(vector store,通常还支持稀疏搜索,sparse search),这意味着它同时支持语义搜索和关键词搜索。

检索一开始很简单:你把文档嵌入(embed),然后根据用户的问题来提取。

但正如我们之前说的,如果只是简单地这样做,每个输入都是不可变的。这意味着即使事实变了,文本还是会留在那儿。

这里可能出现的问题包括提取到多个互相矛盾的事实,这会让代理(agent)困惑。最坏的情况是,相关事实可能被埋在一堆检索到的文本里。

代理也不知道某件事是什么时候说的,或者它指的是过去还是未来。

正如我们之前讨论的,有办法解决这些问题。

你可以搜索旧的记忆并更新它们,给元数据加上时间戳,定期总结对话来帮助LLM理解提取到的细节的上下文。

但用向量,你还会面临数据库不断增长的问题。最终,你得清理旧数据或压缩它们,这可能会让你丢掉有用的细节。

如果我们看看知识图谱(KGs),它们把信息表示成实体(节点,nodes)和它们之间的关系(边,edges)的网络,而不是像向量那样的非结构化文本。

Agentic AI:构建长期记忆-AI.x社区

KGs不会直接覆盖数据,而是可以给旧事实加一个“失效日期”(invalid_at date),这样你还能追溯它的历史。它们通过图遍历(graph traversals)来提取信息,让你可以跨多个跳跃追踪关系。

不过正如我们提到的,用向量也可以通过提取旧事实并更新来做到类似的事。

但因为KGs能跳跃到连接的节点并以更结构化的方式保持事实更新,它们在多跳推理(multi-hop reasoning)上往往表现更好。

不过KGs也有自己的挑战。随着规模扩大,基础设施会变得更复杂,你可能在深层遍历时注意到更高的延迟,因为系统需要找很远的信息。

维护成本也可能很高。

总之,不管是用向量还是KG为基础的解决方案,人们通常会选择更新记忆而不是不断添加新的,加入我们之前看到的“小型事实”的特定分类功能。

他们还经常用LLMs来在存储消息前总结和提取信息。

回到最初的目标(同时拥有小型记忆和长期记忆),你可以混合使用RAG和KG的方法来达到目的。

当前供应商解决方案(即插即用)

我会介绍几种不同的独立解决方案,帮助你设置记忆,分析它们的工作方式、使用的架构,以及它们的框架成熟度如何。

Agentic AI:构建长期记忆-AI.x社区

长期记忆供应商 —— 我总是把资源收集在这个仓库里 | 图片由作者提供

构建高级LLM应用还是很新的东西,所以这些解决方案大多在过去一两年才发布。

刚开始时,了解这些框架的构建方式会很有帮助,能让你知道自己可能需要什么。

正如之前提到的,它们大多分为KG优先或向量优先两类。

Agentic AI:构建长期记忆-AI.x社区

记忆供应商功能 —— 我总是把资源收集在这个仓库里 | 图片由作者提供

先看看Zep(或Graphiti),一个基于KG的解决方案,他们用LLMs来提取、添加、使失效和更新节点(实体)和边(带时间戳的关系)。

Agentic AI:构建长期记忆-AI.x社区

当你提问时,它会执行语义和关键词搜索来找到相关节点,然后遍历到连接的节点来提取相关事实。

如果有新消息带来矛盾的事实,它会更新节点,同时保留旧事实。

这和Mem0不同,Mem0是一个基于向量的解决方案,它会把提取的事实叠加起来,并用一个自我编辑系统来识别并完全覆盖无效事实。

Letta的工作方式类似,但还包括额外的功能,比如核心记忆(core memory),它会存储对话摘要以及定义需要填充内容的块(或类别)。

所有解决方案都能设置类别,我们可以定义系统需要捕获什么。比如,如果你建一个冥想应用,一个类别可以是用户的“当前心情”。这些就是我们之前在ChatGPT系统里看到的小型事实分类。

我之前提到过,向量优先的方法在时间推理和多跳推理上有问题。

比如,如果我说两个月后要搬到柏林,但之前提到住在斯德哥尔摩和加利福尼亚,几个月后我问系统时,它能明白我现在住在柏林吗?

它能识别模式吗?用知识图谱,信息已经结构化,LLM更容易利用所有可用上下文。

用向量,随着信息增长,噪声可能会变得太大,系统难以连接信息点。

Letta和Mem0虽然总体上更成熟,但这两个问题还是可能出现。

对于知识图谱,关注点在于规模扩大时的基础设施复杂性,以及如何管理越来越多的信息。

虽然我还没彻底测试所有方案,也还缺一些数据(比如延迟数字),但我想提一下它们在企业安全方面的处理,以防你想在公司内部使用。

Agentic AI:构建长期记忆-AI.x社区

记忆云安全 —— 我总是把资源收集在这个仓库里 | 图片由作者提供

我找到的唯一SOC 2 Type 2认证的云选项是Zep。不过,很多方案可以自托管,这种情况下安全性取决于你自己的基础设施。

这些解决方案还很新。你可能最终会自己构建,但建议先试试这些,看看它们如何处理边缘情况。

使用供应商的经济性

为LLM应用添加功能很棒,但你得记住这也会增加成本。

我总是会提到实施某项技术的经济性,这次也不例外。这是我在添加任何东西时首先会检查的。我需要知道这对应用的单位经济性(unit economics)会有什么长期影响。

大多数供应商解决方案会让你免费开始。但一旦消息量超过几千条,成本就会迅速增加。

Agentic AI:构建长期记忆-AI.x社区

“估算”每条消息的记忆定价 —— 我总是把资源收集在这个仓库里 | 图片由作者提供

记住,如果你的组织每天有几百次对话,通过这些云解决方案发送每条消息时,定价会开始累积。

一开始用云解决方案可能比较理想,然后随着规模扩大转到自托管。

你也可以尝试混合方式。

比如,自己实现一个分类器来决定哪些消息值得存为事实,以降低成本,同时把其他内容推到自己的向量存储里,定期压缩和总结。

话虽如此,在上下文窗口里使用小型事实应该比直接粘贴5000个token的历史记录要好。提前给LLM相关事实也有助于减少幻觉(hallucinations),总体上降低LLM生成成本。

注意事项

重要的是要注意,即使有了记忆系统,也别指望完美。这些系统有时还是会产生幻觉或漏掉答案。

与其追求100%的准确率,不如接受不完美,这样能省去很多挫败感。

目前没有哪个系统能达到完美准确,至少现在还没有。研究显示,幻觉是LLMs的固有问题。即使加了记忆层,也无法完全消除这个问题。

本文转载自AI大模型观察站,作者:AI研究生

已于2025-10-16 07:14:57修改
收藏
回复
举报
回复
相关推荐