简介(未完成)
为了更好地理解智能体记忆的工作原理,我们首先需要区分“存储”和“记忆”的概念。
- 存储:通常指数据的保存与管理。程序通过文件系统、数据库或内存等手段来存储数据。存储是被动的,数据仅在被明确调用时才会被取用。
- 记忆:记忆不仅是对数据的保存,它还包含了对过去事件、知识、经验的主动回忆与调用。记忆是有目的性的,通过上下文或条件触发,能够帮助智能体在适当的场景下自动检索相关信息。 在智能体系统中,“存储”更多对应的是持久化数据的保存,而“记忆”则对应智能体对过去交互的“理解”与“回忆”。也就是说,智能体的记忆是一种主动系统,它能够通过交互学习、累积知识,进而优化后续对话或决策。
举例说明
- 存储:当一个智能体被设计来存储用户的信息,如用户的地址或偏好,智能体只需在数据库中保存这些数据即可,后续用户查询时直接检索数据库即可。
- 记忆:智能体能够自动记住用户过去的交互内容,比如用户之前提到自己喜欢的编程语言是Python,下一次用户询问推荐书籍时,智能体可以根据这个记忆推荐Python相关书籍。
当LangGraph遇上Mem0:如何让你的AI Agent具有更智能的记忆与个性化的体验?
分类
根据智能体在不同场景下记忆的功能和用途,智能体记忆可以划分为以下几种主要类型:
- 程序性记忆。程序性记忆类似于人类大脑中的“核心指令集”,即智能体记住如何执行任务。它是关于“如何做某事”的记忆,涵盖了智能体执行任务的规则和流程。举例:人类的程序性记忆体现在学会如何骑自行车,而智能体的程序性记忆则可能体现在如何处理某类任务,比如如何在Excel中自动生成特定的图表。
- 语义记忆。语义记忆是智能体的长期知识库,类似于人类的长期知识记忆。它存储了世界上各类事实和信息。智能体可以通过语义记忆来回答特定问题或在对话中调用相关信息。举例:人类的语义记忆包含了学校里学到的知识,智能体的语义记忆则可以包括用户喜欢的电影类型或编程语言。
- 情景记忆。情景记忆是指回忆特定事件或过去的经历。在智能体中,情景记忆用于记住某个特定的用户交互过程,帮助智能体在相似的场景下应用相同的解决方案。举例:用户多次向智能体寻求相同类型的帮助,智能体可以通过情景记忆迅速检索出过去类似交互中的解决方法,减少重复问题的处理时间。
智能体记忆的几个显著特点:
- 智能体的记忆可以分为长期记忆和短期记忆。短期记忆通常用于在当前会话中保存最近的交互信息,而长期记忆则用于跨会话的知识累积和历史信息的存储。
- 短期记忆:主要应用在对话中,智能体能够记住当前会话中的内容。例如,在用户与客服机器人的交谈中,短期记忆允许智能体记住用户在会话中的请求或问题,以确保下一次回复更加准确。
- 长期记忆:智能体在多次交互中积累知识。例如,一个购物推荐系统可以记住用户过去购买的产品偏好,以便将来推荐相关产品。
- 上下文相关性。智能体的记忆并不是被动的存储,而是与上下文强相关的。它能够通过当前的对话或环境条件触发相关记忆。也就是说,智能体在不同的情境下能够检索和应用不同的记忆。
- 自我更新与学习。智能体的记忆具有学习能力。它能够根据与用户的交互不断更新自身的记忆,逐步积累更多的知识,从而为用户提供更个性化的服务。比如一个智能体帮助用户处理财务报表,它可以记住用户之前的操作习惯,比如每次生成报表的具体格式、常用的过滤条件等。在后续操作中,智能体可以基于这些记忆自动优化用户体验。
记忆的更新是智能体记忆系统中的关键部分。智能体的记忆更新可以分为两种主要方式:热路径更新和后台更新。
- 热路径更新是指在智能体生成响应之前直接更新记忆。它是在每次交互中显式触发的更新方式,通常用于即时性的反馈。例如,用户输入的信息在经过智能体处理后,直接保存为长期记忆,供下次交互时调用。
- 优点:及时更新,无需等待。
- 缺点:增加了每次交互的处理延迟,影响响应速度。
- 后台更新则是在交互结束后,由后台进程在不影响用户体验的情况下自动更新记忆。这种方式能够减少前台处理的压力,但需要设计合理的触发机制来启动后台进程。
- 优点:不影响实时响应速度,能够在交互结束后自动完成记忆更新。
- 缺点:可能存在更新延迟,记忆不能立刻在下一次交互中生效。
- 用户反馈驱动的更新。智能体也可以通过用户反馈来优化记忆更新。用户可以标记特定的交互为“有帮助”或“无帮助”,帮助智能体调整记忆的优先级和更新策略。 在一个在线客服系统中,用户多次询问如何申请退款,智能体每次都会提供不同的解决方案。在热路径更新的情况下,智能体可以即时记住用户喜欢的解决方案并在下次交互中优先使用。而在后台更新的模式下,客服结束后,系统会自动分析用户的反馈,决定是否更新记忆。
与历史人工会话的关系
历史人工会话如何用在RAG也是一个比较难的命题,信息挖掘存在几个难点,其一为数据源较杂乱,不同于标准化的书面文本,其中掺杂了较多口语化内容,且格式不一,其挖掘难度大;其二为关键信息关联性低,往往用户的问题是通过多轮交互后才能得到解决方案,解决方案较为分散;其三为信息准确度要求高,若挖掘出来的信息准确率较低,在后续的检索中会削弱模型性能,降低智能问答效率。在历史会话的挖掘上,我们也在调研后考虑了两个方案。
- 初期调研时,针对大部分历史会话的探索基本上还是微调大模型对会话进行总结和摘要的能力。但在我们的场景下,一些研发平台的人工答疑链路会很长,直接利用整个总结数据灌入知识库又回到了Query-Document匹配难的问题。这里要解决也可以再进行细粒度query抽取,从总结里再生成问题和对应答案。但整体方案这样看起来会有个误差累积的风险,所以我们在构思,是不是也可以直接微调一版能够从历史会话中直接抽取有效问答对的模型。
- 历史会话问答对挖掘。如上述思路,我们将方案转变到历史会话的问答对直接挖掘。下图为利用会话问答对大模型对历史工单进行问答对抽取的推理流程。第一个核心模块是会话问答对大模型,这里我们利用了多尺度的问答对提取策略。针对会话问题中多轮回答的复杂性,单步提示难以让模型同时感知到全局和局部的知识。我们设计了一种分步提示(Multi-Step Prompting)策略,该生成策略用于训练数据准备、训练任务构造及大模型推理三个部分。本策略将针对历史会话的问答对抽取分解为两层子任务,分别构建不同的提示词prompt,包括全局层和局部层。
- 全局问答对抽取:由于往往一个历史会话工单中用户有最初进入提问的主要问题,而该类主要问题的解决方案往往横跨了整个对话。因此在全局层,首先要求大模型熟悉会话全文并理解全文判断会话中客服是否解决了用户所提出的主要问题,若解决了,则输出全局的问答对。
- 局部问答对抽取:考虑到内部研发问题的复杂度往往较高,在多轮对话中往往存在多个衍生子问题,该类问题对于知识库建设也起着较为关键的作用。因此在局部层,要求大模型从局部出发,判断用户可能提出的业务问题及客服是否有解决方案,若有解决方案,则输出多个局部问答对。 针对上下两层子任务,我们分别设计了相应的提示词,基于这个策略我们借用开源模型抽取+人工检验标注了基于2000+个会话的问答对数据,最终可用数据有1300条。我们用这批数据lora微调了Qwen-14b的模型。为了保证问答对抽取的完整性,并未限制抽取的问答对的数量,因此局部抽取模块的问答对抽取自由度较高,导致可能会有脏数据产生。我们也利用大模型对抽取的问答对作质量评估,将质量较低的问答对筛选掉。由于前文所述的会话问答对大模型在经过对话数据微调后,对于对话有相应理解能力,此处我们仅用该大模型作简单的评估即可对部分无关问题进行剔除。我们抽取问答对的可用率在试点租户上可达70%。
作为领域知识
先验知识扩充-领域型知识抽取许多模型预先并不知道一些领域内的先验知识,单凭检索出来的相关内容进行回答总会有效果不好的问题。因此,也有许多领域化的探索想方设法将领域化知识传入大模型中。这类探索也大致可以归纳成以下两类。
- 将领域型知识内化进大模型。将领域型知识内化进大模型也就是让大模型在回答前就已经学习了相关的领域类知识,最常用的就是领域化数据微调方案。一开始都会去尝试微调,但我们前期的微调效果不佳,后续没有再走这条路的原因有几个:
- 数据收集对我们来说难度高,需要有业务的同学帮忙去整理一些领域高质量数据,同时领域化数据也需要配比一些通用型数据进行微调,数据质量也很影响最终的;
- 不同研发平台的领域化概念可能不同,为每个平台都定制领域化微调模型并部署,这个资源上是完全不可行的;
- RAG做到后面,其实生成部分用的开源大模型的更迭是很快的,我们不太可能及时去训新开源的模型,换更新的大模型的收益又比用微调后的原有模型增益高。
- 如果后续能有一些知识编辑的策略,可以低成本地将我们内部的所有的研发文档输入到模型的某个记忆单元,在模型层面也就相当于做了增量的预训练。但短期内,在落地上更有效的方案还是将领域型知识显示地灌入大模型。
- 将领域型知识显式给大模型,实际落地上,我们暂时没法让模型长期记忆里存储领域型知识,于是选择的方案是对query进行知识检索的同时也去检索一遍相关领域专有知识,类似于MemoRAG的机制去建立我们的领域Memo Model。这套方案的核心也是在于领域的Memo Model如何构建。在这里,我们构建了基于领域图谱的MemoRAG。由于我们在构建领域图谱的时候,大模型遍历了整个知识库,它能获取的领域关联在一次次遍历和总结时候的可用率是非常高的。
- 构建领域图谱的具体步骤如下: step1: 模型会先多次读取文档分块,从中提取出领域实体(可结合不同场景规定实体类型)。 step2: 在遍历完所有文档分块后,模型会再多次遍历提取出的领域实体,将其中的相似相关实体进行合并再总结。 step3: 对合并后的实体,模型再根据文本块去提取实体之间的关联。 step4: 对抽取的实体和关联做社区发现,并对所聚集的社区做报告摘要
- 因此,在一整个链路后,模型能够获取跨文档完整的领域实体相关知识。对每个实体,模型也会做社区发现,生成社区报告。这类实体和社区报告,在这里完全可以作为Memo Model的重要组成。query进来后,我们首先对query分词去我们的领域Memo Model中检索属于该租户的相关领域线索,并后续一并给模型,显式地将领域知识灌入模型。PS:MemoRAG 和图谱结合还能这么玩,做图谱的时候,本来就要搞一些总结,不做白不做。