在多轮对话中，用户的问题往往不是孤立的。“那上个月的政策呢？”“你能再详细解释一下吗？”——这些追问都依赖之前的对话上下文。如果系统把每一轮都当作全新问题处理，回答就会生硬、不连贯，甚至答非所问。会话记忆管理的目的，就是让系统“记住”之前说过什么，从而给出连贯、自然的回复。
为什么需要会话记忆
- 理解指代与省略：用户说“它支持哪些型号？”中的“它”，需要回溯上文提到的产品名。
- 追问与深化：用户可能先问“怎么开通”，再问“费用怎么算”，系统需要记住前一问的主题。
- 避免重复提问：高效对话中，用户期望系统记得已确认过的上下文，而不是反复要求澄清。
核心实现方式
在 RAG 系统中，会话记忆通常通过管理对话历史来实现。具体做法是：在每一轮调用 LLM 时，除了当前问题和检索到的知识片段，还要把之前几轮的对话记录（用户问题 + 助手回答）一并拼接到提示词中。这样模型就能“看到”完整的对话脉络。
基本流程
- 用户输入当前问题。
- 系统从存储中取出本次会话的历史记录（例如最近 N 轮对话）。
- 拼接提示词模板：
系统指令 + 历史对话 + 当前问题 + 检索到的知识。 - 发送给 LLM 生成回答。
- 将当前轮次的问题和回答追加到历史记录中，以备下一轮使用。
简单而有效的管理策略
- 滑动窗口：只保留最近 K 轮对话（如 3~5 轮），既保留足够上下文，又避免提示词过长导致成本上升、响应变慢。对于大部分业务场景，这是性价比最高的选择。
- 摘要压缩：当对话很长时，可以定期调用 LLM 对较早的历史进行摘要，用“对话要点”代替原始记录，减少长度损耗。
- 关键信息提取：在对话过程中主动提取并持久化关键实体（如用户姓名、工号、订单号），即使历史轮次滑出窗口，这些结构化信息仍可作为上下文注入。
- 重置与分支：提供手动“新对话”按钮，清除历史；或在检测到话题完全切换时自动清空历史，避免旧上下文干扰。
需要留意的现实问题
- Token 消耗：每次请求都携带历史记录，会增加每次调用的输入 token 数，直接提升成本。采用滑动窗口或摘要策略可有效控制。
- 检索仍以当前问题为主：历史记录主要帮助模型理解意图和指代，检索步骤通常仍只使用当前轮次的问题（或结合最近一轮），避免用冗长的历史去向量搜索导致噪声。
- 知识更新与记忆冲突：如果知识库内容已更新，而历史记录中助手曾引用过旧信息，可能导致前后矛盾。可以在提示词中增加提示，要求模型以最新检索结果为准，或在检测到冲突时主动修正。
实际示例
用户：“我想了解年假政策。”
助手：【根据最新《员工手册》】“您每年享有 10 天带薪年假，具体申请流程可查看第 5 章。”
用户：“如果没休完会怎样？”
此时系统将上一轮问答作为历史放入提示词，模型理解“没休完”指年假，检索“未休年假处理”相关条款后回答：“根据手册第 5.3 条，未休完的年假可延期至次年 3 月底，逾期视为放弃。”
工程落地建议
- 将会话记录存储在 Redis 等高速缓存中，以会话 ID 为键，设置过期时间（如 30 分钟），实现自动清理。
- 设计提示词时，将历史对话用清晰的角色标记区分（
用户：...、助手：...），帮助模型理解。 - 对于敏感信息，注意不在日志或存储中明文记录，必要时进行脱敏。
会话记忆管理听起来简单，但做得好与坏直接决定用户体验的流畅程度。通过有策略地保留和剪裁上下文，而不是无脑塞入全部历史，可以在成本、响应速度和对话连贯性之间取得良好的平衡。