1. 从“用户记忆”到“知识库”为什么你的Agent总是“记不住事”做过Agent开发的人大概率都经历过这个场景用户第一轮说了“我住在杭州平时喜欢喝美式”第三轮再问“帮我推荐个附近的咖啡店”Agent一脸茫然地反问“请问您在哪个城市”。这不是模型不够聪明而是它压根没有“记住”这件事的机制。大模型本身是无状态的每次调用对它来说都是第一次见面所谓“用户记忆”和“知识库”本质上就是我们在模型外面给它搭的一套“外挂大脑”。这套外挂大脑要解决两个层面的问题。第一个层面是用户记忆也就是“这个用户是谁、他之前说过什么、他的偏好是什么”属于个性化、动态变化、跟具体用户强绑定的信息。第二个层面是知识库也就是“这个领域的专业知识、产品文档、FAQ、操作手册”属于相对静态、面向所有用户共享、需要精准检索的信息。很多人把这两个混为一谈结果做出来的Agent要么把用户隐私塞进公共知识库要么把产品文档当成用户记忆反复注入上下文最后token烧得飞快效果还一塌糊涂。我见过太多团队在这件事上踩坑。有个做企业客服Agent的朋友一开始图省事把用户的历史对话直接拼到prompt里前几轮还行聊到二十轮以后上下文直接爆炸模型开始胡言乱语成本还翻了好几倍。后来他们拆成了“短期记忆用滑动窗口摘要、长期记忆用向量库、知识库单独走RAG”三层结构问题才解决。所以这篇文章我想把“用户记忆”和“知识库”这两件事彻底拆开讲清楚从架构设计、技术选型、实操落地到踩坑排查给一套可以直接抄作业的方案。不管你是刚接触Agent开发的新手还是已经在做企业级知识库的老手应该都能从里面找到能用的东西。2. 用户记忆与知识库的架构设计先想清楚“存什么”再谈“怎么存”2.1 用户记忆和知识库的本质区别先把概念理清楚不然后面全是坑。用户记忆和知识库虽然都叫“记忆”但它们的生命周期、访问频率、数据结构、检索方式完全不同。用户记忆的核心特征是“跟人走”。它记录的是某个具体用户的画像、偏好、历史交互、当前任务状态。比如用户说“我下周要去北京出差”这条信息只对当前用户有意义对其他用户毫无价值。它的数据量通常不大但更新频繁而且对时效性要求高——用户昨天说喜欢美式今天说改喝拿铁了你得能覆盖掉旧偏好。知识库的核心特征是“跟领域走”。它记录的是产品文档、行业规范、操作流程、FAQ这些公共知识。它面向所有用户更新频率低但数据量大检索时要求高召回和高精度。用户问“你们的退货政策是什么”不管谁来问答案都一样。我习惯用一个类比用户记忆像是你私人助理的笔记本记着你的口味、你的日程、你上次聊到哪了知识库像是公司前台那本厚厚的员工手册谁来了都能翻。两者不能混着放混着放的结果就是助理拿着员工手册跟你聊私事尴尬又低效。维度用户记忆知识库归属单个用户全体用户/领域共享生命周期动态、频繁更新相对静态、低频更新数据量小KB级大MB到GB级检索方式精确匹配时间衰减向量检索关键词混合典型存储Redis、关系库、向量库向量库、全文索引时效要求高需覆盖旧值低版本化管理2.2 三层记忆架构的设计思路基于上面的区别我一般推荐把Agent的记忆拆成三层这也是目前业界比较主流的做法。第一层是短期记忆Working Memory。它保存当前会话的最近N轮对话直接拼进prompt。N一般取5到10轮具体看你的模型上下文窗口和成本预算。这一层不需要任何检索就是简单的队列先进先出。它的作用是让Agent在单轮对话里保持连贯比如用户说“它多少钱”Agent得知道“它”指的是上一轮提到的那个产品。第二层是长期记忆Long-term Memory。它保存用户跨会话的偏好、事实、历史摘要。这一层必须走向量检索因为用户下次来的时候你得从几百条记忆里捞出跟当前问题最相关的那几条。比如用户三个月前说过“我对花生过敏”今天问“推荐个零食”你得能把这条捞出来。长期记忆的关键是“写入策略”和“检索策略”后面会细讲。第三层是知识库Knowledge Base。它保存领域知识走RAG流程。用户提问时先从知识库检索相关文档片段拼进prompt让模型基于这些片段回答。这一层的核心是“切分策略”和“检索质量”也是RAG最容易翻车的地方。这三层不是必须全上小项目可以只做短期记忆知识库但只要你做的是面向C端的Agent长期记忆迟早要补上因为用户会期待你“记得他”。2.3 为什么不能把用户记忆塞进知识库我见过最偷懒的做法是把用户的所有对话都写进知识库然后靠元数据过滤“user_id”来区分。这个方案在小规模下能跑但很快就会崩。第一个问题是检索污染。向量检索是按语义相似度排序的用户A问“退货政策”检索出来的可能是用户B三个月前问过的类似问题因为语义太像了。你靠user_id过滤能挡掉一部分但过滤之后召回率会骤降因为本来该用户自己的记忆就不多过滤完可能一条都不剩。第二个问题是更新困难。用户偏好变了你得找到旧的那条记忆删掉或覆盖。知识库的向量是批量写入的单条更新很麻烦而且向量库一般不支持高效的按条件更新。第三个问题是成本。知识库的文档切分、embedding、存储都是按量计费的把用户对话这种高频写入的数据塞进去成本会失控。用户记忆用Redis或者关系库存成本能低一个数量级。所以我的建议很明确用户记忆和知识库物理隔离各用各的存储和检索链路。这不是过度设计是踩过坑之后的血泪教训。3. 用户记忆的落地实操从写入策略到检索排序3.1 什么信息值得被“记住”不是所有对话都值得存进长期记忆。如果你把用户每句话都存下来检索的时候全是噪音。我一般用一套“记忆提取”的规则来筛选。值得记的用户的稳定偏好“我喜欢靠窗座位”、重要事实“我有个三岁的女儿”、长期目标“我在准备考研”、明确的纠正“我不叫小明我叫小华”。这些信息的共同点是“跨会话仍然有效”。不值得记的一次性的指令“帮我查下明天的天气”、闲聊“哈哈今天天气不错”、已经完成的任务状态“帮我订个外卖”。这些信息要么时效性太短要么对后续对话没帮助。实操上我会在每轮对话结束后用一个轻量模型比如小参数量的模型做一次“记忆提取”让它输出结构化的JSON比如{ should_remember: true, memory_type: preference, content: 用户喜欢喝美式咖啡不加糖, confidence: 0.92, expire_at: null }这个提取步骤很关键它决定了记忆库的质量。我试过直接存原始对话检索出来的全是无关内容换成结构化提取之后召回的相关性明显提升。提取用的模型不需要太强小模型足够因为任务很简单就是判断“这句话值不值得记”和“记成什么类型”。3.2 记忆的写入去重、覆盖与时间衰减记忆写入最大的坑是“重复”和“冲突”。用户可能在不同会话里反复说“我喜欢美式”如果你每次都存一条检索的时候会返回一堆重复内容浪费上下文窗口。我的做法是写入前先做相似度检查。新记忆生成后先拿它的embedding去记忆库里查一下如果跟已有记忆的相似度超过0.9就不新增而是更新旧记忆的时间戳。如果相似度在0.7到0.9之间说明是相关但不同的信息可以合并成一条更完整的记忆。冲突处理更麻烦。用户先说“我喜欢美式”后来说“我改喝拿铁了”。这两条记忆语义上不冲突但事实上后者覆盖前者。我的处理方式是给记忆加一个“时效权重”检索时按时间衰减排序新的记忆权重更高。同时在提取阶段让模型判断“这条新信息是否推翻了旧信息”如果是就把旧记忆标记为“已失效”检索时过滤掉。时间衰减的公式我一般用指数衰减weight base_weight * exp(-lambda * days_since_update)lambda取0.01到0.05之间具体看你的场景。如果是长期偏好lambda取小一点衰减慢如果是短期状态lambda取大一点快速淘汰。这个参数没有标准答案得根据你的业务数据调。3.3 记忆的检索不只是向量相似度很多人做记忆检索直接拿用户当前问题去向量库查top-k这是不够的。记忆检索要考虑三个因素语义相关性、时间新鲜度、记忆类型匹配。语义相关性就是常规的向量相似度。时间新鲜度用上面的衰减公式算。记忆类型匹配是指如果当前问题是“推荐个餐厅”那“用户喜欢美式咖啡”这条记忆的相关性就低而“用户不吃辣”这条相关性就高。这个匹配可以通过给记忆打标签、检索时按标签过滤来实现。我一般用混合排序final_score alpha * semantic_score beta * time_decay gamma * type_matchalpha、beta、gamma三个权重根据场景调。客服场景可能更看重语义相关性alpha取0.6个人助理场景更看重时间新鲜度beta取0.5。这个排序逻辑写在应用层不依赖向量库本身灵活度更高。还有一个细节检索出来的记忆要控制数量。一般top-3到top-5就够了太多会稀释prompt的注意力。我试过塞10条记忆进去模型反而抓不住重点回答变得泛泛。3条精准的记忆比10条模糊的记忆有用得多。3.4 一个可直接复用的记忆模块代码结构下面是我常用的记忆模块结构用Python伪代码示意你可以按自己的技术栈翻译。class UserMemory: def __init__(self, vector_store, kv_store, extractor_llm): self.vector_store vector_store # 存记忆向量 self.kv_store kv_store # 存记忆原文和元数据 self.extractor extractor_llm # 记忆提取模型 def extract(self, dialogue_turn): # 用模型提取值得记的信息 result self.extractor.invoke(dialogue_turn) return result # 结构化JSON def write(self, user_id, memory): # 去重检查 similar self.vector_store.search(memory.embedding, top_k1) if similar and similar[0].score 0.9: self.kv_store.update_timestamp(similar[0].id) return # 冲突检查 if memory.is_override: self.kv_store.mark_invalid(memory.override_target) # 写入 mem_id self.kv_store.insert(user_id, memory) self.vector_store.insert(mem_id, memory.embedding) def retrieve(self, user_id, query, top_k3): query_vec embed(query) candidates self.vector_store.search(query_vec, top_k20) # 过滤该用户的记忆 candidates [c for c in candidates if c.user_id user_id] # 混合排序 scored [] for c in candidates: score (0.6 * c.semantic_score 0.3 * time_decay(c.updated_at) 0.1 * type_match(c.type, query)) scored.append((score, c)) scored.sort(reverseTrue) return [c for _, c in scored[:top_k]]这个结构的好处是职责清晰提取归提取写入归写入检索归检索。每一层都可以单独替换比如你想换个更强的提取模型或者换个向量库都不影响其他部分。4. 知识库与RAG实战切分、检索、重排的完整链路4.1 知识库构建的第一步文档切分策略RAG效果好不好七成看切分。我见过太多人直接把整篇PDF丢进去embedding然后抱怨检索不准。文档切分不是简单的按字数切要考虑语义完整性。按语义切分是首选。Markdown文档按标题层级切每个二级标题下的内容作为一个chunkPDF文档先做版面分析识别出段落、表格、图片再按段落切。切分的粒度我一般控制在300到500字太短了语义不完整太长了检索精度下降。重叠切分是必要的补充。相邻chunk之间保留10%到20%的重叠防止一个完整的语义被切断。比如一段话讲“退货流程分三步”切分点正好落在第二步中间没有重叠的话检索“退货流程”可能只召回后半段信息就不完整了。特殊内容特殊处理。表格不要按行切要整表保留因为表格的语义在整体结构里代码块要整块保留按行切会破坏语法图片要么做OCR提取文字要么用多模态模型生成描述再embedding。热词里有人问“rag知识库能存储图片嘛”答案是能但不是直接存图片而是存图片的描述或OCR文本检索时匹配文本返回时把图片一起展示。切分方式适用场景优点缺点固定长度纯文本、无结构简单快速语义易断裂按标题层级Markdown、HTML语义完整依赖文档结构按段落PDF、Word平衡需版面分析语义切分高质量要求效果最好需额外模型4.2 向量检索的瓶颈与优化向量检索不是银弹它有几个明显的瓶颈。第一个是召回率问题用户问“怎么退款”文档里写的是“如何申请退货”语义相近但用词不同纯向量检索可能召回不到。第二个是精度问题向量检索返回的top-k里可能有一半是语义相似但实际无关的内容。第三个是长文档问题一个chunk太长embedding会丢失细节太短又缺乏上下文。我的优化方案是混合检索向量检索关键词检索BM25两路结果合并后重排。向量检索负责语义匹配关键词检索负责精确匹配两者互补。实测下来混合检索的召回率比纯向量检索能提升20%到30%。具体做法是先用向量检索取top-20再用BM25取top-20两路结果去重后合并然后用一个重排模型Rerank对合并后的结果重新打分排序取top-5送给大模型。重排模型我一般用开源的bge-reranker或者cohere的rerank接口效果比单纯按向量相似度排序好很多。还有一个容易被忽略的点是查询改写。用户的问题往往很短很模糊比如“那个怎么弄”直接拿去检索效果很差。我会在检索前加一步查询改写用模型把用户问题扩展成更完整的检索query比如把“那个怎么弄”改写成“退货流程怎么操作”。这一步能显著提升召回率尤其是多轮对话场景。4.3 RAG的完整链路与参数配置把上面的东西串起来一个完整的RAG链路是这样的文档入库文档解析 → 切分 → 生成embedding → 存入向量库查询处理用户提问 → 查询改写 → 生成query embedding检索向量检索top-20 BM25检索top-20 → 合并去重重排Rerank模型对候选重排 → 取top-5生成把top-5片段拼进prompt → 大模型生成回答引用返回答案时附带来源片段方便用户核实每一步都有参数要调。切分粒度300到500字重叠10%到20%向量检索top-20BM25 top-20重排后top-5prompt里明确要求“只基于提供的片段回答不知道就说不知道”。这些参数不是拍脑袋定的是我在不同项目里反复试出来的经验值你可以作为起点再根据自己数据微调。提示prompt里一定要加“如果提供的片段中没有相关信息请直接说不知道不要编造”。这一句话能挡掉大部分幻觉问题比任何后处理都管用。4.4 知识库的版本管理与更新知识库不是建完就完事了文档会更新产品会迭代。我一般用“版本化增量更新”的策略。每次文档更新不直接覆盖旧向量而是打一个新版本号检索时默认只查最新版本。旧版本保留一段时间方便回滚和对比。增量更新是指只对变化的文档重新切分和embedding没变的文档复用旧向量这样能省大量计算。元数据里我会存文档来源、版本号、更新时间、所属分类。检索时可以按分类过滤比如用户问“技术问题”就只在技术文档里检索缩小范围提升精度。这个过滤条件在向量检索之后做不影响召回但能提升精度。5. 常见问题与排查技巧实录5.1 检索不准的排查思路检索不准是最常见的问题排查要按链路一步步来。先看切分把检索到的chunk打印出来看内容是否完整、是否包含答案。如果chunk本身就不含答案那是切分问题调整切分粒度或重叠比例。再看embedding把用户query和chunk的向量相似度打出来如果相似度很低但人眼判断应该相关那是embedding模型不适合你的领域换个领域微调过的模型。最后看重排如果召回里有正确chunk但排序靠后那是重排模型的问题换个更强的rerank模型或者调整权重。我整理了一个速查表现象可能原因排查方法解决召回为空切分太碎/embedding不匹配打印chunk和相似度调整切分/换模型召回相关但排序低重排模型弱看重排前后排序换rerank模型答案含幻觉prompt没约束检查prompt加“不知道就说不知道”多轮对话检索差query没改写看原始query加查询改写表格/图片检索不到未特殊处理检查入库内容表格整表存/图片OCR5.2 用户记忆与知识库冲突怎么办有时候用户记忆和知识库会冲突。比如知识库说“退货需要7天”但用户记忆里记着“这个用户是VIP退货期30天”。这时候Agent该听谁的我的原则是用户记忆优先于知识库因为用户记忆是个性化的、更具体的。但要在prompt里明确告诉模型这个优先级否则模型可能随机选一个。具体做法是在prompt里把用户记忆放在知识库片段之前并标注“以下是该用户的个性化信息优先级高于通用知识”。还有一种冲突是用户记忆本身矛盾比如用户先说“我喜欢美式”后说“我讨厌咖啡”。这种要在写入阶段就处理掉用时间衰减和覆盖机制保证只保留最新有效的记忆。5.3 并发与性能的实战经验热词里有人问“ai agent 怎么扛并发”这是个好问题。Agent的并发瓶颈通常不在模型推理而在检索和记忆读写。向量检索的并发能力取决于你用的向量库。Milvus、Qdrant这些支持水平扩展单机能扛几千QPSFAISS是内存索引并发高但不好扩展。我的建议是如果QPS在100以内单机向量库够用超过100考虑分布式向量库或者加缓存。缓存的策略是对高频query的检索结果做缓存比如“退货政策”这种问题答案基本不变缓存5分钟能挡掉大量重复检索。用户记忆的读写用Redis单机几万QPS没问题。真正要小心的是embedding计算每次检索都要算query向量这个可以用小模型或者缓存query embedding来优化。还有一个坑是批量写入。知识库初始化时如果一条条写入向量库速度极慢。要用批量接口一次写几百条速度能快几十倍。我试过用单条写入初始化一个10万chunk的知识库跑了几个小时换成批量写入几分钟就搞定了。5.4 几个我踩过的坑第一个坑是embedding模型选型。一开始我用的是通用embedding模型中文效果一般。后来换成中文优化的模型检索准确率明显提升。选embedding模型一定要在你的领域数据上测别看榜单榜单和实际场景差距很大。第二个坑是chunk太大。我一开始觉得chunk大一点信息全结果检索精度很差因为一个chunk里混了好几个主题embedding被平均了。后来把chunk缩小到300字左右精度立马上来了。第三个坑是忽略元数据。早期我没存文档来源和分类检索出来没法过滤也没法给用户展示引用来源。后来补上元数据既能过滤又能引用体验好很多。第四个坑是记忆提取太频繁。我一开始每轮对话都提取记忆成本高且噪音多。后来改成每3到5轮提取一次或者检测到用户说了“记住”“我喜欢”这类关键词时才提取效果好很多。6. 工具选型与部署建议6.1 向量库怎么选向量库的选择取决于你的规模和部署环境。小规模、单机、快速验证用FAISS或者Chroma装个包就能跑零运维。中等规模、需要持久化和过滤用Qdrant或者Milvus支持元数据过滤和水平扩展。大规模、企业级、要高可用用Milvus集群或者云厂商的向量服务。国内企业私有化部署的话Milvus和Qdrant都是不错的选择社区活跃文档齐全。如果团队规模小不想运维可以考虑云服务但要注意数据合规。6.2 大模型与embedding模型的选择生成模型和embedding模型要分开选。生成模型负责最终回答要求理解能力强、指令遵循好embedding模型负责检索要求语义表征准、领域适配好。embedding模型我一般用bge系列或者m3e系列中文效果好开源可私有化。生成模型看你的预算和合规要求开源的可选Qwen、Llama系列闭源的看各家API。如果做私有化部署开源模型是首选但要注意显存和推理速度的平衡。6.3 一个最小可用的部署架构如果你要从零搭一套我建议的最小架构是文档解析用Python的unstructured库切分自己写规则embedding用bge-small向量库用Qdrant生成模型用Qwen或者API记忆存储用Redis编排用LangChain或者自己写。这套架构单机就能跑成本低够用。等规模上来了再把向量库换成Milvus集群embedding换成更大的模型加Rerank加缓存。不要一上来就上最复杂的架构先用最小可用版本跑通链路再逐步优化。7. 写在最后的一些个人体会做用户记忆和知识库这两年我最大的体会是这两件事的难点都不在技术而在“取舍”。什么信息值得记、什么信息该忘、检索几条合适、切分多大粒度这些都没有标准答案得根据你的业务场景和数据特点去调。我见过太多团队追求“最先进”的方案结果链路太复杂出了问题都不知道从哪排查。我的建议是先用最简单的方案跑通把链路打通把数据跑起来然后根据实际bad case去优化。RAG的优化是个迭代过程不是一次设计就能完美的。每次遇到检索不准就按“切分→embedding→检索→重排→生成”的顺序排查一遍慢慢你就知道你的数据适合什么参数了。还有一点用户记忆和知识库的边界要清晰。我见过把用户隐私写进公共知识库的也见过把产品文档塞进用户记忆的最后都是灾难。物理隔离各管各的这是底线。最后分享一个小技巧在prompt里给模型一个“记忆使用说明”告诉它哪些是用户个性化信息、哪些是通用知识、冲突时听谁的。这个说明不用长两三句话就够但效果立竿见影。我试过不加说明和加说明的对比加了之后回答的准确率和一致性明显提升。这个细节很多教程不会讲但实际用起来很管用。 Agent记忆与知识库架构设计：用户记忆、RAG检索与工程落地实战
1. 从“用户记忆”到“知识库”为什么你的Agent总是“记不住事”做过Agent开发的人大概率都经历过这个场景用户第一轮说了“我住在杭州平时喜欢喝美式”第三轮再问“帮我推荐个附近的咖啡店”Agent一脸茫然地反问“请问您在哪个城市”。这不是模型不够聪明而是它压根没有“记住”这件事的机制。大模型本身是无状态的每次调用对它来说都是第一次见面所谓“用户记忆”和“知识库”本质上就是我们在模型外面给它搭的一套“外挂大脑”。这套外挂大脑要解决两个层面的问题。第一个层面是用户记忆也就是“这个用户是谁、他之前说过什么、他的偏好是什么”属于个性化、动态变化、跟具体用户强绑定的信息。第二个层面是知识库也就是“这个领域的专业知识、产品文档、FAQ、操作手册”属于相对静态、面向所有用户共享、需要精准检索的信息。很多人把这两个混为一谈结果做出来的Agent要么把用户隐私塞进公共知识库要么把产品文档当成用户记忆反复注入上下文最后token烧得飞快效果还一塌糊涂。我见过太多团队在这件事上踩坑。有个做企业客服Agent的朋友一开始图省事把用户的历史对话直接拼到prompt里前几轮还行聊到二十轮以后上下文直接爆炸模型开始胡言乱语成本还翻了好几倍。后来他们拆成了“短期记忆用滑动窗口摘要、长期记忆用向量库、知识库单独走RAG”三层结构问题才解决。所以这篇文章我想把“用户记忆”和“知识库”这两件事彻底拆开讲清楚从架构设计、技术选型、实操落地到踩坑排查给一套可以直接抄作业的方案。不管你是刚接触Agent开发的新手还是已经在做企业级知识库的老手应该都能从里面找到能用的东西。2. 用户记忆与知识库的架构设计先想清楚“存什么”再谈“怎么存”2.1 用户记忆和知识库的本质区别先把概念理清楚不然后面全是坑。用户记忆和知识库虽然都叫“记忆”但它们的生命周期、访问频率、数据结构、检索方式完全不同。用户记忆的核心特征是“跟人走”。它记录的是某个具体用户的画像、偏好、历史交互、当前任务状态。比如用户说“我下周要去北京出差”这条信息只对当前用户有意义对其他用户毫无价值。它的数据量通常不大但更新频繁而且对时效性要求高——用户昨天说喜欢美式今天说改喝拿铁了你得能覆盖掉旧偏好。知识库的核心特征是“跟领域走”。它记录的是产品文档、行业规范、操作流程、FAQ这些公共知识。它面向所有用户更新频率低但数据量大检索时要求高召回和高精度。用户问“你们的退货政策是什么”不管谁来问答案都一样。我习惯用一个类比用户记忆像是你私人助理的笔记本记着你的口味、你的日程、你上次聊到哪了知识库像是公司前台那本厚厚的员工手册谁来了都能翻。两者不能混着放混着放的结果就是助理拿着员工手册跟你聊私事尴尬又低效。维度用户记忆知识库归属单个用户全体用户/领域共享生命周期动态、频繁更新相对静态、低频更新数据量小KB级大MB到GB级检索方式精确匹配时间衰减向量检索关键词混合典型存储Redis、关系库、向量库向量库、全文索引时效要求高需覆盖旧值低版本化管理2.2 三层记忆架构的设计思路基于上面的区别我一般推荐把Agent的记忆拆成三层这也是目前业界比较主流的做法。第一层是短期记忆Working Memory。它保存当前会话的最近N轮对话直接拼进prompt。N一般取5到10轮具体看你的模型上下文窗口和成本预算。这一层不需要任何检索就是简单的队列先进先出。它的作用是让Agent在单轮对话里保持连贯比如用户说“它多少钱”Agent得知道“它”指的是上一轮提到的那个产品。第二层是长期记忆Long-term Memory。它保存用户跨会话的偏好、事实、历史摘要。这一层必须走向量检索因为用户下次来的时候你得从几百条记忆里捞出跟当前问题最相关的那几条。比如用户三个月前说过“我对花生过敏”今天问“推荐个零食”你得能把这条捞出来。长期记忆的关键是“写入策略”和“检索策略”后面会细讲。第三层是知识库Knowledge Base。它保存领域知识走RAG流程。用户提问时先从知识库检索相关文档片段拼进prompt让模型基于这些片段回答。这一层的核心是“切分策略”和“检索质量”也是RAG最容易翻车的地方。这三层不是必须全上小项目可以只做短期记忆知识库但只要你做的是面向C端的Agent长期记忆迟早要补上因为用户会期待你“记得他”。2.3 为什么不能把用户记忆塞进知识库我见过最偷懒的做法是把用户的所有对话都写进知识库然后靠元数据过滤“user_id”来区分。这个方案在小规模下能跑但很快就会崩。第一个问题是检索污染。向量检索是按语义相似度排序的用户A问“退货政策”检索出来的可能是用户B三个月前问过的类似问题因为语义太像了。你靠user_id过滤能挡掉一部分但过滤之后召回率会骤降因为本来该用户自己的记忆就不多过滤完可能一条都不剩。第二个问题是更新困难。用户偏好变了你得找到旧的那条记忆删掉或覆盖。知识库的向量是批量写入的单条更新很麻烦而且向量库一般不支持高效的按条件更新。第三个问题是成本。知识库的文档切分、embedding、存储都是按量计费的把用户对话这种高频写入的数据塞进去成本会失控。用户记忆用Redis或者关系库存成本能低一个数量级。所以我的建议很明确用户记忆和知识库物理隔离各用各的存储和检索链路。这不是过度设计是踩过坑之后的血泪教训。3. 用户记忆的落地实操从写入策略到检索排序3.1 什么信息值得被“记住”不是所有对话都值得存进长期记忆。如果你把用户每句话都存下来检索的时候全是噪音。我一般用一套“记忆提取”的规则来筛选。值得记的用户的稳定偏好“我喜欢靠窗座位”、重要事实“我有个三岁的女儿”、长期目标“我在准备考研”、明确的纠正“我不叫小明我叫小华”。这些信息的共同点是“跨会话仍然有效”。不值得记的一次性的指令“帮我查下明天的天气”、闲聊“哈哈今天天气不错”、已经完成的任务状态“帮我订个外卖”。这些信息要么时效性太短要么对后续对话没帮助。实操上我会在每轮对话结束后用一个轻量模型比如小参数量的模型做一次“记忆提取”让它输出结构化的JSON比如{ should_remember: true, memory_type: preference, content: 用户喜欢喝美式咖啡不加糖, confidence: 0.92, expire_at: null }这个提取步骤很关键它决定了记忆库的质量。我试过直接存原始对话检索出来的全是无关内容换成结构化提取之后召回的相关性明显提升。提取用的模型不需要太强小模型足够因为任务很简单就是判断“这句话值不值得记”和“记成什么类型”。3.2 记忆的写入去重、覆盖与时间衰减记忆写入最大的坑是“重复”和“冲突”。用户可能在不同会话里反复说“我喜欢美式”如果你每次都存一条检索的时候会返回一堆重复内容浪费上下文窗口。我的做法是写入前先做相似度检查。新记忆生成后先拿它的embedding去记忆库里查一下如果跟已有记忆的相似度超过0.9就不新增而是更新旧记忆的时间戳。如果相似度在0.7到0.9之间说明是相关但不同的信息可以合并成一条更完整的记忆。冲突处理更麻烦。用户先说“我喜欢美式”后来说“我改喝拿铁了”。这两条记忆语义上不冲突但事实上后者覆盖前者。我的处理方式是给记忆加一个“时效权重”检索时按时间衰减排序新的记忆权重更高。同时在提取阶段让模型判断“这条新信息是否推翻了旧信息”如果是就把旧记忆标记为“已失效”检索时过滤掉。时间衰减的公式我一般用指数衰减weight base_weight * exp(-lambda * days_since_update)lambda取0.01到0.05之间具体看你的场景。如果是长期偏好lambda取小一点衰减慢如果是短期状态lambda取大一点快速淘汰。这个参数没有标准答案得根据你的业务数据调。3.3 记忆的检索不只是向量相似度很多人做记忆检索直接拿用户当前问题去向量库查top-k这是不够的。记忆检索要考虑三个因素语义相关性、时间新鲜度、记忆类型匹配。语义相关性就是常规的向量相似度。时间新鲜度用上面的衰减公式算。记忆类型匹配是指如果当前问题是“推荐个餐厅”那“用户喜欢美式咖啡”这条记忆的相关性就低而“用户不吃辣”这条相关性就高。这个匹配可以通过给记忆打标签、检索时按标签过滤来实现。我一般用混合排序final_score alpha * semantic_score beta * time_decay gamma * type_matchalpha、beta、gamma三个权重根据场景调。客服场景可能更看重语义相关性alpha取0.6个人助理场景更看重时间新鲜度beta取0.5。这个排序逻辑写在应用层不依赖向量库本身灵活度更高。还有一个细节检索出来的记忆要控制数量。一般top-3到top-5就够了太多会稀释prompt的注意力。我试过塞10条记忆进去模型反而抓不住重点回答变得泛泛。3条精准的记忆比10条模糊的记忆有用得多。3.4 一个可直接复用的记忆模块代码结构下面是我常用的记忆模块结构用Python伪代码示意你可以按自己的技术栈翻译。class UserMemory: def __init__(self, vector_store, kv_store, extractor_llm): self.vector_store vector_store # 存记忆向量 self.kv_store kv_store # 存记忆原文和元数据 self.extractor extractor_llm # 记忆提取模型 def extract(self, dialogue_turn): # 用模型提取值得记的信息 result self.extractor.invoke(dialogue_turn) return result # 结构化JSON def write(self, user_id, memory): # 去重检查 similar self.vector_store.search(memory.embedding, top_k1) if similar and similar[0].score 0.9: self.kv_store.update_timestamp(similar[0].id) return # 冲突检查 if memory.is_override: self.kv_store.mark_invalid(memory.override_target) # 写入 mem_id self.kv_store.insert(user_id, memory) self.vector_store.insert(mem_id, memory.embedding) def retrieve(self, user_id, query, top_k3): query_vec embed(query) candidates self.vector_store.search(query_vec, top_k20) # 过滤该用户的记忆 candidates [c for c in candidates if c.user_id user_id] # 混合排序 scored [] for c in candidates: score (0.6 * c.semantic_score 0.3 * time_decay(c.updated_at) 0.1 * type_match(c.type, query)) scored.append((score, c)) scored.sort(reverseTrue) return [c for _, c in scored[:top_k]]这个结构的好处是职责清晰提取归提取写入归写入检索归检索。每一层都可以单独替换比如你想换个更强的提取模型或者换个向量库都不影响其他部分。4. 知识库与RAG实战切分、检索、重排的完整链路4.1 知识库构建的第一步文档切分策略RAG效果好不好七成看切分。我见过太多人直接把整篇PDF丢进去embedding然后抱怨检索不准。文档切分不是简单的按字数切要考虑语义完整性。按语义切分是首选。Markdown文档按标题层级切每个二级标题下的内容作为一个chunkPDF文档先做版面分析识别出段落、表格、图片再按段落切。切分的粒度我一般控制在300到500字太短了语义不完整太长了检索精度下降。重叠切分是必要的补充。相邻chunk之间保留10%到20%的重叠防止一个完整的语义被切断。比如一段话讲“退货流程分三步”切分点正好落在第二步中间没有重叠的话检索“退货流程”可能只召回后半段信息就不完整了。特殊内容特殊处理。表格不要按行切要整表保留因为表格的语义在整体结构里代码块要整块保留按行切会破坏语法图片要么做OCR提取文字要么用多模态模型生成描述再embedding。热词里有人问“rag知识库能存储图片嘛”答案是能但不是直接存图片而是存图片的描述或OCR文本检索时匹配文本返回时把图片一起展示。切分方式适用场景优点缺点固定长度纯文本、无结构简单快速语义易断裂按标题层级Markdown、HTML语义完整依赖文档结构按段落PDF、Word平衡需版面分析语义切分高质量要求效果最好需额外模型4.2 向量检索的瓶颈与优化向量检索不是银弹它有几个明显的瓶颈。第一个是召回率问题用户问“怎么退款”文档里写的是“如何申请退货”语义相近但用词不同纯向量检索可能召回不到。第二个是精度问题向量检索返回的top-k里可能有一半是语义相似但实际无关的内容。第三个是长文档问题一个chunk太长embedding会丢失细节太短又缺乏上下文。我的优化方案是混合检索向量检索关键词检索BM25两路结果合并后重排。向量检索负责语义匹配关键词检索负责精确匹配两者互补。实测下来混合检索的召回率比纯向量检索能提升20%到30%。具体做法是先用向量检索取top-20再用BM25取top-20两路结果去重后合并然后用一个重排模型Rerank对合并后的结果重新打分排序取top-5送给大模型。重排模型我一般用开源的bge-reranker或者cohere的rerank接口效果比单纯按向量相似度排序好很多。还有一个容易被忽略的点是查询改写。用户的问题往往很短很模糊比如“那个怎么弄”直接拿去检索效果很差。我会在检索前加一步查询改写用模型把用户问题扩展成更完整的检索query比如把“那个怎么弄”改写成“退货流程怎么操作”。这一步能显著提升召回率尤其是多轮对话场景。4.3 RAG的完整链路与参数配置把上面的东西串起来一个完整的RAG链路是这样的文档入库文档解析 → 切分 → 生成embedding → 存入向量库查询处理用户提问 → 查询改写 → 生成query embedding检索向量检索top-20 BM25检索top-20 → 合并去重重排Rerank模型对候选重排 → 取top-5生成把top-5片段拼进prompt → 大模型生成回答引用返回答案时附带来源片段方便用户核实每一步都有参数要调。切分粒度300到500字重叠10%到20%向量检索top-20BM25 top-20重排后top-5prompt里明确要求“只基于提供的片段回答不知道就说不知道”。这些参数不是拍脑袋定的是我在不同项目里反复试出来的经验值你可以作为起点再根据自己数据微调。提示prompt里一定要加“如果提供的片段中没有相关信息请直接说不知道不要编造”。这一句话能挡掉大部分幻觉问题比任何后处理都管用。4.4 知识库的版本管理与更新知识库不是建完就完事了文档会更新产品会迭代。我一般用“版本化增量更新”的策略。每次文档更新不直接覆盖旧向量而是打一个新版本号检索时默认只查最新版本。旧版本保留一段时间方便回滚和对比。增量更新是指只对变化的文档重新切分和embedding没变的文档复用旧向量这样能省大量计算。元数据里我会存文档来源、版本号、更新时间、所属分类。检索时可以按分类过滤比如用户问“技术问题”就只在技术文档里检索缩小范围提升精度。这个过滤条件在向量检索之后做不影响召回但能提升精度。5. 常见问题与排查技巧实录5.1 检索不准的排查思路检索不准是最常见的问题排查要按链路一步步来。先看切分把检索到的chunk打印出来看内容是否完整、是否包含答案。如果chunk本身就不含答案那是切分问题调整切分粒度或重叠比例。再看embedding把用户query和chunk的向量相似度打出来如果相似度很低但人眼判断应该相关那是embedding模型不适合你的领域换个领域微调过的模型。最后看重排如果召回里有正确chunk但排序靠后那是重排模型的问题换个更强的rerank模型或者调整权重。我整理了一个速查表现象可能原因排查方法解决召回为空切分太碎/embedding不匹配打印chunk和相似度调整切分/换模型召回相关但排序低重排模型弱看重排前后排序换rerank模型答案含幻觉prompt没约束检查prompt加“不知道就说不知道”多轮对话检索差query没改写看原始query加查询改写表格/图片检索不到未特殊处理检查入库内容表格整表存/图片OCR5.2 用户记忆与知识库冲突怎么办有时候用户记忆和知识库会冲突。比如知识库说“退货需要7天”但用户记忆里记着“这个用户是VIP退货期30天”。这时候Agent该听谁的我的原则是用户记忆优先于知识库因为用户记忆是个性化的、更具体的。但要在prompt里明确告诉模型这个优先级否则模型可能随机选一个。具体做法是在prompt里把用户记忆放在知识库片段之前并标注“以下是该用户的个性化信息优先级高于通用知识”。还有一种冲突是用户记忆本身矛盾比如用户先说“我喜欢美式”后说“我讨厌咖啡”。这种要在写入阶段就处理掉用时间衰减和覆盖机制保证只保留最新有效的记忆。5.3 并发与性能的实战经验热词里有人问“ai agent 怎么扛并发”这是个好问题。Agent的并发瓶颈通常不在模型推理而在检索和记忆读写。向量检索的并发能力取决于你用的向量库。Milvus、Qdrant这些支持水平扩展单机能扛几千QPSFAISS是内存索引并发高但不好扩展。我的建议是如果QPS在100以内单机向量库够用超过100考虑分布式向量库或者加缓存。缓存的策略是对高频query的检索结果做缓存比如“退货政策”这种问题答案基本不变缓存5分钟能挡掉大量重复检索。用户记忆的读写用Redis单机几万QPS没问题。真正要小心的是embedding计算每次检索都要算query向量这个可以用小模型或者缓存query embedding来优化。还有一个坑是批量写入。知识库初始化时如果一条条写入向量库速度极慢。要用批量接口一次写几百条速度能快几十倍。我试过用单条写入初始化一个10万chunk的知识库跑了几个小时换成批量写入几分钟就搞定了。5.4 几个我踩过的坑第一个坑是embedding模型选型。一开始我用的是通用embedding模型中文效果一般。后来换成中文优化的模型检索准确率明显提升。选embedding模型一定要在你的领域数据上测别看榜单榜单和实际场景差距很大。第二个坑是chunk太大。我一开始觉得chunk大一点信息全结果检索精度很差因为一个chunk里混了好几个主题embedding被平均了。后来把chunk缩小到300字左右精度立马上来了。第三个坑是忽略元数据。早期我没存文档来源和分类检索出来没法过滤也没法给用户展示引用来源。后来补上元数据既能过滤又能引用体验好很多。第四个坑是记忆提取太频繁。我一开始每轮对话都提取记忆成本高且噪音多。后来改成每3到5轮提取一次或者检测到用户说了“记住”“我喜欢”这类关键词时才提取效果好很多。6. 工具选型与部署建议6.1 向量库怎么选向量库的选择取决于你的规模和部署环境。小规模、单机、快速验证用FAISS或者Chroma装个包就能跑零运维。中等规模、需要持久化和过滤用Qdrant或者Milvus支持元数据过滤和水平扩展。大规模、企业级、要高可用用Milvus集群或者云厂商的向量服务。国内企业私有化部署的话Milvus和Qdrant都是不错的选择社区活跃文档齐全。如果团队规模小不想运维可以考虑云服务但要注意数据合规。6.2 大模型与embedding模型的选择生成模型和embedding模型要分开选。生成模型负责最终回答要求理解能力强、指令遵循好embedding模型负责检索要求语义表征准、领域适配好。embedding模型我一般用bge系列或者m3e系列中文效果好开源可私有化。生成模型看你的预算和合规要求开源的可选Qwen、Llama系列闭源的看各家API。如果做私有化部署开源模型是首选但要注意显存和推理速度的平衡。6.3 一个最小可用的部署架构如果你要从零搭一套我建议的最小架构是文档解析用Python的unstructured库切分自己写规则embedding用bge-small向量库用Qdrant生成模型用Qwen或者API记忆存储用Redis编排用LangChain或者自己写。这套架构单机就能跑成本低够用。等规模上来了再把向量库换成Milvus集群embedding换成更大的模型加Rerank加缓存。不要一上来就上最复杂的架构先用最小可用版本跑通链路再逐步优化。7. 写在最后的一些个人体会做用户记忆和知识库这两年我最大的体会是这两件事的难点都不在技术而在“取舍”。什么信息值得记、什么信息该忘、检索几条合适、切分多大粒度这些都没有标准答案得根据你的业务场景和数据特点去调。我见过太多团队追求“最先进”的方案结果链路太复杂出了问题都不知道从哪排查。我的建议是先用最简单的方案跑通把链路打通把数据跑起来然后根据实际bad case去优化。RAG的优化是个迭代过程不是一次设计就能完美的。每次遇到检索不准就按“切分→embedding→检索→重排→生成”的顺序排查一遍慢慢你就知道你的数据适合什么参数了。还有一点用户记忆和知识库的边界要清晰。我见过把用户隐私写进公共知识库的也见过把产品文档塞进用户记忆的最后都是灾难。物理隔离各管各的这是底线。最后分享一个小技巧在prompt里给模型一个“记忆使用说明”告诉它哪些是用户个性化信息、哪些是通用知识、冲突时听谁的。这个说明不用长两三句话就够但效果立竿见影。我试过不加说明和加说明的对比加了之后回答的准确率和一致性明显提升。这个细节很多教程不会讲但实际用起来很管用。