预训练前的规则系统：数据清洗与语料过滤的工程指南

前几天有个做算法工程的朋友突然问我：“你说的大模型训练永远绕不开数据，那在真正的预训练开始之前，是不是还有一层 pre-pre-training 的前置工序？这一层里的规则系统到底有哪些？”我愣了一下。这个词确实不是某篇 paper 里严格定义过的术语，但干这行的人基本都心领神会：它指的是大规模预训练真正开始之前，所有由人预先设定好、不靠梯度更新来学习的判断逻辑。

我把这几年搭过的数据处理链路、看过的开源项目以及踩过的坑合并在一起，最终梳理了一份还算完整的答案。先说结论：pre-pre-training 阶段的规则系统不是一个单一系统，而是一组分布在“语料进场前、文本解析中、训练目标构造前”的规则集合。它甚至还有一个历史坐标——在大规模预训练成为默认范式之前，NLP 本身就是靠规则系统在撑场面的。所以下面我按我的理解，把这两条线一起盘一遍，重点讲哪些规则系统今天依然在起作用、它们的边界在哪里，以及真正落地时的工程姿势。

1. 先把坐标定清楚：pre-pre-training 这个阶段到底在哪

1.1 这个词的两个常见坐标

我在不同场合听过有人说 pre-pre-training，多数时候他们指的是同一个意思：大规模预训练之前的数据准备阶段。按照现在主流的大模型训练流水线，数据大致要走过“采集 → 清洗 → 过滤 → 去重 → 脱敏 → 分句 → tokenization → 预训练”这一长串路径。凡是发生在 token 进入模型之前、并且是用显式规则而不是反向传播来完成的处理，都可以被算进这个阶段。

另一个坐标更偏历史。把时间倒回到 2018 年之前，当时的 NLP 主流范式还没有被预训练模型统一，很多任务靠的是人写规则、维护词典、配置正则表达式。我们把那一段也叫做 pre-pre-training 时代——它是“预训练时代之前”的意思。这两层理解并不冲突，甚至今天很多处理预训练语料的工具，骨子里仍然是老派 NLP 留下的规则技术。

理解坐标的意义在于：当你问“pre-pre-training 的规则系统有哪些”时，真正要回答的其实是“在数据进入模型之前，有哪些逻辑是必须靠规则先验来兜底的”。统计模型擅长从大规模数据里学规律，但学不出稳定可靠的底线；规则系统存在的价值，是把人类已经知道的约束在第一时间显式写进去。

1.2 规则系统在这个阶段扮演的角色

我习惯把 pre-pre-training 中的规则系统分成三类角色。每一类角色面对的问题不同，设计和维护方式也不同。

第一类是质量闸门。语料采集进来之后，你肯定不能直接把网页文本扔给 tokenizer，里面可能有乱码、重复段落、广告噪音、非目标语言文本、色情暴力内容，甚至还有个人信息。这类规则系统的职责是决定“什么文本能留下”，通常表现为过滤器和清洗器。

第二类是前置结构感知。模型要学的终究是自然语言的结构，但在预训练前我们往往已经能利用一些现成的语言学规则把边界切好。比如分句、分词、词形还原、实体粗标。这类系统不一定直接参与训练，但会显著影响后续数据质量和训练效率。

第三类是训练目标的构造器。有些预训练阶段不是从头裸学，而是想先让模型在某个领域或某种能力上热身，这个阶段需要一批粗标注数据。规则系统非常适合做批量打标，把“包含症状描述的句子”“疑似代码注释的文本”“含数学公式的段落”等信号快速抽出来，为后续的任务适配预训练提供监督信号。

1.3 为什么今天还要重新重视规则系统

这是个很现实的问题。前几年大家觉得大模型足够强，规则系统是过时的东西。但做过实际预训练的人应该都有体会：在数据量动辄几 T 的规模下，模型的最终效果经常不取决于模型结构差多少，而取决于喂进去的数据干净到什么程度。很多公开的预训练数据集也会拿出大段篇幅描述自己的过滤规则，比如根据重复 n-gram 比例过滤、根据困惑度过滤、用分类器过滤低质量页面等。

规则系统之所以在 pre-pre-training 阶段不可替代，还有一个原因：白箱可审计。如果一条数据没有进入训练集，你能拿规则日志说出是“语言识别未通过”还是“质量评分过低”。换成纯模型过滤，你可能要花很长时间去解释一个黑箱决策。我们做工程的人永远需要这种可控性。

2. 语料进模型前的规则闸门：每一行文本都要过几个关卡

2.1 语言识别与字符规范化是第一道墙

不管训练中文、英文还是多语言模型，第一件事通常是语言识别。大规模抓取的语料里会混入各种语言，有些是目标语言，有些是路过语言的碎片。你当然可以训练一个语言分类器来识别，但在 pre-pre-training 阶段，大多数工业实现仍然从一组轻量规则开始：先检查 Unicode 码点分布，判断文本主体属于哪个文字系统；再用停用词表或高频字符表做二次确认；最后再交给 fastText 的语言识别模型兜底。

顺序是有讲究的。码点规则极便宜，O(n) 扫描一遍就能挡掉绝大多数乱码；词表规则稍微贵一点，但能补足“虽然码点是拉丁字母但其实是西班牙语”这类情况；模型兜底放在最后，因为它慢、且需要加载权重。我在实践中见过不少团队一上来就上模型识别，结果把大量纯数字页面误判成某种语言，或者因为模型在短文本上不稳定而对几句话的文本乱标。更稳的做法永远是小规则在前、模型兜底在后。

字符规范化也要在这个阶段统一处理。全角半角、大小写、各种不可见字符、零宽空格、HTML 实体，这些都要依赖确定的规则集做映射。这里强调“确定”两个字，是因为很多规则会在清洗时被反复执行，如果规则不是幂等的，同一份数据每跑一遍结果都不一样，后面做版本管理会痛不欲生。

2.2 文档质量过滤：一组启发式规则的组合拳

所谓质量过滤，就是告诉系统“哪些文本没有资格进入预训练语料”。业界现在最常见的做法不是靠单个大规则，而是把多个启发式指标组合起来打分，再经过阈值判断保留或丢弃。

一个典型的规则集合长这样：

这组指标单独看都很简单，甚至可以说简陋，但组合起来的效果非常可观。我们之前在清洗一批爬虫语料时，单靠“重复行比例 + 符号占比”两条规则就滤掉了接近 20% 的机器生成页面，而且几乎没有误伤正常文章。

需要注意，这套规则的阈值不应该一次拍死。我的习惯是先用肉眼抽样本估算分布，再做一个小批量实验，看看被过滤掉的文本里误杀比例是多少。规则宁松勿紧，因为规则过紧会把一些风格独特的优质文本杀掉，而这种错误在预训练阶段很难被下游指标发现。等模型训练完再发现语料有问题，想追溯是哪条规则误杀，成本就非常高了。

2.3 去重：从精确哈希到近似去重的规则体系

重复数据对预训练的影响已经有很多论文讨论过了，它会让模型在重复文本上过拟合，还会稀释数据多样性。去重这件事本身也分几层规则：

URL 级去重通常是第一层，因为同一个页面可能被多次抓取，扩展名、查询参数、跟踪链接都可能导致 URL 不同，所以需要一套规则做 URL 规范化，把 tracking 参数去掉、把默认页 index.html 归一化。第二层是精确去重，对全文计算哈希，如果哈希相同直接丢弃。第三层是近似去重，用 MinHash 或 SimHash 对文档做 shingle 签名，再通过局部敏感哈希找到高相似度的文档。

近似去重里其实也有大量规则维度的选择：shingle 取 n=5 还是 n=8，签名数量取多少，相似度阈值是 0.8 还是 0.9。这些参数不是从论文里抄一个就能完事的，跟语料类型强相关。比如新闻语料模板化严重，阈值要更敏感；代码语料本身重复模式多，阈值太敏感反而会把不同文件里共有的公共头误删掉。shingle 的规则本质上是“在什么粒度上算重复”的人为定义，这恰恰是规则系统在发挥作用。

2.4 隐私脱敏与安全底线，必须放在训练之前

现在做预训练语料，个人信息和敏感内容的处理不是可选项，而是上线前的硬性要求。这部分在 pre-pre-training 阶段几乎全靠规则系统，因为涉及隐私信息检测时，规则比模型的姿态更加确定、容易被审计。

一个可落地的正则规则集通常包括：邮箱地址、手机号、身份证号、银行卡号、IP 地址、详细的家庭住址特征词等。这些规则不需要多复杂，核心是召回率达到预期，宁可多做 mask 也不做删除。删除会改变句子结构，mask 则至少保留句法上下文。而且一旦发现一个新模式，比如某种带格式的日志编号泄露了内部信息，直接往规则库里加一条正则就能解决，不需要重新训练模型。

这里我要特别提醒：脱敏规则的优先级必须高于质量过滤。如果先做质量过滤，某些含个人信息的短文本可能因为“长度太短”被删掉，表面上消失了，但在后续日志里你没法区分它是正常删除还是脱敏删除，审计时就说不清了。正确顺序是先把所有需要保留的字段用占位符替换掉，再走质量过滤。

3. 老派 NLP 留下的规则系统遗产，今天依然是地基

3.1 预分词器：最容易被忽视的规则系统

很多人以为 tokenization 是模型的一部分，实际上在进入 BPE 或 SentencePiece 训练之前，还有一个预分词环节，而它本质上就是一个规则系统。Hugging Face Tokenizers 库里的 pre_tokenizers 就默认使用规则把文本按空格和标点切碎，再做 Unicode 规范化。对英文这类空格分隔语言，这套规则跑得很顺；对中文这种没有天然空格的语言，预分词规则就要小心设计。

中文语料常见的做法是直接按字符训练 BPE，这样最简单，也不会引入分词错误。但如果你的任务需要保留词边界信息，用词典分词后再做 BPE 也是常见选项。问题在于分词语料如果来自规则词典，词典覆盖面不够时会把文本切得很碎，反而影响后续训练。我的经验是：如果用字级 BPE，预分词阶段只需要做好中文标点归一和常见英文单词边界保护，不要强行套词法分析，否则就是引入一层不可控的误差。

3.2 规则实体识别，仍是数据筛选和 mask 的利器

现在一提到命名实体识别，大家想到的都是序列标注模型。但在 pre-pre-training 阶段，尤其是面向领域数据的准备阶段，规则实体识别仍然以极低成本扮演重要角色。比如你想筛出所有包含药物的句子、所有包含型号参数的文本，不需要训练模型，维护一张词典加一组规则就够了。

判断一条文本是否属于某领域，基于实体覆盖率的规则比训练分类器更透明。把实体词典做成一个规则的命中列表，计算文本中命中实体的种类和频率，超过阈值就保留。这样做的好处是当天词表更新后立即生效，不用重训分类器。缺点是实体词典的召回有限，但作为粗筛步骤它足够优秀，后面可以再套一个分类器做细筛。

3.3 句法规则辅助分句，比想象中更实用

语料进入预训练之前总要分句，分句质量对后续训练的影响被很多人低估了。分句本质就是一组规则：遇到句号、问号、感叹号后是否切分，需要考虑小数点、缩写、引号闭合等问题。不要小看这些琐碎的规则，我做过一个实验，把分句规则里“引号闭合判断”去掉后，模型中长句的连贯度明显下降，因为大量成对引语被错误地拦腰截断，模型学到很多不完整的句法片段。

老派 NLP 的上下文无关文法在今天几乎没人用来做端到端解析了，但它的一些思想被留存在分句、组块识别等规则实现中。当你处理多语言语料时，尤其中文和英文混排的文本，你需要一套兼顾两种语言习惯的分句规则，这种场景没有现成模型可以完全替代规则系统，因为它要求的是确定性而不是概率预测。

4. 面向特定领域的预训练热身，规则系统能帮你造监督信号

4.1 用规则做领域语料筛选，成本远低于训练分类器

当你想从一个超大规模通用语料里捞出一个领域子集（代码、医疗、金融、数学），第一个可用的方法依然是规则系统。以代码语料为例，最简单的规则就是按文件扩展名过滤，.py、.java、.go 全保留，再根据 shebang 行补充没有扩展名的脚本文件。接下来才是更精细的规则：过滤掉超长行（通常是压缩后的代码）、过滤掉由大量括号组成的自动生成代码、统计注释占比判断是不是文档仓库。

医疗领域语料筛选则更多依赖术语命中率。你不需要把所有医学文本都识别出来，只需要维护一个 5000~10000 词的核心术语表，然后给每个文档打一个术语密度分。术语密度超过阈值的文本大概率是医学内容，这个规则比训练一个 BERT 分类器好操作得多，也容易跟合作方解释。归根结底，领域筛选规则捕捉的是“这个领域的文本在表面形式上的强特征”。

4.2 规则抽出候选文本，构造第二阶段的训练目标

如果你的目标是做领域自适应预训练（先把通用模型在某个领域语料上继续训练），规则系统还能帮你找出更适合模型“热身”的样本。比如数学语料里，纯散文式的数学讲解和公式推导对模型的帮助不一样，用规则可以快速挑出含公式的段落：检测行内是否有 LaTeX 标记、是否出现“定理”“证明”“定义”等关键词、是否含有常见数学符号组合。这些规则不完美，但足以让你构造出“先学公式表达、再学推理文本”的训练顺序。

代码数据里的一个类似做法是按注释密度和标识符风格对文件分级。标识符命名风格本身是一次规则判断：snake_case、camelCase、全大写常量，这些模式可以用正则识别。如果你想让模型先学会代码语法骨架再理解领域逻辑，完全可以把“命名规范、结构完整的仓库”优先排到训练序列前面。

4.3 从散装规则到弱监督规则系统：Snorkel 这类框架在预训练前的价值

当规则多到一定程度，规则之间开始打架，人工调权重会变得非常痛苦。我见过一些数据团队把 50 多条正则写在一个 Python 文件里，靠 if-else 堆优先级，每次改规则都心惊胆战。这个问题在 pre-pre-training 场景中的解法，可以参考弱监督框架 Snorkel 的思路：把每条规则封装成一个 labeling function，允许规则给出正例、负例或弃权，再用一个 label model 学出规则的权重，从而把互相冲突的弱信号融合成训练标签。

这个思路放在语料筛选里尤其有用。比如你同时有“文本包含症状描述词”和“文本包含药物名”以及“文本存在于某个健康网站白名单”三条规则，它们单独拿出来精度都不够，但组合起来可能非常可靠。Snorkel 的 label model 能根据规则在无标注数据上的共现和冲突情况，自动估计每条规则的准确度，最终输出一个概率化的标签。对预训练数据准备来说，你甚至可以把输出当成一个质量分数，超过某个阈值才让文本进入训练集。

这类框架虽然不是传统意义上的“规则配置”，但它把规则系统的方法论从“人肉调优先级”升级成了“规则生成候选证据 + 模型学习融合权重”。当你手上的先验规则超过 20 条，并且需要频繁增删时，用这套思路来管理比硬编码 if-else 可靠得多。

5. 规则系统的工程化组织，决定了你是优雅地处理还是痛苦地补丁

5.1 规则必须分层，成本和收益要匹配

我会把所有 pre-pre-training 规则按处理粒度分成三层：文档层、句子/段落层、token 层。分层的原则是先跑最便宜的大粒度规则，把明显不合格的数据整块删掉，再用中等成本规则做句子级清洗，最后到 token 层做细微修正。这个顺序反过来会非常浪费算力，因为你在 token 层的精细处理，可能在下一层大粒度过滤时整个文档都会被删掉，等于白干。

一个实际的分层示意如下：

5.2 规则的优先级与动作语义要显式化

我见过很多团队维护规则时，只用代码注释写“这里先过滤再清洗”，过两周自己都忘了顺序。更科学的做法是把每条规则明确声明成三种动作之一：硬删除、修正替换、仅标记。硬删除规则应该是少数，只有语言不对、内容明确违规、重复严重这三类才配删除。修正替换用于可恢复的问题，比如 Unicode 错误、HTML 标签残留。仅标记则是把可疑文本留着，但给样本打一个标签，等后续模型过滤或人工抽检时再处理。

优先级设计上要遵循一条铁律：不可逆动作永远排在可逆动作之后。删除是彻底的，替换是半可逆的，标记是可逆的。一旦规则顺序错了，先删了再想用标记数据做分析就没机会了。

5.3 规则的审计追踪和回放能力不能被省略

pre-pre-training 阶段动不动就是几十 TB 数据，处理链路跑一次要好几天。如果规则没有版本管理，处理结果就是黑盒。我在系统里会给每一条规则分配唯一 ID，并在每一次过滤命中时写入审计日志。一个数据样本被丢掉时，能查到它命中了哪条规则、规则版本是多少。后来排查语料问题时，这层日志帮我省了非常多时间。

不只是规则代码要进 Git，规则依赖的词表、黑名单、阈值配置也要一起纳入版本。我遇到过最头疼的问题：某次处理时更新了停用词表，结果之后生成的训练集质量发生变化，但代码版本完全没变，找了半天才发现是挂在外部存储上的词表被悄悄替换了。规则系统不只是代码，更是一组配置、词表和顺序约束的组合体，每一部分都要可复现。

5.4 用一个闭环评估判断规则是加还是砍

很多团队的规则是“只加不减”，越堆越多。因为没人敢随便去掉一条规则，怕模型效果下滑。但规则过多会带来语料多样性下降，对预训练不一定是好事。我建议在 pre-pre-training 阶段把规则调整当成一个小型实验来做：固定一个包含几十万条样本的验证语料子集，跑规则后观察保留率；再在这个子集上做一个超小规模的预训练，用几个下游任务做评测。

这个评估闭环不贵。我实际做下来，百亿参数以下的模型，在 1% 语料上训练几千步，已经能暴露数据质量的大部分问题。规则加进去之后如果小模型评测不掉点，甚至还有提升，再推到全量数据。如果小模型评测掉了，即便规则在人工抽查时看着合理，也应该暂缓。模型对数据的感觉，经常和人眼对数据的感觉不完全一致，这点要交给实验去裁决。

6. 我在这个阶段踩过的几个坑，每一个都值得你绕开

6.1 误把“看起来不干净”当成“应该删除”

早期做爬虫语料清洗时，我有一条规则：文本中包含超过 5 个 URL 就整个文档删除。这条规则确实滤掉了大量导航页和聚合页，后来检查被删样本时发现，有一批技术问答页面正文里本身就包含“如何配置多个链接”的讨论，正文质量很高，但因为示例代码里的 URL 太多被误杀了。那一次让我学会：规则面对的是特征，不是语义。URL 数量多不一定是垃圾页，也可能是代码文档或教程类页面。后来我改成只统计正文区域内的 URL，并把“示例代码场景”排除到规则之外，误杀率大幅下降。

6.2 清洗规则和 tokenizer 的字符假设打架

还有一个非常隐蔽的坑。当时我给中文语料做清洗时，把所有的连续空白符压缩成了单个空格，理由是减少无效 token。但后来训练出的模型在生成代码时频繁出现缩进错乱，排查了很久才意识到：代码语料里的缩进是有语义的，压缩空白的规则把代码结构破坏了。同一个清洗规则在不同语料类型上表现完全相反。从那以后，我的预处理管线会先按语料类型分叉，代码类语料跳过空白压缩，自然语言类语料才执行。规则必须感知上下文，不能指望一条规则通吃所有文本形态。

6.3 规则更新后没有重放，导致链路数据前后不一致

这个问题我在 5.3 里提过，但值得单独说一次。某次我发现一条正则写错了，本意是过滤包含“点击此处”的广告文本，结果因为贪婪匹配把一大批正常文本也吞了。修复正则之后我以为就完事了，后来下游任务评测出了波动，才发现之前用旧规则处理的数据已经进入了缓存目录，新规则只对增量数据生效。两批数据混在一起训练，指标波动根本没法解释。现在我的所有数据处理任务都会在产物目录里写一个 manifest 文件，记录规则集版本、输入数据版本、执行时间和关键参数。凡是规则变更，必须重新生成产物，不允许增量拼接不同规则版本的数据。

6.4 对规则系统本身做回归测试，是投入产出比最高的投资

最后一条经验，也算是给整个话题收个尾。规则系统看似简单，但它分布在数据链路的各个阶段，任何一条正则的改动都可能在下游产生蝴蝶效应。所以我在项目里专门维护了一个 regression set，里面放了一批“必须被保留的困难样本”和“必须被过滤的典型坏样本”。每次改动规则都要跑一遍这个集合，确保该留的还在、该删的确实被删了。这个集合规模不用大，几百条就够，但它的价值远远超过写规则本身。规则系统中的坑大多是“改了 A 规则，破坏了 B 类文本”，而回归测试是最直接能兜住这层风险的网。做 pre-pre-training 阶段的数据工作，真正难的不是写出某一条规则，而是让上百条规则在一个长链路上稳定协作，这只有靠工程上的纪律才能实现。