feat: audit DeepSeek Chat across sources

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
@@ -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>