Files

T

wuyang a09e6b14ce research: freeze Chat prompts and CRN runner

2026-07-30 04:23:14 +08:00

13 KiB

Raw Blame History

DeepSeek-V2-Lite-Chat 任务 bootstrap 与显式共同随机数协议

状态：已预注册，尚未运行本协议的任何生成输出

预运行修订 1：实现审查后把“四条 trajectory 逐条执行”改为固定四行 batch；取样仍由每步显式共享的 u_t 完成。修订发生在任何 smoke / 正式输出之前，只为避免四倍重复 forward；finished row 的后续 PAD=EOS 与 mask=0 合同同时冻结在下文。

预运行修订 2：tokenizer-only 闸门发现首版 manifest 误把路由探针的短输入 hash 标成 Chat 生成 prompt hash。此时模型尚未加载、协议输出仍为 0。清单保留路由 hash，并新增由正式 Chat renderer 产生的 256 个 prompt hash；runner 只核验后者。

注册日期：2026-07-30

协议 ID：llm-atlas-deepseek-chat-task-bootstrap-crn-v1

冻结清单： research/DEEPSEEK_V2_LITE_CHAT_TASK_BOOTSTRAP_MANIFEST.json

清单文件 SHA-256： 6313e70536c464fe598a93035576752418f08016dfd60ac246437c3b43bf2ae1

清单规范内容 SHA-256： d15303e18345f6dec2aaf891ba812c0a0232b86f416f8f685eabbe818249e838

256 个 Chat prompt 合同 hash： 7f766be54463c7f513948dd6d63a55e12b85b9220ee177361c743cd9997f6c3b

0. 一句话说明这一轮

Round 07 用 4 道 HumanEval、4 道 GSM8K 和每题 4 个 seed 回答了“换几道题后，现象还在不在”。但 4 道题仍太少，而且把同题多个随机输出当成多道题会制造伪样本量。

Round 08 改为：

主分析：
  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 分开回答：

在固定 T0 随机带下，period - EOS 是否改变选定任务上的通过率、自然 EOS 率和输出长度？
system on - off 是否在 EOS 与 period 边界下方向一致？
任务级差异是否足以让 Round 07 的 4 题方向翻转？
同一均匀随机带下，四个条件从哪一步开始分叉；分叉前是否逐步读取完全相同的 u_t？

1.2 诊断问题

每域固定 index 0, 8, 16, 24 四题，额外运行 T1、T2、T3：

T0 上的任务级差异相对随机带差异有多大？
主要 contrast 的方向是否依赖单条随机带？
对同一道题，四条随机带带来的成功/失败与长度变化有多大？

这些是敏感性诊断，不与 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。

固定四条件与行序：

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，行序即上述条件序。batch 内没有跨行 attention；取样不调用 PyTorch RNG。同一行结束后，后续步追加 PAD=EOS 且该位置 attention mask 为 0，其他仍活跃行继续 forward。这个合同避免四倍重复 forward，也把执行形状固定下来。

3. 任务如何在结果前冻结

输入来源：

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

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

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：

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：

用 Transformers TemperatureLogitsWarper(0.3)；
用 Transformers TopPLogitsWarper(0.95, min_tokens_to_keep=1)；
以 torch.float32 做 softmax；
按 token ID 0..vocab-1 做 torch.float32 cumulative sum；
强制最后一个 CDF 元素为 1.0；
将 u_t cast 为 torch.float32；
float32 转换若落在端点，则 clamp 到 torch.nextafter(0,1) / torch.nextafter(1,0)；
torch.searchsorted(cdf, u_t, right=False) 取得 token ID。

因此：

共享的是概率积分尺度上的 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，四条件：

8 sources × 2 tapes × 4 conditions = 64 short outputs

通过闸门：

正式 64 题 × 4 条件的 256 个 prompt hash 全部与清单 exact；
64 条短输出无 OOM、NaN、exception；
同进程重放 8 sources × T0 × 4 = 32 cells 逐 token、文本与 stop state exact；
T0/T1 至少一个 source-condition trajectory 分叉；
同一 source+tape 四条件的前 16 个 z_t 定义逐步 exact；
生成前后 PyTorch CPU/CUDA RNG state exact，证明 sampling 不消费隐式 RNG；
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 组装。
四格固定同 batch；finished row 在后续步追加 PAD=EOS、对应 attention mask 为 0。

5.3 跨进程独立重放

每域 index：

0, 4, 8, 12, 16, 20, 24, 28

只跑 T0 × 四条件：

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

沿用前序四本账：

代码抽取是否成功；
Python AST 是否可解析；
sandbox 是否真正执行；
tests 是否通过。

固定 sandbox：

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。报告失败类型：

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 上计算右减左：

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 或主指标。

任何偏离必须在结果审计中逐项列出；不能静默修订本文件。

13 KiB Raw Blame History Unescape Escape