公众号内著述一览

图片

在AI应用中，不论是多轮对话场景、RAG场景照旧AI Agent场景中，挂念才略齐是不成或缺的一部分。但是，挂念才略是目下大模子的短板，是以，当今许多框架，诸如 LangChain、MetaGPT 等，齐封装了我方的挂念模块，以便捷开发者扫尾我方大模子应用的挂念功能。

之前我们简便概览了一下 LangChain 的 Memory 模块（【AI大模子应用开发】【LangChain系列】3. 一文了解LangChain的挂念模块（表面实战+细节）），那仅仅在多轮对话场景中，简便的取最近几次的对话历史四肢挂念。这是最简便的使用挂念的顺次，亦然短期挂念的一种。

本文我们来系统看下扫尾大模子应用挂念的顺次，包括短期挂念和恒久挂念。照旧以LangChain为例来进行实战。

0. LangChain中 Memory 实战

我这里将挂念简便领略为对话历史，查询历史等历史记载。

0.1 挂念封装胪列

在 LangChain 中提供了多种得回挂念的封装，举例ConversationBufferMemory、ConversationBufferWindowMemory、ConversationTokenBufferMemory等。

简便胪列如下：

· ConversationBufferMemory不错领略为通用的将全部的历史记登第出来。

· ConversationBufferWindowMemory不错领略为滑动窗口，每次只取最近的K札记载。

· ConversationTokenBufferMemory不错领略为戒指每次取的历史记载的Token数。

· ConversationSummaryMemory: 对高下文作念提要

· ConversationSummaryBufferMemory: 保存 Token 数驱散内的高下文，对更早的作念提要

· VectorStoreRetrieverMemory: 将 Memory 存储在向量数据库中，字据用户输入检索回最相关的部分

· ConversationEntityMemory：保存一些实体信息，举例从输入中找出一个东谈主名，保存这个东谈主的信息。

· ConversationKGMemory：将历史记载按常识图谱的步地保存和查询

这内部的大部分挂念封装，之前我们照旧学习过了，这里不再重迭。详备的使用教程不错参考我之前的著述：【AI大模子应用开发】【LangChain系列】3. 一文了解LangChain的挂念模块（表面实战+细节）。

个位：上期为3,质号,合号最近两周相对走冷，遗漏4次，本期关注合号，参考8。

底下看下 VectorStoreRetrieverMemory 的使用和扫尾成果。

0.2 试验：VectorStoreRetrieverMemory的使用0.2.1 齐全代码

from langchain.memory import VectorStoreRetrieverMemoryfrom langchain_openai import ChatOpenAIfrom langchain.embeddings.openai import OpenAIEmbeddingsfrom langchain.vectorstores import Chromafrom langchain.chains import ConversationChainfrom langchain.prompts import PromptTemplatevectorstore = Chroma(embedding_function=OpenAIEmbeddings())retriever = vectorstore.as_retriever(search_kwargs=dict(k=1))memory = VectorStoreRetrieverMemory(retriever=retriever)memory.save_context({"input": "我可爱学习"}, {"output": "你真棒"})memory.save_context({"input": "我不可爱玩儿"}, {"output": "你可太棒了"})PROMPT_TEMPLATE = """以下是东谈主类和 AI 之间的友好对话。AI 话语多且提供了许多来自其高下文的具体细节。如若 AI 不知谈问题的谜底，它会敦厚地说不知谈。以前对话的相关片断：{history}（如若不相关，你不需要使用这些信息）现时对话：东谈主类：{input}AI："""prompt = PromptTemplate(input_variables=["history", "input"], template=PROMPT_TEMPLATE)chat_model = ChatOpenAI()conversation_with_summary = ConversationChain(    llm=chat_model,    prompt=prompt,    memory=memory,    verbose=True)print(conversation_with_summary.predict(input="你好，我叫同学小张，你叫什么"))print(conversation_with_summary.predict(input="我可爱干什么？"))

0.2.2 代码诠释注解

（1）代码中我们使用了 VectorStoreRetrieverMemory 四肢挂念存储和得回的模块。它既然是向量存储和查询，是以继承参数：retriever=retriever，必须要穿给它一个向量数据库才调使命。

（2）然后使用了 ConversationChain 四肢对话的Chain。它继承一个 memory = memory 参数设备，指定使用的挂念类型。默许是最平庸的 ConversationBufferMemory 类型。

图片

（3）什么时分会去检索挂念呢？在Chain运行 invoke 的一运行，就加载了。源码如下：

图片

图片

图片

不错看到，临了即是用用户的输入，行止量数据库中检索相关的片断四肢需要的挂念。

0.2.3 运行成果展示

第一个问题，检索到的内容不相关，但是也得检索出一条。

图片

第二个问题，检索到的内容相关，用检索到的内容回答问题。

图片

1. 若何让AI应工具备恒久挂念？

我这里将“恒久挂念”领略为捏久化挂念省略长高下文挂念。也即是两种步地的挂念我齐认为是“恒久挂念”：

· 第一种：捏久化挂念，对话历史等历史记载捏久化保存，不会跟着进度的退出而隐匿。举例保存到手文献或存储进数据库等。

· 第二种：长高下文挂念，当历史记载极端多时，若何从历史记载中找出灵验的挂念，而不是只顺心最近的几条历史记载。

1.1 LangChain 中的挂念模块是否具有恒久挂念的才略？

上头胪列的和实战的 LangChain 中的挂念模块，ConversationBufferMemory、 ConversationBufferWindowMemory、ConversationTokenBufferMemory 看起来齐无法扫尾恒久挂念的才略：无法捏久化（看源码，底层齐是一个List类型，保存到内存，跟着进度沦一火而沦一火），也没法查询长的高下文。

图片

 ConversationSummaryMemory、ConversationSummaryBufferMemory 在一定程度上能提供更多的挂念信息（因为其对之前的历史记载作念了记忆压缩），是以在某些高下文不是极端长的场景中，照旧不错用一用来扫尾简便的恒久挂念才略的。

ConversationEntityMemory、ConversationKGMemory一个只保存实体信息，一个将历史记载组织成常识图谱，会对长高下文场景中的万古挂念功能异常灵验。它不错从全局的角度将用户发问中的实体或相关常识作补充，而不是顺心最近的几次对话。

VectorStoreRetrieverMemory应该是最佳和最能扫尾恒久挂念才略的类型了。一方面，它是向量数据库存储，不错便捷的捏久化数据，物联网app开发另一方面，它的向量检索才略，原来即是针对用户发问检索出最相关的文档片断，不受长高下文的窗口驱散。但是其检索的相关片断之间是否存在信息缺失等，会影响万古挂念的准确性，从而影响最终的驱散。

是以，ConversationEntityMemory、ConversationKGMemory + VectorStoreRetrieverMemory 是否不错一试？三者揣摸，保捏相关片断的相关性，同期应用实体关系和常识图谱进行补充，是否不错更好地扫尾万古挂念的才略？感兴味的不错通盘接头~

1.2 对于让AI应工具备恒久挂念的一些讨论1.2.1 挂念想考：回忆和后想考使LLM具有恒久挂念

论文原文：Think-in-Memory: Recalling and Post-thinking Enable LLMs with Long-Term Memory

这篇著述建议了一种名为TiM（Think-in-Memory）的挂念机制，旨在使LLM在对话过程中保捏挂念，存储历史想考。TiM包括两个环节阶段：在生成恢复之前，LLM从挂念中追念相关想考；在生成恢复之后，LLM进行后想考并将历史和新想考揣摸起来更新挂念。

下图描绘了TiM顺次的使用面孔：

（1）在回答第二个问题时，需要沟通问题1的内容，从问题1中推理出谜底，尔后在回答问题2。 （2）在回答第三个问题时，需要同期沟通问题1和问题2，从问题1和问题2中推理出谜底，尔后再回答问题3。

这就导致了问题的存在：问题1被推理了两遍，两遍的驱散还可能不相似，导致最终的不实。

而TiM的想路，是将每一个问题的想考也存起来，这么，在回答问题3时，不错使用问题2之前的想考，幸免从头想考问题1，从而幸免屡次想考驱散不一致导致的不实。

图片

具肉步地如下：

图片

app

总的旨趣是，将相关的挂念放到通盘，举例上图中，对于book的语言放到index 0中，对于moive的语言放到index 1中。

若何将相关内容放到通盘的？论文中扫尾了一种基于局部明锐哈希（LSH）的存储系统，用于高效地存储和检索大范畴的向量数据。LSH的作用是将每个向量映射到一个哈希索引，相似的向量有更高的概率被映射到疏导的哈希索引。

而疏导的哈希索引不错将用户问题固定到某一块挂念中，然后只在这一块挂念中进行向量检索，大大提拔了检索遵循。

这篇著述照旧值得精读一下的，数据的组织面孔和索引面孔齐相比高等，很有启发。

1.2.2 递归记忆在大型语言模子中扫尾恒久对话挂念

论文原文：Recursively Summarizing Enables Long-Term Dialogue Memory in Large Language Models

这篇著述建议了一种递归记忆的顺次，用于增宽阔模子的恒久挂念才略，以科罚在长对话中无法回忆昔日信息和生成不一致反应的问题。该顺次领先刺激LLM挂念小的对话高下文，然后递归地使用先前的挂念和后续的高下文生成新的挂念。

其过程如下：

图片

简便详尽，即是：上一轮的内容记忆 + 本轮的问题回答 = 本轮的内容记忆。本轮的内容记忆 + 下轮的问题回答 = 下轮的内容记忆。...... 不休迭代。与 LangChain中ConversationSummaryMemory 的扫尾很雷同。

这种顺次每一轮齐要记忆一次，也即是调用一次大模子，使用资本很高啊...... 骨子分娩中应该落地相比难。

1.2.3 更多讨论

更多对于AI应用 Memory 的讨论不错参考底下这个著述：

张泽宇，公众号：RUC AI EngineLLM-based Agent Memory相关论文集锦

加个TODO，还没看完，内行不错通盘看。

如若认为本文对你有匡助，艰苦点个赞和顺心呗 ~~~

· 内行好，我是 同学小张，平日共享AI常识和实战案例

· 迎接 点赞 + 顺心 👏，捏续学习物联网软件开发公司，捏续干货输出。

本站仅提供存储职业，通盘内容均由用户发布，如发现存害或侵权内容，请点击举报。

• AI
• 模子
• 物联网软件开发公司
• 挂念
• 应用开发