1. 项目缘起当AI助手患上“健忘症”你有没有过这样的经历你正在和一个AI助手深入探讨一个复杂的项目比如一个机器学习模型的调优或者一个软件架构的设计。你们已经聊了十几轮你详细解释了业务背景、技术选型的考量、遇到的瓶颈甚至分享了一些关键的代码片段。然后你问了一个基于之前所有对话才能回答的问题比如“那么根据我们刚才讨论的A方案和B方案的优缺点结合我昨天提到的那个数据延迟问题你觉得最终的架构应该怎么定”结果AI助手回给你一个礼貌但令人沮丧的答案“很抱歉我无法访问之前的对话历史。为了提供最佳帮助请重新描述一下您的项目背景、A/B方案的具体内容以及数据延迟问题的细节。”那一刻是不是感觉之前的沟通都白费了就像每次和一位新来的、对历史一无所知的同事开会你必须从头到尾把故事再讲一遍。这正是我过去几个月使用各类AI助手进行深度学习和项目研究时的日常。我把这种每次对话都“从零开始”的体验称为AI的“会话性失忆”。对于需要连续性、累积性思考的学习和研究场景来说这简直是效率杀手。你无法构建一个层层递进的知识图谱每次提问都像是在沙滩上写字潮水新的对话一来痕迹全无。这个痛点促使我思考为什么AI不能像人类一样拥有“持久化记忆”我们的大脑之所以能进行复杂思考正是因为它能存储、关联并调用过往的经验和信息。于是我决定不再等待某个大厂发布这个功能而是自己动手为我的AI学习伙伴注入“记忆”。这个项目的核心目标非常明确构建一个系统让AI助手能够记住跨会话的关键信息、学习偏好和项目上下文从而实现真正连贯、个性化的“学习会话”。2. 核心设计思路为AI打造一个“外部大脑”要实现持久化记忆最直观的想法可能是去修改AI模型本身比如在模型权重中嵌入记忆。但这对于普通开发者来说无异于天方夜谭。因此我的设计思路转向了更务实、更工程化的方案为AI助手构建一个“外部大脑”或“记忆库”。这个“外部大脑”不试图改变AI模型内部的运作机制而是在AI的输入输出流程中扮演一个智能的上下文管理者和信息检索者。其核心工作流可以概括为“存储-关联-检索-注入”四个步骤。2.1 架构总览记忆系统的四大模块整个系统我将其划分为四个核心模块它们协同工作模拟了人类的记忆过程记忆存储模块这是系统的“海马体”负责将每一轮有价值的对话内容以一种结构化的方式保存下来。简单的文本日志是远远不够的。我需要存储的不仅仅是对话原文还包括元数据比如对话的时间、主题、涉及的关键实体如项目名、技术栈、人名、以及用户表达出的明确偏好例如“我不喜欢用Java”、“请用Python举例”。记忆向量化与索引模块这是系统的“大脑皮层”负责将存储的文本记忆转化为计算机能高效理解和检索的形式。我选择了文本嵌入模型将每一段记忆可能是一句话也可能是一段描述转换成一个高维度的向量一组数字。这个向量就像这段文本的“数学指纹”语义相近的文本其向量在空间中的距离也更近。然后我使用一个向量数据库来存储所有这些“指纹”及其对应的原始文本。当需要检索时我不再是进行关键词匹配而是进行“语义搜索”。记忆检索与关联模块这是系统的“前额叶”负责思考“当前用户的问题需要调用过去的哪些记忆”。当用户提出一个新问题时系统首先将这个问题也转化为向量。然后它在向量数据库中进行相似性搜索找出与当前问题最相关的几条历史记忆。这里的“相关”是语义层面的而不仅仅是词汇匹配。例如用户问“TensorFlow和PyTorch在分布式训练上谁更好”系统能关联到之前讨论过“我在AWS上用GPU集群跑过ResNet”和“PyTorch的DistributedDataParallel用起来很顺手”这些记忆。上下文构建与注入模块这是系统的“工作记忆”负责将检索到的相关记忆与当前问题一起巧妙地组合成一段新的、增强版的提示词然后发送给AI助手。这里的关键在于“巧妙”。你不能简单地把10条历史记录堆在提示词里那会严重消耗AI的上下文窗口并可能造成信息干扰。需要设计一个模板清晰地告诉AI“以下是你我过往对话中与当前问题可能相关的背景信息请作为参考。当前的问题是……”2.2 技术选型背后的逻辑为什么选择这样的技术路径这背后有几个关键的考量可行性直接微调或改造GPT、Claude这类大语言模型LLM的“记忆”能力对于个人开发者是封闭的。而构建外部系统利用其提供的API是唯一可行的路径。灵活性外部记忆系统独立于AI模型。这意味着我可以为同一个AI助手连接不同的记忆库比如一个用于工作项目一个用于个人学习或者将来轻松切换不同的AI模型后端而记忆库可以复用。可控性记忆的存储、检索和隐私完全由我掌控。我可以决定记住什么、忘记什么设置记忆过期时间或手动清理所有数据都保存在本地或我信任的服务器上。性能与成本大模型的上下文窗口如GPT-4的128K是宝贵且昂贵的资源。将海量记忆全部塞进上下文是不现实的。向量检索的方式只注入最相关的几条记忆极大地节约了令牌使用量降低了成本也提高了AI处理核心问题的效率。注意这个设计的一个核心前提是当前的主流大语言模型LLM虽然不具备跨会话的持久记忆但它们在一个会话窗口内处理复杂上下文和指令的能力非常强。我们的系统正是通过精心设计的提示词将“长期记忆”转化为“当前会话的上下文”从而激活模型的这种能力。3. 核心细节解析与实操要点明确了“做什么”和“为什么这么做”之后我们来深入拆解“怎么做”的细节。这部分是项目的筋骨每一个设计选择都直接影响最终体验。3.1 记忆存储不只是保存文本记忆存储的第一步是定义“什么值得记”。如果事无巨寸地记录所有对话记忆库很快就会变得臃肿不堪检索效率低下且会引入大量噪声。我制定的记忆捕获策略是用户主动声明当用户说出“请记住这一点……”或“这是我的项目背景……”时系统会将其标记为高优先级记忆。AI输出总结在每一轮对话结束后可以调用一个轻量级的LLM甚至是同一个模型但使用一个简化的指令对刚刚这轮对话的核心信息进行摘要特别是那些涉及事实、决策、偏好的内容。例如将一段关于选择数据库的讨论总结为“用户决定在XX项目中使用PostgreSQL原因是其JSONB功能和对地理空间数据的支持”。关键实体识别使用命名实体识别技术自动提取对话中出现的项目名、技术术语、代码库链接、日期等作为记忆的标签便于后续分类和过滤。存储格式我选择了JSON因为它结构灵活易于扩展。一条典型的内存记录如下{ “id”: “memory_123”, “content”: “用户决定在推荐系统项目中采用协同过滤和内容过滤的混合模型初期使用MovieLens数据集进行验证。”, “embedding”: [0.12, -0.45, 0.78, …], // 由嵌入模型生成的向量 “metadata”: { “timestamp”: “2023-10-27T14:30:00Z”, “session_id”: “session_abc”, “entities”: [“推荐系统”, “协同过滤”, “内容过滤”, “MovieLens”, “Python”], “memory_type”: “decision”, // 类型decision决策, fact事实, preference偏好, code代码 “importance_score”: 0.8 // 手动或自动评估的重要性分数 } }3.2 向量化与检索让AI理解“相似”这是整个系统的技术核心。我选择了OpenAI的text-embedding-3-small模型来生成文本嵌入向量。它足够快效果也很好并且与我的AI助手GPT来自同一生态兼容性最佳。向量数据库的选择上我评估了几个选项ChromaDB轻量级易于集成适合快速原型和本地部署。我的项目初期就使用了它。Pinecone或Weaviate云服务功能强大支持自动扩缩容适合生产环境。如果记忆量非常大数十万条以上我会考虑迁移到这类服务。检索不是简单的“找最相似的”。我实现了混合检索策略语义检索主用当前问题的向量去数据库里找最相似的N条记忆。元数据过滤辅允许用户或系统指定过滤条件。例如“只检索过去一周内标签包含‘机器学习’且类型为‘代码’的记忆”。这能大幅提升检索的精准度。时间衰减加权更近期的记忆通常相关性更高。在计算最终相似度分数时我会给较新的记忆一个轻微的权重加成。3.3 上下文构建与AI对话的艺术检索到相关记忆后如何呈现给AI是关键。糟糕的提示词设计会让AI忽略这些记忆或者产生混淆。我设计的提示词模板如下你是一个拥有持久记忆的AI学习助手。以下是我们过往对话中与当前问题相关的背景信息请仔细阅读并用于理解当前上下文 【相关记忆1】[记忆内容1] 【相关记忆2】[记忆内容2] ...通常限制在3-5条最相关的记忆 当前用户的问题是[用户的新问题] 请基于你的通用知识并结合上述相关记忆给出全面、连贯的回答。如果记忆中的信息与你的知识或当前问题有冲突请以当前问题和你的最佳判断为准。这个模板明确了几个要点角色设定首先告诉AI“你是有记忆的”引导它去使用提供的背景。信息隔离将历史记忆清晰地框定在“相关记忆”区块与当前问题分离避免信息混杂。指令明确要求AI“结合”记忆并给出了冲突处理原则。实操心得记忆注入的顺序也有讲究。经过测试将相关记忆放在系统指令之后、用户问题之前效果最稳定。这符合大多数LLM处理“系统指令-上下文-用户输入”的范式。同时一定要控制注入的记忆条数和总长度避免淹没核心问题。4. 实操过程与核心环节实现下面我将以Python为例展示核心环节的代码实现。假设我们使用OpenAI API作为LLMChromaDB作为本地向量数据库langchain库来简化一些流程但为了理解原理我会拆解关键步骤。4.1 环境搭建与依赖安装首先创建一个新的项目目录并安装必要的包。# 创建项目目录 mkdir ai-memory-assistant cd ai-memory-assistant # 创建虚拟环境推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install openai chromadb langchain langchain-openai tiktokenopenai: 官方SDK用于调用嵌入模型和聊天模型。chromadb: 轻量级向量数据库。langchainlangchain-openai: 提供了构建AI应用链的高级抽象能简化代码但我们也会了解其底层操作。tiktoken: 用于计算文本的令牌数管理上下文长度。4.2 记忆存储与向量化模块实现我们创建一个MemoryManager类来负责核心的记忆操作。import json from datetime import datetime from typing import List, Dict, Any import chromadb from chromadb.config import Settings import openai import tiktoken class MemoryManager: def __init__(self, chroma_persist_dir./chroma_db, openai_api_keyyour-key): # 初始化OpenAI客户端 self.openai_client openai.OpenAI(api_keyopenai_api_key) # 初始化ChromaDB客户端设置持久化目录 self.chroma_client chromadb.PersistentClient(pathchroma_persist_dir) # 获取或创建一个名为“conversation_memories”的集合类似数据库的表 self.collection self.chroma_client.get_or_create_collection(nameconversation_memories) # 初始化令牌编码器用于计算文本长度 self.encoder tiktoken.get_encoding(cl100k_base) # GPT-3.5/4使用的编码 def _generate_embedding(self, text: str) - List[float]: 调用OpenAI嵌入模型生成文本向量 response self.openai_client.embeddings.create( modeltext-embedding-3-small, inputtext ) return response.data[0].embedding def _extract_entities_and_summarize(self, text: str) - Dict[str, Any]: 一个简化的关键信息提取函数。 在实际项目中这里可以集成更复杂的NLP管道如spaCy或调用LLM进行摘要。 此处返回一个模拟的元数据字典。 # 这里可以添加真实的实体识别和摘要逻辑 # 例如调用LLM: “请用一句话总结以下文本的核心信息并提取关键的技术术语作为标签。” metadata { timestamp: datetime.utcnow().isoformat(), estimated_entities: [sample_entity], # placeholder memory_type: fact, importance: 0.5 } return metadata def store_memory(self, content: str, session_id: str, **extra_metadata): 存储一段记忆。 1. 提取元数据。 2. 生成内容向量。 3. 存入向量数据库。 # 1. 准备元数据 base_metadata self._extract_entities_and_summarize(content) base_metadata.update({session_id: session_id}) base_metadata.update(extra_metadata) # 合并外部传入的元数据 # 2. 生成向量 embedding self._generate_embedding(content) # 3. 生成唯一ID这里用时间戳哈希简化 from hashlib import md5 memory_id fmem_{md5(content.encode()).hexdigest()[:10]}_{int(datetime.utcnow().timestamp())} # 4. 存入ChromaDB self.collection.add( documents[content], # 原始文本 embeddings[embedding], # 向量 metadatas[base_metadata], # 元数据 ids[memory_id] # ID ) print(fMemory stored: {memory_id}) return memory_id4.3 记忆检索模块实现在MemoryManager类中继续添加检索方法。def retrieve_relevant_memories(self, query: str, n_results: int 3, filter_dict: Dict None) - List[Dict]: 根据查询检索相关记忆。 1. 将查询文本向量化。 2. 在向量数据库中执行相似性搜索可结合元数据过滤。 3. 返回记忆内容和元数据。 # 1. 生成查询向量 query_embedding self._generate_embedding(query) # 2. 执行查询 # ChromaDB的query方法 results self.collection.query( query_embeddings[query_embedding], n_resultsn_results, wherefilter_dict, # 可选的元数据过滤条件例如 {memory_type: code} include[documents, metadatas, distances] ) # 3. 格式化结果 retrieved_memories [] if results[documents]: for i in range(len(results[documents][0])): memory { content: results[documents][0][i], metadata: results[metadatas][0][i], similarity_score: 1 - results[distances][0][i] # ChromaDB默认使用余弦距离转换为相似度 } retrieved_memories.append(memory) # 可选按时间衰减重新排序简化示例假设metadata里有timestamp retrieved_memories.sort(keylambda x: ( x[similarity_score] * 0.7 self._recency_weight(x[metadata].get(timestamp)) * 0.3 ), reverseTrue) return retrieved_memories[:n_results] # 返回Top N def _recency_weight(self, timestamp_str: str) - float: 计算时间衰减权重越近权重越高0-1之间 if not timestamp_str: return 0.5 try: mem_time datetime.fromisoformat(timestamp_str.replace(Z, 00:00)) now datetime.utcnow() hours_passed (now - mem_time).total_seconds() / 3600 # 简单的指数衰减半衰期设为168小时一周 decay_rate 0.5 ** (hours_passed / 168) return decay_rate except: return 0.54.4 集成AI对话构建有记忆的聊天循环最后我们创建一个主循环将记忆管理器和AI聊天结合起来。class PersistentMemoryAssistant: def __init__(self, memory_manager: MemoryManager, llm_modelgpt-3.5-turbo): self.memory_manager memory_manager self.llm_model llm_model self.current_session_id fsession_{int(datetime.utcnow().timestamp())} self.conversation_buffer [] # 用于临时存储当前会话的对话轮次以便进行摘要 def _build_prompt_with_memory(self, user_query: str) - str: 构建包含相关记忆的最终提示词 # 1. 检索相关记忆 relevant_mems self.memory_manager.retrieve_relevant_memories(user_query, n_results3) # 2. 构建记忆上下文字符串 memory_context if relevant_mems: memory_context 以下是我们过往对话中与当前问题相关的背景信息请作为参考\n\n for i, mem in enumerate(relevant_mems, 1): memory_context f【相关记忆{i}】({mem[metadata].get(memory_type, info)}): {mem[content]}\n memory_context \n # 3. 组合成系统指令 system_message { role: system, content: f你是一个拥有持久记忆的AI学习助手。{memory_context}请基于你的知识并结合上述相关记忆如果存在来回答用户的问题。如果记忆信息与你的知识冲突请以你的最佳判断为准。 } # 4. 用户消息 user_message {role: user, content: user_query} # 返回OpenAI API所需的messages格式 return [system_message, user_message] def chat_cycle(self): 主聊天循环 print(Persistent Memory Assistant 已启动。输入 quit 退出。) while True: user_input input(\nYou: ) if user_input.lower() in [quit, exit, q]: # 在会话结束时可选对本次会话进行摘要并存储为一条高阶记忆 self._summarize_and_store_session() print(会话结束。) break # 1. 构建带记忆的提示词 messages self._build_prompt_with_memory(user_input) # 2. 调用LLM获取回答 try: response self.memory_manager.openai_client.chat.completions.create( modelself.llm_model, messagesmessages, temperature0.7 ) ai_reply response.choices[0].message.content print(f\nAssistant: {ai_reply}) # 3. 将本轮交互的“精华”存储为记忆 # 简单策略将用户输入和AI回答组合后存储。更优策略是调用LLM进行摘要。 interaction_summary fUser: {user_input}\nAssistant: {ai_reply} self.memory_manager.store_memory( contentinteraction_summary, session_idself.current_session_id, memory_typeinteraction ) # 4. 将本轮对话加入缓冲区用于后续可能的会话摘要 self.conversation_buffer.append((user_input, ai_reply)) except Exception as e: print(f调用AI时出错: {e}) def _summarize_and_store_session(self): 可选会话结束时生成一个整体摘要作为一条高阶记忆 if not self.conversation_buffer: return # 这里可以设计一个提示词让LLM总结整个会话的核心议题、结论和决策。 # 例如“请总结以下对话的核心学习要点和达成的共识。” # 然后将总结出的文本通过 store_memory 存储memory_type 可设为 session_summary。 pass # 运行助手 if __name__ __main__: # 初始化记忆管理器需填入你的OpenAI API Key mm MemoryManager(openai_api_keyyour-openai-api-key-here) assistant PersistentMemoryAssistant(mm) assistant.chat_cycle()这段代码实现了一个基础但完整的有记忆AI助手。当你运行它并开始对话后第二次提到相关话题时AI的回答就能体现出对之前讨论内容的“记忆”。5. 常见问题与排查技巧实录在实际构建和使用的过程中我遇到了不少坑也总结出一些让系统更“聪明”的技巧。5.1 记忆检索不准确或无关问题表现AI的回答似乎没有用到该用的记忆或者用到了完全不相关的记忆。排查与解决检查嵌入模型确保用于生成记忆向量和查询向量的模型是同一个。不同模型生成的向量空间不同无法直接比较。优化记忆文本质量存储的“记忆”文本本身需要是自包含、信息密度高的句子或段落。避免存储“嗯”、“好的”这类无意义对话。这就是为什么需要在store_memory前进行摘要或过滤。调整检索数量k值n_results参数需要调优。太小可能遗漏关键记忆太大会引入噪声。可以从3开始根据对话长度和复杂度调整到5或7。引入元数据过滤这是提升精度的利器。在存储时打好标签如project: ml_pipeline,topic: data_cleaning检索时通过filter_dict限定范围。例如当讨论“A项目”时只检索project为A的记忆。审视查询本身有时用户的新问题过于简短或模糊如“上次那个方案怎么样”导致查询向量不明确。可以尝试让系统在检索前先用LLM对当前简短查询进行一次“查询扩展”基于对话历史将其重写为更完整的句子。5.2 上下文过长导致API调用失败或成本激增问题表现OpenAI API返回错误提示上下文长度超限或者账单费用增长过快。排查与解决严格限制单条记忆长度在存储前使用tiktoken计算令牌数对过长的记忆进行强制截断或再次摘要。控制注入的记忆条数和总长在_build_prompt_with_memory函数中不仅限制条数n_results还要累加注入记忆的总令牌数设定一个硬性上限例如1024个令牌。采用更智能的记忆摘要不要存储完整的对话原文。对于较长的讨论存储由LLM生成的精炼摘要。这能极大压缩记忆体积。实现记忆“老化”与清理为记忆设置importance_score和last_accessed_time。可以定期运行一个清理任务删除重要性低且很久未被访问的旧记忆或者将其转移到冷存储。5.3 AI似乎“无视”注入的记忆问题表现相关记忆已经被正确检索并注入到提示词中但AI的回答完全没有体现这些信息。排查与解决优化提示词模板这是最常见的原因。系统指令必须足够清晰和强硬。对比我提供的模板和简单的“以下是一些历史信息[记忆]”前者的效果要好得多。可以尝试在指令中加入“你必须参考以下背景信息”、“你的回答应体现出你对以下历史信息的理解”等更强引导性的语句。检查记忆的相关性手动检查检索到的记忆是否真的与当前问题高度相关。不相关的记忆会干扰AI。可以尝试提高检索的相似度阈值只注入相似度高于某个值如0.8的记忆。调整LLM的温度参数过高的temperature如0.9会增加回答的随机性可能导致AI“放飞自我”忽略上下文。对于需要严谨结合记忆的任务可以适当降低temperature如0.3-0.7。使用更强大的模型如果使用gpt-3.5-turbo效果不佳可以尝试切换到gpt-4。更大的模型在遵循复杂指令和处理长上下文方面通常表现更好。5.4 隐私与数据安全问题核心关切所有对话记忆都存储了下来其中可能包含敏感信息。应对策略本地化部署向量数据库如ChromaDB和整个应用后端部署在你自己的服务器或电脑上。只有向OpenAI API发送的提示词和返回结果会经过其服务器需遵守OpenAI的数据使用政策。记忆加密在将记忆文本存入向量数据库前可以进行对称加密。不过这会使基于内容的语义检索失效因为你无法对加密后的密文生成有意义的向量。一个折中方案是只对元数据中的敏感字段如项目真名、人名进行加密或脱敏处理而记忆内容本身用代号表示。用户控制提供清晰的界面或指令让用户可以查看、编辑或删除特定的记忆。例如实现类似“忘记所有关于[某某项目]的事情”这样的命令。构建这个持久记忆系统的过程让我深刻体会到当前AI应用的创新很大程度上是“提示词工程”和“外部系统设计”的创新。我们无法轻易改变模型的内核但可以通过精巧的架构引导它发挥出远超其基础设计的能力。这个项目不仅解决了我的“AI健忘症”问题更像是一个可扩展的框架未来我可以轻松地为它添加更多功能比如基于记忆的个性化学习计划生成、跨文档的知识关联等等。它让AI从一个“聪明的临时工”变成了一个“持续成长的合作伙伴”。
基于向量数据库与LLM构建AI持久记忆系统：告别会话失忆
1. 项目缘起当AI助手患上“健忘症”你有没有过这样的经历你正在和一个AI助手深入探讨一个复杂的项目比如一个机器学习模型的调优或者一个软件架构的设计。你们已经聊了十几轮你详细解释了业务背景、技术选型的考量、遇到的瓶颈甚至分享了一些关键的代码片段。然后你问了一个基于之前所有对话才能回答的问题比如“那么根据我们刚才讨论的A方案和B方案的优缺点结合我昨天提到的那个数据延迟问题你觉得最终的架构应该怎么定”结果AI助手回给你一个礼貌但令人沮丧的答案“很抱歉我无法访问之前的对话历史。为了提供最佳帮助请重新描述一下您的项目背景、A/B方案的具体内容以及数据延迟问题的细节。”那一刻是不是感觉之前的沟通都白费了就像每次和一位新来的、对历史一无所知的同事开会你必须从头到尾把故事再讲一遍。这正是我过去几个月使用各类AI助手进行深度学习和项目研究时的日常。我把这种每次对话都“从零开始”的体验称为AI的“会话性失忆”。对于需要连续性、累积性思考的学习和研究场景来说这简直是效率杀手。你无法构建一个层层递进的知识图谱每次提问都像是在沙滩上写字潮水新的对话一来痕迹全无。这个痛点促使我思考为什么AI不能像人类一样拥有“持久化记忆”我们的大脑之所以能进行复杂思考正是因为它能存储、关联并调用过往的经验和信息。于是我决定不再等待某个大厂发布这个功能而是自己动手为我的AI学习伙伴注入“记忆”。这个项目的核心目标非常明确构建一个系统让AI助手能够记住跨会话的关键信息、学习偏好和项目上下文从而实现真正连贯、个性化的“学习会话”。2. 核心设计思路为AI打造一个“外部大脑”要实现持久化记忆最直观的想法可能是去修改AI模型本身比如在模型权重中嵌入记忆。但这对于普通开发者来说无异于天方夜谭。因此我的设计思路转向了更务实、更工程化的方案为AI助手构建一个“外部大脑”或“记忆库”。这个“外部大脑”不试图改变AI模型内部的运作机制而是在AI的输入输出流程中扮演一个智能的上下文管理者和信息检索者。其核心工作流可以概括为“存储-关联-检索-注入”四个步骤。2.1 架构总览记忆系统的四大模块整个系统我将其划分为四个核心模块它们协同工作模拟了人类的记忆过程记忆存储模块这是系统的“海马体”负责将每一轮有价值的对话内容以一种结构化的方式保存下来。简单的文本日志是远远不够的。我需要存储的不仅仅是对话原文还包括元数据比如对话的时间、主题、涉及的关键实体如项目名、技术栈、人名、以及用户表达出的明确偏好例如“我不喜欢用Java”、“请用Python举例”。记忆向量化与索引模块这是系统的“大脑皮层”负责将存储的文本记忆转化为计算机能高效理解和检索的形式。我选择了文本嵌入模型将每一段记忆可能是一句话也可能是一段描述转换成一个高维度的向量一组数字。这个向量就像这段文本的“数学指纹”语义相近的文本其向量在空间中的距离也更近。然后我使用一个向量数据库来存储所有这些“指纹”及其对应的原始文本。当需要检索时我不再是进行关键词匹配而是进行“语义搜索”。记忆检索与关联模块这是系统的“前额叶”负责思考“当前用户的问题需要调用过去的哪些记忆”。当用户提出一个新问题时系统首先将这个问题也转化为向量。然后它在向量数据库中进行相似性搜索找出与当前问题最相关的几条历史记忆。这里的“相关”是语义层面的而不仅仅是词汇匹配。例如用户问“TensorFlow和PyTorch在分布式训练上谁更好”系统能关联到之前讨论过“我在AWS上用GPU集群跑过ResNet”和“PyTorch的DistributedDataParallel用起来很顺手”这些记忆。上下文构建与注入模块这是系统的“工作记忆”负责将检索到的相关记忆与当前问题一起巧妙地组合成一段新的、增强版的提示词然后发送给AI助手。这里的关键在于“巧妙”。你不能简单地把10条历史记录堆在提示词里那会严重消耗AI的上下文窗口并可能造成信息干扰。需要设计一个模板清晰地告诉AI“以下是你我过往对话中与当前问题可能相关的背景信息请作为参考。当前的问题是……”2.2 技术选型背后的逻辑为什么选择这样的技术路径这背后有几个关键的考量可行性直接微调或改造GPT、Claude这类大语言模型LLM的“记忆”能力对于个人开发者是封闭的。而构建外部系统利用其提供的API是唯一可行的路径。灵活性外部记忆系统独立于AI模型。这意味着我可以为同一个AI助手连接不同的记忆库比如一个用于工作项目一个用于个人学习或者将来轻松切换不同的AI模型后端而记忆库可以复用。可控性记忆的存储、检索和隐私完全由我掌控。我可以决定记住什么、忘记什么设置记忆过期时间或手动清理所有数据都保存在本地或我信任的服务器上。性能与成本大模型的上下文窗口如GPT-4的128K是宝贵且昂贵的资源。将海量记忆全部塞进上下文是不现实的。向量检索的方式只注入最相关的几条记忆极大地节约了令牌使用量降低了成本也提高了AI处理核心问题的效率。注意这个设计的一个核心前提是当前的主流大语言模型LLM虽然不具备跨会话的持久记忆但它们在一个会话窗口内处理复杂上下文和指令的能力非常强。我们的系统正是通过精心设计的提示词将“长期记忆”转化为“当前会话的上下文”从而激活模型的这种能力。3. 核心细节解析与实操要点明确了“做什么”和“为什么这么做”之后我们来深入拆解“怎么做”的细节。这部分是项目的筋骨每一个设计选择都直接影响最终体验。3.1 记忆存储不只是保存文本记忆存储的第一步是定义“什么值得记”。如果事无巨寸地记录所有对话记忆库很快就会变得臃肿不堪检索效率低下且会引入大量噪声。我制定的记忆捕获策略是用户主动声明当用户说出“请记住这一点……”或“这是我的项目背景……”时系统会将其标记为高优先级记忆。AI输出总结在每一轮对话结束后可以调用一个轻量级的LLM甚至是同一个模型但使用一个简化的指令对刚刚这轮对话的核心信息进行摘要特别是那些涉及事实、决策、偏好的内容。例如将一段关于选择数据库的讨论总结为“用户决定在XX项目中使用PostgreSQL原因是其JSONB功能和对地理空间数据的支持”。关键实体识别使用命名实体识别技术自动提取对话中出现的项目名、技术术语、代码库链接、日期等作为记忆的标签便于后续分类和过滤。存储格式我选择了JSON因为它结构灵活易于扩展。一条典型的内存记录如下{ “id”: “memory_123”, “content”: “用户决定在推荐系统项目中采用协同过滤和内容过滤的混合模型初期使用MovieLens数据集进行验证。”, “embedding”: [0.12, -0.45, 0.78, …], // 由嵌入模型生成的向量 “metadata”: { “timestamp”: “2023-10-27T14:30:00Z”, “session_id”: “session_abc”, “entities”: [“推荐系统”, “协同过滤”, “内容过滤”, “MovieLens”, “Python”], “memory_type”: “decision”, // 类型decision决策, fact事实, preference偏好, code代码 “importance_score”: 0.8 // 手动或自动评估的重要性分数 } }3.2 向量化与检索让AI理解“相似”这是整个系统的技术核心。我选择了OpenAI的text-embedding-3-small模型来生成文本嵌入向量。它足够快效果也很好并且与我的AI助手GPT来自同一生态兼容性最佳。向量数据库的选择上我评估了几个选项ChromaDB轻量级易于集成适合快速原型和本地部署。我的项目初期就使用了它。Pinecone或Weaviate云服务功能强大支持自动扩缩容适合生产环境。如果记忆量非常大数十万条以上我会考虑迁移到这类服务。检索不是简单的“找最相似的”。我实现了混合检索策略语义检索主用当前问题的向量去数据库里找最相似的N条记忆。元数据过滤辅允许用户或系统指定过滤条件。例如“只检索过去一周内标签包含‘机器学习’且类型为‘代码’的记忆”。这能大幅提升检索的精准度。时间衰减加权更近期的记忆通常相关性更高。在计算最终相似度分数时我会给较新的记忆一个轻微的权重加成。3.3 上下文构建与AI对话的艺术检索到相关记忆后如何呈现给AI是关键。糟糕的提示词设计会让AI忽略这些记忆或者产生混淆。我设计的提示词模板如下你是一个拥有持久记忆的AI学习助手。以下是我们过往对话中与当前问题相关的背景信息请仔细阅读并用于理解当前上下文 【相关记忆1】[记忆内容1] 【相关记忆2】[记忆内容2] ...通常限制在3-5条最相关的记忆 当前用户的问题是[用户的新问题] 请基于你的通用知识并结合上述相关记忆给出全面、连贯的回答。如果记忆中的信息与你的知识或当前问题有冲突请以当前问题和你的最佳判断为准。这个模板明确了几个要点角色设定首先告诉AI“你是有记忆的”引导它去使用提供的背景。信息隔离将历史记忆清晰地框定在“相关记忆”区块与当前问题分离避免信息混杂。指令明确要求AI“结合”记忆并给出了冲突处理原则。实操心得记忆注入的顺序也有讲究。经过测试将相关记忆放在系统指令之后、用户问题之前效果最稳定。这符合大多数LLM处理“系统指令-上下文-用户输入”的范式。同时一定要控制注入的记忆条数和总长度避免淹没核心问题。4. 实操过程与核心环节实现下面我将以Python为例展示核心环节的代码实现。假设我们使用OpenAI API作为LLMChromaDB作为本地向量数据库langchain库来简化一些流程但为了理解原理我会拆解关键步骤。4.1 环境搭建与依赖安装首先创建一个新的项目目录并安装必要的包。# 创建项目目录 mkdir ai-memory-assistant cd ai-memory-assistant # 创建虚拟环境推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install openai chromadb langchain langchain-openai tiktokenopenai: 官方SDK用于调用嵌入模型和聊天模型。chromadb: 轻量级向量数据库。langchainlangchain-openai: 提供了构建AI应用链的高级抽象能简化代码但我们也会了解其底层操作。tiktoken: 用于计算文本的令牌数管理上下文长度。4.2 记忆存储与向量化模块实现我们创建一个MemoryManager类来负责核心的记忆操作。import json from datetime import datetime from typing import List, Dict, Any import chromadb from chromadb.config import Settings import openai import tiktoken class MemoryManager: def __init__(self, chroma_persist_dir./chroma_db, openai_api_keyyour-key): # 初始化OpenAI客户端 self.openai_client openai.OpenAI(api_keyopenai_api_key) # 初始化ChromaDB客户端设置持久化目录 self.chroma_client chromadb.PersistentClient(pathchroma_persist_dir) # 获取或创建一个名为“conversation_memories”的集合类似数据库的表 self.collection self.chroma_client.get_or_create_collection(nameconversation_memories) # 初始化令牌编码器用于计算文本长度 self.encoder tiktoken.get_encoding(cl100k_base) # GPT-3.5/4使用的编码 def _generate_embedding(self, text: str) - List[float]: 调用OpenAI嵌入模型生成文本向量 response self.openai_client.embeddings.create( modeltext-embedding-3-small, inputtext ) return response.data[0].embedding def _extract_entities_and_summarize(self, text: str) - Dict[str, Any]: 一个简化的关键信息提取函数。 在实际项目中这里可以集成更复杂的NLP管道如spaCy或调用LLM进行摘要。 此处返回一个模拟的元数据字典。 # 这里可以添加真实的实体识别和摘要逻辑 # 例如调用LLM: “请用一句话总结以下文本的核心信息并提取关键的技术术语作为标签。” metadata { timestamp: datetime.utcnow().isoformat(), estimated_entities: [sample_entity], # placeholder memory_type: fact, importance: 0.5 } return metadata def store_memory(self, content: str, session_id: str, **extra_metadata): 存储一段记忆。 1. 提取元数据。 2. 生成内容向量。 3. 存入向量数据库。 # 1. 准备元数据 base_metadata self._extract_entities_and_summarize(content) base_metadata.update({session_id: session_id}) base_metadata.update(extra_metadata) # 合并外部传入的元数据 # 2. 生成向量 embedding self._generate_embedding(content) # 3. 生成唯一ID这里用时间戳哈希简化 from hashlib import md5 memory_id fmem_{md5(content.encode()).hexdigest()[:10]}_{int(datetime.utcnow().timestamp())} # 4. 存入ChromaDB self.collection.add( documents[content], # 原始文本 embeddings[embedding], # 向量 metadatas[base_metadata], # 元数据 ids[memory_id] # ID ) print(fMemory stored: {memory_id}) return memory_id4.3 记忆检索模块实现在MemoryManager类中继续添加检索方法。def retrieve_relevant_memories(self, query: str, n_results: int 3, filter_dict: Dict None) - List[Dict]: 根据查询检索相关记忆。 1. 将查询文本向量化。 2. 在向量数据库中执行相似性搜索可结合元数据过滤。 3. 返回记忆内容和元数据。 # 1. 生成查询向量 query_embedding self._generate_embedding(query) # 2. 执行查询 # ChromaDB的query方法 results self.collection.query( query_embeddings[query_embedding], n_resultsn_results, wherefilter_dict, # 可选的元数据过滤条件例如 {memory_type: code} include[documents, metadatas, distances] ) # 3. 格式化结果 retrieved_memories [] if results[documents]: for i in range(len(results[documents][0])): memory { content: results[documents][0][i], metadata: results[metadatas][0][i], similarity_score: 1 - results[distances][0][i] # ChromaDB默认使用余弦距离转换为相似度 } retrieved_memories.append(memory) # 可选按时间衰减重新排序简化示例假设metadata里有timestamp retrieved_memories.sort(keylambda x: ( x[similarity_score] * 0.7 self._recency_weight(x[metadata].get(timestamp)) * 0.3 ), reverseTrue) return retrieved_memories[:n_results] # 返回Top N def _recency_weight(self, timestamp_str: str) - float: 计算时间衰减权重越近权重越高0-1之间 if not timestamp_str: return 0.5 try: mem_time datetime.fromisoformat(timestamp_str.replace(Z, 00:00)) now datetime.utcnow() hours_passed (now - mem_time).total_seconds() / 3600 # 简单的指数衰减半衰期设为168小时一周 decay_rate 0.5 ** (hours_passed / 168) return decay_rate except: return 0.54.4 集成AI对话构建有记忆的聊天循环最后我们创建一个主循环将记忆管理器和AI聊天结合起来。class PersistentMemoryAssistant: def __init__(self, memory_manager: MemoryManager, llm_modelgpt-3.5-turbo): self.memory_manager memory_manager self.llm_model llm_model self.current_session_id fsession_{int(datetime.utcnow().timestamp())} self.conversation_buffer [] # 用于临时存储当前会话的对话轮次以便进行摘要 def _build_prompt_with_memory(self, user_query: str) - str: 构建包含相关记忆的最终提示词 # 1. 检索相关记忆 relevant_mems self.memory_manager.retrieve_relevant_memories(user_query, n_results3) # 2. 构建记忆上下文字符串 memory_context if relevant_mems: memory_context 以下是我们过往对话中与当前问题相关的背景信息请作为参考\n\n for i, mem in enumerate(relevant_mems, 1): memory_context f【相关记忆{i}】({mem[metadata].get(memory_type, info)}): {mem[content]}\n memory_context \n # 3. 组合成系统指令 system_message { role: system, content: f你是一个拥有持久记忆的AI学习助手。{memory_context}请基于你的知识并结合上述相关记忆如果存在来回答用户的问题。如果记忆信息与你的知识冲突请以你的最佳判断为准。 } # 4. 用户消息 user_message {role: user, content: user_query} # 返回OpenAI API所需的messages格式 return [system_message, user_message] def chat_cycle(self): 主聊天循环 print(Persistent Memory Assistant 已启动。输入 quit 退出。) while True: user_input input(\nYou: ) if user_input.lower() in [quit, exit, q]: # 在会话结束时可选对本次会话进行摘要并存储为一条高阶记忆 self._summarize_and_store_session() print(会话结束。) break # 1. 构建带记忆的提示词 messages self._build_prompt_with_memory(user_input) # 2. 调用LLM获取回答 try: response self.memory_manager.openai_client.chat.completions.create( modelself.llm_model, messagesmessages, temperature0.7 ) ai_reply response.choices[0].message.content print(f\nAssistant: {ai_reply}) # 3. 将本轮交互的“精华”存储为记忆 # 简单策略将用户输入和AI回答组合后存储。更优策略是调用LLM进行摘要。 interaction_summary fUser: {user_input}\nAssistant: {ai_reply} self.memory_manager.store_memory( contentinteraction_summary, session_idself.current_session_id, memory_typeinteraction ) # 4. 将本轮对话加入缓冲区用于后续可能的会话摘要 self.conversation_buffer.append((user_input, ai_reply)) except Exception as e: print(f调用AI时出错: {e}) def _summarize_and_store_session(self): 可选会话结束时生成一个整体摘要作为一条高阶记忆 if not self.conversation_buffer: return # 这里可以设计一个提示词让LLM总结整个会话的核心议题、结论和决策。 # 例如“请总结以下对话的核心学习要点和达成的共识。” # 然后将总结出的文本通过 store_memory 存储memory_type 可设为 session_summary。 pass # 运行助手 if __name__ __main__: # 初始化记忆管理器需填入你的OpenAI API Key mm MemoryManager(openai_api_keyyour-openai-api-key-here) assistant PersistentMemoryAssistant(mm) assistant.chat_cycle()这段代码实现了一个基础但完整的有记忆AI助手。当你运行它并开始对话后第二次提到相关话题时AI的回答就能体现出对之前讨论内容的“记忆”。5. 常见问题与排查技巧实录在实际构建和使用的过程中我遇到了不少坑也总结出一些让系统更“聪明”的技巧。5.1 记忆检索不准确或无关问题表现AI的回答似乎没有用到该用的记忆或者用到了完全不相关的记忆。排查与解决检查嵌入模型确保用于生成记忆向量和查询向量的模型是同一个。不同模型生成的向量空间不同无法直接比较。优化记忆文本质量存储的“记忆”文本本身需要是自包含、信息密度高的句子或段落。避免存储“嗯”、“好的”这类无意义对话。这就是为什么需要在store_memory前进行摘要或过滤。调整检索数量k值n_results参数需要调优。太小可能遗漏关键记忆太大会引入噪声。可以从3开始根据对话长度和复杂度调整到5或7。引入元数据过滤这是提升精度的利器。在存储时打好标签如project: ml_pipeline,topic: data_cleaning检索时通过filter_dict限定范围。例如当讨论“A项目”时只检索project为A的记忆。审视查询本身有时用户的新问题过于简短或模糊如“上次那个方案怎么样”导致查询向量不明确。可以尝试让系统在检索前先用LLM对当前简短查询进行一次“查询扩展”基于对话历史将其重写为更完整的句子。5.2 上下文过长导致API调用失败或成本激增问题表现OpenAI API返回错误提示上下文长度超限或者账单费用增长过快。排查与解决严格限制单条记忆长度在存储前使用tiktoken计算令牌数对过长的记忆进行强制截断或再次摘要。控制注入的记忆条数和总长在_build_prompt_with_memory函数中不仅限制条数n_results还要累加注入记忆的总令牌数设定一个硬性上限例如1024个令牌。采用更智能的记忆摘要不要存储完整的对话原文。对于较长的讨论存储由LLM生成的精炼摘要。这能极大压缩记忆体积。实现记忆“老化”与清理为记忆设置importance_score和last_accessed_time。可以定期运行一个清理任务删除重要性低且很久未被访问的旧记忆或者将其转移到冷存储。5.3 AI似乎“无视”注入的记忆问题表现相关记忆已经被正确检索并注入到提示词中但AI的回答完全没有体现这些信息。排查与解决优化提示词模板这是最常见的原因。系统指令必须足够清晰和强硬。对比我提供的模板和简单的“以下是一些历史信息[记忆]”前者的效果要好得多。可以尝试在指令中加入“你必须参考以下背景信息”、“你的回答应体现出你对以下历史信息的理解”等更强引导性的语句。检查记忆的相关性手动检查检索到的记忆是否真的与当前问题高度相关。不相关的记忆会干扰AI。可以尝试提高检索的相似度阈值只注入相似度高于某个值如0.8的记忆。调整LLM的温度参数过高的temperature如0.9会增加回答的随机性可能导致AI“放飞自我”忽略上下文。对于需要严谨结合记忆的任务可以适当降低temperature如0.3-0.7。使用更强大的模型如果使用gpt-3.5-turbo效果不佳可以尝试切换到gpt-4。更大的模型在遵循复杂指令和处理长上下文方面通常表现更好。5.4 隐私与数据安全问题核心关切所有对话记忆都存储了下来其中可能包含敏感信息。应对策略本地化部署向量数据库如ChromaDB和整个应用后端部署在你自己的服务器或电脑上。只有向OpenAI API发送的提示词和返回结果会经过其服务器需遵守OpenAI的数据使用政策。记忆加密在将记忆文本存入向量数据库前可以进行对称加密。不过这会使基于内容的语义检索失效因为你无法对加密后的密文生成有意义的向量。一个折中方案是只对元数据中的敏感字段如项目真名、人名进行加密或脱敏处理而记忆内容本身用代号表示。用户控制提供清晰的界面或指令让用户可以查看、编辑或删除特定的记忆。例如实现类似“忘记所有关于[某某项目]的事情”这样的命令。构建这个持久记忆系统的过程让我深刻体会到当前AI应用的创新很大程度上是“提示词工程”和“外部系统设计”的创新。我们无法轻易改变模型的内核但可以通过精巧的架构引导它发挥出远超其基础设计的能力。这个项目不仅解决了我的“AI健忘症”问题更像是一个可扩展的框架未来我可以轻松地为它添加更多功能比如基于记忆的个性化学习计划生成、跨文档的知识关联等等。它让AI从一个“聪明的临时工”变成了一个“持续成长的合作伙伴”。
