聊天记录是用户与聊天模型之间对话的记录。它用于在整个对话过程中保持上下文和状态。聊天记录是一系列消息，每条消息都与特定角色相关联，例如“user”、“assistant”、“system”或“tool”。

大多数对话都以设置对话上下文的系统消息开始。接下来是包含用户输入的用户消息，然后是包含模型响应的助手消息。

助手（assistant）可以直接响应用户，或者如果配置了工具请求，则调用工具来执行特定任务。

因此，完整的对话通常涉及两种交替消息模式的组合：

1. 用户和助手代表来回对话。

2. 助手和工具消息表示的 agent 工作流，其中助手正在调用工具来执行特定任务。

由于聊天模型对输入大小有最大限制，因此管理聊天记录并根据需要对其进行修剪以避免超出上下文窗口非常重要。

在处理聊天记录时，保留正确的对话结构至关重要。管理聊天记录的关键准则：

• 对话应遵循以下结构之一：

• 第一则消息是“user”消息或“system”消息，后跟“user”消息，然后是“assistant”消息。

• 最后一条消息应该是“user”消息或包含工具调用结果的“tool”消息。

• 使用工具调用时，“tool”消息应仅跟在请求工具调用的“assistant”消息之后。

理解正确的对话结构对于在聊天模型中正确实现记忆至关重要。

可以参考《使用 LangChain 构建一个有记忆的聊天机器人》

我们首先将《使用LangChain建立检索增强生成（RAG）系统》的关键代码抽取出来：

我略过了加载文档、拆分文档和生成索引的步骤，因为这和本文关系不大。

我们构建的 RAG 链直接使用输入查询来检索相关上下文。但在对话设置中，用户查询可能需要对话上下文才能被理解。例如，考虑以下的会话：

用户：“物理学对马斯克有什么影响？”

AI：“物理学为马斯克提供了一个理解复杂和反直觉事物的研究框架，比如量子力学。它教会他使用第一性原理思考问题，这是一种将事物分解到最基本实质再进行推理的方法，对探索未知领域非常重要。这种方法帮助他在创新时能追溯问题的本质，从而产生独创性的解决方案。”

用户：“马斯克对这个学科有什么看法？”

为了回答第二个问题，我们的系统需要理解“这个学科”指的是“物理学”。

针对这个问题，我们需要更新现有的 RAG 链：

1. 提示模板：更新我们的提示模板以支持历史消息作为输入。

2. 上下文问题：添加一个子链，该子链接受最新的用户问题并在聊天历史的上下文中重新表述它。这可以简单地被认为是构建一个新的“历史感知”检索器（retriever）。而之前我们有：

• 查询 -> 检索器

    现在我们将有：

• （查询，对话历史）-> LLM -> 重新表述的查询 -> 检索器

首先，我们需要定义一个子链，该子链接收历史消息和最新的用户问题，如果问题引用了历史信息中的任何信息，则重新表述该问题。

我们将使用一个包含名为“chat_history”的 MessagesPlaceholder 变量的提示。这允许我们使用“chat_history”输入键将消息列表传递给提示模板，这些消息将插入在系统消息之后和包含最新问题的人工消息之前。

请注意，我们利用辅助函数 create_history_aware_retriever 来完成此步骤，该函数管理 chat_history 为空的情况，否则按顺序应用 prompt | llm | StrOutputParser() | retriever。

create_history_aware_retriever 构造一个链，该链接受键 input 和 chat_history 作为输入，并具有与检索器相同的输出模式。

该链将输入查询的改写添加到我们的检索器中，以便检索包含对话的上下文。

现在我们可以构建完整的 QA 链。我们将使用 create_stuff_documents_chain 生成 question_answer_chain，输入键为 context、chat_history 和 input——它接受检索到的上下文以及对话历史记录和查询以生成答案。更详细的解释在这里

我们使用 create_retrieval_chain 构建最终的 rag_chain。此链按顺序应用 history_aware_retriever 和 question_answer_chain，保留中间输出（例如检索到的上下文）以方便使用。它具有输入键 input 和 chat_history，并在其输出中包含 input、chat_history、context 和 answer。

我们来试验一下：

因为我们的链包含“chat_history”输入，所以调用者需要管理聊天记录。我们可以通过将输入和输出消息附加到列表中来实现这一点。

但是在生产中，问答应用程序通常会将聊天历史记录保存到数据库中，并能够适当地读取和更新它。

LangGraph 实现了内置的持久层，使其成为支持多轮对话的聊天应用程序的理想选择。所以现在将我们的聊天模型包装在最小的 LangGraph 应用程序中，使我们能够自动保存消息历史记录，从而简化多轮应用程序的开发。

你可以参考《使用 LangChain 构建一个有记忆的聊天机器人》。

核心逻辑如下：

此应用程序开箱即用地支持多个对话线程。我们传入一个配置字典，为线程指定唯一标识符，以控制运行哪个线程。这使应用程序能够支持与多个用户的交互。

可以通过应用程序的状态检查对话历史记录：

以下就是我们这个会话式 RAG 系统的架构图了：

Agent 利用 LLM 的推理能力在执行过程中做出决策。使用 Agent 可以让你在检索过程中减轻一些判断力。尽管它们的行为比链更难预测，但它们在这种情况下具有一些优势：

• Agent 直接生成检索器的输入，而不一定需要我们明确构建上下文，就像我们上面所做的那样；

• Agent 可以执行多个检索步骤来处理查询，或者完全不执行检索步骤（例如，响应用户的一般问候）。

Agent 可以访问工具并管理其执行。在本例中，我们将把检索器转换为 LangChain 工具，供 Agent 使用：

现在我们已经定义了工具和 LLM，我们可以创建 Agent 了。我们将使用 LangGraph 来构建 Agent。目前，我们使用高级接口来构建 Agent，但 LangGraph 的优点在于，如果你想要修改代理逻辑，这个高级接口由低级、高度可控的 API 支持。

注意，我加入了内存检查点来存储历史记录。

这就是我们构建对话式 RAG Agent 所需的全部内容。

让我们观察一下它的行为。请注意，如果我们输入不需要检索步骤的查询，Agent 就不会执行该步骤：

此外，如果我们输入确实需要检索步骤的查询，Agent 将生成工具的输入：

上面的输出很长，我的图只截取了其中一部分。

上图中，Agent 没有将我们的查询逐字逐句地插入到工具中，而是删除了“什么”等不必要的单词。

同样的原则允许 Agent 在必要时使用对话的上下文：

请注意，Agent 能够推断出我们查询中的“他”指的是“马斯克”，并生成了一个合理的搜索查询：在本例中为“马斯克 对 物理学 的 看法”。