企业官网建设流程全解析

你有没有遇到过这种情况：一个AI助手，昨天还陪着你把项目背景聊得明明白白，今天你打开对话框，它一脸茫然反问“什么项目？”。如果只是做个哄自己玩的Demo，这倒没什么。可一旦要落成客服、知识助手、Agent这类真实产品，这种“失忆”就是致命的。我在实际项目里为这个问题折腾了很久，最后沉淀出一套方案，名字就叫ai-memory。它不是什么神秘黑科技，而是一整套把“记忆”这件事拆开、落地的工程实践。

这篇文章适合正在做对话应用、想要给大模型加“长期记忆”的开发者，也适合那些被上下文窗口逼到墙角的产品经理。我会把整个记忆系统的搭建思路、分层设计、代码链路和真实踩坑经历都摊开讲，尽量让你看完之后，能直接在自己的项目里动手复现。

1. 大模型为什么会“金鱼脑”：先理解记忆缺失的本质

1.1 一次对话都记不全的模型

大模型本质上是一个函数：你给它一段上下文，它预测并输出下一段文字。它没有“硬盘”，没有“数据库”，每次对话都是无状态的。你问它“上回我们说到的那个方案”，它根本没有上回的索引可用。这就是为什么所有AI应用想要聊得久，就得自己解决记忆问题。

这句话听起来简单，但很多人刚上手时会忽略一个关键点：把历史消息一股脑塞进上下文窗口，这不叫记忆，叫搬运。窗口是有限的，长对话聊着聊着就会把前面的信息挤出去，而且搬运价格不菲——每轮都重发全部历史，token消耗会让你账单涨得飞快，响应延迟也跟着上去。

我在做记忆系统之前，用的就是最笨的“全文回放”方案。结果公司客服机器人上线第二天就出了问题：用户在第一轮报了订单编号，聊到第十轮客服机器人开始答非所问，因为它把订单号“忘了”。不是真忘了，是上下文太长了，被早期截断策略吞掉了。从那天起我就明白，必须给大模型外挂一套真正的记忆机制。

1.2 你需要的其实是三种记忆

人的记忆也不是铁板一块。你记得五分钟前同事跟你说的八卦，也记得三年前跳槽的公司名字，还能瞬间回忆起来“今天下午要交周报”这个事实。AI的记忆系统同样需要分层，我把它拆成三类：

• 短期记忆：负责当前会话的连续性，类似于工作记忆，聊到哪跟到哪。
• 长期记忆：跨会话保留的知识、偏好、背景，比如用户的工作单位、项目偏好。
• 事实清单：确定性强、不能模糊的信息，比如用户姓名、截止日期、明确的选择。

这三类需求对应不同的存储和读取策略。一上来就建一套庞大的向量库，把所有对话全丢进去做相似度检索，这种方案我试过，效果很糟糕。原因后面讲，先记住这个结论：记忆系统的设计，必须从“信息怎么分类”开始，而不是从“用什么数据库”开始。

2. Memory三层架构：短期缓冲、语义沉淀和事实清单

2.1 短期记忆层：别让上下文窗口裸奔

短期记忆层的目标很简单：用最少的token，保证当前会话的连贯性。常用的做法是维护一个滑动窗口，只保留最近N轮对话。N选多少，取决于你的模型窗口和预算。

我在项目里用的是Redis List，按会话ID存储最近20轮人机消息。每次对话开始时先拉取窗口内容，注入到System Prompt里。这比“全量回放”省了差不多70%的token消耗，响应速度也快了。

但这层有个很隐蔽的问题：窗口只保留最近20轮，一旦超过这个范围，早期信息就永久丢失了。所以短期记忆层必须和长期记忆层配合，关键信息在掉出窗口之前，必须先“沉淀”到后面的层里去。

2.2 长期记忆层：向量库里的语义沉淀

长期记忆层承担的是“模糊回忆”的功能。用户问“上次说的那个服务器迁移方案到底怎么落地”，这句话里没有明确关键词，但它和几天前某段对话语义相关。靠SQL LIKE是查不出来的，得靠句子向量做相似度召回。

这一层的存储，我用的是向量数据库加一张元数据表。每个记忆条目包括：记忆ID、来源对话ID、消息内容、摘要文本、向量、创建时间、最后访问时间、重要程度评分。

写入时机很关键。我不会拿每条消息都去入库，而是在一轮对话结束后，用模型抽取“值得记住的事实”。比如用户说“我们技术栈是Spring Boot，数据库用的是PostgreSQL”，这句话会被压成一条结构化摘要存起来；而“嗯嗯”、“好的”这类话，直接丢进回收站。

2.3 事实清单层：确定信息单独放

其实很多人做记忆系统时，会忽略第三种记忆。用户说“我每周三下午都有例会”，这句话如果被扔进向量库，到时候召回可能是概率性的——有时召回了，有时没召回。可这事儿用户默认你应该永远记住。

所以我把这类确定性信息单独抽出来，存成结构化的Key-Value事实清单。比如：

{ "user_id": "u_1024", "facts": { "name": "老周", "weekly_meeting": "每周三下午14:00-15:00", "preferred_db": "PostgreSQL", "budget_level": "中等，不追求顶配" } }

事实清单永远优先级最高。每次构造Prompt时，先注入这些强约束事实，再注入长期记忆的召回结果，最后才是短期窗口的最近对话。这样的顺序，模型就不容易出现“角色混乱”或者“前后矛盾”。

3. 一条记忆从写入到生效：压缩、召回注入的完整链路

3.1 什么时候写入：不是每句话都值得记

记忆的第一步不是存，而是判断“该不该记”。我把这个环节叫记忆过滤器。最开始的版本我偷懒，把整轮完整对话直接丢给模型让它写摘要，结果存了一堆“用户问了价格”这种垃圾摘要，召回的时候全是噪音。

后来我改成两步走：

• 用规则先筛一遍：消息长度超过20字、包含明确偏好/事实/任务节点、用户主动纠正AI错误，满足任一条件就进入待提炼队列。
• 再让模型做压缩：把这条消息连同前文上下文一起喂给模型，要求输出格式化的记忆条目，包括类型、实体、内容、置信度。

判断逻辑大概长这样：

def should_extract(message: str) -> bool: if len(message) < 20: return False if any(kw in message for kw in ["我习惯", "我想要", "记住", "不是", "改成", "用不了", "预算"]): return True # 兜底：基于规则的启发式 return extractor_model.predict(message) > 0.7

3.2 压缩摘要：把冗长对话变成记忆单元

记忆条目的设计决定了后续召回到Prompt里的可用性。我用的是这样的结构：

{ "memory_id": "mem_20250118_0213", "type": "preference", "content": "用户倾向使用ClickHouse做日志分析，明确不想引入Hadoop生态", "source_dialog_id": "dialog_20250117_1530", "confidence": 0.92, "created_at": "2025-01-18T10:00:00Z", "updated_at": "2025-01-18T10:00:00Z", "last_access_at": "2025-01-18T10:00:00Z" }

这里最关键的是type字段。我分了四类：preference（用户偏好）、fact（客观事实）、task（任务进度）、decision（决策记录）。分类的意义在于召回后可以按不同类型决定注入权重，比如fact的权重比preference高，task则要结合时效性判断是否还有效。

压缩用的模型不需要太大。我试过用旗舰模型抽取摘要，效果好了那么几个点，但成本和延迟翻了两倍。后来换了个中等规模的模型，把输出格式定义得足够清楚，线上效果基本持平。真正重要的不是模型多强，而是你给它的指令模板是否把记忆条目写得足够结构化。

3.3 召回与注入：让记忆进入模型视野

召回是记忆系统真正见真章的地方。用户发来一句话，我先把它向量化，然后去向量库找Top-K条相关记忆，再用一个重排器把分数和时效性做综合排序，最后把最相关的3到5条注入Prompt。

注入的顺序非常有讲究。我的Prompt模板里划分成三个区块：

1. 事实清单（facts）：最硬的信息，先给。
2. 长期记忆摘要（memory）：召回结果，按相关度降序排列。
3. 最近对话（recent window）：短期记忆滑动窗口。

值得注意的是，召回结果不一定全塞进去。我给每条记忆设了一个门槛分，低于0.75的直接丢弃，宁可让模型不知道，也不能拿错误记忆去误导它。

4. 召回质量是命门：相似不等于有用，时间会稀释一切

4.1 向量召回的翻车现场

只用向量检索做召回，听起来高大上，实战里处处是坑。最典型的一个场景：用户说“就按上次说的办吧”。这句话向量化之后，跟任何具体记忆的相似度都不会高，因为里面没有实体词。你搜“上次说的”，什么都搜不到。

我的解法是混合检索：向量检索负责语义关联，关键词检索负责实体命中，最后把两路结果合并打分。关键词那边我用的是传统BM25，不需要训练，开箱即用。

再举一个例子。用户之前提到“我们准备从单体架构拆成微服务，第一步先把用户模块独立出去”。过了一周，用户问“用户模块那个拆分方案，你帮我细化一下数据库表设计”。纯靠向量召回，可能召回到当时讨论的整段对话，但重点会模糊。加了BM25之后，“微服务”、“用户模块”、“拆分”这些词的权重会被放大，召回结果就精准得多。

4.2 记忆也会“过期”

时间对记忆的腐蚀在AI系统里往往被忽略。我见过一个团队做出来的记忆系统，用户三个月前说“我最近在学Go语言”，三个月后模型还在Prompt里写“用户正在学习Go”，可用户那时候已经入职Go岗位了。

我在召回阶段引入了一个时间衰减因子。每条记忆的最终排序分，不是单纯的相似度分，而是：

最终分 = 相似度分 * 时间衰减系数

时间衰减系数我用指数衰减：

decay = math.exp(-age_days / half_life_days)

half_life_days根据记忆类型设定：decision和task的有效期短，建议7天更新一次权重；fact和preference相对稳定，可以放到30天。这样既兼顾了语义相关性，又让旧记忆不会永远霸占前排。

4.3 同义改写是隐形刺客

中文场景里同义改写特别折磨人。用户在对话里说“甲骨文数据库”，后面提问时却只说“Oracle”。如果向量模型不够强，这条召回可能就断了。我在系统里专门加了一张同义词别名表，抽摘要时把高频实体归一化存储，比如“甲骨文/Oracle”统一成“Oracle”，“宝塔/Panel”统一成“宝塔面板”。

归一化不是上来就做，而是等同一个实体在记忆库里出现了两次以上，我才会做合并。这样能避免过度归一化导致的信息失真。

5. 记忆的成长与淘汰：当记忆不再是一味“往里塞”

5.1 重复写入与冲突覆盖

最早版本的记忆系统，有个很尴尬的问题：用户说一次“我喜欢用VS Code”，系统就写一条。聊个五遍，库里躺着五条几乎一样的“偏好”。召回的时候，五条全被塞进Prompt，浪费token还让模型以为用户对VS Code有某种执念。

现在我给每条记忆加了“合并键”。抽取摘要的时候，先按实体和类型去查一遍库，如果发现已有相同记忆条目，不新建，而是把原条目的content更新掉、updated_at顶上来、confidence重新计算。效果上，用户纠正说法的场景也能被正确处理。比如用户先说“预算控制在三万以内”，隔几天改口“预算提到五万了”，系统不是追加一条新记忆，而是找到原来那条预算记忆，覆盖数值，旧值留在一个hidden字段做审计。

5.2 淘汰策略：能忘才能记住更多

长期下来，记忆库一定会膨胀。我每两周跑一次清理任务，分两个维度做淘汰：

• 低重要度且长期未被访问的记忆：给每条记忆记录last_access_at，超过90天没有被召回过的低置信度条目，直接归档。
• 上下文塞不下的情况：如果召回结果加上事实清单已经超出预算，按“事实清单 > 高置信度近期记忆 > 普通记忆”的顺序筛选，宁可牺牲一部分回忆，也要保住当前对话的质量。

另外，我特别提一句：有些记忆是“一次性的”。用户说“帮我看看这家店的营业时间”，这个问题解决完了，它就不应该长期占用记忆空间。我给这类消息打上ephemeral标记，只保留7天。

5.3 从零散记忆里挖出更强的结论

单条记忆是碎片，真正有价值的是规律。每过一段时间，系统会对记忆库做一次离线统计，尝试提炼“用户级画像摘要”。比如用户反复提到“我们团队人少”、“不想自己运维”、“用云数据库贵”，系统可以综合生成一条“倾向于使用低维护成本的托管服务”的强结论。

这条强结论在召回时享有较高的优先注入权。它的可靠性远比单次对话的记录要高，因为它是跨多次会话沉淀下来的共性。这一步做完，记忆系统才真正从“记事本”变成“懂你的助理”。

6. 实测踩坑记录：从Demo到生产这段路最耗人

6.1 中文embedding选型的教训

我一开始用的是通用英文向量模型，跑中文对话召回，效果不说惨不忍睹吧，至少是忽高忽低。换成在中文语料上训练过的向量模型之后，召回精度肉眼可见地涨了一截。这事的本质不是模型好不好的问题，而是中英文对相似句子的语义空间划分完全不同，英文模型的词表对中文不友好。

后来我又测了一轮开源中文向量模型，发现同一个句子在不同模型上的向量距离表现差异很大。别迷信榜单分数，最好用自己的历史对话数据切出一批query和候选记忆，手工标注一百条地检验召回效果。花一下午做标注，能帮你省下上线后两周的召回调试时间。

6.2 记忆注入太多，模型反而“人格分裂”

有段时间我贪心，把召回分数够的15条记忆全塞进System Prompt，结果模型说话变得特别僵硬，答问题先念一遍“根据您的历史偏好...”。更离谱的是，两条时间接近但内容矛盾的记忆同时被注入后，模型偶尔会自己跟自己打架。比如用户这个月换了新工作，旧公司的长期记忆还是上个月存的，系统没来得及清理，模型就对着新问题给出夹杂旧信息的回答。

修法是给记忆注入设硬顶：普通场景最多注入5条，重要度分的权重拉高，宁可信息少也不能信息杂。

6.3 并发写入下的重复与错乱

记忆抽取通常放在异步任务里做，但异步就会带来并发问题。同一个会话的多轮消息同时触发抽取，或者用户连续改了三次信息，最后库里可能存了三条互相矛盾的版本。我后来在存储层加了唯一索引，按memory_id去重，再给每次写入带一个version字段，冲突时以version大的为准。这套类似乐观锁的做法，能让绝大多数并发冲突自动消解。

6.4 哪些内容不该进记忆库

安全边界问题做记忆系统时必须想清楚。用户报出的手机号、信用卡信息、密码片段，属于绝对不能入库的内容。我的做法是在抽取之前先跑一层敏感信息过滤，命中的字段直接打码替换成占位符，再进后面的流程。这不是什么高深技术，但漏掉它会让你吃大亏。

敏感信息过滤不是一个一次性的开关，因为用户会换着花样表达。比如直接问“微信号是多少”，跟“方便后续联系吗，加您V”，语义完全不同，但都涉及隐私意图。我的规则表里维护了一组常见隐私类型的触发词，配合模型判断双保险。

7. 落地之后关于记忆的几点真实体会

把ai-memory这套系统跑起来之后，我最大的感受是：记忆不是功能，是基础设施。用户不会因为你的AI“记性好”就惊呼，但会因为你的AI“明明聊过却忘了”而流失。前者是隐形加分项，后者是致命扣分项。

我发现在两类产品里，记忆带来的收益最大。一类是长周期任务的场景，比如年度项目协作、跨周的技术咨询；另一类是垂直领域专家的角色，比如法律顾问、健身教练这类需要长期跟踪用户状态的助手。反过来，如果是纯一次性问答工具，记忆系统反而会让用户觉得毛骨悚然——“我就问一次天气，你干嘛要记住我”。

如果只让我做一个最简版本，我会先把短期记忆窗口做好，把事实清单这一层加上，已经能覆盖大部分用户的真实痛点。向量库和长期记忆是后面的事，先把地基打牢比什么都强。

最后再分享一个小技巧：给记忆系统加一个“自我检查”的日志接口，把每次召回的记忆条目和分数全部打出来。调试时你会庆幸自己预留了这个后门——很多看似玄学的问题，一翻日志立刻现形。