research: preregister task bootstrap CRN protocol

2026-07-30 04:14:58 +08:00
parent 756e0e6b18
commit 6181af90c8
3 changed files with 1883 additions and 0 deletions
@@ -0,0 +1,381 @@
+# DeepSeek-V2-Lite-Chat 任务 bootstrap 与显式共同随机数协议
+
+> 状态：**已预注册，尚未运行本协议的任何生成输出**
+>
+> 注册日期：2026-07-30
+>
+> 协议 ID：`llm-atlas-deepseek-chat-task-bootstrap-crn-v1`
+>
+> 冻结清单：
+> `research/DEEPSEEK_V2_LITE_CHAT_TASK_BOOTSTRAP_MANIFEST.json`
+>
+> 清单文件 SHA-256：
+> `7f5ef75f8e4bade35875e9132ea16f25f7fdb54450490e07cf1f6b2f701fceac`
+>
+> 清单规范内容 SHA-256：
+> `42ec988585d34ce9c2a193dd59a30a7f549d8a67b768c17098aaf3f30ca73804`
+
+## 0. 一句话说明这一轮
+
+Round 07 用 4 道 HumanEval、4 道 GSM8K 和每题 4 个 seed 回答了“换几道题后，现象还在
+不在”。但 4 道题仍太少，而且把同题多个随机输出当成多道题会制造伪样本量。
+
+Round 08 改为：
+
+```text
+主分析：
+  32 HumanEval × 1 冻结随机带 × 4 条件 = 128 outputs
+  32 GSM8K   × 1 冻结随机带 × 4 条件 = 128 outputs
+
+随机带敏感性诊断：
+  每域 4 道预选题 × 额外 3 条随机带 × 4 条件 = 48 outputs / domain
+
+正式总计：
+  256 + 96 = 352 outputs
+```
+
+它第一次允许在当前预选的 32 道题内做**按题重采样**，并且让同题四个条件在第 `t` 个
+生成步真正读取同一个均匀随机数。它仍然不是完整 HumanEval / GSM8K benchmark，不估计
+模型总体能力，也不把 counterfactual `period` 序列称为官方聊天格式。
+
+---
+
+## 1. 研究问题
+
+### 1.1 主要问题
+
+HumanEval 与 GSM8K 分开回答：
+
+1. 在固定 T0 随机带下，`period - EOS` 是否改变选定任务上的通过率、自然 EOS 率和输出
+   长度？
+2. `system on - off` 是否在 EOS 与 period 边界下方向一致？
+3. 任务级差异是否足以让 Round 07 的 4 题方向翻转？
+4. 同一均匀随机带下，四个条件从哪一步开始分叉；分叉前是否逐步读取完全相同的
+   `u_t`？
+
+### 1.2 诊断问题
+
+每域固定 index `0, 8, 16, 24` 四题，额外运行 T1、T2、T3：
+
+1. T0 上的任务级差异相对随机带差异有多大？
+2. 主要 contrast 的方向是否依赖单条随机带？
+3. 对同一道题，四条随机带带来的成功/失败与长度变化有多大？
+
+这些是敏感性诊断，不与 32 题 T0 主分析合并成一个更大的“样本”。
+
+---
+
+## 2. 模型、软件与提示合同
+
+冻结：
+
+- checkpoint：`deepseek-ai/DeepSeek-V2-Lite-Chat`；
+- revision：`85864749cd611b4353ce1decdb286193298f64c7`；
+- checkpoint 身份：SFT Chat；
+- Transformers `4.41.2`；
+- PyTorch `2.11.0+cu128`；
+- BF16、官方 remote modeling code、eager attention；
+- embedding + layers 0–23 放 CUDA；
+- layers 24–26、final norm 与 `lm_head` 放 CPU；
+- `device_map=auto`，GPU budget `28GiB`，CPU budget `80GiB`；
+- `use_cache=true`，每条 trajectory 的 `max_new_tokens=512`；
+- BOS `100000`，EOS `100001`，PAD alias EOS。
+
+固定四条件与行序：
+
+```text
+s0_eos, s1_eos, s0_period, s1_period
+```
+
+- `s0/s1`：system off/on；
+- `eos`：官方历史 assistant 边界；
+- `period`：把该位置的单个 EOS ID 换成 ordinary period ID `13`；
+- 其余 prompt token 与前序冻结模板相同；
+- 每条 prompt token hash 必须与冻结清单逐格 exact。
+
+正式生成不是四行 batch。四条 trajectory 逐条执行，以避免一个条件先 EOS 后 batch
+padding / RNG 调用对其他条件产生隐式影响。
+
+---
+
+## 3. 任务如何在结果前冻结
+
+输入来源：
+
+```text
+src/data/deepseek-v2-lite-routing-special-token-family-control.json
+SHA-256 c372c1b03a8b15f615b54ded5d9257a8fc2cdb7728001735d3d4c1d8534af5bf
+sample salt llm-atlas-deepseek-routing-template-control-v1
+```
+
+每个领域使用其中按 `within_domain_index=0..31` 已冻结的全部 32 条，不根据 Round 07
+正确率、输出长度、EOS 或文本质量二次筛选。完整 source ID、selection rank、源文本 hash、
+四格 prompt hash、随机带分配和重放分配均在冻结清单内。
+
+### 3.1 HumanEval
+
+```text
+00 HumanEval/31   01 HumanEval/44   02 HumanEval/133  03 HumanEval/23
+04 HumanEval/147  05 HumanEval/34   06 HumanEval/123  07 HumanEval/77
+08 HumanEval/22   09 HumanEval/127  10 HumanEval/37   11 HumanEval/48
+12 HumanEval/158  13 HumanEval/70   14 HumanEval/89   15 HumanEval/9
+16 HumanEval/53   17 HumanEval/145  18 HumanEval/35   19 HumanEval/103
+20 HumanEval/25   21 HumanEval/98   22 HumanEval/115  23 HumanEval/10
+24 HumanEval/141  25 HumanEval/91   26 HumanEval/122  27 HumanEval/75
+28 HumanEval/134  29 HumanEval/142  30 HumanEval/149  31 HumanEval/102
+```
+
+### 3.2 GSM8K
+
+```text
+00 1069  01 1228  02 0144  03 1251  04 0676  05 0126  06 0438  07 1299
+08 0546  09 0537  10 0226  11 1128  12 0760  13 1173  14 0452  15 0357
+16 1050  17 0951  18 0906  19 0092  20 0372  21 0361  22 0733  23 0687
+24 0584  25 1152  26 1021  27 1194  28 0399  29 0214  30 1084  31 0964
+```
+
+GSM8K 行均指 `gsm8k/test/NNNN`。
+
+gold 只进入生成后的 evaluator：
+
+| 输入 | SHA-256 |
+|---|---|
+| HumanEval JSONL.gz | `b796127e635a67f93fb35c04f4cb03cf06f38c8072ee7cee8833d7bee06979ef` |
+| GSM8K test JSONL | `3730d312f6e3440559ace48831e51066acaca737f6eabec99bccb9e4b3c39d14` |
+
+---
+
+## 4. 真正的共同随机数如何构造
+
+### 4.1 为什么不再只重置 seed
+
+Transformers `generate()` 的常规 sampling 最终调用 `torch.multinomial`。即使四行共享 batch
+seed，每行也消费不同 RNG 子流；如果逐行重置同 seed，分布内部的实现细节仍不等于我们
+明确定义并能逐步审计的共同随机数合同。
+
+本轮不调用 `torch.multinomial`，也不把输出称作“Transformers 官方 sampler 的 exact
+trajectory”。模型、logits 和官方 `.3/.95` 解码分布仍来自固定 checkpoint；离散取样器改为
+本协议定义的**显式均匀数 + token-ID 顺序逆 CDF**。
+
+### 4.2 冻结随机带
+
+四条带 T0–T3 的 display seed：
+
+| 带 | display seed | 派生字符串 SHA-256 |
+|---|---:|---|
+| T0 | 2,572,353,518 | `9952ffeec840649d2654d35b9a86c97db3737b70826c366e3f5a7633ec26d0c4` |
+| T1 | 399,507,326 | `17cfff7e5b3b6d011f4d1b8076637d4bdfb0ebd8a6021beb2a0011a8f6d520c6` |
+| T2 | 405,284,229 | `1828258525ea1b450d6de0ba0d9ff12f737b048b1cef554d7dd2ba90d25e5f4d` |
+| T3 | 568,701,915 | `21e5b3dbe506f1b7e9d483318195fc5cb4990c518850a52d40b5eff225491bd2` |
+
+对 `tape_label, source_id, step`：
+
+```text
+H = SHA256(
+  protocol_id + "\0uniform\0"
+  + tape_label + "\0"
+  + source_id + "\0"
+  + decimal(step)
+)
+
+z_t = H[0:8]，big-endian unsigned uint64
+u_t = (z_t + 0.5) / 2^64
+```
+
+`u_t` 位于开区间 `(0,1)`。同一 source + tape 的四个条件在相同生成步 `t` 使用完全相同
+的 `z_t`。某条件 EOS 后停止，不再产生“配对输出”；其他仍存活条件继续读取下一步相同
+定义的随机带。
+
+### 4.3 每一步的概率与取样
+
+对模型最后位置 logits：
+
+1. 用 Transformers `TemperatureLogitsWarper(0.3)`；
+2. 用 Transformers `TopPLogitsWarper(0.95, min_tokens_to_keep=1)`；
+3. 以 `torch.float32` 做 softmax；
+4. 按 token ID `0..vocab-1` 做 `torch.float32` cumulative sum；
+5. 强制最后一个 CDF 元素为 `1.0`；
+6. 将 `u_t` cast 为 `torch.float32`；
+7. `torch.searchsorted(cdf, u_t, right=False)` 取得 token ID。
+
+因此：
+
+```text
+共享的是概率积分尺度上的 u_t
+≠ 强迫四格选择同一 token
+```
+
+prompt 改变 logits 后，同一个 `u_t` 可以落入不同 token 区间，这正是共同随机数配对所需
+的性质。
+
+每条 output 记录：
+
+- 前 8 个 `z_t` / `u_t`；
+-实际消费的 `z_t` 序列规范 hash；
+- prompt hash、generated token IDs 与 hash；
+- EOS / truncation；
+-生成前后 CPU/CUDA RNG state hash；
+- PyTorch RNG 是否完全未被取样器消费。
+
+---
+
+## 5. 执行网格、smoke 与独立重放
+
+### 5.1 16-token smoke
+
+每域 index `0,8,16,24`，T0/T1，四条件：
+
+```text
+8 sources × 2 tapes × 4 conditions = 64 short outputs
+```
+
+通过闸门：
+
+1. 正式 64 题 × 4 条件的 256 个 prompt hash 全部与清单 exact；
+2. 64 条短输出无 OOM、NaN、exception；
+3. 同进程重放 8 sources × T0 × 4 = 32 cells 逐 token、文本与 stop state exact；
+4. T0/T1 至少一个 source-condition trajectory 分叉；
+5. 同一 source+tape 四条件的前 16 个 `z_t` 定义逐步 exact；
+6. 生成前后 PyTorch CPU/CUDA RNG state exact，证明 sampling 不消费隐式 RNG；
+7. synthetic distribution 单元测试覆盖 CDF 边界与被 top-p 过滤 token。
+
+smoke 不进入正式统计。
+
+### 5.2 正式运行
+
+- 全部 64 题跑 T0 × 四条件：256 outputs；
+- 每域 index `0,8,16,24` 再跑 T1/T2/T3 × 四条件：96 outputs；
+- 合计 352 outputs；
+- 每题结束后写独立 journal；再次启动时必须核验协议、source、prompt 与输出内容 hash 后才
+  能 resume；
+- journal 只用于可恢复执行，正式 JSON 由全部合格 journal 组装。
+
+### 5.3 跨进程独立重放
+
+每域 index：
+
+```text
+0, 4, 8, 12, 16, 20, 24, 28
+```
+
+只跑 T0 × 四条件：
+
+```text
+16 sources × 1 tape × 4 conditions = 64 outputs
+```
+
+逐格比较 protocol、model revision、generation contract、tape、prompt hash、uniform hash、
+generated token IDs、decoded text、EOS、truncation 和生成前 RNG state。目标为 64/64
+全部 exact。
+
+---
+
+## 6. evaluator 在输出前冻结
+
+### 6.1 HumanEval
+
+沿用前序四本账：
+
+1. 代码抽取是否成功；
+2. Python AST 是否可解析；
+3. sandbox 是否真正执行；
+4. tests 是否通过。
+
+固定 sandbox：
+
+```text
+python:3.11-alpine
+@sha256:25976e9d34a0fab1f278cae931f34c8303d97bf0c0d7f85b6b4dcf641d7702a4
+```
+
+仍为 network none、read-only root filesystem、非 root、drop ALL capabilities、
+no-new-privileges、256 MiB、64 PIDs、0.5 CPU、5 秒 timeout。报告失败类型：
+
+```text
+extract_failed / syntax_error / timeout / runtime_error / assertion_failed / passed
+```
+
+主 correctness 是 fixed-budget tests pass；strict-complete pass 单独报告，不混写。
+
+### 6.2 GSM8K
+
+沿用冻结 numeric final-answer evaluator：
+
+- gold：`####` 后最后一个规范化数字；
+- prediction：输出中最后一个规范化数字；
+- fixed-budget numeric exact；
+- strict-complete numeric exact；
+- 无数字单独记为 `no_numeric_answer`；
+- 有数字但不等于 gold 记为 `wrong_numeric_answer`。
+
+---
+
+## 7. 统计合同
+
+### 7.1 主要 contrast
+
+在每个 domain 内、每道题、T0 上计算右减左：
+
+```text
+period_at_s0  = s0_period - s0_eos
+period_at_s1  = s1_period - s1_eos
+system_at_eos = s1_eos    - s0_eos
+system_at_period = s1_period - s0_period
+```
+
+success 用 `{-1,0,+1}` 任务级转移；长度与 EOS 保留配对差。两因子 main effect 与
+interaction 可以作为 secondary descriptive summary，但不能替代四个预注册 contrast。
+
+### 7.2 任务 bootstrap
+
+HumanEval 32 题与 GSM8K 32 题分别进行：
+
+- 10,000 次；
+- 每次在当前 domain 的 32 题中有放回抽 32 题；
+- 同一次 resample 对四条件保持题级配对；
+- 固定 seed `1,364,512,825`；
+- 报告 percentile 2.5% / 50% / 97.5%。
+
+必须写成：
+
+> 当前冻结 32 题、固定 T0 下的 selected-task resampling band。
+
+不得写成：
+
+- 完整 benchmark 总体 95% CI；
+- 模型真实能力 CI；
+- 同时覆盖 generation-seed uncertainty 的 CI；
+- 因果效应 CI。
+
+### 7.3 多随机带诊断
+
+对每域固定四题 × T0–T3：
+
+- 分别报告每条带的 condition success / EOS / length；
+- 计算题内跨带 range 与带内跨题 range；
+- 分别做 selected-task 和 selected-tape 描述；
+- 不把 `4 tasks × 4 tapes = 16` 当成 16 道独立题。
+
+---
+
+## 8. 结论边界
+
+允许：
+
+- 描述这 32 道预选题、T0 下四个条件的配对差；
+- 描述任务重采样带与 8 道诊断题上的 tape sensitivity；
+- 描述显式共同随机数下的 first-divergence、转移表和长度差；
+- 报告 exact replay 是否通过。
+
+禁止：
+
+- 把 period 当成官方可部署格式；
+- 把 selected-task band 外推为 benchmark / 用户分布总体；
+- 把一条 tape 的结果写成 sampling robustness；
+- 把测试通过写成代码安全；
+- 把同一 `u_t` 错写成“同一 token”；
+- 把本协议 sampler 写成 Transformers `generate()` / `torch.multinomial` 的 exact
+  trajectory；
+- 根据正式输出修改 source、tape、contrast、bootstrap seed、sandbox 或主指标。
+
+任何偏离必须在结果审计中逐项列出；不能静默修订本文件。