聊到 500 楼她还记得第 1 楼——我给 AI 聊天装了个记忆库如果你用过一些 AI 对话工具尤其是那些号称能进行“长对话”的可能遇到过这种情况聊到后面AI 要么开始胡言乱语要么干脆忘了你们之前聊过什么。这背后一个核心问题就是上下文长度限制和记忆管理失效。今天要聊的就是怎么给 AI 聊天真正装上一个靠谱的“记忆库”让它能记住几百上千条对话里的关键信息而不是像个金鱼只有七秒记忆。这不仅仅是调个参数那么简单。它涉及到从对话中提取关键事实、建立记忆索引、在需要时精准检索以及处理“记忆冲突”和“记忆更新”。我基于一些开源项目和自己的实践整理了一套可落地的方案核心目标是让 AI 在超长对话中依然能保持对早期关键信息的理解和引用并且这个过程对用户是透明、可控的。下面我会从为什么需要记忆库、记忆库的核心组件、如何搭建和集成、以及最重要的——如何验证和测试它的效果一步步拆解。无论你是想优化自己的 AI 应用体验还是在进行 AI Agent 或对话系统的开发这套思路都能直接拿来参考。1. 先拆解问题长对话失忆到底卡在哪很多人觉得给模型一个超长的上下文窗口比如 128K、200K问题就解决了。但实测下来这只是把“记不住”变成了“记混乱”。模型可能会把不同时间点、甚至互相矛盾的信息混在一起回答或者对早期细节的引用变得模糊不清。这不仅仅是技术限制更是工程问题。1.1 模型自身的“注意力稀释”即使上下文窗口很长Transformer 架构的注意力机制在处理超长序列时对序列开头部分的“注意力权重”也会自然衰减。你可以理解为模型“看”最后几百个 token 最清楚再往前就越来越模糊。这不是 bug是架构特性。单纯加长窗口就像让人一口气读完一本厚书然后立刻回答问题对开头章节的细节必然印象模糊。1.2 纯文本上下文的效率陷阱把所有历史对话都堆在上下文里每次对话都重新发送会产生几个问题成本高昂大多数 API 按 token 数计费重复发送历史记录意味着巨大的浪费。速度下降模型处理长序列的计算时间显著增加。关键信息淹没重要的用户偏好、人物设定、关键事实被淹没在大量的日常寒暄和无关对话中。1.3 我们需要什么样的记忆一个有效的记忆库不应该只是聊天记录的备份。它需要具备提取与摘要能自动从对话流中抽取出事实性信息如“用户喜欢咖啡”、“项目 deadline 是周五”、用户偏好和关键承诺。结构化存储以结构化的方式例如向量、图数据库或简单键值对存储这些记忆并附上时间戳、重要性权重等元数据。按需检索在生成新回复时能根据当前对话的上下文快速、准确地检索出相关的记忆片段并只将这些片段而非全部历史注入给模型。更新与维护记忆可能过时、矛盾或失效系统需要能合并、更新或归档旧记忆。理解了这些我们再来看具体怎么做。2. 记忆库的核心组件与选型一个完整的记忆系统通常包含以下几个部分。我会给出一些常见的开源工具选型但更重要的是理解每个部分的作用。2.1 记忆提取器这是记忆库的“输入端”负责从原始对话中识别和提取值得记忆的内容。做什么分析每轮或每几轮对话判断其中是否包含应被长期记忆的信息事实、偏好、任务、承诺等。怎么做规则启发式简单但有效。例如识别包含“我喜欢”、“我讨厌”、“我住在”、“我的目标是”等模式的句子。用小模型分类训练或使用一个轻量级文本分类模型判断一段文本是否属于“可记忆事实”。用大模型本身在对话间歇让大模型如 GPT-4, Claude, 或本地小模型对最近一段对话进行总结并提取关键实体和关系。这是最灵活、准确的方式但会增加延迟和成本。实践建议初期可以从规则开始快速验证流程。稳定后可以引入一个专门的小模型如经过微调的 BERT 类模型来做提取平衡效果和速度。对于对记忆质量要求极高的场景再用大模型做精炼。2.2 记忆存储器这是记忆库的“数据库”负责存储提取出来的记忆。选型考量向量数据库如Chroma,Weaviate,Qdrant,Milvus。这是目前最主流的选择。将记忆文本编码成向量存储便于后续基于语义相似度进行检索。适合记忆条目多、检索需求灵活的场景。图数据库如Neo4j。如果记忆之间存在复杂的关系如人物、地点、事件的关联图数据库能更好地存储和查询这些关系网络。传统数据库/缓存如SQLite,Redis。如果记忆结构简单键值对或对速度要求极高这是更轻量的选择。可以用 JSON 字段存储记忆内容。实践建议对于大多数聊天应用向量数据库是首选。Chroma轻量易用适合入门和快速原型Weaviate功能更全自带向量化和模块化设计Qdrant性能出色适合生产环境。选择时考虑部署复杂度、社区支持和与现有技术栈的整合度。2.3 记忆检索器这是记忆库的“输出端”负责在生成回复时找到相关的记忆。核心流程查询构造根据当前最新的用户消息和可能的最近几轮对话构造一个搜索查询Query。语义搜索将查询编码成向量在向量数据库中进行相似度搜索如余弦相似度找出最相关的 K 条记忆。时间/重要性加权单纯的语义搜索可能找回很久以前但不那么相关的记忆。因此需要引入时间衰减因子越近的记忆权重越高和重要性分数提取时赋予的权重对搜索结果进行重新排序。相关性过滤设定一个相似度阈值过滤掉相关性太低的记忆避免引入噪声。进阶技巧混合检索。结合关键词搜索BM25和向量搜索可以同时保证召回率和精确度。一些向量数据库如 Weaviate已内置此功能。2.4 记忆合成器这是记忆库与对话模型的“连接器”负责将检索到的记忆以合适的格式“喂”给大模型。关键点如何组织记忆提示Prompt。常见模式你是一个有帮助的助手并且拥有以下长期记忆 - [记忆1]用户曾说过他喜欢喝美式咖啡不喜欢加糖。 - [记忆2]用户正在进行的项目“AI记忆库”的截止日期是本周五。 - [记忆3]用户有一只名叫“奥利奥”的猫。 当前对话历史 用户今天好累需要提神。 你实践建议明确标注用“长期记忆”、“用户背景”等标签将记忆与当前对话历史区分开。控制数量不要一次性注入太多条记忆如超过10条以免干扰模型。只注入最相关的几条。格式化使用清晰、简洁的列表或自然语言段落来描述记忆。3. 动手搭建从零集成一个记忆模块理论说完了我们来看一个具体的实现方案。这里我以SillyTavern一个流行的本地 AI 聊天前端为例讲解如何为其添加外部记忆库。这个思路可以迁移到任何基于 API 的聊天应用。3.1 环境与工具准备假设我们的技术栈如下对话前端/客户端SillyTavernST。它负责界面和基本的对话管理。大模型 API可以是 OpenAI GPT Claude 或本地部署的 Llama、Qwen 等通过兼容 API如 Ollama、OpenAI-Compatible API提供服务的模型。记忆服务我们将要构建的一个独立的 Python 服务提供记忆的存储和检索接口。向量数据库选用Chroma因为它最简单可以纯内存或持久化。你需要准备安装 Python 3.8。安装 SillyTavern从 GitHub 拉取即可。一个可用的模型 API 端点本地或云端。3.2 构建记忆服务我们创建一个简单的memory_service.pyimport json from datetime import datetime from typing import List, Dict, Any import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer # 用于本地文本向量化 class MemoryBank: def __init__(self, persist_directory: str “./chroma_db”): # 初始化 Chroma 客户端 self.client chromadb.PersistentClient(pathpersist_directory) # 创建或获取一个集合类似于数据库的表 self.collection self.client.get_or_create_collection(name“conversation_memories”) # 加载本地句子编码模型可选如果不想用 Chroma 默认的 self.encoder SentenceTransformer(‘all-MiniLM-L6-v2’) # 轻量级模型 def extract_memory(self, conversation_turn: Dict[str, str]) - List[str]: “”” 简单的记忆提取器。 这里实现一个规则如果用户消息包含‘我’动词/形容词简化或助手消息包含重要确认则提取。 实际应用中这里可以替换为更复杂的模型或调用大模型 API。 “”” memories [] user_msg conversation_turn.get(“user”, “”).lower() assistant_msg conversation_turn.get(“assistant”, “”).lower() # 示例规则提取用户陈述的偏好或事实 if “我喜欢” in user_msg or “我讨厌” in user_msg or “我是” in user_msg: memories.append(user_msg) # 示例规则提取助手确认的重要信息 if “记住了” in assistant_msg or “好的你” in assistant_msg: # 可以尝试关联上下文提取更具体的记忆 memories.append(f“Context: {user_msg} - Assistant acknowledged.”) return memories def store_memory(self, memory_text: str, conversation_id: str, timestamp: datetime None): “””存储一条记忆到向量数据库“”” if not timestamp: timestamp datetime.now() # 生成向量 embedding self.encoder.encode(memory_text).tolist() # 生成唯一 ID mem_id f“{conversation_id}_{timestamp.timestamp()}” # 存入 Chroma self.collection.add( documents[memory_text], embeddings[embedding], metadatas[{“conversation_id”: conversation_id, “timestamp”: timestamp.isoformat()}], ids[mem_id] ) print(f“Memory stored: {memory_text}”) def retrieve_memories(self, query: str, conversation_id: str, top_k: int 5) - List[str]: “””根据查询检索相关记忆“”” # 也可以对查询进行向量化 query_embedding self.encoder.encode(query).tolist() # 在 Chroma 中搜索可以过滤只属于当前对话的记忆 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k, where{“conversation_id”: conversation_id} # 可选限制在当前对话内检索 ) if results and results[‘documents’]: return results[‘documents’][0] # 返回最相关的 top_k 条记忆文本 return [] # 示例用法 if __name__ “__main__”: bank MemoryBank() # 模拟一轮对话 turn {“user”: “我最喜欢的颜色是蓝色而且我养了一只狗”, “assistant”: “好的我记住了你喜欢蓝色并且有一只狗。”} extracted bank.extract_memory(turn) for mem in extracted: bank.store_memory(mem, conversation_id“test_conv_1”) # 模拟检索 query “用户有什么宠物吗” relevant_mems bank.retrieve_memories(query, conversation_id“test_conv_1”) print(“Retrieved memories:”, relevant_mems)这个服务提供了最基础的功能基于规则的记忆提取、向量化存储和语义检索。3.3 将记忆服务集成到 SillyTavernSillyTavern 支持通过“扩展”Extensions和“API 连接”来增强功能。我们可以通过两种方式集成方式一使用 SillyTavern 的“外部扩展”功能推荐在 ST 的public/scripts/extensions/目录下创建一个新文件夹例如memory-bank。编写一个前端脚本监听 ST 的消息发送事件。在消息发送给模型 API之前脚本将当前的对话上下文或最近几轮发送给你的记忆服务。记忆服务返回相关记忆脚本将这些记忆插入到 ST 即将发送给模型的系统提示System Prompt或用户消息之前。这需要对 ST 的扩展机制有一定了解但能做到无缝集成。方式二代理模式Proxy启动你的记忆服务并额外创建一个“代理 API”端点。将 SillyTavern 中配置的模型 API 地址如http://localhost:11434/v1改为你的代理地址如http://localhost:8000/proxy。你的代理服务收到 ST 的请求后从请求中提取出完整的对话历史。调用记忆服务的检索接口获取相关记忆。将记忆和原始对话历史重新组装形成新的提示转发给真正的模型 API如 Ollama。将模型 API 的回复返回给 ST。这种方式更通用不依赖于 ST 的具体实现但会引入额外的网络跳转。集成关键点触发时机最好在每轮用户消息发送时触发检索而不是每次助手回复时。记忆注入位置通常放在系统提示System Prompt中作为对话的“背景知识”。对话 ID确保你的记忆服务能区分不同对话或不同角色Character通常需要从 ST 传递一个唯一的会话标识符。4. 效果验证与基准测试怎么知道记忆真的有用搭建完了怎么测试它是不是真的解决了“长对话失忆”的问题不能光靠感觉需要设计一些可量化的测试。4.1 设计你的“记忆基准测试”你可以创建一套标准化的测试对话脚本模拟长对话过程并在关键节点进行提问。测试用例示例事实记忆在对话第 10 轮用户说“我叫 Alex住在北京。”在对话第 200 轮提问“我之前告诉过你我叫什么住在哪里吗”期望AI 应能准确回答“Alex”和“北京”。偏好记忆在对话第 50 轮用户说“我对花生严重过敏。”在对话第 300 轮用户说“推荐一家餐厅吧。”期望AI 推荐的餐厅不应包含花生制品或应主动提醒过敏风险。任务/承诺记忆在对话第 30 轮用户说“帮我制定一个本周五前完成项目报告的计划。”在对话第 150 轮用户说“我现在的进度怎么样了”期望AI 应能联系到之前的“项目报告”和“周五截止”这个上下文。4.2 执行测试与评估对照组设置A组无记忆库使用原始模型上下文窗口设为足够长如 8K将全部历史对话放入上下文。B组有记忆库使用你的记忆库方案上下文窗口可以设小如 2K只放入最近对话检索到的记忆。运行测试用脚本自动化运行上述测试用例记录 AI 的回复。评估指标准确性回答是否包含了关键事实如名字、地点。可以用字符串匹配或让另一个 AI 模型来评分。相关性回答是否与早期信息逻辑自洽。资源消耗对比两组的 token 使用量成本、响应延迟。长期稳定性将对话拉长到 500 轮、1000 轮观察记忆准确性是否显著下降。4.3 分析结果与迭代如果有记忆库组在长对话中的事实准确性显著高于无记忆库组说明你的记忆提取和检索是有效的。如果效果不明显检查记忆提取是否太保守漏掉了关键信息记忆检索的相似度阈值是否合适是否因为时间衰减权重不对导致总是检索到不相关的旧记忆记忆合成的提示词是否清晰模型是否真的“理解”了这些记忆是背景信息如果有记忆库组的响应速度慢很多需要优化检索速度如缓存、索引优化或减少每次注入的记忆条数。5. 进阶优化与避坑指南一个能跑起来的记忆库只是第一步要让它稳定、好用还需要考虑下面这些实际问题。5.1 记忆的冲突、更新与遗忘冲突用户先说“我喜欢猫”后来说“我其实更爱狗”。记忆库中可能同时存在两条矛盾记忆。解决在存储新记忆时检查是否存在语义高度相似但内容矛盾的旧记忆。可以设计一个冲突解决策略例如“以最新为准”或者将两条记忆都保留但标记为“冲突”在检索时同时返回让模型判断。更新用户的地址从“北京”换到了“上海”。解决同冲突处理。更好的方式是建立记忆的“实体-属性”关联。当检测到关于同一实体如“用户的居住地”的新记忆时更新该属性的值而不是简单新增一条。遗忘不是所有信息都需要永久记忆。一些临时性、场景性的信息应该被自动清理。解决为每条记忆设置一个“过期时间”或“重要性衰减函数”。低重要性、过时的记忆在检索时排名靠后或定期从活跃存储迁移到归档存储。5.2 性能与成本权衡提取频率每轮对话都提取记忆还是每 N 轮提取一次高频提取更及时但增加计算负担低频提取可能遗漏信息。检索频率同上。通常每轮用户消息都检索是合理的。向量模型选择使用庞大的模型如text-embedding-ada-002精度高但慢且贵使用小型本地模型如all-MiniLM-L6-v2快且免费但精度略有损失。根据场景选择。记忆条数限制一个对话会话最多存储多少条记忆防止数据库无限膨胀。5.3 与现有生态的整合SillyTavern 角色卡角色卡Character Card本身包含背景设定。你的记忆库应该与角色卡信息互补而不是覆盖。可以将角色卡信息作为“初始记忆”预加载到记忆库中。其他扩展SillyTavern 可能有其他处理对话历史的扩展。注意协调避免功能冲突或重复处理。多模态记忆如果对话包含图片生成、语音输入记忆库是否需要支持存储和检索非文本信息这是一个更复杂的课题。5.4 几个常见的“坑”过度检索每次注入太多条记忆比如 20 条反而会干扰模型让它无法聚焦在当前对话上。从 3-5 条开始测试。记忆噪声提取器不够精准把“你好”、“谢谢”这样的寒暄也当成记忆存了进去污染了记忆库。加强提取器的过滤条件或引入重要性评分。循环引用AI 的回复被错误地提取为“用户记忆”存了回去导致后续对话出现奇怪的自引用。仔细设计提取规则区分用户消息和助手消息。启动冷新对话开始时记忆库是空的AI 在最初几轮会表现得“没有记忆”。考虑预加载一些通用知识或角色设定作为种子记忆。给 AI 聊天加上一个有效的记忆库本质上是在弥补当前大模型在超长上下文处理上的工程缺陷。它不是一个“魔法开关”而是一个需要精心设计数据流、检索策略和更新机制的系统。最关键的收获不是某个具体的代码片段而是这套**“提取-存储-检索-合成”的框架思维**。你可以用简单的规则和 Chroma 快速验证想法也可以用更复杂的图神经网络和强化学习来优化记忆的关联与推理。开始动手时不要追求一步到位。先用最简单的规则提取器存到 SQLite 里用关键词匹配来检索把整个流程跑通。然后再逐个环节升级换向量检索、优化提取模型、增加冲突解决逻辑。每做一步都像第 4 部分那样设计测试用例来验证效果。这样下来当对话真的进行到第 500 楼时你才能有底气说你的 AI 不仅记得第 1 楼说了什么还能理解那和此刻第 500 楼的话题之间存在着怎样的联系。这才是真正有价值的“长对话”体验。 AI长对话记忆库构建：从Transformer注意力机制到向量检索的工程实践
聊到 500 楼她还记得第 1 楼——我给 AI 聊天装了个记忆库如果你用过一些 AI 对话工具尤其是那些号称能进行“长对话”的可能遇到过这种情况聊到后面AI 要么开始胡言乱语要么干脆忘了你们之前聊过什么。这背后一个核心问题就是上下文长度限制和记忆管理失效。今天要聊的就是怎么给 AI 聊天真正装上一个靠谱的“记忆库”让它能记住几百上千条对话里的关键信息而不是像个金鱼只有七秒记忆。这不仅仅是调个参数那么简单。它涉及到从对话中提取关键事实、建立记忆索引、在需要时精准检索以及处理“记忆冲突”和“记忆更新”。我基于一些开源项目和自己的实践整理了一套可落地的方案核心目标是让 AI 在超长对话中依然能保持对早期关键信息的理解和引用并且这个过程对用户是透明、可控的。下面我会从为什么需要记忆库、记忆库的核心组件、如何搭建和集成、以及最重要的——如何验证和测试它的效果一步步拆解。无论你是想优化自己的 AI 应用体验还是在进行 AI Agent 或对话系统的开发这套思路都能直接拿来参考。1. 先拆解问题长对话失忆到底卡在哪很多人觉得给模型一个超长的上下文窗口比如 128K、200K问题就解决了。但实测下来这只是把“记不住”变成了“记混乱”。模型可能会把不同时间点、甚至互相矛盾的信息混在一起回答或者对早期细节的引用变得模糊不清。这不仅仅是技术限制更是工程问题。1.1 模型自身的“注意力稀释”即使上下文窗口很长Transformer 架构的注意力机制在处理超长序列时对序列开头部分的“注意力权重”也会自然衰减。你可以理解为模型“看”最后几百个 token 最清楚再往前就越来越模糊。这不是 bug是架构特性。单纯加长窗口就像让人一口气读完一本厚书然后立刻回答问题对开头章节的细节必然印象模糊。1.2 纯文本上下文的效率陷阱把所有历史对话都堆在上下文里每次对话都重新发送会产生几个问题成本高昂大多数 API 按 token 数计费重复发送历史记录意味着巨大的浪费。速度下降模型处理长序列的计算时间显著增加。关键信息淹没重要的用户偏好、人物设定、关键事实被淹没在大量的日常寒暄和无关对话中。1.3 我们需要什么样的记忆一个有效的记忆库不应该只是聊天记录的备份。它需要具备提取与摘要能自动从对话流中抽取出事实性信息如“用户喜欢咖啡”、“项目 deadline 是周五”、用户偏好和关键承诺。结构化存储以结构化的方式例如向量、图数据库或简单键值对存储这些记忆并附上时间戳、重要性权重等元数据。按需检索在生成新回复时能根据当前对话的上下文快速、准确地检索出相关的记忆片段并只将这些片段而非全部历史注入给模型。更新与维护记忆可能过时、矛盾或失效系统需要能合并、更新或归档旧记忆。理解了这些我们再来看具体怎么做。2. 记忆库的核心组件与选型一个完整的记忆系统通常包含以下几个部分。我会给出一些常见的开源工具选型但更重要的是理解每个部分的作用。2.1 记忆提取器这是记忆库的“输入端”负责从原始对话中识别和提取值得记忆的内容。做什么分析每轮或每几轮对话判断其中是否包含应被长期记忆的信息事实、偏好、任务、承诺等。怎么做规则启发式简单但有效。例如识别包含“我喜欢”、“我讨厌”、“我住在”、“我的目标是”等模式的句子。用小模型分类训练或使用一个轻量级文本分类模型判断一段文本是否属于“可记忆事实”。用大模型本身在对话间歇让大模型如 GPT-4, Claude, 或本地小模型对最近一段对话进行总结并提取关键实体和关系。这是最灵活、准确的方式但会增加延迟和成本。实践建议初期可以从规则开始快速验证流程。稳定后可以引入一个专门的小模型如经过微调的 BERT 类模型来做提取平衡效果和速度。对于对记忆质量要求极高的场景再用大模型做精炼。2.2 记忆存储器这是记忆库的“数据库”负责存储提取出来的记忆。选型考量向量数据库如Chroma,Weaviate,Qdrant,Milvus。这是目前最主流的选择。将记忆文本编码成向量存储便于后续基于语义相似度进行检索。适合记忆条目多、检索需求灵活的场景。图数据库如Neo4j。如果记忆之间存在复杂的关系如人物、地点、事件的关联图数据库能更好地存储和查询这些关系网络。传统数据库/缓存如SQLite,Redis。如果记忆结构简单键值对或对速度要求极高这是更轻量的选择。可以用 JSON 字段存储记忆内容。实践建议对于大多数聊天应用向量数据库是首选。Chroma轻量易用适合入门和快速原型Weaviate功能更全自带向量化和模块化设计Qdrant性能出色适合生产环境。选择时考虑部署复杂度、社区支持和与现有技术栈的整合度。2.3 记忆检索器这是记忆库的“输出端”负责在生成回复时找到相关的记忆。核心流程查询构造根据当前最新的用户消息和可能的最近几轮对话构造一个搜索查询Query。语义搜索将查询编码成向量在向量数据库中进行相似度搜索如余弦相似度找出最相关的 K 条记忆。时间/重要性加权单纯的语义搜索可能找回很久以前但不那么相关的记忆。因此需要引入时间衰减因子越近的记忆权重越高和重要性分数提取时赋予的权重对搜索结果进行重新排序。相关性过滤设定一个相似度阈值过滤掉相关性太低的记忆避免引入噪声。进阶技巧混合检索。结合关键词搜索BM25和向量搜索可以同时保证召回率和精确度。一些向量数据库如 Weaviate已内置此功能。2.4 记忆合成器这是记忆库与对话模型的“连接器”负责将检索到的记忆以合适的格式“喂”给大模型。关键点如何组织记忆提示Prompt。常见模式你是一个有帮助的助手并且拥有以下长期记忆 - [记忆1]用户曾说过他喜欢喝美式咖啡不喜欢加糖。 - [记忆2]用户正在进行的项目“AI记忆库”的截止日期是本周五。 - [记忆3]用户有一只名叫“奥利奥”的猫。 当前对话历史 用户今天好累需要提神。 你实践建议明确标注用“长期记忆”、“用户背景”等标签将记忆与当前对话历史区分开。控制数量不要一次性注入太多条记忆如超过10条以免干扰模型。只注入最相关的几条。格式化使用清晰、简洁的列表或自然语言段落来描述记忆。3. 动手搭建从零集成一个记忆模块理论说完了我们来看一个具体的实现方案。这里我以SillyTavern一个流行的本地 AI 聊天前端为例讲解如何为其添加外部记忆库。这个思路可以迁移到任何基于 API 的聊天应用。3.1 环境与工具准备假设我们的技术栈如下对话前端/客户端SillyTavernST。它负责界面和基本的对话管理。大模型 API可以是 OpenAI GPT Claude 或本地部署的 Llama、Qwen 等通过兼容 API如 Ollama、OpenAI-Compatible API提供服务的模型。记忆服务我们将要构建的一个独立的 Python 服务提供记忆的存储和检索接口。向量数据库选用Chroma因为它最简单可以纯内存或持久化。你需要准备安装 Python 3.8。安装 SillyTavern从 GitHub 拉取即可。一个可用的模型 API 端点本地或云端。3.2 构建记忆服务我们创建一个简单的memory_service.pyimport json from datetime import datetime from typing import List, Dict, Any import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer # 用于本地文本向量化 class MemoryBank: def __init__(self, persist_directory: str “./chroma_db”): # 初始化 Chroma 客户端 self.client chromadb.PersistentClient(pathpersist_directory) # 创建或获取一个集合类似于数据库的表 self.collection self.client.get_or_create_collection(name“conversation_memories”) # 加载本地句子编码模型可选如果不想用 Chroma 默认的 self.encoder SentenceTransformer(‘all-MiniLM-L6-v2’) # 轻量级模型 def extract_memory(self, conversation_turn: Dict[str, str]) - List[str]: “”” 简单的记忆提取器。 这里实现一个规则如果用户消息包含‘我’动词/形容词简化或助手消息包含重要确认则提取。 实际应用中这里可以替换为更复杂的模型或调用大模型 API。 “”” memories [] user_msg conversation_turn.get(“user”, “”).lower() assistant_msg conversation_turn.get(“assistant”, “”).lower() # 示例规则提取用户陈述的偏好或事实 if “我喜欢” in user_msg or “我讨厌” in user_msg or “我是” in user_msg: memories.append(user_msg) # 示例规则提取助手确认的重要信息 if “记住了” in assistant_msg or “好的你” in assistant_msg: # 可以尝试关联上下文提取更具体的记忆 memories.append(f“Context: {user_msg} - Assistant acknowledged.”) return memories def store_memory(self, memory_text: str, conversation_id: str, timestamp: datetime None): “””存储一条记忆到向量数据库“”” if not timestamp: timestamp datetime.now() # 生成向量 embedding self.encoder.encode(memory_text).tolist() # 生成唯一 ID mem_id f“{conversation_id}_{timestamp.timestamp()}” # 存入 Chroma self.collection.add( documents[memory_text], embeddings[embedding], metadatas[{“conversation_id”: conversation_id, “timestamp”: timestamp.isoformat()}], ids[mem_id] ) print(f“Memory stored: {memory_text}”) def retrieve_memories(self, query: str, conversation_id: str, top_k: int 5) - List[str]: “””根据查询检索相关记忆“”” # 也可以对查询进行向量化 query_embedding self.encoder.encode(query).tolist() # 在 Chroma 中搜索可以过滤只属于当前对话的记忆 results self.collection.query( query_embeddings[query_embedding], n_resultstop_k, where{“conversation_id”: conversation_id} # 可选限制在当前对话内检索 ) if results and results[‘documents’]: return results[‘documents’][0] # 返回最相关的 top_k 条记忆文本 return [] # 示例用法 if __name__ “__main__”: bank MemoryBank() # 模拟一轮对话 turn {“user”: “我最喜欢的颜色是蓝色而且我养了一只狗”, “assistant”: “好的我记住了你喜欢蓝色并且有一只狗。”} extracted bank.extract_memory(turn) for mem in extracted: bank.store_memory(mem, conversation_id“test_conv_1”) # 模拟检索 query “用户有什么宠物吗” relevant_mems bank.retrieve_memories(query, conversation_id“test_conv_1”) print(“Retrieved memories:”, relevant_mems)这个服务提供了最基础的功能基于规则的记忆提取、向量化存储和语义检索。3.3 将记忆服务集成到 SillyTavernSillyTavern 支持通过“扩展”Extensions和“API 连接”来增强功能。我们可以通过两种方式集成方式一使用 SillyTavern 的“外部扩展”功能推荐在 ST 的public/scripts/extensions/目录下创建一个新文件夹例如memory-bank。编写一个前端脚本监听 ST 的消息发送事件。在消息发送给模型 API之前脚本将当前的对话上下文或最近几轮发送给你的记忆服务。记忆服务返回相关记忆脚本将这些记忆插入到 ST 即将发送给模型的系统提示System Prompt或用户消息之前。这需要对 ST 的扩展机制有一定了解但能做到无缝集成。方式二代理模式Proxy启动你的记忆服务并额外创建一个“代理 API”端点。将 SillyTavern 中配置的模型 API 地址如http://localhost:11434/v1改为你的代理地址如http://localhost:8000/proxy。你的代理服务收到 ST 的请求后从请求中提取出完整的对话历史。调用记忆服务的检索接口获取相关记忆。将记忆和原始对话历史重新组装形成新的提示转发给真正的模型 API如 Ollama。将模型 API 的回复返回给 ST。这种方式更通用不依赖于 ST 的具体实现但会引入额外的网络跳转。集成关键点触发时机最好在每轮用户消息发送时触发检索而不是每次助手回复时。记忆注入位置通常放在系统提示System Prompt中作为对话的“背景知识”。对话 ID确保你的记忆服务能区分不同对话或不同角色Character通常需要从 ST 传递一个唯一的会话标识符。4. 效果验证与基准测试怎么知道记忆真的有用搭建完了怎么测试它是不是真的解决了“长对话失忆”的问题不能光靠感觉需要设计一些可量化的测试。4.1 设计你的“记忆基准测试”你可以创建一套标准化的测试对话脚本模拟长对话过程并在关键节点进行提问。测试用例示例事实记忆在对话第 10 轮用户说“我叫 Alex住在北京。”在对话第 200 轮提问“我之前告诉过你我叫什么住在哪里吗”期望AI 应能准确回答“Alex”和“北京”。偏好记忆在对话第 50 轮用户说“我对花生严重过敏。”在对话第 300 轮用户说“推荐一家餐厅吧。”期望AI 推荐的餐厅不应包含花生制品或应主动提醒过敏风险。任务/承诺记忆在对话第 30 轮用户说“帮我制定一个本周五前完成项目报告的计划。”在对话第 150 轮用户说“我现在的进度怎么样了”期望AI 应能联系到之前的“项目报告”和“周五截止”这个上下文。4.2 执行测试与评估对照组设置A组无记忆库使用原始模型上下文窗口设为足够长如 8K将全部历史对话放入上下文。B组有记忆库使用你的记忆库方案上下文窗口可以设小如 2K只放入最近对话检索到的记忆。运行测试用脚本自动化运行上述测试用例记录 AI 的回复。评估指标准确性回答是否包含了关键事实如名字、地点。可以用字符串匹配或让另一个 AI 模型来评分。相关性回答是否与早期信息逻辑自洽。资源消耗对比两组的 token 使用量成本、响应延迟。长期稳定性将对话拉长到 500 轮、1000 轮观察记忆准确性是否显著下降。4.3 分析结果与迭代如果有记忆库组在长对话中的事实准确性显著高于无记忆库组说明你的记忆提取和检索是有效的。如果效果不明显检查记忆提取是否太保守漏掉了关键信息记忆检索的相似度阈值是否合适是否因为时间衰减权重不对导致总是检索到不相关的旧记忆记忆合成的提示词是否清晰模型是否真的“理解”了这些记忆是背景信息如果有记忆库组的响应速度慢很多需要优化检索速度如缓存、索引优化或减少每次注入的记忆条数。5. 进阶优化与避坑指南一个能跑起来的记忆库只是第一步要让它稳定、好用还需要考虑下面这些实际问题。5.1 记忆的冲突、更新与遗忘冲突用户先说“我喜欢猫”后来说“我其实更爱狗”。记忆库中可能同时存在两条矛盾记忆。解决在存储新记忆时检查是否存在语义高度相似但内容矛盾的旧记忆。可以设计一个冲突解决策略例如“以最新为准”或者将两条记忆都保留但标记为“冲突”在检索时同时返回让模型判断。更新用户的地址从“北京”换到了“上海”。解决同冲突处理。更好的方式是建立记忆的“实体-属性”关联。当检测到关于同一实体如“用户的居住地”的新记忆时更新该属性的值而不是简单新增一条。遗忘不是所有信息都需要永久记忆。一些临时性、场景性的信息应该被自动清理。解决为每条记忆设置一个“过期时间”或“重要性衰减函数”。低重要性、过时的记忆在检索时排名靠后或定期从活跃存储迁移到归档存储。5.2 性能与成本权衡提取频率每轮对话都提取记忆还是每 N 轮提取一次高频提取更及时但增加计算负担低频提取可能遗漏信息。检索频率同上。通常每轮用户消息都检索是合理的。向量模型选择使用庞大的模型如text-embedding-ada-002精度高但慢且贵使用小型本地模型如all-MiniLM-L6-v2快且免费但精度略有损失。根据场景选择。记忆条数限制一个对话会话最多存储多少条记忆防止数据库无限膨胀。5.3 与现有生态的整合SillyTavern 角色卡角色卡Character Card本身包含背景设定。你的记忆库应该与角色卡信息互补而不是覆盖。可以将角色卡信息作为“初始记忆”预加载到记忆库中。其他扩展SillyTavern 可能有其他处理对话历史的扩展。注意协调避免功能冲突或重复处理。多模态记忆如果对话包含图片生成、语音输入记忆库是否需要支持存储和检索非文本信息这是一个更复杂的课题。5.4 几个常见的“坑”过度检索每次注入太多条记忆比如 20 条反而会干扰模型让它无法聚焦在当前对话上。从 3-5 条开始测试。记忆噪声提取器不够精准把“你好”、“谢谢”这样的寒暄也当成记忆存了进去污染了记忆库。加强提取器的过滤条件或引入重要性评分。循环引用AI 的回复被错误地提取为“用户记忆”存了回去导致后续对话出现奇怪的自引用。仔细设计提取规则区分用户消息和助手消息。启动冷新对话开始时记忆库是空的AI 在最初几轮会表现得“没有记忆”。考虑预加载一些通用知识或角色设定作为种子记忆。给 AI 聊天加上一个有效的记忆库本质上是在弥补当前大模型在超长上下文处理上的工程缺陷。它不是一个“魔法开关”而是一个需要精心设计数据流、检索策略和更新机制的系统。最关键的收获不是某个具体的代码片段而是这套**“提取-存储-检索-合成”的框架思维**。你可以用简单的规则和 Chroma 快速验证想法也可以用更复杂的图神经网络和强化学习来优化记忆的关联与推理。开始动手时不要追求一步到位。先用最简单的规则提取器存到 SQLite 里用关键词匹配来检索把整个流程跑通。然后再逐个环节升级换向量检索、优化提取模型、增加冲突解决逻辑。每做一步都像第 4 部分那样设计测试用例来验证效果。这样下来当对话真的进行到第 500 楼时你才能有底气说你的 AI 不仅记得第 1 楼说了什么还能理解那和此刻第 500 楼的话题之间存在着怎样的联系。这才是真正有价值的“长对话”体验。