在 RAG 系统的实际使用中，多轮对话是提升交互自然度的必备能力。用户往往不会一次性把需求说清，而是通过追问、澄清、切换角度来逐步深入。然而，一旦进入多轮对话模式，系统很容易暴露出 上下文丢失 和 前后矛盾 这两类问题，严重影响用户体验和答案可信度。
26.4.1 问题的表现与根源
上下文丢失
用户在前一轮刚说清楚的条件或对象，到下一轮就被系统“忘记”了。例如：
- 用户：“请介绍一下我们公司的 A 产品。”
助手：（查询知识库后详细介绍了 A 产品）
- 用户：“它的保修期是多久？”
助手直接回答通用保修条款，没有意识到“它”指代的是 A 产品，而是泛泛而谈。
这种丢失通常发生在 系统没有将历史对话信息有效传递给检索模块 的环节。如果检索时只用了用户当前这句话（“它的保修期是多久”），向量搜索自然找不到与“它”对应的 A 产品相关信息，后续生成自然也就脱离了前文语境。
前后矛盾
在同一轮对话中，不同步骤的回答逻辑不一致，或者后面的回答直接否定了前面的观点，却又给不出合理解释。例如：
- 用户：“退货需要哪些条件？”
助手：“需要商品完好且购买 7 天以内。”
- 用户：“那如果超过了 7 天呢？”
助手：“根据政策，超过 7 天的一概不能退。”
- 用户：“可我上次咨询，说超过 7 天质量问题可以退的。”
助手又改口：“是的，质量问题可以延长到 15 天。”
这种矛盾背后，往往是检索模块在不同轮次中召回了不同版本或不同上下文中的片段，而生成模型没有在全局层面进行逻辑一致性检查，只是机械地按当前检索结果作答。
26.4.2 原因分析
多轮对话中出现混乱，技术根因主要集中在这几方面：
- 检索时未融合历史关键信息。只把当前用户输入（可能只是一个“它”“那个”“上次提到的”）送入检索，导致检索结果与之前轮次的信息脱节。
- 对话状态管理缺失。没有明确记录用户意图、实体（产品名、查询类别）、偏好等关键变量，使得系统无法在上下文中连贯推断。
- 提示词中没有足够的历史摘要。如果把所有历史原文不加处理地塞入窗口，容易超出 token 限制；但如果完全丢弃，模型自然无法保持记忆。简单截断或粗暴摘要又可能遗漏关键约束。
- 知识库本身存在冲突或陈旧内容。不同文档对同一问题给出了不同说法时，检索排名的不确定性会导致不同轮次返回的片段不同，进而生成互相矛盾的答案。
26.4.3 实用解决方案
针对多轮对话混乱，可以按以下思路逐步优化：
1. 显式管理对话状态
在多轮对话中引入一个轻量级的状态维护层，用简单的变量记录当前会话的实体、意图和约束。例如：
current_product = "A产品"current_intent = "询问保修"last_mentioned_conditions = ["7天内", "质量问题"]
这些状态可以由另一个轻量级 LLM 在每轮对话后提取并更新，然后在下一轮检索前，将状态中的关键实体拼接到提问中，形成更具信息量的检索查询，如：“A 产品的保修期及政策”。这样检索出的片段就与对话历史一致了。
2. 对历史进行压缩摘要后注入上下文
为了避免窗口溢出，同时保留上下文连续性，可以在每轮对话时做两步处理：
- 保留最近 2～3 轮的完整对话原文（含用户问题和系统回答），确保近期指代可以被正确解析；
- 对更之前的对话，生成一段简短的“对话要点摘要”（如“用户在咨询A产品的保修和退换货条款，已知A产品标准保修1年，用户对超过7天退货有疑问”）。
将这段摘要连同最近几轮原文一起注入提示词，使模型既了解全局背景，又有细粒度上下文。
3. 对核心问题强制加入历史约束
在生成答案的提示词中，添加明确的指令：“如果当前问题指向代指词（如‘它’、‘这个’），请根据对话历史推断具体所指，并在回答中明确指出，如‘根据您刚才提到的 A 产品……’”。这样即使检索结果没有精准命中，模型也会倾向于在回答中衔接前文，减少断裂感。
4. 统一检索查询的重写策略
一个效果很好的做法是：在每次检索前，让模型先根据对话历史改写用户当前问题。例如：
- 原始问题：“那这个版本支持吗？”
- 改写后：“我们公司使用的 CRM 系统 V3.2 版本是否支持与企业微信的数据同步？”
再利用重写后的清晰查询去做检索，能够有效解决指代和省略带来的信息缺损。这个改写步骤本身也可以由 LLM 完成，延迟和成本都很低。
5. 知识库侧的版本管理和去冲突
如果连续几轮回答出现矛盾，需要检查知识库本身是否包含矛盾内容。必要时：
- 引入文档级别的时效标记，让检索优先命中最新版本；
- 对于检测到相互矛盾的两个片段，生成模型可以主动提示用户：“关于这一点，文档中存在两个不同版本的说法，请参考……” 或直接由管理员预先标注权威来源。
26.4.4 真实场景示例
某企业 IT 服务台机器人，经常遇到员工连续追问某个系统问题的操作步骤。
- 优化前：员工先问“邮箱无法发送大附件怎么办”，随后追问“那这个和网络有关系吗？”。机器人对第二个问题直接检索“网络和大附件的关系”，返回与网络配置通用知识，丢失了“邮箱”这个关键实体，导致回答跑题。
- 优化后：系统在每次用户提问时，自动用对话历史改写查询。第二个问题被改写为“企业邮箱无法发送大附件是否与网络配置有关”，再检索企业邮箱的故障排查文档，回答精准且与前文连贯。
26.4.5 注意事项与权衡
- 对话状态和改写都会增加少量延迟和 token 消耗，但对用户体验的提升往往物有所值。可根据业务场景选择轻量级方案。
- 极长的多轮对话，仍建议每隔几轮触发一次主动澄清或小结，避免历史积累过大。
- 最终答案中主动重复关键实体名称（如“根据您提到的 A 产品…”）可以进一步巩固用户对连贯性的感知，即使背后检索偶尔不够理想，也能给出一种“我记着上下文”的安全感。
通过上述实用手段，RAG 系统可以在多轮对话中维持上下文的一致性和连贯性，有效减少混乱与矛盾，使交互体验逼近真人对话的流畅水平。