突破LLM上下文限制：基于自我摘要的记忆系统设计与实现

1. 项目概述当AI学会“记笔记”最近在跟进大语言模型LLM应用落地的项目时一个核心痛点反复出现模型在处理长文本或多轮对话时经常“前言不搭后语”记不住几分钟前自己说过的话。这就像让一个记忆力只有七秒的人去参加一场持续数小时的复杂会议结果可想而知。因此当我看到“Researchers Teach AI to Retain Memory by Summarizing Its Own Work”这个标题时立刻被吸引了。这本质上是在解决LLM的“上下文窗口”限制问题但方法非常巧妙——不是粗暴地扩大窗口而是教会AI自己给自己“记笔记”、做摘要从而构建一个动态的、可扩展的记忆系统。这个思路的核心价值在于它试图让AI从“单次对话的应答者”转变为“拥有持续记忆的协作者”。想象一下你正在和AI助手规划一个长达数月的项目每次对话都可能涉及任务分配、进度更新、决策记录。传统模式下每次新对话都是一次重启你需要不断重复背景信息。而如果AI能自动将每次交互的核心内容提炼成摘要并存入一个“记忆库”那么在下一次对话时它就能快速“回忆”起关键上下文让协作变得连贯而高效。这不仅是对技术瓶颈的突破更是迈向更自然、更智能人机交互的关键一步。接下来我将从设计思路、技术实现、实操要点到避坑经验完整拆解这套“AI自我摘要记忆法”。2. 核心思路拆解从“健忘症”到“记忆宫殿”要理解这个项目首先要明白LLM为什么“健忘”。主流模型如GPT系列有一个固定的“上下文窗口”例如4K、8K、16K tokens。这个窗口就像AI的“工作记忆区”所有输入你的提问、历史对话、提供的文档和它即将生成的输出都共享这个有限的空间。一旦对话轮次或输入文档长度超过窗口限制最早的信息就会被“挤出”窗口模型便无法再访问它们。直接扩大窗口在技术上成本高昂计算量呈平方级增长且效率低下因为并非所有历史信息都同等重要。因此项目的核心思路不是“扩容”而是“提炼”。其设计哲学可以概括为将冗长的、线性的对话历史转化为精炼的、结构化的记忆摘要并在需要时动态检索和注入相关记忆从而在有限的上下文窗口内实现近似无限长的记忆能力。这背后是一套完整的系统设计2.1 记忆的生成从对话到摘要记忆不是对原始对话的简单截取和存储而是经过理解、筛选和重构的产物。这个过程通常包含几个关键环节触发与分割系统需要决定何时生成一份记忆摘要。常见的策略有两种一是基于长度当对话轮次或token数达到某个阈值时触发二是基于话题转换通过检测用户提问的主题变化来自然分割对话段落。更高级的系统会两者结合。摘要生成这是技术的核心。系统会将被触发的那一段对话历史例如最近的10轮对话作为输入提示PromptLLM生成一份结构化摘要。这个Prompt设计至关重要它需要引导模型提取事实、决策、用户偏好、待办事项等关键信息并忽略寒暄、重复和无关细节。摘要的格式通常是清单或简短的段落。注意摘要的“保真度”是关键挑战。要避免模型在摘要过程中“捏造”或“扭曲”事实。Prompt中必须强调“严格基于提供的历史不要添加任何未提及的信息”。记忆存储生成的摘要连同其对应的原始对话时间戳、话题标签等元数据被存入一个向量数据库如ChromaDB, Pinecone, Weaviate或传统数据库中。向量化存储的优势在于支持基于语义相似度的快速检索。2.2 记忆的检索在需要时想起当用户发起新一轮对话时系统不会一股脑地把所有历史摘要都塞进上下文。那样做和扩大窗口没有本质区别。正确的做法是相关性检索将用户的新问题Query进行向量化然后在记忆库中进行语义搜索找出与当前问题最相关的若干条记忆摘要。例如用户问“我们上周决定的项目排期是什么”系统就应该检索出包含“项目排期”、“会议决定”等关键词的记忆片段。重要性/新鲜度加权检索结果可能有多条。系统需要给它们排序。通常越近期的记忆权重越高新鲜度同时某些被标记为“关键决策”的记忆可能获得额外权重。上下文组装将检索到的、经过排序的Top-K条记忆摘要与用户的当前问题一起组装成最终的Prompt提交给LLM生成回答。这样LLM的上下文窗口中包含了最相关的“记忆”和当前问题从而做出连贯的回答。2.3 记忆的管理更新与遗忘记忆不是一成不变的。一个好的记忆系统还需要能更新和清理记忆。记忆更新当新的对话对旧记忆进行了修正或补充时系统需要能更新对应的记忆摘要而不是创建一条矛盾的新记忆。这可能需要更复杂的记忆合并逻辑。记忆遗忘/归档并非所有记忆都需要被高频检索。系统可以设定规则将很久未被访问或重要性较低的记忆移出快速检索的向量索引转入成本更低的冷存储实现记忆的“归档”这类似于人类的长期记忆逐渐变得模糊。这套“生成-检索-使用”的循环构成了AI自我摘要记忆系统的核心骨架。它巧妙地用“摘要”这一高信息密度的形式突破了原始“上下文窗口”的物理限制。3. 技术实现详解构建你的AI记忆系统理解了思路我们来动手搭建一个简化但可用的版本。我们将使用Python借助LangChain框架它提供了大量用于构建LLM应用的工具链和开源的向量数据库。3.1 环境准备与工具选型首先明确我们的技术栈LLM我们将使用OpenAI的GPT-3.5-turbo或GPT-4作为核心的“大脑”和“摘要生成器”。你也可以替换为Claude、国产大模型等只需调整API调用。向量数据库选择ChromaDB因为它轻量、易用且无需外部服务适合本地开发和原型验证。应用框架使用LangChain它能极大地简化记忆管理、检索链的构建。开发语言Python 3.8。安装依赖pip install langchain langchain-openai langchain-chroma tiktokentiktoken用于精确计算token管理上下文长度。3.2 核心模块一记忆生成器这个模块负责将一段对话历史转化为记忆摘要。我们设计一个MemoryGenerator类。from langchain.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI import json class MemoryGenerator: def __init__(self, llm_modelgpt-3.5-turbo): self.llm ChatOpenAI(modelllm_model, temperature0.1) # 低温度保证摘要稳定 # 精心设计的摘要生成Prompt self.summary_prompt ChatPromptTemplate.from_messages([ (system, 你是一个精准的对话摘要助手。请基于以下对话历史生成一份简洁、结构化的摘要。请只提取关键事实、达成的共识、做出的决策、用户明确表达的偏好以及待办事项。绝对不要添加任何对话中未出现的信息。如果对话无关紧要摘要可以为空。输出格式为JSON{summary: 摘要内容, keywords: [关键词1, 关键词2]}), (human, 对话历史\n{conversation_history}) ]) def generate_memory(self, conversation_history): 将对话历史生成记忆 if not conversation_history or len(conversation_history.strip()) 50: # 如果历史太短或无意义不生成记忆 return None chain self.summary_prompt | self.llm response chain.invoke({conversation_history: conversation_history}) try: # 解析LLM返回的JSON memory_dict json.loads(response.content) memory_dict[raw_history_snippet] conversation_history[-500:] # 保存一段原始文本片段供参考 return memory_dict except json.JSONDecodeError: # 如果LLM没有返回标准JSON尝试提取或返回一个安全值 print(fLLM返回非标准JSON: {response.content}) return {summary: response.content[:200], keywords: []}关键点解析Prompt设计这是成功的关键。我们要求LLM输出JSON格式包含summary和keywords。keywords字段将为后续的向量化检索提供额外的语义标签。温度Temperature设置为较低的0.1是为了让摘要生成更确定、更少“创造性”保证记忆的准确性。错误处理必须处理LLM输出不符合格式的情况避免系统崩溃。3.3 核心模块二记忆存储与检索器这个模块负责存储记忆并能根据新问题找到相关记忆。from langchain_chroma import Chroma from langchain_openai import OpenAIEmbeddings from langchain.schema import Document from datetime import datetime class MemoryStore: def __init__(self, persist_directory./chroma_memory_db): # 使用OpenAI的嵌入模型将文本转化为向量 self.embedding_function OpenAIEmbeddings(modeltext-embedding-3-small) # 初始化或加载Chroma向量数据库 self.vectorstore Chroma( collection_nameconversation_memories, embedding_functionself.embedding_function, persist_directorypersist_directory ) self.memories_metadata [] # 用于存储记忆的元数据如时间戳 def add_memory(self, memory_dict, conversation_context): 将一条记忆存入向量库 if not memory_dict or summary not in memory_dict: return summary_text memory_dict[summary] if not summary_text or len(summary_text) 10: return # 准备存入向量的文档。将摘要和关键词合并作为文档内容增强检索能力。 content_for_embedding f摘要{summary_text}\n关键词{, .join(memory_dict.get(keywords, []))} doc Document( page_contentcontent_for_embedding, metadata{ timestamp: datetime.now().isoformat(), raw_snippet: memory_dict.get(raw_history_snippet, ), context: conversation_context # 可选的标记这段记忆属于哪个对话或用户 } ) self.vectorstore.add_documents([doc]) self.memories_metadata.append({ timestamp: doc.metadata[timestamp], summary: summary_text }) print(f记忆已保存{summary_text[:50]}...) def search_memories(self, query, k3): 检索与查询最相关的k条记忆 if self.vectorstore._collection.count() 0: return [] docs self.vectorstore.similarity_search(query, kk) return docs关键点解析嵌入模型Embedding我们使用text-embedding-3-small它平衡了性能、成本和效果。嵌入模型将文本转换为数学向量语义相似的文本向量距离也近。文档内容我们将summary和keywords一起嵌入这样无论是用总结性语言还是具体关键词检索都能找到相关记忆。元数据Metadata存储timestamp和raw_snippet非常有用。时间戳可用于按时间过滤原始片段可用于在需要时追溯细节。3.4 核心模块三对话引擎与记忆管理这是将以上模块串联起来的总控系统管理整个对话流程。class ConversationalAgentWithMemory: def __init__(self, memory_store, memory_generator, llm_for_chat): self.memory_store memory_store self.memory_generator memory_generator self.chat_llm llm_for_chat self.current_session_history [] # 存储当前未生成记忆的对话轮次 self.summary_trigger_length 5 # 每5轮对话触发一次摘要生成 def add_to_session(self, speaker, text): 添加一轮对话到当前会话历史 self.current_session_history.append(f{speaker}: {text}) # 检查是否达到触发摘要的条件 if len(self.current_session_history) self.summary_trigger_length: self._condense_and_store_memory() def _condense_and_store_memory(self): 压缩当前会话历史并存储为记忆 history_text \n.join(self.current_session_history[-self.summary_trigger_length:]) # 取最近N轮 memory self.memory_generator.generate_memory(history_text) if memory: self.memory_store.add_memory(memory, conversation_contextsession) # 可选生成记忆后可以清空或保留部分当前历史避免重复摘要 # self.current_session_history [] def generate_response(self, user_input): 处理用户输入生成回答 # 1. 将用户输入添加到当前会话 self.add_to_session(User, user_input) # 2. 检索相关记忆 relevant_memories self.memory_store.search_memories(user_input, k2) memory_context if relevant_memories: memory_context 相关记忆\n \n---\n.join([doc.page_content for doc in relevant_memories]) # 3. 组装最终Prompt包含记忆、最近对话和当前问题 recent_chat \n.join(self.current_session_history[-6:]) # 提供最近3轮对话作为即时上下文 prompt f 你是一个有帮助的AI助手拥有之前对话的记忆。 {memory_context} 最近的对话 {recent_chat} 请根据以上信息回答用户的最新问题。 用户{user_input} 助手 # 4. 调用LLM生成回答 response self.chat_llm.invoke(prompt) assistant_reply response.content # 5. 将AI的回答也添加到当前会话历史 self.add_to_session(Assistant, assistant_reply) return assistant_reply3.5 运行示例# 初始化所有组件 store MemoryStore() generator MemoryGenerator() chat_llm ChatOpenAI(modelgpt-3.5-turbo, temperature0.7) agent ConversationalAgentWithMemory(store, generator, chat_llm) # 模拟多轮对话 conversation [ 用户我们下周要启动的A项目市场调研部分由谁负责, 用户另外预算初步定在50万以内。, 用户技术选型会明天下午两点开记得通知小李。, 用户对了A项目的目标用户画像你整理好了吗, 用户关于预算50万是上限我们要尽量控制在45万。 ] print(开始模拟对话...) for i, user_msg in enumerate(conversation): print(f\n轮次 {i1}) print(f[用户] {user_msg}) reply agent.generate_response(user_msg) print(f[助手] {reply}) # 查询记忆库 print(\n--- 检索测试 ---) test_query A项目的预算是多少 memories store.search_memories(test_query, k1) if memories: print(f对于问题{test_query}检索到的记忆) print(memories[0].page_content)这个示例展示了系统如何在一段关于项目管理的对话中自动生成关于“负责人”、“预算”、“会议”的记忆并在后续询问预算时成功从记忆库中检索出相关信息来辅助回答。4. 高级优化与实战心得基础系统搭建完成后要让它真正稳定、好用还需要一系列优化。这些都是从实际项目踩坑中总结出来的经验。4.1 摘要质量的提升技巧最初的摘要可能过于笼统或包含幻觉。提升质量需要“调教”Prompt和流程多步摘要与校验不要指望一次生成完美摘要。可以采用两步法第一步让LLM提取对话中的“原子事实”谁什么时间做了什么决定第二步让另一个LLM或同一LLM不同Prompt对这些事实进行整合、去重形成连贯摘要。甚至可以引入一个“校验”步骤对比摘要和原始历史标记不一致处。结构化模板强制对于特定领域如客服、会议纪要可以定义更严格的JSON输出模板。例如{ decisions: [], action_items: [{owner: 张三, task: 完成调研, deadline: 2023-10-01}], key_facts: [], open_questions: [] }让LLM严格按照字段填充可解析性和准确性更高。为摘要打分引入一个简单的评分机制评估摘要的“信息密度”是否包含关键实体和“一致性”是否与原文矛盾。低分摘要可以要求重生成或直接丢弃。4.2 检索策略的精细化设计简单的语义相似度检索可能不够用。混合检索Hybrid Search结合语义检索向量相似度和关键词检索BM25。语义检索擅长处理“意思相近”关键词检索擅长处理“名称、代号等精确匹配”。例如用户问“PPT做得怎么样了”语义检索可能找不到但如果历史摘要里提到了“幻灯片”或“演示文档”关键词检索就能命中。LangChain可以很方便地集成混合检索。时间衰减加权在检索评分中引入时间因子让近期记忆的排名更高。计算公式可以简化为最终分数 语义相似度分数 * exp(-λ * 时间差)。这符合人类记忆“越近的事印象越深”的特点。元数据过滤在检索时可以加入过滤器。例如vectorstore.similarity_search(query, k5, filter{context: project_A})只检索属于“项目A”对话的记忆避免不同话题间的记忆污染。4.3 记忆的更新、合并与遗忘机制这是实现“长期记忆”的难点。记忆更新当检索到一条相关旧记忆而新对话对其进行了修正时一个策略是将旧记忆、新对话以及一条“更新指令”一起发给LLM让它生成一条合并后的新记忆然后替换掉向量数据库中的旧记录。这需要维护记忆的唯一ID。记忆合并如果检索到多条关于同一主题的记忆例如三次会议都讨论了预算可以在注入上下文前先让LLM对这些记忆进行一次“摘要的摘要”合成一条更精炼的总体记忆再送给对话模型。这能节省上下文空间。记忆归档与遗忘可以定期如每天运行一个后台任务检查记忆的“活跃度”最近被检索的次数、时间。将长期未被访问的记忆从高性能的向量索引中移除只保留核心元数据在传统数据库。当未来某次检索未命中向量库但元数据匹配时可以再从冷存储中加载。这实现了成本与性能的平衡。4.4 系统性能与成本考量Token消耗摘要生成、检索时的嵌入计算、以及最终对话都在消耗Token。尤其是嵌入模型虽然比大语言模型便宜但调用频繁也是一笔开销。需要对摘要触发频率、检索条数k值进行优化。对于非关键对话可以降低摘要生成频率或使用更小的嵌入模型。延迟检索向量数据库、调用LLM生成摘要都会增加对话的响应延迟。在实时性要求高的场景如在线客服可以考虑异步生成摘要即不阻塞当前对话响应在后台进行记忆的生成和存储。向量数据库选择对于生产环境ChromaDB单机版可能成为瓶颈。需要考虑Pinecone、Weaviate、Qdrant等支持云服务、分布式和更高级检索功能的专业向量数据库。5. 常见问题与避坑指南在实际部署中你会遇到各种各样的问题。以下是一些典型问题及解决方案。问题现象可能原因排查与解决思路AI的回答开始“胡言乱语”包含矛盾信息1. 记忆摘要本身有错误幻觉。2. 检索到了不相关或过时的记忆。3. 相关记忆和当前问题一起导致上下文混乱。1.检查摘要质量抽样查看生成的记忆摘要优化摘要生成Prompt增加事实校验步骤。2.优化检索降低检索数量k尝试混合检索增加元数据过滤。3.清理记忆库删除早期低质量或测试产生的记忆。引入记忆新鲜度加权。系统似乎“忘记”了不久前才说过的事1. 摘要触发频率太低对话历史还没被压缩成记忆。2. 检索失败没有找到相关记忆。3. 记忆摘要丢失了关键细节。1.调整触发策略除了轮次可以基于对话token长度或话题明显转变来触发摘要。2.增强检索检查嵌入模型是否合适尝试在记忆存储时加入更多关键词。3.改进摘要在Prompt中强调保留具体数字、名称、时间等细节。响应速度明显变慢1. 记忆库过大向量检索变慢。2. 同步进行摘要生成阻塞了对话。3. 网络或API延迟。1.数据库优化对向量索引进行优化或迁移到性能更强的专业向量数据库。2.异步处理将摘要生成和存储改为异步任务不阻塞主响应链路。3.缓存对常见问题的检索结果进行短期缓存。不同用户或会话的记忆互相干扰所有记忆都存储在同一个集合Collection中没有区分。引入会话/用户隔离为每个对话会话或用户创建独立的向量集合Collection或在元数据中增加session_id/user_id字段检索时严格过滤。这是多用户系统的必须项。Token消耗超出预期1. 摘要过长。2. 检索后注入上下文的记忆过多。3. 对话历史本身积累过长。1.控制摘要长度在Prompt中明确限制摘要字数如“不超过100字”。2.限制检索条数动态调整k值或对检索到的记忆再进行一次压缩摘要。3.定期清空会话历史在生成记忆后可以安全地清空或截断current_session_history。最重要的心得没有“银弹”Prompt。你的摘要生成Prompt和最终对话的System Prompt需要根据你的具体领域数据反复调试和打磨。最好的方法是准备一批高质量的“输入-输出”配对样本进行少量示例的提示Few-shot Prompting让LLM更好地理解你想要它如何总结和利用记忆。这个过程更像是一种“训练”或“对齐”是项目成功的关键也是最耗费精力的部分。