数据工程·多轮对话演化树

《AI 数据全书》· 第 22 章 · 多轮 Agent 交互数据

多轮数据不是「一堆单轮拼接」，轨迹的天花板是环境。四个 Tab 各堵一个洞： 结构规则不满足，多轮数据直接变脏信号； 模板换了而 mask 逻辑没换，模型会学会自问自答； 上下文一致性是规则层只能抓住最明显那 30–50% 的活； 意图波动不是「上下文不够长」——信息还在窗口里、但已经过期了，外推与压缩都救不了。 三条结构规则、loss mask 边界、泄漏检查、两种平均、JSON Schema 校验、规则层一致性全部在浏览器里真算； Tab ② 的对话是规则模板生成（已明示），环境 Scaling Law 曲线是示意，13 种波动场景回源到论文原表。

🧮本 Tab 的三条结构规则、token 切分、两种平均与泄漏检查全部在浏览器里真跑，不是模拟动画。 分词是浏览器端近似（中文按字、英文按空白与标点），不是真实 BPE——它只用来演示「mask 的边界落在哪」，真实训练必须按 tokenizer 的 vocabulary 对齐。

🧪脏样本库

🔍validate_messages 实时结果

1 处
system#0
你是一个有用的助手。
user#1
帮我订一张机票
system#2
你现在是订票专员。
✗ system at position 2
assistant#3
好的，请问出发地？
user#4
北京
assistant#5
已为您查询北京出发的航班。

🎭loss mask 逐 token 高亮

📖 §22.2.2🧮 真跑
<|start_header_id|>system<|end_header_id|>你是一个有用的助手。<|eot_id|><|start_header_id|>user<|end_header_id|>今天天气怎么样？<|eot_id|><|start_header_id|>assistant<|end_header_id|>我需要查询天气数据。请问你在哪个城市？<|eot_id|><|start_header_id|>user<|end_header_id|>北京<|eot_id|><|start_header_id|>assistant<|end_header_id|>北京今天晴，最高温度25°C。<|eot_id|><|start_header_id|>user<|end_header_id|>明天呢？<|eot_id|><|start_header_id|>assistant<|end_header_id|>明天多云，最高23°C，风力3级，空气质量良，适合出行，记得带伞以防阵雨。<|eot_id|>
assistant 正文 · 正确算 lossassistant 正文 · 被漏掉非 assistant · 被算进 loss（泄漏）模板 token · 被算进 loss条件部分（不计 loss）
总 token
121
算进 loss
69
泄漏 token
0
模板 0 / 其他 0
漏算 token
0
泄漏检查（零模型）
✓ 通过
Δ=0.000000

🧠第三层 mask：教师推理标注（Thought）计不计 loss

📖 §22.2.2 末🧮 真算
上面两张卡片的粒度停在「assistant vs 非 assistant」；这一层在 assistant 输出内部再切一刀。 下方每轮 assistant 的 Thought 区段即教师推理标注， 开关切换它是否进入监督区间——被 mask 的 Thought 仍保留在上下文里，只是不计 loss。
<|start_header_id|>system<|end_header_id|>你是航班预订助手。<|eot_id|><|start_header_id|>user<|end_header_id|>帮我把下周三去西安的机票改成早班。<|eot_id|><|start_header_id|>assistant<|end_header_id|>用户要改签，需要先查原订单再查可选航班；订单号没给，先查询。好的，查到您的原订单CA1832（本周三14:20）。下周三早班有CA183108:20，改签费200元，要改吗？<|eot_id|><|start_header_id|>user<|end_header_id|>改吧。<|eot_id|><|start_header_id|>assistant<|end_header_id|>用户确认，执行change_flight：flight_id=CA1831，date=下周三。已改签成功：新航班CA1831下周三08:20，200元已从预授权扣款。<|eot_id|>
Thought · 被算进 loss（full）Thought · 被排除（masked，仍留在上下文）assistant 正文 · 计 loss条件部分（不计 loss）
总 token
170
算进 loss
121
占 71.2%
Thought token
50
占 assistant 输出 41.3%
正文 token
71
零模型实算 loss
1.4837
masked 口径下另有 41.8% 参与率
🧪
反直觉结论⚠ workshop · 待验证
SyntheticAgentTraceQA（arXiv:2607.29175，International Workshop on Agentic AI for Next-Generation Software Development, 2026-10 Munich（workshop，未正式收录））在四个工具生态上报告：masked supervision（开关关掉）提升最终答案指标；full supervision（开关打开）在答案质量上反而更差， 且在参考轨迹一致性上也没有一贯提升——9B 规模尤其明显。三条边界：workshop 论文，未见正式期刊/会议收录；结论来自 9B 单一规模、四个工具生态；与 §22.6.6 的 turn 级 mask 是不同粒度：那边按信息量选 turn，这边按 token 类别选内容。 实践建议：默认先按 masked 试，再按你的目标（要过程能力还是要答案质量）决定是否打开。
「Thought 可监督」≠「Thought 应该进 loss」：Thought 留在上下文里、不进 loss，可同时拿到「可归因」（可单独对 Thought 做质量评审， 见 §22.3.4）与「答案质量」两头的收益。注意与 §22.6.6 的 turn 级 mask 是不同粒度——那边按信息量选哪些 turn 参与，这边按 token 类别选内容，两者可以同时用。

⚖️轮级平均 vs token 级平均

🧮 真算
轮 1
19 tok · 27.5%
轮 2
14 tok · 20.3%
轮 3
36 tok · 52.2%
轮级平均 loss
1.4147
token 级平均 loss
1.4144
最长回复占梯度
52.2%
长回复主导梯度
本例最后一条回复写了 30 个字，前两条各 10 字出头。轮级平均下三条回复各占 33.3%，token 级平均下最长那条独占 52.2%—— 这正是 §22.2.2 说的「工业实践多采用 token 级平均并配合长度截断，避免超长回复主导梯度」。

🕵️mask 泄漏检查怎么跑

📖 §22.2.2
零模型 = 输出恒定的分布，所以每个 token 的 loss 只由 token 本身决定、与上下文无关。 于是可以先从 messages 里离线算出「只有 assistant 正文时应该得到的 loss」， 再和训练管线实际报出来的 loss 比对——对不上，就是 mask 的边界和 messages 的 assistant 区间不一致。
应有 loss（离线算）
1.414391
管线实算 loss
1.414391
与应有值一致
✓零模型跑出来的 loss 与离线期望完全一致 → 监督区间里只有 assistant token，可以上线。

🧩工具调用样本的三个字段坑

📖 §22.4.1
训练数据里 content: null 与 content 有正文两种形态都要有——只给一种，模型会学出 「必须先说话才能调工具」或「调工具时绝不能说话」的死板模式。
{
  "role": "assistant",
  "content": null,
  "tool_calls": [
    {
      "id": "call_001",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\": \"北京\", \"date\": \"tomorrow\"}"
      }
    }
  ],
  "toolMsgs": [
    {
      "role": "tool",
      "name": "get_weather",
      "content": "{\"temp\": 23, \"weather\": \"cloudy\"}",
      "tool_call_id": "call_001"
    }
  ]
}
content: null 合法性
null 是合法值——模型学到了「调工具时可以不先说话」
arguments 是字符串化 JSON
字符串化 JSON：与 OpenAI 协议一致
id ↔ tool_call_id 配对
call_001 ↔ call_001 严格配对
§22.2.4 轮次切分提醒：一个「轮次」指一次 user→assistant 往返，评估数据规模通常统计轮数分布而非消息条数（见 Tab ② 直方图）。

这个工具里哪些数字是真的

📖 文献值（原书 / 论文引文，非本工具实算）
  • · UltraChat 5 轮截断、双 GPT-4、结束检测 <|end|>（§22.2.5）
  • · System Prompt 五类型配比 30/20/20/20/10（§22.2.6）
  • · 一致性规则层过滤 30–50% 最明显不一致（§22.2.3）
  • · 合成 trajectory 不合格率 15–25%，>40% 应修上游（§22.5.2）
  • · HardGen：Qwen3-4B BFCL Multi-Turn 22.13% → 63.13%，对比 Gemini-3-Pro-Preview 60.75% / GPT-5.2 28.13%（§22.5.1）
  • · SKT：2,000 skills → 4,000 task packages → 27,164 轨迹（§22.3.5）
  • · xLAM 60K / Glaive 100K Tool-Use 数据（§22.4.5）
  • · §22.8 十步 SOP 与 30/30/20/20 来源配比
  • · 13 种意图波动场景的名称 / 计数 / 占比：arXiv:2608.02110 正文 Table 18（N=5,639，逐项相加 = 5,639）；测试集 2,550（ID 1,272 / OOD 1,278），18.7% 原地修订、4.2% 丢弃
  • · 五维诊断指标 JGA / SCRR / RIR / DTCR / ISSR：同一论文 §3.3
  • · TRAJECT-Bench（arXiv:2510.04550）：相似工具混淆 / 参数盲选两类失效 + 「短→中长度轨迹跃迁是瓶颈」（§22.5.5，书籍 09-22 edit）
  • · Trajectory2Gym（arXiv:2610.33568，10-24 预印本未见收录）：structural-support selection / parent-normalized SFT 两条做法、三基准等权均值 +16.9–29.8pp、增益在有状态多轮交互上最强（§22.5.5 第七维，书籍 10-30 edit）
  • · SyntheticAgentTraceQA（arXiv:2607.29175，workshop·待验证）：masked supervision 提升最终答案指标、full 反而更差（9B 尤其明显）；execution-first 合成顺序（§22.2.2 / §22.3.4，书籍 10-11 edit）
  • · 环境量化律（arXiv:2610.23946，NeurIPS 2026 已接收）：指数排序 environment > task > trajectory、world diversity 主驱动、临界比跨轴差一个数量级、最高 1.7× 算力效率——逐轴指数与分项数值未回正文（§22.6.4，书籍 10-30 edit）
  • · ATBench（arXiv:2604.02022）：8 风险来源 × 14 失效模式 × 10 现实危害、1,000 条轨迹 503/497、平均 9.01 turns、3.95k tokens、1,954/2,084 工具池（§22.5.6，书籍 09-22 edit）
  • · Davinci-Tool（arXiv:2610.16867，预印本）：30,395 条已验证轨迹 / 2,260 工具名；30B 模型 τ²-bench 52.4→88.2、BFCL v4 30.4→62.8、MCP-Atlas 16.9→56.2（§22.5.7 / §22.6.5，书籍 10-30 edit）
  • · TestJack（arXiv:2610.10619）：约 34.4% 被判正确 trial 违反任务要求、解决率 50.6%→33.2%；Interaction-as-a-Judge（arXiv:2610.17895）：人类偏好预测 65.6%→69.1%、需求验证 77.0%→81.6%、win-rate +6.7pp（§22.5.3，书籍 10-30 edit）
  • · COVERT（arXiv:2604.09813）：oracle-preserving 增强两步法（§22.4.3，书籍 10-11 edit）
  • · DeepSeek-V4-Pro 的 12,200 反例：Redwood Research 的 NLS depth 操作化提案（AI Alignment Forum, 2026-09-11）
🧮 浏览器内真算
  • · validate_messages 三条规则（8 条脏样本逐条跑，报错串与原文一致）
  • · chat template 渲染、token 切分、loss mask 边界与泄漏 / 漏算计数
  • · 零模型下的「应有 loss vs 管线实算 loss」泄漏检查（Δ 精确到 1e-9）
  • · 轮级平均与 token 级平均、最长回复占梯度比例
  • · validate_tool_call 的 JSON Schema 校验与 id ↔ tool_call_id 配对检查（8 条样本）
  • · 规则层一致性检查（城市 / 日期 / 带单位数字 / 称呼 四类槽位逐轮比对）
  • · 演化树的分支抽样、质量分、簇划分、三种剪枝与轮数分布直方图
  • · 第三层 mask 面板：Thought 区段计 / 不计 loss 的 token 流渲染、loss 参与占比与零模型实算 loss 两种口径
⚠ 教学模型 / 示意值 / 规则生成
  • · Tab ② 的对话全部由规则模板 + mulberry32 种子生成，不调用任何模型；质量分是本工具按规则算的，非人工标注真值
  • · 分词是浏览器端近似（中文按字、英文按空白与标点），不是真实 BPE
  • · 环境 Scaling Law 曲线为按 §22.6.4 定性描述设定的示意曲线，非任何实测拟合；量化版结论卡的四条为 📖 摘要层文献值
  • · Tab ④ 的 8 条样本是刻意挑的反面教材集，不合格率不代表真实管线
  • · 七维打分：前五维与第六/七维均为按样本缺陷人工标注的真值（第六维 depOrder / 第七维 grounding 读样本标注字段），非模型打分
  • · 意图波动沙盘的三段对话是固定脚本（真跑的是 stale flag 状态机与残留 / 循环计数），不是模型输出
⚠ 本工具不调用任何模型或后端服务。原书 §22.5.1 只写了「13 种细粒度波动场景」这个总数、未列名称与占比， 本工具没有做任何推测填充——名称、计数、占比全部回源 arXiv:2608.02110 正文 Table 18。 另注：IACM-RL 的场景设定是复杂工具调用下的长程执行，若你的 Agent 不涉及多步工具调用，场景分类需要重新梳理， 但「过时约束仍在上下文中」这一失效机理仍然成立。
内容参考 《AI 数据全书》第 22 章「多轮 Agent 交互数据」