这道题我会先把目标拆开:多轮对话要解决三件事,先说记得住,能保留前文关键信息;接着说用得对,能在当前轮找到真正相关的历史;再补充前后一致,不要和自己之前确认过的事实、角色或约束冲突。
架构上,单纯拉长上下文窗口有帮助,但不是唯一方案。长上下文可以用稀疏注意力、[[滑动窗口]]注意力、分层编码这些方式降低计算成本,让模型能看更长历史。但对非常长的会话,只靠窗口硬塞不现实,所以我会加显式记忆模块。
显式记忆可以分短期和长期。短期记忆保留最近几轮完整对话,因为最近内容对当前回复最重要;长期记忆保存用户偏好、已确认事实、任务状态、历史摘要和关键实体。每轮结束后,系统抽取高价值信息写入记忆库,推理时再根据当前 query 检索相关记忆拼回上下文。这里要注意,记忆不是越多越好,要有时效、来源和置信度。
训练策略上,我会做多阶段。预训练或继续预训练阶段,让模型适应长文本和长对话结构;[[SFT]] 阶段用高质量多轮对话,让模型学会指代消解、状态跟踪、承接前文和遵守系统角色;偏好优化阶段,用多轮偏好数据训练模型更偏好一致、简洁、符合上下文的回答。
一致性训练不能简单要求相邻回答语义接近,因为多轮对话可能每轮都在讨论不同内容。更合理的是做事实一致性、角色一致性和状态一致性。比如用户第一轮说“我预算 5000”,后面模型不能推荐 2 万的方案;系统设定是专业客服,后面就不能突然变成闲聊风格;任务状态已经确认的信息,后面不能又反复询问。
数据构造也很关键。除了普通多轮对话,还要专门构造长距离依赖样本、指代样本、省略样本、事实冲突样本和角色漂移负样本。比如第 2 轮给出用户偏好,第 15 轮再问推荐方案,看模型是否还能用上前面的偏好。负样本可以故意改写某轮回答,让它和前文冲突,再训练模型识别或避免这类错误。
推理机制上,我会做动态上下文管理。输入不是简单拼全量历史,而是系统指令、当前任务状态、检索到的长期记忆、最近几轮完整对话和当前问题。窗口快满时,旧轮次先摘要,再抽取关键事实入库;对特别关键的信息,比如用户约束和业务状态,单独结构化保存,不只依赖自然语言摘要。
还要做冲突检测。长期记忆、当前对话和外部工具结果不一致时,要按可信度和时效排序。一般实时工具结果优先于历史记忆,明确用户刚刚修改的偏好优先于旧偏好。模型如果无法判断,要说明不确定并追问,而不是把冲突信息硬拼成一个答案。
所以我的整体方案是:架构上长上下文加外部记忆,训练上强化多轮状态和一致性,数据上覆盖长距离依赖和冲突样本,推理上做动态上下文、记忆检索和冲突裁决。这样才能系统性提升多轮对话,而不是只靠把窗口变长。