学NLP这件事最怕的不是没资料而是资料多到不知道该从哪条主线走。今天是我给自己定的“日拱一卒”计划第22天议题是英文词形还原Lemmatization工具选定为spaCy。先说清楚这篇文章能帮你什么如果你刚接触到NLP里的文本预处理对runs、ran、running这些词到底该归成一个词还是保留各自形态有疑问或者你已经被各种词干提取Stemming的粗糙结果坑过那这篇就是为你准备的。我在这22天里踩过不少坑尤其是分词之后直接拿高频词做统计结果leaves和leaf被当成两个独立特征studying和studies也各占一个坑位整个关键词表乱得像一锅粥。后来我才意识到问题不在分词而在我跳过了文本归一化里非常关键的一步——词形还原。spaCy做这件事很方便但它的“方便”背后有一套自己的逻辑不了解这套逻辑你用起来依然会翻车。这篇文章我会把原理、模型选型、实际代码、常见坑以及如何接进真实项目一次性讲透。1. 为什么第22天要专门做英文词形还原NLP流程里的位置1.1 一个肉眼可见的问题runs、ran、running真的是三个词吗先看一个很基础的例子。一段普通的英文文本里可能出现这样的句子“She runs every morning. Yesterday she ran five miles. She is still running now.”如果按词面统计runs、ran、running会被记成三个完全不同的词。但在绝大多数NLP任务里这三个词指向同一个动作“run”只是时态、人称变了。英文的形态变化不像中文那么“干净”动词有第三人称单数、过去式、进行时名词有复数形容词有比较级和最高级。如果你把这些形态各异的词汇直接喂给模型特征空间会迅速膨胀样本稀疏问题也跟着加重。词形还原要解决的就是这个问题把单词还原到它的词典原形也叫词元Lemma。例如runs、ran、running统统回到runleaves回到leafbetter回到good。注意最后这个例子它不是简单去掉后缀能得到的涉及比较级的不规则变化这也是词形还原和词干提取拉开差距的关键场景。1.2 词形还原在任务链中的位置我自己的学习路线是分词Tokenization→ 词性标注POS Tagging→ 依存分析Dependency Parsing→ 词形还原Lemmatization。严格来说词形还原通常出现在词性标注之后因为很多词在还原为原形之前必须先搞清楚它在当前上下文里是什么词性。举个真实场景里的例子saw这个单词作名词是“锯子”作动词是“看见”的过去式。如果不知道它在句子里是名词还是动词你就没法决定该还原成saw还是see。spaCy把词性标注组件和词形还原组件设计成流水线里的不同模块就是为了让还原动作能吃到前面那一步的输出。换句话说词形还原不是一个孤立的查表操作它和上下文理解是绑在一起的。这个位置关系决定了另一件事如果你的下游任务是文本分类、情感分析、主题建模或者检索词形还原通常安排在特征构造之前如果你的下游任务是机器翻译或语法纠错那反而要明确区分时态语态这时候要不要做词形还原就要谨慎了不能一个方案走天下。2. 先分清同路人词干提取和词形还原不是一回事2.1 词干提取的粗糙与代价很多NLP入门资料把Stemming和Lemmatization放在一起讲甚至混着用。我能理解为什么会混因为它们俩的目的相似缩小词汇变体。但方法论和结果差别非常大。词干提取的典型代表是Porter Stemmer它的核心思想是用一连串启发式规则把词尾不断“砍”掉。比如running会被砍成runflies会被砍成flistudies会被砍成studi。看出来了吧它保证的是“词干尽可能短”不保证结果是合法单词。所以你在词干提取结果里会看到一堆中间状态有些看起来像拼写错误有些根本没有语言依据。更麻烦的是词干提取对不规则变化基本无能为力。went拿到Porter里走一趟出来的还是went它不认识go。better会被砍成better因为它只认后缀规则不查词典。在信息检索里这种粗糙有时候能接受因为检索任务看重的是字符串匹配的召回率但在语义任务里把studies变成studi会让下游模型多学一个没有意义的“伪词根”白白增加噪声。2.2 词形还原的目标一个规范形态Lemma词形还原追求的是回到词典里那个规范形态也就是你在字典里查词时看到的主词条。它不只是机械删后缀而是综合考虑词性、上下文、形态变化表最终输出一个合法单词。went还原成gobetter还原成goodcacti还原成cactus这些结果不仅合法而且保留了语义信息。但也正因为要“考虑上下文”词形还原的代价比词干提取高。它需要依赖词性标注的结果规则也更复杂。spaCy之所以是我目前用下来最顺手的方案就是因为它把词性标注和词形还原放在同一条流水线里不需要我自己拼装两套工具。我做了一个小对比方便你直观感受差异。同样是处理一句“The studies are better than before but the leaves fell.”原始词Porter词干提取spaCy词形还原studiesstudistudybetterbettergoodleavesleavleaffellfellfall这四行对比基本可以说明全部问题词干提取在studies、leaves这些规则变体上都输出了非词而词形还原四个全对。所以在做主题建模、文本聚类这类偏语义的任务时我会毫无犹豫选择词形还原而不是词干提取。3. 环境准备与模型选择从en_core_web_sm到trf3.1 安装与下载先交代环境。我用的是spaCy 3.x版本Python 3.9。安装主库很简单pip install spacy但只装主库还不够你需要下载英文模型。spaCy把模型拆成了独立包不像某些库把模型和数据混在安装包里。下载命令如下python -m spacy download en_core_web_sm下载成功后在代码里加载import spacy nlp spacy.load(en_core_web_sm)如果你是第一次接触spaCy可能会有一个疑问为什么要单独下载模型因为spaCy本身只是框架处理英语、德语、中文需要不同的语言资源和预训练参数。模型单独管理的好处是你可以按需切换不同规模的模型而不用重新安装整个框架。这里补一句经验国内网络环境下模型下载偶尔会超时。如果spacy download反复失败你可以去spaCy的模型发布页找到对应模型文件名用下载工具拿到.whl文件再本地pip install xxx.whl效果完全一样。3.2 四种英文模型怎么看怎么选英文模型根据训练数据规模和词向量覆盖度分成好几个版本最常用的四个是en_core_web_sm、en_core_web_md、en_core_web_lg、en_core_web_trf。它们的区别不只是“大小”和“速度”这么简单。模型包大小词向量速度精度适合场景en_core_web_sm约13MB无哈希向量最快够用学习、原型、低资源环境en_core_web_md约44MB有约2万词较快更好普通项目en_core_web_lg约682MB有约50万词较慢更好语义相似度、精度敏感en_core_web_trf约438MB有Transformer编码最慢建议GPU最好高精度场景如果你的任务只是做词形还原和词性标注sm模型完全够。我见过不少人一上来就装lg结果内存涨了速度慢了词的还原结果却没本质提升。因为词形还原更多依赖规则和词性结果而不是词向量覆盖度。词向量主要影响相似度计算和上下文表示的质量。但有一种情况建议直接上md以上你的下游任务还要做文本相似度计算或者你会在自定义语料上做迁移实验。那时词向量就重要了。trf模型最准但它本质是开了个Transformer编码器CPU上跑长文本会很吃力实际项目里要先想清楚算力预算。4. 实战用spaCy完成首次英文词形还原4.1 读取词形还原结果的正确姿势模型加载完成后词形还原几乎是零门槛的。你只要把文本丢给nlp对象然后遍历每个Token取lemma_属性即可。import spacy nlp spacy.load(en_core_web_sm) text The leaves were falling from the trees while I was running faster. doc nlp(text) for token in doc: print(token.text, token.lemma_, token.pos_)输出长这样The the DET leaves leaf NOUN were be AUX falling fall VERB from from ADP the the DET trees tree NOUN while while SCONJ I I PRON was be AUX running run VERB faster fast ADV . . PUNCT注意were还原成befalling还原成fallfaster还原成fast。这正是词形还原该干的活。我特别想强调一个新手容易忽略的点lemma_和pos_要一起看。如果你只取token.lemma_而不看词性某些结果会显得莫名其妙比如saw到底是saw还是see不看pos_永远搞不清楚。所以我在处理文本时几乎总是同时保留这两个字段方便后续排查。4.2 批次处理与字段保存单条文本的循环打印只能用来验证效果真实项目的文本量至少是几千条起步。这时候建议用nlp.pipe()做批次处理它能内部自动分块速度比逐条调用nlp(text)快很多。import spacy import json nlp spacy.load(en_core_web_sm) texts [ The cat sat on the mat., The cats were playing outside., She studied hard and finally passed the exam., ] results [] for doc in nlp.pipe(texts, batch_size64): tokens [ {text: token.text, lemma: token.lemma_, pos: token.pos_} for token in doc ] results.append({text: doc.text, tokens: tokens}) with open(lemmas.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这一段代码基本覆盖了“批量处理字段保存”两个场景。batch_size参数的取值没有绝对标准我一般先设64然后根据机器内存上下调整。如果文本特别长可以把批次调小如果文本短批次调大也无妨。实际项目里我通常还会过滤掉停用词和标点只保留实义词减少下游存储和计算压力。过滤方法很简单token.is_stop和token.is_punct再配合token.pos_白名单。比如valid_tokens [] for token in doc: if token.is_stop or token.is_punct: continue if token.pos_ in (NOUN, VERB, ADJ, ADV): valid_tokens.append(token.lemma_.lower())我把lemma_转成小写是因为后续做词频统计时The和the不能算两个词。这一步看起来简单却是我在实际项目中踩过小坑之后才养成的习惯。5. 引擎盖下面spaCy的Lemmatizer如何工作5.1 流水线组件与词性标注的关系spaCy处理文本的方式是流水线式的。默认的英文流水线大致是tok2vec→tagger→parser→attribute_ruler→lemmatizer。其中tagger负责给每个Token打上词性标签lemmatizer再依据词性执行还原。这也是为什么spaCy的词形还原结果比很多独立工具更可靠——它不是在真空里查词典而是利用前面已经计算好的上下文特征。比如I saw the film里的saw会被tagger标成VERB于是lemmatizer查动词表得到see而The saw is sharp里的saw被标成NOUN于是保持saw。如果没有词性标注这一步同一个词你只能靠字典里的默认顺序猜很容易猜错。实际工程里我们经常用nlp.pipe跑完之后再回头看每个Token的属性这个过程可以对中间产物做检查。比如早期调试时我会打印(token.text, token.pos_, token.lemma_)来确认tagger给的词性和lemmatizer给的还原是否一致。一旦发现某个词在实例里还原得不对第一反应应该是看词性标注对不对而不是怀疑lemmatizer坏了。5.2 查表规则例外英语还原的实际机制spaCy的Lemmatizer可以粗略理解成由三种策略组合运转词典查找表lookups、规则表rules、例外表exceptions。例外表处理的是不规则形态比如went→go、better→good、mice→mouse。这些词没有通用规则可以覆盖只能靠硬编码的词典。规则表处理规则变化比如名词复数加-s、动词过去式加-ed、进行时加-ing。spaCy里的规则通常和形态特征绑定比如看到标签是VBD过去式且词形是fell就确认它是fall的过去式而不是尝试直接剥离后缀。实际判断流程大致是先查例外表如果命中就直接返回没命中就根据词性查规则表匹配词尾规则都搞不定就退回原词。这套“三级策略”保证了大多数常规文本都能被处理同时把不规则变化也兜住了。理解这个机制对排查问题很有用。比如cafe和café一个不带重音一个带重音spaCy的词典可能只收录了其中一种拼写。如果你发现café没有被还原不用惊讶直接加例外规则即可。我后面会专门说怎么加规则。5.3 自定义规则AttributeRuler怎么介入自定义规则最常用的工具是AttributeRuler它能在管道中提前修改Token的属性包括LEMMA。假设你有一个领域词汇yoloedspaCy的词典不认识它你可能希望它还原成yolo。可以用如下方式加一条规则from spacy.pipeline import AttributeRuler nlp spacy.load(en_core_web_sm) ruler AttributeRuler(nlp.vocab) ruler.add( patterns[[{TEXT: yoloed}]], attrs{LEMMA: yolo} ) nlp.add_pipe(attribute_ruler, beforelemmatizer) doc nlp(I yoloed all weekend long.) for token in doc: print(token.text, token.lemma_, token.pos_)输出里yoloed的lemma_就会是yolo。实际项目里这种自定义规则通常来自你对领域语料的观察。比如你处理的是医学文本有很多专业名词变体处理的是饭馆评论有很多菜名的复数写法。把高频错误样本统计出来逐个添加规则是见效最快的优化手段。6. 踩坑实录词性误判、大小写、专有名词与外来说6.1 一字之差词性标注错误如何带偏还原我实际测试过一句话“The saw cuts wood.”这句话里的saw是名词指锯子。结果用en_core_web_sm一跑tagger把saw标成了VERBlemmatizer跟着把它还原成see。语义完全歪了。这不是spaCy独有的问题而是所有NLP流水线共有的风险上游模块的错误会向下游传递。词性标注本身的准确率在通用模型上大约是95%出头意味着每20个词就有1个可能标错。单独一个词标错词形还原就跟着错所以你会看到see出现在一个和“看”毫无关系的句子里。针对这个问题我的做法是分两层。第一层在发布到生产环境之前用自己的语料做一次人工抽样验证记录错误高频词然后针对性地加AttributeRuler规则。第二层在统计任务里把词性标注结果也纳入过滤条件比如只统计被标成NOUN的名词这样即使个别误判对整体分布的干扰也会被稀释。6.2 大小写和标点对还原的影响第二个高频坑是大小写。全大写的标题里Running会被正常还原成run这没问题但有一些专有名词比如地名Reading雷丁如果用户在文本里写成reading模型会把它当动词标注并还原。Reading和reading这两个词的区分本质上靠的也是词性标注。标签器看到大写Reading且后面跟介词短语可能会按专有名词处理但如果你把文本统一转成小写这个信息就丢了Reading就会变成read。所以这里有个取舍如果你在预处理阶段做了lower()以便统一关键词那么词形还原的专有名词判断能力就会下降。我的建议是如果下游任务需要区分专有名词就不要在小写化之后再跑词形还原而是先还原、后小写或者干脆保留pos_等于PROPN的Token原样。标点对词形还原本身影响不大但会影响词频统计。如果你不把句点和逗号过滤掉词表中会混入大量标点看起来非常脏。所以我在前面的代码里专门加了token.is_punct的判断。6.3 专有名词与缩写词的保留策略英文专有名词如Google、Python在大多数情况下不需要还原还原结果一般也还是原词。但有些系统会根据名词复数规则把MacBooks还原成MacBook这可能是好事也可能不是取决于你的需求。如果你希望保留品牌原样可以在清洗阶段对PROPN的Token直接跳过lemmatizer的输出保留原文。缩写词是另一个容易出问题的地方。像Dr.、vs.、e.g.spaCy通常能识别并给出相应的lemma_。但我遇到过I被还原成I第一人称代词原形就是大写结果有人误以为是大写问题统一小写后变成i在词向量里找不到对应向量。这类问题很隐蔽排查起来费时间所以我会提醒所有刚上手的朋友保存原始文本和还原结果时建议同时保存token.text、token.lemma_、token.pos_三个字段很多坑都能靠这三列数据定位。7. 词形还原接入真实项目的三种姿势7.1 关键词聚合和词频统计最直接的用途是做词频统计。假设你要分析一堆英文评论统计高频词。不做词形还原app、apps、application、applications全被当成独立词每个词的频数都被稀释做了还原之后它们汇聚到application或app取决于词典收录的是哪个原形关键词分布一下子就清爽了。我习惯用Counter来做这一步简单且快速from collections import Counter texts [ The applications are running smoothly., The application has been downloaded., Several applications were reviewed., ] counter Counter() for doc in nlp.pipe(texts): for token in doc: if token.is_stop or token.is_punct: continue if token.pos_ in (NOUN, VERB, ADJ): counter[token.lemma_.lower()] 1 for word, count in counter.most_common(): print(f{word}: {count})application最终会汇聚成一个计数。这个小例子解决了我最开始提到的“关键词表脏乱差”问题。7.2 文本检索和相似度计算统一形态在做简单文本检索时用户搜索run文档里写的是running或ran如果索引时做了词形还原两边就能匹配上。这一点在构建最小可用的本地搜索工具时特别有价值。具体做法是在建立倒排索引之前对文档做分词词形还原把处理后的词元作为索引词项用户查询的时候同样走一遍分词还原再在索引中查找。这样做比传统的子串匹配召回率高很多而且实现成本很低。当然如果项目体量到了搜索平台级别那需要对位中文分词的配置或英文的分析器配置做调优跟这里讲的是同一个道理。7.3 数据管线性能优化只保留需要的组件最后一个偏工程的经验默认流水线包含parser依存分析器它是整条流水线里最重的组件之一。如果你的场景只需要词性标注和词形还原根本用不到依存关系那就可以禁用parser速度会有明显提升。nlp spacy.load(en_core_web_sm, disable[parser])或者更精细一点只启用需要的组件nlp spacy.load(en_core_web_sm, disable[parser, ner])我在一次处理80万条英文评论的测试里禁掉parser和ner之后整体耗时大约下降了30%到40%。对于以词形还原为核心预处理步骤的项目这个优化几乎是无痛的。唯一需要记住的是如果之后你用token.dep_或者token.head做特征那就不能禁用parser因为关联信息全没了。8. 我的第22天小结与后续计划学到现在我最大的感受是词形还原的代码量极低但思考量极高。极低的点是只要调对了模型调用token.lemma_就能得到结果极高的点是你怎么理解模型结果的边界、怎么在领域数据上修正错误、怎么决定哪些词需要还原哪些词不能动这些判断往往决定整个文本预处理的质量。如果你要跟着练习我建议手写一个英文短文本包含不规则动词、名词复数、比较级以及一个多义词比如saw、book、leaves然后逐一对token.lemma_和token.pos_做记录。很快你就会发现词形还原并不是一个“一键清理”工具它更像是一位需要你和它配合的同事——你给它正确的词性它才能给你正确的原形。下一步我计划继续折腾自定义规则把领域词汇注入AttributeRuler让词形还原更贴合真实项目里的专业术语。到时候如果踩到什么新鲜的坑我再来更新。
学NLP这件事最怕的不是没资料而是资料多到不知道该从哪条主线走。今天是我给自己定的“日拱一卒”计划第22天议题是英文词形还原Lemmatization工具选定为spaCy。先说清楚这篇文章能帮你什么如果你刚接触到NLP里的文本预处理对runs、ran、running这些词到底该归成一个词还是保留各自形态有疑问或者你已经被各种词干提取Stemming的粗糙结果坑过那这篇就是为你准备的。我在这22天里踩过不少坑尤其是分词之后直接拿高频词做统计结果leaves和leaf被当成两个独立特征studying和studies也各占一个坑位整个关键词表乱得像一锅粥。后来我才意识到问题不在分词而在我跳过了文本归一化里非常关键的一步——词形还原。spaCy做这件事很方便但它的“方便”背后有一套自己的逻辑不了解这套逻辑你用起来依然会翻车。这篇文章我会把原理、模型选型、实际代码、常见坑以及如何接进真实项目一次性讲透。1. 为什么第22天要专门做英文词形还原NLP流程里的位置1.1 一个肉眼可见的问题runs、ran、running真的是三个词吗先看一个很基础的例子。一段普通的英文文本里可能出现这样的句子“She runs every morning. Yesterday she ran five miles. She is still running now.”如果按词面统计runs、ran、running会被记成三个完全不同的词。但在绝大多数NLP任务里这三个词指向同一个动作“run”只是时态、人称变了。英文的形态变化不像中文那么“干净”动词有第三人称单数、过去式、进行时名词有复数形容词有比较级和最高级。如果你把这些形态各异的词汇直接喂给模型特征空间会迅速膨胀样本稀疏问题也跟着加重。词形还原要解决的就是这个问题把单词还原到它的词典原形也叫词元Lemma。例如runs、ran、running统统回到runleaves回到leafbetter回到good。注意最后这个例子它不是简单去掉后缀能得到的涉及比较级的不规则变化这也是词形还原和词干提取拉开差距的关键场景。1.2 词形还原在任务链中的位置我自己的学习路线是分词Tokenization→ 词性标注POS Tagging→ 依存分析Dependency Parsing→ 词形还原Lemmatization。严格来说词形还原通常出现在词性标注之后因为很多词在还原为原形之前必须先搞清楚它在当前上下文里是什么词性。举个真实场景里的例子saw这个单词作名词是“锯子”作动词是“看见”的过去式。如果不知道它在句子里是名词还是动词你就没法决定该还原成saw还是see。spaCy把词性标注组件和词形还原组件设计成流水线里的不同模块就是为了让还原动作能吃到前面那一步的输出。换句话说词形还原不是一个孤立的查表操作它和上下文理解是绑在一起的。这个位置关系决定了另一件事如果你的下游任务是文本分类、情感分析、主题建模或者检索词形还原通常安排在特征构造之前如果你的下游任务是机器翻译或语法纠错那反而要明确区分时态语态这时候要不要做词形还原就要谨慎了不能一个方案走天下。2. 先分清同路人词干提取和词形还原不是一回事2.1 词干提取的粗糙与代价很多NLP入门资料把Stemming和Lemmatization放在一起讲甚至混着用。我能理解为什么会混因为它们俩的目的相似缩小词汇变体。但方法论和结果差别非常大。词干提取的典型代表是Porter Stemmer它的核心思想是用一连串启发式规则把词尾不断“砍”掉。比如running会被砍成runflies会被砍成flistudies会被砍成studi。看出来了吧它保证的是“词干尽可能短”不保证结果是合法单词。所以你在词干提取结果里会看到一堆中间状态有些看起来像拼写错误有些根本没有语言依据。更麻烦的是词干提取对不规则变化基本无能为力。went拿到Porter里走一趟出来的还是went它不认识go。better会被砍成better因为它只认后缀规则不查词典。在信息检索里这种粗糙有时候能接受因为检索任务看重的是字符串匹配的召回率但在语义任务里把studies变成studi会让下游模型多学一个没有意义的“伪词根”白白增加噪声。2.2 词形还原的目标一个规范形态Lemma词形还原追求的是回到词典里那个规范形态也就是你在字典里查词时看到的主词条。它不只是机械删后缀而是综合考虑词性、上下文、形态变化表最终输出一个合法单词。went还原成gobetter还原成goodcacti还原成cactus这些结果不仅合法而且保留了语义信息。但也正因为要“考虑上下文”词形还原的代价比词干提取高。它需要依赖词性标注的结果规则也更复杂。spaCy之所以是我目前用下来最顺手的方案就是因为它把词性标注和词形还原放在同一条流水线里不需要我自己拼装两套工具。我做了一个小对比方便你直观感受差异。同样是处理一句“The studies are better than before but the leaves fell.”原始词Porter词干提取spaCy词形还原studiesstudistudybetterbettergoodleavesleavleaffellfellfall这四行对比基本可以说明全部问题词干提取在studies、leaves这些规则变体上都输出了非词而词形还原四个全对。所以在做主题建模、文本聚类这类偏语义的任务时我会毫无犹豫选择词形还原而不是词干提取。3. 环境准备与模型选择从en_core_web_sm到trf3.1 安装与下载先交代环境。我用的是spaCy 3.x版本Python 3.9。安装主库很简单pip install spacy但只装主库还不够你需要下载英文模型。spaCy把模型拆成了独立包不像某些库把模型和数据混在安装包里。下载命令如下python -m spacy download en_core_web_sm下载成功后在代码里加载import spacy nlp spacy.load(en_core_web_sm)如果你是第一次接触spaCy可能会有一个疑问为什么要单独下载模型因为spaCy本身只是框架处理英语、德语、中文需要不同的语言资源和预训练参数。模型单独管理的好处是你可以按需切换不同规模的模型而不用重新安装整个框架。这里补一句经验国内网络环境下模型下载偶尔会超时。如果spacy download反复失败你可以去spaCy的模型发布页找到对应模型文件名用下载工具拿到.whl文件再本地pip install xxx.whl效果完全一样。3.2 四种英文模型怎么看怎么选英文模型根据训练数据规模和词向量覆盖度分成好几个版本最常用的四个是en_core_web_sm、en_core_web_md、en_core_web_lg、en_core_web_trf。它们的区别不只是“大小”和“速度”这么简单。模型包大小词向量速度精度适合场景en_core_web_sm约13MB无哈希向量最快够用学习、原型、低资源环境en_core_web_md约44MB有约2万词较快更好普通项目en_core_web_lg约682MB有约50万词较慢更好语义相似度、精度敏感en_core_web_trf约438MB有Transformer编码最慢建议GPU最好高精度场景如果你的任务只是做词形还原和词性标注sm模型完全够。我见过不少人一上来就装lg结果内存涨了速度慢了词的还原结果却没本质提升。因为词形还原更多依赖规则和词性结果而不是词向量覆盖度。词向量主要影响相似度计算和上下文表示的质量。但有一种情况建议直接上md以上你的下游任务还要做文本相似度计算或者你会在自定义语料上做迁移实验。那时词向量就重要了。trf模型最准但它本质是开了个Transformer编码器CPU上跑长文本会很吃力实际项目里要先想清楚算力预算。4. 实战用spaCy完成首次英文词形还原4.1 读取词形还原结果的正确姿势模型加载完成后词形还原几乎是零门槛的。你只要把文本丢给nlp对象然后遍历每个Token取lemma_属性即可。import spacy nlp spacy.load(en_core_web_sm) text The leaves were falling from the trees while I was running faster. doc nlp(text) for token in doc: print(token.text, token.lemma_, token.pos_)输出长这样The the DET leaves leaf NOUN were be AUX falling fall VERB from from ADP the the DET trees tree NOUN while while SCONJ I I PRON was be AUX running run VERB faster fast ADV . . PUNCT注意were还原成befalling还原成fallfaster还原成fast。这正是词形还原该干的活。我特别想强调一个新手容易忽略的点lemma_和pos_要一起看。如果你只取token.lemma_而不看词性某些结果会显得莫名其妙比如saw到底是saw还是see不看pos_永远搞不清楚。所以我在处理文本时几乎总是同时保留这两个字段方便后续排查。4.2 批次处理与字段保存单条文本的循环打印只能用来验证效果真实项目的文本量至少是几千条起步。这时候建议用nlp.pipe()做批次处理它能内部自动分块速度比逐条调用nlp(text)快很多。import spacy import json nlp spacy.load(en_core_web_sm) texts [ The cat sat on the mat., The cats were playing outside., She studied hard and finally passed the exam., ] results [] for doc in nlp.pipe(texts, batch_size64): tokens [ {text: token.text, lemma: token.lemma_, pos: token.pos_} for token in doc ] results.append({text: doc.text, tokens: tokens}) with open(lemmas.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这一段代码基本覆盖了“批量处理字段保存”两个场景。batch_size参数的取值没有绝对标准我一般先设64然后根据机器内存上下调整。如果文本特别长可以把批次调小如果文本短批次调大也无妨。实际项目里我通常还会过滤掉停用词和标点只保留实义词减少下游存储和计算压力。过滤方法很简单token.is_stop和token.is_punct再配合token.pos_白名单。比如valid_tokens [] for token in doc: if token.is_stop or token.is_punct: continue if token.pos_ in (NOUN, VERB, ADJ, ADV): valid_tokens.append(token.lemma_.lower())我把lemma_转成小写是因为后续做词频统计时The和the不能算两个词。这一步看起来简单却是我在实际项目中踩过小坑之后才养成的习惯。5. 引擎盖下面spaCy的Lemmatizer如何工作5.1 流水线组件与词性标注的关系spaCy处理文本的方式是流水线式的。默认的英文流水线大致是tok2vec→tagger→parser→attribute_ruler→lemmatizer。其中tagger负责给每个Token打上词性标签lemmatizer再依据词性执行还原。这也是为什么spaCy的词形还原结果比很多独立工具更可靠——它不是在真空里查词典而是利用前面已经计算好的上下文特征。比如I saw the film里的saw会被tagger标成VERB于是lemmatizer查动词表得到see而The saw is sharp里的saw被标成NOUN于是保持saw。如果没有词性标注这一步同一个词你只能靠字典里的默认顺序猜很容易猜错。实际工程里我们经常用nlp.pipe跑完之后再回头看每个Token的属性这个过程可以对中间产物做检查。比如早期调试时我会打印(token.text, token.pos_, token.lemma_)来确认tagger给的词性和lemmatizer给的还原是否一致。一旦发现某个词在实例里还原得不对第一反应应该是看词性标注对不对而不是怀疑lemmatizer坏了。5.2 查表规则例外英语还原的实际机制spaCy的Lemmatizer可以粗略理解成由三种策略组合运转词典查找表lookups、规则表rules、例外表exceptions。例外表处理的是不规则形态比如went→go、better→good、mice→mouse。这些词没有通用规则可以覆盖只能靠硬编码的词典。规则表处理规则变化比如名词复数加-s、动词过去式加-ed、进行时加-ing。spaCy里的规则通常和形态特征绑定比如看到标签是VBD过去式且词形是fell就确认它是fall的过去式而不是尝试直接剥离后缀。实际判断流程大致是先查例外表如果命中就直接返回没命中就根据词性查规则表匹配词尾规则都搞不定就退回原词。这套“三级策略”保证了大多数常规文本都能被处理同时把不规则变化也兜住了。理解这个机制对排查问题很有用。比如cafe和café一个不带重音一个带重音spaCy的词典可能只收录了其中一种拼写。如果你发现café没有被还原不用惊讶直接加例外规则即可。我后面会专门说怎么加规则。5.3 自定义规则AttributeRuler怎么介入自定义规则最常用的工具是AttributeRuler它能在管道中提前修改Token的属性包括LEMMA。假设你有一个领域词汇yoloedspaCy的词典不认识它你可能希望它还原成yolo。可以用如下方式加一条规则from spacy.pipeline import AttributeRuler nlp spacy.load(en_core_web_sm) ruler AttributeRuler(nlp.vocab) ruler.add( patterns[[{TEXT: yoloed}]], attrs{LEMMA: yolo} ) nlp.add_pipe(attribute_ruler, beforelemmatizer) doc nlp(I yoloed all weekend long.) for token in doc: print(token.text, token.lemma_, token.pos_)输出里yoloed的lemma_就会是yolo。实际项目里这种自定义规则通常来自你对领域语料的观察。比如你处理的是医学文本有很多专业名词变体处理的是饭馆评论有很多菜名的复数写法。把高频错误样本统计出来逐个添加规则是见效最快的优化手段。6. 踩坑实录词性误判、大小写、专有名词与外来说6.1 一字之差词性标注错误如何带偏还原我实际测试过一句话“The saw cuts wood.”这句话里的saw是名词指锯子。结果用en_core_web_sm一跑tagger把saw标成了VERBlemmatizer跟着把它还原成see。语义完全歪了。这不是spaCy独有的问题而是所有NLP流水线共有的风险上游模块的错误会向下游传递。词性标注本身的准确率在通用模型上大约是95%出头意味着每20个词就有1个可能标错。单独一个词标错词形还原就跟着错所以你会看到see出现在一个和“看”毫无关系的句子里。针对这个问题我的做法是分两层。第一层在发布到生产环境之前用自己的语料做一次人工抽样验证记录错误高频词然后针对性地加AttributeRuler规则。第二层在统计任务里把词性标注结果也纳入过滤条件比如只统计被标成NOUN的名词这样即使个别误判对整体分布的干扰也会被稀释。6.2 大小写和标点对还原的影响第二个高频坑是大小写。全大写的标题里Running会被正常还原成run这没问题但有一些专有名词比如地名Reading雷丁如果用户在文本里写成reading模型会把它当动词标注并还原。Reading和reading这两个词的区分本质上靠的也是词性标注。标签器看到大写Reading且后面跟介词短语可能会按专有名词处理但如果你把文本统一转成小写这个信息就丢了Reading就会变成read。所以这里有个取舍如果你在预处理阶段做了lower()以便统一关键词那么词形还原的专有名词判断能力就会下降。我的建议是如果下游任务需要区分专有名词就不要在小写化之后再跑词形还原而是先还原、后小写或者干脆保留pos_等于PROPN的Token原样。标点对词形还原本身影响不大但会影响词频统计。如果你不把句点和逗号过滤掉词表中会混入大量标点看起来非常脏。所以我在前面的代码里专门加了token.is_punct的判断。6.3 专有名词与缩写词的保留策略英文专有名词如Google、Python在大多数情况下不需要还原还原结果一般也还是原词。但有些系统会根据名词复数规则把MacBooks还原成MacBook这可能是好事也可能不是取决于你的需求。如果你希望保留品牌原样可以在清洗阶段对PROPN的Token直接跳过lemmatizer的输出保留原文。缩写词是另一个容易出问题的地方。像Dr.、vs.、e.g.spaCy通常能识别并给出相应的lemma_。但我遇到过I被还原成I第一人称代词原形就是大写结果有人误以为是大写问题统一小写后变成i在词向量里找不到对应向量。这类问题很隐蔽排查起来费时间所以我会提醒所有刚上手的朋友保存原始文本和还原结果时建议同时保存token.text、token.lemma_、token.pos_三个字段很多坑都能靠这三列数据定位。7. 词形还原接入真实项目的三种姿势7.1 关键词聚合和词频统计最直接的用途是做词频统计。假设你要分析一堆英文评论统计高频词。不做词形还原app、apps、application、applications全被当成独立词每个词的频数都被稀释做了还原之后它们汇聚到application或app取决于词典收录的是哪个原形关键词分布一下子就清爽了。我习惯用Counter来做这一步简单且快速from collections import Counter texts [ The applications are running smoothly., The application has been downloaded., Several applications were reviewed., ] counter Counter() for doc in nlp.pipe(texts): for token in doc: if token.is_stop or token.is_punct: continue if token.pos_ in (NOUN, VERB, ADJ): counter[token.lemma_.lower()] 1 for word, count in counter.most_common(): print(f{word}: {count})application最终会汇聚成一个计数。这个小例子解决了我最开始提到的“关键词表脏乱差”问题。7.2 文本检索和相似度计算统一形态在做简单文本检索时用户搜索run文档里写的是running或ran如果索引时做了词形还原两边就能匹配上。这一点在构建最小可用的本地搜索工具时特别有价值。具体做法是在建立倒排索引之前对文档做分词词形还原把处理后的词元作为索引词项用户查询的时候同样走一遍分词还原再在索引中查找。这样做比传统的子串匹配召回率高很多而且实现成本很低。当然如果项目体量到了搜索平台级别那需要对位中文分词的配置或英文的分析器配置做调优跟这里讲的是同一个道理。7.3 数据管线性能优化只保留需要的组件最后一个偏工程的经验默认流水线包含parser依存分析器它是整条流水线里最重的组件之一。如果你的场景只需要词性标注和词形还原根本用不到依存关系那就可以禁用parser速度会有明显提升。nlp spacy.load(en_core_web_sm, disable[parser])或者更精细一点只启用需要的组件nlp spacy.load(en_core_web_sm, disable[parser, ner])我在一次处理80万条英文评论的测试里禁掉parser和ner之后整体耗时大约下降了30%到40%。对于以词形还原为核心预处理步骤的项目这个优化几乎是无痛的。唯一需要记住的是如果之后你用token.dep_或者token.head做特征那就不能禁用parser因为关联信息全没了。8. 我的第22天小结与后续计划学到现在我最大的感受是词形还原的代码量极低但思考量极高。极低的点是只要调对了模型调用token.lemma_就能得到结果极高的点是你怎么理解模型结果的边界、怎么在领域数据上修正错误、怎么决定哪些词需要还原哪些词不能动这些判断往往决定整个文本预处理的质量。如果你要跟着练习我建议手写一个英文短文本包含不规则动词、名词复数、比较级以及一个多义词比如saw、book、leaves然后逐一对token.lemma_和token.pos_做记录。很快你就会发现词形还原并不是一个“一键清理”工具它更像是一位需要你和它配合的同事——你给它正确的词性它才能给你正确的原形。下一步我计划继续折腾自定义规则把领域词汇注入AttributeRuler让词形还原更贴合真实项目里的专业术语。到时候如果踩到什么新鲜的坑我再来更新。
