Agent记忆与知识库实战：从RAG原理到长期记忆系统搭建

1. 从“用户记忆”到“知识库”为什么你的Agent总是“记不住事”做Agent开发的人大概率都经历过这样一个尴尬时刻你花了两周时间搭好一个对话机器人接入了大模型调好了提示词演示的时候流畅自然。结果第二天用户回来接着聊它一脸茫然地问“请问您是哪位”。更离谱的是同一个会话窗口里用户五分钟前刚说过“我对花生过敏”五分钟后推荐餐厅时它照样给你推了家花生酱拌面出名的馆子。这不是模型不够聪明而是它压根没有“记忆”。大模型本身是无状态的。每一次API调用对它来说都是第一次见面。你发给它的上下文窗口里有什么它就知道什么窗口里没有的它一概不知。这就像你雇了一个智商180但患有严重顺行性遗忘症的顾问——每句话说完就忘光下次开口前你得把所有背景重新讲一遍。用户记忆和知识库本质上解决的是同一个问题的两个面前者关注“这个用户是谁、他之前说过什么、偏好是什么”后者关注“这个组织有哪些沉淀下来的事实、文档、规则”。两者合在一起才构成一个Agent真正可用的“长期记忆系统”。我见过太多团队在这件事上走弯路。有人把用户历史对话直接拼进prompt聊到第三轮就爆token有人把所有文档塞进向量库检索出来一堆似是而非的片段模型拿着半截话就开始编还有人把记忆和知识库混为一谈结果用户说“我上次说的那个方案”系统去文档库里搜“那个方案”当然什么都搜不到。这篇文章我想把“用户记忆”和“知识库”这两件事拆开讲透再讲它们怎么协同工作。从核心概念、架构选型、实操搭建到检索调优、常见坑点尽量把我在实际项目中踩过的、见过的、修过的都写出来。不管你是刚接触RAG的新手还是已经在调Agent的老手应该都能找到能直接抄作业的部分。2. 核心概念拆解用户记忆、知识库、RAG到底各管什么2.1 用户记忆不是聊天记录是结构化的人物档案很多人一上来就把“用户记忆”理解成“把聊天记录存下来”。这个理解不能说错但太粗糙了。聊天记录是原始素材不是记忆本身。真正的用户记忆是从对话中抽取出来的、结构化的、可检索的、关于这个用户的事实集合。举个例子。用户说“我上周刚从北京搬到杭州之前做Java后端的最近在学Rust家里养了只猫叫豆豆。”原始聊天记录就是这句话本身。而结构化记忆应该是居住地杭州2024年X月从北京迁入职业背景Java后端开发当前学习方向Rust宠物猫名字叫豆豆为什么要结构化因为下次用户问“帮我推荐个周末去处”你需要知道他在杭州他问“有没有适合转语言的学习路线”你需要知道他Java转Rust他说“我家猫最近不爱吃饭”你得知道他有只猫叫豆豆而不是反问“您养宠物吗”。用户记忆的核心操作有三个抽取、存储、召回。抽取靠LLM做信息提取存储靠结构化数据库或向量库召回靠检索策略。三者缺一不可。2.2 知识库组织沉淀的“事实底座”知识库和用户记忆最大的区别在于知识库是共享的用户记忆是个性化的。一个企业的产品文档、FAQ、内部规范、历史工单解决方案这些都属于知识库。它不随某个用户而变化但对所有用户都生效。用户问“你们的退款政策是什么”Agent应该去知识库里找标准答案而不是去翻这个用户的历史对话。知识库的形态可以很多样Markdown文档、PDF手册、Confluence页面、数据库表、甚至是一组结构化的JSON规则。但不管原始形态是什么要让Agent用起来通常都要经过一个“向量化”的过程——把文本切成片段用嵌入模型转成向量存进向量数据库检索时用相似度匹配。这里有个常见误区知识库不等于向量库。向量库只是知识库的一种索引方式。对于精确匹配的场景比如查订单号、查产品型号传统的关键词检索或SQL查询可能比向量检索更靠谱。成熟的方案往往是混合检索向量召回关键词召回重排序。2.3 RAG把“检索”和“生成”串起来的流水线RAGRetrieval-Augmented Generation检索增强生成这个词这两年已经被说烂了但很多人对它的理解还停留在“把文档塞进向量库然后让模型基于检索结果回答”。这只是RAG最基础的一层。真正在生产环境跑得住的RAG至少包含以下几个环节文档解析PDF、Word、HTML、图片里的文字怎么提取出来分块策略按固定长度切、按语义切、按标题层级切效果差别巨大向量化选哪个嵌入模型维度多少要不要微调存储与索引用什么向量库要不要建倒排索引做混合检索检索策略Top-K怎么定要不要做查询改写、多路召回重排序用交叉编码器对召回结果精排生成约束怎么让模型只基于检索到的内容回答不编造引用溯源答案里能不能标出出处方便用户核实这八个环节每一个都有坑。后面我会逐个展开。2.4 用户记忆与知识库的协同关系把用户记忆和知识库放在一起看它们的关系可以用一个场景说明用户问“我上次说的那个Rust学习计划你帮我看看有没有对应的内部培训课程”用户记忆负责回答“上次说的Rust学习计划是什么”——去用户档案里找历史对话摘要知识库负责回答“有没有对应的内部培训课程”——去企业培训文档里检索Agent负责把两者拼起来“根据您之前提到的Rust学习计划记忆我查到公司内部有一门《Rust从入门到实战》的课程知识库下周开课需要我帮您报名吗”没有用户记忆Agent不知道“那个计划”指什么没有知识库Agent不知道公司有什么课程。两者缺一体验就断档。3. 架构选型从零搭建一套可用的记忆与知识系统3.1 整体架构分层我习惯把整套系统分成四层接入层负责接收用户输入做初步的意图识别和路由。判断这次请求是需要查知识库、查用户记忆还是两者都要。记忆层包含用户记忆的抽取、存储、召回。通常用一个关系库存结构化档案一个向量库存对话摘要的嵌入。知识层包含文档解析、分块、向量化、索引、检索、重排序。核心是一个向量库加一个全文索引库。生成层把检索到的记忆片段和知识片段拼进prompt调用LLM生成回答并做引用标注。这四层可以部署在同一台机器上也可以拆成微服务。小规模场景日活几百一台8核16G的机器加一个向量库就够了。大规模场景日活上万需要考虑向量库的分布式部署、嵌入模型的推理加速、检索结果的缓存。3.2 向量数据库怎么选这是被问得最多的问题之一。我的建议是先看你的数据量和团队技术栈再看功能。向量库适合场景优点注意点FAISS本地实验、小规模轻量、快、无需部署服务不支持增删改、无持久化Chroma快速原型、小团队上手极快、API简洁生产环境性能一般Milvus中大规模生产功能全、支持混合检索部署较重、运维成本高Qdrant中小规模生产Rust写的、性能好、过滤强生态相对小pgvector已有PostgreSQL不用额外引入组件大规模性能不如专用库Elasticsearch已有ES集群全文向量混合检索成熟向量功能相对较新我个人的经验是如果你已经在用PostgreSQLpgvector是最省事的起点如果数据量超过百万级向量或者需要复杂的元数据过滤Milvus或Qdrant更合适如果只是做个demo验证想法Chroma十分钟就能跑起来。3.3 嵌入模型的选择逻辑嵌入模型决定了“检索准不准”的上限。选型时看三个维度语言支持、维度、推理成本。中文场景下BGE系列BAAI的bge-large-zh、bge-m3是目前开源里表现很稳的。如果追求更好的效果且预算允许可以调云端嵌入API。如果要在本地跑bge-small-zh在消费级显卡上就能实时推理效果对多数场景够用。维度不是越高越好。1024维和768维在多数检索任务上差距不大但存储和计算成本差一倍。我一般建议从768维起步效果不够再升。还有一个容易被忽略的点嵌入模型要和你的分块策略匹配。如果你的块是512个token嵌入模型的最大输入长度是512那刚好如果块是1024token模型只能截断处理后面的内容就丢了。选型时一定要看模型的最大序列长度。3.4 用户记忆的存储设计用户记忆我建议用“关系库向量库”双写关系库比如PostgreSQL存结构化字段用户ID、事实类型、事实内容、置信度、更新时间、来源对话ID。向量库存事实内容的嵌入用于语义召回。比如用户问“我之前说过的那个爱好”向量检索能匹配到“喜欢摄影”这条记忆即使字面不完全一致。记忆的更新策略也很关键。我见过两种极端一种是只增不改用户改了偏好旧记忆还在导致召回冲突另一种是频繁覆盖用户随口一说就被当成长期事实噪声很大。我的做法是给每条记忆加置信度和时效性。用户明确说“我现在住在杭州”置信度高覆盖旧居住地用户闲聊说“最近在看房”置信度低只作为短期上下文不写入长期档案。时效性方面居住地、职业这类相对稳定宠物、爱好次之临时状态比如“今天心情不好”不写入长期记忆。4. 实操搭建从文档到可检索知识库的完整流程4.1 文档解析别小看这一步一半的坑在这里很多人搭RAG上来就调分块和检索结果效果不好回头才发现是文档解析就出了问题。PDF是最麻烦的。扫描版PDF需要OCR表格需要专门提取多栏排版需要正确识别阅读顺序。我试过直接用PyPDF2提取表格全乱段落顺序错位检索出来的片段根本没法用。我的建议是纯文本PDF用pdfplumber或PyMuPDF按页提取保留段落结构扫描版PDF先用OCR工具比如PaddleOCR转成文本再处理Word文档python-docx可以提取段落和表格注意保留标题层级HTMLBeautifulSoup或trafilatura去掉导航栏和广告图片如果知识库需要存图片用多模态嵌入模型比如CLIP单独建图片索引文本检索和图片检索分开走注意文档解析阶段一定要保留元数据。来源文件名、页码、章节标题这些在后面做引用溯源时必不可少。我习惯在解析时就把这些信息作为metadata附在每个文本块上。4.2 分块策略固定长度是下策语义分块是中策层级分块是上策分块是RAG里最被低估的环节。块切得不好检索再准也白搭。固定长度分块按512token一刀切。优点是简单缺点是经常把一句话切成两半或者把不相关的内容塞进同一个块。适合快速验证不适合生产。语义分块用嵌入模型计算相邻句子的相似度在相似度骤降的地方切分。效果比固定长度好但计算成本高而且对短文档不友好。层级分块这是我目前最推荐的方式。先按文档的自然结构标题、章节、段落切分大块用于召回小块用于生成。具体做法是按标题层级切成章节块比如每个H2一个块章节块内再按段落切成小块比如每3-5段一个块检索时先召回章节块再在章节块内定位到具体段落块这样做的好处是召回时上下文完整生成时精度高。用户问一个具体问题系统先找到相关章节再把章节里最相关的段落喂给模型。分块大小方面我的经验值是中文场景下每个块300-500字比较合适。太小了信息不完整太大了检索精度下降。如果文档本身结构清晰优先按结构切如果是一堆零散笔记再考虑语义分块。4.3 向量化与索引构建分块完成后批量调用嵌入模型生成向量。这里有几个实操细节批量大小不要一条一条调也不要一次调几千条。我一般用32或64作为批量大小兼顾吞吐和内存。失败重试嵌入API偶尔会超时或限流一定要加重试机制。我习惯用指数退避重试3次每次间隔翻倍。增量更新知识库不是一次建完就不动了。新文档进来、旧文档更新都要能增量索引。向量库要支持upsert并且用文档ID作为主键避免重复。索引参数如果用FAISSIVF索引的nlist参数影响检索速度和精度。经验公式是nlist sqrt(N)N是向量总数。比如10万条向量nlist设316左右。如果用HNSWefConstruction和efSearch需要调一般efConstruction200、efSearch64起步。4.4 检索策略单路召回不够混合检索才稳只用向量检索会遇到两个问题一是专有名词、型号、代码这类精确匹配查不准二是相似度阈值不好定太低召回噪声太高漏召回。我的做法是三路召回重排序向量召回用嵌入相似度取Top 20关键词召回用BM25或Elasticsearch的全文检索取Top 20元数据过滤如果用户问题里有时效性要求比如“最新的政策”按时间过滤三路结果合并去重后用交叉编码器比如bge-reranker做精排取Top 5喂给生成模型。重排序这一步很关键。向量召回是双编码器快但精度有限交叉编码器把问题和文档拼在一起编码精度高但慢。先用双编码器粗筛再用交叉编码器精排是速度和精度的平衡点。4.5 生成约束让模型“有据可依”检索到内容后怎么让模型不编造我的prompt模板大概是这样的你是一个基于知识库回答问题的助手。请严格根据以下检索到的内容回答问题。 检索内容 {context} 用户问题{question} 回答要求 1. 只使用检索内容中的信息不要添加外部知识 2. 如果检索内容不足以回答问题直接说“根据现有资料无法回答” 3. 回答时标注信息来源格式为[来源: 文件名, 页码] 4. 如果检索内容中有矛盾指出矛盾并说明这个模板的关键是第2条和第3条。第2条给模型一个“不知道”的出口避免硬编第3条强制引用方便用户核实也方便你排查检索质量问题。实操心得我试过在prompt里加“如果检索内容不相关请忽略”结果模型经常把相关的内容也忽略了。后来改成“只使用检索内容中的信息”效果好很多。措辞的细微差别对模型行为影响很大建议多试几版。5. 用户记忆的抽取与召回让Agent真正“认识”用户5.1 记忆抽取的时机与方式记忆抽取不是每轮对话都做那样成本太高而且噪声大。我的策略是实时抽取用户明确表达个人信息时“我叫XX”“我在XX公司”“我的邮箱是XX”立即抽取并写入。异步抽取对话结束后用LLM对整段对话做摘要抽取值得长期保留的事实。这个可以批量做比如每小时跑一次。触发式抽取用户说“记住”“以后都”“下次”这类词时触发抽取。抽取的prompt要设计得克制。我见过有人让模型“尽可能多地抽取用户信息”结果模型把“用户说今天天气不错”也抽成“用户关注天气”。记忆库很快就被噪声填满了。我的抽取prompt核心要求是只抽取稳定的、可验证的、对未来交互有价值的事实。具体包括身份信息、偏好、技能、关系、重要日期、明确的需求或约束。临时情绪、闲聊内容、重复信息不抽取。5.2 记忆的存储结构我用的表结构大概是这样的CREATE TABLE user_memory ( id BIGSERIAL PRIMARY KEY, user_id VARCHAR(64) NOT NULL, memory_type VARCHAR(32) NOT NULL, -- identity, preference, skill, relation, event content TEXT NOT NULL, confidence FLOAT DEFAULT 1.0, source_dialog_id VARCHAR(64), created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP, -- NULL表示永久 is_active BOOLEAN DEFAULT TRUE );向量库里存的是content字段的嵌入metadata里带user_id和memory_type检索时先按user_id过滤再按相似度排序。5.3 记忆召回的时机与策略不是每轮对话都要召回记忆。我的做法是用户问题里出现“我”“我的”“之前”“上次”等指代词时触发记忆召回用户问题涉及个性化推荐、偏好判断时触发记忆召回其他情况只召回最近几轮对话的短期上下文召回时先按user_id过滤再取Top 5相关记忆。如果记忆之间有冲突比如两条居住地记录按confidence和updated_at排序取最新的高置信度记录。踩过的坑早期我没做user_id过滤结果A用户的记忆被召回给了B用户差点造成隐私事故。后来在向量库层面强制加了user_id的标量过滤并且在应用层做了二次校验。这件事让我意识到记忆系统的隔离性比召回精度更重要。5.4 记忆的更新与遗忘记忆不是越多越好。过时的、错误的记忆会干扰召回。我设计了三种遗忘机制时效性遗忘expires_at到期的记忆自动标记为inactive。比如“用户下周出差”这条记忆两周后就失效了。覆盖式更新新记忆和旧记忆冲突时旧记忆标记为inactive新记忆写入。比如用户说“我换工作了”旧的职业信息失效。置信度衰减长时间未被召回的边缘记忆置信度逐渐降低低于阈值后归档。这些机制不需要很复杂但一定要有。我见过跑了半年的Agent记忆库里堆了几万条记录召回时噪声比信号还多效果还不如没有记忆。6. 常见问题与排查技巧实录6.1 检索不准先查分块再查嵌入最后查查询检索不准是最常见的问题。我的排查顺序是第一步看分块。把检索到的块打印出来看内容是否完整、是否相关。如果块本身就不对后面怎么调都没用。第二步看嵌入。用几个典型问题手动算一下和文档块的相似度看排序是否符合直觉。如果不符合可能是嵌入模型不适合你的领域考虑换模型或微调。第三步看查询。用户的问题往往很短、很口语化和文档的书面语有差距。可以加一个查询改写步骤用LLM把用户问题改写成更适合检索的形式。第四步看阈值。相似度阈值设得太高相关文档被过滤设得太低噪声进来。我一般先用0.7作为起点根据实际效果调整。6.2 模型编造检索到了但不用或者没检索到硬编模型编造有两种情况检索到了但不用通常是prompt约束不够强或者检索内容太长模型注意力分散。解决办法是加强prompt约束或者把检索内容精简后再喂。没检索到硬编模型不知道“不知道”硬着头皮编。解决办法是在prompt里明确给出“无法回答”的出口并且在检索阶段设置一个最低相似度阈值低于阈值就不传给模型直接返回“未找到相关信息”。6.3 并发扛不住瓶颈通常在嵌入和向量检索Agent扛并发瓶颈一般不在LLM生成可以排队而在嵌入和向量检索。嵌入模型如果是本地部署推理速度决定了吞吐。bge-small在GPU上大概能跑几百QPSbge-large可能只有几十。如果并发高要么用更小的模型要么加GPU要么用云端嵌入API。向量检索的瓶颈在索引类型。FAISS的Flat索引是暴力搜索百万级向量查询延迟可能到几百毫秒IVF或HNSW能降到几毫秒。如果并发高优先用HNSW。还有一个容易被忽略的点缓存。相同或相似的问题检索结果可以缓存。我用Redis缓存查询的嵌入和检索结果命中率能到30%以上显著降低后端压力。6.4 常见问题速查表现象可能原因排查方向解决思路检索结果不相关分块不合理打印检索块内容调整分块策略检索结果不相关嵌入模型不匹配手动算相似度换模型或微调检索结果不相关查询太短看用户原始问题加查询改写模型编造prompt约束弱检查prompt加强约束、加引用要求模型编造检索内容太长看context长度精简检索内容召回率低阈值太高看相似度分布降低阈值或加多路召回召回噪声大阈值太低看相似度分布提高阈值或加重排序响应慢嵌入推理慢看嵌入耗时换小模型或加GPU响应慢向量检索慢看索引类型换HNSW或加缓存记忆冲突更新策略缺失看记忆表加覆盖和遗忘机制6.5 几个独家避坑技巧技巧一给检索结果加“新鲜度”权重。知识库里的文档有新旧之分用户通常更关心新内容。我在重排序时给新文档加了一个小的分数加成效果比单纯按相似度排好。技巧二用户记忆和知识库检索分开做不要混在一个向量库里。混在一起会导致检索时互相干扰而且权限管理也麻烦。分开建库检索时分别召回在生成层合并。技巧三定期做检索质量评估。我每周会抽100个真实用户问题人工标注正确答案然后跑一遍检索算Hit Rate和MRR。没有评估调优就是盲人摸象。技巧四给用户一个“纠错”入口。用户发现回答不对时可以点“这个回答有问题”系统记录下问题和检索结果用于后续分析。这个反馈闭环比任何自动评估都值钱。技巧五知识库文档的元数据要丰富。除了文件名和页码我还加了文档类型、更新时间、作者、部门。检索时可以根据用户身份过滤比如普通员工看不到HR文档也可以根据问题类型过滤比如问流程时优先召回制度文档。7. 进阶方向从基础RAG到Agentic RAG基础RAG跑通之后下一步可以考虑几个进阶方向。多跳检索有些问题需要多次检索才能回答。比如“我们公司和竞品在定价策略上有什么差异”需要先检索自家定价再检索竞品定价再对比。Agentic RAG可以让模型自己决定检索几次、检索什么。GraphRAG把知识库里的实体和关系抽出来建成图。检索时不仅用向量相似度还用图上的关联关系。适合实体关系复杂的领域比如医疗、法律、金融。多模态知识库知识库里不只有文本还有图片、表格、图表。用多模态嵌入模型统一索引检索时文本和图片一起召回。这个方向目前还在早期但进展很快。个性化记忆增强用户记忆不仅用于对话还可以用于检索排序。比如用户是技术背景检索时优先召回技术文档用户是销售背景优先召回案例和话术。这个需要把用户画像和检索策略打通。记忆的主动遗忘与隐私保护用户有权要求删除自己的记忆。系统需要支持按用户ID批量删除记忆和向量并且确保删除后不再被召回。这个在合规层面越来越重要。8. 我个人的一些实操体会做用户记忆和知识库这套东西最大的感受是效果好不好八成取决于数据质量两成取决于算法。我见过团队花两个月调检索算法提升不到5个点后来花一周整理文档、优化分块效果直接翻倍。文档本身结构清晰、内容准确比任何花哨的检索技巧都管用。另一个体会是不要追求一步到位。先跑通最小闭环——几个文档、一个向量库、一个简单的检索和生成——然后拿真实用户问题去测根据反馈迭代。我见过太多人一开始就设计复杂的多路召回、重排序、记忆抽取结果每个环节都有bug调都不知道从哪调起。还有一点用户记忆的隐私边界要提前想清楚。哪些信息可以记、记多久、谁能看、用户能不能删这些不是技术问题但技术方案必须支持。我习惯在记忆表里加一个source字段记录每条记忆来自哪次对话方便审计和删除。最后分享一个小技巧给检索结果加一个“置信度”标签。高置信度的结果直接生成回答中等置信度的结果在回答里加一句“根据现有资料可能...”低置信度的结果直接说“未找到相关信息”。这样用户对回答的可靠性有预期体验反而更好。这套系统没有银弹但每一步都有相对靠谱的实践。把分块做好、把检索做稳、把记忆管住、把评估做起来效果就不会差。剩下的就是根据你的具体场景慢慢磨了。