做“从零手搓大模型”系列做到第七个赛季文本编码这条线上我踩过的坑比写过的代码还多。S07-E03这一篇咱们聊一个听起来很简单、做起来容易翻车的小东西滑动窗口的数字采样。它夹在分词和Transformer编码器之间负责把一串不定长的token向量切成局部窗口再用数字采样的手段把每个窗口压成更紧凑的特征表示既控制序列长度又保留局部语义。它在长文本编码、定长特征抽取、轻量级文本向量化里都有实际用途适合正在手写分词器、自己搭编码器、或者想把sequence变短再喂给注意力机制的朋友参考。我不会只给结论会从原理讲到可运行的PyTorch代码再把工程里的坑一个个列清楚。1. 为什么文本编码需要滑动窗口的数字采样1.1 一个奇怪的名字滑动窗口为什么和采样凑在一起初次看到“滑动窗口的数字采样”很容易懵滑动窗口不是网络协议里那个重传机制吗数字采样不是信号处理里的概念吗怎么跑到大模型文本编码里来了先解释名字。这里的“数字采样”不是生成文本时那个“随机采样”而是从一段离散序列里按规则抽取或聚合信息类似把一段语音按固定时间窗切成帧、再把每帧压成一个特征向量。文本经过分词和embedding之后得到的是形状为(batch, seq_len, d_model)的向量序列。我把它看成一段“数字信号”横轴是token位置纵轴是语义维度。滑动窗口就像一个放大镜一次看一小段局部片段然后从片段里“采”出一个或几个代表值窗口按步长往后挪最终产出一串更短的新序列。为什么要这么做最直接的原因是Transformer的注意力计算量随序列长度平方增长。把1万token直接塞进全局注意力显存和时间都要爆炸。另一个原因是局部语义聚合单独一个token经常携带的信息噪声很大把相邻若干token组成窗口再采样相当于做了一个局部平滑让后续编码器拿到的是更有稳定含义的片段特征而不是某个孤立token的向量。生活里有个特别贴切的类比想把一部两小时的电影做成一分钟预告片你不能每秒都保留得按固定间隔抽取关键画面还要保证每个片段之间的动作连贯。滑动窗口的数字采样干的就是这事只不过对象从画面换成了token embedding。1.2 编码链路里滑动窗口采样的三种位置在文本编码的完整链路里滑动窗口和采样可以在三个不同环节出现用途完全不一样别混在一起。第一个位置在token序列的输入侧也就是对切出来的token ids直接做窗口切分。比如把一段2048个token的文本切成4段512的片段每段分别编码再拼接。这种做法的好处是实现简单坏处是片段边界可能切断完整语义一个词被劈成两半。第二个位置在embedding特征侧就是这篇文章的主战场。分词之后先得到(batch, seq_len, d_model)的向量然后通过滑动窗口加采样把长度从L降到一个更小的L。这个位置最灵活因为窗口可以重叠、采样策略可以换、甚至可以用可学习的加权方式聚合不会破坏原始token的完整性。第三个位置在编码器输出侧对Transformer的输出做滑窗池化。这种做法常见于把变长输出压缩成固定大小的句向量像CLS的替代方案把最后一层输出按窗口切分再对每个窗口做mean或者max最后拼成一个定长向量喂给分类头或匹配头。这篇博文主要讲第二种因为它在“从零手搓大模型”的文本编码阶段最常用也最容易解释清楚参数设计和反向传播的关系。理解了第二种另外两种就是换一下输入输出位置而已。1.3 滑动窗口采样和Top-k采样可不是一回事很多新手看到“采样”两个字脑子里蹦出来的是大模型生成时那个top_k50、temperature0.8。这俩除了中文都叫采样底层完全是两码事。生成阶段的Top-k采样是概率性的模型在词表上输出一个概率分布你只从概率最高的一批候选词里随机抽一个抽完词就定下来了带随机性用于增加输出多样性。而滑动窗口的数字采样是确定性的它发生在编码阶段输入是已经算好的向量序列按窗口和步长做均值、最大值或步长抽取同一个输入永远得到同一个输出不存在随机性也不涉及词表。我用一个简单表格把区别列清楚方便你脑子里建立边界对比维度生成阶段Top-k采样编码阶段滑动窗口数字采样所在阶段解码器输出logits之后token embedding之后、编码器之前输入对象词表概率分布向量序列是否随机随机抽样确定性下采样/聚合主要目的增加生成多样性压缩序列长度、聚合局部特征是否可微通常不可微用Gumbel近似可微能正常反向传播如果你在做生成任务时把滑动窗口采样误当成Top-k采样去接loss大概率会出问题因为前者输出形状已经变了后者还等着处理词表概率。所以动手写代码之前先把概念边界钉死。2. 核心参数与数学原理解析2.1 窗口大小、步长、采样策略三件套实现滑动窗口数字采样真正的核心超参数只有三个窗口大小、步长、采样策略。窗口大小决定一次看多长局部片段步长决定窗口之间隔多远采样策略决定窗口内多个向量怎么变成一个或几个向量。窗口大小w是感受野。w越大每个采样点融合的token越多局部语义更完整但细节丢得也多。w1就是什么都不做w接近整个序列长度就等价于全局池化。实际使用时我通常从8到64这个区间起步具体看任务文本的平均片段长度。步长s决定窗口移动的速度也直接决定输出长度。当s w时窗口之间没有重叠每个token恰好被一个窗口覆盖一次这是最省算力的设置。当s w时相邻窗口有重叠相当于对同一段信息看了好几遍特征更平滑但计算量更大。当s w时窗口之间有间隔有些token会被直接跳过信息损失最严重一般只在需要激进压缩时使用。采样策略是三件套里最灵活的一个。后面专门开一小节讲但核心原则是均值采样适合整体信息均衡的场景最大采样适合关键词主导的场景步长采样适合目标就是降维、不想引入额外平滑的场景。2.2 输出长度的数学公式与重叠率计算在正式写代码前先把输出长度的公式定下来。给定输入序列长度L窗口大小w步长s不填充时输出序列长度L_out是L_out floor((L - w) / s) 1这个公式的前提是最后一个窗口必须完整覆盖w个token窗口起始位置最大是L - w。如果你的策略是允许最后一个窗口不完整那可以换成ceil((L - w) / s) 1或者干脆用填充把长度补到能整除。重叠率的计算公式是overlap (w - s) / w当w64, s32时重叠率就是(64-32)/64 50%相邻两个窗口共享一半token。当sw时重叠率为0输出长度变成floor(L/w)这是最快的方案也是很多长文本分段编码的默认选择。举一个具体数字帮助理解。假设输入L1024选择w64, s32那么L_out floor((1024-64)/32) 1 30 1 31。也就是说你把1024个token的序列压缩成了31个窗口向量每个窗口代表约64个token的局部语义但相邻窗口共享一半内容整体输入长度降到了原来的约3%。如果选择w128, s128那么L_out floor(1024/128) 88个窗口无重叠直接变成8个定长片段这个配置常和分段编码配合使用。2.3 三种数字采样策略的实现与取舍均值采样、最大采样、步长采样是滑动窗口数字采样最常用的三个策略。它们的实现差异只有几行代码但行为差异非常大选错会直接影响下游任务表现。均值采样在每个窗口内对所有向量做平均。它等价于把窗口内的token信息均匀混合对异常值不敏感梯度在窗口内是均匀分布的训练最稳定。它适合情感分类、语义相似度这类“整体意思比某个关键词更重要”的任务。最大采样在每个窗口内取每个维度的最大值。它保留的是窗口内最突出的特征信号等价于特征维度的“关键词提取”。它适合关键词强相关的场景比如关键词识别、异常片段检测。但它的缺点是梯度只回传到每个维度上值最大的那个token其他token几乎拿不到梯度窗口内大量信息被直接丢弃。步长采样更简单直接按窗口起始位置取出向量窗口内部不聚合。比如w64, s64时就是每64个token抽第1个token。它适合你已经通过其他手段做了局部聚合、现在只想降低序列长度的场景。它的问题也很明显单独一个token的向量噪声可能很大后面编码器容易忽略窗口内的上下文。三种策略我用参数对比列一下策略每个窗口输出信息保留方式梯度特点推荐场景均值采样1个向量窗口内所有token均匀混合梯度均匀回传语义分类、文本匹配最大采样1个向量保留每个维度的极值梯度稀疏只回传最大值token关键词识别、异常检测步长采样1个向量只保留窗口起始token梯度只流向抽中的token激进降采样、二次聚合2.4 边界与对齐Padding的四种玩法滑动窗口处理长序列时序列长度大概率不能刚好被窗口和步长整除最后一段会不够一个完整窗口。这时候有四种常见处理方式各有代价。第一种是尾部补零也叫zero padding。在序列末尾补上足够多的零向量让它能被完整滑完。实现最简单但补出来的窗口包含大量无效零值均值采样会被稀释最大采样因为零值不会成为最大值所以相对安全。第二种是反射填充也叫reflect padding。把序列尾部的数据镜像翻转补到末尾窗口看起来像连续信号语义上比补零更平滑。但它会增加一点计算量并且会让窗口边界出现“重复但对称”的假象。第三种是重复末尾token也叫replicate padding。直接复制最后一个有效向量来补齐。它最接近“文本还在继续”的假设适合长文本压成定长向量的场景但会让采样结果偏向尾部内容。第四种是截断直接从pad_to wstart L - w开始滑最后一个窗口不满的就丢弃。这种策略信息损失最大一般只在输入长度本来就远超所需时用。我在代码实现里默认用反射填充因为它在序列任务里表现最稳均值采样和最大采样都不会因为全零向量产生明显偏差。但要注意填充本身只是为了让计算形状合法真正决定语义的是采样策略对填充位置的处理所以后面讲mask对齐时会再强调一次。3. 从零实现滑动窗口数字采样模块3.1 模块在编码流程中的位置动手写代码前先把模块在整体流程里的位置摆清楚。一个典型的文本编码流程是原始文本 - 分词器 - token ids - embedding层 - 滑动窗口数字采样 - Transformer Encoder - 下游任务。滑动窗口采样层接收embedding层的输出形状是(batch, seq_len, d_model)。它的输出是一个更短的向量序列形状是(batch, L_out, d_model)后续所有模块不需要感知序列曾经被压缩过接口完全兼容。有些实现会把采样直接合并进embedding层比如对Embedding的权重做窗口平均。我不推荐这么做因为embedding层和采样层的职责应该分开前者负责把token映射成向量后者负责局部特征聚合。分开了你才能单独调试采样策略而不需要重新训embedding。3.2 用PyTorch实现可微的滑动窗口采样层直接写一个可以直接放进模型的PyTorch模块。我选择基于torch.nn.functional.unfold的思路先通过as_strided生成窗口视图再对窗口维做池化。下面是我在项目里用的一个精简版本import torch import torch.nn as nn import torch.nn.functional as F class SlidingWindowSampler(nn.Module): 滑动窗口数字采样层。 输入: (batch, seq_len, d_model) 输出: (batch, L_out, d_model) def __init__(self, window: int, stride: int, mode: str mean): super().__init__() assert mode in {mean, max, stride}, funsupported mode: {mode} self.window window self.stride stride self.mode mode def forward(self, x): # x: (B, L, D) B, L, D x.shape w, s self.window, self.stride # 反射填充保证最后一个窗口完整 pad_len (w - (L - w) % s) % s if pad_len 0: x F.pad(x, (0, 0, 0, pad_len), modereflect) L L pad_len # 计算输出长度 L_out (L - w) // s 1 # 用 as_strided 切出窗口视图 # 形状: (B, L_out, w, D) strides (x.stride(0), s * x.stride(1), x.stride(1), x.stride(2)) windows x.as_strided((B, L_out, w, D), strides) if self.mode mean: return windows.mean(dim2) # (B, L_out, D) elif self.mode max: return windows.max(dim2).values # (B, L_out, D) elif self.mode stride: # 只取窗口第一个位置 return windows[:, :, 0, :] # (B, L_out, D) raise ValueError(self.mode)这个实现有几个细节值得说清楚。第一as_strided不复制数据只是改变内存视图所以整个前向过程非常快不会产生额外的窗口拷贝。副作用是返回的tensor是原tensor的视图如果后面要修改它需要先.contiguous()复制一遍。第二F.pad的反射填充在L - w小于0时会报错也就是序列长度比窗口还短的情况。真实场景里一般不会发生但你在写通用模块时得加一个保护分支序列太短就直接跳过采样。第三stride模式其实只需要x[:, 0::s, :]就能实现写成窗口视图是想保持接口统一。如果你追求极致简洁步长采样可以直接一行搞定。3.3 用卷积的思路实现数值更稳的滑动窗口采样as_strided很好用但有一个潜在的风险它在某些版本的PyTorch里如果strides算错会产生未定义行为。而且可读性一般。另一个更稳、更容易被团队同学理解的实现方式是用一维卷积加池化。均值采样等价于卷积核全为1/w的Conv1d最大采样等价于MaxPool1d。具体点说class ConvBasedSampler(nn.Module): 基于卷积和池化的滑动窗口采样效果和上面对齐。 这种方式比 as_strided 更稳显存行为更好预测。 def __init__(self, window: int, stride: int, mode: str mean): super().__init__() self.window window self.stride stride self.mode mode def forward(self, x): # x: (B, L, D) x x.transpose(1, 2) # (B, D, L) if self.mode mean: # 通过 avg_pool1d 实现滑动平均 # 注意 count_include_padFalse避免 padding 影响均值 x F.avg_pool1d(x, kernel_sizeself.window, strideself.stride, padding0, count_include_padFalse) elif self.mode max: x F.max_pool1d(x, kernel_sizeself.window, strideself.stride) return x.transpose(1, 2)用avg_pool1d的好处是它内部处理了窗口形状和边界不需要自己写 pad 逻辑。count_include_padFalse这个参数在 PyTorch 里要特别注意它决定了均值池化在计算平均值时是否把填充的零值也算进分母默认是 True也就是补零会拉低均值这通常不是我们想要的。我自己在用补零方案时会显式设成 False保证每个窗口只对有效token求平均。卷积方案和as_strided方案在数学上等价但显存访问模式更规整。如果你关心推理延迟avg_pool1d通常更快。如果你需要可学习的加权窗口聚合把avg_pool1d换成一个kernel_sizewindow的Conv1d初始化为1/w训练时让模型自己学权重效果可能比固定均值更好。3.4 Mask跟着采样走别让填充值污染下游文本编码几乎总是带着attention_mask记录哪些位置是真实token、哪些是填充。滑动窗口采样改变了序列长度mask也必须同步改变不然Transformer编码器会把填充窗口当成真实内容去计算注意力。mask的处理原则很简单每个窗口的mask值由窗口内所有token的mask共同决定。如果窗口内有一个真实token这个窗口就应该被保留如果窗口内全是填充token这个窗口应该被mask掉。对于非填充的尾部窗口如果窗口内真实token数量很少你需要决定是保留还是丢弃。我习惯用“窗口内是否存在真实token”作为保留条件实现如下def sample_mask(mask: torch.Tensor, window: int, stride: int) - torch.Tensor: mask: (B, L)1 表示真实token0 表示填充token 返回: (B, L_out)1 表示窗口内有有效token0 表示全是填充 B, L mask.shape pad_len (window - (L - window) % stride) % stride if pad_len 0: mask F.pad(mask, (0, pad_len), modeconstant, value0) L L pad_len L_out (L - window) // stride 1 # 将 mask 切成窗口: (B, L_out, window) mask_windows mask.unfold(1, window, stride) # 需要先 pad to 2D return mask_windows.any(dim2).float()unfold是PyTorch里专门用来切滑动窗口的API其实比as_strided更适合做这个场景因为它直接返回一个带窗口维的tensor语义清楚。如果你的均值采样需要按有效token数做归一化那mask的作用就不仅是过滤窗口还要参与平均计算。正确做法是把窗口内的mask求和作为分母把embedding向量乘上mask后再求和。这个时候用masked_mean会比avg_pool1d更精确因为它完全不受填充值影响。后面实战我一般直接用masked方案省得为填充值专门调参。4. 工程实践训练与推理中的避坑清单4.1 窗口大小怎么选信息密度和算力的博弈窗口大小没有标准答案但有一个靠谱的起步区间。我的经验是短文本任务从8到16起步中等长度文本从32起步超长文本如果主要为了压缩算力再用128以上的大窗口。别一上来就照搬别人论文里的窗口大小因为Tokenizer的压缩率不同同样128个token在中文和英文里覆盖的语义长度差得很多。窗口太大会把一句话里不同子句的信息混在一起让采样结果变成一锅粥。窗口太小局部语义聚合的能力接近没有序列压缩效果也差。我实际调参时习惯先固定stride window / 2让相邻窗口保持50%重叠然后从32开始按倍数往上试。如果验证集指标在窗口变大时明显下降说明你的任务依赖细粒度token信息如果指标基本持平而训练速度大幅提升恭喜你的采样窗口找到了一个还能继续往上加的空间。4.2 采样策略的梯度陷阱MaxPool为什么会丢信息我一开始图省事很多任务都用最大采样因为它在小数据集上指标特别好。后来训练大规模模型时发现一个问题最大采样的梯度在窗口内只流向一个token其他token在反向传播时梯度为零。如果窗口内存在大量重复或高度相关的token最大采样会让某些token长期拿不到梯度对应的embedding维度更新极慢表现为loss训练到某个阶段后停滞。均值采样的梯度是均匀分布在窗口内所有token上的训练更稳定但代价是会把少数关键token的强信号稀释掉。一个折中办法是使用加权平均给每个token一个可学习的权重让模型自己决定窗口内哪些位置更重要。我试过用初始权重为均匀分布的Conv1d替代固定均值收敛速度会慢一点但最终效果通常更好。还有一个容易被忽略的坑max_pool1d在反向传播时只回传最大值的索引位置。如果你在采样之后又做了残差连接梯度回传会从一个窗口只经过一个token的路径回流这条路一旦反复被选中某些维度会比其他维度学习快得多最后产生隐性偏置。所以在深层Transformer前做最大采样我会格外小心必要时候宁可选择均值。4.3 滑动窗口采样和滑窗注意力不是一回事好多朋友看完代码会问这不是和SwiGLU、滑窗注意力类似吗还真不是。滑窗注意力是保持序列长度不变只限制每个token只能看周围固定范围内的token解决的是注意力扩散导致的计算量问题。滑动窗口数字采样是缩小序列长度输出token数量本来就变少了后续每两个token之间的距离在原始序列里被拉远。两者可以叠加使用但顺序很重要。我的经验是先用滑动窗口采样把长序列压到可计算范围再在压缩后的序列上做滑窗注意力效果最好。反过来先滑窗注意力再采样注意力已经在小范围内聚合过一遍采样再压缩就不容易出问题但多了一轮完整的前向计算性价比不高。如果你在做一个非常长的文档级别的编码任务可以考虑一个三层结构第一层用大步长采样快速降维第二层用均值窗口聚合局部语义第三层再交给滑窗注意力。这个结构很像图像里的多尺度特征金字塔每一层都在不同粒度上提炼信息实验效果明显好于单层大窗口采样。4.4 性能优化别再用Python循环切窗口新手最容易写出这样的代码windows [] for i in range(0, L - w 1, s): windows.append(x[:, i:iw, :]) out torch.stack(windows, dim1).mean(dim2)这个写法在短序列上没什么问题但序列一长就原形毕露。Python循环每迭代一次都有解释器开销窗口数量上万时光循环就比计算本身慢了一个数量级。实际项目里请用as_strided、unfold或者avg_pool1d这些都是纯C实现速度差距能到10倍以上。显存方面也有优化空间。as_strided不产生额外拷贝是最省显存的。unfold会生成(B, L_out, w, D)的完整视图如果你的L_out * w很大显存会爆。avg_pool1d是逐窗口计算的不需要一次性展开所有窗口内存占用最平稳。我自己的经验排序是追求极致速度用as_strided追求稳定用avg_pool1d基本不会用unfold做超大窗口的显存敏感任务。还有一个容易忽略的优化点如果采样层后面接的是固定长度的Transformer且你的采样参数永远不变你可以在数据处理阶段先算好窗口索引表甚至提前把embedding序列切好缓存起来。这样训练时采样层直接查表取数省掉每次前向的pad和切窗计算。这个优化在数据加载是瓶颈的任务里有奇效。5. 常见问题与快速排查5.1 问题速查表一行一个坑我把实际工程里经常遇到的问题整理成一张速查表排查的时候可以直接对照。症状可能原因解决方案输出序列长度比预期多1填充公式写错L_out计算用了ceil而不是floor统一用1 (L - w) // s别让边界条件漂移均值采样后所有特征都变小count_include_pad默认把填充零计入分母设置count_include_padFalse或改用masked mean最大采样训练时部分token梯度恒为0窗口内最大值索引固定其他token无梯度换均值采样或用可学习加权卷积Mask没有跟着变注意力看到全填充窗口只采样了embedding忘了同步采样mask用窗口内any操作重建mask反射填充报错输入比窗口还短序列长度小于windowF.pad无法反射输入过短时先判断直接返回原序列或全局池化显存随窗口数线性暴涨用了unfold生成大窗口视图改用avg_pool1d或as_strided推理速度反而比不用采样还慢循环切窗口Python解释器开销过大换成卷积或池化实现5.2 两个亲测有效的调试技巧第一个技巧用随机整数序列做“可重建性测试”。先用nn.Embedding生成一批固定token序列的embedding滑动窗口采样后再接一个反卷积或者简单的线性层尝试把采样序列恢复到原始长度。如果重建loss收敛说明你的采样层没有破坏太多原始信息如果重建loss始终很高说明窗口太大或采样策略丢了关键信息。这个测试能帮你快速判断一个窗口配置是否合理不用每次跑完整模型。第二个技巧对比“去掉采样层”和“加上采样层”两条训练曲线。做长文本任务时我先把采样层设成恒等映射window1, stride1跑50个step拿到baseline loss再切到目标窗口配置再跑50个step。如果loss突然跳高且长时间回不到baseline不是采样策略的问题就是mask和填充没处理对。如果loss和baseline差不多但训练速度明显加快说明这个窗口配置是安全的。这个方法在踩坑初期帮我省了非常多时间。5.3 两个小众但很实用的扩展思路如果你已经理解了基础版本这里有两个可以继续玩的扩展方向。第一个是把采样层做成可学习的“软窗口”不要直接用固定均值而是初始化一个window长度的可学习权重向量然后用归一化后的权重对窗口内向量做加权求和。这样模型可以自动学会窗口中央的token更重要还是窗口边缘的token更重要。我试过在语义匹配任务上这种软窗口比固定均值高1到2个点代价是每个窗口的求和变成逐元素乘加计算量略有上升。第二个是把多个不同窗口大小的采样结果拼起来形成一个多尺度表示。比如同时用window16和window64做两组采样对齐长度后concat再送入编码器。这在长文本里能同时保留短距离句法和长距离主题信息是我处理文档级分类任务时很喜欢用的一招。代价是输出维度变宽下游模块的输入维度要相应调整。6. 从零复现时的最后几句体己话真按这套流程自己从零写一遍我个人体会是最值得花时间的地方不是采样的代码实现而是窗口参数和mask对齐。代码部分半小时就能写完但window和stride怎么配mask怎么跟着同步采样策略怎么和下游任务匹配这三件事才是决定效果的关键。我再分享一个保守的默认配置如果没有任何先验知识先上window32, stride16, modemean同时mask用窗口内any策略。这个配置在大多数长文本编码任务里都不会太差跑通之后再根据验证集表现往两个方向调如果指标偏低把window调小到16如果计算量太大把stride调大到window的一半以上。这个思路比一上来就搜参数省太多事了。滑动窗口的数字采样不是一个花哨的技术但它几乎是长文本编码里性价比最高的一个组件。你把它的原理想通、参数调顺、mask处理到位后面再接Transformer编码器都会顺手很多。最后再补一句任何采样都会丢信息关键是丢哪些、保住哪些要刻意设计不要靠运气。