wuyang/llm-atlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: audit DeepSeek Chat across sources

Browse Source
This commit is contained in:
wuyang
2026-07-30 03:56:55 +08:00
parent 29ceae4e1b
commit 9211333234
24 changed files with 123017 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
research/DEEPSEEK_V2_LITE_CHAT_CROSS_SOURCE_SAMPLING_AUDIT.md
+725
View File
@@ -0,0 +1,725 @@
# DeepSeek-V2-Lite-Chat 跨来源采样审计
> 执行日期：2026-07-30
>
> 协议：`llm-atlas-deepseek-chat-cross-source-sampling-v1`
>
> 模型：`deepseek-ai/DeepSeek-V2-Lite-Chat`
>
> revision：`85864749cd611b4353ce1decdb286193298f64c7`
>
> 预注册：`research/DEEPSEEK_V2_LITE_CHAT_CROSS_SOURCE_SAMPLING_PROTOCOL.md`
>
> 前序：Round 06 单来源 × 八 seed × 八条件采样
## 0. 一句话结论
本轮保持 256 条正式生成的总预算不变，把网格从 Round 06 的：
```text
4 sources × 8 seeds × 8 conditions
```
改成：
```text
16 sources × 4 seeds × 4 conditions
```
结果为：
```text
256 sampled outputs
├─ 250 natural EOS
├─ 6 budget truncated
├─ 247 个不同的完整 token trajectory hashes
├─ Math：47 / 64 strict exact
├─ Code：52 / 64 official tests pass
├─ R0 / R1：63 / 64 同 source-condition 轨迹分叉
└─ 新进程 R0：64 / 64 格的八项合同字段 exact
```
最重要的不是总正确数下降，而是总数背后的题目异质性终于可见：
```text
Math tasks：14 / 16 · 16 / 16 · 8 / 16 · 9 / 16
Code tasks：16 / 16 · 8 / 16 · 12 / 16 · 16 / 16
```
Round 06 的 Math `62 / 64` 与 Code `63 / 64` 各来自同一道题的重复采样，不能代表
64 道独立任务。本轮也仍不是完整 benchmark；它只把覆盖单位从每域 1 条扩大到每域
4 条，并第一次允许我们描述这 4 条 source 之间的离散性。
---
## 1. 这轮修复的统计对象错误
### 1.1 seed 是题内重复，不是新题
对固定 Math source 抽 64 个 seed，能够回答：
- 同一道题的有限采样轨迹怎样分叉；
- 这道题的任务结果是否对 seed 敏感；
- 固定 seed 与执行环境时能否复跑出同一轨迹。
它不能回答：
- 模型在 64 道不同 Math 题上的能力；
- source 换成另一题后，条件方向是否保留；
- 这道题是否容易、典型或能代表 GSM8K；
- 一个由 seed 数制造的窄区间是否具有 benchmark 意义。
本轮因此冻结：
```text
主要覆盖单位：source
source 内重复：seed
```
所有方向先在每条 source 内，由四个 seed 的 cell summary 计算；然后只描述四条
source 的正、零、负方向数量。没有把题内 seed 当作独立 source。
### 1.2 为什么仍保留 micro total
`47 / 64` 与 `52 / 64` 仍有用，因为它们精确描述这份固定网格中通过的输出数。但它们
必须与逐题矩阵一起展示：
```text
micro total
≠ 题目难度分布
≠ benchmark accuracy
≠ population estimate
```
### 1.3 本轮不是盲确认
`period` 是在看到 Round 06 结果后选出的定向 follow-up：上一轮句点格在单来源上出现
明显的长度收缩与轨迹集合变化。因此：
- 本轮可以检查前序方向在新增 source 上是否保留；
- 不能称为完全独立、未见结果的 confirmatory experiment；
- 不能从 `11 / 16` 同向构造事后显著性故事。
---
## 2. 冻结执行合同
### 2.1 模型与软件
| 对象 | 冻结值 |
|---|---|
| checkpoint | `deepseek-ai/DeepSeek-V2-Lite-Chat` |
| revision | `85864749cd611b4353ce1decdb286193298f64c7` |
| dtype | BF16 |
| attention | eager |
| PyTorch | `2.11.0+cu128` |
| Transformers | `4.41.2` |
| CUDA placement | embedding + layers 0–23 |
| CPU placement | layers 24–26 + final norm + `lm_head` |
| padding | left padding；`PAD=EOS`；padding mask 为 0 |
| cache | `use_cache=true` |
CPU offload 是本机执行拓扑，不是模型结构或能力属性。
### 2.2 解码参数
固定 revision 的官方 `generation_config.json` 给出：
```text
do_sample = true
temperature = 0.3
top_p = 0.95
```
正式执行显式传入：
```text
do_sample = true
temperature = 0.3
top_p = 0.95
top_k = 0
max_new_tokens = 512
use_cache = true
```
`top_k=0` 用于关闭 Transformers 通用默认 top-k，不是额外的 checkpoint 作者结论。
### 2.3 四格条件
```text
s0_eos
s1_eos
s0_period
s1_period
```
- `s0/s1`：system off/on；
- `eos`：官方 assistant 历史边界；
- `period`：把该位置的 EOS 单 ID 替换为普通句点 ID 13。
句点格是单 ID 反事实，不是官方有效聊天序列。每个 source × replicate 的四格放在同一个
batch，行顺序固定。
### 2.4 四个 seed
| replicate | base seed |
|---:|---:|
| R0 | 2,101,325,316 |
| R1 | 2,511,573,438 |
| R2 | 1,677,220,094 |
| R3 | 2,412,346,607 |
base seed 在结果之前由协议字符串的 SHA-256 派生。每条 source 再从 base seed 与
source ID 派生 run seed。四行共享 batch seed 与随机调用时序，但各行消费不同 RNG
子流，因此仍是：
```text
batch-seed aligned
≠ common-random-number paired
```
本轮不报告 paired p-value。
---
## 3. source 选择与输入身份
source 不是按 Round 06 的正确率、完成率或文本质量挑选，而是来自已经冻结的公开语料
选择合同：
```text
sample salt = llm-atlas-deepseek-routing-template-control-v1
每域按 SHA-256 selection_rank 排序，取 within_domain_index 0–3
```
### 3.1 四域各四条
| domain | index 0 | index 1 | index 2 | index 3 |
|---|---|---|---|---|
| English | WikiText `0443` | `0030` | `2909` | `2746` |
| Chinese | TNEWS `4855` | `8935` | `3448` | `1059` |
| Code | HumanEval `31` | `44` | `133` | `23` |
| Math | GSM8K `1069` | `1228` | `0144` | `1251` |
### 3.2 prompt hash 闸门
本轮的：
```text
16 sources × 4 conditions = 64 prompt cells
```
与 Round 05 已执行的对应输入逐格比较：
```text
64 / 64 prompt token SHA-256 exact
```
HumanEval canonical solution/tests 与 GSM8K gold 只在生成冻结后进入独立 evaluator，
从未进入模型 prompt。
---
## 4. smoke 与正式执行
### 4.1 16-token smoke
```text
16 sources × R0/R1 × 4 conditions = 128 short outputs
16 sources × R0 replay × 4 conditions = 64 replay outputs
```
| 闸门 | 结果 |
|---|---:|
| prompt hash exact | 64 / 64 |
| R0 同进程重放全合同 exact | 64 / 64 |
| R0/R1 可比格 | 64 |
| R0/R1 trajectory 分叉 | 34 / 64 |
| OOM / NaN / exception | 0 |
16-token smoke 只检查执行合同，没有进入正式统计。
### 4.2 正式网格
```text
16 sources
× 4 seeds
× 4 conditions
× 512 new-token cap
= 256 sampled outputs
```
| 检查 | 结果 |
|---|---:|
| sources | 16 |
| sources / domain | 4 |
| conditions / source | 4 |
| seeds / source-condition | 4 |
| total outputs | 256 |
| missing / duplicate cells | 0 |
| prompt hash exact | 64 / 64 |
执行记录：
| 指标 | 值 |
|---|---:|
| generation seconds | `3,520.086` |
| peak CUDA allocated | `29,694,417,408 bytes` |
| unique full trajectory hashes | `247 / 256` |
| R0/R1 trajectory different | `63 / 64` |
这里的耗时属于 CPU-offloaded eager 机制审计，不是服务吞吐 benchmark。
---
## 5. stopping 与轨迹总账
| 指标 | 结果 |
|---|---:|
| natural EOS | 250 / 256 |
| budget truncated | 6 / 256 |
| unique full token trajectory hashes | 247 / 256 |
| R0/R1 comparable cells | 64 |
| R0/R1 different trajectories | 63 |
`247 unique` 只说明完整 token ID 序列的 SHA-256 不同，不说明存在 247 种语义、策略或
推理方法。
高 EOS 率也不等于高正确率：
```text
Math 的 17 条失败全部 natural EOS
Code 有自然 EOS 的 runtime / assertion failure
```
因此仍按四张账处理：
```text
stopping
→ task terminal
→ evaluator coverage
→ correctness
```
---
## 6. Math：47 / 64 怎样分布
独立 evaluator 使用 GSM8K 官方 gold，抽取最终数值；严格成功要求：
```text
自然完成
+ evaluator covered
+ predicted numeric answer == gold numeric answer
```
### 6.1 4 tasks × 4 conditions
| source | S0·EOS | S1·EOS | S0·句点 | S1·句点 | total |
|---|---:|---:|---:|---:|---:|
| GSM8K/1069 | 3/4 | 4/4 | 3/4 | 4/4 | 14/16 |
| GSM8K/1228 | 4/4 | 4/4 | 4/4 | 4/4 | 16/16 |
| GSM8K/0144 | 2/4 | 2/4 | 3/4 | 1/4 | 8/16 |
| GSM8K/1251 | 1/4 | 4/4 | 1/4 | 3/4 | 9/16 |
总计：
```text
47 / 64 strict exact
```
### 6.2 这张矩阵教会什么
同样是预先冻结的 GSM8K source：
- `/1228` 在 16 次生成中全对；
- `/0144` 只有 8 / 16；
- `/1251` 只有 9 / 16；
- `/1069` 的 14 / 16 更接近 Round 06 单题高正确率。
所以 Round 06 的 `62 / 64` 首先是 `/1069` 这一道题的局部性质，不能推广成模型的
GSM8K 采样正确率。
### 6.3 source-blocked task contrast
system main effect 的四条 source 方向：
```text
2 positive · 1 zero · 1 negative
```
句点减 EOS 的 main effect：
```text
0 positive · 3 zero · 1 negative
```
interaction：
```text
0 positive · 2 zero · 2 negative
```
这些是固定四题的描述量，不是总体效应。
### 6.4 失败身份
Math 有 17 条 strict failure：
- `/1069`：2；
- `/0144`：8；
- `/1251`：7；
- `/1228`：0。
17 条全部自然 EOS，全部为 evaluator 已覆盖但最终数值与 gold 不同。失败不是正则抽取器
无法找到答案，也不是长度上限截断。
---
## 7. Code：52 / 64 怎样分布
生成完成后，独立 evaluator：
1. 抽取 Python candidate；
2. 做 AST parse；
3. 在固定容器中执行 HumanEval official tests；
4. 记录 passed、runtime error、assertion failed；
5. 以 candidate/test/harness hashes 做安全缓存。
### 7.1 沙箱合同
| 对象 | 值 |
|---|---|
| image | `python:3.11-alpine@sha256:25976e9d…7702a4` |
| network | none |
| filesystem | read-only |
| user | `65534:65534` |
| capabilities | all dropped |
| no new privileges | true |
| memory / swap | 256 MiB / 256 MiB |
| pids | 64 |
| cpus | 0.5 |
| timeout | 5 seconds |
| unique code cache entries | 47 |
| cache hits | 17 |
64 / 64 candidates 完成 AST 检查与执行身份记录。
### 7.2 4 tasks × 4 conditions
| source | S0·EOS | S1·EOS | S0·句点 | S1·句点 | total |
|---|---:|---:|---:|---:|---:|
| HumanEval/31 | 4/4 | 4/4 | 4/4 | 4/4 | 16/16 |
| HumanEval/44 | 2/4 | 1/4 | 1/4 | 4/4 | 8/16 |
| HumanEval/133 | 4/4 | 4/4 | 4/4 | 0/4 | 12/16 |
| HumanEval/23 | 4/4 | 4/4 | 4/4 | 4/4 | 16/16 |
总计：
```text
52 / 64 official tests pass
```
### 7.3 总 interaction 为 0，却不代表每题为 0
Code strict success 的 source-level interaction：
| source | interaction |
|---|---:|
| HumanEval/31 | 0 |
| HumanEval/44 | +1.0 |
| HumanEval/133 | −1.0 |
| HumanEval/23 | 0 |
| domain mean | 0 |
这是本轮最清楚的聚合陷阱：
```text
domain mean = 0
```
不是“每道题都没有 interaction”，而是 `/44` 与 `/133` 正负完全抵消。
### 7.4 失败身份
12 条 Code strict failure：
```text
HumanEval/44
├─ 5 runtime_error
└─ 3 assertion_failed
HumanEval/133
└─ 4 assertion_failed（全部 s1_period）
```
其中只有 1 条属于 budget-truncated unresolved；其余失败不能归因于 512-token 上限。
AST 合法、自然 EOS 或说明流畅都不能替代 official tests。
---
## 8. 句点是否普遍缩短生成
每条 source 内先计算：
```text
period main
= mean(S0·period, S1·period)
− mean(S0·EOS, S1·EOS)
```
负数表示句点格更短。
### 8.1 四域方向
| domain | shorter sources | domain mean | source median |
|---|---:|---:|---:|
| English | 1 / 4 | −8.5 | +21.2 |
| Chinese | 3 / 4 | −13.9 | −13.0 |
| Code | 4 / 4 | −130.0 | −166.1 |
| Math | 3 / 4 | −19.8 | −9.6 |
| total | 11 / 16 | — | — |
### 8.2 English 直接修正 Round 06 的单来源印象
| source | period − EOS mean tokens |
|---|---:|
| WikiText/0443 | −121.0 |
| WikiText/0030 | +44.5 |
| WikiText/2909 | +41.0 |
| WikiText/2746 | +1.375 |
如果只看 Round 06 的 `/0443`，会写成：
```text
句点大幅缩短 English 输出
```
加入三条预先冻结的 English source 后：
```text
1 条更短
3 条更长
domain mean 仍是 −8.5
source median 却是 +21.2
```
均值与多数方向相反，是因为 `/0443` 的 `−121` 足以压过另外三条正值。这正是为什么
本轮在前端同时展示四个 source 点、均值和中位数。
### 8.3 其余三域
Chinese：
```text
+0.375 · −30.0 · −7.5 · −18.5
```
Code：
```text
−178.625 · −164.375 · −167.875 · −9.0
```
Math：
```text
−4.625 · −68.75 · +8.875 · −14.5
```
Code 的四条 source 同向，是当前固定网格里最一致的长度模式；仍不能写成对
HumanEval 总体或所有代码任务的普遍规律。
---
## 9. system main effect 也依赖 source
平均生成长度的 system main effect：
| domain | negative | zero | positive | mean |
|---|---:|---:|---:|---:|
| English | 4 | 0 | 0 | −137.0 |
| Chinese | 2 | 0 | 2 | −6.9 |
| Code | 4 | 0 | 0 | −143.3 |
| Math | 3 | 0 | 1 | −13.6 |
English 与 Code 在这四条 source 上都呈 system-on 更短；Chinese 则正负各半。不能把
一个域的方向复制到另一个域。
自然 EOS 已接近天花板：
- system-on 提升 EOS 的 source：English 2 / 4；
- Chinese、Code、Math：均 0 / 4；
- 这主要说明多数 cell 已经 4 / 4 EOS，不是 system 没有其它行为差异。
---
## 10. source 间与 source 内离散
每个 domain-condition 同时保存：
```text
within-source seed length range
between-source mean length range
within-source seed success range
between-source success-rate range
```
这些量回答不同问题：
- within-source：固定一道题，四个 seed 能让长度或成功怎样变化；
- between-source：固定域与 condition，四道题的均值或成功率跨度多大。
它们没有被压成一个“哪种随机性更大”的全局数字，因为：
- length 与 correctness 量纲不同；
- 四条 source 太少，不适合稳定估计方差分量；
- seed 并不是逐行 common random numbers；
- source 不是从总体随机抽样。
前端允许逐域逐 condition 检查两个范围，但不输出伪精确的总体方差比例。
---
## 11. 独立新进程复跑
正式生成后，全新进程只重跑：
```text
16 sources × R0 × 4 conditions = 64 outputs
```
逐格比较八项预注册字段：
| 字段 | exact |
|---|---:|
| run seed | 64 / 64 |
| prompt hash | 64 / 64 |
| complete generated token IDs | 64 / 64 |
| decoded text | 64 / 64 |
| EOS state | 64 / 64 |
| truncation state | 64 / 64 |
| CPU RNG pre-state hash | 64 / 64 |
| CUDA RNG pre-state hash | 64 / 64 |
因此这份固定合同同时满足：
```text
不同 seed：63 / 64 同格轨迹分叉
相同合同：64 / 64 新进程轨迹 exact
```
“采样会变化”和“采样可复现”并不矛盾。
exact replay 不承诺跨 PyTorch、Transformers、CUDA kernel、硬件或 batch 合同复现。
---
## 12. 工件与 hash chain
| 工件 | bytes | SHA-256 |
|---|---:|---|
| formal sampling | 1,980,601 | `f013132485f27adce008f03f781bed9982efc0d7939f13faede01c9f6f3d7f7c` |
| independent evaluation | 370,580 | `e88b274599fc5951561f9e5e7438fb4d6d25f341ae3bc4a2c4121877a0db8975` |
| fresh-process R0 rerun | 597,066 | `143dc9d0f7c914db4781e36b1401cdc9fbc2971a0dca71188bab0f8cedb002a6` |
| reproduction comparison | 30,037 | `ec4a47894953f5d73bb62211b588632ef7032da0e915218992b7fc3ef9c2a556` |
| source-blocked analysis | 168,001 | `d0dece388998fee419d34ff33f140695a9fedef6e79799cdf42eb283b047bc84` |
前端压缩工件：
```text
src/data/deepseek-v2-lite-chat-cross-source-sampling-compact.json
SHA-256 d0ab65646c6119bdeafeb451103dc6afebff3624a1e05f13a45a52ad965be1af
```
builder 在生成前端数据之前验证：
1. evaluator 输入 hash 指向正式 sampling；
2. reproduction 的 formal/rerun hashes 指向对应文件；
3. analysis 的三项输入 hashes 全部一致；
4. 64 格八项复现字段全部 exact；
5. `16 × 4 × 4 = 256` 网格合同成立。
---
## 13. 一手来源与实现身份
### 13.1 官方 checkpoint 配置
- DeepSeek-V2-Lite-Chat generation config：
<https://huggingface.co/deepseek-ai/DeepSeek-V2-Lite-Chat/blob/main/generation_config.json>
这里只把固定 revision 文件中的 `.3/.95` 记为作者发布配置；`top_k=0` 是本实验为关闭
Transformers 通用 top-k 而显式加入的执行参数。
### 13.2 nucleus sampling
- Holtzman et al., *The Curious Case of Neural Text Degeneration*：
<https://arxiv.org/abs/1904.09751>
本轮使用 nucleus sampling 的有限样本，不声称恢复完整生成分布。
### 13.3 任务来源
- Chen et al., *Evaluating Large Language Models Trained on Code*：
<https://arxiv.org/abs/2107.03374>
- Cobbe et al., *Training Verifiers to Solve Math Word Problems*：
<https://arxiv.org/abs/2110.14168>
HumanEval official tests 与 GSM8K gold 只服务于本轮固定四题的独立评测，不生成
benchmark 总体分数。
---
## 14. 可以说与不能说
### 可以说
- 在固定 16 条 source 的网格中，250 / 256 条生成自然 EOS；
- 247 / 256 条完整 token trajectories 唯一；
- R0/R1 在 63 / 64 同 source-condition cells 分叉；
- 新进程 R0 在 64 / 64 格、八项预注册字段 exact；
- 四道 Math 的 strict pass 从 8 / 16 到 16 / 16；
- 四道 Code 的 tests pass 从 8 / 16 到 16 / 16；
- 句点在 11 / 16 条 source 上缩短平均生成长度；
- English 的域均值与多数 source 方向相反；
- Code 的 task interaction 域均值为 0，但两条非零 source 正负抵消。
### 不能说
- DeepSeek-V2-Lite-Chat 的 GSM8K 准确率是 47 / 64；
- DeepSeek-V2-Lite-Chat 的 HumanEval pass@1 是 52 / 64；
- 16 条 source 随机代表四个数据集总体；
- 4 个 seed 是 4 道独立题；
- 11 / 16 构成总体显著性；
- period 是官方有效聊天边界；
- period 普遍缩短所有 English、Math 或中文输出；
- domain mean 为 0 说明每条 source 都没有效应；
- natural EOS、AST parse 或可执行等同于正确；
- exact replay 会跨软件、硬件和 batch 合同自动成立。
---
## 15. 下一步
本轮修复了“单题多 seed 冒充多题覆盖”，但仍只有每域 4 条 source。下一轮优先级应是：
1. 把任务覆盖扩大到足以报告 task-level bootstrap，并在结果前冻结抽样框；
2. 为每条 source 使用独立 per-row RNG stream，构造真正可解释的 common-random-number
条件对；
3. 分离 ordinary boundary token 的词法身份、频率与位置作用，不只复查句点；
4. 对 HumanEval/44 与 /133 的相反 interaction 做预注册 failure taxonomy；
5. 在足够 source 覆盖后，再决定是否值得进行干预式 mediation；
6. 继续保持生成、evaluator、统计分析与 reproduction 四套工件分离。
本轮已经回答的是：
```text
同样的 sampling 配方与输入干预，换一条 source 后，方向会不会变？
```
答案是：
```text
会，而且聚合均值有时会与多数 source 方向相反。
```
research/DEEPSEEK_V2_LITE_CHAT_CROSS_SOURCE_SAMPLING_PROTOCOL.md
+454
View File
@@ -0,0 +1,454 @@
# DeepSeek-V2-Lite-Chat 跨来源采样协议
> 状态：已按预注册协议执行；正式结果见
> `research/DEEPSEEK_V2_LITE_CHAT_CROSS_SOURCE_SAMPLING_AUDIT.md`
>
> 注册日期：2026-07-30
>
> 协议 ID：`llm-atlas-deepseek-chat-cross-source-sampling-v1`
>
> 模型：`deepseek-ai/DeepSeek-V2-Lite-Chat`
>
> revision：`85864749cd611b4353ce1decdb286193298f64c7`
>
> 前序实验：Round 06 单来源 × 八 seed × 八条件采样
## 0. 这一轮补什么，不补什么
Round 06 固定四条 source，每条 source 在八个 seed 和八种边界条件下生成：
```text
4 sources × 8 seeds × 8 conditions = 256 outputs
```
它证明了两件看似矛盾但可以同时成立的事：
1. 不同 seed 会让同一格的 sampled trajectory 分叉；
2. 固定 checkpoint、输入、batch 行顺序、软件与 seed 后，同一 trajectory 可以跨进程逐
token 复现。
但 Math 和 Code 各只有一道题。即使那一道题有 64 个 sampled outputs，也仍然只有一个
任务对象。把 64 个 seed 重复当成 64 道独立 benchmark 题，会制造伪样本量。
Round 07 因此把预算从“同题更多 seed”移动到“更多预先选定的 source”：
```text
16 sources × 4 seeds × 4 conditions = 256 outputs
```
本轮第一次允许描述固定 4 道 Math / 4 道 Code 之间的离散性，但仍不是完整
GSM8K/HumanEval benchmark，更不是模型总体能力估计。
---
## 1. 研究问题与证据层级
### 1.1 主要问题
在固定 source selection、官方 sampling 参数与四行 batch 合同下：
1. Round 06 观察到的 completion-length / EOS 模式能否在另外三条同域 source 上出现？
2. Math / Code 的 pass count 是否由单一道题主导？
3. `system off/on × EOS/period` 四格的方向是否跨 source 一致，还是明显依赖题目？
4. source 间差异与 source 内 seed 差异，哪一个在当前固定网格中更大？
### 1.2 探索与确认的边界
选择 `period` 作为唯一 ordinary-token 对照，受 Round 06 的结果启发：它在单来源运行中
显示了明显的输出长度与 exact-trajectory 收缩。因此本轮是**定向复查**，不是完全独立、
未见前序结果的 confirmatory experiment。
本轮不会：
- 把 Round 06 与 Round 07 合并后计算“独立复现率”；
- 把四道题的方向一致写成总体显著性；
- 根据本轮结果继续替换 source、condition 或 seed；
- 把 period 序列称为官方有效聊天格式；
- 把题内四个 seed 当成四道独立题。
---
## 2. 模型、依赖与解码合同
继承冻结对象：
- 官方 SFT Chat checkpoint；
- revision `85864749cd611b4353ce1decdb286193298f64c7`；
- checkpoint 12 个文件及各自 SHA-256；
- Transformers `4.41.2`；
- PyTorch `2.11.0+cu128`；
- BF16、官方 remote modeling code、eager attention；
- CUDA resident：embedding + layers 0–23；
- CPU offload：layers 24–26 + final norm + `lm_head`；
- `PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True`；
- GPU static placement `28GiB`、CPU placement `80GiB`；
- 左填充，`PAD=EOS`，padding mask 为 0；
- `use_cache=true`、统一 `max_new_tokens=512`。
固定 revision 的官方 `generation_config.json` 给出：
```text
do_sample = true
temperature = 0.3
top_p = 0.95
bos_id = 100000
eos_id = 100001
```
正式执行显式传入：
```text
do_sample = true
temperature = 0.3
top_p = 0.95
top_k = 0
max_new_tokens = 512
use_cache = true
```
`top_k=0` 用于关闭 Transformers 通用默认 top-k；它不是 checkpoint 文件中的额外作者
结论。
---
## 3. source 如何在结果之前冻结
source 不按 Round 06 的正确率、完成率或文本质量挑选。它们取自已冻结的
`deepseek-v2-lite-routing-special-token-family-control.json`：
```text
sample salt = llm-atlas-deepseek-routing-template-control-v1
每域按 SHA-256 selection_rank 排序，取 within_domain_index 0–3
```
### 3.1 English
| index | source ID |
|---:|---|
| 0 | `wikitext2/raw-validation/0443` |
| 1 | `wikitext2/raw-validation/0030` |
| 2 | `wikitext2/raw-validation/2909` |
| 3 | `wikitext2/raw-validation/2746` |
### 3.2 Chinese
| index | source ID |
|---:|---|
| 0 | `tnews/test/4855` |
| 1 | `tnews/test/8935` |
| 2 | `tnews/test/3448` |
| 3 | `tnews/test/1059` |
### 3.3 Code
| index | source ID |
|---:|---|
| 0 | `HumanEval/31` |
| 1 | `HumanEval/44` |
| 2 | `HumanEval/133` |
| 3 | `HumanEval/23` |
### 3.4 Math
| index | source ID |
|---:|---|
| 0 | `gsm8k/test/1069` |
| 1 | `gsm8k/test/1228` |
| 2 | `gsm8k/test/0144` |
| 3 | `gsm8k/test/1251` |
这些正是 Round 05 greedy completion 已执行的 16 条 source。本轮在加载模型前，必须验证
16 × 4 = 64 个 prompt token hashes 与 Round 05 对应格逐格 exact。
---
## 4. 四格因子与 batch 合同
固定四格：
```text
s0_eos, s1_eos, s0_period, s1_period
```
其中：
- `s0/s1`：system off/on；
- `eos`：官方 assistant 历史边界；
- `period`：把该位置的 EOS 单 ID 替换为普通句点 ID 13；
- system 文本、one-shot 内容、target source、角色词头、目标位置与 prompt 其余 token 均继承
前序协议。
每个 source × replicate 的四格在同一个 batch，行顺序永久固定。四行 batch 与 Round 06
的八行 batch 不同，因此即使复用相同 base seed，也不应期待 trajectory exact；本轮使用
新协议派生的新 seed，避免把两种 batch 合同伪装成直接重复。
Transformers `4.41.2` 对整个 batch 调用一次 `torch.multinomial`，不接受逐行
`Generator`。四格只共享 batch seed 与调用时序，每行消费不同 RNG 子流，因此仍是：
```text
batch-seed aligned
≠ common-random-number paired
```
---
## 5. seed 冻结
四个 base seed 由以下字符串做 SHA-256，取前 4 bytes big-endian unsigned integer：
```text
llm-atlas-deepseek-chat-cross-source-sampling-v1/seed/{index}
```
固定结果：
| replicate | base seed |
|---:|---:|
| R0 | 2,101,325,316 |
| R1 | 2,511,573,438 |
| R2 | 1,677,220,094 |
| R3 | 2,412,346,607 |
实际 run seed：
```text
SHA256(
protocol_id + "/run\0"
+ decimal(base_seed)
+ "\0"
+ source_id
)[0:8] big-endian
modulo (2^63 - 1)
```
每次 source × replicate batch 前：
```python
torch.manual_seed(run_seed)
torch.cuda.manual_seed_all(run_seed)
```
同时记录 CPU / CUDA RNG state 的执行前后 SHA-256。
---
## 6. 输入文件身份
| 输入 | SHA-256 |
|---|---|
| source selection contract | `c372c1b03a8b15f615b54ded5d9257a8fc2cdb7728001735d3d4c1d8534af5bf` |
| Round 05 greedy baseline | `6af40512c5868caab0ef58356aaa7728384f2b7acc7c502aa89478fdf5a2a468` |
| HumanEval gzip | `b796127e635a67f93fb35c04f4cb03cf06f38c8072ee7cee8833d7bee06979ef` |
| GSM8K test JSONL | `3730d312f6e3440559ace48831e51066acaca737f6eabec99bccb9e4b3c39d14` |
| TNEWS test JSONL | `74f199325768fbf2d6020711edfff23d653e99e0f8ac31a126a54db29c3a0ca8` |
| TNEWS archive | `77c476e70cfe0b014a81b84c6e1db2142a8a2f52f4ae0a8216aa75e673933462` |
| WikiText-2 validation parquet | `204929b7ff9d6184953f867dedb860e40aa69c078fc1e54b3baaa8fb28511c4c` |
HumanEval `canonical_solution` / tests 与 GSM8K answer 只进入生成后的独立 evaluator，绝不
进入模型 prompt。
---
## 7. 执行网格与闸门
### 7.1 16-token smoke
```text
16 sources × R0/R1 × 4 conditions × 16 tokens = 128 short outputs
16 sources × R0 replay × 4 conditions × 16 tokens = 64 replay outputs
```
通过条件：
1. 64 / 64 prompt hashes 与 Round 05 exact；
2. 128 条 smoke 无 OOM、NaN 或 exception；
3. R0 同进程 replay 的 run seed、prompt hash、token IDs、text 与 stop state 64 / 64 exact；
4. R0/R1 的 64 个同 source-condition cells 至少一格 trajectory 分叉；
5. 正式参数确实是 `.3/.95/top-k 0`。
smoke 输出不进入正式统计。
### 7.2 正式网格
```text
16 sources
× 4 seeds
× 4 conditions
× 512 new-token cap
= 256 sampled outputs
```
source 顺序固定为 English → Chinese → Code → Math，各域按 `within_domain_index` 升序；
replicate 固定 R0 → R3；每个 replicate 内行顺序固定为四格顺序。不能根据中间输出提前
停止或只续写截断格。
### 7.3 新进程复跑
正式完成后重新启动 Python、重新加载模型，只复跑 R0：
```text
16 sources × 1 seed × 4 conditions = 64 outputs
```
逐格核对：
- run seed；
- prompt token hash；
- 完整 generated token IDs；
- decoded text；
- EOS state；
- truncation state；
- CPU RNG pre-state hash；
- CUDA RNG pre-state hash。
只能写“64 / 64 R0 cells independently reproduced”，不能写 256 / 256。
---
## 8. 独立 evaluator
仍把四张账分开：
1. stopping：natural EOS / budget truncated；
2. task terminal：明确答案、闭合 code fence 或 tests pass；
3. evaluator coverage：数值可抽取，或代码 AST + sandbox 已执行；
4. correctness：GSM8K strict numeric exact / HumanEval official tests pass。
HumanEval 每个独特 candidate 使用固定镜像：
```text
python:3.11-alpine@
sha256:25976e9d34a0fab1f278cae931f34c8303d97bf0c0d7f85b6b4dcf641d7702a4
```
沙箱：
```text
network none · read-only filesystem · user 65534:65534
cap-drop ALL · no-new-privileges · no host mounts
256 MiB memory/swap · pids 64 · cpus .5 · timeout 5s
```
完全相同的 candidate + task + tests + harness 可以复用 execution cache，但保留每个生成格
自己的 evaluator row。
---
## 9. 预注册统计
### 9.1 source × condition
每个集合有 4 个 seed，报告：
- natural EOS / 4；
- truncated / 4；
- generated length mean / min / max；
- unique full-token trajectory hashes / 4；
- 六对 seed pair 的 token similarity；
- Math：4 个抽取答案、严格正确数、唯一绝对多数答案（若存在）；
- Code：AST、executed、official tests pass、observed any-pass。
`observed any-pass` 只表示当前四次抽样至少一次通过，不称为标准 HumanEval pass@4。
### 9.2 domain × condition
每个 domain 的四条 source 等权，报告：
- micro count：16 个 outputs 的合计；
- source macro mean：先算每条 source 的四 seed 比例，再对四条 source 等权；
- source range：四条 source 的最小/最大；
- 4 × 4 source-condition 矩阵。
因为每条 source 的 seed 数相同，micro 与 macro 点估计可能数值相同；两者仍分开呈现，
避免未来不等重复数时悄悄改变权重。
### 9.3 source-blocked 四格 contrast
对每条 source 先算四格 cell mean，再形成描述性 contrast：
```text
system main =
mean(s1_eos, s1_period) - mean(s0_eos, s0_period)
boundary main =
mean(s0_period, s1_period) - mean(s0_eos, s1_eos)
interaction =
(s1_period - s1_eos) - (s0_period - s0_eos)
```
分别对：
- natural EOS rate；
- generated-token length；
- Math / Code fixed-budget success；
- Math / Code strict-complete success。
每个 domain 展示四条 source 的 contrast dots、median、min、max 与正/零/负方向计数。不算
p-value，不给总体置信区间。
### 9.4 两层离散性
对 generated-token length 与 task success：
- `within-source seed range`：同 source-condition 四 seed 的范围；
- `between-source cell-mean range`：同 domain-condition 四条 source 均值的范围。
这只是固定网格中的描述，不作随机效应方差分解，也不把四条 source 当作领域总体随机样本。
### 9.5 前序方向复查
只针对 Round 06 已观察到的方向登记：
```text
period 相对 EOS 是否缩短 mean generated tokens？
system on 相对 off 是否提高 natural EOS rate？
```
按 source 报告方向，不因结果改写为“改善质量”。Math / Code correctness 单独展示，不能由
长度或 EOS 代替。
---
## 10. 失败与修订规则
- smoke 前可修实现错误；正式 source/seed/condition/metrics 不随输出改动；
- 正式 JSON 完整写出前失败，整轮重新开始，不保留“表现较好”的部分 source；
- OOM 优先降低 static GPU placement，并用同 seed smoke 做 placement exact 闸门；
- 不拆四行 batch；拆 batch 或改行顺序意味着新协议；
- evaluator bug 可以修复并重跑 evaluator，但 sampled output 文件冻结；
- 新进程 R0 任一 preregistered 字段不 exact，则结果只作复现失败诊断；
- 某题 evaluator uncovered 仍保留该格，不能删题或换题；
- 沙箱超时、AST 失败、assertion failure 与 runtime error 分开记录。
---
## 11. 永久禁止的结论
- 4 道 GSM8K / HumanEval 代表完整 benchmark；
- 64 个 task-domain outputs 等于 64 道独立题；
- 4 seeds 足以估计完整生成分布；
- observed any-pass 等于标准 pass@4；
- period 是官方有效聊天边界；
- system 或 period 让模型“更聪明”“更稳定”；
- natural EOS、语义终点、可评测与正确是同一个指标；
- 四条 source 的方向计数是总体显著性；
- batch-seed aligned 是 common-random-number pair；
- exact same-seed replay 可跨软件、kernel 或硬件保证；
- CPU-offloaded eager 延迟等于生产服务吞吐；
- 输出关联已经定位到 hidden-state / router mediation。
---
## 12. 一手来源
- DeepSeek-V2-Lite-Chat pinned `generation_config.json`：
<https://huggingface.co/deepseek-ai/DeepSeek-V2-Lite-Chat/blob/85864749cd611b4353ce1decdb286193298f64c7/generation_config.json>
- Holtzman et al., *The Curious Case of Neural Text Degeneration*：
<https://arxiv.org/abs/1904.09751>
- Chen et al., *Evaluating Large Language Models Trained on Code*：
<https://arxiv.org/abs/2107.03374>
- Cobbe et al., *Training Verifiers to Solve Math Word Problems*：
<https://arxiv.org/abs/2110.14168>
- OpenAI HumanEval pinned repository：
<https://github.com/openai/human-eval/tree/6d43fb980f9fee3c892a914eda09951f772ad10d>