围绕 LLM 的长期记忆Long term memory做架构实验是我最近花时间最多的一块。原因很简单LLM 的上下文窗口再大也只能装下当前这一次会话的内容一旦对话结束、服务重启、或者请求被分配到另一个 session之前的重要信息就全丢了。很多人第一反应是“把历史对话全部塞进 prompt”或者干脆“把上下文窗口调大”但真正做完一轮实验就会发现窗口变大只是推迟了溢出问题并没有解决“该记住什么、怎么更新、怎么快速找到”这三个核心问题。这篇文章把我这轮架构实验里的几种路线、参数取舍和踩坑点整理出来适合正在给 LLM 应用加长期记忆、或者准备做个人知识库和 Agent 记忆系统的开发者参考。我的核心判断是长期记忆不是某个模型功能而是一套需要自己设计的数据读写架构越早按这个思路做后面改造成本越低。1. 先把问题定义清楚长期记忆到底要解决什么1.1 上下文窗口不是记忆只是临时缓冲区LLM 的上下文窗口本质上是模型一次推理时能看到的输入拼接区。窗口里的内容会被完整当作输入参与计算窗口之外的内容模型根本看不见。所以它更像是“工作台”或者“临时缓冲区”而不是真正意义上的记忆。临时缓冲区有两个天然限制一是容量有限。即便窗口从几千 token 扩到几十万 token总会有装满的一天而且窗口越大单次请求的延迟和费用通常也越高。二是生命周期短。对话轮次结束、服务重启、或者你换了主题之后之前的上下文会被清理掉。用户第二天再回来问“我上次让你整理的那份需求”模型大概率什么都想不起来。这就像一个人只有“正在思考的桌面”没有“长期存储的书架”。没有书架桌面上无论堆多少纸换一篇文章就全得清空。1.2 先分清“记忆”和“检索”这两个能力做架构设计之前我建议先分清两组概念。记忆系统可以拆成四个环节写入从对话或文档里提取值得保留的信息。存储把信息按一定结构保存下来。读取在需要时把相关信息找回来。更新当旧信息被新信息覆盖或冲突时做修改、合并、删除。检索只是其中的一个环节。很多人把“向量数据库 相似度查询”直接等同于长期记忆这其实只完成了存储和读取的一部分。写入时提什么、存什么读取时怎么过滤、怎么排序更新时怎么处理重复和冲突才是真正决定记忆质量的地方。1.3 什么场景值得动手做这套实验不是所有 LLM 应用都需要长期记忆。我建议按下面的场景来判断一次性问答、代码生成、翻译不需要给足上下文就行。多轮客服、咨询助手需要短期记忆至少要能记住本会话内的关键信息。个人知识库、AI 助手长期陪伴、Agent 反复执行同一个长期任务需要真正的长期记忆。如果你只是玩票性质做一个 demo可以不那么讲究把历史消息全部塞进上下文也能跑。但如果要做成一个能被反复使用、跨会话连贯的产品长期记忆就是从“能用”到“好用”的分水岭。2. 动手前的架构选型不要一上来就上大模型2.1 最小可运行环境其实不需要多高配置我第一轮实验用的环境很普通本地一台 16G 内存的机器模型通过 API 访问向量数据库用轻量级方案 embedding 模型也选了小体积版本。这里要说清楚整个记忆系统的资源消耗大头通常不在 LLM 本身而在 embedding 计算和向量库的检索性能。如果你打算跑本地模型比如基于 Llama 或 Qwen 系列权重做实验建议先确认显存和内存。模型精度方面常见选择是 fp16 和 bf16占用的显存大约是权重参数量的两倍fp32 会再翻一倍机器配置不够时很容易直接 OOM。关于精度问题我的建议是纯 float32 在本地实验里很少有必要bf16 或者 fp16 已经能覆盖绝大多数任务省下来的显存可以留给更大的 embedding 模型或更长的上下文。2.2 三种常见记忆载体对比我把常见的记忆存储方式分成了三类分别适合不同的实验阶段。记忆载体适合场景优点缺点实现成本纯文本文件/JSON原型验证、日志记录、单用户实验简单、可读、容易调试检索能力弱只能靠关键词最低向量数据库语义检索、跨文档联想、知识库能按语义找相似内容需要设计写入和更新策略中等关系型/图数据库实体关联、多跳查找、结构化记忆关系清晰适合更新和一致性控制结构化成本高写入麻烦较高第一轮实验我强烈建议先用文本文件或 JSON 把流程跑通再替换成向量数据库。不要一开始就纠结 Milvus、Chroma、FAISS、Elasticsearch 选哪个。记忆系统的核心难点在流程不在存储引擎流程没想清楚换再强力的数据库也没用。2.3 数据准备把记忆拆成可检索的单元无论用哪种存储都要先决定“记一条”的最小单位是什么。常见粒度有三种按单轮对话记录实现最简单但信息碎片化严重后续检索容易命中一堆半句话。按主题段落记录先让 LLM 把一段对话里与某主题相关的内容压缩成一条记忆信息密度更高。按实体和属性记录例如“用户张三偏好喜欢简洁回答约束对价格敏感”适合做结构化记忆。我的原则是先做主题段落再做实体属性。主题段落的好处是粒度适中既能保留上下文又不像单轮对话那样细碎。等系统积累了足够数据、发现主题段落之间出现重复和矛盾时再引入实体抽取也不迟。3. 第一轮实验向量检索式长期记忆3.1 写入流程怎么设计向量检索式记忆最简单的结构是这样用户和 LLM 完成一轮对话。把这一轮对话交给一个压缩模型或规则模块提取“值得记住的事实”。对提取结果做 embedding 向量化。把向量和原文一起写入向量数据库。这里最关键的是第二步。直接存原始对话会带来两个问题一是内容冗余一条记忆里塞满了寒暄和无关细节二是后续读取时 token 消耗大因为检索回来的是整段原文。我第一版就是这么做的结果检索回来的基本都是“用户今天测试了系统”“用户说好的谢谢”这类低价值内容。后来改成先让 LLM 做一轮抽取规则是只保留事实性、偏好性、任务进展类信息过滤寒暄、情绪和临时状态写出来的记忆尽量控制在 50 到 100 个 token 内。写入前还应该做一次去重检查。如果新记忆和已有记忆在语义上高度相似优先走更新而不是追加。这个判断可以先用向量相似度粗筛再用 LLM 判断是否合并。3.2 读取流程怎么设计读取流程决定了记忆能不能在最合适的时机被看到。我的推荐顺序是用户发起新问题时先对问题做 embedding。在向量库里做相似度检索取 top-k 条候选记忆。用一个相关性过滤规则清掉相似度过低的条目。把留下的记忆拼接到系统提示词或上下文中。LLM 生成回答。这里有两个参数最容易出问题。一个是 top-k 取值我见过很多人在默认参数下取 20、30 条结果有用的没几条上下文反而被无关记忆撑爆。另一个是相似度阈值阈值设太低会混入噪声设太高又会漏掉弱相关的记忆。建议先在小样本上观察一轮把每条检索结果的相似度分数打印出来再决定阈值。不要一上来就开最大查询并发。向量库看起来只是“查一下”但并发高的时候embedding 服务和数据库查询都是资源大户。先把单条检索的延迟压到可接受范围再逐步加并发。3.3 判断一轮实验是否成功的标准一轮实验跑完不要只看“它能记住之前说过的话”这种模糊结论。我给自己定的验证清单是这样的跨会话命中新开会话后问一个只在前一次会话中出现过的细节看能否正确回答。无关内容不命中问一个和已存记忆无关的问题确认不会因为相似度误匹配而引入旧信息。检索耗时单次记忆检索加拼接的总耗时是否在应用可接受范围内。token 开销平均每次请求因为记忆拼接多消耗了多少 token和直接塞全部历史相比是否明显下降。可维护性记忆内容是否能被人工查看、修改和删除而不是只能黑盒写入。最后一条经常被忽略。如果记忆写坏了没法修那这套系统在长期运行中一定会积累大量垃圾数据。4. 第二轮实验记忆摘要与分层压缩4.1 为什么单靠向量检索不够第一轮实验跑通之后很快会遇到一个新问题当记忆条目越来越多且它们之间存在演进关系时单靠向量检索并不能表达“变化”。举个例子。用户第一天说“我喜欢简洁的回复”第三天说“我现在需要非常详细的技术报告”。两条都是事实语义上并不冲突但都检索出来之后模型不知道该以哪条为准。这就是典型的记忆冲突问题。另一个问题是记忆会过时。用户换了公司、换了项目、改了偏好旧记忆如果不更新反而会变成干扰项。向量检索只能保证“找到语义相近的内容”不能保证“找到的内容仍然有效”。4.2 分层记忆工作记忆、情景记忆、语义记忆为了处理这些问题我参考了认知科学里常见的分层方式把记忆分成三层工作记忆当前会话内已经确认的关键信息比如用户刚刚提供的需求细节不跨会话保留。情景记忆某个时间点发生过的事情比如“昨天上午用户要求把报表改成按周汇总”。语义记忆从情景中抽象出来的稳定偏好和规则比如“用户倾向于按周查看报表”。每次写入时先判断这条信息应该进哪一层。情景记忆可以大量保留负责具体细节语义记忆负责抽象稳定结论数量少但优先级高。到了读取阶段优先使用语义记忆再按需补充情景记忆工作记忆只作用于当前会话。这个设计能明显减少信息噪声。因为很多应用根本不需要把“昨天发生了什么”全部记住只需要记住“由这些事情推导出的规则”。4.3 更新策略什么时候改写旧记忆我踩过的最大坑是记忆只增不改最后变成一个相互矛盾的垃圾桶。更新策略我没有用复杂的规则而是采用了一个相对简单的流程新记忆写入前先做相似度检索找出可能相关的旧记忆。如果相似度超过阈值把新旧记忆一起交给 LLM 判断。判断结果有三种以新为准并删除旧条目、把新旧合并成一条、两者独立保留。每次更新都保留一条简要的变更记录方便回溯。变更记录很重要。因为在调试阶段你经常会遇到“模型没按预期回答”的情况。有变更记录你才能知道它到底是没读到记忆还是读到了过时的记忆。没有变更记录你只能靠猜。5. 第三轮实验结构化记忆与多会话一致性5.1 从自由文本到实体关系第二轮实验之后如果只是单用户个人知识库其实已经够用了。但如果你要做 Agent 或者多用户系统就会发现自由文本式的记忆还有一个短板无法表达复杂的实体关系。比如“张三负责 A 项目A 项目上周延期了原因是依赖 B 团队”这是一段文本。你能检索到“A 项目”也能检索到“B 团队”但模型不一定能理解“项目依赖团队”这条关系链。第三轮实验我尝试了把部分记忆改造成结构化形式实体表和关系表。实体保存属性关系保存连接。这样做的收益是当用户问“B 团队还影响了哪些项目”时系统可以先通过关系拿到候选实体再回到原始记忆中取上下文检索的准确性明显高于纯向量匹配。代价也很明显抽取和维护结构成本高而且 LLM 抽取出的实体关系不一定稳定。我的建议是只对高频核心实体做结构化其他内容继续用自由文本。全量结构化是个无底洞收益边际递减很快。5.2 多用户记忆的隔离与命名空间一旦系统里不止一个用户就要处理记忆隔离。最简单也最稳妥的方案是给每条记忆带上命名空间标识比如 user_id、conversation_id、session_id。所有写入和读取都强制走命名空间过滤。这一步看起来简单但特别容易出 bug。常见问题是写入时忘了存 user_id读取时忘了过滤结果用户 A 的私密对话跑到了用户 B 的上下文里。这类问题一旦上线就是事故级问题。建议在写入接口和读取接口两层都加上校验而不是只在业务层依赖开发者的自觉。5.3 并发写入与版本控制多个会话同时写同一条用户记忆时会出现互相覆盖的问题。用户一边在网页端说“我不要 weekly 报告了”一边在 API 端说“weekly 报告改为周二发送”两条写入如果并发执行最后落库的版本取决于谁后完成逻辑上可能完全错乱。处理方式不复杂给每条记忆增加版本号或更新时间戳写入选主或合并冲突时先比较时间或优先级必要时把两条都保留并标记冲突让 LLM 在读取时进行裁决。这里不要追求强数据库事务记忆系统对偶尔的不一致是能容忍的更关键的是不要静默丢数据。6. 参数调优与效果验证6.1 最影响结果的五个参数一轮实验做完真正值得反复调优的参数其实就几个。参数影响调优建议记忆条目标题/摘要长度影响 token 开销和检索精度先控制在 50 到 100 token再根据场景调整分块大小影响语义粒度单条记忆太碎会噪声大太大则检索不精准top-k影响上下文清洗度从 3 到 5 开始不要默认直接拉满相似度阈值影响召回率和误报率用小样本打印分数分布后决定记忆更新频率影响过时率与写入成本按重要程度决定不要每条都更新修改任何一个参数前先做一次小样本对比。我的习惯是准备一组包含 30 到 50 个问题的测试集分布覆盖跨会话命中、无关信息过滤、冲突信息更新三类场景每次调整后统一跑一遍。6.2 怎么判断记忆“好用”我给这些实验项目写过一个粗糙的评分表每项按 1 到 5 打分命中率该记住的信息在后续会话里有多少次被正确找回。误用率不该被使用的旧信息有多少次被拼进上下文并影响了回答。更新及时性用户改口之后系统多久开始使用新信息。资源开销每次请求的记忆检索耗时和 token 增量是否稳定。可解释性出现错误回答时能不能快速定位到是哪条记忆导致了错误。不用追求每一项都满分。不同的应用优先级完全不同个人知识库更看重命中率和可解释性客服助手更看重误用率和更新及时性。6.3 从单机实验到框架化部署当实验变得稳定之后再考虑把它整理成一套可复用的组件。这里我特别想强调一个大家常误解的点“LLM 框架”不是长期记忆的前提。像 LangChain、LlamaIndex 这类编排框架提供了记忆相关的封装但它们主要解决的是调用链路问题不是记忆质量本身。我自己更倾向于先把记忆逻辑写成独立模块接口保持简单只暴露三个方法写入、查询、更新。这样无论底层换不换框架记忆系统都可以独立演进。框架帮不了你的部分比如“用户改口之后下一次回答要立刻使用新偏好”还是要靠自己在写入和读取环节做判断。7. 常见问题排查顺序7.1 检索不到记忆先看输入再看存储现象是用户明明之前说过某件事跨会话提问却完全没想起来。排查顺序应该是先确认记忆是否真的写入了查数据库里的记录数和最近写入时间。再确认写入时的输入是什么检查抽取模块是否把关键信息过滤掉了。检查查询问题与记忆的 embedding 相似度分数看是检索不到还是被阈值过滤掉了。最后检查命名空间和过滤条件是不是查到了但被 user_id 等条件挡掉了。我遇到过的最多情况是第 2 种抽取规则写太严格把“用户提到城市是杭州”这种关键信息当成噪声过滤了。也有不少情况是第 4 种查询条件少了过滤字段反而什么都查不到。7.2 记住旧信息但不更新问题多半在写入侧现象是用户在对话里明确改了偏好但后续回答还是按旧偏好执行。重点检查三点新信息是否触发了写入流程有时改写对话没有被判定为“值得记忆”。更新策略里的相似度阈值是不是设太高导致新旧记忆没有关联上。检索读取时是不是只取了旧记忆没有把新记忆同时带入上下文。这里有一个小技巧当用户明确否定之前的信息时可以在抽取规则里给“否定句”更高优先级强制触发更新流程而不是等相似度匹配。7.3 记忆膨胀导致响应变慢现象是记忆条目越来越多单次请求拼接的 token 越来越大响应延迟明显上升。处理顺序检查每次请求实际读取了多少条记忆是否超过预期 top-k。看有没有大量低价值记忆长期堆积比如“用户今天说了谢谢”这类信息。给记忆增加时间衰减或访问频率权重降低过时条目的读取优先级。定期做一轮归档或压缩把不活跃的细节记忆合并成摘要只保留核心结论。7.4 本地部署资源占用过高如果使用本地模型跑这套系统资源占用过高通常有三个瓶颈本地 LLM 权重本身占显存fp16/bf16 下 7B 模型大约需要 14G 显存左右这还没算推理时的中间激活值。embedding 模型虽然小但并发请求多时 CPU 占用会很高。向量库随着数据量增长内存占用会持续上升。排查时用资源监控工具看是哪个进程在涨不要凭感觉猜。如果是向量库内存暴涨先降低向量维度或清理历史版本如果是 embedding 并发问题就先加队列限流而不是盲目加机器。8. 实验结论与我的最终建议这轮实验做下来我最大的感受是长期记忆系统的复杂度不来自某个单一技术而是来自数据治理。你要不断回答“什么值得记”“什么时候更新”“怎么避免互相矛盾”“怎么让模型在合适的时机读到合适的信息”。每一个问题单独看都不难连在一起就成了架构设计。给不同阶段的读者一个直接的结论如果你只是做学习验证用“文本文件 手动记录”就能理解记忆流程没必要先上向量库。如果要做个人知识库直接按“主题段落 向量检索 摘要压缩”这套组合做性价比最高。如果做 Agent 或生产级应用必须补上更新策略、命名空间隔离、版本记录和可解释性日志而不是只堆检索能力。如果发现记忆经常互相矛盾先别急着换向量数据库先检查你的写入和更新流程。我个人更建议先把单条记忆的写入、更新、读取链路跑稳再考虑批量导入、并发、多用户这些扩展问题。技术方案可以不断换但流程设计一旦乱掉后面所有实验都是在错误的地基上垒墙。真正落地时最该盯住的不是功能列表而是输入抽取、更新冲突和失败重试这几条容易被低估的细节。