人人都会AI编程

9.4 多轮对话 RAG

更新时间：2026-07-12

前面章节讨论的 RAG 系统大多基于单轮问答：用户提问，系统检索后生成回答，一问一答即结束。但在实际应用中，用户常常会连续追问、澄清意图或逐步细化需求，这就涉及多轮对话的场景。如果只是简单地把每一轮当作独立问题处理，系统很容易丢失上下文，导致回答脱节或反复询问已知信息。

多轮对话 RAG 的目标，就是在保持 RAG 优势（事实准确性、可溯源）的同时，让系统具备对话记忆与上下文理解能力，实现自然、连贯的交互。

9.4.1 多轮场景下的核心挑战

将 RAG 从单轮扩展到多轮，会引入几个典型难题：

  • 意图漂移：用户在后续轮次可能不再重复主题关键词，例如第一轮问“年假多少天”，第二轮只问“那如果没休完呢？”。如果没有上下文，系统无法知道“那”指的是年假。
  • 检索失焦：直接用当前轮次的文字去检索，可能会漏掉前几轮建立的语境，导致检索到的片段与当前话题无关。
  • 信息拼接混乱：多轮对话需要在不丢失历史信息的前提下，将新的检索结果与之前的回答自然融合，考验提示词设计能力。
  • 对话状态管理：需要记录已澄清的信息（比如用户身份、所属部门、特定产品型号），并在后续检索和回答中复用。

9.4.2 多轮对话 RAG 的通用架构

实现多轮对话 RAG，通常是在标准 RAG 流水线上添加对话历史管理模块，并对检索和生成环节做相应扩展。

典型流程如下：

  1. 接收用户当前输入，同时读取对话历史记录（通常保留最近 N 轮对话，或基于摘要的历史）。
  2. 改写或扩展查询（Query Rewriting）：根据对话历史，将用户本轮省略式或指代不明的语句补全为独立、完整的查询。例如：“那如果没休完呢？” → “如果年假没休完，怎么处理？”
  3. 用改写后的查询进行检索，从知识库获取相关片段。
  4. 将历史对话、当前问题、检索结果一起填入提示模板，明确要求模型基于资料回答问题，并注意与前文保持连贯。
  5. 生成回答，同时更新对话历史，供下一轮使用。

9.4.3 关键实现要点

对话历史的组织方式

  • 窗口记忆：保留最近 K 轮对话全文，简单直接，但轮次过多时 token 消耗大，容易超出模型上下文限制。
  • 摘要记忆：对较早的对话片段用模型自动总结，只保留摘要，节省上下文空间。可以在每轮结束后触发一次轻量摘要更新。
  • 状态记忆：提取关键槽位（如用户意图、实体参数），结构化存储，在后续检索和回答时注入。

查询改写（Query Rewriting）

查询改写是多轮 RAG 中最关键的步骤之一。可以直接用一个轻量级的小模型或主模型本身的“补全”能力，根据历史对话生成一个独立理解的查询。一个实用的提示词示例如下：

基于以下对话历史，将用户的最新消息改写为一个完整的、无需上下文即可理解的检索查询。
对话历史：
用户：年假有几天？
助手：根据员工手册，您每年享有15天年假。
用户：那如果没休完呢？
改写后的查询：如果年假未休完，如何处理？

改写后，检索模块就能准确命中“未休年假处理规则”的相关文档，而不是被“那”这样的代词卡住。

提示词模板设计

将检索结果与对话历史一同传入时，需要清晰划分不同信息区域，防止模型混淆。一种典型的模板结构：

你是一个基于知识库回答问题的助手。请严格根据下面的资料回答问题，如果资料中没有相关信息，请明确说明。
【对话历史】
用户：……
助手：……
【已知用户信息】{部门：技术部，职级：P6}
【本轮问题】{改写后的问题}
【相关资料】
1. （来源：员工手册，第3节）内容……
2. （来源：福利政策2025版，第2条）内容……
【回答要求】
- 使用自然、连贯的口语
- 如果与历史对话相关，注意衔接
- 答案末尾注明信息来源

这样，模型在生成时会兼顾：资料准确性、对话连贯性、以及已知的上下文字段。

9.4.4 一个真实对话示例

以下是一个企业内部 HR 助手的多轮对话片段，展示了多轮 RAG 的实际表现。

第一轮

用户：我今年的年假有多少天？
助手：根据《员工手册》第5章，您每年享有18天年假。具体天数可能根据入职年限调整，如需确认请提供您的工号。

第二轮

用户：那没休完怎么办？
（系统内部进行查询改写，生成：“年假未休完如何处理？”）
助手：未休的年假可在次年3月底前申请延期，逾期将按250%折算为薪资。详见《福利政策2025版》第2.3条。

第三轮

用户：我刚用了3天，还剩多少？
（系统结合历史信息推断用户仍有15天未用，改写查询：“年假剩余天数计算方法”，检索得到通用说明，同时结合“18天”进行数值计算）
助手：您今年的总年假为18天，使用3天后剩余15天。请注意，未休假天数根据政策可结转或折算，建议您提前规划。

9.4.5 注意事项

  • 检索质量依赖改写：如果改写不到位，检索结果就会跑偏。建议在改写环节保留备选方案，例如同时用原始问题和改写问题各检索一次，合并去重。
  • 对话轮次控制：不要无限制堆积历史消息，一般保留最近 5~10 轮或最近 2000 token 的历史，超出部分以摘要形式留存。
  • 避免信息泄露：在多用户场景下，务必隔离不同会话的对话历史，防止通过对话记录串用指向其他用户的私有信息。
  • 时效性与对话状态：用户可能在对话中提及的实体（如“最新的政策”）随时间变化，注意在检索时将时间相关性纳入考虑。

多轮对话 RAG 并不是对基础 RAG 的颠覆，而是在其上的自然延伸。做好查询改写与对话状态管理，就能在不牺牲事实准确性的前提下，为用户提供真正流畅的咨询体验。对于大多数企业知识助手、客服机器人场景，多轮对话能力往往是衡量系统“好用”还是“能用”的分水岭。