向量存储与“活”记忆
摘要
文章澄清了经典 RAG(无状态)与智能体记忆(有状态)之间的区别,并介绍了两种新兴方法:Mem0 采用三层记忆和自动编辑,Letta 采用类操作系统的记忆(核心/归档)。文章强调,真正的挑战是更新和遗忘的逻辑,而不是向量存储。
我看到仍然有很多帖子/文章把“RAG”和“agent memory”放在同一个篮子里,我认为这值得澄清,因为它们是两个不同的问题。经典 RAG 很简单:你把文档切块(chunk),做嵌入(embed),然后找出与查询语义最接近的段落。这对于静态文档来说效果非常好,但它本质上是无状态的(stateless)——它对你一无所知,也不知道 3 次会话之前发生了什么。智能体记忆(agent memory)是一个不同的问题:需要存储随交互而演变的上下文(偏好、学到的事实、纠正),尤其是要管理更新、可追溯性(provenance)和遗忘——而一个简单的向量存储原生地做不到这三件事中的任何一件。我们看到有两种解决方式正在涌现:Mem0:三层记忆(用户/会话/智能体),当两个事实相互矛盾时,系统会自动编辑,而不是堆积重复内容。其理念是让记忆随时间保持“干净”。Letta:类操作系统的方式,一个“核心”记忆始终在上下文中(就像 RAM),还有一个归档记忆,在需要时通过工具调用显式地去取回。智能体自己决定把什么放在前台,什么归档。总之,存储向量是容易的部分。真正的关键,在于更新和决策的逻辑,知道保留什么、丢弃什么,以及如何在不复制整个库的情况下纠正一个事实。你们目前在生产环境中用什么,有没有遇到过记忆“漂移”的麻烦(矛盾不断累积、上下文爆炸)?
相似文章
@PrajwalTomar_: 你的向量数据库不是记忆,它是坟墓。伦敦存储、取消忽略、健身房仍、伦敦嵌入有效、数据库有效……
这篇文章认为,向量数据库单独作为数据坟墓,缺乏真正的记忆功能,并描述了在Actian VectorAI DB之上构建具有矛盾检测和遗忘周期的本地AI记忆层。
不受欢迎的观点:AI 代理并不总是需要向量数据库来存储项目记忆
文章认为,对于中小型编码项目,使用向量数据库作为 AI 代理的记忆可能没有必要,并提议使用 Markdown 和 Git 作为更简单、可审计的替代方案来管理项目上下文。
V1记忆架构在多代理设置(主管/子代理)中的反馈——目标检索与统一存储的对比?
一位开发者分享了一个多代理系统的原型记忆架构,包含对情景记忆、语义记忆和程序记忆的分开存储,以及基于意图的检索,寻求关于可扩展性和设计选择的反馈。
理解智能体记忆(38分钟阅读)
本文比较了三种常见的智能体记忆系统形态——基于文件的、结构化存储和基于经验的,并通过一个使用常见智能体循环和开源模型的基准测试评估了它们的有效性。
AIPass 记忆系统:为何拥有小型 JSON 文件的智能体胜过巨型向量存储
AIPass 引入了一个记忆系统,其中 AI 智能体在小型 JSON 文件中管理其身份和会话历史,通过钩子实现在必要时才归档到向量存储的上下文注入,从而提升多智能体设置的效率。