一篇读懂多轮对话训练：多轮对话数据的构造、训练与评测

多轮对话和单轮差在哪

被高估的「自然涌现」

一个流传很广的假设是：模型见过足够的单轮对话数据，多轮能力是自然涌现的。实践反复证伪这一点。微软研究院 2025 年的论文《LLMs Get Lost in Multi-Turn Conversation》（Laban 等人，arXiv 2505.06120）做了系统实验：把同等的任务信息拆进多轮对话（模拟真实用户常见的分次表述、中途补充约束、隐含省略），模型在多轮设定下的任务表现相对单轮全信息设定平均下降约 39%，而且一个反直觉的发现是「轮次拆分得越细，掉得越多」——模型倾向于在第一轮就给出仓促的答案，而不是先澄清缺失信息。这个数字说明多轮对话是一种需要专门训练的独立能力，其核心难点有三：上下文累积（必须记住并正确使用前面轮次确立的约束）、轮间一致性（前后轮的说法不能自相矛盾）、主动澄清（信息不足时先问而不是先猜）。

从训练数据的角度看问题更直观：单轮数据教的是「给定完整问题给完整答案」，而真实多轮对话的第 N 轮，问题的完整语义分散在全部历史里——用户第二轮说「那换成 Python 呢」，脱离第一轮的问题文本完全不可解析。数据分布上，多轮样本的「有效条件信息」与「当前轮文本」的比例随轮次递增，这正是单轮训练无法覆盖的分布外区域。

多轮数据的构造

三条来源：真实收集、模型模拟、单轮合成

生产级多轮数据的来源分三条路线，各有明确的适用边界。真实用户数据（如 WildChat，1 百万条真实 ChatGPT 网页端对话，2023 年开放）分布最真实，但质量方差极大：含大量闲聊、敏感内容与半途而废的对话，清洗管线（去重、毒性过滤、完整度判定）要做得很重，且使用授权需要谨慎处理。模型模拟是当前的主力：UltraChat（2023，约 57 万条多轮对话）用两个模型分别扮演提问者与回答者，围绕预设话题生成有目标的多轮交互——提问模型被设计成「追问、质疑、切换子话题」，这正是真实用户行为的模拟。单轮合成多轮成本最低：把已有的高质量单轮样本作为最后一轮，反向生成之前的对话历史（「为一个答案构造自然的提问上下文」），适合在多轮数据不足时快速补量。

三条路线都要过同一道质量关：轮间连贯性校验。合成多轮最常见的失败模式是「伪多轮」——每轮独立成立，合在一起逻辑断裂（第二轮的「它」指代不清、第三轮引入的约束与第二轮矛盾）。可执行的校验是逐轮用判别模型验证：给定前 k 轮历史，当前轮的用户文本是否自然连贯、指代是否可解析。这个校验的判别通过率是数据管线最值得监控的指标，UltraChat 论文报告其数据管线里专门有针对性地缓解了这类指代断裂问题。

flowchart TD
    A[话题种子库] --> B[用户模型生成追问]
    B --> C[助手模型回答]
    C --> D{轮数达标或话题耗尽}
    D -- 否 --> B
    D -- 是 --> E[完整对话轨迹]
    E --> F[逐轮连贯性校验]
    F --> G{指代与逻辑可解析}
    G -- 是 --> H[入库并生成 loss mask]
    G -- 否 --> I[丢弃或回退到可解析前缀]
    H --> J[训练集]

构造时的三个工程细节

细节一：角色不可混淆。合成数据要把用户轮与助手轮用不同的生成模型或至少不同的系统提示区分，否则对话风格趋同（用户回答问题而不是提问），训练出的模型会学坏。细节二：轮数分布要有意识设计。真实业务的对话轮数集中在 3 到 8 轮，合成数据如果默认生成 2 轮或均匀分布到 20 轮，分布就不匹配；成熟做法是按业务日志统计轮数直方图，按直方图采样目标轮数。细节三：最后一轮的信息密度。评测时模型的得分几乎完全由最后一轮的表现决定（见下文 MT-Bench），所以构造数据时要保证最后一轮「值得回答」——它是任务的收束点而不是随口的「谢谢」。这三个细节共同决定了合成多轮数据的可用率，业界管线的经验值在五六成上下，其余在连贯性校验环节被丢弃。

训练细节：Loss 该算在哪

三种 mask 策略与它们的取舍

多轮对话训练里最重要的一个决策是对哪些 token 计算损失。三种策略。策略 A：只对助手轮算损失，用户轮与系统轮永远 mask 掉——这是共识底线，没有争议。策略 B：对所有助手轮都算损失（从第一轮到最后）。策略 C：只对最后一轮助手轮算损失，前面轮次的助手输出只作为上下文参与注意力但不计损失。

策略 C 不是拍脑袋，DeepSeek-V2 论文（2024）明确报告了对多轮对话数据采用末轮损失，并给出正面评价。它的逻辑：多轮训练要学的能力是「在累积上下文条件下生成恰当回应」，策略 B 让模型同时学习「给定短上下文回答」（早期轮）与「给定长上下文回答」（后期轮），两个任务的梯度混在一起且早期轮占用了大部分序列位置；策略 C 把训练目标统一收敛到最长上下文条件下的生成，与评测时「看全部历史、答最后一问」的推理形态严格对齐。代价是数据利用率降低——同样一条 8 轮对话，策略 C 的有效监督 token 只有策略 B 的八分之一，需要更大的数据量来补偿。工程建议：资源紧张时用策略 B（主流开源框架如 LLaMA-Factory、TRL 的默认行为），追求多轮能力上限时做一次策略 C 的对照实验，用多轮评测集验证收益再定稿。

# 伪代码：构造多轮样本与 loss mask（ChatML 风格）
tokens, labels = [], []
for turn in conversation:
    if turn.role == "user":
        seg = tokenize(f"<|im_start|>user\n{turn.text}<|im_end|>\n")
        tokens += seg
        labels += [IGNORE_INDEX] * len(seg)     # 用户轮不计损失
    else:
        seg = tokenize(f"<|im_start|>assistant\n{turn.text}<|im_end|>\n")
        tokens += seg
        labels += seg if TRAIN_ALL_TURNS else [IGNORE_INDEX] * len(seg)
        # 策略 B: TRAIN_ALL_TURNS = True
        # 策略 C: 只有最后一轮为 True，其余置 IGNORE_INDEX

还有一个容易被忽略的实现级 bug 源：跨轮注意力与位置编码。多轮样本整条拼接训练时，模板里的特殊 token（<|im_start|> 等）参与了位置编码计数，推理时模板又由推理引擎重新拼接——训练侧与推理侧的模板实现稍有出入（比如是否给系统轮单独计位置），多轮长上下文下的行为就会出现训练不一致的漂移。上线前用「训练脚本导出的完整文本」与「推理引擎组装的完整文本」做字节级 diff，是必须的一次性验证。

多轮能力与长上下文：相关但不等价

还有一个常见的概念混淆需要澄清：多轮能力差，是不是扩长上下文窗口就能解决？答案是相关但不等价。长上下文解决的是「装得下」——几十轮、数万 token 的历史能完整放进窗口；多轮能力解决的是「用得好」——模型能否在长历史里定位到第二轮确立的那个约束、并保持与第七轮自己说过的话一致。前者的研究工具是大海捞针类检索测试，后者的研究工具是指代解析与约束累积测试，两者测的是不同回路。实证上模型可以检索得很好而多轮表现很差（Laban 等人的论文里模型能复述全部历史却仍然答错当前问题），这就是「装得下不等于用得好」的直接证据。训练上的对应关系：上下文扩展（位置编码外推、长序列训练）不自动提升多轮分数，多轮专项数据与末轮损失策略也不提升检索精度，两组工作要分开立项、分开评测。

由此推出数据构造的最后一个细节：轮数与长度的联合分布。合成多轮数据如果平均每轮 200 token、10 轮封顶，训练出的模型面对「每轮 2000 token 的长轮次对话」（真实业务里粘贴代码、长文档的场景）就落在分布外。成熟的做法是从业务日志统计「轮数 × 每轮长度」的二维直方图，按直方图采样构造数据，并对超长对话设定截断策略——保留首尾、截中间是最常用的方案（首部含任务设定、尾部含当前问题），但截断点附近的指代关系会断裂，所以截断必须在样本级校验（截断后最后一轮是否仍可解析）而不是盲切。

评测：MT-Bench 之外

MT-Bench 的设计与它的失真

MT-Bench（Zheng 等人，2023，随 Chatbot Arena 一同发布）至今仍是多轮能力最常引用的基准：80 道跨领域题，每题固定两轮（第一轮开放问题，第二轮要求修正或深化第一轮的答案），用 GPT-4 做裁判打 1 到 10 分。它的贡献是第一次把「第二轮表现」变成显式考项——第二轮的分数天然低于第一轮（模型要同时理解自身第一轮的输出并做出修正），这个分差本身就是多轮能力的信号。但它的局限同样明显：80 题的信息量太小（置信区间宽）、两轮的深度远不及真实对话、GPT-4 裁判对被评模型的家族偏好与长度偏好已被反复记录。今天的 MT-Bench 分数应当只当作粗粒度的回归指标，不能作为模型间精细排序的依据。

走向真实负载的评测

更接近真实的多轮评测分两类。一类是能力型基准：MultiChallenge（Scale AI，2024）用 10 轮级的复杂交互测指代解析、约束累积与上下文更新，报告显示当时的前沿模型在这类任务上的表现远低于其单轮能力所暗示的水平；ToolTalk 与各类 agent 基准则把多轮扩展到工具调用场景。另一类是过程型指标：不看单轮得分，而看整条对话轨迹的任务完成率、澄清提问率、轮间矛盾率——这些指标需要从线上日志回流构造，但它们是唯一与业务收益直接挂钩的数字。评测建设上，开源基准负责横向对比与回归测试，自建评测集（从真实用户对话采样、人工校验标注）负责回答「我们的多轮改进是否让用户少复述、少澄清」这个终极问题。

小结

多轮对话是需要专门训练的独立能力：同等任务拆进多轮，模型平均掉三成以上，根因是「条件信息散布在全部历史」的分布单轮训练覆盖不了。数据侧的三条路线——真实收集重清洗、模型模拟重连贯（UltraChat 式双角色生成）、单轮合成重指代校验——都要过轮间连贯性这道质量关，可用率五六成是正常水位。训练侧的核心决策是 loss mask：只对助手轮计损失是底线，末轮损失（DeepSeek-V2 采用）在目标对齐上更优但数据利用率降八成，值得做对照实验；训练与推理的模板一致性必须做字节级验证。评测侧 MT-Bench 只配当回归指标，MultiChallenge 类能力基准与线上轨迹的过程指标才是多轮能力的真实标尺。多轮能力的提升从来不是「多加点对话数据」那么简单，它是数据构造、损失设计、评测口径三件事同时到位的结果。