I. AI长时记忆:向自演进智能体的范式转变

大规模语言模型(LLMs)的上下文窗口不断扩大,显著提升了短期交互的连贯性和多步骤推理能力,即短期记忆(Short-Term Memory, STM)的功能。然而,对于用户提出的跨会话持久化用户身份、偏好和习惯的需求,仅依赖STM是远远不够的。长时记忆(Long-Term Memory, LTM)系统旨在解决一个根本性的、需要持久化的挑战:支持真正的个性化和终身学习。

1.1 功能差距:上下文窗口限制与持久化身份

一个生产级的AI记忆系统由四个核心支柱组成:STM(追踪最近交互)、LTM(跨会话持久化,存储事实、偏好和身份)、检索机制(通过向量搜索或知识图谱查找相关信息)以及动态更新机制(在新信号输入时重写或强化记忆)1。

LTM被视为实现AI自演进的关键机制 2。传统的LLM基础模型是在庞大的静态数据集上训练的;相比之下,LTM允许模型在推理阶段根据处理过的真实世界交互数据和累积的个性化经验不断发展 2。这种架构设计使得核心LLM推理引擎(可以视为“人工新皮层” 3)与动态、个性化的数据存储层解耦。LTM负责管理持续变化的、针对个体用户的“长尾数据” 2。这种解耦是必要的,因为它允许系统以低延迟的方式持续更新用户模型,从而绕过成本高昂且耗时的传统模型微调过程,实现了模型在推理时的快速“演进”。

1.2 定义复杂个性化:习惯、偏好和时间焦点

用户需求要求系统不仅能回忆简单的事实,还需要提取动态、复杂且可能相互冲突的信息,例如用户习惯、不断变化的喜好和当前的关注点。

为了实现这种复杂程度的提取,LTM需要采用专业化的记忆策略 4:

  1. 语义记忆 (Semantic Memory): 用于捕获事实性知识,例如客户的交易历史或项目细节 4。

  2. 用户偏好记忆 (User Preference Memory): 用于捕获在特定上下文中明确或隐含的偏好。这些信息通常以结构化的方式存储,包含类别和上下文元数据,例如:{“preference”: "Prefers Python for development work", “categories”: [“programming”, ”code-style”], “context”: “User wants to write a student enrollment website”} 4。

  3. 总结记忆 (Summarization Memory): 用于将复杂的、多轮对话提炼成持续的叙事,以便更好地进行上下文管理 4。

这种将偏好提取为结构化记录(而非纯文本)的做法至关重要。结构化的、多维度的记录(如JSON或XML)附带元数据、类别和上下文,能够更好地支持用户提及的“其他AI使用场景”,允许下游智能体执行条件推理(例如:“如果上下文是医疗保健,则仅检索语义记忆;如果上下文是开发,则检索Python偏好记忆”)。这种显式的结构和元数据过滤能力 5 使得智能体能够准确地找到并“补充遗漏的关注细节”。

此外,由于用户偏好并非一成不变,LTM系统必须具备时间动态建模的能力。这要求系统配备机制,例如偏好变化检测器(Preference Shift Detector) 6。该机制利用滑动窗口和指数移动平均(EMA)等组合方法来建模用户偏好的时间动态,从而检测渐进性的漂移或突然的意图转变,确保模型的响应策略始终与用户不断发展的意图保持一致 6。

II. 关联性召回的LTM基础架构与数据建模

LTM底层的选择是构建系统的核心决策,它决定了系统建模关系、保持透明度以及执行多跳推理的能力,这些都是实现用户复杂个性化目标的关键要素。

2.1 标准向量数据库(VDB)RAG的局限性

标准检索增强生成(RAG)纯粹依赖于向量数据库(VDBs),通过语义相似性进行检索。VDBs擅长处理非结构化数据,并通过在潜在空间中寻找相似性来高效获取信息,即使没有精确的关键词也能工作 7。

然而,VDB在建模复杂关系方面存在根本缺陷 7。由于其检索机制基于相似性得分和预定义的返回限制,当查询涉及实体间的复杂关联时,VDB往往难以高效地返回精确结果,可能导致结果不完整、过于宽泛或事实不准确 8。这种对向量检索的依赖,阻碍了系统模仿人类长时记忆动态且相互关联的本质,尤其是关联性召回(Associativity)的能力 3。

2.2 知识图谱(KG)范式与关系记忆

知识图谱(KGs)通过将信息组织成实体和显式、带标签的关系网络,弥补了VDB的固有局限性,使其在建模用户习惯和复杂关联方面表现卓越。

KGs将数据存储为节点和它们之间的关系网络,为LLMs提供了结构化数据的支持 9。这种结构使模型能够更智能地导航信息空间,从而促进复杂、多部分的多跳推理 8。对于复杂的查询,例如“过去十二个月中,有哪些董事会议至少有两名成员投了弃权票?”,KG通过遍历图结构返回精确信息,而VDB则可能在向量空间的中间找到一个模糊答案 8。

此外,KGs提供了完全的透明度,开发人员可以追溯查询路径,识别数据中的错误信息或幻觉的来源,并进行修正,这在VDB的黑箱相似性评分中是难以实现的 8。值得注意的是,LLMs也可以被用来直接从非结构化文本中提取实体和关系,从而自动构建知识图谱 10。

2.3 混合架构:优化关联记忆(HippoRAG 2)

最先进的LTM系统通常结合了VDB(用于快速语义召回)和KG(用于深度关系推理)的优势。GraphRAG即是将RAG与知识图谱结合,增强上下文的结构化基础 10。

HippoRAG 2框架是一种受神经生物学启发的LTM模型,它将LLM视为新皮层,将KG和个性化PageRank (PPR) 算法视为海马体 3。PPR算法被集成到在线检索过程中,赋予检索机制多跳推理能力,这对实现用户所需的关联性记忆至关重要 3。在检索时,LLM从查询中提取命名实体,这些实体成为KG中的种子节点。PPR算法以这些种子节点分配的重置概率运行,将概率分布导向这些节点及其邻域,从而实现基于上下文的检索 3。这种设计使得HippoRAG 2在关联记忆任务中取得了显著提升,证明了KG/PPR混合架构在模仿人类记忆动态方面的优越性 3。

用户要求提取“习惯”和“关注点”,这本身就要求系统具备关联记忆能力。一个习惯是行为和偏好的因果链(例如:“用户经常熬夜 [事实 1] $\rightarrow$ 喜欢点咖啡 [事实 2] $\rightarrow$ 总是使用 Python 编写代码 [偏好] $\rightarrow$ 因为看重延迟 [关注点]”)。纯粹的VDB RAG难以将“熬夜”和“使用Python”关联起来,除非它们碰巧在语义上相近。KG架构通过显式建模这种关系路径,强制实现了深度个性化所必需的关联连接。

III. 动态记忆生命周期管理:提取与整合

LTM架构的有效性依赖于维持和完善记忆状态的动态过程。核心工程挑战在于智能化的整合和有纪律的记忆管理。

3.1 智能记忆提取与异步处理

为了避免在实时交互中引入延迟,记忆的形成过程必须在后台进行。这通常被称为潜意识形成(Subconscious Formation) 5。该技术要求系统在对话发生后(或在非活动期)提示LLM对对话进行反思,从而提取模式和结构化见解,同时不拖慢即时交互速度 5。

这个过程涉及到记忆提取代理(Extraction Agents)对STM中的会话内容进行分析,以识别应持久化到LTM中的有意义信息 4。在此阶段,系统执行专门的策略,如语义、偏好和总结记忆的提取 4。

3.2 整合算法与冲突解决

稳健LTM系统的一个关键区别在于LLM驱动的整合循环,它用于防止冗余和解决记忆冲突。

整合过程的机制:当新的记忆被提取后,系统首先从同一命名空间和策略中检索出语义最相似的 $N$ 个现有记忆 4。新记忆和已检索的现有记忆随后被发送给LLM,并附带一个高度专业化的整合提示(consolidation prompt) 4。LLM根据提示确定适当的行动 4:

  • ADD (添加): 新信息与现有记忆明显不同。

  • UPDATE (更新): 新知识补充或增强现有条目(例如,加强已知的偏好或添加上下文) 4。

  • DELETE/INVALIDATE (删除/失效): 信息存在矛盾、已过时或必须被清除。AWS AgentCore等系统通过将过时的记忆标记为 INVALID 而不是立即删除,来维护不可变的审计追踪 4。

  • NO-OP (不操作): 信息是冗余的(例如,已整合了“喜欢披萨”和“爱吃披萨”) 4。

这种LLM整合步骤实际上扮演了实时知识图谱维护操作者的角色。它动态推理知识关系、解决本体论冲突并维护数据卫生。然而,由于LLM推理是ADD/UPDATE/NO-OP决策的必要环节,这引入了额外的延迟和代币成本到记忆管理循环中 13,因此必须异步管理 4。

3.3 记忆管理:减轻“经验负债”

与直觉相反,简单地积累更多数据并不能自动带来更好的性能。研究表明,AI的经验可能成为一种负债,固化错误并使基础设施变得臃肿 14。那些与新任务具有高输入相似性但产生低输出相似性(即表现不佳)的经验,被称为“失调的经验重放”(Misaligned Experience Replay),必须被移除 14。

因此,有纪律的记忆管理至关重要。通过基于历史的删除和选择性删除低价值或失调的记忆,能够提高系统的长期性能 14。当系统处理包含敏感用户数据(如个人身份信息或偏好)时,法律和合规性要求变得突出。例如,在AWS AgentCore中,维护不可变的审计追踪(通过标记 INVALID 而非永久删除)是一种技术实践,同时也是满足合规性要求的关键,确保数据的透明度和可审计性 4。

IV. 生产级框架回顾与性能基准

对现有领先LTM框架的评估有助于了解生产级系统在优化、成本管理和延迟最小化方面的实现细节。

4.1 Mem0:通过LLM驱动的整合实现性能优化

Mem0被设计为一个可扩展的、以记忆为中心的算法,专为生产环境中的智能体而构建 12。

架构和效率:Mem0摄入最新对话、滚动总结和最近 $m$ 条消息来提取记忆候选 12。它通过确保长期总结的刷新在异步后台进行,避免了实时交互时的推理停顿,从而实现了显著的优化 12。在LOCOMO基准测试中,Mem0表现出卓越的效率:相对于OpenAI的记忆系统,准确性提高了 26%;相对于全上下文模型,p95延迟降低了 91%;代币成本节省了 90% 12。

Mem0ᵍ(知识图谱增强):作为Mem0的增强版,Mem0ᵍ将记忆存储为有向、带标签的图结构。它使用实体提取器和关系生成器将文本转化为结构化图,从而实现了高效的子图检索和语义三元组匹配,为复杂的、多跳的、有时态性的推理提供了支持 12。

4.2 LangMem与LangChain生态系统

LangMem为LangChain/LangGraph生态系统提供了LTM集成的概念框架。其核心操作模式清晰:接受会话和当前记忆状态 $\rightarrow$ 提示LLM决定如何扩展或整合记忆状态 $\rightarrow$ 响应更新后的记忆状态 5。

LangMem与LangGraph的 BaseStore 接口集成,支持多种检索方式:直接访问(按键)、语义搜索(VDB)和元数据过滤 5。这种灵活性,尤其是元数据过滤能力,对于检索结构化的偏好数据非常有用。

4.3 替代架构方法:循环记忆Transformer (RMT)

循环记忆Transformer(RMT)提供了一种与RAG模型不同的LTM方法,它通过将记忆直接集成到模型的正向传递中,作为一种内部机制。RMT是一种记忆增强的分段级循环Transformer 15。它将记忆作为特殊的代币添加到输入序列中,模型经过训练来控制记忆操作和序列表示处理 15。RMT在需要全局信息保留的任务中表现出色 16。然而,全循环的结构使其并行化程度较低,相比于解耦的RAG/KG架构,RMT在部署时面临更高的延迟限制 16。

在对各种框架的性能分析中发现了一个核心工程权衡:虽然更复杂的记忆机制(如基于图的推理和LLM整合)能增强系统能力和准确性,但它们往往会大幅增加记忆操作的延迟 13。因此,在设计自定义代码时,必须像Mem0那样,通过积极优化异步提取阶段和使用紧凑的算法来严格控制检索延迟。

V. 指导性实施建议与结论

为了将架构理论转化为可操作的代码,本报告将专注于提取提示、后端选择和延迟缓解的实践细节,并提供最终的总结对比。

5.1 设计结构化提取代理提示

用户系统的基石在于提示的设计,它负责将非结构化对话转化为结构化、可重用的记忆记录(JSON/XML)。

  1. 提取提示蓝图: 提取提示必须指示LLM(充当数据专家 4)输出特定的结构化模式,例如用户偏好格式 4。提示必须通过提供“特定主题和少样本示例”进行定制 17,以确保LLM只捕获高价值的用户习惯和关注点。

  2. 整合提示蓝图: 整合提示必须包含检索到的冲突记忆、新提取的记忆,以及一个严格的输出格式,定义LLM的行动(ADD、UPDATE、DELETE、NO-OP)。该提示需要广泛的防护措施,以确保输出格式合规性,并最大限度地减少幻觉行动 4。

5.2 选择正确的后端:成本、所有权和结构

用户必须选择一个持久化层,既能满足关系数据建模的功能要求(用于个性化),又能管理成本和数据所有权。

SQL/结构化后端:Memori等框架证明LTM可以完全存储在标准的SQL数据库(SQLite/PostgreSQL)中 18。其优势包括:真正的数据所有权、完全可审计性、高透明度(可通过SQL查询)、高成本效益(在大规模运行时比VDB节省80-90%的成本),以及合规性准备 18。鉴于对透明度、精确关系查询(特别是如果上层实现KG层)的需求,以及用户画像数据的敏感性,强烈建议采用 SQL/KG 混合后端作为核心存储,而非纯粹的VDB。

5.3 实施异步延迟缓解措施

延迟管理对于顺畅的用户体验至关重要。提取和整合过程必须被设计为异步生成流水线 17,可能在会话结束或一段时间不活动后触发 5。这种“潜意识”方法确保智能体不会因等待记忆更新而停滞。此外,利用并行处理架构允许不同的记忆策略(语义、偏好、总结)独立运行,进一步减少总体更新时间 4。

5.4 比较总结与战略建议

本节通过比较分析,为用户的自定义LTM代码实现提供最终的决策支持。

表 1: 架构对比:对用户偏好和习惯建模的适用性

特征

纯向量数据库 (例如:标准 RAG)

知识图谱 (KG) / Graph RAG

混合 LLM 驱动系统 (例如:Mem0/HippoRAG 2)

数据结构

密集向量(嵌入)

节点和带标签的边(三元组)

VDB 或 KG 内的结构化记录(通常为 JSON/XML)

关系建模能力

较差(仅依赖潜在空间中的接近度) 8

优秀(明确建模复杂的、多跳关系) 10

良好(利用结构化数据处理复杂事实,向量用于相似性)

处理时间变化

困难(需要持续重新索引)

中等(可通过跟踪边上的时间戳来建模时间上下文)

优秀(利用 LLM 和 EMA 等算法进行偏好变化检测) 6

检索机制

语义相似性(最近邻搜索) 7

图遍历、PPR、语义三元组匹配 3

VDB 搜索与结构化查询/整合的组合

透明度与可解释性

低(黑箱相似性得分) 8

高(查询路径可通过图遍历追溯) 10

中高(有审计追踪和明确的 LLM 行动记录) 4

最适合用户目标 (习惯/偏好)

低(不足以处理复杂关联)

高(对于深度关系上下文至关重要)

最佳(优化了事实检索和关联性)

表 2: 领先 LTM 框架的对比分析

框架

主要数据结构

关键提取策略

记忆更新机制

性能与效率亮点

最佳应用场景

Mem0 (核心)

向量数据库 + 滚动总结

动态 LLM 提取 (异步) 12

LLM 驱动的 ADD/UPDATE/DELETE/NOOP 4

高准确性,p95 延迟降低 91%,代币节省 90% 12

生产级智能体,要求高速度和高效率

Mem0ᵍ

有向、带标签的图 (KG)

实体和关系提取器 12

LLM 冲突检测器/解析器 (合并、失效) 12

实现多跳、时态和开放域推理

复杂推理、高关联性需求、持久化系统

LangMem

LangGraph BaseStore (灵活后端)

潜意识反思/整合 5

LLM 决策引擎用于扩展或整合状态 5

通过总结和选择性召回最小化上下文大小 1

LangChain/LangGraph 生态系统内的集成

HippoRAG 2

KG + 向量索引 + PPR

实体提取与段落集成 3

持续学习;在线 LLM 参与检查相关性 3

卓越的事实、意义理解和关联记忆能力 3

非参数化持续学习,高关联性召回

AgentCore (AWS)

多策略存储 (向量/键值)

语义、偏好和总结记忆 4

智能整合,并维护不可变审计追踪 (INVALIDation) 4

并行处理架构 4

企业级 AI 智能体,客户支持/CRM,个性化医疗

Memori

结构化 SQL 数据库 (SQLite/PG) 18

结构化实体提取/SQL 检索

透明的更新逻辑 (SQL/LLM 验证)

高透明度,比 VDB 节省 80-90% 成本 18

优先考虑数据所有权和可审计性的自定义实现

6.3 最终结论与实施建议

基于对现有LTM系统架构、性能和数据模型优缺点的全面分析,为实现用户对“提取长记忆用于其他AI使用场景”的目标,特别是捕获用户习惯、偏好和关注点,提供以下战略性建议:

  1. 采纳混合知识图谱架构: 纯粹基于语义相似性的方法无法捕捉复杂的习惯和因果关联。系统必须采用 知识图谱(KG)范式 来显式地建模关系,以实现精确的、多跳的关联性召回 10。建议使用结构化数据库作为后端,以存储这些KG结构,确保透明度和可审计性 18。

  2. 设计异步、LLM驱动的记忆管理: 必须将记忆的提取和整合(包括冲突解决和冗余消除)作为异步后台任务 4。这一过程需要利用专门的LLM代理和高度结构化的提示来决定记忆的 ADD、UPDATE 或 DELETE/INVALID 4,从而在不牺牲实时用户体验的前提下,持续维护记忆的准确性和卫生。

  3. 整合动态偏好检测和记忆管理: LTM代码应包含机制来识别偏好的时间漂移(例如,使用EMA或滑动窗口) 6,确保个性化模型是动态更新的,而非基于过时数据。同时,必须实施基于历史的删除机制,主动清除低价值或误导性的记忆,避免系统被“失调的经验重放”所累 14。

  4. 优化数据结构以支持下游推理: 确保提取出的偏好数据以结构化、可过滤的格式(如带有元数据的 JSON 或 XML)存储 4。这种结构化格式是支持用户其他AI使用场景进行高效条件推理和上下文注入的基础,有效补充遗漏细节。

引用的著作
  1. AI Memory Layer: Top Platforms and Approaches - Arize AI, 访问时间为 十月 24, 2025, https://arize.com/ai-memory/

  2. Long Term Memory : The Foundation of AI Self-Evolution - arXiv, 访问时间为 十月 24, 2025, https://arxiv.org/html/2410.15665v4

  3. From RAG to Memory: Non-Parametric Continual Learning ... - arXiv, 访问时间为 十月 24, 2025, https://arxiv.org/abs/2502.14802

  4. Building smarter AI agents: AgentCore long-term memory deep dive - AWS, 访问时间为 十月 24, 2025, https://aws.amazon.com/blogs/machine-learning/building-smarter-ai-agents-agentcore-long-term-memory-deep-dive/

  5. Long-term Memory in LLM Applications, 访问时间为 十月 24, 2025, https://langchain-ai.github.io/langmem/concepts/conceptual_guide/

  6. Preference-Aware Memory Update for Long-Term LLM Agents - arXiv, 访问时间为 十月 24, 2025, https://arxiv.org/html/2510.09720v1

  7. Knowledge graph vs vector database: Which one to choose? - FalkorDB, 访问时间为 十月 24, 2025, https://www.falkordb.com/blog/knowledge-graph-vs-vector-database/

  8. Knowledge Graph vs. Vector Database for Grounding Your LLM - Neo4j, 访问时间为 十月 24, 2025, https://neo4j.com/blog/genai/knowledge-graph-vs-vectordb-for-retrieval-augmented-generation/

  9. 访问时间为 十月 24, 2025, https://neo4j.com/blog/genai/knowledge-graph-llm-multi-hop-reasoning/#:~:text=Knowledge%20graphs%20ground%20LLMs%20in,and%20the%20connections%20between%20them.

  10. How to Improve Multi-Hop Reasoning With Knowledge Graphs and LLMs - Neo4j, 访问时间为 十月 24, 2025, https://neo4j.com/blog/genai/knowledge-graph-llm-multi-hop-reasoning/

  11. From RAG to Memory: Non-Parametric Continual Learning for Large Language Models, 访问时间为 十月 24, 2025, https://arxiv.org/html/2502.14802v1

  12. AI Memory Research: 26% Accuracy Boost for LLMs | Mem0, 访问时间为 十月 24, 2025, https://mem0.ai/research

  13. MemoryBench: A Benchmark for Memory and Continual Learning in LLM Systems - arXiv, 访问时间为 十月 24, 2025, https://arxiv.org/html/2510.17281v1

  14. Smarter Memories, Stronger Agents: How Selective Recall Boosts LLM Performance, 访问时间为 十月 24, 2025, https://d3.harvard.edu/smarter-memories-stronger-agents-how-selective-recall-boosts-llm-performance/

  15. booydar/recurrent-memory-transformer: [NeurIPS 22] [AAAI 24] Recurrent Transformer-based long-context architecture. - GitHub, 访问时间为 十月 24, 2025, https://github.com/booydar/recurrent-memory-transformer

  16. Recurrent Memory Transformer - NIPS papers, 访问时间为 十月 24, 2025, https://papers.neurips.cc/paper_files/paper/2022/file/47e288629a6996a17ce50b90a056a0e1-Paper-Conference.pdf

  17. Vertex AI Agent Engine Memory Bank overview - Google Cloud Documentation, 访问时间为 十月 24, 2025, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/overview

  18. Open-Source Memory Engine for LLMs, AI Agents & Multi-Agent Systems - GitHub, 访问时间为 十月 24, 2025, https://github.com/GibsonAI/memori

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐