做 NLP 任务这些年有一个特别常见但又特别容易被忽视的环节把原始文本丢给模型之前到底应该做什么很多人习惯直接.fit()或者.train()结果要么报错说“Expected tensor, got str”要么训练出来的模型表现稀烂却又找不到原因。其实问题往往不出在模型结构上而出在输入侧——文本根本没被料理干净也没被转换成模型能吃的数字形态。这篇文章我就把这个过程完整地捋一遍从字符串到模型输入的张量中间到底隔了多远每一步为什么要这么做不做会怎样以及常见的大坑在哪里。内容面向两种读者一是刚开始碰 NLP、打算自己训练模型的新手二是已经跑通 pipeline、但总觉得哪里不对劲、想回头补基础的老手。看完你应该能对着自己的代码按图索骥地找出输入侧的问题。1. 内容整体设计与思路拆解1.1 预处理到底解决的是哪一类问题先说一个最核心的观念模型——不管是 Transformer、RNN还是传统机器学习模型——底层吃的都是数字而且最好是浮点数张量。字符串、空格、逗号、表情符号这些东西对模型来说全是“外星语言”。模型不会“理解”一个词的意思它只能看到一长串向量然后通过统计规律去捕捉向量之间的关系。因此把人类语言转换成机器能处理的数字形态是文本进入模型前必须跨越的第一道坎。这听起来简单实际操作中却很麻烦。因为原始文本的“脏”程度远超想象大小写不一致、标点符号混乱、URL和HTML标签混在其中、中英文混杂、特殊 emoji 乱入甚至还有全角半角的问题。如果不把这些干扰项清掉模型学到的规律会被噪声带跑偏。你可以把文本预处理类比成做菜前洗菜切菜菜不洗砂子入锅菜不切火候和调味都没法控制。预处理不是锦上添花而是决定成品质量的基础工序。还有一个不太直观但非常重要的问题词汇表的确定。模型能处理的词是有限集合里的词。你需要先把所有要出现的 token 统计一遍决定“模型认识的词有哪些”然后把每个词映射到一个整数 ID再转成 one-hot 编码或者 embedding 向量。这个映射表词典一旦定下来训练和推理都必须严格使用同一份否则就乱了套。这就牵出另一个概念——模型检查器。在实际工程里我拿到别人训练好的模型时第一件事往往不是直接用而是先检查它配套的词典和 tokenizer 配置确认它期望的输入格式是什么。词表大小、特殊 token ID、序列最大长度这些不核对清楚后面无论怎么推理结果都是错的。1.2 张量表示的终极目标文本预处理完成之后下一个关键问题是怎么把 token 序列变成张量。最标准的目标形态是(batch_size, sequence_length)的整数张量每个位置是 token 对应的索引再进一步经过 embedding 层后变成(batch_size, sequence_length, embedding_dim)的浮点张量。中间可能还会伴随 attention mask 之类的辅助张量用来告诉模型哪些位置是真实内容、哪些位置是填充的占位符。为什么批量要放在最前面这其实是为了计算效率。模型训练时一次处理一个样本太慢GPU 的并行能力发挥不出来。把一个批次的多条文本堆叠成一个矩阵可以一次性做矩阵乘法大幅提升吞吐。但这里有个麻烦一个批次里每条文本长度往往不一样而张量要求矩形结构不能有“锯齿”。因此需要做 padding——把短的句子用特殊占位符补齐到同一个长度。这是预处理阶段最后一个、也最容易被忽略的环节。我个人的体会是一方面要有“输入是整个数据流的上游”的意识另一方面要理解“模型不是万能的它只认数字规律”。预处理看似繁琐但每个细节都对应着一个真实的工程问题漏掉大小写统一可能让“Apple”和“apple”被当成两个词漏掉截断长文本可能让输入长度超出模型上限直接 OOM搞错 padding 方向可能让模型把“开始”和“结束”搞反。这些坑我都踩过有些甚至排查了一整天才定位到。写这篇文章的时候我把每一步背后“为什么这么做”也一并讲透希望你能少走这些弯路。2. 核心细节解析与实操要点2.1 文本清洗不是简单去掉标点就完事文本清洗是最基础但最容易被人做糙的环节。很多人觉得清洗嘛就是string.lower() 去掉标点完事。其实不同场景要清洗的内容差异很大处理不好会直接影响后续分词和词典质量。以英文为例几个典型的清洗点大小写统一不统一的话“Python”和“python”会被算成两个 token词典膨胀、数据稀疏。常规做法是全部小写化除非你处理的是代码或者有明确大小写语义的领域比如品牌名识别。标点符号去留这个要看任务。情感分析有时保留感叹号有信息量“great!!!” 比 “great” 情绪更强但如果做关键词提取或翻译标点通常直接去掉。稳妥的做法是先做实验对比留与不留在验证集上的差异凭数据做决定。URL、HTML标签、用户、emoji社交文本里全是这些东西。大多数 NLP 任务里它们都是噪声建议替换成特殊占位符或直接删除。比如 URL 替换成url用户替换成user这样语义上更干净还能保留“这里有一个链接”这个事实。全角半角转换中文场景经常遇到全角字母和数字混进文本不转换会在分词时产生奇怪的碎片。用unicodedata.normalize或简单的字符映射都能处理。清洗没有放之四海而皆准的流程我的建议是先写一个小脚本输出清洗前和清洗后的文本对比肉眼检查几遍确认没有误删关键信息再进入下一步。注意控制清洗强度过度清洗可能把上下文里的关键信号也删掉。比如在情绪分析中把 “not happy” 里的 “not” 误删了语义就完全反转了——这种情况我就遇到过清洗规则激进导致模型效果大跌最后逐条回滚才找到元凶。2.2 分词为什么你的分词结果这么碎分词是文本预处理的另一个核心环节也是前后端认知差异最大的地方。不同语言、不同任务分词策略千差万别。英文最朴素的做法是按空格切分。但这样 “don’t” 会被切成一个 token“machine learning” 则被切成两个。如果你做的是基于统计的模型这么切其实也能跑但词表会很大且稀疏。主流方案是 subword 分词代表性算法包括 Byte-Pair EncodingBPE、WordPiece 和 Unigram。它们的基本思想是不按完整单词切而是按出现的子词单元切既能控制词表大小又能处理未登录词。比如 “playing” 可能被切成 “play” “ing”哪怕遇到没见过的 “playfully”也能通过子词组合拼出来不会掉进 OOVout-of-vocabulary的黑洞。中文因为没有天然空格分词问题更复杂。传统的做法是结巴分词这类基于词典和统计的工具到了预训练模型时代很多中文模型直接以“字”为单位切分或者用 BERT 系的 WordPiece把常见汉字直接收进词表字和词混合。哪种好我的经验是如果你的任务偏短文本分类、情感分析字级分词通常就够了稳定、不容易出错如果做长文本理解或摘要词级信息可能更利于语义建模。但具体还得看数据量数据量少的时候字级更稳数据量大到一定程度词级能榨取更多语义。混合语言中英混合的文本很麻烦一个折中的方案是对中文用单字切分对英文用 subword 切分然后把两套结果拼接成一个 token 序列。工业界也有直接用 SentencePiece 做无监督分词的做法它把空格也当成普通字符处理在混合语料上效果不错。分词这一步没有绝对的标准核心原则只有一个确保训练和推理用的是同一个 tokenizer词表一致。这个我在生产环境里踩过坑——训练脚本用了 BERT 官方的 tokenizer服务端为了省事用了简单的空格切分结果线上输入分布变了指标掉了好几个点。2.3 词表构建与特殊 token不只是一个查表动作分词完成后就要建立一个从 token 字符串到整数的映射表。正常情况下你会统计训练集里所有 token 的出现频次按频次排序给每个 token 分配一个 ID。但这里有几个关键细节特殊 token 必须放在最前面比如pad、unk、bos、eos、mask等。它们有专门的作用ID 通常固定为 0、1、2、3…… 例如 PyTorch 的nn.Embedding默认会额外加一个 padding 位置的向量如果你的padID 不是 0就得手动指定padding_idx否则 padding 位的向量也会被更新白白浪费参数。未登录词处理模型总会在推理阶段见到训练集里没出现过的词。好的做法是把所有未知 token 统一替换成unk在词表里给unk留一个固定 ID。不这么做查表直接 KeyError程序崩溃。用 subword 分词时OOV 概率已经小很多但仍要兜底。词表大小上限词表越大embedding 层参数量越大。比如词表 5 万embedding 维度 768那么光 embedding 矩阵就是 5万×768 ≈ 3840 万参数占整个模型体积很大一块。所以词表大小要在“覆盖度”和“参数量”之间权衡。一般通过最小频次过滤来控制出现次数小于某个阈值比如 2 次或 3 次的 token 直接并入unk。词表的问题往往要到模型训练到一半才会暴露Loss 不降、指标怪异、甚至显存爆炸。我排查过的一个经典案例某人用中文语料训练分类器跑了一段时间发现 loss 居高不下一看词表发现里面全是不成词的“字碎片”——原来分词方案和词表构建用的不是同一个函数词表是拿字级结果构建的而训练时却用了词级分词。这种不一致只有靠日志审查和对比实验才能暴露靠直觉很难发现。3. 实操过程与核心环节实现3.1 从零构建一个完整处理流水线下面我用 PyTorch 把一个标准流程走一遍。假设任务是一个英文情感分类模型输入是若干条评论文本我们需要把原始字符串变成模型可以训练的输入张量。第一步先写文本清洗函数。我在这里做了一个适度清洗小写化、去掉 URL 和 HTML 标签、保留部分标点、统一空白字符。import re import html def clean_text(text: str) - str: text html.unescape(text) # 还原 amp; lt; 等实体 text re.sub(rhttps?://\S|www\.\S, url, text) text re.sub(r[^], , text) # 去掉HTML标签 text text.lower() text re.sub(r[^a-z0-9\s.!?], , text) # 保留基础标点 text re.sub(r\s, , text).strip() return text第二步分词。这里我直接演示 BPE 训练。实际工作中可以调用tokenizers库或transformers里现成的 tokenizer但为了展示原理我用tokenizers中的 BPE 来训练一个专属词表from tokenizers import Tokenizer, models, pre_tokenizers, trainers tokenizer Tokenizer(models.BPE()) tokenizer.pre_tokenizer pre_tokenizers.Whitespace() trainer trainers.BpeTrainer( vocab_size20_000, special_tokens[pad, unk, bos, eos], min_frequency2 ) # 假设 texts 是清洗后的语料列表 tokenizer.train_from_iterator(texts, trainertrainer) tokenizer.save(my_tokenizer.json)这个Trainer配置里的vocab_size20_000和min_frequency2是关键参数前者控制词表大小后者过滤低频 token。词表太大的话embedding 层会吃掉大量显存词表太小的话文本会被切得非常碎语义损耗严重。20k 对英文情感分类任务是一个比较稳妥的起手值。第三步把文本编码成 ID。这部分相当于把“词表映射”和“截断/填充”一起完成from transformers import PreTrainedTokenizerFast fast_tokenizer PreTrainedTokenizerFast( tokenizer_objecttokenizer, bos_tokenbos, eos_tokeneos, unk_tokenunk, pad_tokenpad, ) def encode(texts, max_len64): return fast_tokenizer( texts, max_lengthmax_len, paddingmax_length, truncationTrue, return_tensorspt, )这一步产出的input_ids就是一个(batch_size, 64)的形状类型为torch.LongTensor或者TensorType.PT下的torch.Tensor里面每一个数字都是词表里的索引。同时还会产出attention_mask长度为 1 的位置是真实 token0 的位置是 padding。到这里“文本变成张量”的原始目标已经完成了一半接下来把它送进模型。第四步简单模型实战验证。搭一个无比简单的 embedding 平均池化 线性分类器验证我们预处理出来的张量能否被模型正常消费import torch.nn as nn class TinyClassifier(nn.Module): def __init__(self, vocab_size, embed_dim128, num_labels2): super().__init__() self.embedding nn.Embedding(vocab_size, embed_dim, padding_idx0) self.classifier nn.Linear(embed_dim, num_labels) def forward(self, input_ids, attention_mask): embedded self.embedding(input_ids) # (B, L, D) mask attention_mask.unsqueeze(-1).float() # (B, L, 1) embedded embedded * mask # padding位置置零 pooled embedded.sum(dim1) / mask.sum(dim1).clamp(min1e-9) return self.classifier(pooled)这里有一个非常关键的细节embedded * mask。如果只对 input_ids 做了 padding但计算时不管 maskpadding 位置的向量也会参与平均池化等于往语义里灌了噪声。我在调试早期模型时经常遇到“验证集 loss 不降”的情况排到最后发现是 mean pooling 时没把 padding 位置 mask 掉。这个错法非常隐蔽batch 内句子长度差距越大噪声越严重。总之padding 只是形状上的补齐真正把 padding 排除在计算之外靠的是 attention_mask 后续所有显式的操作。3.2 中英文场景下的预处理差异与适配上面的流程以英文为例。中文场景里清洗和分词都要调整。中文清洗最需要注意的是全角字符和标点。中文文本通常不做小写化因为汉字没有大小写但字母部分还是要统一大小写。分词这块标准做法之一是用 jieba 做词级切分但主流预训练模型的 tokenizer 大多是字级或 subword 级。我的经验是如果基于 BERT 类模型微调直接用它自带的 tokenizer 最省事如果要自己从零训练模型建议用 SentencePiece 训练一个 unigram 模型它能在字符和词之间做一个合理的平衡。import sentencepiece as spm # 训练完bpe/unigram模型之后加载并编码 sp spm.SentencePieceProcessor(model_filemy_model.model) ids sp.encode(今天天气不错, out_typeint) print(ids) # 比如 [101, 2453, 3322, 1332, 102]这里要特别提一下中文任务里要不要把标点去掉也取决于下游任务。比如文本蕴含或问答标点可能有语法作用删掉会影响句法结构。但情感分类时“。”和“”保留与否影响不大去掉能降低序列长度提升训练速度。我最常用的策略是先把数字和字母统一为半角再把中文标点替换成空格最后按“连续的非空白字符”作为词或字的分割。另外一个很实际的细节训练和推理时的编码长度上限要保持一致。我见过不少项目训练时设max_len128但部署时为了省计算资源把max_len改成 64结果截断位置的文本分布被打乱线上效果立刻下降。长度上限不是随便改的要么训练部署都改要么都别动。3.3 张量表示进阶从索引向量到 embedding 的完整链路预处理结束后模型内部究竟怎么处理这些索引张量这里值得花点篇幅解释清楚因为不少人卡在“为什么 input_ids 能直接送进 Embedding 层”这个问题上。input_ids里的每个整数是词表中的一个位置。Embedding 层本质上就是一个巨大的查询表形状是(vocab_size, embedding_dim)。输入 id 数字 5查询表就返回第 5 行输入 id 数字 1024就返回第 1024 行。这在 PyTorch 里用nn.Embedding(weight)可以很方便地实现视觉效果就像按图索骥地取一行行向量。得到 embedding 之后模型通常还会叠加位置编码。这里要敲黑板Transformer 等模型不具备天然的词语顺序感知能力所以需要额外把位置信息灌进去。位置编码分两类一类是绝对位置编码比如正余弦函数或者可学习的绝对位置 embedding另一类是旋转位置编码RoPE现在大量主流模型都用 RoPE。RoPE 的思想是把位置信息以旋转矩阵的方式做进 Q、K 向量里简单说就是“通过旋转词向量来标记位置”这样模型能自然地建模相对位置关系外推到更长序列时也更友好。最后整体张量会流经多头自注意力、前馈网络等模块。这些模块对输入的要求非常单纯一个(batch, seq, hidden)的浮点张量外加一个 mask。可以说从原始文本到张量表示整个流水线最后的出口就在这一步。你要盯住的目标是给模型的张量必须是干净的、有明确含义的、形状正确的。3.4 预训练模型输入与本地模型的槽位对齐近年来越来越多的人选择把开源预训练模型拉下来做微调或者本地部署。比如你会看到一些项目里用 Ollama 拉qwen2.5:7b或者部署ChatGLM、LLaMA等开源模型。这些模型的权重和配置文件里自带了它们专用的 tokenizer 和词表。强烈建议除非你从头训练否则不要自定义分词器直接用模型仓库里配套的。我在实际操作中会先加载一个模型检查器比如 HuggingFace 的transformers里AutoTokenizer和AutoModel然后打印tokenizer.all_special_tokens和配置里的max_position_embeddings。这些信息告诉你它支持的最大序列长度、特殊 token 的 ID 和位置也告诉你模型的 embedding 矩阵到底多大。几个容易踩坑的地方用错词表手动下载模型文件后只拿了权重.bin忘了拿vocab.txt或tokenizer.json导致加载 tokenizer 失败。这种错误在本地离线部署时尤其常见。max length 超限模型支持的上下文长度有限。比如老一代 BERT 是 512你想着“我的语料平均 800 词”不截断直接塞进去结果所有超长样本在注意力计算时触发形状错误。遇到这类情况要么截断要么改用支持长文本的模型。pad token 缺失不少开源预训练模型在预训练阶段根本没有定义 pad token比如 GPT 系列典型只定义了|endoftext|。微调的时候需要手动设置 pad_token否则做 batch 编码时直接报错。“对齐”这个词在深度学习里通常指张量维度对齐但在工程上我更愿意把它理解成“模型的输入习惯和你的数据格式相互匹配”。本地部署开源模型时看一下config.json对着model_max_length、bos_token_id、eos_token_id这些字段检查一遍花不了多少时间但能避免后面各种莫名奇妙的报错。4. 常见问题与排查技巧实录4.1 序列长度该选多少一条关于截断和不截断的权衡max length 的确定不是拍脑袋随便选的。我的建议是先对训练数据的 token 序列长度做一次分布统计看四分位数。比如 75% 的样本序列长度在 60 以内95% 在 128 以内那max_len128就是比较合理的选择。设置太长训练速度和显存都吃亏设置太短部分长文本会被粗暴截断丢掉后文关键信息指标明显下滑。实际操作中有个取巧办法如果你的任务是短文本分类比如句子对匹配、新闻标题分类直接max_len64起步如果处理对话、长文档先看长度分布再说。另外部分模型支持滑动窗口比如长文本任务里对超长输入做窗口切片这类方案可以绕开 max_len 限制但实现复杂度和推理代价都上去了。如果只是普通任务我建议别碰滑动窗口老老实实做截断。4.2 模型报 shape mismatch八成是 padding 和 mask 没搭配好shape mismatch 是我在群里答疑时排第一的高频问题。报错信息通常是 “size mismatch for tensor” 或者 “The size of tensor a must match the size of tensor b”。绝大多数情况下问题出在两个位置输入层你的input_ids形状是(batch, seq_len)但某些代码里少打了 batch 维度变成了(seq_len,)模型里所有带 batch 维度的操作全部爆掉。解决办法打印input_ids.shape确认是三维还是二维该unsqueeze(0)就加。交互层比如分类任务里你对每条句子做池化后丢进全连接层。池化输出维度是(batch, hidden)但分类层输入要求(batch, seq, hidden)就会报 mismatch。解决办法是明确你是在序列维度上池化还是在 batch 维度上池化。这类问题靠肉眼盯代码有时候很难发现。我的习惯是先print(model)看结构再在 forward 里插print(x.shape)逐层打印定位到出错的层。排查 shape mismatch 时第一件事不是改代码而是把输入 shape、mask shape、模型每层期望 shape 按顺序列出来对一遍。4.3 训练 loss 不降预处理侧的隐性信号模型训练不收敛很多人第一时间调学习率、换优化器、改层数却忽略了一个可能性预处理给模型喂了脏数据。我在多次跨项目调试中总结了三个隐藏问题标签错位文本和标签在清洗、分词、切 batch 的过程中错位了。比如你用多进程预处理但 shuffle 时把(text, label)对应关系弄丢了。这种情况 loss 通常会在一个较高水平震荡偶尔还会出现极端的 spike。词表泄漏构建词表时不小心混入了验证集或测试集的数据导致模型在语料分布上“作弊”——训练时 loss 降得很快验证集却表现奇差。这属于数据泄漏非常隐蔽。排查方法检查词表中的 token 是否只在验证集出现。如果是说明切分数据时没有先分割再建词表。序列大部分是 padding如果你的 batch 里句子都特别短但 max_len 设得很大那么一个 batch 里可能有 90% 的位置是 padding。经过 mask 后虽然没有噪声但有效信息密度太低模型梯度更新方向非常不稳定。解决办法动态 padding也就是每个 batch 按该 batch 内的最长序列来 padding而不是全局固定到某个 max_len。4.4 实战排查attention_mask 与 padding_mask 的混淆这是一个非常典型、普遍而且让人头大的坑。很多框架实现里提到 attention_mask这里说的是 Transformer 内部的 mask它和预处理阶段生成的 attention_mask 其实都叫 mask但作用不同很多人容易混淆。预处理阶段生成的attention_mask形状是(batch, seq_len)值为 0/10 表示 padding 位置或者被 mask 掉的位置1 表示有效 token。在 HuggingFace 的代码里这个 mask 通过-10000这样的极大负数做 off-diagonal 惩罚让注意力权重在被 mask 的位置上趋近于 0。逻辑本身不算复杂但一旦你把 mask 传错位置、或者忘了传给模型模型就会把 padding 位置当成有效 token 来注意结果各种诡异行为甚至训练不收敛。我在调试中见过的最隐蔽案例有人在预处理时用的是二值 mask0/1但另一位同事在标注时使用 padding_mask1 表示 padding两者方向正好相反。模型内部默认处理 1 表示有效的 mask结果 0/1 反了整个注意力机制完全失效。排查技巧在训练的 step 里打印一次输入 mask 和标签和手算结果对比重点检查“1 是有效还是 pad”的方向约定。4.5 长文本的窗口切分与信息丢失长文本任务比如文档分类、摘要需要处理超过模型 max_len 的输入。常见做法是滑窗切分也就是说把一个 2000 词的文档切成多个 512 的窗口然后分别过模型再聚合成文档级表示。实现思路不复杂但有两个很实际的坑边界截断导致语义断裂比如一个句子被切成了两半模型在窗口前半部分看不到句子的后半部分语义不完整。改进方式尽量从句子边界切或者设置窗口重叠overlap比如每次滑 100 的步长保留上下文重叠区域。聚合策略影响最终效果对窗口 embedding 做 max pooling 还是 average pooling还是直接首尾拼接效果差异很大。一般先试 average pooling如果效果不理想再试 weighted pooling按句子的重要程度加权。这部分没有统一答案跑实验最靠谱。另外做长文本之前可以先考虑能不能压缩输入。比如用 TextRank 抽关键句只保留 top-K 句再送给模型。这类“预处理侧降维”往往比无脑滑窗速度快得多效果也不差。经验是能抽关键信息的任务就抽不能抽的再滑窗。这算是我在长文本处理上最实用的一条心得。5. 实操经验补充与工具链推荐5.1 Hugging Face 生态最省心的流水线方案如果你不想从零手写 tokenizer建议直接拥抱 Hugging Face 的datasetstokenizerstransformers三件套。数据集的加载、分词、padding、截断几乎都能用几行代码完成。对新手来说这是最稳定的起步方式。用到的几个核心 API 值得记住from datasets import Dataset from transformers import AutoTokenizer dataset Dataset.from_dict({text: texts, label: labels}) tokenizer AutoTokenizer.from_pretrained(bert-base-uncased) def tokenize_fn(batch): return tokenizer( batch[text], truncationTrue, paddingmax_length, max_length128, ) dataset dataset.map(tokenize_fn, batchedTrue)注意padding参数的三种取值max_length是固定长度填充适合形状硬性要求一致的场景longest是动态填充到 batch 内最长序列速度快、显存省do_not_pad是不填充。我平时跑实验默认paddinglongest因为这样 batch 内有效信息密度最高训练速度明显快于固定长度。但如果你想用torch.compile或者需要固定的计算图可能还是得max_length。5.2 保存与加载模型和预处理配置必须绑定在一起训练完模型保存时不能只存权重。预处理配置tokenizer 文件、词表、max_len、pad token 设置一定要一起保存。否则你会陷入一个非常尴尬的局面模型参数加载成功了但推理时发现词汇表对不上只能重新处理数据甚至重训模型。推荐的做法是用 Hugging Face 的save_pretrained和from_pretrained接口来保存/加载整个目录它会自动把tokenizer.json、config.json、模型权重打包在一起。如果是纯手写的词表用torch.save或者 JSON 把 vocab 对象单独存一份并在服务启动时先核对版本号或 MD5。我在实际部署中遇到过最坑的一次训练时用的 Python 3.8 环境和 tokenizers 库 0.10 版本线上环境是 Python 3.10 tokenizers 0.13加载同一种 tokenizer 文件后生成的 ID 竟然不一样因为两个版本里 Unigram/BPE 的 fallback 逻辑有差异。从那以后我的原则就是快速验证时可以用 pip 最新版但正式训练和部署必须锁版本最好连 tokenizer 序列化结果都提前固化一次并测试一遍。5.3 数据增强与预处理结合多一步翻转多一份鲁棒性对文本任务做数据增强本质上是对预处理产出的 token 序列做扰动。常见的做法有同义词替换、随机插入删除、随机交换相邻 token、对英文做 back-translation。不过要注意增强策略里任何改变语义的操作都可能伤害模型性能比如把“not interesting”替换成“boring”可能还好但把“not good”里的“good”替换成“fine”就保持了否定结构而把“not good”直接替换成“bad”则彻底改变了原句的细粒度语义。保守的建议是先用一次简单的随机 token 交换或 dropout看验证集效果再决定要不要增加幅度。另外不少库会提供“分词后增强”的接口直接在 token ID 层面做替换或删除。这样做的优势是速度快、实现简单但也容易产生不通顺的伪样本需要你根据验证集效果来判断是否使用。5.4 模型蒸馏与预处理的一致性师生模型必须共用一套输入规则这几年模型蒸馏特别热门——用一个大的教师模型教一个小学生模型。很多人只关注蒸馏损失怎么算却忽略了一个最基础的问题教师模型和学生模型的输入规则如果不一致蒸馏效果会大打折扣。举例教师模型是 BERT 系列要求 token 序列以[CLS]开头、[SEP]结尾学生模型如果是一个自己从零训练的 BPE 模型输入序列没有这两个特殊 tokenteacher 的输出分布和学生学习的分布就对不上学到的只是“噪声分布”。正确的做法是教师模型和学生模型共用同一个 tokenizer或者在蒸馏之前把学生模型的词表初始化为教师的子集。实际操作中我一般用教师 tokenizer 对学生数据做预处理然后用教师输出的隐藏状态或概率分布作为 soft label让学生模型去拟合。这一套流程跑通之前建议先在小规模验证集上人工检查一下同一个句子在两个模型的 tokenizer 下产生的 ID 序列是否一致或至少对齐。一致性检查永远是蒸馏的第一步没有对齐就没有蒸馏。6. 一些心里话预处理不是小事张量思维是根本回头看我这些年做 NLP 的经验文本预处理与张量表示听起来像是最基础、最没技术含量的工作但实际上它决定了模型天花板。模型结构再花哨如果输入侧是乱的后面全部白搭。数据处理几行代码的改动往往比调一周模型结构更能涨点。我见过不少新手一开始就追求“高级模型”把主要精力放在调 Transformer 结构、设计 loss 上结果被一个小小的 tokenizer 版本问题卡了一整天。真正务实的工作流永远是先把数据做到位再谈模型。对于文本预处理与张量表示这条链路建议你把标准操作流程内化成肌肉记忆先清洗再分词再建词表再 padding/mask最后转张量。每一步都留日志、做小样本验证确认前后一致再放大规模跑。如果你有条件可以在训练开始前跑一个前向小实验构造两条长度差异很大的文本打印它们的 input_ids、attention_mask、embedding 结果肉眼核对一遍 padding 位置在数值上确实没有参与计算。这个小动作能帮你规避未来至少 80% 的输入侧 bug。最后再分享一个小技巧所有预处理函数第一行永远是打印输入和输出的形状。真到排查问题的时候你会感谢这个习惯的。