论文

你改变了主意,模型没有:揭开多轮对话中的意图之谜

你改变了主意,模型没有:揭开多轮对话中的意图之谜

当大语言模型处理多轮任务、用户提出修改但最终否决时,模型本应视作什么都没发生、继续执行原任务。我们却发现一个令人意外的失败模式:仅仅提及被否决的修改 就能让任务执行偏离正轨,即使用户的最终意图并未改变。 为系统研究用户意图演变下的语言模型行为,我们提出 Intent-Eval,一个受控基准,覆盖工具调用、代码、数据库与数学任务。在多样任务上,模型对 被否决的提议 与 被取代的需求 都很脆弱,符合 mentioned-as-in-effect 混淆:对话内容即使已被否决或替换,仍被当作生效中的需求。准确率下降可能随交互持续而加深或长期存在,凸显区分「已提及」与「仍生效」的必要性。 基于这一洞察,我们提出 Intent-OPSD,一个决策条件下的 on-policy 自蒸馏框架,Teacher 与 Student 由同一模型初始化。冻结的 Teacher 依据与用户决策一致的完整任务提供 活跃意图监督,并在完整对话上训练 Student,使其遵循反映用户意图的活跃需求。

论文精读

TL;DR 发现 LLM 在多轮对话中会混淆被拒绝的提案为有效需求,提出 Intent-Eval 基准与 Intent-OPSD 自蒸馏框架来分离提及内容与有效意图。

问题

问题背景:多轮对话已成为 LLM 应用于 Agent、工具调用、代码编辑等交互式场景的核心。当前研究聚焦指令遵循与对话状态追踪,但用户意图在对话中动态演化(提出修改、撤销、替换)的建模仍不充分。

现有方法局限:主流的监督微调(SFT)与偏好对齐(如 RLHF)默认训练对话中的每条用户消息均为应遵循的指令,缺少对 "已拒绝提议" 或 "已被替代需求" 的显式建模。模型易出现 mentioned-as-in-effect confusion(提及即生效混淆),即把对话历史中所有出现过的内容都视作活跃要求,即使后续已否定或覆盖。现有对话基准多评估静态意图,未系统构造意图变更场景,无法暴露该缺陷。

为什么难/重要:真实用户会试探性提议、反悔、澄清,模型必须持续区分 "提及过什么" 与 "当前生效什么"。若无法跟踪活跃意图,错误会在多轮交互中累积或持久,导致任务执行偏离原始目标,影响长程任务可靠性。这对企业级 Agent、IDE 编程助手、数据库查询等高风险场景尤为关键。

行业类比:类似客服机器人中用户先说 "用信用卡支付",然后说 "还是用 PayPal",最后说 "算了先不付"——系统必须只记住 "先不付",而不被信用卡或 PayPal 干扰。

核心洞察

  • 本文揭示了大模型在多轮对话中的 mentioned-as-in-effect 混淆:即使用户最终意图未变,仅仅提及一个被拒绝的提议或已被替代的需求,模型也会将其当作活跃要求执行,导致任务失败。这个角度独特在于,它超越了传统指令遵循或对话状态追踪研究,聚焦于意图随对话演化时的动态有效性判定,并构建了 Intent-Eval 可控基准进行系统化量化,而非依赖零散案例。
  • Intent-OPSD 提出决策条件在线自蒸馏框架,用冻结的教师模型提供与用户最终决策一致的完整任务监督,训练学生模型从完整多轮对话中学习跟随活跃意图。其独特之处在于利用同一模型初始化教师与学生,通过自蒸馏注入对话状态中的意图区分能力,相比常规 SFT 仅拟合最终答案或忽略中间驳回内容,能更直接地纠正 mentioned-as-in-effect 偏差,并在多轮交互扩展中保持稳定。

方法

输入

多轮对话历史(包含用户提及但最终拒绝或替换的变更请求)以及用户最终决策(接受/拒绝/修订)。

关键模块

  1. 决策条件参考构建:根据用户决策,从任务空间中选择或构造与用户最终意图一致的 active-task reference(如正确的工具调用序列、代码、数据库查询或数学推导结果)。该 reference 是学生模型应学习的“生效需求”的完整示范。
  2. Teacher-Student 自蒸馏:Teacher 与 Student 初始化为同一模型。Teacher 冻结,仅在 reference 上执行前向,生成 token 级 logits 或中间状态作为监督信号;Student 在完整原始对话(含干扰内容)上进行前向,通过蒸馏损失对齐 Teacher 的输出分布,使 Student 学会忽略已失效的提及内容。
  3. On-policy 训练:Student 的生成采用自身采样结果(on-policy)而非仅依赖 ground-truth token,以缓解对话中由历史提及导致的分布偏移。

输出

训练后的 Student 模型,在多轮交互中能稳定跟随当前生效的需求,即使对话中出现被拒绝的提议或已被取代的旧要求,也不会干扰任务执行。

与常规指令微调或上下文学习不同,Intent-OPSD 显式利用用户决策构造参考,并通过自蒸馏让模型区分“被提及”与“仍生效”,而非简单模仿对话最终结果。

实验

实验设计

论文构建 Intent-Eval 基准,覆盖 tool actions、code、database、math 四类任务,通过多轮对话模拟用户意图动态变化。核心条件包括:(1) Retained——用户提出变更但最终拒绝,最终意图不变;(2) Revised——用户提出替代要求,最终意图被替换。另设单轮控制组和交互扩展协议(accumulation、persistence),考察干扰随对话深度是否累积或持续。

关键发现

模型普遍表现出 mentioned-as-in-effect confusion:对话中被拒绝或已替换的提议仍被当作生效中的需求,导致任务准确率显著下降。即使用户最终意图保持不变,仅“提及” rejected change 就可能使模型偏离任务执行。准确率下降随交互轮次加深而扩大或难以恢复,说明模型缺乏对 active intent(当前生效意图)与历史提及内容的显式区分能力。

对比与解读

与标准的监督微调(SFT)相比,直接训练学生会强化对完整对话中失效内容的错误关注。Intent-OPSD 引入 decision-conditioned on-policy self-distillation:冻结 Teacher 根据用户实际决策从完整任务中生成活性意图监督,Student 则在完整对话上学习忽略已被否决或替换的内容。这一设计将训练目标从“拟合所有出现过的文本”转向“遵循与用户决策一致的有效需求”,更贴合真实交互中意图演化的状态跟踪需求。

项目主页 提供了更多示例与条件渲染细节。

行业影响

落地场景

Intent-Eval 与 Intent-OPSD 直接面向所有需要长时多轮交互的 AI 产品,尤其是任务执行型助手:

  • 电商客服:用户先说“修改收货地址为 B”,随后又说“算了,还是用原来的 A”。模型若混淆“提及”与“生效”,可能误改订单地址,造成物流事故。
  • 代码助手 / IDE 插件:用户要求“把排序改成降序”,下一轮又说“不用了,保持升序”。模型若继续生成降序代码,会破坏代码库。
  • 企业 RPA / 内部工具:多轮需求确认中,用户可能试探性提出变更后又收回,自动化流程需严格跟随最终意图。

商业价值

  • 降本:减少因意图漂移导致的错误执行,降低人工复核与修复成本。
  • 体验提升:用户能更自然地进行多轮试探,模型不会把“提过但已拒绝”的要求当真,显著降低交互挫败感。
  • 增收/转化:在销售或配置类对话中,准确跟踪最终意图可避免错误下单或错误配置,减少流失。

与现有工作流集成

Intent-Eval 可作为对话模型的回归评测集,嵌入 CI/CD 流程,量化模型对“被拒绝提议”的抗干扰能力。Intent-OPSD 采用 decision-conditioned on-policy self-distillation,用同一个模型初始化 Teacher 和 Student,无需额外人工标注即可进行意图校准微调;可附加在现有 SFT 或 RLHF 阶段之后,配合当前 agent 框架的意图状态管理模块,直接替换或增强对话策略。

局限

  • **基准的合成性与领域覆盖有限**:Intent-Eval 虽覆盖工具调用、代码、数据库、数学等多个领域,但任务均为受控构建的合成数据,且以英文为主,缺少真实开放域多轮对话中的复杂语境(如隐式意图、情绪、指代消解等)。模型在真实用户交互中的表现可能与该基准有差异,泛化性尚需验证。
  • **Intent-OPSD 依赖高质量教师模型**:该方法利用冻结的教师模型根据完整任务和用户决策提供主动意图监督,要求教师本身具备较强的意图理解能力。若教师模型在长程多轮任务中也存在偏差,学生可能继承错误。此外,训练需要完整对话与决策信息,真实场景中可能难以获取或标注成本较高。
  • **评估模型范围与工程落地考量不足**:论文仅在若干开源模型上评测,未覆盖所有主流商业模型,且未讨论推理延迟与计算开销。Intent-OPSD 虽提升准确率,但在线蒸馏部署可能增加额外复杂度;同时未与基于提示工程或上下文压缩的轻量方案进行系统对比,实际工程落地需权衡。
论文Junle Chen2026-10-05原文

相关内容