NLL 6.x 不是架构天花板：30K 数据平台审计
SPR-064比较了 TreeHeap、Flat GRU 和小 Transformer。它回答了“这些模型在同一小实验里谁更好”，却没有先回答另一个基础问题：30,000 对训练语料，是否足以让任何一个模型展示真实能力？ 如果实验平台本身只有 NLL 6.x、BLEU 约 3 到 5 的水平，那么模型之间相差 0.1，可能只是在比较谁更适应一个严重缺数据的平台，而不是比较架构上限。
本文补上这次遗漏的数据规模实验。结论先说：
30K 不是本数据集的最优平台，更不是 TreeHeap 的能力上限。把独立训练样本增加到 1M，同时保持优化器更新次数不变，三种模型的 NLL 都从 6.x 降到了约 4.0。这个改善主要来自数据多样性，而不是 TreeHeap 独有优势。
1. “平台问题”指什么
这里的“平台”不是服务器、显卡或操作系统，而是我们用来评价架构的整套实验坐标系：
数据量与数据质量
tokenizer
训练更新次数
模型参数量
优化器与学习率
验证集和测试集
baseline 的成熟度
评价指标
假设我们造了两辆新车，却只让它们在一条泥泞、限速 10 公里的小路上比赛。两辆车都只能跑到 9 公里，不代表它们的最高速度相同；只能说明当前道路把车辆差异压住了。
SPR-064 的平台大致是：
| 项目 | 设置 |
|---|---|
| 训练数据 | 30,000 对英中句子 |
| 验证 / 测试 | 2,000 / 2,000 对 |
| 参数量 | 约 2,730 万 |
| 训练 | 4 epoch |
| TreeHeap h1 NLL | 6.1231 |
| Flat GRU NLL | 6.0401 |
| 小 Transformer NLL | 6.4423 或 6.5330 |
这些数字可以比较本轮模型，却不能证明“Flat 已经是数据集最优解”，也不能证明“TreeHeap 只是更慢的 Flat”。要判断平台是否压住了模型，我们需要改变数据量，同时冻结其他主要变量。
2. NLL 6.x 到底意味着什么
NLL 是 Negative Log-Likelihood，负对数似然。对每个目标 token，模型会给整个词表分配概率。如果正确 token 的概率是 $p_t$，平均 NLL 为：
$$ \operatorname{NLL}=-\frac{1}{T}\sum_{t=1}^{T}\log p_t $$越低越好。常见的 PPL，也就是困惑度，为：
$$ \operatorname{PPL}=e^{\operatorname{NLL}} $$可以把 PPL 粗略理解成：模型在每一步面对多少个“同样有竞争力”的候选。它不是候选词的真实数量，但适合帮助理解尺度。
| NLL | PPL 约为 | 直观趋势 |
|---|---|---|
| 6.27 | 527 | 非常不确定 |
| 5.15 | 172 | 明显改善，但仍很宽 |
| 4.26 | 71 | 候选范围继续收缩 |
| 4.02 | 56 | 比 30K 平台可靠得多 |
因此，从 NLL 6.27 降到 4.02 不是小数点上的装饰。PPL 从约 527 降到了约 56，说明模型给正确 token 的相对概率大幅提高。
但 NLL 也不是产品质量的完整替代。teacher forcing 下 NLL 下降，并不保证自由生成一定自然；还要结合 BLEU、样例、人工检查和真实任务评价。
3. 为什么不能直接把数据放大，再训练相同 epoch
最简单的做法是：
30K 训练 4 epoch
1M 也训练 4 epoch
但这不是纯粹的数据量实验。1M 的 4 epoch 包含的优化器更新次数约为 30K 的 33 倍。结果变好以后，我们不知道原因是：
看到了更多不同句子
还是
只是计算了更多次梯度
因此，这次实验固定每组都是：
15,625 次 AdamW 更新
batch size = 64
总样本曝光量约 1,000,000
唯一主动改变的变量是独立训练句子数量：
| 独立训练句对 | 每条数据平均复用次数 |
|---|---|
| 30,000 | 33.33 次 |
| 100,000 | 10.00 次 |
| 300,000 | 3.33 次 |
| 1,000,000 | 1.00 次 |
30K 组反复背同一本薄练习册，1M 组把同样的一百万次阅读机会用于一百万个不同样本。这样才能较干净地测量“数据多样性”本身。
4. 实验预注册
正式 Claim 为：
S3-PRIVATE-PROTOCOL-DATA-DOSE-C03：在优化器更新预算和验证/测试集固定时，如果
SPR-064的 TreeHeap h1 主要受数据不足限制，那么独立训练句对从 30K 增加到 1M 应显著降低 held-out NLL。
执行前写死四条判断门槛：
- h1 的 1M NLL 至少比 30K 低
0.10。 log10(数据量)与 h1 NLL 的 Spearman 相关系数不高于-0.80。- 三次相邻扩容中，至少两次使 h1 NLL 下降。
- 所有梯度保持有限，不得用数值崩溃解释结果。
Flat GRU 和参数量接近的小 Transformer 也执行相同数据剂量。这一点很重要：如果只有 TreeHeap 改善，可以怀疑 TreeHeap 特别缺数据；如果三者都改善，更合理的解释是整个平台都受数据多样性限制。
固定变量
模型 seed = 71901
验证集 = 固定 2K，哈希锁定
测试集 = 固定 2K，哈希锁定
tokenizer = 固定 SentencePiece 模型，SHA-256 锁定
batch = 64
更新次数 = 15,625
learning rate = 0.002
验证间隔 = 500 steps
训练集采用嵌套设计：30K 是 100K 的子集，100K 是 300K 的子集，300K 是 1M 的子集。因此，扩容不是换一套完全不同的数据抽签。
5. 正式结果
实验在 io 的 RTX 3090 上运行 5.32 小时。三种模型、四档数据量共 12 个训练臂。
Test NLL
| 模型 | 30K | 100K | 300K | 1M | 30K 到 1M 改善 |
|---|---|---|---|---|---|
| TreeHeap h1 | 6.2671 | 5.1454 | 4.2558 | 4.0198 | 2.2473 |
| Flat GRU | 6.0319 | 5.0532 | 4.2025 | 3.9365 | 2.0954 |
| Small Transformer | 6.5373 | 5.3375 | 4.1761 | 3.9201 | 2.6172 |
三条曲线都严格单调下降，三种模型的 Spearman 系数都是 -1.0。TreeHeap 的四条预注册 gate 全部通过。
TreeHeap h1 的完整体检
| 独立句对 | 最佳 step | Test NLL | PPL | Token BLEU-4 | 训练时间 | 峰值显存 |
|---|---|---|---|---|---|---|
| 30K | 1,000 | 6.2671 | 526.9 | 5.401 | 56.9 分钟 | 1.84 GiB |
| 100K | 3,000 | 5.1454 | 171.6 | 7.778 | 57.0 分钟 | 1.85 GiB |
| 300K | 14,000 | 4.2558 | 70.5 | 11.079 | 56.7 分钟 | 1.84 GiB |
| 1M | 15,625 | 4.0198 | 55.7 | 12.085 | 56.7 分钟 | 1.84 GiB |
训练时间和显存基本不变，符合固定更新预算。NLL、PPL 和 BLEU 则同时随独立数据增加而改善。
6. 30K 为什么会停在 NLL 6.x
最有解释力的不只是最终 NLL，而是最佳 checkpoint 出现在哪里。
三个 30K 模型都在第 1,000 step 达到最佳验证结果。继续把同样的 30K 数据重复到 15,625 step 后，最终验证 NLL 严重恶化：
TreeHeap h1：10.7979
Flat GRU：10.8155
Transformer：14.7291
这说明 30K 不是“学到了平台最优解”，而是很快耗尽了有限样本提供的新信息，随后开始过拟合。
相反，1M 的 TreeHeap 和 Transformer 都在最后一个 step 才达到本轮最佳结果。它们只完整看过训练集约一次，曲线仍可能继续下降。因此，1M 的 NLL 约 4.0 也不能叫架构上限，只能叫当前固定预算下的一遍数据结果。
所以 SPR-064 中的 NLL 6.x 应重新解释为：
30K 独立样本不足以支撑约 27M 参数模型的稳定比较。重复曝光增加了计算，却不能替代新的关系证据。
这就是平台问题的实证答案。
7. TreeHeap 赢了吗
没有。
TreeHeap 的 NLL 从 6.2671 降到 4.0198，证明它能从新增数据中持续学习；但 Flat 和 Transformer 也同样改善。在 1M 时：
TreeHeap h1 比 Flat 落后 0.0833 NLL
TreeHeap h1 比 Transformer 落后 0.0997 NLL
因此最强解释是普遍的数据多样性效应，不是 TreeHeap 独有 scaling law。
也有一条谨慎的积极信号：TreeHeap 与最佳 baseline 的差距从 30K 时的 0.2352，缩小到 300K 到 1M 时约 0.08 到 0.10。这说明增加数据没有把 TreeHeap 甩开，但单 seed 不足以判断差距缩小是否稳定。
工程效率仍然是明确负项：
| 模型 | 每个数据剂量平均时间 |
|---|---|
| TreeHeap h1 | 约 56.8 分钟 |
| Flat GRU | 约 15.5 分钟 |
| Small Transformer | 约 6.8 分钟 |
当前 TreeHeap 比 Flat 慢约 3.7 倍，比这个小 Transformer 慢约 8.3 倍。它证明了可学习性，没有证明计算优势。
8. 数据越多就一定越好吗
也不能这样下结论。
数据源文件声明包含约 1,417 万行、2.52 GB 文本，但样例检查发现了一些网页碎片、乱码和错位句对。例如型号页面、URL 错误页、广告文本和并不严格对应的双语句子。这些噪声不会推翻固定 split 下的 NLL 曲线，却会限制翻译产品质量。
数量和质量是两个不同变量：
更多不同样本
-> 减少重复记忆，扩大关系覆盖
更多噪声样本
-> 也可能教给模型错误对应和网页模板
这次实验只证明在当前语料排序与过滤规则下，从 30K 扩到 1M 的净收益为正。它没有证明继续扩到 14M 一定保持同一斜率，更没有证明“500 GB 才够”。
9. 以后怎样避免平台误判
后续架构实验至少应同时报告四张表。
数据卡
数据来源、字节数、行数
清洗与去重规则
训练 / 验证 / 测试哈希
tokenizer 哈希
长度分布和语言分布
训练卡
参数量
optimizer / learning rate
batch、更新次数、样本曝光量
最佳 step 与最终 step
GPU 时间、峰值显存
质量曲线
NLL / PPL
BLEU 或任务指标
至少三个数据剂量
至少三个随机 seed
生成样例与人工审计
架构归因
matched Flat
matched Transformer
TreeHeap 地址、root、detail、head 干预
相同数据、参数和计算预算
只有当 baseline 已经随着数据正常改善、主要模型接近收敛、结果跨 seed 稳定时，架构差异才有资格被解释为结构能力。
10. 下一步判断门槛
这次 Claim 的状态是：
数据不足假设：supported pilot
TreeHeap 可从 1M 数据继续学习：supported pilot
TreeHeap 优于 Flat：not supported
TreeHeap 优于 Transformer：not supported
通用 scaling law：未证明
产品级翻译能力：未证明
下一轮不应只把数据继续堆大。更有效的实验是：
- 对 1M 端点执行至少三个 seed，确认
0.08到0.10的差距是否稳定。 - 给 1M 模型更多更新，区分“一遍数据未收敛”和“模型容量不足”。
- 建立清洗语料对照，分开测量数量收益与质量收益。
- 使用更成熟、真正收敛的小 Transformer 作为平台上限参考。
- 报告达到相同 NLL 所需的 token、step、时间和显存，而不只比较最终分数。
这会把问题从“30K 谁赢了”升级为：
在足够数据和公平计算预算下，TreeHeap 是否具有不同于 Flat 与 Transformer 的学习曲线、结构因果性和外推收益？
11. 本轮结论
SPR-064 的架构比较没有作废，但它的适用范围必须缩小：它是一个 30K 小数据平台上的私有协议与结构因果实验，不是架构能力排名。
数据剂量实验给出了三个清晰结论：
- 30K 的 NLL 6.x 主要受到数据多样性限制，不能当作数据集最优值。
- TreeHeap、Flat 和 Transformer 都能从 1M 独立句对中获得巨大收益。
- TreeHeap 在 1M 时接近两个 baseline，但仍更慢、NLL 仍略差，因此只证明继续航行的资格，没有证明胜利。
这篇文章真正补上的，是我们的测量尺。没有足够宽的平台，架构优劣很容易被过拟合、未收敛和弱 baseline 伪装。现在至少可以确认：此前看到的 6.x 不是墙，只是 30K 这块窄甲板的边缘。
完整 ARA 证据：
ara/s3-generation/logic/private_protocol_data_dose.md
ara/s3-generation/evidence/s3_private_protocol_data_dose_full/
代码提交：7bbb89c；结论归档提交：6182b5d。实验保留 config.json、数据 manifest、split hash、逐步 trace、运行日志、生成样例和 summary.json。
本文与相关代码沿用项目现有开源许可证。supported pilot 表示受控单 seed 证据成立，不等于通用 scaling law 或产品性能承诺。