这道题其实是在问,怎么让大模型记住更长时间跨度里的事情,而不是每次对话都像失忆一样。本质是突破固定上下文窗口的限制。我一般从三个层面来思考这个问题:架构层、外部记忆模块、还有[[检索增强]]。
先说架构层,最直接的方法是扩展上下文窗口本身。像现在的 Ring Attention 或者 StreamingLLM,能把有效窗口从4K推到1M以上。但这里有个前提,训练数据必须够长,不然模型学不会长距离依赖。推理时还要优化 [[KV Cache]],不然内存会爆。另一种思路是分层记忆架构,比如MemGPT,它模拟操作系统的内存管理:主上下文就放当前最相关的信息,像内存一样有限,外部记忆像磁盘,需要的时候通过[[函数调用]]去读写。这样模型可以自主决定什么时候存档、什么时候回忆。
再一个层面是外部记忆模块,说白了就是给模型配一个外挂硬盘。我重点说两个方案。一个是Memory Bank,按实体或者话题把对话历史聚类成摘要向量,适合多轮对话和角色扮演,比如客服场景里,用户反复问同一个订单的退款进度,模型得记住之前处理到哪一步了。另一个是[[向量数据库]]加时间衰减,用 [[Dense Retrieval]] 检索,再结合遗忘曲线给越久远的信息降权,适合持续学习场景。这里有个坑:写入策略不能全量存,否则存不下,成本也高。我会让模型自己生成摘要或者事件三元组,比如“用户退款,金额100元,状态已提交”,把信息压缩后再存。检索时用[[混合检索]],向量相似度加时间近邻再加重要性评分,三层过滤。
说到检索增强,其实跟RAG很像,但记忆检索更强调时序性和因果关联。比如在[[Agent]]任务里,模型要持续追踪一个目标,像帮用户订机票,中间可能穿插了查天气、问酒店,模型得把对话状态链保持住。这时候我会用记忆树,层次化组织信息,从细节到抽象,支持跨粒度检索。举个例子,用户说“上次那个航班的行李额是多少”,模型能从记忆树里找到具体航班号对应的行李政策,而不是从头再问。
真正落地时,这些方案很少单独用,往往是架构改进加外部记忆一起上。 比如客服场景,我会优先用结构化记忆,因为事实准确性要求高;创作场景则用摘要式记忆,更看重连贯性。但不管哪种方案,都有几个落地风险要关注。一是延迟,异步写入加缓存热点记忆能缓解;二是成本,分层存储,热数据放Redis,冷数据放ES;三是准确性,检索完一定要[[重排序]],设个置信度阈值,低于0.6的直接丢掉,不然召回质量会崩。
其实还有一个方向我没细说,就是怎么让记忆自更新。比如用户改过一次订单信息,模型得把旧记忆覆盖掉,而不是同时保留两个版本。这涉及到一致性维护,我通常会定期触发记忆反思,让模型自己整合碎片化信息,有点像人睡觉时整理记忆。
所以整体上,我更倾向于把记忆机制看成一套分层系统,而不是某个单一技术。架构解决容量,外部模块解决持久化,检索解决效率,三者缺一不可。如果面试官让我选一个优先做,我会先搞定检索,因为检索质量直接决定了记忆能不能用起来。