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

《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

⚖️轮级平均 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
  • · 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 配对检查（6 条样本）
  • · 规则层一致性检查（城市 / 日期 / 带单位数字 / 称呼 四类槽位逐轮比对）
  • · 演化树的分支抽样、质量分、簇划分、三种剪枝与轮数分布直方图
⚠ 教学模型 / 示意值 / 规则生成
  • · Tab ② 的对话全部由规则模板 + mulberry32 种子生成，不调用任何模型；质量分是本工具按规则算的，非人工标注真值
  • · 分词是浏览器端近似（中文按字、英文按空白与标点），不是真实 BPE
  • · 环境 Scaling Law 曲线为按 §22.6.4 定性描述设定的示意曲线，非任何实测拟合
  • · Tab ④ 的 6 条样本是刻意挑的反面教材集，不合格率不代表真实管线
  • · 五维打分为按样本缺陷人工标注的真值，非模型打分
  • · 意图波动沙盘的三段对话是固定脚本（真跑的是 stale flag 状态机与残留 / 循环计数），不是模型输出
⚠ 本工具不调用任何模型或后端服务。原书 §22.5.1 只写了「13 种细粒度波动场景」这个总数、未列名称与占比， 本工具没有做任何推测填充——名称、计数、占比全部回源 arXiv:2608.02110 正文 Table 18。 另注：IACM-RL 的场景设定是复杂工具调用下的长程执行，若你的 Agent 不涉及多步工具调用，场景分类需要重新梳理， 但「过时约束仍在上下文中」这一失效机理仍然成立。
内容参考 《AI 数据全书》第 22 章「多轮 Agent 交互数据」