做文本数据预处理的人经常被误以为只是在写正则、调停用词表。实际上分词、子词切分、规范化与数据增强这几件事每一件都能决定模型最终能跑多好。我最近在做一个短文本分类的模拟项目数据量不算小模型也用了预训练模型结果折腾了整整两周最后发现所有问题的根源都出在预处理环节——不是模型不够强而是喂给模型的文本根本没被处理好。这篇东西适合谁看呢凡是自己拉过数据、自己训练过文本模型的人无论是做文本分类、情感分析、检索增强还是微调大模型只要被怎么清洗数据才靠谱为什么同样的数据别人训练出来效果比我好增强之后模型反而变傻了这类问题困扰过都应该能从这里找到一些线索。我尽量把原理、代码和真实踩坑都揉在一起讲不绕弯子。1. 分词这一步先想清楚你拿到的是哪一类文本1.1 中文分词与词典幻觉中文分词是预处理里最容易被高估的一环。常见的工具比如 jieba、pkuseg、HanLP各有各的词典和默认策略但很多人默认装好就用结果分词结果里充满了伪词。举个例子我做电商评论项目时商品标题里大量出现iPhone14ProMax这类词。jieba默认词典里没有这个东西会硬切成iPhone14/Pro/Max而实际上iPhone14ProMax作为一个整体在后面做关键词匹配时才有意义。这不是工具的问题是我没有场景化更新词表。正确做法是先收集领域词表再让分词器去加载自定义词。jieba 支持用户词典pkuseg 也支持自定义词表。但这里有一个坑用户词典不是越全越好。词典太大会引入大量低概率词汇导致分词结果反而变碎、变乱。我自己的经验是领域词表要按词频和一致性筛选而不是把商品名、实体名一股脑塞进去。1.2 英文分词的空格假设会失效英文处理看似简单用空格切分再去标点。但这个假设在真实语料里经常失效尤其是用户生成内容UGC。比如Im 要不要分成 I 和 mstate-of-the-art 里的连字符要不要拆纽约这样的中文地名夹在英文文本里怎么处理user https://t.co/xxx 这类 token 很多场景下该保留还是过滤我的做法是不要把分词看成一个万能步骤而是看成给后续任务准备的最小语义单元。如果后面接的是BERT这类子词模型那英文分词可以直接退化为按空格与标点切分剩下的交给子词模型处理。如果后面接的是词袋模型或传统机器学习模型那英文分词就要做得细一些比如用 spaCy 的规则器处理缩写和连字符。1.3 一个实用的分词选择策略我自己的经验一般会按任务类型来选任务类型推荐方案理由短文本分类 / 情感分析jieba 自定义领域词表词粒度直接特征清晰长文本摘要 / 篇章理解不切词直接用字符或子词避免累积切词错误英文通用任务空格 标点 规则处理给子词模型留空间专业领域医疗、法律、金融领域分词工具 实体词表扩充术语完整度决定召回这个表不一定放之四海而皆准但能帮你快速定方向。核心逻辑是分词工具本身不产生信息只是决定哪些字符组合被打包成一个单元。你打包得越合理后面的统计或模型训练就越稳打包得越乱后面的所有环节都在替你承担代价。2. 子词切分当分词满足不了模型的时候2.1 从OOV到词表爆炸分词之后紧跟着的一个重要问题用什么粒度把文本变成模型能读的向量传统做法是建一个词表把每个词映射成ID。但真实文本里的词是开放的新词、拼写变体、罕见词永远存在。词表开太小OOVout-of-vocabulary词表外词多词表开太大模型参数量涨得离谱。子词切分的出现就是为了解决这个矛盾。它不把词看成一个不可分割的整体而是把词切分成更小的子词碎片。例如unbelievably 可以切成 un, believ, ably这样一来即便模型没见过unbelievably它也能通过un-和believ这些片段猜出大致语义。这套思路和人类查词典时拆词根的方法很像。2.2 BPE、WordPiece 与 SentencePiece 的差别这块很多人只记住了名字没搞懂真正的区别。我简单说下本质BPEByte-Pair Encoding是一种自底向上的合并方法。先从单个字符开始统计文本中相邻字符对的出现频率每次把最高频的字符对合并成一个新符号重复直到达到目标词表大小。核心逻辑是贪心地把高频片段融合。WordPiece本质和 BPE 类似但合并标准不是共现频率最高而是合并后对整个词表的语言模型概率提升最大。它在 BERT 时代被广泛使用。SentencePiece并不是一种独立的切分策略它更像是一个框架——可以在这个框架里运行 BPE 或 Unigram 算法并且它会把空格也当成一个普通字符参与建模。这一点对中文、日文这种没有自然空格的语言相当友好。三者的关系可以用一张表直观总结算法合并依据是否把空格当字符典型使用者特点BPE字符对共现频率否GPT系列简单高效WordPiece语言模型概率增益否BERT需要预训练辅助SentencePiece基于子词单元的LM是T5、多语言模型对无空格语言友好你不需要把每个细节都背下来但需要记住选哪个取决于你的文本语言、是否需要处理多语言、以及你是否有能力训练自己的词表。2.3 训练自己的BPE词表时参数怎么定现在很多人直接用预训练模型自带的 tokenizer省事但遇到垂直领域医疗、金融、代码时预训练词表往往会浪费大量 token。比如BERT的词表里有大量通用词而对心肌梗死肾小球滤过率这类医学术语却拆得很碎。如果你决定训练自己的 BPE 词表有几个参数要留意vocab_size太小导致碎片化太大导致词表稀疏。我一般从 8k 到 32k 之间调中文语料 16k 通常是个不错的起点。min_frequency控制哪些字符对可以进入合并候选。调高它会过滤掉低频噪声但也会减小词表的领域覆盖度。normalization在训练词表之前是否先做了 Unicode 规范化、是否小写化。这些决定会直接影响切分结果。我自己的一个经验是先用小样比如10万条训练词表再用一个留出集检验恢复率round-trip tokenization rate也就是切分后再拼回原句的还原度。如果还原度很低说明词表太小或 min_frequency 设得太激进。2.4 中文任务要不要自己训BPE中文文本如果直接跑BPE效果经常很尴尬。因为中文天然是字级别的语言字本身就是信息密度很高的符号强行把词切成子词碎片很多时候只是在制造噪声。我的经验是分两种情况如果是用预训练中文BERT系模型直接用它的 tokenizer不做自定义BPE效果通常不会差。如果是自训练一个模型比如训练 T5 或 BART 类模型那么中文语料更合适的方式是训练 SentencePiece 模型并设置add_dummy_prefixFalse或按字符级全切分来初始化这样才能避免空格带来的奇怪行为。3. 规范化里的隐形杀器从Unicode到标点清洗3.1 处理顺序比处理规则本身更重要规范化是所有预处理里最基础但最容易被忽略的一环。我见过一个团队先做了小写化再做了 Unicode NFC 规范化结果把一些原本能区分的字符比如德语元音变音给合并了导致后面检索阶段出现信息丢失。规范化有一个通用的经验顺序按这个流程走基本不会出错先把文本从字节流解码成统一编码UTF-8。做 Unicode 规范化我一般用NFKC而不是NFC因为 NFKC 会把全角字符转成半角还能处理兼容字符。再做大小写转换、去重空格、去除控制字符。最后再做标点和特殊符号的清洗。这个顺序看起来简单但一旦颠倒会连续踩坑。3.2 半角全角、组合字符和控制字符全角字符是中文文本里最常见的坑。用户可能从Excel或PDF里粘贴文本逗号、括号、空格经常会变成全角状态肉眼看不出来但分词和匹配就会出问题。用 Python 的unicodedata.normalize(NFKC, text)可以一次性把全角转半角把一些兼容字母合并掉。组合字符也是个大坑。比如e后面跟一个 U0301组合重音符号和直接用éU00E9是不同的表示方式。视觉几乎一样但计算机里是两个不同序列。NFKC 可以把组合形式转成预组合形式减少后续匹配的复杂度。另外控制字符也不要忽略。很多从网页爬下来的文本里混着零宽空格U200B、零宽连字符U200D这些字符看不见摸不着会在分词时产生空 token也会在计算文本长度时干扰截断逻辑。我自己会专门写一个正则把这些不可见字符清掉。3.3 清洗规则流程化别再用一坨正则硬扛很多人写预处理脚本时喜欢把所有规则都堆在一个超级正则里。比如text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9。、], , text)这种写法的最大问题是不可复用、不可解释、不可回退。某天发现这条规则把温度-5度里的负号也去掉了你根本不知道是哪个步骤惹的祸。我更推荐的做法是把规范化流程拆成一个一个可插拔的函数每一步职责单一并且每一步都带上注释和日志。import re import unicodedata def unify_unicode(text: str) - str: 统一Unicode全角转半角组合字符转预组合字符 text unicodedata.normalize(NFKC, text) return text def remove_control(text: str) - str: 去掉控制字符和不可见字符 return re.sub(r[\x00-\x1f\x7f\u200b-\u200f\u202a-\u202e\u2060], , text) def normalize_space(text: str) - str: 合并多余空白去掉首尾空格 return re.sub(r\s, , text).strip() def clean_punct(text: str) - str: 保留基本中英文标点其他符号替换为空格 # 这里不要直接删标点替换成空格更安全避免单词被硬粘在一起 text re.sub(r[^\w\s\u4e00-\u9fa5,.!?;:。()\-], , text) return re.sub(r\s, , text)然后用一个流水线把这些函数串起来每个阶段都可以单独抽出测试。这样做的好处是如果将来某个环节出了问题可以直接定位到具体函数而不是在几百行正则里考古。4. 数据增强在不过度破坏语义的前提下扩充文本4.1 EDA的四板斧什么时候用、什么时候别用数据增强对文本任务不像图像任务那么普适因为文本是离散的随便扰动可能直接改变语义。EDAEasy Data Augmentation是里面最经典的组合包括同义词替换、随机插入、随机交换、随机删除。我在项目里实测下来的感受是同义词替换SR在长句子里稳定性和语义保持度最好因为它本质是局部替换只要同义词质量别太离谱整体句子结构不变。随机插入RI适合把句子变长用于长文本分类任务但插进去的词如果和上下文无关模型会把注意力浪费在噪声上。随机交换RS对短文本非常危险尤其是在中文里语序一换语义可能全变了。我打了他变成他打了我这已经不是增强是造谣。随机删除RD要慎用因为它会改变核心信息覆盖。我通常只在小样本或者面对过拟合时用删除比例控制在10%以内。如果你要用EDA强烈建议先拿一个留出验证集做AB测试不要想当然认为加了增强就一定更好。在某些任务里增强后的数据会让模型学到语义被扰动的不变式但这并不一定对应真实推理场景的噪声分布。4.2 回译效果好但别忽略成本与陷阱回译是我个人最推荐的一种文本增强方法尤其对于分类和相似度任务。思路很简单把中文句子翻译成英文再把英文翻译回中文得到语义相近但表达不同的样本。但回译有几个陷阱翻译错误会被当成增强多样性保留进训练集这等于把错误信息当正样本灌输给模型。回译后的句子长度波动很大有些句子翻译两轮后凭空多出一堆信息或者丢掉部分实体对实体敏感的任务比如命名实体识别尤其不友好。回译成本不低。如果数据集是百万级全部做回译性价比很低。我一般只在低资源类别上做比如某个分类只有几千条样本回译到两三倍就够了。判断回译质量有一个简单方法把回译后的句子与原句做一次相似度计算比如用 Sentence-BERT 类模型算余弦相似度低于某个阈值我一般设0.82的直接丢弃。这样能过滤掉大部分语义漂移样本但也会牺牲少量多样性。4.3 中文文本增强真正的坑同义词表质量很多人想在中文里复现 EDA先卡在第一步找一个好的同义词表。中文同义词表既没有英文 WordNet 那么丰富也没有明确的多义词消歧机制。你用便宜替换成廉价可能没问题但这家店便宜这句话里的便宜如果同义词表里有便利这个义项就会生成这家店便利语义完全偏掉。在实战中我的做法是自己做一个小规模的领域同义词表而不是直接用通用同义词库。比如做奶茶评论的情感分类人工整理好喝/口感佳/味道不错/赞这类同义词比自动替换的效果稳定得多。通用词表只在词性简单、语义单一的场景下能直接用。另外中文的否定词极其敏感。一个不喜欢被替换成讨厌还行但如果同义词表把不错替换成可以就可能在负面样本里引入中性或正面噪声。凡是涉及否定、程度副词的句子我建议要么不增强要么只做回译。4.4 增强之后必须做的质量过滤很多人做了增强就直接拼进训练集这是不对的。增强数据的质量参差不齐直接混入会拖垮模型效果。我的标准流程是先对增强后的句子做通顺度评估最简单的方式是用困惑度perplexity过滤语言模型算出来的分数越高越可疑。再做标签一致性校验。对于分类任务可以用一个之前用干净数据训练好的小模型预测增强数据的标签把预测结果和原标签不一致的样本剔除。最后人工抽检200条看看整体质量分布再决定要不要调整增强参数。这一步看起来费时间但能避免一个更严重的后果增强数据把模型的精度方差拉大训练十几次每次结果都不一样最后你根本不知道模型能力到底如何。5. 一套可直接照抄的预处理流水线附代码5.1 一个具体场景情感分类的原始数据假设你手上有这样一份数据从电商平台收集的用户评论包含商品名称、评论文本、评分。你计划做一个二分类情感分析标签由评分映射得到好评/差评。原始文本长这样【京东】美的电磁炉C21-RT2160 家用多功能电磁炉货到付款 很好用炒菜快!!! 收到货了颜值可以但是声音大客服态度一般般。 #晒单#主要还是便宜性价比可以我不会真的针对某个具体电商平台但这类文本里的问题非常典型包含商品名、平台名、促销关键词、emoji、多余标点、不规范空格。我们的目标是把这些文本清洗成适合子词模型输入的紧凑序列。5.2 流水线代码一个可插拔的预处理类我在实际项目中倾向于把所有预处理逻辑封装成一个类这样流程统一、便于复用。import re import unicodedata class TextPreprocessor: def __init__(self, do_segment: bool False, segmentorNone): self.do_segment do_segment self.segmentor segmentor def unify_unicode(self, text: str) - str: return unicodedata.normalize(NFKC, text) def remove_control(self, text: str) - str: return re.sub(r[\x00-\x1f\x7f\u200b-\u200f\u202a-\u202e\u2060], , text) def normalize_space(self, text: str) - str: return re.sub(r\s, , text).strip() def remove_special_markers(self, text: str) - str: # 去掉【】里的活动词、#话题#标签 等对情感判断无助益的信息 text re.sub(r【[^】]*】, , text) text re.sub(r#[^#]*#, , text) return text def clean_punct(self, text: str) - str: text re.sub(r[^\w\s\u4e00-\u9fa5,.!?;:。()\-], , text) return re.sub(r\s, , text) def lower(self, text: str) - str: return text.lower() def process(self, text: str) - str: text self.unify_unicode(text) text self.remove_control(text) text self.remove_special_markers(text) text self.clean_punct(text) text self.normalize_space(text) text self.lower(text) if self.do_segment and self.segmentor: text .join(self.segmentor.cut(text)) return text这个类的好处是每一行process里的步骤都清晰可见你可以按自己的数据情况增删步骤。比如商品名中的括号想保留就把clean_punct里的括号从剔除豁免列表里移出去如果要做中文分词就把do_segmentTrue并传入一个 jieba 实例。5.3 验证流水线先感受再对齐跑完预处理后不要急着训练。先把处理前和处理后的文本各抽100条并排打印出来人工看一遍。这一步叫感受数据看起来土但比任何自动化指标都直观。我当时就发现评论里的 !!! 连续感叹号会被切成三个标点 token这在子词模型里会白白占用 token 数量。后来我在clean_punct里加了连续感叹号合并的规则!{2,}变成!。这种细节不看实际输出样本是永远发现不了的。6. 实测中让我印象最深的几个坑6.1 去停用词未必能提升效果网上很多教程把去停用词当成常规操作但我在多个任务里试过去掉停用词并不总能提升效果甚至可能让模型变差。原因是停用词表大多是通用列表里面包含的了是这类词对某些短文本分类任务来说这些词本身携带一定的时态或语气信息。更关键的是如果你后面接的是BERT这类子词模型它自带的tokenizer和注意力机制完全可以自己处理停用词你强行去掉反而破坏了句子的自然结构。我的建议是可以先做一次实验对比把去停用词与否分别跑一遍看效果差异。如果停用词真的影响了效果再针对性过滤而不是直接套模板。6.2 文本去重的粒度要粗一些数据增强做完之后去重是很必要的一步。但去重粒度要把握好。按完全一致去重是最容易的但会漏掉大量高相似但不同的重复样本。比如增强产生的很好用和很好用啊字符层级不同但语义上几乎是同一条样本如果不去重模型会在这一条语义上过拟合。我后来的做法是先做完全去重再用 MinHash 或 SimHash 做一次近似去重相似度阈值设到0.92左右。这样能把增出来的冗余样本进一步压掉。6.3 预处理流程本身也要做A/B测试最后想强调一个很多人都忽略的点预处理流程不是一次写对就万事大吉的它和模型架构、超参数一样需要反复调试。我的做法是以预处理策略为变量做A/B测试——比如用不用BPE、清洗规则里删不删数字、增强比例设多少分别跑到模型端看指标变化。只有把预处理当成实验的一部分而不是训练前随便清洗一下的例行公事你才能在文本模型的效果上获得真正的可解释提升。我见过太多人把时间花在调模型结构上却忽视了文本输入本身的质量。预处理做完之后我会习惯性地把每一批样本的token数量分布打印出来看一眼。如果切完之后的token分布突然变得特别集中比如所有样本都在80到100个token之间这通常说明清洗规则把长句信息给截断了需要重新审视规则边界。数据预处理不是流水线里最光鲜的环节但它是所有下游模型的地基。地基稳不稳训练曲线和线上效果都会诚实地告诉你。
做文本数据预处理的人经常被误以为只是在写正则、调停用词表。实际上分词、子词切分、规范化与数据增强这几件事每一件都能决定模型最终能跑多好。我最近在做一个短文本分类的模拟项目数据量不算小模型也用了预训练模型结果折腾了整整两周最后发现所有问题的根源都出在预处理环节——不是模型不够强而是喂给模型的文本根本没被处理好。这篇东西适合谁看呢凡是自己拉过数据、自己训练过文本模型的人无论是做文本分类、情感分析、检索增强还是微调大模型只要被怎么清洗数据才靠谱为什么同样的数据别人训练出来效果比我好增强之后模型反而变傻了这类问题困扰过都应该能从这里找到一些线索。我尽量把原理、代码和真实踩坑都揉在一起讲不绕弯子。1. 分词这一步先想清楚你拿到的是哪一类文本1.1 中文分词与词典幻觉中文分词是预处理里最容易被高估的一环。常见的工具比如 jieba、pkuseg、HanLP各有各的词典和默认策略但很多人默认装好就用结果分词结果里充满了伪词。举个例子我做电商评论项目时商品标题里大量出现iPhone14ProMax这类词。jieba默认词典里没有这个东西会硬切成iPhone14/Pro/Max而实际上iPhone14ProMax作为一个整体在后面做关键词匹配时才有意义。这不是工具的问题是我没有场景化更新词表。正确做法是先收集领域词表再让分词器去加载自定义词。jieba 支持用户词典pkuseg 也支持自定义词表。但这里有一个坑用户词典不是越全越好。词典太大会引入大量低概率词汇导致分词结果反而变碎、变乱。我自己的经验是领域词表要按词频和一致性筛选而不是把商品名、实体名一股脑塞进去。1.2 英文分词的空格假设会失效英文处理看似简单用空格切分再去标点。但这个假设在真实语料里经常失效尤其是用户生成内容UGC。比如Im 要不要分成 I 和 mstate-of-the-art 里的连字符要不要拆纽约这样的中文地名夹在英文文本里怎么处理user https://t.co/xxx 这类 token 很多场景下该保留还是过滤我的做法是不要把分词看成一个万能步骤而是看成给后续任务准备的最小语义单元。如果后面接的是BERT这类子词模型那英文分词可以直接退化为按空格与标点切分剩下的交给子词模型处理。如果后面接的是词袋模型或传统机器学习模型那英文分词就要做得细一些比如用 spaCy 的规则器处理缩写和连字符。1.3 一个实用的分词选择策略我自己的经验一般会按任务类型来选任务类型推荐方案理由短文本分类 / 情感分析jieba 自定义领域词表词粒度直接特征清晰长文本摘要 / 篇章理解不切词直接用字符或子词避免累积切词错误英文通用任务空格 标点 规则处理给子词模型留空间专业领域医疗、法律、金融领域分词工具 实体词表扩充术语完整度决定召回这个表不一定放之四海而皆准但能帮你快速定方向。核心逻辑是分词工具本身不产生信息只是决定哪些字符组合被打包成一个单元。你打包得越合理后面的统计或模型训练就越稳打包得越乱后面的所有环节都在替你承担代价。2. 子词切分当分词满足不了模型的时候2.1 从OOV到词表爆炸分词之后紧跟着的一个重要问题用什么粒度把文本变成模型能读的向量传统做法是建一个词表把每个词映射成ID。但真实文本里的词是开放的新词、拼写变体、罕见词永远存在。词表开太小OOVout-of-vocabulary词表外词多词表开太大模型参数量涨得离谱。子词切分的出现就是为了解决这个矛盾。它不把词看成一个不可分割的整体而是把词切分成更小的子词碎片。例如unbelievably 可以切成 un, believ, ably这样一来即便模型没见过unbelievably它也能通过un-和believ这些片段猜出大致语义。这套思路和人类查词典时拆词根的方法很像。2.2 BPE、WordPiece 与 SentencePiece 的差别这块很多人只记住了名字没搞懂真正的区别。我简单说下本质BPEByte-Pair Encoding是一种自底向上的合并方法。先从单个字符开始统计文本中相邻字符对的出现频率每次把最高频的字符对合并成一个新符号重复直到达到目标词表大小。核心逻辑是贪心地把高频片段融合。WordPiece本质和 BPE 类似但合并标准不是共现频率最高而是合并后对整个词表的语言模型概率提升最大。它在 BERT 时代被广泛使用。SentencePiece并不是一种独立的切分策略它更像是一个框架——可以在这个框架里运行 BPE 或 Unigram 算法并且它会把空格也当成一个普通字符参与建模。这一点对中文、日文这种没有自然空格的语言相当友好。三者的关系可以用一张表直观总结算法合并依据是否把空格当字符典型使用者特点BPE字符对共现频率否GPT系列简单高效WordPiece语言模型概率增益否BERT需要预训练辅助SentencePiece基于子词单元的LM是T5、多语言模型对无空格语言友好你不需要把每个细节都背下来但需要记住选哪个取决于你的文本语言、是否需要处理多语言、以及你是否有能力训练自己的词表。2.3 训练自己的BPE词表时参数怎么定现在很多人直接用预训练模型自带的 tokenizer省事但遇到垂直领域医疗、金融、代码时预训练词表往往会浪费大量 token。比如BERT的词表里有大量通用词而对心肌梗死肾小球滤过率这类医学术语却拆得很碎。如果你决定训练自己的 BPE 词表有几个参数要留意vocab_size太小导致碎片化太大导致词表稀疏。我一般从 8k 到 32k 之间调中文语料 16k 通常是个不错的起点。min_frequency控制哪些字符对可以进入合并候选。调高它会过滤掉低频噪声但也会减小词表的领域覆盖度。normalization在训练词表之前是否先做了 Unicode 规范化、是否小写化。这些决定会直接影响切分结果。我自己的一个经验是先用小样比如10万条训练词表再用一个留出集检验恢复率round-trip tokenization rate也就是切分后再拼回原句的还原度。如果还原度很低说明词表太小或 min_frequency 设得太激进。2.4 中文任务要不要自己训BPE中文文本如果直接跑BPE效果经常很尴尬。因为中文天然是字级别的语言字本身就是信息密度很高的符号强行把词切成子词碎片很多时候只是在制造噪声。我的经验是分两种情况如果是用预训练中文BERT系模型直接用它的 tokenizer不做自定义BPE效果通常不会差。如果是自训练一个模型比如训练 T5 或 BART 类模型那么中文语料更合适的方式是训练 SentencePiece 模型并设置add_dummy_prefixFalse或按字符级全切分来初始化这样才能避免空格带来的奇怪行为。3. 规范化里的隐形杀器从Unicode到标点清洗3.1 处理顺序比处理规则本身更重要规范化是所有预处理里最基础但最容易被忽略的一环。我见过一个团队先做了小写化再做了 Unicode NFC 规范化结果把一些原本能区分的字符比如德语元音变音给合并了导致后面检索阶段出现信息丢失。规范化有一个通用的经验顺序按这个流程走基本不会出错先把文本从字节流解码成统一编码UTF-8。做 Unicode 规范化我一般用NFKC而不是NFC因为 NFKC 会把全角字符转成半角还能处理兼容字符。再做大小写转换、去重空格、去除控制字符。最后再做标点和特殊符号的清洗。这个顺序看起来简单但一旦颠倒会连续踩坑。3.2 半角全角、组合字符和控制字符全角字符是中文文本里最常见的坑。用户可能从Excel或PDF里粘贴文本逗号、括号、空格经常会变成全角状态肉眼看不出来但分词和匹配就会出问题。用 Python 的unicodedata.normalize(NFKC, text)可以一次性把全角转半角把一些兼容字母合并掉。组合字符也是个大坑。比如e后面跟一个 U0301组合重音符号和直接用éU00E9是不同的表示方式。视觉几乎一样但计算机里是两个不同序列。NFKC 可以把组合形式转成预组合形式减少后续匹配的复杂度。另外控制字符也不要忽略。很多从网页爬下来的文本里混着零宽空格U200B、零宽连字符U200D这些字符看不见摸不着会在分词时产生空 token也会在计算文本长度时干扰截断逻辑。我自己会专门写一个正则把这些不可见字符清掉。3.3 清洗规则流程化别再用一坨正则硬扛很多人写预处理脚本时喜欢把所有规则都堆在一个超级正则里。比如text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9。、], , text)这种写法的最大问题是不可复用、不可解释、不可回退。某天发现这条规则把温度-5度里的负号也去掉了你根本不知道是哪个步骤惹的祸。我更推荐的做法是把规范化流程拆成一个一个可插拔的函数每一步职责单一并且每一步都带上注释和日志。import re import unicodedata def unify_unicode(text: str) - str: 统一Unicode全角转半角组合字符转预组合字符 text unicodedata.normalize(NFKC, text) return text def remove_control(text: str) - str: 去掉控制字符和不可见字符 return re.sub(r[\x00-\x1f\x7f\u200b-\u200f\u202a-\u202e\u2060], , text) def normalize_space(text: str) - str: 合并多余空白去掉首尾空格 return re.sub(r\s, , text).strip() def clean_punct(text: str) - str: 保留基本中英文标点其他符号替换为空格 # 这里不要直接删标点替换成空格更安全避免单词被硬粘在一起 text re.sub(r[^\w\s\u4e00-\u9fa5,.!?;:。()\-], , text) return re.sub(r\s, , text)然后用一个流水线把这些函数串起来每个阶段都可以单独抽出测试。这样做的好处是如果将来某个环节出了问题可以直接定位到具体函数而不是在几百行正则里考古。4. 数据增强在不过度破坏语义的前提下扩充文本4.1 EDA的四板斧什么时候用、什么时候别用数据增强对文本任务不像图像任务那么普适因为文本是离散的随便扰动可能直接改变语义。EDAEasy Data Augmentation是里面最经典的组合包括同义词替换、随机插入、随机交换、随机删除。我在项目里实测下来的感受是同义词替换SR在长句子里稳定性和语义保持度最好因为它本质是局部替换只要同义词质量别太离谱整体句子结构不变。随机插入RI适合把句子变长用于长文本分类任务但插进去的词如果和上下文无关模型会把注意力浪费在噪声上。随机交换RS对短文本非常危险尤其是在中文里语序一换语义可能全变了。我打了他变成他打了我这已经不是增强是造谣。随机删除RD要慎用因为它会改变核心信息覆盖。我通常只在小样本或者面对过拟合时用删除比例控制在10%以内。如果你要用EDA强烈建议先拿一个留出验证集做AB测试不要想当然认为加了增强就一定更好。在某些任务里增强后的数据会让模型学到语义被扰动的不变式但这并不一定对应真实推理场景的噪声分布。4.2 回译效果好但别忽略成本与陷阱回译是我个人最推荐的一种文本增强方法尤其对于分类和相似度任务。思路很简单把中文句子翻译成英文再把英文翻译回中文得到语义相近但表达不同的样本。但回译有几个陷阱翻译错误会被当成增强多样性保留进训练集这等于把错误信息当正样本灌输给模型。回译后的句子长度波动很大有些句子翻译两轮后凭空多出一堆信息或者丢掉部分实体对实体敏感的任务比如命名实体识别尤其不友好。回译成本不低。如果数据集是百万级全部做回译性价比很低。我一般只在低资源类别上做比如某个分类只有几千条样本回译到两三倍就够了。判断回译质量有一个简单方法把回译后的句子与原句做一次相似度计算比如用 Sentence-BERT 类模型算余弦相似度低于某个阈值我一般设0.82的直接丢弃。这样能过滤掉大部分语义漂移样本但也会牺牲少量多样性。4.3 中文文本增强真正的坑同义词表质量很多人想在中文里复现 EDA先卡在第一步找一个好的同义词表。中文同义词表既没有英文 WordNet 那么丰富也没有明确的多义词消歧机制。你用便宜替换成廉价可能没问题但这家店便宜这句话里的便宜如果同义词表里有便利这个义项就会生成这家店便利语义完全偏掉。在实战中我的做法是自己做一个小规模的领域同义词表而不是直接用通用同义词库。比如做奶茶评论的情感分类人工整理好喝/口感佳/味道不错/赞这类同义词比自动替换的效果稳定得多。通用词表只在词性简单、语义单一的场景下能直接用。另外中文的否定词极其敏感。一个不喜欢被替换成讨厌还行但如果同义词表把不错替换成可以就可能在负面样本里引入中性或正面噪声。凡是涉及否定、程度副词的句子我建议要么不增强要么只做回译。4.4 增强之后必须做的质量过滤很多人做了增强就直接拼进训练集这是不对的。增强数据的质量参差不齐直接混入会拖垮模型效果。我的标准流程是先对增强后的句子做通顺度评估最简单的方式是用困惑度perplexity过滤语言模型算出来的分数越高越可疑。再做标签一致性校验。对于分类任务可以用一个之前用干净数据训练好的小模型预测增强数据的标签把预测结果和原标签不一致的样本剔除。最后人工抽检200条看看整体质量分布再决定要不要调整增强参数。这一步看起来费时间但能避免一个更严重的后果增强数据把模型的精度方差拉大训练十几次每次结果都不一样最后你根本不知道模型能力到底如何。5. 一套可直接照抄的预处理流水线附代码5.1 一个具体场景情感分类的原始数据假设你手上有这样一份数据从电商平台收集的用户评论包含商品名称、评论文本、评分。你计划做一个二分类情感分析标签由评分映射得到好评/差评。原始文本长这样【京东】美的电磁炉C21-RT2160 家用多功能电磁炉货到付款 很好用炒菜快!!! 收到货了颜值可以但是声音大客服态度一般般。 #晒单#主要还是便宜性价比可以我不会真的针对某个具体电商平台但这类文本里的问题非常典型包含商品名、平台名、促销关键词、emoji、多余标点、不规范空格。我们的目标是把这些文本清洗成适合子词模型输入的紧凑序列。5.2 流水线代码一个可插拔的预处理类我在实际项目中倾向于把所有预处理逻辑封装成一个类这样流程统一、便于复用。import re import unicodedata class TextPreprocessor: def __init__(self, do_segment: bool False, segmentorNone): self.do_segment do_segment self.segmentor segmentor def unify_unicode(self, text: str) - str: return unicodedata.normalize(NFKC, text) def remove_control(self, text: str) - str: return re.sub(r[\x00-\x1f\x7f\u200b-\u200f\u202a-\u202e\u2060], , text) def normalize_space(self, text: str) - str: return re.sub(r\s, , text).strip() def remove_special_markers(self, text: str) - str: # 去掉【】里的活动词、#话题#标签 等对情感判断无助益的信息 text re.sub(r【[^】]*】, , text) text re.sub(r#[^#]*#, , text) return text def clean_punct(self, text: str) - str: text re.sub(r[^\w\s\u4e00-\u9fa5,.!?;:。()\-], , text) return re.sub(r\s, , text) def lower(self, text: str) - str: return text.lower() def process(self, text: str) - str: text self.unify_unicode(text) text self.remove_control(text) text self.remove_special_markers(text) text self.clean_punct(text) text self.normalize_space(text) text self.lower(text) if self.do_segment and self.segmentor: text .join(self.segmentor.cut(text)) return text这个类的好处是每一行process里的步骤都清晰可见你可以按自己的数据情况增删步骤。比如商品名中的括号想保留就把clean_punct里的括号从剔除豁免列表里移出去如果要做中文分词就把do_segmentTrue并传入一个 jieba 实例。5.3 验证流水线先感受再对齐跑完预处理后不要急着训练。先把处理前和处理后的文本各抽100条并排打印出来人工看一遍。这一步叫感受数据看起来土但比任何自动化指标都直观。我当时就发现评论里的 !!! 连续感叹号会被切成三个标点 token这在子词模型里会白白占用 token 数量。后来我在clean_punct里加了连续感叹号合并的规则!{2,}变成!。这种细节不看实际输出样本是永远发现不了的。6. 实测中让我印象最深的几个坑6.1 去停用词未必能提升效果网上很多教程把去停用词当成常规操作但我在多个任务里试过去掉停用词并不总能提升效果甚至可能让模型变差。原因是停用词表大多是通用列表里面包含的了是这类词对某些短文本分类任务来说这些词本身携带一定的时态或语气信息。更关键的是如果你后面接的是BERT这类子词模型它自带的tokenizer和注意力机制完全可以自己处理停用词你强行去掉反而破坏了句子的自然结构。我的建议是可以先做一次实验对比把去停用词与否分别跑一遍看效果差异。如果停用词真的影响了效果再针对性过滤而不是直接套模板。6.2 文本去重的粒度要粗一些数据增强做完之后去重是很必要的一步。但去重粒度要把握好。按完全一致去重是最容易的但会漏掉大量高相似但不同的重复样本。比如增强产生的很好用和很好用啊字符层级不同但语义上几乎是同一条样本如果不去重模型会在这一条语义上过拟合。我后来的做法是先做完全去重再用 MinHash 或 SimHash 做一次近似去重相似度阈值设到0.92左右。这样能把增出来的冗余样本进一步压掉。6.3 预处理流程本身也要做A/B测试最后想强调一个很多人都忽略的点预处理流程不是一次写对就万事大吉的它和模型架构、超参数一样需要反复调试。我的做法是以预处理策略为变量做A/B测试——比如用不用BPE、清洗规则里删不删数字、增强比例设多少分别跑到模型端看指标变化。只有把预处理当成实验的一部分而不是训练前随便清洗一下的例行公事你才能在文本模型的效果上获得真正的可解释提升。我见过太多人把时间花在调模型结构上却忽视了文本输入本身的质量。预处理做完之后我会习惯性地把每一批样本的token数量分布打印出来看一眼。如果切完之后的token分布突然变得特别集中比如所有样本都在80到100个token之间这通常说明清洗规则把长句信息给截断了需要重新审视规则边界。数据预处理不是流水线里最光鲜的环节但它是所有下游模型的地基。地基稳不稳训练曲线和线上效果都会诚实地告诉你。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
