1. 项目概述当AI学会“记住”对话最近在做一个挺有意思的实验项目核心目标很简单让一个AI对话系统能真正“记住”之前聊过什么并且利用这些记忆来持续优化它的行为。听起来像是给AI装上一个不会遗忘的“笔记本”。这个项目的具体形态是一个具备持续记忆能力的冲突调解员智能体。为什么是冲突调解因为在日常沟通中无论是线上社区管理、客户服务还是团队协作很多矛盾都不是一次对话就能解决的。它们往往有历史渊源当事人的立场、情绪和诉求会随着时间演变。一个传统的、无状态的聊天机器人每次对话都像是第一次见面需要用户反复陈述背景这不仅低效更会让人感到不被理解和尊重。我们需要的是一个能记住“上次我们谈到哪里了”、“张三和李四之前因为什么有过分歧”、“王五最在意的底线是什么”的智能助手。这个项目的挑战和魅力也正在于此。它不仅仅是调用一个大语言模型的API然后获取回复那么简单。它涉及到如何为AI设计一个稳定、可检索的“记忆”存储系统如何定义和提取对话中的关键信息作为记忆点如何让AI在后续对话中主动、恰当地运用这些记忆以及如何处理记忆可能带来的隐私、偏见和错误累积问题。这实际上是在构建一个具备初步“长期人格”或“关系认知”的智能体原型。下面我就把自己从零搭建这个“有记忆的调解员”过程中的核心设计、技术选型、踩过的坑以及一些实用的心得完整地分享出来。2. 整体架构与核心设计思路2.1 为什么选择“记忆”作为核心能力在决定构建这个调解员智能体时我首先摒弃了那种追求“一次性完美回复”的思路。冲突调解的本质是过程管理而不是问题解答。一个好的调解员价值体现在对矛盾演变脉络的把握、对当事人性格与诉求的持续理解、以及对过往共识与承诺的追踪上。这些能力都依赖于记忆。无状态的AI就像是一个失忆的调解员每次会议都要重新自我介绍重新了解冲突全貌这显然不现实。因此项目的基石必须是智能体记忆Agent Memory。这里的记忆不是指模型参数本身的更新那是训练阶段的事而是在应用层为每个对话会话Session或每个用户User建立一个外挂的、结构化的信息库。2.2 核心架构拆解三层记忆模型我参考了学术界和工业界对AI记忆的多种分类最终为我的调解员设计了一个三层记忆模型这构成了整个系统的骨架对话记忆Conversation Memory这是最基础的短期记忆。它完整记录当前会话中的所有消息交换Human Message, AI Message。它的主要作用是提供完整的上下文供大语言模型生成下一轮回复。通常我们会采用一个“滑动窗口”机制只保留最近N轮对话以防止上下文过长导致模型性能下降或API费用激增。实体记忆Entity Memory这是长期记忆的核心也是本项目重点。它不记录完整的对话流水而是从中提取出关于“实体”如人、事件、规则、诉求的关键事实facts和属性attributes。例如从对话中提取出“用户张三”的“核心诉求是退款”“情绪特点是容易焦虑”“上次沟通中同意了方案A但未执行”。这些结构化信息被存储起来并能在后续对话中被查询和更新。摘要记忆Summary Memory这是一种压缩和升华的记忆。当一次长对话结束或一个冲突阶段告一段落时系统会自动生成一个摘要概括本次对话的核心议题、达成的共识、存在的分歧以及下一步行动计划。这个摘要既是对实体记忆的补充也为未来快速回顾整个事件脉络提供了高效入口。这个三层模型的好处是层次清晰、各司其职。对话记忆保证连贯性实体记忆保证深度理解摘要记忆保证宏观把握。调解员智能体在每次需要回应时会综合查询这三类记忆形成丰富的背景知识再结合当前用户输入做出更有针对性的判断和建议。2.3 技术栈选型与理由确定了架构接下来就是技术选型。我的原则是优先选择成熟、开源、社区活跃且易于集成的工具。核心AI引擎LLM我选择了OpenAI的GPT-4系列API。原因很简单它在理解复杂语境、进行多轮推理和生成人性化文本方面目前仍是标杆。虽然也测试了Claude和国内的一些大模型但在处理“从对话中提取结构化信息”和“基于复杂记忆进行综合判断”这两个核心任务上GPT-4的稳定性和准确性更胜一筹。对于预算敏感的场景可以将GPT-3.5-Turbo用于一些对精度要求不高的摘要生成任务。记忆存储与检索这是关键。单纯用关系型数据库如MySQL存文本检索效率低且难以做语义搜索。我选择了向量数据库Vector Database。具体来说是Chroma。它轻量、易用且与LangChain等智能体开发框架集成良好。工作原理是将提取出的实体记忆如“张三-诉求-退款”通过嵌入模型Embedding Model如OpenAI的text-embedding-3-small转换为向量一串数字然后存储。当需要查询时将查询语句如“张三想要什么”也转换为向量在向量空间中找到最相似的记忆向量返回。这实现了基于语义的模糊搜索而不仅仅是关键词匹配。智能体开发框架为了快速搭建智能体的决策流程如何时调用记忆、何时总结、如何组织提示词我使用了LangChain。它提供了ConversationChain、Agent、Memory类等高级抽象能极大地简化代码。虽然LangChain有时因为封装过度而显得“黑盒”但对于快速原型开发来说它能节省大量时间。后端与部署使用FastAPI构建RESTful API接口方便前端或其他系统调用。部署在常规的云服务器上通过Docker容器化保证环境一致性。注意技术选型没有绝对的对错只有是否适合当前阶段的需求。例如如果对数据隐私要求极高可能需要部署本地开源模型如Llama 3和本地向量数据库如Milvus。但考虑到开发效率和能力上限我选择了基于云API的方案。3. 核心模块实现细节3.1 记忆的写入如何从对话中提取关键信息记忆不是把用户说的每句话都存起来那样只会得到一堆噪音。我们需要一个“记忆提取器”。我设计了一个基于LLM的提取流程在每轮对话后异步执行触发条件并非每轮对话后都提取。我设置了两个触发条件一是检测到用户输入中包含了明显的事实陈述如“我最讨厌的是等待”、“我上次同意的是方案B”二是对话轮数达到一个阈值如5轮进行一次批量提取。提取提示词设计这是核心技巧。我给LLM的指令非常具体你是一个精准的信息提取员。请从以下对话片段中提取关于【人物】、【事件】、【诉求】、【情绪】和【承诺】的明确事实。 只提取客观陈述或双方确认的信息不要推断。 以JSON格式输出格式为{entities: [{type: person/event/demand/emotion/commitment, name: 实体名, attribute: 属性名, value: 属性值, source_utterance: 来源原句}]} 对话片段[最近的几轮对话文本]通过限定输出格式和提取类型能极大提高结构化数据的质量。后处理与去重提取出的JSON数据在存入向量数据库前会进行后处理。比如对同一实体的同一属性进行更新如张三的诉求从“换货”变为“退款”而不是简单新增。同时会用一个简单的规则检查明显的矛盾如同一个事实有两个相反的值并打上标记供后续人工复核。3.2 记忆的存储向量数据库的实践将提取出的结构化记忆存入Chroma需要几步生成嵌入向量对于每一条记忆如“张三-诉求-退款”我将其拼接成一段自然语言描述“关于人物张三的事实他的核心诉求是退款。” 然后用text-embedding-3-small模型将其转换为1536维的向量。这个描述文本的生成方式会影响检索效果我尝试了几种模板最终发现“关于[实体类型][实体名]的事实[属性]是[值]”这种格式效果最稳定。组织存储结构Chroma中我以session_id会话ID和user_id用户ID作为元数据metadata进行过滤。这样在检索时可以快速定位到特定会话或特定用户的记忆实现了记忆的隔离。每条记忆的向量、原始文本和元数据一起存储。设置索引Chroma会自动为向量创建索引。我选择了默认的HNSW索引它在精度和速度之间取得了很好的平衡。对于数据量不大的场景万条以内这完全够用。3.3 记忆的读取与运用在对话中“回忆”这是智能体显得“有记性”的关键。在生成回复前系统会执行一个“记忆检索”步骤生成检索查询直接使用当前用户的最新输入作为查询有时会显得不够精准。我采用了一个小技巧让LLM根据当前对话生成一个更明确的检索问题。例如用户说“那我的问题怎么解决”LLM可能会将其重写为“检索用户张三关于问题解决的历史诉求和承诺”。这个重写后的查询再进行向量化检索准确率更高。执行向量检索将查询向量送入Chroma指定session_id和user_id检索出最相似的K条记忆我通常设K5。Chroma会返回相似度分数。记忆筛选与注入不是所有检索到的记忆都相关。我会设置一个相似度阈值如0.7过滤掉低分记忆。然后将筛选后的记忆以清晰格式如“根据之前的记录1. 张三的诉求是退款2. 张三曾表示讨厌等待超过24小时...”拼接到给LLM的最终提示词Prompt中放在系统指令和当前对话历史之间。指导LLM使用记忆在系统指令中我会明确告诉LLM“以下‘历史记忆’是之前对话中提取的关键信息请在你的回复中充分考虑并恰当引用这些信息以体现对话的连续性。” 这样LLM生成的回复就会自然地带入“我记得你之前说过……”这样的表述。3.4 冲突调解逻辑的实现有了记忆系统作为基础调解员的具体逻辑就体现在精心设计的提示词和少量规则引擎上。角色设定与系统提示词这是智能体的“人格”。我的提示词大致如下你是一个专业的冲突调解员名字叫“和言”。你的目标是帮助双方厘清问题、促进理解、达成可行方案。 你的核心原则是中立不偏袒任何一方、共情理解各方情绪和需求、聚焦于解决方案引导对话向前看。 在对话中你需要主动1. 复述和确认各方观点2. 识别共同点和分歧点3. 基于历史信息提出建议4. 总结阶段性共识。 以下是本次对话相关的历史记忆[此处动态插入检索到的记忆] 当前对话历史[此处插入最近的对话记录] 请根据以上信息对用户的最新输入做出回应。多轮策略调度我实现了一个简单的状态机。根据对话内容智能体会处于不同“阶段”如“信息收集”、“情绪安抚”、“方案探讨”、“共识确认”。不同阶段其回复的侧重点和调用的工具如是否主动总结会有所不同。这通过分析用户输入的情绪标签和意图分类来实现。共识与承诺追踪这是记忆系统的杀手级应用。每当对话中达成一个共识如“双方同意在下周一前提交书面材料”或一个承诺如“我会在明天下午给你答复”系统会将其作为一条高优先级的“承诺”类型记忆提取出来。在后续的对话中智能体会主动询问承诺的履行情况如“关于周一提交材料的约定进展如何”从而推动事情落地而不是停留在空谈。4. 实操中的挑战与解决方案4.1 记忆的准确性与“幻觉”问题LLM在提取记忆时可能产生“幻觉”即编造不存在的事实。例如用户从未同意过方案A但LLM可能错误地提取出“用户同意方案A”。这种错误记忆一旦存入后患无穷。我的应对策略高置信度存储只提取那些在对话中明确陈述、且带有高确定性词汇如“是”、“要”、“同意”、“拒绝”的信息。对于模糊表达如“可能”、“也许”不予提取或标记为低置信度。来源追溯每条记忆都强制记录source_utterance来源原句。在向用户呈现或基于记忆做出判断时可以附带“根据您在X月X日说过的话‘……’”增加可信度也给了用户纠正的机会。定期记忆复审设计一个简单的管理界面可以查看和编辑某个会话的所有记忆。在关键节点可以由人工调解员本人或管理员对记忆进行审核和修正。冲突检测当试图存入一条与已有记忆明显矛盾的新记忆时如“诉求是退款” vs “诉求是换货”系统会触发一个警告并尝试从更完整的上下文去判断哪条更可信或者直接向用户提问确认。4.2 记忆的关联与检索效率随着对话进行记忆条目会越来越多。如何从海量记忆中快速、准确地找到当前最相关的几条是一个挑战。简单的向量相似度检索有时会跑偏。我的优化方法分层检索首先用session_id和user_id在元数据层面做快速过滤缩小搜索范围。这相当于先找到了正确的“记忆文件夹”。查询扩展如前所述用LLM对原始查询进行重写和扩展生成多个不同角度的查询词条分别进行检索然后合并去重。这提高了召回率。混合检索结合向量检索和关键词检索。对于名称、日期等精确信息关键词检索BM25更有效。我将两者结果以一定权重融合如70%向量相似度 30%关键词评分取得了更好的效果。记忆摘要在会话开始时先加载本次会话的“摘要记忆”让LLM快速了解背景。在检索具体细节时再用向量搜索。这种“摘要细节”的两步法既保证了宏观不偏题又保证了微观有依据。4.3 隐私与数据安全记忆系统存储了大量敏感的对话信息。必须严肃对待隐私。我采取的措施数据匿名化在存储前对记忆文本中的真实姓名、电话、身份证号等个人信息进行自动脱敏处理替换为占位符如[NAME_A]。记忆生命周期管理为不同类型的记忆设置不同的过期时间TTL。例如“情绪”类记忆可能24小时后自动删除“承诺”和“共识”类记忆则保留较长时间。所有记忆在会话结束一段时间后如30天可被整体归档或清除。用户控制权提供用户界面让用户可以查看、导出和删除系统关于自己的所有记忆。这是符合数据隐私法规如GDPR的基本要求。加密存储所有记忆数据在数据库包括向量数据库中均以加密形式存储。4.4 系统性能与成本控制频繁调用LLM进行记忆提取和查询重写以及生成嵌入向量都会产生API费用和延迟。我的成本优化实践异步与批处理记忆提取和摘要生成等非实时任务全部放到后台异步队列中执行不影响主对话线程的响应速度。并且可以积累一定量的文本后批量进行嵌入减少API调用次数。缓存机制对于频繁检索的、不常变化的记忆如用户的基本偏好将其向量和结果在应用层缓存一段时间如5分钟避免重复计算。模型分级使用对精度要求高的核心回复生成使用GPT-4对记忆提取、查询重写等任务使用更便宜的GPT-3.5-Turbo对生成嵌入向量使用专门的、性价比高的嵌入模型如text-embedding-3-small。上下文长度管理严格控制送入LLM的对话历史和记忆文本的总长度。采用滑动窗口只保留最近N轮对话对过长的记忆文本进行智能截断或总结确保不触发模型的上下文长度限制也节省了Token消耗。5. 效果评估与迭代方向经过一段时间的测试和迭代这个有记忆的调解员智能体展现出了几个明显的优势对话连贯性极大提升用户不再需要重复背景信息智能体能够基于记忆进行自然衔接用户体验更加流畅和“聪明”。调解深度增加智能体能够指出“你之前的诉求是A但现在似乎更关注B我们能聊聊这个变化吗”从而引导对话触及更深层的矛盾。促进责任落实通过对“承诺”类记忆的追踪和主动询问切实推动了部分线上争议的解决进程。当然它远非完美。目前主要的不足在于对复杂、隐晦情绪的识别和记忆还不够精准有时会机械地引用记忆而显得不够灵活。此外当冲突涉及多方、信息量巨大时记忆系统的组织和检索逻辑还需要进一步优化。未来的迭代方向我计划从以下几点入手记忆的主动遗忘与重要性加权不是所有记忆都同等重要。需要设计算法根据记忆被检索的频率、其关联事件的解决状态等动态调整记忆的“权重”或“活跃度”对于陈旧的、不重要的记忆进行降级或归档让系统更聚焦于关键信息。引入知识图谱目前的实体记忆还是扁平的键值对。下一步可以尝试将实体人、事、物之间的关系也存储起来构建一个轻量的知识图谱。例如“张三” “投诉” “产品B”“产品B” “属于” “部门C”。这样智能体的推理能力会更强能回答“还有谁遇到过类似问题”这样的关联性问题。多模态记忆如果对话场景支持未来可以考虑接入图像、语音甚至对话时的语气分析结果形成更立体的“用户画像”记忆使调解更加细腻。构建一个有记忆的AI系统就像在教一个数字大脑如何做笔记并学以致用。这个过程充满了挑战但每当看到它准确回忆起之前的对话细节并据此做出更人性化的回应时那种成就感是巨大的。这个项目让我深刻体会到AI应用的下一波浪潮或许不在于模型本身有多大而在于我们如何为它们设计更精巧、更实用的“外脑”和“工作流程”。如果你也在探索智能体记忆相关的应用欢迎交流我们一起踩坑一起前进。
构建有记忆的AI调解员：基于向量数据库与LLM的智能体记忆系统实践
1. 项目概述当AI学会“记住”对话最近在做一个挺有意思的实验项目核心目标很简单让一个AI对话系统能真正“记住”之前聊过什么并且利用这些记忆来持续优化它的行为。听起来像是给AI装上一个不会遗忘的“笔记本”。这个项目的具体形态是一个具备持续记忆能力的冲突调解员智能体。为什么是冲突调解因为在日常沟通中无论是线上社区管理、客户服务还是团队协作很多矛盾都不是一次对话就能解决的。它们往往有历史渊源当事人的立场、情绪和诉求会随着时间演变。一个传统的、无状态的聊天机器人每次对话都像是第一次见面需要用户反复陈述背景这不仅低效更会让人感到不被理解和尊重。我们需要的是一个能记住“上次我们谈到哪里了”、“张三和李四之前因为什么有过分歧”、“王五最在意的底线是什么”的智能助手。这个项目的挑战和魅力也正在于此。它不仅仅是调用一个大语言模型的API然后获取回复那么简单。它涉及到如何为AI设计一个稳定、可检索的“记忆”存储系统如何定义和提取对话中的关键信息作为记忆点如何让AI在后续对话中主动、恰当地运用这些记忆以及如何处理记忆可能带来的隐私、偏见和错误累积问题。这实际上是在构建一个具备初步“长期人格”或“关系认知”的智能体原型。下面我就把自己从零搭建这个“有记忆的调解员”过程中的核心设计、技术选型、踩过的坑以及一些实用的心得完整地分享出来。2. 整体架构与核心设计思路2.1 为什么选择“记忆”作为核心能力在决定构建这个调解员智能体时我首先摒弃了那种追求“一次性完美回复”的思路。冲突调解的本质是过程管理而不是问题解答。一个好的调解员价值体现在对矛盾演变脉络的把握、对当事人性格与诉求的持续理解、以及对过往共识与承诺的追踪上。这些能力都依赖于记忆。无状态的AI就像是一个失忆的调解员每次会议都要重新自我介绍重新了解冲突全貌这显然不现实。因此项目的基石必须是智能体记忆Agent Memory。这里的记忆不是指模型参数本身的更新那是训练阶段的事而是在应用层为每个对话会话Session或每个用户User建立一个外挂的、结构化的信息库。2.2 核心架构拆解三层记忆模型我参考了学术界和工业界对AI记忆的多种分类最终为我的调解员设计了一个三层记忆模型这构成了整个系统的骨架对话记忆Conversation Memory这是最基础的短期记忆。它完整记录当前会话中的所有消息交换Human Message, AI Message。它的主要作用是提供完整的上下文供大语言模型生成下一轮回复。通常我们会采用一个“滑动窗口”机制只保留最近N轮对话以防止上下文过长导致模型性能下降或API费用激增。实体记忆Entity Memory这是长期记忆的核心也是本项目重点。它不记录完整的对话流水而是从中提取出关于“实体”如人、事件、规则、诉求的关键事实facts和属性attributes。例如从对话中提取出“用户张三”的“核心诉求是退款”“情绪特点是容易焦虑”“上次沟通中同意了方案A但未执行”。这些结构化信息被存储起来并能在后续对话中被查询和更新。摘要记忆Summary Memory这是一种压缩和升华的记忆。当一次长对话结束或一个冲突阶段告一段落时系统会自动生成一个摘要概括本次对话的核心议题、达成的共识、存在的分歧以及下一步行动计划。这个摘要既是对实体记忆的补充也为未来快速回顾整个事件脉络提供了高效入口。这个三层模型的好处是层次清晰、各司其职。对话记忆保证连贯性实体记忆保证深度理解摘要记忆保证宏观把握。调解员智能体在每次需要回应时会综合查询这三类记忆形成丰富的背景知识再结合当前用户输入做出更有针对性的判断和建议。2.3 技术栈选型与理由确定了架构接下来就是技术选型。我的原则是优先选择成熟、开源、社区活跃且易于集成的工具。核心AI引擎LLM我选择了OpenAI的GPT-4系列API。原因很简单它在理解复杂语境、进行多轮推理和生成人性化文本方面目前仍是标杆。虽然也测试了Claude和国内的一些大模型但在处理“从对话中提取结构化信息”和“基于复杂记忆进行综合判断”这两个核心任务上GPT-4的稳定性和准确性更胜一筹。对于预算敏感的场景可以将GPT-3.5-Turbo用于一些对精度要求不高的摘要生成任务。记忆存储与检索这是关键。单纯用关系型数据库如MySQL存文本检索效率低且难以做语义搜索。我选择了向量数据库Vector Database。具体来说是Chroma。它轻量、易用且与LangChain等智能体开发框架集成良好。工作原理是将提取出的实体记忆如“张三-诉求-退款”通过嵌入模型Embedding Model如OpenAI的text-embedding-3-small转换为向量一串数字然后存储。当需要查询时将查询语句如“张三想要什么”也转换为向量在向量空间中找到最相似的记忆向量返回。这实现了基于语义的模糊搜索而不仅仅是关键词匹配。智能体开发框架为了快速搭建智能体的决策流程如何时调用记忆、何时总结、如何组织提示词我使用了LangChain。它提供了ConversationChain、Agent、Memory类等高级抽象能极大地简化代码。虽然LangChain有时因为封装过度而显得“黑盒”但对于快速原型开发来说它能节省大量时间。后端与部署使用FastAPI构建RESTful API接口方便前端或其他系统调用。部署在常规的云服务器上通过Docker容器化保证环境一致性。注意技术选型没有绝对的对错只有是否适合当前阶段的需求。例如如果对数据隐私要求极高可能需要部署本地开源模型如Llama 3和本地向量数据库如Milvus。但考虑到开发效率和能力上限我选择了基于云API的方案。3. 核心模块实现细节3.1 记忆的写入如何从对话中提取关键信息记忆不是把用户说的每句话都存起来那样只会得到一堆噪音。我们需要一个“记忆提取器”。我设计了一个基于LLM的提取流程在每轮对话后异步执行触发条件并非每轮对话后都提取。我设置了两个触发条件一是检测到用户输入中包含了明显的事实陈述如“我最讨厌的是等待”、“我上次同意的是方案B”二是对话轮数达到一个阈值如5轮进行一次批量提取。提取提示词设计这是核心技巧。我给LLM的指令非常具体你是一个精准的信息提取员。请从以下对话片段中提取关于【人物】、【事件】、【诉求】、【情绪】和【承诺】的明确事实。 只提取客观陈述或双方确认的信息不要推断。 以JSON格式输出格式为{entities: [{type: person/event/demand/emotion/commitment, name: 实体名, attribute: 属性名, value: 属性值, source_utterance: 来源原句}]} 对话片段[最近的几轮对话文本]通过限定输出格式和提取类型能极大提高结构化数据的质量。后处理与去重提取出的JSON数据在存入向量数据库前会进行后处理。比如对同一实体的同一属性进行更新如张三的诉求从“换货”变为“退款”而不是简单新增。同时会用一个简单的规则检查明显的矛盾如同一个事实有两个相反的值并打上标记供后续人工复核。3.2 记忆的存储向量数据库的实践将提取出的结构化记忆存入Chroma需要几步生成嵌入向量对于每一条记忆如“张三-诉求-退款”我将其拼接成一段自然语言描述“关于人物张三的事实他的核心诉求是退款。” 然后用text-embedding-3-small模型将其转换为1536维的向量。这个描述文本的生成方式会影响检索效果我尝试了几种模板最终发现“关于[实体类型][实体名]的事实[属性]是[值]”这种格式效果最稳定。组织存储结构Chroma中我以session_id会话ID和user_id用户ID作为元数据metadata进行过滤。这样在检索时可以快速定位到特定会话或特定用户的记忆实现了记忆的隔离。每条记忆的向量、原始文本和元数据一起存储。设置索引Chroma会自动为向量创建索引。我选择了默认的HNSW索引它在精度和速度之间取得了很好的平衡。对于数据量不大的场景万条以内这完全够用。3.3 记忆的读取与运用在对话中“回忆”这是智能体显得“有记性”的关键。在生成回复前系统会执行一个“记忆检索”步骤生成检索查询直接使用当前用户的最新输入作为查询有时会显得不够精准。我采用了一个小技巧让LLM根据当前对话生成一个更明确的检索问题。例如用户说“那我的问题怎么解决”LLM可能会将其重写为“检索用户张三关于问题解决的历史诉求和承诺”。这个重写后的查询再进行向量化检索准确率更高。执行向量检索将查询向量送入Chroma指定session_id和user_id检索出最相似的K条记忆我通常设K5。Chroma会返回相似度分数。记忆筛选与注入不是所有检索到的记忆都相关。我会设置一个相似度阈值如0.7过滤掉低分记忆。然后将筛选后的记忆以清晰格式如“根据之前的记录1. 张三的诉求是退款2. 张三曾表示讨厌等待超过24小时...”拼接到给LLM的最终提示词Prompt中放在系统指令和当前对话历史之间。指导LLM使用记忆在系统指令中我会明确告诉LLM“以下‘历史记忆’是之前对话中提取的关键信息请在你的回复中充分考虑并恰当引用这些信息以体现对话的连续性。” 这样LLM生成的回复就会自然地带入“我记得你之前说过……”这样的表述。3.4 冲突调解逻辑的实现有了记忆系统作为基础调解员的具体逻辑就体现在精心设计的提示词和少量规则引擎上。角色设定与系统提示词这是智能体的“人格”。我的提示词大致如下你是一个专业的冲突调解员名字叫“和言”。你的目标是帮助双方厘清问题、促进理解、达成可行方案。 你的核心原则是中立不偏袒任何一方、共情理解各方情绪和需求、聚焦于解决方案引导对话向前看。 在对话中你需要主动1. 复述和确认各方观点2. 识别共同点和分歧点3. 基于历史信息提出建议4. 总结阶段性共识。 以下是本次对话相关的历史记忆[此处动态插入检索到的记忆] 当前对话历史[此处插入最近的对话记录] 请根据以上信息对用户的最新输入做出回应。多轮策略调度我实现了一个简单的状态机。根据对话内容智能体会处于不同“阶段”如“信息收集”、“情绪安抚”、“方案探讨”、“共识确认”。不同阶段其回复的侧重点和调用的工具如是否主动总结会有所不同。这通过分析用户输入的情绪标签和意图分类来实现。共识与承诺追踪这是记忆系统的杀手级应用。每当对话中达成一个共识如“双方同意在下周一前提交书面材料”或一个承诺如“我会在明天下午给你答复”系统会将其作为一条高优先级的“承诺”类型记忆提取出来。在后续的对话中智能体会主动询问承诺的履行情况如“关于周一提交材料的约定进展如何”从而推动事情落地而不是停留在空谈。4. 实操中的挑战与解决方案4.1 记忆的准确性与“幻觉”问题LLM在提取记忆时可能产生“幻觉”即编造不存在的事实。例如用户从未同意过方案A但LLM可能错误地提取出“用户同意方案A”。这种错误记忆一旦存入后患无穷。我的应对策略高置信度存储只提取那些在对话中明确陈述、且带有高确定性词汇如“是”、“要”、“同意”、“拒绝”的信息。对于模糊表达如“可能”、“也许”不予提取或标记为低置信度。来源追溯每条记忆都强制记录source_utterance来源原句。在向用户呈现或基于记忆做出判断时可以附带“根据您在X月X日说过的话‘……’”增加可信度也给了用户纠正的机会。定期记忆复审设计一个简单的管理界面可以查看和编辑某个会话的所有记忆。在关键节点可以由人工调解员本人或管理员对记忆进行审核和修正。冲突检测当试图存入一条与已有记忆明显矛盾的新记忆时如“诉求是退款” vs “诉求是换货”系统会触发一个警告并尝试从更完整的上下文去判断哪条更可信或者直接向用户提问确认。4.2 记忆的关联与检索效率随着对话进行记忆条目会越来越多。如何从海量记忆中快速、准确地找到当前最相关的几条是一个挑战。简单的向量相似度检索有时会跑偏。我的优化方法分层检索首先用session_id和user_id在元数据层面做快速过滤缩小搜索范围。这相当于先找到了正确的“记忆文件夹”。查询扩展如前所述用LLM对原始查询进行重写和扩展生成多个不同角度的查询词条分别进行检索然后合并去重。这提高了召回率。混合检索结合向量检索和关键词检索。对于名称、日期等精确信息关键词检索BM25更有效。我将两者结果以一定权重融合如70%向量相似度 30%关键词评分取得了更好的效果。记忆摘要在会话开始时先加载本次会话的“摘要记忆”让LLM快速了解背景。在检索具体细节时再用向量搜索。这种“摘要细节”的两步法既保证了宏观不偏题又保证了微观有依据。4.3 隐私与数据安全记忆系统存储了大量敏感的对话信息。必须严肃对待隐私。我采取的措施数据匿名化在存储前对记忆文本中的真实姓名、电话、身份证号等个人信息进行自动脱敏处理替换为占位符如[NAME_A]。记忆生命周期管理为不同类型的记忆设置不同的过期时间TTL。例如“情绪”类记忆可能24小时后自动删除“承诺”和“共识”类记忆则保留较长时间。所有记忆在会话结束一段时间后如30天可被整体归档或清除。用户控制权提供用户界面让用户可以查看、导出和删除系统关于自己的所有记忆。这是符合数据隐私法规如GDPR的基本要求。加密存储所有记忆数据在数据库包括向量数据库中均以加密形式存储。4.4 系统性能与成本控制频繁调用LLM进行记忆提取和查询重写以及生成嵌入向量都会产生API费用和延迟。我的成本优化实践异步与批处理记忆提取和摘要生成等非实时任务全部放到后台异步队列中执行不影响主对话线程的响应速度。并且可以积累一定量的文本后批量进行嵌入减少API调用次数。缓存机制对于频繁检索的、不常变化的记忆如用户的基本偏好将其向量和结果在应用层缓存一段时间如5分钟避免重复计算。模型分级使用对精度要求高的核心回复生成使用GPT-4对记忆提取、查询重写等任务使用更便宜的GPT-3.5-Turbo对生成嵌入向量使用专门的、性价比高的嵌入模型如text-embedding-3-small。上下文长度管理严格控制送入LLM的对话历史和记忆文本的总长度。采用滑动窗口只保留最近N轮对话对过长的记忆文本进行智能截断或总结确保不触发模型的上下文长度限制也节省了Token消耗。5. 效果评估与迭代方向经过一段时间的测试和迭代这个有记忆的调解员智能体展现出了几个明显的优势对话连贯性极大提升用户不再需要重复背景信息智能体能够基于记忆进行自然衔接用户体验更加流畅和“聪明”。调解深度增加智能体能够指出“你之前的诉求是A但现在似乎更关注B我们能聊聊这个变化吗”从而引导对话触及更深层的矛盾。促进责任落实通过对“承诺”类记忆的追踪和主动询问切实推动了部分线上争议的解决进程。当然它远非完美。目前主要的不足在于对复杂、隐晦情绪的识别和记忆还不够精准有时会机械地引用记忆而显得不够灵活。此外当冲突涉及多方、信息量巨大时记忆系统的组织和检索逻辑还需要进一步优化。未来的迭代方向我计划从以下几点入手记忆的主动遗忘与重要性加权不是所有记忆都同等重要。需要设计算法根据记忆被检索的频率、其关联事件的解决状态等动态调整记忆的“权重”或“活跃度”对于陈旧的、不重要的记忆进行降级或归档让系统更聚焦于关键信息。引入知识图谱目前的实体记忆还是扁平的键值对。下一步可以尝试将实体人、事、物之间的关系也存储起来构建一个轻量的知识图谱。例如“张三” “投诉” “产品B”“产品B” “属于” “部门C”。这样智能体的推理能力会更强能回答“还有谁遇到过类似问题”这样的关联性问题。多模态记忆如果对话场景支持未来可以考虑接入图像、语音甚至对话时的语气分析结果形成更立体的“用户画像”记忆使调解更加细腻。构建一个有记忆的AI系统就像在教一个数字大脑如何做笔记并学以致用。这个过程充满了挑战但每当看到它准确回忆起之前的对话细节并据此做出更人性化的回应时那种成就感是巨大的。这个项目让我深刻体会到AI应用的下一波浪潮或许不在于模型本身有多大而在于我们如何为它们设计更精巧、更实用的“外脑”和“工作流程”。如果你也在探索智能体记忆相关的应用欢迎交流我们一起踩坑一起前进。
