1. 为什么长文本编码绕不开滑动窗口：上下文窗口的硬约束

1.1 模型不是"一口吞"，输入长度天生有上限

从零手搓大模型，做到文本编码这一环，很多人卡在第一道坎：为什么不能把一整篇文章直接塞给模型训练？

答案是：模型内部的所有张量维度，在设计时就已经被写死了。以经典的Transformer结构为例，位置编码是预先定义好最大长度的，注意力矩阵是batch size乘以序列长度再平方的显存消耗。假设你设定最大序列长度为512，输入一篇5000字的文章，要么硬撑到显存爆炸，要么在数据预处理阶段就把长度压到目标尺寸。

这就是滑动窗口登场的理由——它是训练样本构造阶段的"裁纸刀"，把长文本按固定规则切成一段段等宽的Token序列，让模型每次只"读"一个固定长度的小片段。这里需要强调一个容易被忽略的细节：切割的对象不是按"句号"或"段落"来切，而是按Token（词元）的整数编码序列来切，也就是标题里说的"数字采样"。

1.2 直接截断的代价：上下文断层与学习信号被撕碎

如果你图省事，直接对长文本做"从开头截取目标长度"的操作，会立刻踩中两个问题。

第一个问题是覆盖不全。一篇2万Token的文档，只取前512个Token，意味着后面19000多个Token内容完全消失在训练数据里。模型永远学不到文档中后段的信息，这种浪费在数据积累阶段是不可接受的。

第二个问题更隐蔽：上下文断层。长文本的语义往往是连贯的，比如一篇技术教程先讲原理，再讲配置，最后讲排错。如果你在第512个Token处一刀切，恰好把"原理"和"配置"之间的承上启下切断了。模型正在学习"因为A，所以B"的逻辑链条，结果A的开头学到了，B的结尾也学到了，中间最关键的联系被硬生生拆成两份不相干的数据。更糟的是，切出来的第二段开头是"配置"的中间部分，它在没有任何背景的情况下强行成为独立样本，模型学出来就是前后逻辑断裂的碎片。

滑动窗口解决的就是这两个问题：通过按固定步长滑动，让窗口之间保有重叠区域，确保长文本的每个位置都能被模型看到，同时相邻窗口之间存在连续性，模型能学到跨越窗口边界的上下文关联。

2. 窗口大小与步长的数学关系：三种主流滑法与覆盖公式

2.1 先建立一个直观的"滑窗"心智模型

想象你面前有一卷很长的电影胶片，胶片上按顺序写着密集的字符。你的读片机一次只能看固定宽度的一段画面，比如512格。读完当前这段，机器向右前进一定格数，再看下一段。这个"前进格数"就是步长（stride），"每次看的宽度"就是窗口大小（window_size）。

这个类比的重点是：步长可以小于、等于或大于窗口宽度。步长比窗口小，前后两段就有重叠；步长等于窗口宽度，两段首尾相接、互不重叠；步长大于窗口宽度，中间会漏掉一部分内容。

在模型训练中，窗口大小往往由模型的max_position_embeddings决定，也就是位置编码能表示的最大长度。比如你设计模型时给了512的位置编码，那窗口大小基本就固定在512。步长由你根据数据量和训练成本来控制。

2.2 三种主流滑法：无重叠、固定重叠、随机起点

我把实践中常见的滑法整理成一张对照表，方便你直接抄作业：

样本数量的精确公式是：

n_samples = max(0, floor((total_len - window_size) / stride) + 1)

举个例子：一段1200 Token的文本，window_size=512，stride=256。

n_samples = floor((1200 - 512) / 256) + 1 = floor(688/256) + 1 = 2 + 1 = 3

三个样本的区间分别是[0:512]、[256:768]、[512:1024]，能看出来它们两两之间都重叠了256个Token。

2.3 重叠度的本质：数据冗余与训练成本的对赌

重叠区域其实是一种有意的数据冗余。每次滑动，前一段窗口的后半部分会成为下一段窗口的前半部分。这意味着这部分Token被模型反复学习，跨边界的依赖关系会被强化。代价是训练数据量上升，每个epoch消耗的时间变多。

在实际操作中，我见过两种极端的翻车案例。一种是把stride设成window_size的1/8，数据量膨胀到原来的8倍，显著拖慢训练节奏，但模型收益并没有同比例提升；另一种是图省事把stride设成等于window_size，省了算力，但模型在长文档上的连贯性明显变差。

我的经验是，在预训练阶段，stride取window_size的一半到四分之一是比较稳的区间。具体选哪个值，要看你的语料冗余度。如果语料里本身重复内容多（比如爬虫抓取的网页正文夹杂大量页脚版权信息），重叠可以少一点；如果语料是小说、论文这种每句话都有语义价值的，重叠就多一点。

3. 数字采样采的到底是什么：Token ID 序列与窗口边界处理

3.1 先分词，后取数：数字采样的真实对象

标题里的"数字采样"，很多人会误解为是对原始文本里的字节或字符做采样。其实不是。

原始文本先要被分词器（Tokenizer）处理。分词器把一句话拆成一个个Token，每个Token对应词表里的一个整数编号。比如"你好世界"经过BPE分词可能变成["你"，"好"，"世界"]，对应ID是[1024, 556, 88]。这一串整数ID，才是滑动窗口真正操作的对象。

这一步非常关键，因为滑动窗口切在字节层面和切在Token层面，结果完全不同。如果切在字节层面，一个汉字占3个UTF-8字节，512字节的窗口可能只装得下170个汉字，而且有可能把一个汉字截成两半。如果切在Token层面，512个Token能装下大概200到500个汉字（取决于中英文混合比例和分词粒度），且不会产生"半个词"的问题。

所以滑动窗口采样器的输入，永远是分词之后得到的整数列表，而不是原始字符串。这一步是所有后续操作的前提。

3.2 窗口内怎么放数据：单段连续、跨段拼接与大文档打包

拿到一批窗口区间后，每个窗口里的Token序列怎么组织成模型输入？有三种常见做法。

第一种是单段连续。一个窗口严格取自一篇文档的某个连续区间，不掺任何其他内容。这种做法最干净，适合语料中单篇文档都很长、且彼此独立的情况。

第二种是跨段拼接。当文档很短，比如一篇新闻只有120个Token，而窗口是512时，你可以把多篇短文档按顺序拼进同一个窗口，填满512为止。但拼接时一定要在文档之间插入特殊分隔Token，比如常见的<|sep|>或<|endoftext|>。否则模型会学到"两篇毫无关系的文档之间毫无边界"，在生成时就会把不相关的话题串到一起。

第三种是大文档打包。把一篇长文档滑出来的多个短窗口，先标记好文档的归属关系，再决定是否允许重叠。有些框架为了减少padding浪费，会把多个短窗口拼接成一个超长的batch样本，这时就需要额外的segment标记来告诉模型每个位置属于哪篇文档。

3.3 文档边界陷阱：窗口滑过边界时最容易被忽视的错误

这是我实际踩过的一个坑，值得单独拿出来讲。

假设一篇文章有480个Token，window_size是512，stride是256。从头开始，第一个窗口是[0:512]，但原文只有480，不够512。这时候强制从0开始取样，窗口会缺最后32个Token。如果你为了凑满512，直接把下一篇文档的开头补进来，或者在末尾补一堆padding token，问题就来了：模型会学到"文档到480Token左右就该结束"这种虚假模式，以及"文档末尾紧跟着padding"这种无意义关联。

更隐蔽的版本是：使用全局的滑动窗口，不区分文档边界，窗口跨越了一篇文档的尾部，滑进下一篇文档的头部。这种情况下，模型学到的是一个混合样本：前半段在讲财报分析，后半段突然跳到菜谱。连续滑几步，文档边界处会被反复污染，模型对文档边界的建模能力直接崩塌。

正确做法是先遍历所有Token，为每个Token标记它属于哪篇文档。然后滑动窗口取样时，如果窗口跨越了文档边界，就把末尾部分丢弃，保留窗口内完整属于同一篇文档的Token，剩余位置用padding补足，或者在下一个起始位置跳过边界标记继续滑。一定要让"窗口内的语义边界尽可能等于文档本身的结构边界"。

4. 从零实现一个滑动窗口采样器：代码、边界判断与验证

4.1 基础实现：给定Token序列输出窗口样本

直接用Python写一个朴素版本，逻辑一目了然：

def sliding_window_simple(tokens, window_size, stride): """ 对一维Token ID列表做滑动窗口采样。 tokens: list[int], 单篇文档分词后的整数序列 window_size: int, 每窗口的Token数 stride: int, 每次窗口向右移动的Token数 返回: list[list[int]], 每个元素是一个窗口内的Token ID列表 """ samples = [] start = 0 n = len(tokens) while start + window_size <= n: samples.append(tokens[start:start + window_size]) start += stride return samples

这个版本有一个明确的取舍：最后一段不完整的窗口直接丢弃。对于长度接近窗口整数倍的文档，这样处理问题不大。但对那些长度恰好卡在窗口边界附近的文档，末尾几百个Token会被永远丢掉。

来测一下：

tokens = list(range(0, 1200)) # 模拟1200个Token，ID从0到1199 samples = sliding_window_simple(tokens, window_size=512, stride=256) print(len(samples)) # 3 print(samples[0][0], samples[0][-1]) # 0 511 print(samples[1][0], samples[1][-1]) # 256 767 print(samples[2][0], samples[2][-1]) # 512 1023

注意输出结果：最后从1024到1199这一段（176个Token）被丢弃了，因为它们凑不满512。

4.2 改进版：末尾补齐与末段回溯

要解决尾部丢失，有三种策略：

策略一：padding补齐。把最后一段不足512的Token补到512，padding位置用专用ID（比如词表末尾的<|pad|>）。这种做法的缺点是如果整篇文档本来就很短，会产生大量padding样本，模型学半天全是padding模式。

策略二：末段回溯。当剩余Token不够一个窗口时，把起始位置往回移，让窗口恰好终止在文档末尾。比如上例中剩余176个Token，就把起始点改成1200-512=688，取[688:1200]。这样文档末尾也被完整覆盖了一轮。代价是末尾段和其他窗口重叠比较大，但反正重叠本来也是滑动窗口的特性。

策略三：改变最后一段的结束条件。当剩余长度小于window_size但大于最小阈值（比如256）时，仍然取样本但标记为短样本；小于阈值就直接丢弃。

完整的增强版代码：

import math def sliding_window_advanced(tokens, window_size, stride, tail_strategy="trace_back"): """ 增强版滑动窗口采样，处理末尾不足一个窗口的情况。 tail_strategy: "drop"放弃末尾 / "pad"末尾补齐 / "trace_back"回溯起点 """ samples = [] n = len(tokens) start = 0 while start < n: end = start + window_size if end > n: if tail_strategy == "drop": break elif tail_strategy == "pad": window = tokens[start:n] # 用词表最后一位ID作为padding，实际项目里要换成专用pad_id window += [99999] * (window_size - len(window)) samples.append(window) break elif tail_strategy == "trace_back": start = max(0, n - window_size) window = tokens[start:n] samples.append(window) break samples.append(tokens[start:end]) start += stride return samples

用同一组数据来测trace_back策略：

samples = sliding_window_advanced(tokens, window_size=512, stride=256, tail_strategy="trace_back") print(len(samples)) # 4 print(samples[-1][0]) # 688 print(samples[-1][-1]) # 1199

输出结果为4个样本，最后一个覆盖[688:1200]，文档末尾的内容终于进入训练数据了。

4.3 验证采样正确性的三个小测试

写完采样器，不能只看样本数量，还要验证采样逻辑确实符合预期。我通常做三件事。

第一，覆盖测试：确定所有有效Token是否至少出现在一个窗口里。用集合求并集即可。

covered = set() for s in samples: covered.update(s) print(len(covered), "/", len(tokens)) # 1200 / 1200，说明全部Token都有至少一次曝光

第二，重叠率测试：统计相邻窗口的重叠Token数。对于stride=256、window_size=512，重叠部分应为256。

overlap = len(set(samples[0]) & set(samples[1])) print(overlap) # 256

第三，文档边界测试：验证窗口没有跨越文档边界。把文档按ID范围划分为多个区间，检查每个窗口是否完整落在某一个区间内。这一步在拼接短文档时尤其重要。

5. 真实训练中的滑动窗口调参：踩过的坑和坚信的原则

5.1 步长不是越小越好：训练速度与数据冗余的博弈

回到实际训练场景。我见过有人为了追求"充分的上下文连续性"，把stride设成window_size的1/16。结果一个epoch的训练步数直接翻16倍，训练周期从两天变成一个月，但模型困惑度下降并不明显。

原因是：重叠区域里模型学习到的知识是高度重复的。前一个窗口已经见过的Token，在下一个窗口里作为前缀再次出现，模型确实能强化"记住前面发生了什么"的能力，但这种强化在重叠率达到一定程度后会边际递减。再往后，你只是在让模型反复复习同一批内容。

实际操作中，我会先在1/10规模的语料上做小实验，分别用stride=64、128、256（window_size=512）跑一个epoch，看验证集loss差异。如果128和256的loss差不多，说明128的连续性增益并不值回时间成本，直接用256。

5.2 短文档占比高时，拼接操作比想象中麻烦

如果你处理的语料是新闻、评论这类短文本，一篇文档只有几十到一百多个Token，而window_size是512，那么每个窗口至少需要拼三四篇文档。这时除了加分隔符，还要考虑两个细节。

第一个细节是顺序一致性。拼接时文档的顺序如果每次都随机打乱，模型学到的"上下文"是人为制造的随机跳转，这有助于提升泛化性；如果你希望模型学习到"同一主题的文档彼此关联"，则应该按主题聚类后再拼接。两种思路没有绝对对错，但你必须明确自己的目标。

第二个细节是EOS标记的放置。每篇文档拼接完后，不仅要加分隔符，通常在整篇文档的结尾还要放<|endoftext|>这个特殊Token，告诉模型"这段内容到此为止"。注意不要把endoftext和sep混用，前者表示全文结束，后者只表示文档切换。

5.3 随机种子和shuffle顺序的坑

滑动窗口采样器跑出来的样本顺序，是严格按照文档顺序和窗口起点递增排列的。如果你直接把这种顺序喂给模型，同一篇文档前后窗口会出现在相邻的训练步中，模型相当于在短时间内反复看到几乎相同的内容，会对这些样本产生严重的过拟合。

正确做法是：先对文档顺序做shuffle，再对每个文档内部窗口的起始偏移做随机化。更彻底的做法是先把所有采样结果汇集到内存，统一打乱后再分批。但要注意，如果语料很大，统一打乱会带来额外的内存和IO开销。我常用的折中方案是：按文档粒度shuffle，文档内部窗口按起始位置随机取偏移，这样既保证了长文档内部的连续性得到利用，又打破了长文档训练时的顺序单调性。

最后一个容易被漏掉的细节是随机种子的固定问题。每次跑实验，滑动窗口采样的随机种子要保持一致，否则你在对比实验时，模型效果差异可能只是因为看到的数据顺序不同，而不是因为算法本身改进了。我在工程里会把seed和采样参数一起写进实验配置里，保证实验可复现。

关于滑动窗口的数字采样，核心就这些：窗口大小由模型结构决定，步长由训练策略决定，边界处理由语料特性决定。这三个参数凑齐，采样器才算真正能用。后续如果要做分布式训练，还得在采样器输出多路样本接收器后，配合流式数据集分派样本，但这都是后话了。先把单机版本的滑动窗口写好，文本编码这条路就走稳了一半。