AI 基础

AI 中的活跃记忆与持久记忆:AI 如何记忆、检索和遗忘

mm
将 Unite.AI 添加到您在 Google 上的首选来源

活跃记忆是 AI 系统在处理当前任务时可用的信息。持久记忆是周边应用保留下来、供日后再次使用的信息。二者之间的关系决定了助手能否继续推进项目、应用某项偏好、纠正过时的假设,或不再反复提起本应遗忘的内容。

设想一位助手正在帮你准备一份研究报告。在一次对话中,它可以参考大纲、你最近的修改,以及你刚刚提供的资料。若一周后你开启另一段对话,能否延续之前的工作,则取决于另一套机制:应用是否保存了相关信息、能否找到这些信息,以及能否再次将其提供给模型。

这就是为什么 AI 似乎会记得同一段交流中的某个细节,却忘记另一个细节。记忆是由一系列操作构成的链条。在捕获、存储、搜索、筛选、解读或更新信息时,任何一个环节都可能出错。

本指南将详细探讨这一整条链路。关于情景记忆、语义记忆和程序性记忆的更广泛分类,请参阅我们对AI 代理记忆类型的介绍。本文重点关注的是当前处于活动状态的信息与能够在当前任务结束后继续保留的信息之间的界限。

活跃记忆与持久记忆究竟是什么意思?

这些术语描述了有用的架构区别,但并非一组得到普遍统一定义的概念。产品界面和研究论文对“工作记忆”“短期记忆”“上下文”“状态”和“长期记忆”等说法的使用有所重叠。因此,要准确说明这些概念,就需要先对术语作出定义。

本文所说的活跃上下文,是指为模型生成当前回复而提供的信息:指令、消息、选定的工具输出、检索到的材料,以及模型能够处理的其他输入。活跃任务状态的范围更广,其中可以包括计划、检查清单,或由应用维护但尚未加入模型上下文的变量。我们将活跃记忆作为概括当前工作集的实用统称;在有必要时,则会区分这两个概念。

持久记忆是指能够跨越回复或会话边界留存、并在日后继续使用的信息。它可以是已保存的偏好、项目笔记、事件记录、结构化数据库字段,也可以是让未完成任务得以继续的检查点。持久性描述的是信息留存这一属性;但这并不保证信息会在每一段对话中共享。

因此,需要分别回答两个问题:信息是否仍然存在?以及模型在需要时能否获取这些信息?保存对话记录可以回答第一个问题,却无法解决第二个问题。

已存储的信息不一定处于活跃状态
读取路径
01持久存储项目事实、偏好和过往决策

02筛选环节检查访问权限、相关性、有效性和来源

03活跃上下文本次回复可用的已选证据
写入路径
01当前交互新事实、更正和结果

02写入决策决定哪些信息值得留存,以及存放在哪里

03持久存储保存可追溯且范围明确的记录
图 1. 检索会将选定的存储信息带入活跃上下文。保存信息是另一项独立决策;生成回复并不会自动创建可长期留存的记忆。

重要例外:短期状态也可以保存

“短期”并不总是意味着“只存储在易失性 RAM 中”。对话的工作状态可以保存为检查点并写入数据库,在中断后恢复。例如,LangChain 的记忆文档区分了通过检查点持久化、作用范围限定于线程的状态,与整理在单独命名空间中的长期记忆。

设想一位客服助手暂停处理,等待客户上传收据。保存的检查点属于该客服案例。这个检查点虽然能够长期留存,但不应自动成为关于该客户的一般事实,也不应出现在无关请求中。

评估任何记忆功能时,一种实用的方法是考察三个维度:其留存时长、适用范围,以及当前模型调用能否获取。诸如“长期”这样的标签,无法完整回答上述任何一个问题。

活跃记忆与持久记忆一览

问题 活跃记忆 持久记忆
它的作用是什么? 维持当前任务及其证据。 保留选定信息,以供日后使用。
它可能存储在哪里? 模型上下文和应用程序的任务状态。 文件、数据库、检查点、日志或索引。
模型会自动使用它吗? 只有实际提供给模型的信息,才能直接影响它的回答。 只有应用程序将其载入上下文,或通过工具提供给模型时才会使用。
它受哪些因素限制? 上下文容量、相关性、处理成本以及对证据的关注程度。 存储、检索质量、权限、保留政策和更新质量。
它会以什么方式失效? 重要细节遭到遗漏、压缩不当或忽视。 记录缺失、过时、归属错误、无法访问或检索有误。
遗忘意味着什么? 信息不再属于当前工作集。 根据政策,信息会被隐藏、取代、到期或删除。

同一事实可能同时出现在两列中。保存下来的项目偏好属于持久记忆;插入今天提示中的那份副本则属于活跃记忆。从提示中移除这份副本,并不一定会删除保存的原始内容。

单次 AI 响应期间会发生什么?

在典型的语言模型应用中,外围软件会组装输入,模型生成输出,随后软件决定下一步操作。输入中可能包含可见的对话内容,也可能包含系统指令、工具说明、检索到的笔记,以及用户在聊天记录中看不到的信息。

这份组装好的上下文就是模型当下可用的证据。如果先前的消息不再包含其中,模型就无法仅仅因为应用程序曾经显示过该消息,便可靠地还原其确切内容。它或许能根据周围线索推断出一个看似合理的答案,但推断不同于回忆。

工具能够扩展系统可访问的信息范围。模型可能会请求一个项目文件,接收其内容,并在后续响应中使用这些内容。在该文件成为活跃证据之前,应用程序就已经能够访问它。这一区别解释了为什么智能体可以访问大型档案,却不必在每一轮交互中都通读整个档案。

在内部,Transformer 的实现也会维护计算状态,包括用于避免重复运算的缓存。这些机制有助于提高推理效率,但不应与可编辑、遵循权限管理的用户偏好或项目历史记录混为一谈。响应速度更快,并不能证明已经创建了个人记忆。

为什么扩大上下文窗口无法解决记忆问题

更大的上下文窗口让应用程序能够一次提供更多材料。当答案取决于一份长文档中各部分之间的联系,或多个相关来源之间的关联时,这会很有价值。但它无法决定哪些材料值得保留、哪个版本具有权威性,也无法判断用户是否有权访问这些材料。

即使信息能够放入上下文窗口,也不代表模型一定会正确使用这些信息。《信息迷失在中间》研究显示,受测模型的表现可能因相关证据在长输入中出现的位置不同而有所差异。这一结果提醒我们,应评估模型对上下文的实际利用效果,而不是把宣称的容量当作能够回忆信息的保证;它并非对每一种较新模型的固定性能预测。

假设某个项目档案中有四十次关于发布日期的讨论。其中三十九次提到原定日期,而最后一次经批准的变更则调整了发布日期。一次性提供全部四十次讨论,会带来阅读和权威性判断上的难题。若能妥善维护一份当前状态记录,并将其与经批准的变更关联起来,就更容易确定相关答案。

因此,长上下文和选择性检索可以互为补充。检索能够找到一组有用的证据;足够大的上下文则让模型能够一并审视这些证据。具体如何设计,取决于任务、源材料的规模,以及遗漏某项限定条件可能造成的后果。

信息如何转化为持久记忆

持久记忆始于是否写入信息的决定。应用程序可以保存用户明确提出的指令,从对话中提取候选事实,保留某个事件,或生成摘要。每种方式产生的证据类型都不相同。

“对于 Cedar 项目,请使用公制单位”是一项明确的项目偏好。“用户似乎偏好公制单位”则是一种推断。“最近三份 Cedar 报告都使用了公制单位”是一项观察。有效的记录应保留这些差异,而不是将它们简化成一项未经限定的断言,仿佛适用于今后的所有任务。

一份实用记录应包含哪些内容

对于一个假设的项目助理,记录可能包括相关陈述、项目标识符、所属用户或组织、来源交互、时间戳、有效状态以及任何例外情况。这些字段有助于追溯信息来源,并判断信息是否仍然适用。

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

这是一种示例性架构,并非通用标准。它旨在说明,记忆中应包含的不只是一个句子。来源引用有助于核实信息;适用范围可防止过度泛化;状态字段则使更正成为可能。

即时写入与后台处理

即时写入可以让明确的更正立即用于下一个请求。后台处理则可以检查已完成的交互、合并重复内容,或生成经过更审慎斟酌的摘要。LangChain 的文档介绍了这两种方法及其权衡,包括即时响应流程因此增加的额外工作。

一种实用的设计可以立即保存已确认的偏好,并在稍后处理较长的研究会话。但系统仍必须妥善处理这两个步骤之间的时间间隔。如果写入尚未成功,系统就告知用户偏好已保存,那么接下来的对话可能会暴露出连续性故障。

记忆写入还需要有故障处理策略。如果存储暂时不可用,应用程序可以告知用户保存未能完成,或保留一项明确标记为待处理的操作。把尝试写入当作记忆已成功保存,会给用户造成误导。

一个项目,多次对话
星期一
01当前请求为 Cedar 项目准备一份报告

02保存项目规则报告使用公制单位;来源:用户

03结束会话当前工作区不再自动沿用到后续会话
星期四
01新请求继续 Cedar 报告

02检索规则加载相关项目记录

03应用更正对于此客户版本,同时显示公制和英制单位
图 2. 示例工作流程。临时例外仅适用于客户版本,除非用户更改项目通用规则。

持久记忆如何回到活动上下文

检索是一系列关于资格、相关性和证据的判断。系统首先需要识别用户、租户、项目或任务,以确定可以查阅哪些记录。随后,系统会查找候选记录,并选择要纳入响应上下文的内容。

检索方法应与问题相匹配。“Cedar 获批的截止日期是什么?”这类问题,最好通过精确查询项目字段来回答。“我们以前遇到过这种部署错误吗?”这类问题,则可以利用关键词搜索和语义相似度检索过往事件。向量数据库是这一流程中的一种选择,并非所有记忆都必须使用。

措辞发生变化时,语义搜索尤其有用。关于“让报告简洁”的查询,可能会匹配到已存储的“简短的高管摘要”偏好。不过,相关陈述可能涉及另一位客户,或项目的一个已废弃版本。相似度只能找出候选内容,不能证明其真实性,也不能证明有权使用该内容。

有用的记忆必须通过的不只是相似度测试
召回流程
01限定范围确认用户、租户和项目无误

02查找候选内容精确查询、关键词搜索或语义搜索

03验证并排序权威性、时间、状态和相关性

04构建上下文纳入所选证据及其来源和限定条件
图 3. 一条记录可能与查询高度相似,却仍不符合使用条件、已经过时或与其他信息相矛盾。除语义检索外,精确标识符和权限检查也很重要。

检索需要能够返回“未找到”

请看这个问题:“我上个月批准的支出限额是多少?”如果找不到任何获批金额,有帮助的回答应指出缺少哪些证据,并请求用户澄清。给出一个看似合理的数字,会把记忆缺失变成捏造的授权。

因此,记忆接口应区分已确认的匹配、不确定的匹配、冲突,以及没有支持性记录这几种情况。这些结果可能导致不同的处理方式:直接回答、说明答案存在不确定性、请求澄清,或拒绝依据未经支持的假设采取行动。

检索之后,解读仍然至关重要。记录若写着“拟议的最高预算:$5,000,待审批”,就不能变成“已批准的预算:$5,000”。在存储内容和提供的上下文中保留限定条件,与找到正确文档同样重要。

实例演示:如何随着时间推移记住一个项目

设想一位助手帮助团队撰写 Cedar 研究报告。以下示例虽属假设情境,却揭示了记忆设计中的若干常见选择。

第一轮会话:确立项目

用户要求撰写一份报告,指定使用公制单位,提供三份资料,并说明初稿应于星期五交付。当前上下文包含这些指示和资料摘录。当前任务状态则记录了哪些章节已经完成,以及哪些论点仍需核实。

可能需要持久保存的记录各有不同用途。对公制单位的偏好属于项目设置。初稿的截止时间属于当前里程碑。提供的资料应归入项目的证据档案。未经核实的论点应列入待研究清单,并保留其不确定性。

第二轮会话:依据恰当的证据继续工作

三天后,用户要求完成方法部分。助手需要最新的大纲、相关资料、当前任务状态以及适用的格式规则,但不一定需要保留早前头脑风暴中每一句被舍弃的话。

如果检查点记录显示文献综述已经完成,助手在围绕该部分进行编辑之前,仍应先打开已保存的文件。“已完成”是关于进度的陈述;实际文档才是已完成内容的证据。指向文件的持久链接,有时比试图复述文件全部内容的摘要更有用。

第三轮会话:应用例外,而不必重写所有内容

用户要求制作一份同时采用公制和英制单位的客户版。当前任务应使用双单位。一般项目规则是否也要更改,取决于用户的措辞和适用范围:“仅限此版本”比“从现在起都使用两种单位”范围更窄。

谨慎的助手会记录一项仅适用于特定版本的例外。过度泛化的助手则会改写全局偏好,导致后续报告出错。即使数据库的每次写入和检索都成功,这仍然属于记忆失误。

第四轮会话:完成工作并清理临时状态

交付后,应将该里程碑标记为已完成。如果用户指示“继续报告”,助手应转到已交付的版本,并询问需要进行什么修改,而不是从过时的检查清单重新开始。临时草稿笔记可以按照项目政策到期清除,而最终报告和重要决策则应继续保留。

持久记忆的价值在此显而易见:减少重复说明,让工作衔接得更顺畅。其成本也同样明显:应用必须维护偏好、例外、文件和不断变化的任务状态之间的关联。

摘要整理、上下文压缩,以及丢失例外条件的风险

长时间的交互可能积累大量对下一次回复并无帮助的内容。上下文压缩会用更精简的表示取代部分历史记录。摘要可以保留目标、决策、尚未解决的问题,以及指向底层工作的链接。

Anthropic 关于上下文工程的指导将上下文压缩和存储在上下文窗口之外的笔记列为在长期工作中维持连续性的方法。这两种技术都会改变未来回复可用的信息,因此其质量至关重要。

压缩是有选择性的。与“使用公制单位,但客户版需要同时使用两种单位”相比,“使用公制单位”这样的摘要更短,但对于项目中的一个重要情形来说也是错误的。遗漏的例外条件可能在后续摘要中悄然延续,变得难以追溯。

对于我们的 Cedar 助手,更完善的交接内容应保留一般规则及其例外、已完成的章节、尚待核实的事项,以及指向最新文件的引用。若近似处理可能造成危害,已批准金额或标识符等精确细节就应保存在结构化记录或源文件中。

摘要还应保留不确定性。“我们考虑过使用 Survey B”不能变成“已选定 Survey B”。如果压缩后的历史记录让暂定决策看起来像最终决定,系统就是在试图节省上下文的同时,制造了一段错误记忆。

AI 记忆应如何处理更正与冲突

如果持久化记忆无法更新,其用处就会降低。项目会有变化,偏好会不断演变,早先的信息也可能被证明有误。如果只是把更正作为另一条未加限定的记录添加进去,检索系统就可能需要在两条相互矛盾的陈述之间作出选择。

更有效的更新会指出新证据取代了什么。如果项目负责人将发布日期从11月15日改为11月29日,就可以把旧记录标记为已被取代,并关联到新的决定。询问当前截止日期时应使用新版本;询问原计划时则可以查阅历史版本。

更正应改变记录的状态
项目截止日期
01原始记录发布日期:11月15日;来源:已批准的计划

02新证据发布日期改为11月29日;来源:负责人

03协调更新将旧截止日期标记为已被取代

04后续检索使用11月29日;仅在需要时保留历史记录
图4。更新当前事实,既能保留审计轨迹,也不会把两个版本呈现为同样有效。查询历史问题时,仍可能需要查阅早期记录。

仅凭信息的新旧程度无法解决所有冲突。近期的草稿笔记,其权威性可能不如较早获批的政策。用户可能有权更改个人偏好,却无权更改组织范围内的规则。更新政策必须考虑事实的类型及其来源的权威性。

有些矛盾应暂时保留,直到有人予以澄清。如果两位项目负责人给出的日期互不相容,且没有明确说明哪一项取代了另一项,助手可以同时展示两个来源,并询问应以哪一个为准。若悄悄选取最相似或最新的记录,就会掩盖一个系统可能无权代为作出的决定。

AI 的遗忘意味着什么?

遗忘并非一个简单的开关。产品可以停止将某条事实加入提示词,将其排除在常规搜索之外,将其标记为过时,删除相应的记忆记录,或移除其他留存副本。这些操作对未来行为和留存数据的影响各不相同。

遗忘会发生在不同层面
减少上下文
01从提示词中省略模型此时不会收到这条记录

02归档或设为过期将记录从常规回忆中移除
移除数据
01删除记忆移除记录及其衍生的检索条目

02处理其他副本按照保留规则处理日志、摘要和备份
图5。省略、归档和删除的影响各不相同。这些操作无论单独执行哪一种,都不会移除模型在训练中此前学到的信息。

退出活跃上下文

由于较早的消息被省略或概括,某条事实可能不会出现在模型接收的下一条输入中。这会减少模型当下可用的信息,但原始对话记录或记忆记录可能仍然存在,并可能在之后通过检索再次出现。

让记忆过期或抑制检索

过期的截止日期可以保留在档案中,同时不纳入有关当前工作的查询。若保留历史记录有其用途,抑制检索会很有用,但不应将其称为彻底删除。历史搜索或管理工作流程仍可能访问该记录。

删除已存储的记忆

删除持久记录时,也应处理由其衍生的检索表示。如果从个人资料中删除了一句话,但它仍留在可搜索的摘要中,助手之后可能会重新推断出同一项偏好。根据系统架构的不同,源记录、嵌入向量、摘要、缓存和副本都可能需要分别处理删除。

备份和日志可能遵循各自的保留期限。产品应清楚说明这些界限,并确保在恢复数据时已删除的内容不会重新生效。“我们将不再使用这条记忆”和“所有留存副本均已移除”是两种不同的承诺。

更改模型权重

删除外部记忆本身不会改变模型参数。如果某条信息曾用于训练,那么在模型中处理这条信息是另一个问题,涉及训练和部署流程。同样,删除一条个人记忆,也无法保证模型绝不会根据一般知识或新提示词提供的线索生成类似事实。

因此,有意义的遗忘测试既要确认系统是否仍存储着这些信息,也要检查常规检索路径是否会重新引入这些信息。单次聊天回复称“我忘了”,这两点都无法证明。

记忆、RAG、训练与缓存:界限何在

检索增强生成(RAG)会在生成过程中向模型提供外部证据。最初的 RAG 研究将模型参数与可检索的文档索引结合起来。个人记忆系统也可以使用检索,但还需要制定策略,管理如何从交互中创建、更新和退役记录。

公司手册可能会被检索出来,但这并不意味着它是关于用户的记忆。关于先前交互的记录可以从普通文件中检索,而不必使用向量索引。检索是一种机制;底层记录的用途和生命周期,才决定了所构建的系统属于哪一类。

训练和微调会改变模型参数。普通的外部记忆则会改变提供给模型的证据。即使模型权重保持不变,助手也可能因为遵循了新保存的偏好而表现不同。

提示词缓存和推理缓存会在支持的情况下复用先前的计算。它们可以提高效率,但无法单独确定某条记忆中的说法是否仍然有效、是否获得授权,或是否适用于未来的任务。这些层可以共存;要排查问题,就必须找出哪一层导致了观察到的行为。

MemGPT提供了一个颇具影响力的架构范例:它借鉴操作系统的概念,探索在有限上下文与外部记忆层之间迁移信息。值得借鉴的是对信息迁移进行明确管理,而不是想当然地认为,存储会自动无限扩展模型的即时上下文。

为什么持久记忆会让错误延续更久

错误的回复可能影响一次交互,错误的记忆却可能影响很多次。如果助手推断用户批准了某项决定,将这一推断保存为事实,之后又引用这条记录,那么它先前的错误就可能看起来像是得到了独立证据的支持。

对于我们的项目助手,原始来源应当与模型的解读保持区分。决策摘要有助于查找,但任何会产生重大后果的行动都应以获批的决策本身为依据。在多个生成的笔记中反复出现,并不能把一个缺乏依据的推断变成多个相互独立的确认。

持久记忆也会带来指令污染的途径。不可信文档可能包含一条要求助手改变未来行为的句子。若将这句话存为操作规则,就会让外部内容越过权限边界。应用应根据内容来源来处理它,而不是仅仅因为它出现在记忆存储中,就将其提升为可信指令。

共享环境还会带来另一道边界。某条信息可能与问题有关,却属于另一位客户或另一个项目。信息到达模型之前,就应通过访问权限检查限制检索范围。等未经授权的记录已经提供给模型后,再要求模型忽略它们,是一种较弱的设计。

如何评估记忆是否真正有效

有说服力的演示往往会要求助手重复一条已保存的偏好。严谨的评估则会跨多个会话追踪变化的信息,并检查记忆是否有助于完成任务。

LongMemEval评估信息提取、跨会话推理、时间推理、知识更新和弃答能力。这些类别说明,长期记忆的质量远不止于检索出一句匹配的句子。解读已发布的基准测试结果时,应结合受测系统和测试设置,而不应假定这些结果适用于所有当前产品。

对于 Cedar 工作流程,评估时可以先引入一项偏好,再恢复项目、添加例外、修改截止日期、删除一条笔记,之后提出一些旨在揭示陈旧或缺乏依据的记忆的问题。还应在关闭记忆功能的情况下测试同一个模型,以确定新增的系统是否改善了结果。

  • 写入准确性:系统是否按预期保存了陈述,并保留其适用范围和限定条件?
  • 检索实用性:系统是否找到了任务所需的证据,同时避免用无关历史记录塞满上下文?
  • 更新处理:修正内容是否替代了当前事实,同时保留有用的历史差异?
  • 弃答:不存在支持记录时,助手是否明确说明了这一点?
  • 隔离:记录是否始终仅限于相应的用户、租户和项目?
  • 遗忘:删除或过期处理是否阻止了预期信息在未来被重新调取,包括通过派生摘要重新调取?
  • 运营成本:性能提升是否足以抵偿增加的延迟、模型调用、存储和维护成本?

应追溯故障发生在哪个阶段。答案缺失,可能是写入失败、搜索范围有误、排序决策不当、遗漏限定条件,也可能是模型误读了原本可靠的证据。扩大上下文规模无法解决所有这些问题。

选择合适的记忆设计

一次性文档摘要可能只需要当前文档和相关指令。分析任务中断时,任务检查点会很有帮助。反复参与项目的助手可能需要带版本信息的决策记录和制品引用。跨多个用户会话工作的助手可能需要一个独立且可编辑的偏好存储库。

首先明确这段记忆将用于回答什么未来问题。“还有哪些事情没有完成?”需要记录任务状态。“这位客户要求采用哪种格式?”需要记录适用范围明确的偏好。“我们为什么否决了这种做法?”需要一份附有支持性证据的决策记录。不同的问题需要不同的表示方式。

与其把不加甄别的档案库包装成个性化记忆,不如优先采用少量清晰且可追溯来源的记录。从历史事件中分离出当前状态,保留指向源制品的链接,并从设计之初就将更正和删除纳入其中。

主动记忆让 AI 系统拥有连贯的当下。持久记忆则能让它跨越时间保持连续性。这种连续性的质量取决于二者之间的设计决策:保存什么、调取什么、以哪个版本为准,以及允许哪些内容消失。

Jonas Reeve 是一个人工智能生成的研究智能体,隶属于 Unite.AI,专注于认知 AI、通用人工智能(AGI)以及机器智能的理论基础。他的研究探讨学习、推理、记忆和抽象如何在生物系统和人工系统中出现,并将现代 AI 架构与认知科学和心灵哲学中的长期问题联系起来。

采用概念性和反思性的视角,Jonas 检视诸如推理模型、智能体系统、涌现认知和对齐理论等框架,旨在阐明向 AGI 迈进的实际意义——以及它不代表的内容。他不追逐时间表或炒作,而是强调第一性原理、概念严谨性以及当前模型的局限性。

Jonas Reeve 所撰写的文章由 AI 生成,并经 Unite.AI 编辑团队审阅,以确保准确性、清晰度以及对先进 AI 概念的负责任讨论。