记忆机制：对话内与跨对话的记忆

很多人对大模型记忆有一个根深蒂固的误解以为对话多了模型就认识你了就记得你上周说过什么。这个错觉很危险因为它把工程的归工程的、模型的归模型的全搅在了一起。今天我把这件事讲清楚上下文窗口本身是无状态的所谓的记忆从来不是模型的本事而是一套被你显式管理的状态——存起来再注入回去。理解了这一点你才不会在设计对话系统时在错误的方向上越走越远。一、先拆穿一个幻觉模型根本不记得任何事先把话说绝一点上下文窗口是无状态的。你每调一次 Chat Completions 接口传过去的是一份完整的 messages模型基于这份输入算出下一个 token返回回复然后这次计算就结束了。没有后台线程在默默记笔记没有上次聊到哪了这种东西。下一次调用如果你不主动把历史塞回去模型对上一轮一无所知。这跟传统软件里用户登录态存在 session 里是两码事。模型的记忆不是它长出来的能力而是你替它维护、再喂给它的外部状态。区别在于session 是框架帮你管的而对话记忆从消息列表到摘要到长期事实库全得你自己设计。别神化模型模型不会积累经验每次请求都是一张白纸白纸上有没有字取决于你画了什么。别混淆层次上下文工程归你梯度更新归训练两者不互通。推理时的记忆和训练时的权重无关。别假设连续性多轮对话之所以看起来连贯是因为应用层每轮都把旧消息重新拼进请求不是模型在接着说。所以记忆机制的第一个本质命题就是记忆是被显式管理的状态不是模型的隐式能力。下面两类记忆区别只在于这份状态存在哪里、活多久。二、thread-in单次对话内靠一张不断变长的 message 列表thread-in 指的是同一会话内部的记忆。它最简单也最容易理解你维护一个 list每轮把用户消息 append 进去把模型回复也 append 进去下一轮连着整张列表一起发。fromopenaiimportOpenAI clientOpenAI()messages[{role:system,content:你是一个耐心的订单助手}]defchat(user_input:str)-str:messages.append({role:user,content:user_input})respclient.chat.completions.create(modelgpt-4o,messagesmessages)replyresp.choices[0].message.content messages.append({role:assistant,content:reply})returnreply这段代码的全部记忆就在那个messages变量里。它活在进程内存中对话连续是因为列表连续。thread-in 的好处是零成本、零外部依赖原汁原味。坏处也同样直白它是易失的。服务重启、会话超时、用户退出这个 list 说没就没。而且它没法跨会话——你周一和用户的对话周四再开一个 session内存早清空了。存活范围仅限当前连接 / 当前 session关掉就归零。保真度完整保留原文不丢一字适合需要精确回溯的短对话。天花板列表线性增长迟早撞上上下文窗口上限逼你做裁剪或摘要。当你需要这次关掉下次还能接上thread-in 就不够了得把状态搬出内存。这就是 thread-between。三、thread-between跨对话必须把状态搬出进程内存thread-between 解决的是会话与会话之间的记忆。核心动作只有一个词持久化。会话结束时把有价值的事实或摘要写进外部存储关系库、KV、文件、向量库都行下次会话启动时再把它读回来注入到 system 提示或上下文开头。关键在于两次会话彼此不直接共享任何内存。它们只通过中间那个持久化存储间接连接。中间的进程可能重启过十次内存里的临时状态全死了但只要落库的那份事实还在对话就能接上。最常见的落地形态是用户事实库从对话里抽取用户偏好、背景、已确认信息按 user_id 存起来。importjson# 会话结束抽取事实并落库defpersist_facts(user_id:str,facts:list[str]):# 这里用文件举例生产用数据库 / KVwithopen(ffacts/{user_id}.json,w)asf:json.dump(facts,f,ensure_asciiFalse)# 会话启动加载事实并注入defload_system_with_facts(user_id:str)-str:try:withopen(ffacts/{user_id}.json)asf:factsjson.load(f)exceptFileNotFoundError:facts[]base你是一个了解用户背景的助手。iffacts:base已知用户事实\n\n.join(f-{x}forxinfacts)returnbase跨会话存活状态在外部存储跟进程生命周期脱钩重启无碍。按需加载不是把全部历史灌回来而是加载精炼过的事实避免污染当前任务。隔离与权限跨会话就意味着多用户必须按 user_id 隔离否则 A 的记忆跑到 B 的对话里就是事故。但光落库还不够聪明。如果每次都把全部历史原样读回来你迟早又撞上那个窗口上限。于是需要第三招压缩。四、summary memory用压缩换窗口但别迷信压缩summary memory 的思路是超出窗口的旧消息不再原样保留而是交给模型压成一段摘要。近期消息保留原文远期消息变成一段话两者一起注入。这样既保留了发生过什么的脉络又把 token 用量压了下来。defsummarize(old_messages:list[dict])-str:convo\n.join(f{m[role]}:{m[content]}forminold_messages)prompt[{role:system,content:把下面这段对话压缩成不超过 200 字的摘要保留决策、偏好和待办},{role:user,content:convo}]rclient.chat.completions.create(modelgpt-4o-mini,messagesprompt)returnr.choices[0].message.contentdeftrim(messages:list[dict],keep_recent:int6)-list[dict]:iflen(messages)keep_recent:returnmessages old,recentmessages[:-keep_recent],messages[-keep_recent:]summarysummarize(old)return[{role:system,content:f历史摘要{summary}}]recenttrim就是个简单的滑动窗口加摘要保留最近的若干轮把更早的压缩掉。本质上你是在用有损压缩换上下文空间。这里有个必须说清楚的交易摘要会丢细节。模型压缩时它认为不重要的东西就真的没了。如果用户两周前说过一句我对青霉素过敏而那句话恰好落在被摘要掉的区间压缩后变成用户聊过健康问题危险就埋下了。适合长程闲聊、开放式助手脉络比逐字准确更重要。不适合强约束场景医疗、金融、合同摘要丢一字就是事故。补丁摘要 长期事实库双轨摘要管聊过什么脉络事实库管硬约束后者不参与压缩。讲到这三类正经手段消息列表、摘要、长期记忆都齐了。下面专门点几个反例这些都是生产环境里真实踩过的坑。五、反模式把历史无脑塞进 context以及以为模型记得先说最蠢但最常见的反例把所有历史原样无脑塞进 context。有人图省事messages 只增不减跑到几万 token 还在 append。后果是确定的token 爆炸直接撞上下文上限要么报错要么被截断到一半。注意力稀释真相关的当前问题被淹没在几十条无关历史里模型答非所问。成本失控每轮都把几万 token 重复发一遍账单和延迟一起起飞。# 反例永不裁剪的 message 列表messages[{role:system,content:你是助手}]defbad_chat(user_input):messages.append({role:user,content:user_input})# 危险messages 无限增长从不摘要、从不检索respclient.chat.completions.create(modelgpt-4o,messagesmessages)messages.append({role:assistant,content:resp.choices[0].message.content})returnresp.choices[0].message.content第二个反例更隐蔽以为模型记得上次聊过什么。产品经理拍脑袋说让 AI 记住用户开发就以为调一次接口模型就自动有了记忆。实际上每次都是全新请求你不注入它就什么都不知道。把记忆当模型的隐式能力是这类 bug 的根源。正确的心智模型是像管理缓存一样管理记忆。设窗口、定期摘要、按需检索而不是无脑堆积。具体选型时按下面的优先级走thread-in 够用就别上持久化单轮或短会话维护 message 列表最简单。要跨会话就落库事实而非落库全文存精炼过的事实和摘要加载时按需注入。窗口超了就 trim 摘要强约束另存事实库别让摘要替你背医疗、合同这类硬责任的锅。长期记忆用向量检索而不是全量回灌用户量大了按相似度召回相关事实上下文才可控。记忆机制没有银弹但有一条铁律记忆是被显式管理的状态不是模型的隐式能力。你把它当状态来设计——存在哪、活多久、怎么注入、何时丢弃——系统就稳你把它当魔法来期待系统就一定会翻车。