多轮对话评测：单轮答得好，不代表上下文稳

多轮对话评测：单轮答得好，不代表上下文稳

一、多轮能力更容易退化

很多模型单轮回答很好，但多轮对话中会忘记约束、重复问题、误解指代、丢失用户偏好或把早期错误带到后续回答。一个客服系统在单轮评测中满意度 92%，但多轮场景中用户纠正后，模型有 30% 的概率仍然沿用错误信息回答，导致用户反复纠正后直接放弃。只评测单轮任务，无法发现这些问题。

多轮对话评测要关注上下文保持和状态一致性。

二、设计多轮任务脚本

flowchart TD A[第 1 轮设定目标] --> B[第 2 轮补充约束] B --> C[第 3 轮追问细节] C --> D[第 4 轮修改条件] D --> E[最终输出]

评测脚本要模拟真实用户：先给目标，再追加约束，再纠错，再要求总结。不能只做问答题。

dialog_eval_case: turns: 5 constraints: - remember_user_preference - update_after_correction - avoid_repeating_resolved_question

多轮评测样本要覆盖长短不同的对话。短对话测试基本上下文保持，长对话测试记忆衰减和状态一致性。两者能力曲线不同——有些模型在 10 轮以内稳定，超过 20 轮后摘要记忆开始丢失约束，需要分开评估。

三、指标要看状态

多轮评测不只看最终答案，还要看每轮是否正确使用上下文。比如用户第二轮说“不要使用外部库”，模型第四轮不能又推荐外部库。

dialog_metrics: context_retention: true correction_following: true contradiction_rate: true final_task_success: true

矛盾率是一个很有用的指标。模型前后自相矛盾，会直接损害信任。

四、上下文长度要分档

短对话、中等对话、长对话要分开评测。模型在 5 轮对话里稳定，不代表 30 轮仍然稳定。

dialog_length_buckets: short: 3 medium: 10 long: 30

还要评测压缩记忆。摘要记忆是否丢掉关键约束，是多轮系统常见风险。

上下文越长，压缩策略越激进，不可避免会损失细节。权衡点在于丢掉更早的约束还是更次要的约束。可以按约束类型做优先级标记，让记忆压缩时优先保留安全规则、用户偏好和任务目标，压缩细节描述。

最后，评测结果要关联上下文策略。是模型能力不足，还是记忆裁剪策略有问题，要分开定位。

多轮评测还要加入干扰信息。用户在中间插入无关内容、修改目标、撤销上一轮要求，模型是否能正确更新状态，是对话系统的关键能力。

dialog_stressors: irrelevant_message: true user_correction: true constraint_change: true ambiguous_reference: true

指代解析也要单独看。“把它改短一点”“继续刚才那个方案”“不要用上一种格式”，这些句子都依赖上下文。模型如果指代错了，最终答案会偏离任务。

还要评估礼貌性和效率。多轮系统不能每轮都长篇解释，也不能在用户已经确认后继续反复询问。任务推进效率也是体验指标。

最后，多轮评测轨迹要保存。只看最终答案，很难知道模型是在第几轮开始忘记约束。

还要看工具型多轮对话。用户第一轮上传文件，第二轮要求分析，第三轮修改输出格式，模型是否能正确引用文件状态和工具结果，是比纯聊天更真实的场景。

tool_dialog_eval: file_context: true tool_result_memory: true format_change_midway: true

多轮系统还要评测拒答一致性。第一轮因为安全原因拒绝，后面用户换个说法，模型不能绕过原来的边界。

最后，长对话评测要看成本。上下文越长，token 成本越高，稳定性和成本需要一起衡量。

五、总结

多轮对话评测要设计连续任务脚本，关注上下文保持、纠错遵循、矛盾率和不同长度下的稳定性。

单轮答得好，不代表上下文稳。对话系统必须评测过程。