玩转 LangChain Memory 模块:四种记忆类型详解及应用场景全覆盖

news2025/1/12 2:25:02

系列文章目录

01-玩转LangChain:从模型调用到Prompt模板与输出解析的完整指南
02-玩转 LangChain Memory 模块:四种记忆类型详解及应用场景全覆盖


文章目录

  • 系列文章目录
  • 前言
  • 一、LangChain Memory 概述
    • 1.1 什么是 Memory?
      • 1.1.1 Memory 的核心功能
      • 1.1.2 为什么需要 Memory?
    • 1.2 Memory 的四种主要类型
      • 1.2.1 ConversationBufferMemory
      • 1.2.2 ConversationBufferWindowMemory
      • 1.2.3 ConversationTokenBufferMemory
      • 1.2.4 ConversationSummaryMemory
    • 1.3 Memory 的实际应用场景
    • 1.4 Memory 的工作原理
  • 二、ConversationBufferMemory:基础对话记忆
    • 2.1 基础概念与应用场景
      • 2.1.1 什么是 ConversationBufferMemory?
      • 2.1.2 应用场景
    • 2.2 使用示例:构建基础对话链
      • 2.2.1 初始化与基本配置
      • 2.2.2 示例对话:中文任务管理助理
      • 2.2.3 查看对话历史
    • 2.3 手动保存与加载对话
      • 2.3.1 手动保存对话
      • 2.3.2 手动加载对话
    • 2.4 注意事项与最佳实践
      • 2.4.1 注意事项
      • 2.4.2 最佳实践
  • 三、ConversationBufferWindowMemory:窗口式对话记忆
    • 3.1 基础概念与特点
      • 3.1.1 什么是 ConversationBufferWindowMemory?
      • 3.1.2 应用场景
    • 3.2 使用示例:限制上下文长度
      • 3.2.1 初始化与窗口大小配置
      • 3.2.2 示例对话:快递查询助理
      • 3.2.3 构建对话链
    • 3.3 与 ConversationBufferMemory 的对比
    • 3.4 注意事项与优化建议
      • 3.4.1 注意事项
      • 3.4.2 优化建议
  • 四、ConversationTokenBufferMemory:基于 Token 的记忆管理
    • 4.1 基础概念与特点
      • 4.1.1 什么是 Token?
      • 4.1.2 什么是 ConversationTokenBufferMemory?
      • 4.1.3 应用场景
    • 4.2 使用示例:基于 Token 限制的对话
      • 4.2.1 初始化与配置
      • 4.2.2 示例对话:新闻推荐助手
    • 4.3 注意事项与优化建议
      • 4.3.1 注意事项
      • 4.3.2 优化建议
  • 五、ConversationSummaryMemory:对话总结记忆
    • 5.1 基础概念与特点
      • 5.1.1 什么是 ConversationSummaryMemory?
      • 5.1.2 应用场景
    • 5.2 使用示例:对话总结
      • 5.2.1 初始化与配置
      • 5.2.2 示例场景:会议记录助手
    • 5.3 注意事项与优化建议
      • 5.3.1 注意事项
      • 5.3.2 优化建议
  • 六、Memory 类型的选择与应用
    • 6.1 各种 Memory 类型的对比
    • 6.2 Memory 类型的选择原则
      • 6.2.1 根据对话长度选择
      • 6.2.2 根据资源限制选择
      • 6.2.3 根据上下文需求选择
    • 6.3 实际应用案例分析
      • 6.3.1 案例 1:智能客服系统
      • 6.3.2 案例 2:物流查询助手
      • 6.3.3 案例 3:任务型对话助手(会议记录)
      • 6.3.4 案例 4:实时聊天系统
  • 七、总结
    • 7.1 核心要点回顾


前言

在构建智能对话系统时,你是否遇到过以下问题:

  • 用户刚刚告诉系统自己的名字,而下一轮对话中系统却“忘记”了?
  • 面对长时间的多轮对话,如何在有限资源下高效管理上下文?
  • 如何在信息量巨大的交互中,快速提炼核心内容而不遗漏关键信息?

在传统对话模型中,由于上下文信息管理的缺失,模型经常会给出不连贯或无意义的回答。而随着对话应用需求的不断升级,存储和管理对话历史变得至关重要。LangChain 提供了强大的 Memory 模块,让我们能够轻松实现对话的“记忆力”,从而构建出更智能、更连贯的对话系统。

本文是 LangChain 系列教程 的重要一环,详细解析 Memory 模块中的四种主要记忆类型,包括:

  • ConversationBufferMemory:保存完整对话记录;
  • ConversationBufferWindowMemory:仅保存最近几轮对话;
  • ConversationTokenBufferMemory:基于 Token 限制的记忆管理;
  • ConversationSummaryMemory:通过总结提炼对话的核心信息。

通过通俗易懂的讲解、逐步深入的代码示例,以及贴近实际应用的场景分析,本文将帮助你轻松掌握 Memory 模块,解决对话上下文管理中的难题,为构建更加高效的智能对话系统打下坚实的基础。

无论你是对 LangChain 感兴趣的初学者,还是正在设计智能助手、客服系统或教育应用的开发者,相信这篇文章都能为你带来启发!


一、LangChain Memory 概述

1.1 什么是 Memory?

Memory(记忆)是 LangChain 框架中的一个重要模块,旨在管理对话的上下文信息。在构建对话系统时,单轮问答通常不足以满足复杂需求,因为用户的输入往往与之前的对话内容相关。Memory 的主要作用是让模型具备“记忆力”,可以追踪对话历史,从而生成更连贯和智能的回复。

1.1.1 Memory 的核心功能

  • 上下文跟踪:记录用户和系统的对话内容,避免上下文丢失。
  • 增强连贯性:通过历史记忆,确保模型的输出与之前的对话保持一致。
  • 灵活存储:支持不同的存储方式,如完整存储、部分存储或基于总结的存储。

1.1.2 为什么需要 Memory?

传统对话系统通常是无状态的,这意味着每轮对话都是独立的,无法考虑之前的交互。这种方式的局限性如下:

  • 缺乏上下文意识:模型无法记住用户的名字、需求等信息。
  • 对话不自然:系统无法生成与之前对话逻辑相关的回答。

通过 Memory 模块,可以解决这些问题,让对话更加智能化。例如:

  • 在技术支持聊天中,记住用户的设备型号或问题背景。
  • 在教育应用中,记住学生的学习进度和偏好。

1.2 Memory 的四种主要类型

LangChain 提供了四种 Memory 模块,分别适用于不同的对话场景和需求:

1.2.1 ConversationBufferMemory

特点:完整保存对话历史,适合需要完整上下文的场景。
应用场景

  • 客服系统:需要记录所有对话内容,便于后续查询。
  • 教学对话:需要保留完整的教学记录。

1.2.2 ConversationBufferWindowMemory

特点:仅保存最近若干条对话,适合对历史上下文要求较低但需要近期对话信息的场景。
应用场景

  • 简单问答系统:关注用户近期输入即可。
  • 快速对话场景:如天气查询或简单助手。

1.2.3 ConversationTokenBufferMemory

特点:基于 Token 限制存储对话历史,保证存储内容不会超过指定的 Token 数。
应用场景

  • 长文本对话:在上下文较长时,限制存储的内容大小以节省计算资源。
  • 复杂对话:对上下文有一定要求,但需要控制资源开销。

1.2.4 ConversationSummaryMemory

特点:通过总结方式存储对话历史,浓缩对话内容,保留核心信息。
应用场景

  • 长期对话:如客户关系管理,需要记录关键事件和要点。
  • 任务型对话:如会议助手,总结会议要点。

1.3 Memory 的实际应用场景

Memory 模块在许多场景中都有广泛应用,以下是几个常见的实际案例:

  • 智能客服:在多轮对话中,记住用户的背景信息和问题描述,提供更精准的解决方案。
  • 虚拟助手:记住用户的个人信息,如名字、喜好或习惯,让对话更加个性化。
  • 教育场景:记录学生的学习进度,提供针对性的教学建议。
  • 任务跟踪:帮助用户记录重要任务和日程,提升生产力。

1.4 Memory 的工作原理

Memory 的核心工作原理是通过保存对话的输入(用户问题)和输出(模型回答)来构建对话上下文。根据 Memory 类型的不同,保存和管理上下文的方式也有所不同:

  • Buffer Memory:直接按时间顺序保存对话。
  • Window Memory:只保存最近几轮对话。
  • Token Buffer Memory:基于 Token 长度裁剪对话历史。
  • Summary Memory:通过总结提取关键内容并存储。

二、ConversationBufferMemory:基础对话记忆

2.1 基础概念与应用场景

2.1.1 什么是 ConversationBufferMemory?

ConversationBufferMemory 是 LangChain 提供的最基础的 Memory 类型,其核心功能是记录对话中的所有历史消息,无论是用户的输入还是模型的输出。这种方式确保了整个对话的上下文都能被完整地保留下来。

特点

  • 完整性:无损地存储对话内容。
  • 直观性:适合简单且需要完整上下文的场景。

2.1.2 应用场景

ConversationBufferMemory 适用于以下场景:

  1. 智能客服:需要完整记录用户和客服的交互过程,便于回溯和分析。
  2. 教学助手:保存学生提出的问题及系统的回答,帮助复习。
  3. 聊天机器人:在休闲聊天中保存上下文,提供连贯性更强的对话体验。

示例场景
假设我们构建一个虚拟助理,帮助用户完成任务。用户先告诉助理自己的名字,随后咨询日期计算等功能。如果系统没有 Memory,助理可能会忘记用户的名字。而使用 ConversationBufferMemory,可以确保助理始终记得用户的名字和之前的交互。


2.2 使用示例:构建基础对话链

2.2.1 初始化与基本配置

我们首先需要加载必要的库,并初始化 LangChain 的核心组件,包括聊天模型(ChatOpenAI)和 Memory 模块(ConversationBufferMemory)。

import os
from dotenv import load_dotenv # type: ignore
from langchain_openai import ChatOpenAI # type: ignore
from langchain.memory import ConversationBufferMemory
from langchain.chains import ConversationChain

# 加载 .env 文件中的环境变量
load_dotenv()

# 从环境变量中获取 API Key 和 Base URL
api_key = os.getenv("ALIYUN_API_KEY")
base_url = os.getenv("ALIYUN_API_URL")

# 初始化 ChatOpenAI 客户端
llm = ChatOpenAI(
    openai_api_key=api_key,  # 必须明确设置 api_key
    model_name="qwen-plus",  # 使用 qwen-plus 模型
    base_url=base_url,  # 设置 Base URL
)

memory = ConversationBufferMemory()

# 构建对话链
conversation = ConversationChain(
    llm=llm,
    memory=memory,
    verbose=True
)

2.2.2 示例对话:中文任务管理助理

以下是一个中文对话示例,我们创建一个帮助用户管理日程的虚拟助理:

# 用户输入1:自我介绍
print(conversation.predict(input="你好,我叫李华。"))
# 用户输入2:介绍朋友
print(conversation.predict(input="我的朋友叫张三。"))
# 用户输入3:记忆测试
print(conversation.predict(input="你还记得我和我的朋友叫什么名字吗?"))

输出结果

李华:你好,我叫李华。
助理:你好,李华!很高兴认识你。
李华:我的朋友叫张三。
助理:很高兴知道你朋友的名字是张三。
李华:你还记得我叫什么名字吗?
助理:当然记得!你叫李华,你的朋友叫张三。

2.2.3 查看对话历史

使用 memory.buffer 方法可以查看完整的对话历史:

print(memory.buffer)

输出结果

Human: 你好,我叫李华。
AI: 你好,李华!很高兴认识你。虽然我是一个AI,但我可以进行友好和有意义的对话,帮助你解决问题或提供信息。有什么我可以帮你的吗?
Human: 我的朋友叫张三。
AI: 很高兴知道你朋友的名字是张三。如果你需要任何帮助,比如想和我分享关于张三的一些有趣的事情,或者需要一些建议如何与张三更好地相处,都可以告诉我。我在这里倾听并提供帮助。另外,我也能提供其他各种信息或帮助解答问题。你有什么想聊的吗?
Human: 你还记得我和我的朋友叫什么名字吗?
AI: 当然记得!你叫李华,你的朋友叫张三。我很擅长记住这些信息,所以如果你有更多关于你们的故事或者需要任何帮助的地方,随时可以告诉我。有什么特别的事情想和我分享或者讨论吗?

可以看到,Memory 完整记录了每一轮对话,确保上下文没有丢失。


2.3 手动保存与加载对话

除了使用 ConversationChain 自动管理对话上下文外,我们还可以手动保存和加载对话内容,以便更灵活地使用 Memory。

2.3.1 手动保存对话

通过 memory.save_context() 方法,可以手动存储用户的输入和模型的输出。例如:

# 保存对话
memory.save_context({"input": "早上好"}, {"output": "早上好!有什么可以帮您的吗?"})

2.3.2 手动加载对话

通过 memory.load_memory_variables() 方法可以加载存储的内容:

# 加载对话
print(memory.load_memory_variables({}))

输出结果

{'history': '用户:早上好\n系统:早上好!有什么可以帮您的吗?'}

2.4 注意事项与最佳实践

2.4.1 注意事项

  1. 数据增长问题:随着对话轮次增加,Memory 中存储的内容可能会不断增长,从而影响性能。
    • 解决方案:对于特别长的对话,可以考虑其他 Memory 类型(如 WindowMemory 或 TokenBufferMemory)。
  2. 隐私保护:在敏感场景下,应对对话历史进行加密或敏感数据脱敏处理。

2.4.2 最佳实践

  • 结合实际需求选择 Memory 类型:对于需要完整上下文的任务,可以直接使用 ConversationBufferMemory;对于上下文较少或限制较大的场景,可以选择其他类型。
  • 定期清理 Memory:对于无需长期保存的对话历史,建议在任务完成后清理 Memory。

三、ConversationBufferWindowMemory:窗口式对话记忆

3.1 基础概念与特点

3.1.1 什么是 ConversationBufferWindowMemory?

ConversationBufferWindowMemory 是 LangChain 提供的一种 Memory 类型,与 ConversationBufferMemory 不同的是,它只保存最近几轮对话,而不是完整的对话历史。这种方式通过限制窗口大小,确保存储的对话内容始终保持在指定的条数范围内,从而提高效率并避免冗余数据的存储。

特点

  • 窗口限制:仅保留最近的 k 条对话。
  • 内存占用低:随着对话轮次增加,历史内容会被丢弃,只存储最新内容。
  • 适用场景明确:适合需要短期上下文的对话任务。

3.1.2 应用场景

  1. 短期上下文对话:如天气查询、翻译任务等,仅需参考最近几轮输入。
  2. 高频交互场景:如快递查询系统,用户关注的通常是最近一次交互的内容。
  3. 性能优化场景:在资源有限的环境中,通过限制对话长度减少计算量。

示例场景
假设我们构建一个聊天机器人,用户咨询物流状态。由于用户往往只关心当前包裹的查询内容,保存完整历史并无意义,因此可以使用 ConversationBufferWindowMemory 限制窗口大小。


3.2 使用示例:限制上下文长度

3.2.1 初始化与窗口大小配置

首先,我们通过指定参数 k 来设置窗口大小(即存储的对话条数)。以下代码展示了如何初始化 Memory:

from langchain.memory import ConversationBufferWindowMemory

# 初始化窗口式记忆模块,设置窗口大小为 2
memory = ConversationBufferWindowMemory(k=2)

3.2.2 示例对话:快递查询助理

以下是一个中文示例,用户咨询快递状态,系统只保留最近两轮对话:

# 保存对话
memory.save_context({"input": "你好,帮我查询一下快递状态"}, 
                    {"output": "好的,请提供快递单号"})
memory.save_context({"input": "单号是 123456789"}, 
                    {"output": "您的快递正在配送中,预计明天到达"})
memory.save_context({"input": "能再确认一下时间吗?"}, 
                    {"output": "预计到达时间是明天下午 3 点"})

使用 memory.load_memory_variables() 方法查看当前存储的对话内容:

print(memory.load_memory_variables({}))

输出结果

{'history': '用户:单号是 123456789\n系统:您的快递正在配送中,预计明天到达\n用户:能再确认一下时间吗?\n系统:预计到达时间是明天下午 3 点'}

可以看到,仅保留了最近两轮的对话,而较早的对话被丢弃。


3.2.3 构建对话链

通过 ConversationChain 集成 Memory,可以实现完整的对话链功能,以下代码展示了一个完整的示例:

from langchain_openai import ChatOpenAI # type: ignore
from langchain.chains import ConversationChain

# 初始化 LLM 和窗口记忆模块
llm = ChatOpenAI(
    openai_api_key=api_key,  # 必须明确设置 api_key
    model_name="qwen-plus",  # 使用 qwen-plus 模型
    base_url=base_url,  # 设置 Base URL
)
memory = ConversationBufferWindowMemory(k=2)
conversation = ConversationChain(
    llm=llm,
    memory=memory,
    verbose=True,
)

# 示例对话
print(conversation.predict(input="1+1等于几?"))
print(conversation.predict(input="2+2等于几?"))
print(conversation.predict(input="4+4等于几?"))

print(memory.load_memory_variables({}))

输出结果

用户:2+2等于几?
系统:2+2等于4。
用户:4+4等于几?
系统:4+4=8。

可以发现,仅存储了最近两轮的对话内容,最早的输入(“1+1等于几?”)已经被丢弃。


3.3 与 ConversationBufferMemory 的对比

以下是两种 Memory 的主要区别:

特性ConversationBufferMemoryConversationBufferWindowMemory
存储内容完整记录所有对话仅记录最近 k 条对话
内存占用随对话增加而增加固定占用内存(由 k 决定)
适用场景需要完整上下文的长对话场景仅需近期上下文的短对话或高效对话场景

3.4 注意事项与优化建议

3.4.1 注意事项

  1. 窗口大小的选择k 的大小直接影响上下文的有效性。如果 k 设置过小,可能导致对话不够连贯;如果过大,则会增加资源消耗。
  2. 适用范围有限:窗口式记忆不适用于需要完整上下文的任务,例如需要回顾用户早期输入的对话系统。

3.4.2 优化建议

  • 根据任务需求动态调整 k:在不同对话场景中,可以通过配置窗口大小优化性能。
  • 结合其他 Memory 模块:在需要记录长对话的同时,还需要处理短期上下文时,可以将 ConversationBufferWindowMemory 与其他 Memory 结合使用。

四、ConversationTokenBufferMemory:基于 Token 的记忆管理

4.1 基础概念与特点

4.1.1 什么是 Token?

在自然语言处理中,Token 是文本的最小单位,例如一个单词或一个标点符号。在 GPT 模型中,输入和输出的文本内容都被分解为一系列 Token,模型会根据这些 Token 进行计算。因此,Token 数量会直接影响模型的运行成本和响应速度。

4.1.2 什么是 ConversationTokenBufferMemory?

ConversationTokenBufferMemory 是 LangChain 提供的一种基于 Token 数量限制的记忆模块。与 ConversationBufferMemory 和 ConversationBufferWindowMemory 不同,它并不是根据对话轮次来管理记忆,而是根据 Token 的总数动态裁剪较早的对话内容,确保 Token 总数不超过指定的限制。

特点

  • Token 数量控制:通过限制存储的 Token 总数,防止上下文过长导致性能下降。
  • 灵活性高:能够根据需求适配不同的对话场景,无需指定对话条数或窗口大小。
  • 自动裁剪:当 Token 超过限制时,最早的内容会被自动移除。

4.1.3 应用场景

  1. 长对话场景:需要在上下文长度和性能之间找到平衡时。
  2. 资源受限场景:在 Token 使用受到严格限制的应用(如调用 GPT API 时限制 Token 数)。
  3. 复杂问答:对上下文内容有一定依赖,但历史内容并非完全重要。

4.2 使用示例:基于 Token 限制的对话

4.2.1 初始化与配置

要使用 ConversationTokenBufferMemory,首先需要初始化并设置最大 Token 限制(如 50 个 Token)。

# 初始化 ChatOpenAI 客户端
llm = ChatOpenAI(
    openai_api_key=api_key,  # 必须明确设置 api_key
    model_name="gpt-3.5-turbo",  # 使用 gpt-3.5-turbo 模型
)

# 初始化基于 Token 的记忆模块,设置最大 Token 限制为 50
memory = ConversationTokenBufferMemory(llm=llm, max_token_limit=50)

conversation = ConversationChain(
    llm=llm,
    memory=memory,
    verbose=True,
)

4.2.2 示例对话:新闻推荐助手

以下是一个示例场景,用户咨询最近的新闻热点,系统根据用户输入生成推荐。

# 保存对话内容
memory.save_context({"input": "今天有哪些热门新闻?"}, 
                    {"output": "今天的热门新闻包括:经济增长放缓、全球气候峰会以及AI技术的快速发展。"})
memory.save_context({"input": "能详细说说气候峰会的内容吗?"}, 
                    {"output": "全球气候峰会正在讨论碳中和目标和新能源技术推广。"})
memory.save_context({"input": "AI 技术有哪些进展?"}, 
                    {"output": "AI 技术在医疗诊断和自动驾驶领域取得了突破性进展。"})

加载当前对话内容时,可以看到 Token 超过限制后较早的内容被移除:

print(memory.load_memory_variables({}))

输出结果

{'history': '用户:能详细说说气候峰会的内容吗?\n系统:全球气候峰会正在讨论碳中和目标和新能源技术推广。\n用户:AI 技术有哪些进展?\n系统:AI 技术在医疗诊断和自动驾驶领域取得了突破性进展。'}

4.3 注意事项与优化建议

4.3.1 注意事项

  1. Token 计算限制:不同语言的 Token 长度可能不同,在中文场景中,单个汉字通常被视为一个 Token。
  2. 上下文截断问题:如果对话依赖较早的上下文内容,Token 裁剪可能会导致对话逻辑不完整。

4.3.2 优化建议

  • 动态调整 Token 限制:根据对话复杂度和任务需求灵活设置最大 Token 数。
  • 结合 Summary Memory:对于内容较多但仍需保留关键信息的场景,可以结合 ConversationSummaryMemory 使用。

五、ConversationSummaryMemory:对话总结记忆

5.1 基础概念与特点

5.1.1 什么是 ConversationSummaryMemory?

ConversationSummaryMemory 是 LangChain 提供的一种记忆模块,通过对对话内容进行动态总结,浓缩关键信息并存储下来,从而减少存储的内容量,同时保留上下文的核心要点。

特点

  • 浓缩存储:通过总结算法提取对话的核心信息。
  • 长对话支持:适用于需要保留历史内容但无法存储全部细节的场景。
  • 降低存储成本:相比 Buffer 类型的 Memory,可以大幅减少存储数据量。

5.1.2 应用场景

  1. 客户关系管理:总结客户咨询记录,保留关键问题和解决方案。
  2. 会议纪要助手:记录会议核心要点,生成总结报告。
  3. 长期对话:在多轮对话中,需要保留长时间交互的背景信息。

5.2 使用示例:对话总结

5.2.1 初始化与配置

以下代码展示如何初始化 ConversationSummaryMemory 并构建对话链。

from langchain.memory import ConversationSummaryBufferMemory

# 初始化聊天模型
llm = ChatOpenAI(
    openai_api_key=api_key,  # 必须明确设置 api_key
    model_name="gpt-3.5-turbo",  # 使用 gpt-3.5-turbo 模型
)

# 初始化总结记忆模块
memory = ConversationSummaryBufferMemory(llm=llm, max_token_limit=100)

5.2.2 示例场景:会议记录助手

以下是一个示例场景,用户向系统咨询会议内容,并请求生成总结:

# 保存对话内容
schedule = """
今天的会议包括三个主要议题:
1. 团队目标讨论。
2. 产品发布计划。
3. 新增市场策略。
"""
memory.save_context({"input": "请告诉我今天的会议内容"}, 
                    {"output": schedule})
memory.save_context({"input": "能总结一下会议要点吗?"}, 
                    {"output": "会议主要讨论了团队目标、发布计划以及市场策略。"})

加载总结后的记忆:

print(memory.load_memory_variables({}))

输出结果

{'history': '用户:能总结一下会议要点吗?\n系统:会议主要讨论了团队目标、发布计划以及市场策略。'}

5.3 注意事项与优化建议

5.3.1 注意事项

  1. 总结精度:总结内容可能会忽略部分细节,因此不适用于需要完整记录的场景。
  2. Token 限制:总结仍然受到 Token 限制的影响,建议结合其他 Memory 使用。

5.3.2 优化建议

  • 定期更新总结:对于长期对话,可以定期更新总结以确保核心信息的准确性。
  • 结合 Buffer Memory:保留总结的同时,临时存储未总结的详细对话内容。

六、Memory 类型的选择与应用

6.1 各种 Memory 类型的对比

LangChain 提供了四种 Memory 类型,每种类型都有其独特的适用场景和特点。以下是对它们的功能、特点和适用场景的对比分析:

Memory 类型特点适用场景
ConversationBufferMemory保存完整对话历史,无信息丢失。长对话需要完整上下文的场景,例如客服系统或学习助手。
ConversationBufferWindowMemory仅保存最近几轮对话,可通过窗口大小 (k) 控制记忆容量。短期上下文对话,例如查询类任务(天气、物流)或频繁交互的系统。
ConversationTokenBufferMemory基于 Token 数量限制记忆长度,适合处理较长对话时控制计算资源。长对话中需要平衡上下文和性能的场景,例如实时聊天系统。
ConversationSummaryMemory通过总结浓缩对话内容,仅保留核心信息。长期对话或需要记录关键点的场景,例如会议记录、客户管理系统。

6.2 Memory 类型的选择原则

在实际应用中,选择合适的 Memory 类型至关重要。以下是几个核心的选择原则:

6.2.1 根据对话长度选择

  • 短对话:如果对话长度较短,推荐使用 ConversationBufferMemoryConversationBufferWindowMemory,因为它们能简单地保存上下文。
  • 长对话:对于需要管理较长对话的场景,可以使用 ConversationTokenBufferMemoryConversationSummaryMemory

6.2.2 根据资源限制选择

  • 如果计算资源有限(如调用 GPT 的 API 受限于 Token 数),推荐使用 ConversationTokenBufferMemory,通过限制 Token 长度来提升性能。
  • 如果对话存储需要高效管理,同时要保留关键信息,推荐使用 ConversationSummaryMemory

6.2.3 根据上下文需求选择

  • 完整上下文:如果需要保存所有对话内容且对历史没有丢失要求,使用 ConversationBufferMemory
  • 短期上下文:如果仅需要关注最近的交互,使用 ConversationBufferWindowMemory
  • 关键内容浓缩:如果只需记录核心要点,选择 ConversationSummaryMemory

6.3 实际应用案例分析

以下是几个典型应用案例,展示如何选择合适的 Memory 类型:

6.3.1 案例 1:智能客服系统

  • 需求:记录用户的所有咨询历史,以便于后续的分析和上下文参考。
  • 推荐 Memory 类型:ConversationBufferMemory,因为它能完整保存对话内容。

6.3.2 案例 2:物流查询助手

  • 需求:用户可能只关心最近的查询和回复内容,不需要记录整个对话。
  • 推荐 Memory 类型:ConversationBufferWindowMemory,通过限制窗口大小(如最近 3 轮对话)优化存储。

6.3.3 案例 3:任务型对话助手(会议记录)

  • 需求:对长时间的对话内容进行总结,提取出关键点。
  • 推荐 Memory 类型:ConversationSummaryMemory,因为它可以动态总结内容,避免冗余信息存储。

6.3.4 案例 4:实时聊天系统

  • 需求:控制对话上下文的长度,防止超过 Token 限制,同时保持较好的上下文理解能力。
  • 推荐 Memory 类型:ConversationTokenBufferMemory,确保 Token 控制在模型允许范围内。

七、总结

7.1 核心要点回顾

本文详细介绍了 LangChain 中的四种 Memory 类型以及它们的应用场景和使用方法:

  • ConversationBufferMemory:完整记录所有对话,适合需要长期上下文的应用。
  • ConversationBufferWindowMemory:仅保存最近几轮对话,适合短期交互的任务。
  • ConversationTokenBufferMemory:基于 Token 数限制记忆内容,适合长对话和资源受限的场景。
  • ConversationSummaryMemory:通过总结方式存储对话历史,适合需要提取关键信息的场景。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2275251.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

USRP X310 Windows 烧录镜像

说明 USRP-X 系列设备包含两个用于两个以太网通道的 SFP 端口。由于 SFP 端口支持 1 千兆 (SFP) 和 10 千兆 (SFP) 收发器,因此 UHD 附带了多个 FPGA 图像,以确定上述接口的行为。 注意:Aurora 图像需要从 FPGA 源代码手动构建。 FPGA 图像…

新型物联网智能断路器功能参数介绍

安科瑞刘鸿鹏 摘要 智能断路器作为现代配电系统的重要组成部分,以其实时监测、多重保护和远程操控的智能化功能,显著提升了电力系统的运行效率和安全性。本文以ASCB1系列智能断路器为例,探讨其技术特点和在工业、商业及民用建筑中的应用价…

119.使用AI Agent解决问题:Jenkins build Pipeline时,提示npm ERR! errno FETCH_ERROR

目录 1.Jenkins Build时的错误 2.百度文心快码AI智能体帮我解决 提问1:jenkins中如何配置npm的源 提问2:jenkins pipeline 类型为pipeline script from SCM时,如何配置npm源 3.最终解决方法-Jenkinsfile的修改 4.感触 1.Jenkins Build时…

pytest+allure 入门

使用allure如何生成自动化测试报​​​​​​告 ?一文详解allure的使用 。_allure测试报告-CSDN博客 例子: import allure import pytest import osallure.epic("闹钟") allure.feature("闹钟增删") class TestSchedule():def setu…

【FPGA】时序约束与分析

设计约束 设计约束所处环节: 约束输入 分析实现结果 设计优化 设计约束分类: 物理约束:I/O接口约束(例如引脚分配、电平标准设定等物理属性的约束)、布局约束、布线约束以及配置约束 时序约束:设计FP…

【Vim Masterclass 笔记09】S06L22:Vim 核心操作训练之 —— 文本的搜索、查找与替换操作(第一部分)

文章目录 S06L22 Search, Find, and Replace - Part One1 从光标位置起,正向定位到当前行的首个字符 b2 从光标位置起,反向查找某个字符3 重复上一次字符查找操作4 定位到目标字符的前一个字符5 单字符查找与 Vim 命令的组合6 跨行查找某字符串7 Vim 的增…

win32汇编环境,窗口程序中对按钮控件常用操作的示例

;运行效果 ;win32汇编环境,窗口程序中对按钮控件常用操作的示例 ;常用的操作,例如创建按钮控件,使其无效,改变文本,得到文本等。 ;将代码复制进radasm软件里,直接就可以编译运行。重点部分加备注。 ;>&g…

继承(7)

大家好,今天我们继续来学习一下继承的知识,这方面需要大家勤动脑才能理解,那么我们来看。 1.9 protected关键字 在类和对象章节中,为了实现封装特性,java中引入访向限定符,主要限定:类或者类中成员能否在类外和其他包中被访问. …

基于RK3568/RK3588大车360度环视影像主动安全行车辅助系统解决方案,支持ADAS/DMS

产品设计初衷 HS-P2-2D是一款针对大车盲区开发的360度全景影像 安全行车辅助系统,通过车身四周安装的超广角像机,经算法合成全景鸟瞰图,通过鸟瞰图,司机非常清楚的看清楚车辆四周情况,大大降低盲区引发的交通事故。 产…

NVIDIA发布GeForce RTX 50 系列,售价549美元起

2025 CES消费电子展(1月7日至10日,美国拉斯维加斯)正式开幕。北京时间1月7日 (星期二)上午10:30,NVIDIA举办主题演讲,CEO黄仁勋担任主讲。正式发布了全新的RTX 50系列显卡!一月下旬上市。同时公布了各版本的…

后端:Spring(IOC、AOP)

文章目录 1. Spring2. IOC 控制反转2-1. 通过配置文件定义Bean2-1-1. 通过set方法来注入Bean2-1-2. 通过构造方法来注入Bean2-1-3. 自动装配2-1-4. 集合注入2-1-5. 数据源对象管理(第三方Bean)2-1-6. 在xml配置文件中加载properties文件的数据(context命名空间)2-1-7. 加载容器…

基于EasyExcel实现通用版一对一、一对多、多层嵌套结构数据导出并支持自动合并单元格

接口功能 通用 支持一对一数据结构导出 支持一对多数据结构导出 支持多层嵌套数据结构导出 支持单元格自动合并 原文来自:https://blog.csdn.net/qq_40980205/article/details/136564176 新增及修复 基于我自己的使用场景,新增并能修复一下功能&#x…

【数据库】一、数据库系统概述

文章目录 一、数据库系统概述1 基本概念2 现实世界的信息化过程3 数据库系统内部体系结构4 数据库系统外部体系结构5 数据管理方式 一、数据库系统概述 1 基本概念 数据:描述事物的符号记录 数据库(DB):长期存储在计算机内的、…

网络安全建设方案,信息安全风险评估报告,信息安全检测文档(Word原件完整版)

一、概述 1.1工作方法 1.2评估依据 1.3评估范围 1.4评估方法 1.5基本信息 二、资产分析 2.1 信息资产识别概述 2.2 信息资产识别 三、评估说明 3.1无线网络安全检查项目评估 3.2无线网络与系统安全评估 3.3 ip管理与补丁管理 3.4防火墙 四、威胁细…

数据分析工作流

数据分析工作流 1.流程 数据产生阶段 业务系统生成数据:在各种业务场景下,如用户在电商平台上进行购物(产生订单信息、浏览记录等)、在金融系统中进行交易(产生交易流水、账户余额变动等)或者在企业内部的…

【Go】:图片上添加水印的全面指南——从基础到高级特性

前言 在数字内容日益重要的今天,保护版权和标识来源变得关键。为图片添加水印有助于声明所有权、提升品牌认知度,并防止未经授权的使用。本文将介绍如何用Go语言实现图片水印,包括静态图片和带旋转、倾斜效果的文字水印,帮助您有…

PyQt5 UI混合开发,控件的提升

PromoteLabelTest.py 提升的类 import sys from PyQt5.QtWidgets import QApplication, QWidget,QVBoxLayout,QTextEdit,QPushButton,QHBoxLayout,QFileDialog,QLabelclass PromoteLabel(QLabel):def __init__(self,parent None):super().__init__(parent)self.setText("…

CI/CD 流水线

CI/CD 流水线 CI 与 CD 的边界CI 持续集成CD(持续交付/持续部署)自动化流程示例: Jenkins 引入到 CI/CD 流程在本地或服务器上安装 Jenkins。配置 Jenkins 环境流程设计CI 阶段:Jenkins 流水线实现CD 阶段:Jenkins 流水…

ROS核心概念解析:从Node到Master,再到roslaunch的全面指南

Node 在ROS中,最小的进程单元就是节点(node)。一个软件包里可以有多个可执行文件,可执行文件在运行之后就成了一个进程(process),这个进程在ROS中就叫做节点。 从程序角度来说,node就是一个可执行文件&…

深入Android架构(从线程到AIDL)_22 IPC的Proxy-Stub设计模式04

目录 5、 谁来写Proxy及Stub类呢? 如何考虑人的分工 IA接口知识取得的难题 在编程上,有什么技术可以实现这个方法? 范例 5、 谁来写Proxy及Stub类呢? -- 强龙提供AIDL工具,给地头蛇产出Proxy和Stub类 如何考虑人的分工 由框架开发者…