上一节我们把tokenizer的手艺活儿捋了一遍字符怎么拆、BPE怎么合并、词表怎么定心里大概有数了。但S07这一季的核心还没解决文本编码真正要面对的是一个序列从原始字符串变成embedding向量之前的那些中间步骤。E03要聊的滑动窗口数字采样恰恰是其中最容易被跳过、却又最影响训练效果的一环。先别急着搓Transformer块先把输入端的窗口和采样这两个问题想明白。因为大模型训练和推理时模型的序列长度是固定的但真实语料长短五花八门。一个三万字的公众号长文肯定比一条商品标题长得多。你总不能把整篇长文一股脑塞给模型也不可能对每条短标题都用满2048个token。怎么办靠滑动窗口去切靠数字采样去选。这就是E03存在的意义——实现一个能控制数据长度分布、能保留上下文衔接、又能调节样本数量的文本编码前置模块。这一节适合谁看不管你是要复现GPT系列的数据预处理流程还是想给自己的小模型搭训练管线甚至只是想把超长文本喂给已有模型推理滑动窗口这套逻辑都是绕不开的。我会沿着一贯的“从零手搓”风格把原理讲明白把代码写出来再把踩过的坑挨个拎出来说。1. 为什么文本编码阶段要引入滑动窗口1.1 一次能看多长编码器说了算你要理解文本编码就得先理解一个事实大模型的输入长度不是物理上的纸张大小而是模型架构决定的硬约束。对于标准Transformer来说序列长度直接决定了注意力矩阵的大小。self-attention的计算量是序列长度的平方空间复杂度也一样。如果你把序列长度从512拉到4096计算量直接翻64倍显存也跟着暴涨。所以模型在设计之初就会指定一个max_sequence_length比如LLaMA常见的2048GPT-3的2048较新的LLaMA-2升级到了4096。这个上限值就是滑动窗口的“物理边界”。文本编码阶段无论你拿到的是500个token还是500万个token最终送入模型前都必须被切成长度不超过上限的片段。没有滑动窗口就只能做两件事短于上限的直接全量塞入长于上限的要么截断前N个token要么随机抽一小段。截断和随机抽样的坏处非常明显——长文档的语义往往分布在后半段开头截断会丢掉核心内容随机抽一小段又会丢失上下文连贯性而且会造成训练样本之间的信息重复率极高。我举个实际项目里的例子。当时我在处理一批工业设备操作手册平均每份手册约8000个token模型上限是2048。如果直接截断到2048几乎每份手册都只看得到首页的目录和简介模型训练周期再长也学不到设备维护步骤和故障排查部分。后来我把那份语料重新用滑动窗口切分之后每个操作步骤和参数说明都被完整保留在至少一个窗口里训练出来的模型对故障描述的应答能力提升肉眼可见。滑动窗口的本质就是把“一次只能看一段”的约束转化为“每一段都能被看到”的机会。它不是让模型一次性读长文档而是让文档的每一部分都有机会出现并且相邻窗口之间保留一定的重叠让上下文信息能够通过训练样本的连贯性传递下去。1.2 窗口之间为什么要重叠如果仅仅是切分那直接按固定长度一刀切不就行了不行。问题在于自然语言是强连续的。一个句子的开头在上一个窗口结尾在下一个窗口如果两个窗口之间完全不重叠模型就永远看不到一句话的完整面貌。对训练来说这是灾难性的信息撕裂。重叠设置的直接好处是防止“语义断层”。举个例子一段文本是“今天下午三点在第二会议室召开项目进度会议”如果你的窗口大小是8个token步长也是8个token那么第一个窗口可能是“今天下午三点在第二会议室召”第二个窗口就是“开项目进度会议”——“召”和“开”这两个字符被硬生生拆到两个窗口里。虽然tokenizer不一定分得这么细但语义被切开的情况是真实存在的。更严肃的问题是主题漂移。长文档的章节结构往往存在“铺垫-转折-结论”如果一个转折词落在窗口边界前一个窗口还在讲问题背景后一个窗口突然就在讲解决方案模型学到的因果链就是不完整的。重叠窗口保证了上下文信息的冗余——下一窗口的开头一段token其实是上一窗口的结尾模型有更多机会从不同切法里学到完整语义。那重叠多少合适我在实际项目里通常让重叠率保持在50%到87.5%之间。低重叠率比如步长为窗口的75%适合数据量大、希望覆盖更多差异样本的场景高重叠率比如步长为窗口的12.5%适合单个文档重要、需要尽可能保住语义连续性的场景。这部分的选择逻辑我在第2节里用具体数字算法给你详细拆开讲现在你只需要记一个结论没有重叠的滑动窗口等于没有滑动。2. 滑动窗口数字采样的核心参数与计算2.1 三个关键参数窗长、步长、重叠率滑动窗口三个关键数字参数是窗口大小window_size、步长stride、重叠率overlap_ratio。它们之间的关系非常简单overlap window_size - stride overlap_ratio overlap / window_size换一种写法就是stride window_size * (1 - overlap_ratio)。这三个参数一旦确定一个语料库会被切出多少窗口就是确定的事了所以它们在工程上其实属于“数字采样”的第一层参数该切多大、该走多远、该重叠多少全部是用数字来控制的采样过程。我给出一组我在本地训练2B模型时用过的参数组合你感受一下参数取值说明window_size1024对齐模型的训练序列上限留出pad空间stride256也就是重叠率75%保留语义冗余min_length128小于这个长度的文本不参与滑窗切分sampling_rate0.85滑窗产出的窗口有85%会进入训练集random_seed42控制采样的可复现性窗口数目的计算方法是对一个长度为L的token序列以步长stride滑动窗口会产生ceil((L - window_size) / stride) 1个完整窗口。注意这里必须是完整窗口——如果token序列长度不足window_size那就不能假拼凑要么整段保留要么丢弃这取决于min_length的最低长度限制。具体算一次给你看。假设一份语料的token序列长度L 10000window_size 1024stride 256那么完整窗口数就是ceil((10000 - 1024) / 256) 1 ceil(8976 / 256) 1 ceil(35.06) 1 3636个窗口每个窗口长1024 token那么这36个窗口的总token量就是36864 token而原始语料只有10000 token。数据量膨胀了3.68倍。这就是滑动窗口的副作用之一“数字采样”能不能扛住这份膨胀就得看第二层采样策略了。2.2 数字采样采样率、种子与样本分配的计算我刚才说的“第二层采样策略”才是标题里“数字采样”的真正核心。滑动窗口负责切数字采样负责筛。切出来的窗口不能全量进入训练原因有两个一是数据量会过度膨胀模型反复见过度重复的上下文学习效率反而下降二是某些窗口内容确实没啥训练价值比如大量重复的水军文案、列表式堆砌的商品参数。数字采样要做的事情就是给每个窗口一个可复现的得分然后根据得分决定进不进训练集。我惯用的方案有三个维度文本长度权重、随机哈希筛选、数值分布校准。文本长度权重好理解。短文本切出来的窗口少长文本切出来的窗口多如果直接全量采样长文档会在数据集中占据压倒性优势模型会变成“长文档专家”而不是“通用语言模型”。所以我给每个窗口乘一个长度惩罚系数win_sample_weight base_weight * (min(seq_len, window_size) / window_size)这个权重会参与最终的样本采样。简单说越接近满窗长度的窗口权重越高凑不够长度的短尾巴窗口权重会明显下降让模型少吃“残料”。随机哈希筛选是保证可复现的关键。直接用Python的random模块也可以但要注意一旦训练时修改了语料顺序或者并行shuffle的逻辑同一个窗口的inclusion状态就可能变化影响实验对比。我建议用窗口的起始位置语料ID做输入算一个哈希值再映射到采样概率区间import hashlib def decide_sample(doc_id, start_pos, sampling_rate0.85, seed42): key f{seed}|{doc_id}|{start_pos}.encode() digest hashlib.sha1(key).hexdigest() bucket int(digest[:8], 16) / 0xFFFFFFFF return bucket sampling_rate这样同一个窗口无论你跑多少次、无论在哪个机器上跑得到的采样结果是完全一致的。分布式训练的时候这个策略尤其重要——你不会希望因为多机shuffle顺序不同导致两台机器上的样本分布不一样进而影响梯度同步的稳定性。数值分布校准则是针对“数字”本身的处理。在大模型的文本编码阶段有一类很特殊的信息就是数字token。比如“价格1999元”、“误差0.03mm”、“温度25.6℃”。普通BPE tokenizer对数字的切分经常是随机的——1999可能被拆成“19”和“99”0.03可能被拆成“0”“.03”。这种拆法会让模型很难学到数值的大小关系。我的做法是在滑动窗口内部做一次数字token的统计和采样管束。如果一个窗口内的数字token占比过高比如超过15%常见于价格列表、参数表我就会以一定概率丢弃该窗口避免模型在这些“数字噪声”上过拟占比过低的窗口则可以适当提高保留概率。这样“数字采样”就不仅仅是筛样本还兼顾了数值信息的分布平衡digit_ratio num_digit_tokens / window_len if digit_ratio 0.15: keep_prob * 0.5 # 数字噪声过多降权 elif digit_ratio 0.02: keep_prob * 1.1 # 上下文信息更通用适当加权你看到这里滑动窗口和数字采样就结合成了一个完整方案滑动窗口决定一个样本的覆盖范围数字采样决定这个样本的质量和概率。两者的参数都落在数值计算上所以整个编码模块是可以写成纯函数式、可验证、可统计的。这对手搓大模型特别重要——每一层都必须是能解释、能测量的否则模型出了bug你都无从下手。3. 从零实现一个可落地的滑动窗口数字采样器3.1 数据准备与编码实际动手第一步从语料到token序列。这个过程我直接复用上一节里实现的BPE tokenizer接口假装你已经有了一个tokenize(text) - List[int]的函数。如果没有用HuggingFace的tokenizers库也一样无非是把encode换成自己的实现。我把处理流程写成三个阶段原始文本清洗、token化与ID缓存、滑窗切分。其中原始文本清洗要特别注意换行符。很多长文档里的换行符会占一个token清洗时如果全部转成空格可能把原本的语义边界抹掉如果保留又会在窗口切分时增加无效token。我的习惯是单换行保留为特殊换行符token连续两个以上的换行统一折叠成一个段落分隔token。对滑窗来说段落边界能自动让短窗口优先覆盖完整段落而不是从段落中间硬切。token化与ID缓存阶段有一个性能要点。如果你的语料是几GB级别的最好把每篇文档的token ID列表持久化到磁盘格式用numpy的.npy或者Arrow的二进制格式都行加载速度比纯文本快一个数量级。滑窗阶段需要频繁随机访问文本的任意起始位置如果每次都重新传入原文再tokenize整个预处理管线会慢到难以接受。实际上我踩过一次这个坑。一开始图省事直接edit数据流式处理每次滑窗都重新调用tokenizer处理10万篇文档就花了两天多。后来改成先全量token化缓存再滑窗同样的数据只用四个小时就全部跑完。文本编码阶段这种IO密集任务缓存策略比调参重要得多。3.2 滑动窗口切分实现这里我给出一个可以直接复制使用的窗口切分类。接口设计目标是传入一篇文档的token ID序列返回一组完整的窗口样本。每个窗口样本包含三个字段起始位置、终止位置、窗口内的token ID列表。class SlidingWindowSampler: def __init__(self, window_size1024, stride256, min_length128): self.window_size window_size self.stride stride self.min_length min_length def _full_windows(self, tokens): seq_len len(tokens) if seq_len self.min_length: return [] if seq_len self.window_size: return [(0, seq_len)] windows [] end self.window_size while end seq_len: start end - self.window_size windows.append((start, end)) end self.stride # 确保最后一段不遗漏 if windows[-1][1] seq_len: windows.append((seq_len - self.window_size, seq_len)) return windows def sample(self, tokens, doc_id, sampling_rate0.85, seed42): windows self._full_windows(tokens) results [] for start, end in windows: should_keep self._decide_by_hash( doc_id, start, sampling_rate, seed ) if not should_keep: continue results.append({ doc_id: doc_id, start: start, end: end, tokens: tokens[start:end] }) return results def _decide_by_hash(self, doc_id, start, sampling_rate, seed): import hashlib sample_key f{seed}|{doc_id}|{start}.encode() digest hashlib.sha1(sample_key).hexdigest() bucket int(digest[:8], 16) / 0xFFFFFFFF return bucket sampling_rate这里有一个细节end self.stride的循环里我用的是“窗口右端”不断右移起始点也随之右移。这种写法比“起始点依次加步长”更直观地避免越界问题。因为循环条件检查的是右端end seq_len保证每次形成的窗口都是完整填充的不存在padding凑数的情况。最后一个窗口的处理也需要注意。当循环结束后我额外判断了windows[-1][1] seq_len这保证了序列尾部那一段不被漏掉。有一种工程意见认为尾部不足window_size的部分是可以直接丢弃的因为收益太低。但我的经验是很多文档的结论恰恰集中在尾部宁可多生成一个窗口也别让关键结论彻底消失。不过这个窗口在下一步数字采样时长度会小于window_size长度惩罚机制会自动降低它的权重不会破坏分布均衡。3.3 采样策略与权重计算切分完成只是第一步还要给每个窗口算出一个最终采样权重。权重的作用有两个一是送入数据处理管线时按权重决定要不要保留该窗口二是在最终写入训练索引时可以按权重做非均匀采样让高价值的窗口被反复采样更多次。import math from collections import Counter class NumericSamplingStrategy: def __init__(self, window_size, discard_digit_ratio0.15): self.window_size window_size self.discard_digit_ratio discard_digit_ratio def compute_weight(self, window, digit_token_ids): token_len len(window) if token_len 1: return 0.0 len_weight token_len / self.window_size digit_count sum(1 for t in window if t in digit_token_ids) digit_ratio digit_count / token_len if digit_ratio self.discard_digit_ratio: len_weight * 0.5 elif digit_ratio 0.02: len_weight * 1.1 value_weight 1.0 / math.sqrt(token_len) return len_weight * value_weight这里digit_token_ids就是第2节说的数值分布校准的关键输入。你需要提前对你的tokenizer做一次全词表扫描把所有能匹配[0-9]、小数号、百分号、日期分隔符的token ID收集成一个集合。这个集合在滑窗之前构建好后面每个窗口计算时就是一次集合成员判断复杂度是O(N)全语料跑一遍也不会成为瓶颈。数字占比阈值的设定我有过具体的项目教训。当时一批电商评论语料里充满了“第1个”、“1号链接”、“9.9包邮”之类的表达数字token占比经常在20%到30%之间。如果直接用0.15的阈值几乎一大半窗口都会被降权数据量骤减四成。后来我把它拆成两层策略能整句保留数字语义的比如“误差0.03mm”提高保留度只是数字罗列的比如“1.2.3.4.”直接丢弃。具体的判断方法是看数字token之间的间隔是否小于等于2个非数字token。如果连续多个数字之间几乎没有间隔说明是在罗列数据不是正常表达。这在代码里实现也很简单丢给你一个参考判断逻辑def is_digit_list(window, digit_token_ids, max_gap2): last_pos -1 consecutive 0 gap 0 for i, t in enumerate(window): if t in digit_token_ids: if last_pos 0 and i - last_pos max_gap: consecutive 1 else: consecutive 1 gap i - last_pos - 1 last_pos i if consecutive 4: return True return False这个函数的作用就是识别“数字列表垃圾样本”。窗口里至少连续出现4个相距很近的数字token就认为该窗口大概率是数据罗列可以直接抛弃。实际项目里这一招过滤掉了不少低质量样本有效防止了模型在训练中把“数字List”当成了规律的文本模式。4. 实战避坑与调参经验4.1 边界截断带来的灾难滑动窗口最容易翻车的地方就是文本边界。我在早期版本里也犯过蠢直接用floor(seq_len / window_size)来确定窗口数量结果最后一个窗口因为长度不足被代码强行padding到window_size。这个假样本被丢进训练集后模型就学到了“一句话说完之后要跟一大串占位符”的诡异规律。更隐蔽的是当stride和window_size不是整除关系时尾部窗口的起始位置会跑到序列末尾附近如果处理不当会出现窗口重叠过多、大量重复内容反复进入训练集的情况。解决边界问题的最干净方案就是我前面代码里写的那种判断末尾余量低于min_length的整段丢弃不低于min_length的就单开一个从seq_len - window_size开始的尾部窗口。你别小看这个“从最后往前数一个窗口”的逻辑它能保证尾部信息完整、不跨越语义边界甚至在处理那种“后置结论”型文档时让模型有更好的机会学到总结性内容。我建议你在实现完滑窗后马上跑一个自检脚本统计所有窗口的起始位置分布和长度分布图。正常情况下长度分布应该只有两个峰值——一个是满窗口大小另一个是尾部残窗大小。如果出现第三个峰值说明你的边界逻辑漏了某种情况。不要嫌这个检查繁琐我通常在新语料接入时都会跑一遍花五分钟就能避免训练到第二天才发现数据出错的尴尬。4.2 采样率过低导致的收敛问题数字采样里的sampling_rate如果取得太低会带来一个很容易被误判为“模型能力不行”的问题。我有一段时间为了降低数据量把采样率从0.85调到0.5结果发现模型在验证集上的loss始终降不下来当时一度怀疑是模型架构有问题。后来查了训练数据流才发现因为采样率压得太狠大量低频但在语义上很重要的窗口比如罕见故障描述被筛掉了模型的有效语料覆盖度严重不足。这里有一个基本规律滑动窗口的采样率决定的是模型见过的上下文幅面的广度而训练时的batch决定的是每次迭代的多样性广度不足时重复batch再多也无法弥补。所以我现在的经验是如果语料总量是10亿token不要想当然地把采样率调到0.5去凑5000万窗口。宁可让数据量多到三十亿token然后配合NumericSamplingStrategy的窗口权重做非均匀抽样也不要粗暴砍掉一半的窗口。因为采样率过低会让采样随机性急剧增大模型练出来的能力方差也大——有的知识学得很扎实有的知识几乎完全没见过。顺便提一句如果确实需要控制数据规模优先考虑调整min_length而不是sampling_rate。把短于256token的噪音段落过滤掉远比均匀随机丢弃峰值窗口带来的信息损失更小。我处理过一份OCR扫描的PDF语料里面有大量残缺的页眉页脚文本段长度常常在50到100token之间这种东西对模型训练的贡献接近于零过滤掉它们相当于把有效数据密度提升了一大截。4.3 从实际项目对比中得到的参数推荐讲了这么多参数我给一个可复用的配置模板结合一个实际项目场景来说明。我做过一个领域大模型的训练语料铺设工作语料混合了3类数据维基百科类长文档、问答社区类中等文本、电商平台类短文本。三类文本的长度分布差异很大我用同一套滑窗策略跑下来发现不同类别的数据质量表现完全不同。语料类型平均长度(token)推荐window_size推荐stride推荐min_length长文档类5000-150002048512256问答类300-80051212864短文本类30-1001283216这里的关键规律在于window_size优先对齐模型训练时的最大上下文长度然后根据语料的平均长度调整stride。长文档用大stride因为窗口数量本来就多重叠率可以适当降低一点短文本用小stride否则一段100token的问答如果步长128它就只产生一个窗口语义信息压缩得太狠。对于训练LLM来说迭代批次的样本长度一致性也很重要。如果你把window_size设为2048但一批里混进了大量长度为128的短文本窗口显卡的计算利用率会非常差。因此我在实际构建DataLoader时还会按窗口长度做一次分桶bucket把长度差不多的窗口分到同一批里。这一步虽然不是滑窗本身的责任但如果没有分桶策略前面辛苦做的窗口切分就会在batch层面大打折扣。我还想再提一个容易忽略的细节多重窗口重叠过度的风险。当stride很小、重叠率很高时相邻窗口之间的大量token会重复出现导致训练集里出现高级别的重复n-gram。这会让模型学到一种“反刍”行为也就是生成时反复说同一句话。我用过一个简单指标来监控统计样本集中出现次数最多的100个8-gram。如果这些最高频的8-gram占比异常高说明重叠设置需要调整否则模型输出会出现病态的重复模式。检查方法也不难定期对一个采样后的数据子集跑一遍sklearn.feature_extraction.text.CountVectorizer把n-gram重复率打出来看一眼就好。不必每次都全量跑但每个训练阶段至少检查一次能让你提前发现数据泄漏或者过度重复的问题。我现在用的生产级配置已经变成了一套更工程化的方案滑动窗口切分、哈希采样、数字token统计、长度分桶四个步骤各自独立成模块中间数据用Arrow格式落盘。这样某个环节修改时不需要重新跑整个管线尤其适合你在多个实验配置之间来回切换时节省时间。这就是E03的全部核心内容。回到最初的问题——文本编码阶段你真正要处理的不是“文字本身”而是文字变成向量之前的所有数据形态决策。滑动窗口和数字采样这两个东西看起来只是数据预处理的零件但它们直接决定了你的模型到底见过什么、没见什么、见过几遍。我个人的经验是花一周时间把数据管线打磨到“每一个窗口都可以溯源、每一份样本都有统计依据”远比急着把Transformer堆起来更值得。