文本纠错系统实战：从编辑距离到BERT的完整方案

前段时间接到一个需求要把线上搜索框里的用户搜索词做一遍自动纠错。看似简单的一个小功能真做起来才发现里面的门道不少。从最开始的编辑距离、N-gram统计到后来尝试BERT Mask机制做候选排序再到上线前的一堆阈值调参和badcase治理前前后后折腾了两三周。这篇就把整个文本纠错Text Correction项目的设计思路、核心算法、实现细节和踩过的坑完整记录下来给后面要做类似功能的同学一个参考。文本纠错在自然语言处理里属于比较基础和实用的任务简单说就是自动发现文本中的错误并给出修正结果。错误类型涵盖音近字错误、形近字错误、多字少字、语法搭配不当等。实际业务中应用很广搜索引擎的Query纠错、输入法的智能联想、OCR识别结果的后处理、客服对话的文本规范化甚至语音转写后的错字修正都会用到这个能力。适合对NLP有一定基础、想做实际项目练手或者工作中正好碰到类似需求的同学阅读参考。1. 内容整体设计与思路拆解1.1 文本纠错到底要解决什么问题我在做这个项目之前对文本纠错的理解也比较朴素以为就是“把错别字找出来改成对的”。真正动手之后才发现一个完整的文本纠错系统要拆成三个层次来看。第一层是错误检测就是判断一段文本里到底哪个字或哪个词是错的。这一步看似简单其实很难。比如“我今天去植物圆玩”计算机怎么知道“圆”是错的它需要结合上下文、词频统计、语言模型给出了概率判断才能得出结论。更麻烦的是像“我高兴的跳了起来”这里的“的”应该是“地”这属于语法层面的错误光靠单字判断根本看不出来。第二层是候选生成就是针对检测出的错误位置给出可能的正确字或词。比如“植物圆”的“圆”字候选可能包括“园”“圆”“员”“元”等需要从中挑出最合适的一个。这个环节比拼的是对语言规律的挖掘深度。中文里很多错别字是音近或形近导致的比如“接着”被输入成“藉着”“部署”被写成“布署”这类规律需要积累大量的混淆词对和混淆字集合。第三层是候选排序就是综合语义、语境、词频等信息从多个候选中选出一个最合理的修正结果。比如“去植物圆”和“去植物园”从整句概率上看后者明显更高那就应该选“园”。这一层比较依赖语言模型的效果早期用N-gram统计模型现在用BERT这类预训练模型效果确实提升明显。整个系统跑起来之后还需要考虑速度、准确率、召回率之间的平衡。我见过不少做算法的同学模型效果在离线测试集上刷到很高一上线就被用户骂乱改。原因就是纠错系统是宁可少纠不可错纠改错一个词的体验伤害要远大于漏改一个词。这个观点在做整个项目的时候一定要摆正。1.2 常见错误类型与业务场景的对应关系文本纠错虽然叫一个名字但在不同业务场景里的侧重点完全不同。我把常见错误类型和业务场景的对应关系整理成一张表方便后面对号入座做技术选型。错误类型典型示例高频场景检测难度纠错难度音近字错误“部署”写成“布署”语音转写、拼音输入法中中形近字错误“未来”写成“末来”OCR识别、手写输入高高多字/少字“我我明天来”语音转写低中混合型“接个电话”写成“解个电话”搜索Query、聊天文本高高语法错误“高兴的跳起来”UGC内容、对话高高专业术语错医疗词“阿司匹林”写错医疗、法律文本特殊特殊我给这个项目定的目标是先解决搜索Query里的音近、形近字错误因为这是搜索场景里出现频率最高、用户痛点最明显的两类。语法错误在短Query里出现频率不高所以优先级放后面。专业术语则需要单独建词典处理不能靠通用模型硬来。一个很重要的认知是文本纠错没有一劳永逸的方案每个业务场景都需要针对性调优。比如搜索Query通常很短很少有上下文可依赖而OCR结果往往是整段文字可以用前后文信息辅助判断。同样是“错别字发现”短文本场景对低置信度的判断要更保守。2. 文本纠错的基础方案规则与编辑距离2.1 编辑距离算法的工作机制在做深度学习方案之前我先把最经典的规则方法完整梳理了一遍。编辑距离Edit Distance也叫Levenshtein距离衡量两个字符串之间最少需要多少次编辑操作插入、删除、替换才能相互转换。比如“搜索”到“搜寻”需要把“索”替换成“寻”编辑距离就是1“推荐”到“推件”也是1次替换距离为1。这个算法用动态规划实现状态转移方程很直观。def edit_distance(s1, s2): m, n len(s1), len(s2) dp [[0] * (n 1) for _ in range(m 1)] for i in range(m 1): dp[i][0] i for j in range(n 1): dp[0][j] j for i in range(1, m 1): for j in range(1, n 1): if s1[i - 1] s2[j - 1]: dp[i][j] dp[i - 1][j - 1] else: dp[i][j] min( dp[i - 1][j] 1, # 删除 dp[i][j - 1] 1, # 插入 dp[i - 1][j - 1] 1 # 替换 ) return dp[m][n]编辑距离在文本纠错里的典型用途是做模糊匹配。用户输入了一个可能错误的词我们可以拿它和词典里的候选词逐一算编辑距离距离越小的候选词越可能是正确目标。比如用户输入“部署”词典里有“布置”“部署”“步数”等计算后“部署”的距离为1、“布置”为2、“步数”为2那“部署”就是首选。不过编辑距离只考虑字符层面的差异完全忽略语义和语境。它不知道“布署”和“部署”在语义上是同一个意思也不知道“植物圆”和“植物园”在什么语境下更可能搭配。所以编辑距离适合做候选召回不适合做最终排序。2.2 为什么单纯靠编辑距离会翻车我一开始天真地以为用编辑距离在词典里检索就能解决大部分问题实测之后发现太乐观了。挂在嘴边的一个例子是“奇异果”和“猕猴桃”编辑距离很大但它们在语义上是同一类水果而“被子”和“杯子”编辑距离只有1就一个字不同含义却天差地别。这说明字符层面的相似不能代表语义层面的相似。真正让编辑距离显得力不从心的是长文本场景。用户输入一段话比如“我今天想去颐和园玩顺便看昆明湖”里面有多个潜在错误位置需要对每个位置都做候选生成和排序。纯靠编辑距离和静态词典对每个字都穷举候选计算量很大而且很容易把本来正确的词也误判成错误因为任何词都能在词典里找到距离更近的“正确词”。所以实际项目中编辑距离更多用于词典纠错和形近字映射承担的是“候选召回”职责。这个定位在后面深度学习方案中依然保留只是排序环节换成了更强的模型。很多人会忽略候选召回的重要性其实没有靠谱的候选集合后面的模型再强也发挥不出来。3. 核心算法升级N-gram语言模型与混淆集3.1 N-gram统计模型的原理和局限在试过纯编辑距离之后我把方案升级到了基于N-gram统计语言模型的纠错思路。核心假设是一段正确的文本应该出现在大规模语料中的概率更高而包含错误的文本概率会明显偏低。N-gram模型的基本思想是一个词出现的概率只与它前面的n-1个词相关。比如二元模型Bigram中P(“园”|“植物”) count(“植物园”) / count(“植物”)。当我们判断“我今天去植物圆”里的“圆”是不是错字时就对比 P(“圆”|“植物”) 和 P(“园”|“植物”)哪个概率更高就选哪个。我在实现时直接用了现成的统计工具包KenLM训练语料用的是一份千万级的通用中文语料N值取3三元模型。训练过程很成熟把语料分词后用命令行跑一遍就行。# 训练一个3元语言模型 $ lmplz -o 3 --text corpus.txt --arpa model.arpa # 转换成二进制格式加速加载 $ build_binary model.arpa model.bin # Python调用 $ python import kenlm model kenlm.Model(model.bin) sentence 我今天去植物园 print(model.score(sentence, bosTrue, eosTrue))答案里的“植物园”和“植物圆”前者在语料里的共现次数远高于后者所以模型能正确判断。这个方法对于解决频率类错误非常有效架构也简单离线建好模型后推理速度很快。但N-gram的局限也很明显。第一它严重依赖语料覆盖专业领域和长尾词效果衰减明显医学、法律类文本如果语料没覆盖任何词看起来都像是错的。第二N值大了之后前面的参数空间稀疏严重容易把正确的词判错N值小了又捕捉不到长距离依赖“我想去植物圆”和“我想去动物园”这种跨位置的搭配就区分不出来。3.2 混淆集构建把“容易写错”的知识沉淀下来要让纠错更聪明光靠统计还不够还得把“哪些字容易被混淆”这个知识沉淀成一份词典业内叫混淆集Confusion Set。混淆集就是一组组音近、形近字的集合比如“圆-园-员-元”、“作-做”、“的-地-得”。当模型检测到当前字可疑时就从混淆集里拉出同组的候选字组合成替换后的候选词。我构建混淆集的时候用了几个办法。第一个是从语料里统计高频错误对比如把用户输入和后续用户点击修正后的词对齐挖掘出实际发生的混淆对第二个是从拼音和字形特征自动生成候选把同音字、近音字、形近字汇聚起来第三个是靠人工整理核心错误集优先覆盖业务里最常见的几百组。混淆集的构建质量直接决定纠错上限。我见过一个错误用户搜索“青椒炒肉丝”结果输入成“青交炒肉丝”“交”和“椒”既不同音也不形近常规的混淆集根本覆盖不到。后来是在用户行为日志里发现的于是把它加了进去。这类长尾混淆对光靠人工整理刻不完需要持续从日志里迭代挖掘。4. 深度学习方案的落地实践4.1 用BERT的Mask机制做候选排序在规则和统计方案打了底之后我引入BERT做候选排序。BERT的核心是双向语言模型预训练时它会随机遮盖一部分词然后根据剩余的上下文预测被遮盖的词。这个能力用在纠错上非常合适我们判断某个位置的候选词是否合理本质上就是让模型在这个位置“填词”填出来的概率可以作为排序依据。具体实现时先把原始句子输入BERT对错误位置加上[MASK]标记让模型预测该位置最可能的词。拿“我去植物圆”举例把“圆”替换成[MASK]模型根据“我去植物”和“什么”的上下文预测出该位置最可能是“园”概率远高于“圆”和“员”。from transformers import AutoTokenizer, AutoModelForMaskedLM import torch tokenizer AutoTokenizer.from_pretrained(bert-base-chinese) model AutoModelForMaskedLM.from_pretrained(bert-base-chinese) sentence 我今天去植物[MASK] inputs tokenizer(sentence, return_tensorspt) with torch.no_grad(): outputs model(**inputs) logits outputs.logits mask_pos inputs[input_ids].tolist()[0].index(tokenizer.mask_token_id) probs torch.softmax(logits[0, mask_pos], dim-1) top5 torch.topk(probs, 5) for idx in top5.indices: print(tokenizer.decode([idx]), probs[idx].item())用BERT做排序的实际效果比N-gram提升非常明显尤其在长距离依赖和复杂语义判断上。像“小王把桌子上的杯子拿起来”这类句子整句语义都在影响候选判断N-gram只能局部的看相邻词BERT能做全局的双向建模这一点本身就会带来质变。4.2 序列标注与Seq2Seq方案的取舍除了用BERT做候选排序业界还有两套主流方案序列标注Sequence Labeling和Seq2Seq生成。我一开始也纠结要不要直接上Seq2Seq因为看到不少论文里效果看起来很震撼但实际落地前需要考虑的因素比论文里复杂得多。序列标注方案把每个字标注为“正确”或“需要纠错”相当于把纠错问题转成序列标注任务。训练数据需要人工标注大量错误句子和对应修正。这个方案的优点是推理快、可控性强但缺点是只能做单字级别的替换对于多字错误、词序错误、添字漏字这类情况处理能力有限。Seq2Seq方案直接把错误句子作为输入输出修正后的完整句子理论上可以处理所有类型的错误。但实践中问题也不少训练数据极难准备生成过程不可控对实时性和并发量的要求高。我用一个测试集对比了三种方案的耗时和效果最终没有上Seq2Seq因为业务场景没法接受偶发性的语义篡改。方案效果推理耗时(100条)可控性数据需求规则编辑距离低0.1s高低N-gram统计中0.3s中中BERT Mask排序高1.2s中低(无需标注)Seq2Seq最高2.5s低极高需标注5. 实操过程与核心环节实现5.1 初步版本基于规则和统计的纠错引擎我先把方案拆成了两个模块候选生成模块和候选排序模块。候选生成模块负责找出“哪些词可能错了”以及“可能改成什么”使用混淆集和编辑距离组合完成候选排序模块负责用语言模型挑出概率最高的修正结果。这个版本的处理流程大概是先对输入句子做分词然后遍历每个词在混淆集和同音词表里查候选如果原词不在词典里或它在上下文中的语言模型得分明显偏低就标记为可疑接着用候选词替换原词重新计算整句的语言模型得分得分提升幅度超过阈值才接受纠错。这个流程虽然简单但对付大部分的音近字错误已经够用了。我写这部分代码的时候有一个体会工程上不能只盯着算法精度流程的每个环节都要有兜底。比如候选生成召回为空的词直接放行不强行改语言模型打分波动大的词不硬纠一整句话里同时有多个可疑点时一次只纠一个纠完重新算全句得分避免连锁误判。5.2 引入BERT后的整体架构调整引入BERT后我不会让BERT直接替代整个系统的所有判断而是让它在候选排序环节发挥作用。整体流程变成了先由混淆集和词表做初步的候选召回再让BERT对每个可疑位置做掩码预测最后结合原位置的预测概率和整句的语义合理性决定是否接受纠错。这个设计的关键好处是既保留了规则方法的可控性又吸收了预训练模型的语义理解能力。规则方法覆盖高频确定性的场景速度快、不会乱改BERT覆盖复杂语义场景准确率高。两个模块互为补充实测下来整体效果比单用任一种提升了一截。这里有个细节需要注意。BERT预测时的输入不能只给一个孤立的词要把整个句子的上下文都喂进去才能捕捉到语境信息。但BERT的输入长度有限遇到超长Query要截断。我在实现时采用了一种折中策略对超长句子先按标点切分保留错误位置前后各若干字作为上下文窗口超出窗口的部分丢弃。另外BERT对位置很敏感候选替换后最好重新组织完整句子再做一次得分评估避免因为上下文被截断导致预测偏差。5.3 参数调优如何让系统“少犯错”纠错系统最关键的参数有三个候选召回阈值、BERT预测置信度阈值、整句得分提升阈值。这三个阈值共同决定了系统的“纠错力度”。力度太大容易把正确文本改错力度太小纠错能力又体现不出来。我调参时的主要思路是拿真实日志数据回放。收集一段时间的线上搜索结果把用户实际搜索的词和用户后点击的结果作为黄金标签统计不同阈值组合下的准确率和覆盖率。最终我选择了偏保守的参数组合只有当BERT在候选位置的预测概率是原字概率的两倍以上且替换后整句得分提升超过一定比例才纠错。宁愿少纠不故意乱纠。5.4 从离线测试到线上上线的链路整个系统从离线到上线中间还有几条必须走通的链路。我总结了一下离线评估准备评测集包含正确句子和错误句子计算纠错的准确率、召回率、F1值。影子模式线上流量实时拷贝一份进入纠错系统但结果不直接生效只记录日志用于离线回放调参。白名单机制针对专有名词、地名、人名等不能动的词建白名单防止错误纠错。线上限流BERT推理对性能有压力初期要控制流量比例逐步放量。日志回收与badcase分析持续收集用户反馈定期迭代混淆集和阈值。这个项目最耗时间的其实不是模型部分而是数据清洗和评测体系建设。没有一套靠谱的评测集就无法客观衡量系统是好是坏后面做的所有优化都是盲人摸象。6. 常见问题与排查技巧实录6.1 为什么系统把正确的句子改错了上线初期我们收到过不少用户反馈说纠错把原本正确的内容改错了。排查后发现主要来自三种情况。第一种是专有名词被误伤。比如某个品牌名“破仑”虽然看起来像“拿破仑”的错写但它实际是一个注册商标。这类问题靠通用模型无法解决只能建白名单把该保护的词收集起来在纠错前先行跳过。第二种是领域词汇未被语料覆盖。比如“恒玄科技”这样相对生僻的股票名称模型不熟悉就倾向于改写成高频词导致用户原意被扭曲。这类问题的解决办法是加载领域扩展词典让模型在打分时对这些词保持较高优先级。第三种是本身语义模棱两可的句子模型容易帮用户做“过度补全”。比如“他说的对”和“他说的对”模型可能把前者的“对”改成“队”因为它看见“说的”这个词就联想到“说的队”这个常见搭配。这个只能靠调低置信度阈值缓解没有完美的通用解法。6.2 速度太慢怎么优化线上推理BERT推理速度是真实问题尤其在高并发场景下单个CPU上的BERT推理可能耗时上百毫秒无法直接扛住线上流量。我的优化思路分三层减少需要BERT推理的量。先靠规则和词法过滤掉绝大多数明显正确的词只把少数高嫌疑位置交给BERT这一步能砍掉约70%的推理请求。批量推理。把多个可疑位置的预测请求拼成一个batch一次推理同时处理多句话充分利用GPU算力。模型蒸馏和量化。把大模型蒸馏成小模型上线或者用TensorRT量化成INT8速度能再提升数倍效果损失可以控制在可接受范围内。具体量化方式我用的是ONNX Runtime加FP16单条Query的推理延迟从120ms降到了30ms左右线上版本是用蒸馏模型完成核心推理兼顾效果和速度的平衡。6.3 数据从哪里来如何构造评测集很多做文本纠错的同学会卡在数据这一步。我的做法是用三个来源的融合公开数据集比如中文拼写纠错数据集网上可以找到一些学术机构开源的数据。业务日志挖掘从线上用户行为里挖掘真实错误。用户在搜索结果里输入一个词没有点击换成另一个词又搜索了两个词之间就可能存在纠错关系。这类数据噪声比较大需要过滤。模拟生成对一段正确文本用混淆集随机替换其中的字词生成带错误的数据。这个方法最容易扩展到大规模但替换后的句子要人工抽检避免生成噪音数据。评测集我分了三个子集高频错误集、困难错误集、正常文本集。前两个分别衡量系统的检出能力第三个衡量系统的误判率。每次模型迭代都在这三个子集上分别看指标避免为了刷总分而牺牲某一项。6.4 一个隐蔽的坑大小写、全半角与标点最后想提一个容易被忽视的细节。很多文本在进入纠错系统前如果没有做文本规范化会在一些意想不到的地方出问题。比如中文里全角逗号“”和半角逗号“”被当成不同字符导致语言模型打分异常英文单词大小写不一致被词典误判为错误数字里的中英文标点混用也会干扰候选排序。我给系统增加了一个预处理模块统一做全半角转换、大小写归一化、标点规范化和空白字符压缩。这个模块对最终效果的影响不亚于算法调优虽然听起来平平无奇但在真实数据上它能直接减少一堆莫名其妙的badcase。文本纠错这个项目的完整链路大概就是这样从明确业务目标开始先识别错误类型再选择技术方案从规则方法起步逐步引入统计模型和深度学习模型每一步都围绕准确率、召回率、速度、可控性四个维度做平衡。整个项目做下来我最大的体会是文本纠错并不是简单的“找出错别字”而是一个需要在准确和保守之间反复权衡的系统工程。宁可漏掉一个可改可不改的错误也绝不把一个正确的词改成错的这个原则在文本纠错里永远适用。