样本数还是序列长度？小规模对照实验拆解数据配比决策

1. 当"加数据"变成一道选择题：样本数还是序列长度

做模型训练的人迟早会撞上同一个困惑：手头的算力预算就那么多，数据池子也就那么大，到底该往哪个方向使劲？是塞进去更多条独立的训练样本，还是把每条样本的序列拉得更长、让单条样本承载更多 token？这个问题听起来像是学术论文里的消融实验，但落到实际项目里，它直接决定了你接下来两周的显卡时间怎么花、数据清洗的优先级怎么排、以及最终模型在开发集上到底是涨点还是原地踏步。

我最近就完整跑了一轮这样的对照实验，规模不大但控制得比较干净：训练池固定 32 条，开发集固定 64 条，在这个受控的小规模环境里，把"更多样本"和"更多 token"这两条路线拆开对比。之所以选这么小的规模，是因为小规模实验的噪声虽然大，但迭代快、变量好控制，能在几小时内把结论跑出来，再决定要不要放大到全量数据上。这套思路特别适合那些算力有限、又想搞清楚数据配比逻辑的团队——你不需要 A100 集群，一张消费级卡就能复现整个流程。

需要先说明的是，这个实验的核心不是追求某个绝对精度数字，而是建立一套可复现的对照方法论。很多人在做数据规模实验时，习惯一次性把样本数和 token 数同时往上堆，最后涨点了也不知道是哪个因素起的作用。我这次刻意把两个维度解耦，就是为了让每一份算力投入的边际收益都能被单独观测到。下面我会把实验设计、数据构造、训练配置、结果解读和踩过的坑完整拆一遍，你可以直接照着改参数复现。

2. 实验设计：为什么是 32 条训练池配 64 条开发样本

2.1 小规模受控实验的取舍逻辑

先说清楚为什么选 32 和 64 这两个数字。训练池 32 条是一个"刚好能跑出趋势又不至于过拟合到无法分析"的临界点。如果训练样本少于 20 条，模型基本记不住任何模式，loss 曲线会剧烈震荡，你根本分不清是数据配比的问题还是随机初始化的锅；如果超过 100 条，单轮实验时间拉长，对照组的迭代成本就上去了，失去了小规模快速验证的意义。

开发集 64 条则是训练池的两倍，这个比例是有讲究的。开发集的作用是评估泛化，如果开发集太小（比如和训练集一样大），评估结果的方差会大到让你怀疑人生；如果开发集太大，评估本身消耗的时间又会拖慢迭代节奏。64 条在多数任务上能给出相对稳定的评估信号，同时评估一轮的时间控制在训练一轮的三分之一以内，整体节奏比较舒服。

提示：这里的"条"指的是独立样本数，不是 token 数。在后面的对照里，我会保持样本条数不变、只改每条样本的 token 长度，或者保持总 token 预算不变、只改样本条数，这样才能把两个变量真正拆开。

2.2 两条对照路线的定义

实验分两组，共用同一份原始语料和同一套训练超参，唯一不同的是数据组织方式：

• A 组（更多样本路线）：训练池 32 条，每条样本截断到较短长度（比如 128 token），总 token 预算约 4096。这组模拟的是"样本多样性优先"的策略，用更多独立的短样本覆盖更广的模式。
• B 组（更多 token 路线）：训练池同样 32 条，但每条样本保留完整长度（比如 512 token），总 token 预算约 16384。这组模拟的是"单样本信息密度优先"的策略，用更长的上下文让模型看到更完整的依赖关系。

注意这里有个容易搞混的地方：两组的总 token 数其实不一样。有人会问，这样对比公平吗？答案是——这正是实验要回答的问题。现实中你的算力预算往往是以 token 总量或者训练步数来衡量的，而不是以样本条数。所以我在第三组 C 组里做了补充对照：把 B 组的长样本切分成更多短样本，让 A 组和 C 组的总 token 预算对齐，这样就能分离出"token 总量"和"样本条数"各自的贡献。

2.3 评估口径的统一

评估这块我踩过坑，必须单独拎出来说。开发集 64 条样本，如果 A 组用短序列评估、B 组用长序列评估，那评估结果根本没法比，因为输入分布都不一样了。我的做法是：所有组别统一用开发集的完整长度做评估，也就是评估时不做截断，让模型在相同的输入条件下比拼。训练时可以截断，评估时必须一致，这是保证对照有效性的底线。

评估指标我用了两个：一个是任务本身的准确率（针对具体任务定义），另一个是平均负对数似然（NLL）。前者直观，后者对概率分布的变化更敏感，能捕捉到准确率看不出来的细微差异。两个指标一起看，结论会更稳。

3. 数据构造：32 条训练池怎么切、64 条开发样本怎么留

3.1 原始语料的清洗与去重

数据构造这一步决定了实验的上限。我手头的原始语料大概几百条，第一步是清洗：去掉空样本、去掉长度低于 32 token 的碎片、去掉包含明显乱码或重复字符的样本。这一步没什么技术含量，但必须做，否则后面切分出来的短样本里会混进一堆噪声，污染对照结果。

去重比清洗更关键。小规模实验里，如果训练池和开发集之间有重叠样本，模型直接记住了答案，评估结果会虚高到离谱。我用的是基于文本指纹的近似去重：先对每条样本做归一化（统一大小写、去掉多余空白），再算一个简单的哈希指纹，指纹相同的直接判重。对于语义相近但字面不同的样本，小规模场景下人工扫一遍比上复杂算法更靠谱，毕竟总共就几百条。

3.2 训练池的切分策略

32 条训练池的切分直接对应两条路线：

• A 组切分：把每条原始样本按固定窗口切成 128 token 的片段，如果一条样本切出多个片段，只保留第一个片段，保证训练池还是 32 条。这样每条样本变短了，但条数没变。
• B 组切分：每条原始样本保留完整长度，最长截到 512 token，训练池依然是 32 条。
• C 组切分：把 B 组的长样本按 128 token 窗口切分，切出来的所有片段都进训练池，这样训练池条数会膨胀到远超 32 条，但总 token 预算和 B 组对齐。

这里有个实操细节：切分窗口之间要不要重叠？我试过不重叠和 50% 重叠两种。不重叠的切分更干净，但可能把跨窗口的依赖关系切断；50% 重叠能保留更多上下文，但会引入重复 token，让有效 token 预算打折扣。最后我选了不重叠切分，理由是这次实验的重点是样本数和 token 数的对比，重叠会引入额外的混淆变量，不如先把这个变量固定住。

3.3 开发集的 64 条怎么保证代表性

开发集 64 条是从清洗后的语料里独立抽的，和训练池完全不重叠。抽取时我做了分层：按样本长度分成短、中、长三档，每档按比例抽取，保证开发集里既有短样本也有长样本。这样评估时，A 组（擅长短样本）和 B 组（擅长长样本）都能在开发集上找到自己的"舒适区"，对比才公平。

注意：开发集一旦定下来就不要动。我见过有人跑完 A 组觉得开发集太难，换了一批样本再跑 B 组，这种操作等于把实验做废了。开发集是标尺，标尺不能中途换。

4. 训练配置：让两组对照只差一个变量

4.1 超参数的对齐清单

为了让 A 组和 B 组的对比有意义，除了数据组织方式，其他所有超参必须完全一致。我列了一份对齐清单，每次开新组之前逐项核对：

这里最容易出问题的是训练轮数。A 组每条样本短，一个 epoch 消耗的 token 少；B 组每条样本长，一个 epoch 消耗的 token 多。如果两组都跑同样的 epoch 数，B 组实际看到的 token 量会远超 A 组，对比就变成了"token 总量对比"而不是"样本数对比"。我的处理是：按总 token 预算折算训练步数，让两组在相同 token 消耗下比较。

4.2 学习率与 warmup 的微调

小规模实验里学习率特别敏感。我一开始用 1e-3，结果两组都发散，loss 直接飙到 nan。降到 3e-4 之后稳定了，但 A 组（短样本）的收敛速度明显比 B 组快，因为短样本的梯度噪声更大，反而起到了类似正则化的作用。这个现象在后面结果分析里还会提到。

warmup 步数我设的是总步数的 10%。小规模实验总步数本来就不多，warmup 太长会导致模型还没热身完就训练结束了。10% 是个比较稳的比例，既能避免初期震荡，又不会浪费太多步数。

4.3 显存与批大小的权衡

批大小 8 是在显存限制下试出来的。我试过 16，B 组的长样本直接 OOM；试过 4，训练太慢且梯度噪声过大。8 是个折中点。如果你显存更小，可以用梯度累积来模拟更大的批大小，但要注意梯度累积会改变梯度的统计特性，可能影响两组对比的公平性，所以两组要么都用累积、要么都不用。

提示：如果你的任务对批大小特别敏感，建议把批大小也作为一个对照维度单独跑一组，而不是混在样本数/token 数的对比里。变量一次只动一个，这是实验设计的基本纪律。

5. 结果解读：短样本的多样性红利与长样本的密度优势

5.1 准确率曲线告诉我的第一件事

跑完三组，把开发集准确率按训练步数画出来，趋势比我预想的更有意思。A 组（更多样本路线）在前 30% 的训练步数里涨得最快，很快就到了一个不错的平台；B 组（更多 token 路线）起步慢，但在后 50% 的步数里持续爬升，最终追平甚至略超 A 组；C 组（token 对齐的多样本）介于两者之间，前期比 B 组快，后期比 A 组稳。

这个趋势说明：短样本的优势在于早期快速覆盖模式，长样本的优势在于后期深挖依赖关系。如果你的训练预算有限、只能跑少量步数，优先选更多样本；如果你有足够的步数预算，长样本的后期潜力更大。

5.2 NLL 指标暴露的隐藏差异

准确率之外，NLL 的变化更值得琢磨。A 组的 NLL 下降很快但后期有点"钝"，说明模型对短样本的分布拟合得不错，但对长距离依赖的建模能力没被充分激发；B 组的 NLL 下降慢但更平滑，后期还在持续改善，说明长样本确实让模型学到了更细粒度的概率结构。

这里有个反直觉的发现：C 组虽然总 token 预算和 B 组对齐，但 NLL 并没有追上 B 组。原因是切分后的短样本丢失了跨片段的依赖信息，模型看到的"上下文"被切断了。这提醒我，token 总量相同不代表信息量相同，信息的组织方式本身就有价值。

5.3 一个容易被忽略的方差问题

小规模实验的方差必须重视。我每组用三个不同的随机种子各跑了一遍，发现 A 组的准确率方差明显大于 B 组。原因不难理解：短样本的梯度噪声大，模型对初始化更敏感；长样本的梯度更平滑，结果更稳定。这意味着如果你追求结果的稳定性，长样本路线更省心；如果你能接受一定波动、追求快速迭代，短样本路线更合适。

注意：表中的"基准值"是相对比较，具体数字随任务不同会变，但趋势在小规模实验里比较稳定。不要直接抄数字，要抄的是分析思路。

6. 踩坑记录：那些让实验白跑的瞬间

6.1 评估集泄漏：最隐蔽的坑

第一次跑的时候，我图省事，直接从训练池里抽了几条当开发集。结果 A 组准确率飙到 90% 以上，我还以为发现了什么惊天规律，仔细一查才发现模型把训练样本背下来了。这个坑的隐蔽之处在于，小规模实验里训练集和开发集的边界很容易模糊，尤其是当你只有几十条样本的时候。后来我强制要求训练池和开发集来自不同的原始文档，并且做了指纹去重，才把这个漏洞堵上。

6.2 训练轮数没对齐导致结论反转

第二次跑的时候，我忘了折算训练步数，两组都跑了 20 个 epoch。结果 B 组因为每条样本长、实际 token 消耗是 A 组的好几倍，准确率自然高，我差点得出"长样本更好"的结论。后来把 token 预算对齐重跑，才发现前期的优势其实是 token 总量带来的，不是样本长度本身。这个教训让我养成了一个习惯：每次开跑前先算一遍两组的 token 预算，写进实验记录里。

6.3 随机种子没固定带来的"假差异"

有一次我跑 A 组用了种子 42，跑 B 组忘了改回来还是 42，但中间隔了几天，代码里有个数据加载的随机打乱没固定，导致两次的数据顺序不一样。结果两组差异看起来很明显，实际上只是数据顺序的随机性。从那以后，我把所有随机源（Python、NumPy、框架层面）都统一固定，并且在实验记录里写明种子值。

6.4 显存碎片导致的间歇性 OOM

B 组的长样本对显存压力大，我遇到过跑着跑着突然 OOM 的情况，但重跑又好了。这是显存碎片导致的，不是配置问题。解决办法是在训练循环里定期调用显存清理，或者把批大小再降一点留出余量。小规模实验里这种间歇性故障特别烦人，因为它会让你误以为是数据或模型的问题。

7. 把结论落到实际项目里的决策框架

7.1 什么时候该优先加样本

如果你的项目处于早期探索阶段，数据标注成本还不高，或者任务本身对模式的多样性要求大于对单样本深度的要求，那么优先加样本是更划算的。具体判断标准可以看这几条：训练步数预算有限（比如只能跑几百步）、任务类型偏向分类或匹配、单条样本的信息量本身就不大。这种情况下，短样本的快速覆盖能力能让你在最短时间内看到效果。

7.2 什么时候该优先加 token

反过来，如果你的任务涉及长文档理解、多轮对话、代码生成这类强依赖上下文的场景，或者你的训练步数预算充足、追求最终的精度上限，那么把 token 拉长更值得投入。长样本的代价是单步训练更慢、显存压力更大，但换来的是模型对长距离依赖的建模能力，这个能力在短样本上是练不出来的。

7.3 一个可复用的实验模板

把这套流程抽象一下，你可以直接拿去改：

1. 确定总 token 预算和总训练步数预算，这是你的"货币"。
2. 固定开发集，做去重和分层，评估口径统一。
3. 设计至少三组：多样本短序列、少样本长序列、token 对齐的多样本。
4. 除数据组织方式外，所有超参对齐，随机种子固定。
5. 每组跑三个种子，记录均值和方差。
6. 按训练步数画曲线，看的是趋势不是单点。
7. 结论落到"在什么预算下选什么路线"，而不是"哪个绝对更好"。

这套模板的价值在于，它把"加数据"这个模糊的动作拆成了可量化、可对照的决策。你不需要大算力，也不需要复杂的基础设施，一张卡、几百条样本、一个下午就能跑完一轮，拿到属于你自己任务的结论。

我个人在实际操作中的体会是，数据规模实验最怕的不是结论不对，而是结论不可复现。把变量控制住、把随机源固定住、把评估口径统一住，哪怕规模再小，结论也是可信的。反过来，规模再大，只要有一个变量没控住，跑出来的数字就只是噪声。