# 复现日志

> 每条都记 **做了什么 / 验收到什么程度 / 踩了什么坑**。
> 只写有证据的部分；没验证的不许写成"完成"。

---

## 2026-10-08 · 环境勘察与启动

### 机器事实（实测，不是推断）

| 项 | 值 | 怎么测的 |
|---|---|---|
| GPU | AMD Radeon 8060S (gfx1151)，**99.7 GB** 统一内存，20 CU | `torch.cuda.get_device_properties(0)` |
| torch | `2.12.0a0+rocm7.13.0a20260313` | 装于 `C:\ana\envs\comfyui` |
| **torch.distributed** | **`is_available() == False`** —— 构建里没编 | `import torch.distributed as dist` |
| transformers | 5.9.0（装进本项目 venv） | `pip install` |
| 解释器 | **`C:\ana\envs\comfyui\python.exe`**（用户指定用 comfyui 环境） | 见下方"环境变更" |

### 环境变更记录（装进 comfyui 环境，便于回滚）

按用户要求，本项目直接用 **comfyui 环境**跑，不另起环境。为此装进 `C:\ana\envs\comfyui`：

```
transformers          4.57.6  ->  5.9.0        （multimolecule 的硬需求：
huggingface-hub       0.36.2  ->  1.33.0        它 import transformers.utils.output_capturing，
hf-xet                 1.5.2  ->  1.7.0         4.57 里没有这个模块）
新增：peft 0.21.2 · accelerate 1.15.0 · sentence-transformers 6.1.0 · rouge-score 0.1.2 · nltk 3.10.3
```

`.venv`（在项目目录下，`--system-site-packages` 继承 comfyui 的 torch）保留为备用，
包集合与 comfyui 一致，不动 comfyui。**若 ComfyUI 的自定义节点依赖 transformers 4.x，用 `.venv` 跑本项目。**

### 坑 1：`import multimolecule` 在本机直接不可行

`danling`（MultiMolecule 的运行时依赖）在 import 阶段无条件引用
`torch.distributed.distributed_c10d`、`torch.distributed.tensor`、`dist.ReduceOp`，
而这个 torch 构建**没有分布式后端**。四级连锁失败：

```
ImportError: cannot import name 'dcp' from 'danling.runners.checkpoints.torch_distributed'
ModuleNotFoundError: No module named 'torch._C._distributed_c10d'
AttributeError: module 'torch.distributed' has no attribute 'ReduceOp'
ModuleNotFoundError: No module named 'torch.distributed.tensor.device_mesh'
```

**解法**：`src/rnaqwen/env/shim.py` —— 把缺失符号补成占位符，
并在 `sys.meta_path` **末尾**挂一个 permissive finder（真模块优先，缺的才伪造）。
现在 `from multimolecule.models.rnafm import RnaFmModel, RnaTokenizer` 通过（transformers 5.9.0）。

### 坑 2：网络 —— HF 走得通但慢到不可用，EBI 完全不通

| 通道 | 实测 |
|---|---|
| huggingface.co CDN（`us.aws.cdn.hf.co`） | **0.06 MB/s** |
| hf-mirror.com | 0.06 MB/s（回源到 hf.co，没用） |
| **ModelScope（`cdn-lfs-cn-1.modelscope.cn`）** | **11.2 MB/s** |
| NCBI eutils | 通（esearch / efetch / elink 全 200） |
| rnacentral.org / ftp.ebi.ac.uk / europepmc.org | **SSL EOF / ReadTimeout，全不通** |

推论：
* 权重一律走 ModelScope（`scripts/00b_download_modelscope.py`，并发 + 断点续传）。
* 数据源从 RNAcentral 换成 **NCBI nuccore + pubmed**（差异已写进 README §5）。
* 另外：`huggingface_hub` 走 hf-mirror 会抛
  `FileMetadataError: Distant resource does not seem to be on huggingface.co`
  —— 镜像不给 HEAD 元数据头。别用镜像。

### 坑 3：`urllib`/`requests` 的下载超时用法不一样，且 CDN 会「滴水」

- `urlopen(req, timeout=(20, 120))` 抛
  `TypeError: 'tuple' object cannot be interpreted as an integer`
  —— 元组超时是 `requests` 的用法。四个下载任务全灭了一次。
- 换回 `requests` 之后，**读超时给太长（30s）等于卡死没有出口**：
  CDN 会让连接保持存活但几乎不吐字节，进程静默挂在 0.00 MB/s 上半小时。
  最终解法是 `timeout=(15, 10)`（连接 15s / **读 10s**）＋一个**速率看门狗**
  （45 秒内增量 < 200 KB 就主动断开，带 `Range` 续传重试）。
- 另一个坑：**`Get-ChildItem` 读到的文件大小是缓存的**，明明在下载却一直显示
  旧值，害得我以为卡了三次。改用 Python 的 `os.path.getsize` 才看到真实速率
  （5 个 shard 各 ~2 MB/s，合计 ~10.7 MB/s）。**别用 PowerShell 看下载进度。**

### 坑 4：磁盘写满（Qwen3-8B 下到一半全灭）

`OSError [Errno 28] No space left on device` —— 5 个 shard 同时卡在同一位置反复重试。
C 盘当时只剩 **4.4 GB**（共 918 GB，本来就快满了）。清理：

| 动作 | 释放 |
|---|---|
| 删掉多余的 conda clone `C:\ana\envs\rnaqwen`（我们有 `.venv`，用不到它） | 6.09 GB |
| 清掉 HF 缓存里的 `.incomplete` 残片 | 0.15 GB |
| 删掉 pubmedbert 里冗余的 `pytorch_model.bin`（已与 safetensors 逐位比对一致） | 0.44 GB |

清理后 11.16 GB 可用，15.3 GB 的权重才下得完。
**教训：这台机器 C 盘长期紧张，下大模型前先看 `Get-PSDrive C`。**

### 坑 5：HF 不是慢，是**单连接**被限速

`aria2c -x16 -s16 -k1M` 从 huggingface.co 拉 RNA-FM 的 398 MB：

```
25 秒下完（约 16 MB/s），而单连接只有 0.06 MB/s
```

所以真正的结论不是"HF 不能用"，而是**单连接被掐到 0.06 MB/s，多连接能跑满**。
（ModelScope 单连接就能到 2–11 MB/s，但同样会在并发下载时互相挤。）
以后再遇到"某个源很慢"，先试 `-x16`，别急着换源。

### 坑 6：下载并发多了会互相拖死

5 个下载任务 + 2 个 subagent 同时拉，结果是**所有任务一起停**（每个都显示 0.00 MB/s）。
最后按"一个源最多 5 条流、别再多开进程"来跑才稳定。

### 模型就位情况

| 模型 | 来源 | 状态 |
|---|---|---|
| `Qwen/Qwen3-8B` | ModelScope | 下载中（15.3 GB / 5 shard） |
| `multimolecule/rnafm` | HF（aria2 -x16） | 398 MB，即将完成 |
| `google-bert/bert-base-uncased` | ModelScope `google-bert/bert-base-uncased` | ✅ 441 MB，sha256 全对 |
| `microsoft/BiomedNLP-BiomedBERT-…` | ModelScope | ✅ 见下方说明 |

**PubMedBERT 的一个事实**：上游仓库（HF 和 ModelScope 一致）**根本没有
`model.safetensors`，也没有 `tokenizer.json`** —— 只有 `pytorch_model.bin` + `vocab.txt`。
所以本地这两个文件是**生成的**（safetensors 由 .bin 导出，tokenizer.json 由 vocab.txt 构造），
并已验证：safetensors 与 .bin 前向输出**逐位一致（max|Δ| = 0.0）**。
→ 报告里要写明这一点，别让人以为是从上游拿的原文件。

### 坑 7（最贵的一个）：**静默损坏** —— 大小完全正确，内容是坏的

Qwen3-8B 下完 16.38 GB，`safetensors` 加载成功（399/399 张量全部到位），
但生成出来是乱码：

```
prompt: "Name the four RNA nucleotides, separated by spaces."
sdpa  / bfloat16 -> ',es numpy React sys React matplotlib React React React ...'
eager / bfloat16 -> ',es numpy React sys React matplotlib React React ...'
eager / float32  -> ',es matplotlib React React React React React React ...'
```

三种 attention 后端 × 两种精度**输出同样的乱码** → 不是算子问题，是**权重本身坏了**。

`scripts/00c_verify_models.py` 拿本地 sha256 跟 ModelScope 声明的值对比：

```
model-00005-of-00005.safetensors  1244659840  1244659840  OK  20c2d636... == 20c2d636...
model-00001-of-00005.safetensors  3996250744  3996250744  BAD 8f63b006... != 31d6a825...
model-00002-of-00005.safetensors  3993160032  3993160032  BAD bd732b5f... != 5991236c...
model-00003-of-00005.safetensors  3959604768  3959604768  BAD 52d91d30... != c5185c47...
model-00004-of-00005.safetensors  3187841392  3187841392  BAD 41b73ee3... != b5ee7de7...
```

**4/5 个 shard 坏了，而字节数一个不差。**

成因（复盘）：
1. 这些文件被**多轮续传**拼过 —— 磁盘写满中断 → 换进程重下 → 再断 → 再续；
2. 中途还出现过**两个进程同时写同一个文件**（先起了 26/27 号任务，又起了 29/30 号任务，旧任务没死透）。

`Size` 校验**完全挡不住这种错误**。修复：
* `00b_download_modelscope.py` 改成先写 `.part`、**完整拿到后原子改名**；
* 下完必须跑 `00c_verify_models.py` 对 sha256 —— **不看 sha256 不算下完**。

> 这条要写进开源仓库的 CONTRIBUTING：权重只做 size 校验是危险的，
> 静默损坏的模型会加载成功、跑得动、只是输出垃圾，排查成本极高。

### 坑 8：`aria2c` 会把文件**预分配**成完整大小

aria2 先按最终大小占位，进度只记在 `.aria2` 控制文件里。
我用 `Get-ChildItem` 看到 398.12 MB 就以为下完了，结果 `safetensors` 报
`invalid JSON in header: EOF while parsing a value`。
**判断下载是否完成：看控制文件 / 校验和，不看文件大小。**

### 型号核对：Qwen3-8B 的投影层确实零改动

已下到本地的 `models/Qwen3-8B/config.json`：

```
hidden_size = 4096       num_hidden_layers = 36
vocab_size  = 151936     intermediate_size = 12288
```

与 Llama-3-8B 的 hidden=4096 **逐位相同** → RNA-FM 那条 `640 → 4096` 线性投影
**与原版维度一致，不用改**。这就是选 Qwen3-8B（而不是 Qwen2.5-7B 的 3584）的理由。

> 注意区分：本机 `C:\qwen-api\models\` 下的 `Qwen3.8-27B-*` / `Qwen3.6-35B-A3B-*` 是**别的系列**，
> 不能当底座。复现用的是原始 Qwen3 家族、8B 规模：`Qwen/Qwen3-8B`。

---

## PLAN §7.3 · 评测脚本（**已通过**）

`scripts/03_eval_selfcheck.py`，报告 `reports/eval_selfcheck_bert.json`。

### A 关：ROUGE 对数（自实现 vs Google `rouge_score`）

7 个用例：identical / paraphrase / partial / unrelated / empty / punctuation / numbers

```
-> 最大偏差 0.000e+00（阈值 1e-09）：一致
```

**逐样本完全一致。尺子准了。**

### B 关：语义指标不变量（嵌入 = bert-base-uncased）

```
[high] identical    P=1.0000 R=1.0000 F1=1.0000
[high] paraphrase   P=0.9396 R=0.9396 F1=0.9396
[mid ] partial      P=0.9366 R=0.8748 F1=0.9046
[low ] unrelated    P=0.8004 R=0.8321 F1=0.8159
[ok] identical_ge_0.999 / paraphrase_gt_partial / partial_gt_unrelated / unrelated_lt_0.95
```

### B/C 关：PubMedBERT（`reports/eval_selfcheck_pubmedbert.json`）

A 关同 BERT（7 用例 Δmax = 0.000e+00）。B 关**没过**，C 关过了：

```
identical    P=1.0000 R=1.0000 F1=1.0000
paraphrase   P=0.9938 R=0.9938 F1=0.9938
partial      P=0.9950 R=0.9857 F1=0.9903
unrelated    P=0.9701 R=0.9669 F1=0.9685      <- 比 BERT 的 0.8159 还高

[ok  ] identical_ge_0.999 / paraphrase_gt_partial / partial_gt_unrelated
[FAIL] unrelated_lt_0.95
```

**这个 FAIL 不是 bug，是阈值本身不适用于 PubMedBERT。**
`unrelated_lt_0.95` 是在 BERT 上标定的；而 PubMedBERT 的跨域地板是 0.9518
（§7.3b 实测），**它在数学上不可能满足这条断言**。
C 关同理可信度有限：

```
perfect_100pct   1.0000/1.0000/1.0000   F1=1.0000
half_50pct       0.4800/0.4583/0.4800   F1=0.9907
one_third        0.4800/0.4583/0.4800   F1=0.9907
bare_sequence_like 0.0000/0.0000/0.0000 F1=0.8889   <- 纯 ACGU 乱串也有 0.89
empty            0.0000/0.0000/0.0000   F1=0.0000
-> ROUGE-1 随答案完整度单调：是
```

ROUGE 阶梯正常（1.00 → 0.48 → 0.00）；
但 semantic 那列「50% 答案 0.9907 / 乱码 0.8889」的区分度基本为零。

### C 关：消融阶梯的响应方向

```
variant                   R-1      R-2      R-L   F1@bert
perfect_100pct         1.0000   1.0000   1.0000   1.0000
half_50pct             0.4800   0.4583   0.4800   0.9370
one_third              0.4800   0.4583   0.4800   0.9370
bare_sequence_like     0.0000   0.0000   0.0000   0.2633
empty                  0.0000   0.0000   0.0000   0.0000
-> ROUGE-1 随答案完整度单调：是
```

### 🔎 第一个发现（**后来被部分推翻**）：语义 F1 的"地板很高"

「无关的两段文本」在句子级 max-cosine 下拿到 **F1 = 0.8159**。
当时据此推断分辨率被压缩在 **[0.82, 1.00]**。

> ⚠️ **这个推断后来被证伪了，见 §7.3b。** 0.8159 之所以那么高，是因为
> RNA 与蛋白质晶体学**同属生物医学语域**。换成真正的跨领域配对（RNA vs 经济学/法律/菜谱），
> 同一把尺子立刻掉到 **0.45 左右**。§7.3b 的结论比这里更严重，但方向不同：
> 地板在 BERT 上其实只有 0.52（不是 0.82），真正的病在 PubMedBERT（0.95）。
> 原文保留，记录判断的演进过程。

---

## PLAN §7.3b · semantic F1 的**分辨率地板**（`scripts/03b_semantic_floor.py`）

报告：`reports/semantic_floor.json`（bert + pubmedbert 各一遍，n=2000，seed 20261008）。

### 先纠一个前提错误

原来把 `unrelated`（RNA vs 蛋白质晶体学）的 **0.8159** 当成"完全无关"的下限。
**这是错的**：两者同属生物医学语域、共享大量词根，句子向量本来就靠得近。
按领域两两配（RNA vs 经济学 / 法律 / 菜谱），立刻掉到 **0.45 左右**。

| 无关对（8句 vs 8句） | F1@bert | F1@pubmedbert |
|---|---|---|
| rna vs crystallography（都属生物医学） | 0.7663 | 0.9640 |
| rna vs economics | 0.4490 | 0.9592 |
| rna vs legal | 0.4649 | 0.9498 |
| rna vs cooking | 0.4549 | 0.9522 |
| crystallography vs legal | 0.4771 | 0.9426 |
| economics vs cooking | 0.5374 | 0.9585 |

→ 教训：**"无关"必须按语域设计对照，不能顺手拿两个技术领域当无关。**
语域相邻的"无关"会把地板抬高 0.3，足以把一个结论带反。

### 地板 / 随机基线 / 上界

| | bert-base-uncased | pubmedbert |
|---|---|---|
| 上界（identical） | **1.0000** | **1.0000** |
| 地板 A：跨域无关随机配对 | **0.5205** (std 0.089) | **0.9518** (std 0.008) |
| 地板 B：同域不同事实（分子生物学） | **0.7102** | **0.9682** |
| 地板 C：词序全打乱、词汇全对 | **0.8289** | **0.9718** |
| 地板 D：纯乱码 | 0.2483–0.3913 | 0.9170–0.9250 |
| 句级随机配对（"瞎猜"） | 0.5357 (std 0.147) | 0.9514 (std 0.015) |
| 同域句级随机配对 | 0.7236 | 0.9683 |
| **有效动态范围**（跨域地板 → 1.0） | **[0.52, 1.00]，宽 0.479** | **[0.95, 1.00]，宽 0.048** |

### 最严重的一条：这条指标量的**不是语义**

把每个句子内部的词序全打乱 —— 句子彻底不成话，词 3-gram Jaccard 只剩 **0.0035**
（几乎没有保留任何连续词组），但：

```
bert-base-uncased    乱序 F1 = 0.8275   （原句 1.0000）
pubmedbert           乱序 F1 = 0.9679   （原句 1.0000）
```

**PubMedBERT 上，"词汇全对但语义全错"（0.968）与"完全无关的领域"（0.952）
基本无法区分，和纯乱码（0.92）也差不了多少。**
它对"领域/语域 + 词汇重叠"敏感，对"句子究竟说了什么"不敏感。

### `0.8609` 在不同嵌入上的含义完全不同

| embedder | 地板 | 0.8609 的位置 |
|---|---|---|
| bert | 0.5205 | 高出地板 +0.3404，占可用窗口 **71%** —— 有信息量 |
| pubmedbert | 0.9518 | **低于地板 0.0909** —— 在这个尺度上等于"完全跑题" |

同一把尺子的同一个读数，在两种嵌入上一个算好、一个算跑题。
**说明分母（地板）比分子更决定读数**，也说明 `S_BERT` 与 `S_Pub` 的分数
**不可横向比较** —— 原版表里 0.8609 vs 0.7165 的差距，很可能主要来自嵌入本身的性质，
而不是"BERT 语义更准"。

> 0.8609 是原论文在其**自有评测集**上的数，本地是自建小语料，绝对值不可直接比较；
> 这里只用它定位"同一把尺子在本地语料上的零点"。

### 机制：表示各向异性

| | 跨域句级 cos | 同域句级 cos | 跨/同域差 | 各向异性 |
|---|---|---|---|---|
| bert | 0.4844 | 0.7250 | **+0.2406** | 0.7281 |
| pubmedbert | 0.9466 | 0.9684 | **+0.0218** | 0.9752 |

PubMedBERT 的句向量挤在一个极窄的锥里（任意两句 cosine 就有 0.95），
max-cosine 于是无论如何都被抬到 0.95 以上 —— **地板高是几何必然，不是评测集的问题。**
它的同/跨域可分性比 BERT 低一个数量级（0.022 vs 0.240），
这才是它无法分辨对错的根本原因。

### 落在报告口径上的三条

1. **不能单独用 semantic F1 判复现好坏。** 必须同时报 ROUGE + 同语料的随机/无关基线。
2. **`S_BERT` 与 `S_Pub` 不可跨列比较**（分母不同）。原版表把两种嵌入并排摆，
   容易被读成"BERT 上语义更好"，实际不是。
3. **报 PubMedBERT 的 semantic F1 时量级要特别小心** ——
   0.95 以下没有信息，0.97 与 0.99 之间的差别基本是噪声。

---

## PLAN §7.3c · PubMedBERT 权重忠实性验证（`scripts/00d_verify_embedder_weights.py`）

报告：`reports/embedder_weight_verification.json`。

**为什么必须做**：`pubmedbert` 目录下的 `model.safetensors` 与 `tokenizer.json` 是**本地生成的**
（上游只给 `pytorch_model.bin` + `vocab.txt`），而这里踩过一次
"字节数完全正确、内容全是坏的"的静默损坏（坑 7）。所以"PubMedBERT 地板 0.95"
必须先排除"权重坏了"才成立。

从 ModelScope 重下上游 `pytorch_model.bin`（440,474,434 B）：

```
sha256 = ad7bbb66376cfd6b2db3447192b034efe016337cbef135c35c411fd61b13c193
       == ModelScope 声明值（逐位相同）
上游 208 张量（含 MLM 头 9）→ 去 `bert.` 前缀、剔除 cls.* 后共同键 199
bitwise 相同: 199/199    shape 不一致: 0    max|Δ| = 0.000e+00
前向: last_hidden_state 逐位相同: True      max|Δ| = 0.000e+00
句向量余弦矩阵 max|Δ| = 0.000e+00
[OK] 权重忠实
```

**结论：本地 safetensors 是上游权重的忠实无损导出。地板 0.95 是真模型性质，不是损坏。**

> 顺带修掉一个自己犯的错：第一版比对脚本写成
> `missing, unexpected = m_up.load_state_dict(sd_up, strict=False)`，
> **把返回值丢掉了**，于是 `m_up` 还是随机初始化，前向 max|Δ| = 1.49e+01，
> 差点得出"权重坏了"这个完全相反的结论。
> `load_state_dict` 确实是 in-place 的，但**必须断言 `missing_keys` 为空**才能拿去比前向 ——
> 现在脚本里有 `assert not report.missing_keys`。

> 另一个易踩的坑：`model.safetensors` 是从 `AutoModel`（裸 encoder）导出的，**不含 MLM 头**。
> 用 `AutoModelForMaskedLM` 加载会报 `cls.predictions.*` MISSING，然后拿**随机初始化**的
> MLM 头输出垃圾词（实测：`The patient was diagnosed with [MASK] cancer.` → `vast/grand/looks`，
> 而真 BERT 给的是 `breast/lung/liver`）。
> **别用 MLM 探针验 encoder 权重** —— 会得出错误结论。semantic 指标只吃 encoder 输出，不受影响。

---

## PLAN §7.1 · RNA-FM 探针（**已通过**）

`reports/rnafm_probe.json`（CPU 上跑的；GPU 另见下方"待查"）。

```
config : max_position_embeddings=1026  hidden=640  vocab=28
buffer   embeddings.position_ids: shape=(1, 1026)
[ok]  demo_small             nt=  81  ids=(1,  83)  out=(1,  83, 640)
[ok]  demo_yeast_trna_phe    nt=  76  ids=(1,  78)  out=(1,  78, 640)
[ctx] 1022 nt -> ids (1, 1024)
```

**输出维度 640，逐位对上 config 的 `hidden_size`。** tokenizer 会额外加 BOS/EOS 两个特殊 token。

### ⚠️ 一个和 PLAN 假设不一致的实测结果：**上下文其实是 1022 nt，不是 1024**

PLAN §3 P0 的过滤标准写的是"序列长度 30–1024 nt（RNA-FM 上下文 1026 − 2）"。
`scripts/01b_probe_rnafm_limit.py` 逐长度逼边界，结果：

```
  nt  tokens  result
1022    1024  OK   out=(1, 1024, 640)
1023    1025  FAIL IndexError: index out of range in self
1024    1026  FAIL IndexError: index out of range in self
-> 可用上限：1022 nt
```

`config.max_position_embeddings=1026` 和 `position_ids` 缓冲区的 1026 都对得上，
但**真正生效的 token 上限是 1024**（1024 个 token 能过，1025 就炸）。

所以：**数据过滤上限要从 1024 nt 收到 1022 nt。**
（当前这 50 条最长 966 nt，没踩到；上量到 1K/121K 时必须改，
否则会有一批样本在 encoder 里直接抛 IndexError。）

### GPU 上前向崩过一次 —— 是**暂时的**，已恢复

同一段探针 `--device cuda` 下崩在 `at::native::to` → `empty_strided_cuda` →
`c10::cuda::SetDevice`（HIP 侧抛异常，连 `torch.zeros(8, device='cuda')` 都过不去）。
CPU 上一切正常，说明不是权重问题。

排查过程：
1. 先怀疑 GPU 被别的进程占着 —— `Get-Process` 显示没有大进程，可用内存 52 GB，排除；
2. `aria2c` 式的环境因素排除（两个解释器都崩）；
3. **等了约 20 分钟后原样重试，直接通过**（`CUDA OK`），探针在 GPU 上也跑通了。

结论：gfx1151 + ROCm 7.13 nightly 偶发地会把设备卡住，**重启内核态的驱动状态需要时间**。
→ 遇到 `c10_cuda_check_implementation` / `SetDevice` 这类异常，
**先重试 + 等一会儿，别急着改代码或重装 torch**。

（`reports/rnafm_probe_gpu.json` 是 GPU 版结果，`reports/rnafm_probe.json` 是 CPU 版，内容一致。）

---

## PLAN §7.2 · RNA-QA 重建（采集已通，生成待 GPU）

### 管线逻辑离线自检（**已通过**）

真跑要等 15.3 GB 的权重，但**管线逻辑与模型无关**。
`scripts/99_selftest_pipeline.py` 用一个"假生成器"把 11/12/13 的代码路径整条跑一遍，
假生成器**故意做两件坏事**：按频率吐出序列子串、按频率输出非 JSON 废话。
全部 8 项检查通过：

```
[1] divide(): 20/20 条切块干净                      <- 块边界都落在句末
[2] 解析出 40 组 QA；非 JSON 输出 2 次；闸门拦下 4 条带序列的记录
  [ok  ] divide_keeps_sentence_boundaries
  [ok  ] json_parse_handles_fences                  <- ```json 围栏能剥
  [ok  ] guard_catches_leak                         <- 序列泄漏真的被拦
  [ok  ] guard_flags_bad_json
  [ok  ] guard_positive / guard_negative            <- 闸门不误杀
  [ok  ] guard_ngram_detects_bare_bases             <- 裸碱基串（非 reference 子串）也能抓
  [ok  ] wrote_jsonl
[verdict] PASS —— 管线逻辑没问题，等权重到位即可上量
```

**意义**：真跑之后如果数据是脏的，那一定是模型的问题，不是代码的问题 —— 归因干净。

### 已跑通：采集 50 条 (序列, 文献)

`scripts/10_collect.py`，最终链路 **nuccore → GenBank → pubmed**：

```
[batch 0] ids=60 gb=60 可用=60 pmids=18 已收 50/50
[stats] {"nt_scanned": 60, "bad_len": 0, "bad_alpha": 0, "no_pubmed": 0,
         "short_abstract": 0, "no_abstract": 0, "dup": 0, "kept": 50}
[lens] min=116 median=416 p90=825 max=966          <- 全部落在 RNA-FM 的 1024 内
```

产物：`data/raw/rna_literature_50.jsonl`

**两条被实测否掉的链路**（写下来省得重走）：

1. `pubmed → nuccore`（正向）：拿到的全是 2–4 kb 完整 mRNA（`NM_*`），
   越过 1024 nt 上限，**半小时一条都收不到**。
2. `elink` 反查：传**多个** UID 时会合并成一个 linkset，不告诉你哪条链接属于哪条序列
   （实测 5 个 id 的 pubmed 链接全挤在一起）。
   → 改用 GenBank 自带的 `PUBMED` 字段，一次 efetch 同时拿序列和 PMID，一一对应。

### Qwen3-8B 权重：**已修复并校验通过**

静默损坏的 1/2/3 号 shard 删掉**重新单写者下载**后：

```
model-00001-of-00005.safetensors   3996250744  3996250744  OK  31d6a825... == 31d6a825...
model-00002-of-00005.safetensors   3993160032  3993160032  OK  5991236c... == 5991236c...
model-00003-of-00005.safetensors   3959604768  3959604768  OK  c5185c47... == c5185c47...
model-00004-of-00005.safetensors   3187841392  3187841392  OK  b5ee7de7... == b5ee7de7...
model-00005-of-00005.safetensors   1244659840  1244659840  OK  20c2d636... == 20c2d636...
model.safetensors.index.json            32878       32878  OK  f9fdbcb9... == f9fdbcb9...
[OK] 全部文件与 ModelScope 声明一致。
```

**连贯性验证**（之前是乱码的那次）：

```
[gen] 载入 models/Qwen3-8B 用时 17.9s  device=cuda dtype=torch.bfloat16
prompt: "Name the four RNA nucleotides, separated by spaces. Answer in one line."
OUT: 'Adenine Cytosine Guanine Uracil'          <- 正常了
```

至此 PLAN §1 的两个模型（RNA-FM 640 维 + Qwen3-8B 4096 维）**都在本机跑通**。

### ⚠️ 采集质量的一个硬伤：文献复用 98%（**必须改，否则训不出东西**）

第一版 50 条记录里 **只有 7 篇不同文献**，其中 42 条共用同一篇
（C. elegans 基因组论文 PMID 9851916）——**84% 的"文献"跟这条 RNA 没关系**。

把 `--target` 提到 1000 后又复现了同一件事（子代理实测）：
1000 条里**只有 24 个不同 pmid**，其中一篇（1987 年 S. pombe 线粒体 LSU rRNA）
一条配了 **800 条**序列。后果：`literature` 字段作为监督信号基本无信息量。

根因：`esearch` 的 relevance 排序是确定性的，**第一条 query 一个批次就把 target 填满了**
（`by_query = {ncrna_refseq: 1000}`），后 4 条 query 一次都没跑到；
而每条 RefSeq 记录的 GenBank `PUBMED` 字段大量指向少数几篇"大论文"。

已加的闸门（`10_collect.py`）：
1. `--max-per-pmid 1`：同一篇文献最多给 1 条记录（默认开）；
2. `--require-mention`：DEFINITION 里的**特征标识**（如 `(Lncpnky)`、`(mcmdc2as)`）
   必须出现在摘要里 —— 这是弱相关性检查，但能把"挂名文献"挡掉。

加闸门后实测：单批 100 个 id 只留下 **5 ~ 20 条**（之前是 50）。
**这正是应该的** —— 宁可少，不能脏。

> 顺带一个标注噪声线索：那 800 条被引论文讲的是**线粒体 LSU rRNA 基因**，
> 这批 RefSeq 条目却注释成 "non-coding RNA … lncRNA"。值得单独看一眼。

---

## 下一步

1. Qwen3-8B 权重下完 → 跑 11/12/13，出 50 条 RNA-QA，人工抽查质量（PLAN §3 P0 判据）。
2. RNA-FM 权重到位 → 跑 §7.1 探针，把 output_shape / 上下文长度落成 `reports/rnafm_probe.json`。
3. bert / pubmedbert 到位 → 跑 §7.3 的 B/C 关（语义指标不变量 + 消融阶梯响应方向）。**已完成，见 §7.3 / §7.3b / §7.3c。**
4. 三者都绿之后，进 P1（Stage1 模态对齐：冻结 RNA-FM + 冻结 Qwen，只训 640→4096 投影）。

### 评测口径上必须落地的三条（来自 §7.3b，改 `04_eval.py` 时要照做）

- [ ] **报 semantic F1 时必须同时报基线。** 每次评测都跑一遍"跨域无关对 + 同域句级随机配对"，
      把地板跟着主数字一起报。否则读者无法判断读数落在窗口里的什么位置。
- [ ] **`S_BERT` / `S_Pub` / `S_GPT` 三列不可横向比较。** 每列只能和**它自己**的基线比。
      原版表把三个嵌入并排摆，容易被读成"哪个嵌入更好"，实际是三个不同的分母。
- [ ] **PubMedBERT 那列接近饱和，别当主指标。** 有效窗口只有 0.048 宽；
      报告里应以 ROUGE 为主、`S_BERT` 为辅、`S_Pub` 仅作参考。

---

## E 轨 Stage 1 进度 + 三个"读 checkpoint"的静默错误（已修）

### E 轨 Stage 1 跑到 38.7%

`checkpoints/stage1_run1/`，27 个 checkpoint，step 500 → 13500（`--compress-latent 64`）。
10 epoch × 3488 条 = 34880 步，**还差 21380 步（~5.9 h @ 1.0 s/step）**。

* `val_loss` 从 step 6200 起就在 1.365–1.393 横着，train 掉到 0.76–0.91 —— 典型过拟合。
* `proj_std` 0.32 → 0.39，**没有**退化成常向量。
* Δloss(置零) 峰值 **0.2732 @ step1600**，衰减到 **0.047 @ step13800**。

### ⚠️ 但"Δloss 衰减 = 投影塌缩"这个读法是**错的**

`scripts/31_stage1_rouge_curve.py` 的试点（这是论文的指标，才是判据）：

| step | ROUGE-1 | ROUGE-2 | ROUGE-L |
|---|---|---|---|
| 500 | 0.2084 | 0.0261 | 0.1337 |
| 8000 | **0.3030** | **0.1234** | **0.1914** |

原论文 Modality Fusion (D&C) = **0.0922** ⇒ 我们是它的 **~3.3 倍**。
step-8000 的生成结果里正确写出了 `LINC00115` —— **模型确实在读 RNA**。

**教训（值得单独记一条）**：Δloss 是**逐 token 平均**的。答案变长、变准、变多样，
分母变大，Δloss 天然被摊薄。**它不能替代 ROUGE 做收敛判据。**
`Stage1Config` 里 `collapse_rel_drop=0.75` 那套相对判据同样受这个问题影响，
所以 PLAN 里"置零编码器指标明显下降"这条**只能当辅助信号**，最终以 ROUGE 曲线为准。

### 修掉的三个静默错误（都是"读 checkpoint 时少装东西"，不报错但结果全错）

1. **`scripts/22_zero_encoder_probe.py` 直接崩。**
   `Stage1Config(llm_path=args.llm, **(blob["config"]))` ——
   checkpoint 里的 config 含 `llm_path`（和 `args.llm` 撞名 → `TypeError: got multiple values`），
   且含 `collapse_delta` 这种 dataclass 里根本没有的旧字段。
   → 改成只挑 `dataclasses.fields(Stage1Config)` 认识的键，命令行优先；
   并**装回压缩器**（以前只 load `projection`，E 轨 checkpoint 的压缩器是随机初始化的）。
   同时加了 `--pass-delta/--weak-delta`，并在输出里写明 Δloss 只是参考。

2. **`src/rnaqwen/models/finetune.py` 不支持压缩，E 轨没法进 Stage 2。**
   `build_stage2_model` 硬编码 `Stage1Config(...)`，`encode_samples` 直接
   `model.projection(rna)` —— 压缩器根本没有插入点。
   → `Stage2Config` 加 `compress_latent/compress_method`；
   `build_stage2_model` 传下去、从 blob 装 `compression`、
   **R/E 配错直接 `SystemExit` 报错**（不让它静默跑歪）；
   `encode_samples` 在投影前插 `if model.compression is not None` 分支（None 时逐位不变）；
   `save_stage2` 一并存 `compression` + `compression_spec`。

3. **`scripts/30_infer.py` 的压缩器权重从来没载过。**
   原来只有 `compressor = RnaTokenCompressor(encoder.hidden_size, args.compress_latent)`
   —— **随机初始化**，E 轨推理输出看着像样但全是错的。这是最危险的一个。
   → 改成从 `blob["compression"]` load，配置自动从 `compression_spec` 读，
   配错直接报错退出。

### 冒烟验证（E 轨 Stage 2 全链路，已通过）

```
[stage2] 载入 Stage1 投影 <- checkpoints\stage1_run1\projection_step13500.pt (step 13500)
[stage2] 载入压缩器 <- checkpoints\stage1_run1\projection_step13500.pt (resampler n_latent=64)
trainable params: 15,335,424 || all params: 8,206,070,784 || trainable%: 0.1869
[stage2] {"step": 1, ..., "loss": 1.3883, "seq_len": 135, "elapsed_s": 3.4}
...
[stage2] 完成 6 步，用时 0.1 min
```

* `attn` 预设的 15,335,424 与静态估算**逐位对上**（见 `docs/METRICS.md`）。
* 压缩后 `seq_len` 135–169（不压缩会是 600–1100）。
* 存回的 `projection.pt` 里 `compression` + `compression_spec` 都在，
  `config.compress_latent = 64`，往返一致。
* 实测 Stage 2 吞吐 **0.9 s/样本** ⇒ 80,907 条 × 10 epoch ≈ **202 小时**。
  **所以 Stage 2 默认从 3 epoch 起跑（≈61 h），不是 10。**

> 顺手修的第四个：`--kind` 的 help 写的是 `open | closed`，但数据里的值是
> `open_ended | closed`。按 help 写 `--kind open` 会筛出 0 条样本。
> **文档写错选项名 = 静默的空数据集。** 已改。

### 手动运行

`RUN.md` 是给用户自己跑的命令单（工具 shell 拉起来的长任务已静默死过 5 次以上，
无 traceback、无 abort、事件日志里也没有）。

---

## 🔴 重大事故：RNA-FM 权重一直就是坏的，13500 步 Stage 1 全部作废

**发现方式**：用户贴了一段 `RnaFmModel LOAD REPORT` 问正不正常。报告本身确实正常
（UNEXPECTED 的是 `lm_head.*`/`ss_head.*` 预训练头，MISSING 的是从没用过的 `pooler.*`）。
但顺手验一下「权重真的装进去了吗」，验出问题。

### 症状

```
模型 state_dict 张量数 : 200
checkpoint 原始键数     : 205
剥掉 `model.` 前缀后共有键 : 198   （前缀差异是 from_pretrained 的正常行为，不是问题）
逐位相同                 : YES
未覆盖的模型键           : ['pooler.dense.bias', 'pooler.dense.weight']   <- 只有这个
```

到这里一切正常。继续查：

```
word_embeddings.weight (28, 640)  absmax = 0.000000e+00   nnz = 0 / 17920
序列敏感性：ACGUACGU… vs GGGGGG…   max|Δ| = 0.000000e+00
```

**`word_embeddings` 全零，且不同序列的输出逐位相同。**

前向路径是 `inputs_embeds = self.word_embeddings(input_ids)`（从 `RnaFmEmbeddings.forward`
的源码确认），全零 ⇒ 输入 = 只有位置编码 ⇒ **encoder 完全看不见序列**。

### 量化

```
总张量 205 / 正常 50 / 全零 155
12 层 encoder 的 attention / intermediate / output 几乎全在零里
```

### 根因：文件是对的**大小**，错的是**内容**

```
本地 sha256  38f3ae9aadbf4d3a5ff6873476fe9d16600b83a54711637ec3760e8e83a2408d
上游声明     ec69333eb894dbefb580e690b0cbe1cbae9845fefd2bc78da914cd14226a2828
大小        398,117,588  ==  398,117,588   ← 逐字节相同
```

**和 Qwen3-8B 那 4 个 shard 一模一样的故障模式。**

### 现场复现（这次抓到了机制）

重下时实测 `.part`：

```
逻辑大小 377,701,268 B      ← 只下了 57 MiB，文件却已经接近满
@  1 MB : 有数据          @ 10 MB : 零填充
@ 30 MB : 有数据          @ 50/100/200/300/350 MB : 零填充
Valid Data Length = 377701268   ← NTFS 认为整段都是「有效数据」，零就是真零
```

aria2 **预分配**了整份文件，只有真实分片有数据，其余是零。
（命令行确实带了 `--file-allocation=none`，aria2 1.37.0；大概率是上一轮中断留下的
预分配文件没被截断，新一轮 `--continue=false` 从 0 覆写，尾部那些零是上回的。）

**中断 + 预分配 = 大小正确、内容一半是零。** 这就是全部。

### 为什么没被发现（三个自己给自己发的假通行证）

1. **`from_pretrained` 不报错。** LOAD REPORT 只提 `lm_head`/`ss_head`/`pooler` 这三个
   无关紧要的键，看起来像"只是架构差异，可以忽略"。
2. **探针只查形状。** `01_probe_rnafm.py` / `01b_probe_rnafm_limit.py` 验的是
   `out=(1,83,640)` —— **一个全零的模型照样过**。我据此写过 `[OK]`。
3. **没有 sha256。** Qwen3-8B 坏过一次之后明明立了「单写者 .part + 强制 sha256」的规矩，
   但**只用在了 Qwen3 上，RNA-FM 漏了**。规矩没有强制力，就等于没有。

### 作废清单

| 东西 | 状态 |
|---|---|
| `checkpoints/stage1_run1/` 27 个 checkpoint（13500 步 ≈ 3.75 h） | ❌ 废 |
| `checkpoints/stage1` 500/1000/1500、`_losscheck`、`_timing_gc` | ❌ 废 |
| ROUGE 曲线试点 0.2084 → 0.3030 | ❌ 废 |
| 「step-8000 正确写出 LINC00115 ⇒ 模型在读 RNA」 | ❌ **收回**。encoder 对序列零敏感，这个结论不成立 |
| Δloss 置零探针 0.273 → 0.047 的"塌缩"判读 | ❌ 无意义 |
| 数据 `rnaqa_n6.jsonl` / `evalset` | ✅ 与 encoder 无关，有效 |
| 代码（含本轮修的 4 个 bug） | ✅ 有效 |
| 计时测量 | ✅ 大致仍然成立（encoder 本来就便宜） |

### 修复

`scripts/00e_refetch_rnafm.py`（新）——所有通路都走同一个闸门：

```
下载 -> .part -> sha256 必须 == ec69333e…a2828 -> 才允许原子改名
```

配套规则（每条都对应一个踩过的坑）：

* `archive_corrupt()`：坏文件改名留档，不删；
* **哈希不符时绝不改名**；
* 哈希不符 + 大小已满 ⇒ 判定为「预分配空洞」。这种情况**续传救不了**
  —— 控制文件会说"分片都完成了"，每次续传立刻返回同一个坏文件，卡死循环。
  必须连 `.part.aria2` 一起清掉；
* 哈希不符 + 大小未满 ⇒ 真没下完，保留 `.part` 续传；
* **下载完还要独立验一次「换序列输出会变」** —— 哈希对了也可能装错文件。

### 立规矩

**禁止一直换源。** 选定一条通路就走到底，慢就慢。
把关的不是速度，是校验。遇到"慢"，不要去找更快的源，先把校验补上，然后等。
（已写进 memory.db #1011。）

---

## ✅ 换到 ERNIE-RNA（E 轨）+ 下载与健全性检查全过

### 决定

用户拍板：**改用 ERNIE-RNA 作 backbone**，理由是结构增强（attention bias / pairwise 表示），
性能强于 BERT 基座的 RNA-FM。
**这是 E 轨**（PLAN §7）。论文用的是 RNA-FM，所以 ERNIE-RNA 的任何数字都要单独标 E 轨，
不能和论文 / R 轨并列。

### 取数（三条路都试了）

| 源 | 结果 |
|---|---|
| HF `multimolecule/ernierna` | ✅ **最终成功**。345,071,800 B，sha256 `02274cb7…08eb`，与上游声明逐位一致 |
| hf-mirror.com（并行） | 下到 210/329 MB 后放弃（同一份 artifact，谁先完成算谁的） |
| GitHub `Bruce-ywj/ERNIE-RNA` | 不放权重，只有代码 + 一个 Google Drive 文件 ID |
| Google Drive `ERNIE-RNA_pretrain.pt` | 作者**原始 fp32 权重**，1,035,221,383 B（1.04 GB），实测传不动。**留作兜底** |
| ModelScope | 没有 ernierna。有 `ZhejiangLab-LifeScience/{rnafm,rnaernie,rnamsm,rnabert,dnabert2}`，但都是**浙江lab 自己的转换版**（vocab 26，键名不同），不是 multimolecule 的 |

### 健全性检查：**PASS**

```
sha256            02274cb7…08eb   ✅ 与上游声明一致
张量总数 207，全零 1                ✅ 只有 pooler.dense.bias（非主干，从不使用）
键覆盖 202/202，未覆盖 0            ✅ 权重真的装进模型了
输出形状 (4, 202, 768)             ✅ hidden 768
base vs polyG      max|Δ| = 3.1138e+00   ✅ 序列敏感
base vs shuffled   max|Δ| = 2.3979e+00   ✅ 次序敏感
base vs base       max|Δ| = 0.0000e+00   ✅ 确定性
VERDICT: PASS
```

### 关键实测差异：ERNIE-RNA **没有** RNA-FM 的 1022 nt 硬上限

```
RNA-FM     position_embedding_type = 'absolute'    -> 查表，表只有 1026 行，1023 nt 直接 IndexError
ERNIE-RNA  position_embedding_type = 'sinusoidal'  -> 算出来的，无硬上限；实测 1030 nt（1032 token）也能过
```

但 config 的 `max_position_embeddings = 1026` 是**预训练窗口**，超出去是外推。
所以 `ARCHS["ernierna"].max_nt = 1024`（= 1026 token − BOS/EOS），取预训练范围而不是拍一个数。
（现有数据按 1022 过滤过，所以这个数目前不会真的被用到。）

### 新增/改动

| 文件 | 作用 |
|---|---|
| `src/rnaqwen/paths.py` | **新**。集中默认路径 + 轨道归属。R 轨 `models/rnafm`，E 轨 `models/ernierna`。覆盖优先级：`--encoder` > `RNAQWEN_ENCODER` > 默认 |
| `src/rnaqwen/models/encoder.py` | 重写为多 backbone `RnaEncoder`，按 `config.json` 的 `model_type` **自动识别**；arch 与 config 不符、hidden 不符都直接报错 |
| `scripts/01c_check_encoder_sanity.py` | **新**。四条闸门（哈希 / 结构 / 键覆盖 / 序列+次序敏感性+确定性）。已用已知损坏文件验证过会 FAIL |
| `scripts/00d_fetch_verified.py` | **新**。通用哈希闸门取数；拿不到上游 sha256 就拒绝下载大文件；单写者锁；真实进度读数 |
| `scripts/01b_probe_rnafm_limit.py` | 改为按 arch 解析，不再硬编码 `RnaFmModel` |

### 下一步

1. Stage 1 冒烟（小样本几步），确认 `768 -> 4096` 的链路通
2. Stage 1 全量（E 轨，10 epoch）
3. ROUGE 曲线






---

## 🔄 转向：彻底放弃 RNA-GPT 软提示路线（2026-10-10）

**性质变更：本项目不再是 RNA-GPT 的复现。** 变成「RNA-QA 上软提示路线 vs 原生文本路线的头对头对比」。
新计划见 `PLAN_v2.md`；旧计划留档为 `PLAN_v1_softprompt.md`。

### 触发点不是"做不下去"，是逐条测出了天花板

用户最初提出「Stage 1 对齐目标与 Stage 2 指令目标脱节」的假设，我核实后发现它是**症状不是病根**。
真正的病根在核实过程中浮出来：**我们冻结了 LLM。**

| 检验 | 结果 |
|---|---|
| 投影在丢信息？ | ❌ 减掉公共分量后 inter = **-0.05**，信息完整 |
| 学习式压缩器造成偏执依赖？ | ❌ meanpool 与 resampler 逐 token 剖面几乎一致（负值 58.4% / 63.3%） |
| val_loss 能选投影？ | ❌ 两次独立配对都是 val 低 ↔ grounding 低 |
| 去各向异性是解？ | ❌ val 打平（1.4892 / 1.4926），Δzeroed 差 8× 但消融口径不同、不可比 |
| 原生文本要改 tokenizer？ | ❌ 0.526 tokens/nt，扰动中位影响跨度 **0 nt**，局部稳定 |

### 四条外部证据（都核实过原文，不是转述）

- **ChatMultiOmics** arXiv 2412.19191：`directly applying LoRA ... near-random performance in
  classification and regression tasks ... LoRA primarily leverages pre-trained knowledge to generate
  well-formed answers based on the output format learned from SFT data`
  → 精确命中我们的观测：val_loss 降到 1.384（格式学会了），Δzeroed 衰减到 25%（内容没进去）
- **MAPO** arXiv 2605.27741（JHU + 腾讯混元，作者 Sanjeev Khudanpur / Liefeng Bo）：
  术语 **late-stage modality collapse**；`abandon the primary source signal in favor of
  compressed textual priors`。其仪器（消融参照的跨模态差分熵）与我们的 Δzeroed 是同一个东西，
  但**逐 token、更强**。
- **Moirain** arXiv 2605.23961：RNA + 多模态 SFT + DPO；DPO 动机是
  `without collapsing the learned natural distribution`。
- **RNA-GPT** arXiv 2411.08900：Stage 1 的 Q 留空是**故意**的，为堵死"抄 prompt 文本"——
  这是它的解，也是它的病。

### 今天用血换来的六条方法论

1. `mem_get_info()` 在 gfx1151(APU) 上不可信（报 107 GB，物理内存只 63.6 GB）→ **只看物理内存**
2. 哈希闸门是唯一能挡「大小对、内容空」的手段（已两次）
3. 单测过了还要跑真模型冒烟（SOS-LoRA 单测 8/8，冒烟仍抓出 dtype 与作用域两个 bug）
4. **「测出来的东西和以为测的不是一回事」今天犯了四次** —— 每次都在
   「全零 / max 也零 / 比值太整齐」这类信号上露馅。**看到这种信号先怀疑自己。**
5. 优先用**直接量**（可分辨性、逐 token），不用聚合标量（val_loss 已被证伪两次）
6. 换源不算办法 —— 先修校验，再等

### 新路线

```
RNA 序列 → Qwen3 tokenizer 原生 token（0.526 tokens/nt）
         → ① 序列继续预训练（可选，第一版先跳过）
         → ② 指令微调（SFT / LoRA / SOS-LoRA）
         → ③ 推理微调（可选）
```

**保留**：4,481 RNA / 92,680 QA 数据集、evalset_merged、评测协议、Qwen3-8B、SOS-LoRA 实现。
**零新架构、零 tokenizer 改动**，只需要一段几十行的语料预处理。


---

## 2026-10-10 小实验：FSQ 的码到底是词表还是哈希（44/45/46）

用户问「能做个小实验吗」。这条路线能不能走，取决于一个**不用训 LLM 就能回答**的问题：
离散码是不是可复用的词表。跑了三个递进的对照，**其中两个指标被我自己的设计否掉了**。

### 44_ 覆盖率 —— 第一次自我否证
v1 用 64 条序列 (29k 位置) + 词表 65536，得到「52% 的码只出现一次」。
**这是算术必然，不是发现** —— 平均每码 2.6 个位置，中位重用必然是 1。
v2 改成 256 条序列 (116k 位置)、扫词表 {256,1024,4096,6561,65536} + iid 自助基线。
结果：所有配置的留出覆盖率**都略低于**基线（4096: 95.8% vs 97.5%）。

### 45_ 序列指纹对照 —— 第二次自我否证
「低于基线」的唯一解释应是码在序列内成簇。于是加对照：
(a) 同序列内位置留出 vs (b) 跨序列留出。
- burstiness：平均游程 **1.02**（iid 应为 1.0）—— **码在序列内不成簇**
- (a) -2.0pp，(b) -2.7pp —— **两者一样**

「序列指纹」的解释被推翻。但更重要的：**覆盖率这个指标本身没有判别力。**
词表 4096、训练位 9.3 万时，任何映射都会让每个码被见到几十次 —— 哈希也会给出
90% 利用率和 95% 覆盖。词表远大于样本时又样本不够。**两头都不成立。**

### 46_ 含义迁移 —— 唯一非循环的测试
靶子换成**局部 6-mer**（来自输入序列，不是 encoder 学的，所以不循环）：
在训练序列上学 code -> 最常见 6-mer 的表，在**没见过的序列**上考。

| 量 | 值 |
|---|---|
| 测试位置中码在训练集见过 | 99.1% |
| 按码预测 6-mer 准确率 | **8.48%** |
| 打乱 code<->位置 对照 | 2.95% |
| 常数预测（最常见 6-mer） | 3.02% |
| **增益 / 倍数** | **+5.53pp / 2.88x** |

打乱对照回落到常数水平（2.95% ≈ 3.02%），说明对照有效。

### 结论
**是词表，但是一个不精确的词表。** 码确实携带能跨序列迁移的局部结构信息（2.9x），
不是给每条序列发指纹。但要老实说清两个限制：
1. 局部 6-mer 是**很弱**的靶子 —— ERNIE-RNA 在一位点上编码的远不止 6-mer。
   所以 2.9x 是**下界**，不是上限；但它也说明码与「局部序列组成」的相关性并不强。
2. within/重建 err 这两个指标是**循环的**：FSQ 是确定性映射、AE 又照重构误差训，
   within<1 是构造保证的。**不能拿它们当证据。**

### 对齐踩的坑（记下来）
ERNNIE-RNA 的 tokenizer 每条序列加了 [CLS] 和 [SEP]：
encoder 位置数 = 序列长度 + 2。115886 - 115374 = 512 = 2 x 256，一眼可验。
不做这个偏移，k-mer 靶子整体错位一格，结果全是废的。

### 方法论：一天内第 5、6 次「测的不是我以为的东西」
- 「52% 的码只出现一次」= 词表比样本大（算术必然）
- 「覆盖率低于基线」= 指标无判别力（两头都不成立）
两次都是**先看到太干净的数字，然后才去怀疑自己**。规则 4 又生效了。


---

## 2026-10-10 路线 C 端到端短实验启动（47_）

PLAN_v2.md 已更新：§6.4 第 2 条（去各向异性「前置必需」）**被自己的测量证伪**，降级为消融项；
§6.5 记录 44/45/46 与那两次自我否证；§6.6 记 [CLS]/[SEP] 偏移的坑；§7 换成短实验清单。

### 脚本 scripts/47_routeC_short_sft.py
单变量：底座冻结 + LoRA(attn) + **一张 4096x4096 可训练码表**（16.8M 参数，与臂 A 的 3M 投影同量级）。
RNA 位置不经过 tokenizer，直接用 inputs_embeds 把码 id 映射到码表（不用 resize_token_embeddings，
不污染 Qwen 原词表）。判据是 MAPO 式**逐 token 消融**，不是 loss —— loss 降下来也可能只是模型学会忽略 RNA。

四路消融：真表 / 零表 / 随机表 / 常数码。**关键在对照，不在第一个数：**
- vs 零表 低 => RNA 位置上「有东西」在起作用
- vs 随机表 低 => 起作用的是**码的内容**
- vs 常数码 低 => 起作用的是**码的区分度**
后两个 ≈50% 就是「Qwen 眼里的 RNA 是乱码」，只是换了形式。

### 冒烟（60 条 RNA / 30 步）发现的两个问题 —— 都是我的错
1. |grad_code| 0.0000 每步都是 0。**因为我在 opt.zero_grad() 之后才读 .grad。** 打印全废。
   修到 step 之前读，实测梯度和 19.65 -> 0.79，码表确实在学。
2. **判定逻辑漏了对照。** 第一版只看「vs 零表 < 58.4%」就判 ✅。
   实际冒烟结果是 vs 零表 32.9%、**vs 随机表 48.1%、vs 常数码 47.6%** ——
   后两个是掷硬币，说明模型用的是「RNA 位置有个可训练向量」而非「这个码是什么」。
   **差点报出一个假的成功。** 判定已改成必须三个对照同时 < 45%。

另一个接线 bug：
na_emb 建在 CPU 上（只有 peft 模型走 device_map 上了卡）-> 必须在
ase_emb.weight.device 上建。**方法论规则 3：单元测试过 != 接线对。**

### 冒烟的定位
30 步、码表漂移仅 **3.64%**，对照 ≈50% 是必然的，**没有判别力**。
冒烟只证明端到端能跑通（梯度非零、初始行范数 1.28 与 Qwen 词表 1.38 同量级、四路前向都通）。

### 正式短实验（已在后台启动）
1500 条 RNA / 31190 QA，600 步，每 150 步跑一次三路消融。
**要看的是对照差距随码表漂移「拉开还是一动不动」** —— 那才是判据。
FSQ 已在 668273 个位置上训完，mse 0.045。