人人都会AI编程

15.4 多轮对话优化

更新时间：2026-07-12

单轮问答模式下，每个问题被视为独立事件，RAG 系统只需根据当前提问检索并生成回答即可。但在真实场景中，用户与助手的交互往往是连续的、有上下文的，例如追问细节、切换话题、纠正前文错误等。多轮对话一旦处理不当，就会出现理解偏差、重复检索无关内容、回答脱离语境等问题，严重影响体验和准确性。

因此，多轮对话优化的核心目标可以概括为两点：准确理解当前轮的真实意图，以及高效且精准地利用历史对话信息。

15.4.1 多轮对话的典型挑战

  • 指代消解与省略：用户说“它的价格是多少？”系统需要知道“它”指上一轮提到的哪个产品。
  • 意图补全：用户在首轮问“怎么退货”，第二轮直接说“那换货呢？”实际上是“退货流程”与“换货流程”的承接。
  • 上下文冲突纠正：用户可能纠正自己之前的说法，例如“不是那款，是最新款”，系统不能死守第一轮的信息。
  • 检索噪音：如果不加处理地把整段历史对话当成一个问题直接进行向量检索，容易引入与当前焦点无关的信息，导致检索效果变差。

15.4.2 优化策略一：对话历史的有选择引入

最直接的方法是每轮都将历史对话文本拼接到当前问题后，再送入检索和生成环节。但全量拼接并非总是最优解，需要根据实际情况“挑选”有用的上下文。

实用做法：

  • 滑动窗口（最近K轮）

只保留最近的几轮对话（如最近3轮），丢弃更早的内容，避免过长历史挤占模型窗口，也减少干扰。

  • 关键轮次筛选

根据意图检测，若发现用户正在进行纯粹的话题切换（例如从“产品价格”直接跳到“公司地址”），可以清空或大幅缩减历史上下文。

  • 历史摘要压缩

对于较长的历史对话，先用一个轻量的 LLM 调用将历史压缩成若干句话的摘要，再作为上下文注入当前处理流程。例如：“用户之前询问了 X200 的退货政策，并询问是否支持上门取件。”

示例（拼接方式）：

当前问题：它的续航大概多少？
历史上下文：
- 用户：我想看一下 X200 笔记本的参数。
- 助手：X200 配备 14 英寸屏幕，重量 1.2kg，提供 16GB 内存和 512GB 存储。
→ 最终检索问题：用户询问：“它的续航大概多少？”（上文指 X200 笔记本）。

15.4.3 优化策略二：多轮改写（Query Rewriting）

将用户的“原始提问”结合历史对话改写成一个完整、独立的问题，再拿去检索。这一步骤通常由一个专门用于改写的 LLM 处理。

改写提示词示例：

根据以下对话历史，将用户的当前问题改写成不需要依赖上下文就能理解的独立问题。

对话历史：
用户：你们支持哪些配送方式？
助手：我们提供顺丰、圆通和中通三种快递。

当前问题：那最快的是哪种？

请输出改写后的问题：

改写结果示例：“你们支持的配送方式中，最快的是哪一种？”

改写后的句子去除了指代，直接包含了关键实体和约束，大大提高了检索的命中率。这种方法实现成本低、效果显著，是目前多轮检索优化中使用最广泛的手段之一。

15.4.4 优化策略三：分离“检索上下文”与“生成上下文”

很多时候，适合用来检索的历史片段和适合交给模型生成回答的历史片段并不完全一致。检索更讲究精准、精简，避免无关信息；而生成则需要足够的对话背景让回答自然、连贯。

推荐做法：

  • 检索上下文：使用改写后的独立问题，或者仅注入最近 1-2 轮的核心实体（如产品名、意图关键词），携带少量已确认的约束条件。
  • 生成上下文：保留完整的历史对话（或压缩后的摘要）以及本轮检索到的知识片段，保证模型能生成符合对话氛围的回复。

这种分离可以有效防止检索阶段被“闲聊”或“历史确认信息”带偏，同时最终回答依然保持多轮对话的连续性。

15.4.5 优化策略四：对话状态管理（适合复杂任务）

对于需要多步操作的对话（如预约、下单、信息收集），单纯靠上下文拼接不足以可靠完成任务。这时需要引入轻量的对话状态跟踪。

简化实现： 维护一个 JSON 对象存储当前轮次已获取的槽位信息。

对话状态：
{
  "intent": "product_inquiry",
  "product": "X200",
  "concern": "battery_life"
}

每轮交互时，将状态与历史摘要一同传给检索或改写模块，确保即使在用户跳转话题后又回来时，系统仍能找回之前的上下文事实。

15.4.6 优化策略五：提示词中的多轮意识

在最终生成环节的提示词中明确指示模型如何使用历史上下文，可以有效减少生成偏离。

示例提示词片段：

你是一个客服助手，请结合对话历史和提供的资料回答用户问题。
如果用户的问题存在指代不明，请优先根据对话历史补全含义。
如果需要澄清，可以反问用户，但不要编造资料中没有的信息。

并在每次调用时附带格式化后的历史对话，如：

对话历史：
用户：最近有什么新款手机？
助手：我们有 A100 和 B200 两款新机型。
用户：那个带长焦的多少钱？
（此时你的回答应理解“那个”指代有长焦功能的机型）

15.4.7 真实场景中的效果评估

多轮优化的实际有效性需要持续监控，几个务实的观测点：

  • 意图识别的准确率：改写后的完整问题是否准确反映了用户真实意图。
  • 检索相关性：在多轮场景下，检索返回的片段与当前需要的知识是否依然紧密相关。
  • 指代消解失败率：统计助手回答中出现“您指的是哪一款？”这类澄清语的频率，过高说明历史利用不足。

实践建议：

  • 多轮改写不一定要用大模型，小模型或规则（带指代消解的简单模板）也能解决大部分问题，成本更低。
  • 在初期甚至可以只依赖“最近3轮对话全量拼接+要求模型补全指代”的简单策略，快速上线，再根据困难案例逐步优化。
  • 如果系统同时面向多个业务领域，可以考虑为每个领域维护独立的对话历史，避免交叉干扰。

通过上述方法的组合使用，多轮对话的连贯性和知识检索精准度可以得到明显提升，让 RAG 系统从简单的“一问一答”升级为更贴近真实交互需求的智能助手。