长期记忆的实现方式 | 上下文与 RAG | 做产品

长期记忆的实现方式

「AI 助手会记住你的偏好」是很有吸引力的卖点。但要先说清楚：模型本身没有任何跨会话记忆。所有的「记得」，都是你的系统在旁边替它存和取。

你会遇到的现象

• 用户抱怨「上次都说过了，怎么又问一遍」

• 做了记忆功能之后，它记住了一些莫名其妙的琐事

• 用户改了偏好，它却还按老的来

三个环节

① 提取 —— 从这次对话里挑出值得记的。

对话结束（或进行中），由一个模型调用判断：这里面有哪些是以后还用得上的信息？比如用户说「我一般用 Python」「我们公司在深圳」「不要给我发邮件提醒」。

② 存储 —— 写进记忆库，并处理冲突。

新记忆进来时，要检查和已有记忆有没有矛盾。用户三个月前说「我住北京」，现在说「我搬到上海了」——这两条不能并存，必须更新而不是追加。

③ 注入 —— 下次对话时取出来放进上下文。

新会话开始时，从记忆库里取出相关的几条，拼进系统提示或开头部分。模型看到这些内容，表现出来就是「它还记得我」。

注意第三步的本质：它和 RAG 是同一套机制——检索出相关内容，塞进上下文。区别只在于检索的对象是「关于这个用户的事实」而不是「文档片段」。

难的是哪几步

三步里，第一步和第二步是真正的难点。

提取难在「什么值得记」没有客观标准。

记太多，记忆库很快塞满琐事——用户随口提过的一句玩笑、某次临时的要求，全被当成长期偏好存下来。这些东西之后每次都会被注入上下文，既花钱又干扰判断。

记太少又没有价值，用户感觉不到差别。

实践中比较可行的是限定类别：只记几种明确定义的信息，比如「长期偏好」「身份事实」「明确的禁止项」。不属于这几类的一律不记。宽泛的「记住重要的事」几乎必然跑偏。

冲突难在判断哪条该覆盖哪条。

两条记忆矛盾时，通常按时间取新的。但有例外：用户说「这次先用英文」是临时的，不该覆盖掉「我平时用中文」这条长期偏好。区分「临时」和「长期」是这一步最容易出错的地方。

还有一类隐蔽的问题：记忆是模型提取的，它可能提取错。一条错误记忆一旦存进去，会持续影响之后所有对话，而且很难被发现——用户不知道系统在背后记了什么。

代价

做记忆功能，成本比想象中高，三笔账要算清。

**一、每次对话多出提取的调用。**这是额外的模型开销，用户看不见但你要付钱。

**二、每次对话开头多出注入的内容。**注入的记忆占据窗口，而且每一轮都要重发。记忆越多，这笔固定开销越大。

**三、隐私和合规成本。**这条最容易被低估。你在持续存储用户的个人信息，这直接涉及隐私政策、数据留存期限、用户的删除权。做之前必须让法务过一遍。

产品上还有一条必须做的：**让用户能看到和删除自己的记忆。**一个「AI 记住了关于你的这些事」的页面，允许逐条删除。这既是合规要求，也是信任基础——用户发现系统在背后记了一堆他不知道的事，反弹会很大。

该不该做

给一个务实的建议：先别做通用记忆，从几个明确的字段开始。

很多产品其实不需要一套完整的记忆系统。你要的可能只是记住用户的语言偏好、行业、常用格式——这些完全可以做成显式的设置项，让用户自己填。可预测、可修改、零提取误差、零隐私争议，而且成本几乎为零。

判断标准：如果这个信息用户愿意主动告诉你，就做成设置项，别让 AI 去猜。

真正需要自动记忆的，是那些用户不会主动填、但确实影响体验的东西——工作习惯、常犯的错误、偏好的表达方式。这类才值得上一整套提取和冲突处理。

还有一条边界要划清：**记忆存的是「关于用户的事实」，不是「用户的全部聊天记录」。**后者是日志，属于另一件事，两者的存储方式、保留期限、合规要求都不同，别混在一起做。

这个信息，用户愿意主动告诉你吗？

愿意 不会主动填

做成显式设置项 语言偏好 · 行业 · 常用格式 可预测 · 可修改 · 零提取误差 零隐私争议 · 成本几乎为零 很多产品其实到这里就够了

才值得上自动记忆 工作习惯 · 常犯的错误 · 表达偏好 代价三笔：每次多一次提取调用、 注入内容每轮重发、隐私与合规 必须让用户能看到和删除自己的记忆

还有一条边界：记忆存的是「关于用户的事实」，不是「用户的全部聊天记录」——后者是日志，两者的保留期限和合规要求都不同。

做记忆功能最容易跑偏的一步是提取：宽泛的「记住重要的事」几乎必然记一堆琐事，之后每次都被注入上下文，既花钱又干扰判断。可行的做法是限定类别——只记长期偏好、身份事实、明确的禁止项。

RAG：知识库的三步 记忆注入和 RAG 是同一套机制，只是检索对象不同。

对话压缩 会话内的遗忘和跨会话的记忆，是两个不同的问题。

上下文窗口 注入的记忆也要占额度，记得越多固定开销越大。