大模型记忆系统设计：从上下文窗口到向量库的工程实践

去年我做了一个叫 ai-memory 的项目目标很单纯让大模型记住用户。当时接手的AI客服应用最大的痛点不是模型不够聪明而是它每次都被当成“重新认识用户的外聘顾问”——能力很强但记性为零。这个现象在圈子里有个经典说法大模型有上下文窗口没有长期记忆。项目做到最后我从“给模型加记忆”一路踩到了“给服务加内存”才意识到 ai-memory 这个名字其实很贴切它既指AI该有的记忆也指工程上绕不开的内存问题。这篇东西不吹架构不炫技术就是把 ai-memory 这个模块从设计到落地的完整过程摊开讲。内容包括记忆分层怎么做、向量库怎么选、核心的写入/检索/注入链路怎么实现以及本地部署时显存和内存那些最容易让人失眠的坑。适合正在做AI应用开发、agent项目或者准备把个人助理类应用跑通的人参考。如果你刚接触大模型应用也能从中搞清楚“大模型memory到底是什么”以及“为什么很多项目都要配一个向量数据库”。先说明一点下面这套实现路径是我在多个项目里反复验证过的常见做法不是唯一解法但拿来当骨架完全够用。遇到具体业务替换抽取规则和检索策略就行。1. 项目概述ai-memory 到底要解决什么问题1.1 大模型的“记忆”为什么是个工程问题Transformer架构的大模型本身没有跨会话记忆。你每次调用它对话基本上都是从一个干净的状态开始——你发过去一段prompt模型基于这段上下文生成回复然后这个上下文就该干嘛干嘛去了。上下文窗口可以理解成模型“当前能看见的桌面”它很大但终究有限而且一次会话结束后桌面就清空了。更麻烦的是就算在同一个会话里只要内容超过上下文窗口长度最前面的部分也会被“挤出去”。我习惯用一个例子跟团队解释这件事你请了个能力很强的外聘顾问他每次都认真听你说完然后给出漂亮的方案。但你第二次找他时他完全不记得你上次的情况你得重新介绍背景和约束。用户体验就是AI确实聪明但每次都要从头教。所以结论很直接想让AI有记忆必须给它外挂一个专门负责记忆的系统这就是 ai-memory 存在的意义。具体到工程层面它要做三件事从对话里挑出值得记的内容、把记忆存到可检索的地方、在后续对话中把相关记忆喂回给模型。三件事缺一件整个记忆闭环就跑不起来。1.2 项目适用的场景与目标读者我建设 ai-memory 的目标是把对话式AI从“每次失忆的顾问”变成“了解你的助理”。目前落地最多的是四类场景AI客服记住用户的历史工单、设备型号、沟通偏好。个人助理agent记住日程安排、长期目标、资料偏好。智能文档问答记住用户之前问过什么、关注哪些章节。教育陪练记住学员当前水平、薄弱点和学习习惯。适合看这篇内容的人我大致分两类。一类是已经在做AI应用开发正准备把记忆模块加进自己的agent或聊天产品里的工程师对你来说前文的架构和后文的踩坑细节价值更大。另一类是刚开始研究大模型应用的新手想明白“记忆系统到底长什么样”可以从设计思路和方案选型部分看起先建立全局概念再动手实现。如果你之前没接触过向量数据库也不用慌。这个项目里的向量库只做了一件事把文本变成向量然后按相似度把相关的文本捞出来。这个概念先记住后面实现部分会展开。2. 整体设计思路记忆分层与数据流2.1 短期记忆与长期记忆怎么切分很多第一版记忆系统会把所有聊天记录一股脑存进向量库用户一说话就把“全部历史”检索一遍拼到提示词里。这个方案跑通很容易实际效果却很糟糕。为什么因为用户不需要AI记住每一句话他需要的是AI能记住那些影响后续回复的关键信息。所以我在项目里把记忆拆成两层记忆类型存储载体生命周期典型内容示例短期记忆上下文窗口 Redis缓存单次会话当前对话细节、临时需求“今天想咨询屏幕碎了怎么处理”长期记忆向量数据库跨会话、持久用户偏好、固定事实、重要结论“用户设备是iPhone 15偏好文字客服”短期记忆的核心是“当前对话别丢关键上下文”。会话一长滚动摘要就派上用场了保留最近几轮完整对话更早的部分压缩成摘要继续留在窗口里。长期记忆的核心是“跨会话命中”不能靠塞上下文解决必须用提取加检索的方式。这个边界为什么重要核心原因是上下文窗口永远是稀缺资源。能少塞一点就少塞一点把长期记忆也全部塞进去不仅白白消耗token还会让模型被无关信息干扰关键信息反而看不清楚。2.2 技术选型向量库、缓存与模型接入考虑到项目的起点是“快速跑通闭环”我当时对技术选型定了几条原则能少起服务就少起服务选型要能平滑升级前期不引入重量级商业组件。向量数据库我最终对比了四个方案方案部署成本检索能力适合场景Chroma低可进程内嵌基础原型、小项目Qdrant中Docker单机即可强metadata过滤丰富生产级个人项目Milvus高组件比较多很强大规模生产sqlite-vec极低纯文件基础工具链极简的场景个人项目或早期产品我建议从 Qdrant 或 Chroma 起步。如果团队已经依赖 PostgreSQL也可以考虑 pgvector省掉多维护一套存储。我的最终选择是 Qdrant理由很朴素Docker一条命令能起来metadata过滤做得好后续扩展不用推翻重来。缓存层用的Redis。Redis不止缓存短期记忆还能存“热记忆”也就是那些几乎每次对话都会命中的用户特征避免每次请求都去向量库查一遍。大模型接入侧我预留了OpenAI兼容接口同时用Ollama跑本地模型方便没有外网或数据敏感时切换。2.3 为什么不能“全量记忆”项目启动时团队里有人提议既然上下文窗口已经有128K干脆把用户所有聊天记录都塞进去不就行了这个想法最诱人也最坑。我把原因整理成三条第一token成本线性增长。128K看起来很大但用户只要持续聊上几个月聊天记录轻松超过这个数字。每次请求都带着全部历史费用和延迟会成倍上涨。第二无关信息会干扰模型判断。全量塞入时模型看到大量无关内容反而会降低对关键信息的敏感度。第三检索式记忆本质上是在给模型做“筛选”只让它看该看的部分而不是把整个仓库搬过去。所以我坚持“提取检索注入”三段式先提取关键点再检索最相关的记忆最后只把相关记忆注入提示词。这才是工程上可持续的方案。2.4 整体数据流ai-memory 的核心数据流我用一条线串起来过一遍用户消息进入服务先做会话判断新会话还是续聊。将当前消息发送给抽取模块判断有没有值得进入记忆的信息。有则写入长期记忆库同时更新短期缓存比如用户当前最关心的主题。检索模块拿用户当前问题加用户ID从向量库召回与问题相关的记忆。把召回记忆和短期上下文一起拼进prompt发给大模型。模型返回后再让抽取模块判断回复里有什么新事实需要补进记忆。异步更新记忆的时间戳、使用次数、衰减权重。这个流程里最容易被忽略的是第6步。人类对话里很多关键信息出现在“回复”中——客服说“您的延保到明年3月”这句话就应该被记下来。我实现抽取时会把用户消息和模型回复都过一遍因为这个动作直接决定了记忆库的完整性。3. 核心实现记忆的写入、存储、检索与注入3.1 记忆写入从对话里提取“值得记”的东西记忆系统的质量80%由“提取”决定。检索做再准源头上该记的都丢了后面全是白搭。我定义了五类值得长期记忆的信息用户偏好“喜欢夜里咨询”、固定事实“住在上海”“用的512G手机”、当前目标“在对比两款相机”、重要结论“已确定要买A款预算6000内”、情绪状态“最近比较急回复时注意语气”。剩下的琐碎寒暄、临时指令、一次性问题都不进长期记忆。提取可以交给一次小的LLM调用完成提示词关键部分长这样你是一个信息抽取器。从对话中抽取需要长期记住的、对后续对话有用的用户信息。 要求 1. 只输出结构化JSON字段为 facts 数组每个元素包含 type、content、importance。 2. type 只允许preference偏好、fact事实、goal目标、conclusion结论、emotion情绪。 3. importance 取 1-5 的整数5 表示非常关键且长期有用。 4. 不要抽取一次性指令、寒暄、无实质内容的话。 5. 不确定是否值得记时倾向于不记。 用户消息 {用户消息} 模型回复 {模型回复} 输出JSON这里有个很多人会忽略的细节importance 直接决定了后续检索和淘汰策略。建库时我给每条记忆一个初始 importance随后随时间和使用频率自动衰减或提升。优先级高的记忆即使时间久也依然会被检索到不会被过早清理。3.2 记忆存储向量化与索引设计存储层我设计了一张比较通用的集合字段如下{ id: 唯一ID, user_id: 归属用户/租户, type: preference/fact/goal/conclusion/emotion, content: 记忆内容文本, importance: 4, created_at: 2025-01-01T10:00:00Z, updated_at: 2025-01-02T09:00:00Z, last_used_at: 2025-01-02T09:00:00Z, embedding: [0.012, 0.038, ...] }user_id 字段不是可选项它是多租户隔离的第一道防线。所有查询必须带 user_id 过滤防止一个用户检索到另一个用户的记忆。这个问题我见过很多新手项目踩坑向量库全局共享A用户的问题把B用户的记忆召回了属于事故级bug。向量化模型的选择按性价比来就好。纯中文场景优先 bge-m3 或 bge-large-zh需要多语言通用可以考虑 text-embedding-3-small。本地部署场景用 bge-m3 很稳它同时支持稠密向量和稀疏检索对短句和专有名词的召回有明显提升。索引侧Qdrant里我会给 user_id 建普通索引给 type 和 importance 建过滤字段主键用UUID。排序默认用余弦相似度但embedding必须做归一化否则余弦相似度和内积的结果会偏移影响召回质量。3.3 记忆检索从“全部翻出来”到“只挑最相关的”写检索之前先纠正一个常见误区用户当前问题永远是最好的查询向量。不能把用户的历史问题平均一下当查询那样会稀释语义导致召回结果过于泛化。项目里的检索函数我写得比较简单但思路可以直接复用def search_memories(client, user_id, query_text, top_k5): query_vector embed(query_text) results client.query_points( collection_namememories, queryquery_vector, query_filterFilter( must[FieldCondition(keyuser_id, matchMatchValue(valueuser_id))] ), limittop_k * 2 ) # 按 importance 加权后重新排序 scored [] for hit in results.points: score hit.score importance hit.payload.get(importance, 0) time_bonus decay_score(hit.payload[updated_at]) final_score score * 0.7 (importance / 5) * 0.2 time_bonus * 0.1 scored.append((final_score, hit)) scored.sort(keylambda x: x[0], reverseTrue) return [hit for _, hit in scored[:top_k]]这里有个关键点权重是按业务调的。教育类场景时间衰减权重应该更大因为学员水平变化快知识库问答场景 importance 权重可以小一些因为内容是否相关主要由向量相似度决定。top_k 的取值对话应用一般取5到8条知识库问答可以放到8到12条。太少容易漏关键记忆太多则注入碎片信息干扰模型。相似度阈值一般设0.3到0.5之间具体要看 embedding 模型的分布这个必须拿真实数据画一遍分布才能定拍脑袋设阈值很容易把召回率压死。3.4 记忆注入拼装prompt的正确姿势记忆检索出来后最忌讳直接把原文堆在用户消息后面。模型会把旧记忆当成“用户当前说的话”造成语义错位。我会在prompt里专门开一个“已知用户记忆”区域每条记忆带类型和时间你正在和用户对话。以下是该用户的已知记忆请结合这些信息进行自然回复但不要把记忆内容重复给用户看。 已知记忆 -preference2025-01-02用户希望在回复中避免专业术语优先大白话。 -fact2025-01-05用户使用的是国行iPhone 15iOS 18。 -goal2025-01-05用户正在对比A款和B款相机预算6000元内。 当前对话 {短期上下文} {用户当前消息}为什么每条记忆都带时间因为模型如果只看到内容会默认这是当前状态。加上时间戳后模型至少知道哪些是旧状态避免把过期信息当成当前事实。比如用户上个月说要买A款这个月改了主意带时间的记忆能让模型意识到“这条信息可能已过时”。注入量我控制在总上下文的10%到20%以内超过这个比例模型会被记忆带偏。这又一次说明“提取”质量的重要性——宁缺毋滥。3.5 记忆更新与遗忘很多第一版记忆系统只写了“写入”和“读取”忘了“更新”和“删除”。这会导致一个很严重的后果用户地址换了旧地址还躺在记忆库里AI每次都用旧地址去推理。我的做法是三层策略覆盖新抽取的内容和已有记忆在语义上高度重合通常是相似度高于0.85就用新内容覆盖旧的同时重置 updated_at。衰减importance 随时间和未使用次数递减。比如30天未被命中的记忆importance 减1衰减到2以下的记忆降低检索权重进入“冷记忆”区。删除提供明确的删除接口用户可以说“忘掉我之前说的地址”系统根据当前对话锁定对应记忆并删除。这个能力不是锦上添花隐私合规场景下是必需的。衰减周期不建议写死。我第一版把30天写死在代码里后来发现金融类需求的波动周期是周级最后改成了按业务类型配置衰减周期。这种细节看起来不起眼但对记忆准确率影响很大。4. 工程落地本地部署与内存问题的实战记录4.1 本地跑大模型时的显存/内存规划做 ai-memory 的过程中很多人会把检索系统和模型推理分开看但记忆系统里最容易被内存问题拖垮的往往就是本地部署大模型这一侧。我整理了一些常见开源模型在量化条件下的显存占用估算模型规模4bit量化显存约16bit显存推荐部署方式7B如Qwen2.5-7B5~7GB14GB以上消费级显卡可跑13B10~13GB28GB以上建议16GB以上显存32B20~25GB64GB以上建议多卡或高显存72B45~55GB140GB以上集群或量化加分片实际部署时显存占用不只看模型大小还要看推理框架的开销、KV Cache、并发请求数。vLLM这类框架会额外预分配显存作为KV CacheOllama相对保守但并发能力也更弱。只想本地试效果我建议从 Ollama 跑7B量化模型起步要做并发接口vLLM 更合适。内存问题不一定只在显存。加载 embedding 模型时bge 这类模型也会占内存向量库一次性加载几百万条向量到内存几十GB瞬间就没了。排查顺序应该是先看哪个进程内存涨了再决定是换框架、缩并发还是分批加载。4.2 应用层 OOM 的常见原因与排查思路我在项目里遇到的内存类报错基本可以归成三类推理框架 OOM并发请求太多、KV Cache 分配过大、max tokens 设得过高。表现为请求时报显存不足。向量库内存暴涨加载超大集合时把所有向量一次性读进内存或者过滤查询没索引导致全量扫描。应用容器内存超限Python进程缓存太多对话摘要Redis没设 maxmemory 策略日志无界增长。排查时我习惯先看监控图再看进程数然后按“最近改了什么”来找原因。有一次深夜告警看监控发现是embedding服务挂了网关在疯狂重试最终把内存打满。最后把批量请求限制加上超时重试问题才消失。另一个很实用的建议本地跑大模型应用给所有上游调用设置超时和重试上限尤其是 embedding 和向量库查询。很多 OOM 不是真内存不够而是故障时无限重试把内存耗尽了。4.3 服务化接口设计ai-memory 模块给上层应用提供的接口我尽量收敛成4个写记忆、查记忆、删记忆、清空用户记忆。FastAPI实现示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class MemoryWriteRequest(BaseModel): user_id: str content: str type: str fact importance: int 3 app.post(/memory/write) def write_memory(req: MemoryWriteRequest): # 先向量化 vector embed(req.content) # 写入向量库同时带 user_id 隔离 collection.upsert(points[create_point(req, vector)]) return {status: ok} app.get(/memory/query) def query_memory(user_id: str, query: str, top_k: int 5): return search_memories(client, user_id, query, top_k) app.delete(/memory/{memory_id}) def delete_memory(memory_id: str): client.delete_points(collection, [memory_id]) return {status: deleted}有一点容易漏掉写接口必须校验 type 是否在白名单里内容长度要限制比如单条记忆不超过500字。如果不限制用户一次性扔一大段文本抽取模块很容易把无关内容也存进去污染整个记忆库。多租户隔离我是靠每个请求必带 user_id 实现向量库内所有点的 payload 都写 user_id 字段。后续要做企业级产品可以再加 namespace 或 org_id 一层避免不同企业撞库。5. 常见问题与排查技巧实录5.1 检索效果差模型总是“用不上记忆”我遇到最频繁的问题是用户明说“我之前说过的”但AI毫无反应。排查路径是一条链按顺序检查先看抽取聊天内容是否真的写进了向量库对照日志有没有 MemoryWrite 记录。再看向量化同一个 query 和 content 用的模型是否一致很多人查询时换了向量模型维度都对不上。再看过滤user_id 是否匹配如果用户在Web端和App端用的是不同 user_id记忆就会断掉。最后看检索参数top_k 是否太小相似度阈值是否太严。用真实 query 跑一遍日志看看召回分数的分布。一个很典型的坑是 embedding 模型和检索场景不匹配。有的模型对长文本友好有的对短句友好。对话场景下 query 往往很短如果向量模型对短文本召回差就需要做“查询扩展”把用户当前问题输入一个小模型补全成一句话再向量化。这个技巧简单但效果明显。5.2 记忆污染与幻觉AI把过期记忆当成了当前事实记忆系统最隐蔽的问题是“记忆污染”。场景很常见用户半年前说过“准备买A款相机”这半年里改了两次主意。AI每次聊天都翻出那条旧记忆于是所有建议都朝A款倾斜。解决办法我从三方面入手。一是带时间戳注入让模型有“过期”的概念。二是查重合并新记忆写入前先和旧记忆做语义匹配重合就覆盖而不是新增。三是允许用户显式删除或修正产品上提供“记忆管理”页面让用户看到AI记住了什么随时可以删。千万别小看第三点。给用户记忆管理能力不仅减少记忆污染也是合规刚需。很多项目上线后被用户投诉“AI怎么知道我买了什么”就是因为默认记忆不可见、不可删。5.3 性能问题每次请求都查库延迟扛不住如果每次对话都实时做 embedding、向量检索、大模型推理整体延迟很难压到1秒以内。我的优化顺序是先做热记忆缓存把用户最常命中的几条记忆缓存到Redis设置较短TTL比如10分钟。然后做异步写记忆抽取和写入完全不阻塞回复主流程用户回复生成后再异步落库。最后做并发检索如果一次要查多个向量库用asyncio并发避免串行累计。还有个容易被忽略的瓶颈embedding 调用本身可能占整个检索链路一半以上的延迟。如果用远程 embedding 服务一定要做连接复用不要每次请求都新建 HTTP 客户端。5.4 内存/显存问题速查表把实战中见过的典型症状和解决办法整理成一张表遇到问题直接对照症状可能原因排查方向推理时OOM模型加载成功但请求报错并发请求过多KV Cache超分限流、缩batch、下调max tokens应用进程内存缓慢增长最终被kill向量库全量加载、缓存无上限查日志和Redis设置内存上限检索变慢内存占用上升过滤查询无索引导致全量扫描给 user_id 等字段建索引本地部署加载模型几秒后退出显存不足或swap问题换量化版本、降低上下文长度embedding批量处理报错批量size过大拆小批次增加冷却6. 实操体会先跑通再谈优化6.1 我踩过的两个坑第一个坑是过度设计。第一版 ai-memory规划了知识图谱、多模态记忆、分布式向量库结果两个月没跑通连基本用户反馈都没拿到。后来砍到只剩“提取向量检索注入”三件套一周就上线了。很多时候“先跑通再优化”不是口号而是真能省掉大把沉没成本。第二个坑是只测检索准确率不测端到端体验。之前我把检索Top5准确率调到90%以上以为效果很好结果真实用户还是觉得AI“像失忆一样”。后来才发现是注入格式的问题——记忆没有放在 system 区而是混在用户消息里模型根本不理会。判断记忆系统好不好的标准不能只看检索指标要看完整对话闭环里“用户有没有感受到AI记得他”。6.2 可以继续扩展的方向如果项目继续演进我会按顺序考虑三件事给记忆加重要性自动学习根据对话时长、用户纠错、后续使用频率反推权重引入知识图谱做实体链接让“那个人”“那台设备”能指代到具体对象做跨会话主题聚类让长期记忆管理面板自动分组展示。我在实际项目里做过一次方向调整从“无限记录”改成“精炼记忆”。后来发现用户真正需要的不是AI保留所有对话而是AI在关键节点做出“我记得你上次说过……”的正确反应。大家在做自己的 ai-memory 时不妨先问自己一个问题如果只能记住5件事来服务这个用户你最想记住哪5件把这个问题想明白了后面的工程细节都不会白做。