spaCy v2.2：自然语言处理库的重大更新

介绍 spaCy v2.2

2019年10月2日发布，阅读时间约12分钟。版本2.2的spaCy自然语言处理库更加精简、清晰和用户友好。除了新的模型包以及用于训练、评估和序列化的功能外，还进行了大量的错误修复，改进了调试和错误处理，并大大减少了库在磁盘上的大小。

在感谢整个spaCy社区贡献补丁和支持的同时，某机构有幸迎来了两位值得为近期快速改进特别赞誉的新团队成员：Sofie Van Landeghem和Adriane Boyd已全职投入spaCy的开发。这使得核心团队增加到四位开发者——因此，未来可以期待更多的成果。

新模型与数据增强

spaCy v2.2附带重新训练过的统计模型，这些模型包含错误修复，并针对小写文本提高了性能。与其他统计模型一样，spaCy的模型可能对训练数据与实际处理数据之间的差异很敏感。一个困扰已久的问题是大小写和规范性：我们拥有的大多数训练数据是经过良好编辑的文本，这导致对大小写和标点不统一的文本识别准确率较低。

为了解决这个问题，开始开发一个新的数据增强系统。在v2.2模型中引入的第一个功能是支持配对标点符号（如引号字符）的单词替换系统。在训练期间，可以提供替换词典，在每个训练周期（epoch）的随机句子子集中进行替换。以下是一个这种改进可以解决的示例问题：德语NER模型是在使用“作为开引号符号的树库上训练的。当Wolfgang Seeker开发spaCy的德语支持时，他使用了一个预处理脚本，将其中一些引号替换为Unicode或ASCII引号。然而，像这样的一次性预处理步骤很容易被遗忘——最终导致了v2.1德语模型中的一个错误。更好的做法是在训练期间进行这些替换，这正是新系统所允许的。

如果使用spacy train命令，新的数据增强策略可以通过新的--orth-variant-level参数启用。默认值设置为0.3，这意味着在训练期间，某些词元（token）的30%出现会被替换。此外，如果一个输入被随机选中进行拼写替换，它还有50%的概率被强制转换为小写。我们仍在试验这个策略，但希望它能使模型对大小写变化更加稳健。请告诉我们你的使用体验！未来将开发更多的数据增强API，特别是当我们为这些策略建立更多评估指标之后。

为什么不发布更多模型？ Universal Dependencies语料库使得分发更多语言的模型变得相当容易。然而，大多数基于UD训练的模型在实际工作中并不那么有用。UD语料库通常规模较小，采用CC BY-NC许可，并且往往不提供NER标注。为了避免破坏向后兼容性，我们只在拥有更成熟的模型时才推出新的语言支持。

我们还很高兴地推出另外两种语言的预训练模型：挪威语和立陶宛语。这两种语言的准确度应在后续版本中得到改善，因为当前的模型既没有使用预训练的词向量，也没有使用spacy pretrain命令。这些语言的添加得益于spaCy社区的出色工作，特别是TokenMill贡献了立陶宛语模型，以及某大学语言技术小组贡献了挪威语模型。对于添加新语言模型，我们一直采取谨慎的态度，因为我们希望确保一旦添加了模型，我们就能在spaCy的每个后续版本中继续支持它。这意味着我们必须能够自己训练所有语言模型，因为后续版本的spaCy不一定与之前的模型套件兼容。随着自动化系统的稳步改进和新团队成员的加入，我们期待很快能添加更多语言。

包含20个类别的更好的荷兰语NER

我们的朋友在某机构为spaCy的荷兰语支持做出了巨大贡献。对于v2.2，他们更进一步，标注了一个新的数据集，这应该能使预训练的荷兰语NER模型有用得多。新的数据集在LaSSy语料库上提供了OntoNotes 5标注。

这使得我们可以用基于20个类别的黄金标准实体训练的模型，替换半自动化的维基百科NER模型。可以在我们新的、改进的模型目录中看到更新后的结果，该目录现在显示更多关于不同模型的细节，包括标签方案。乍一看，如果只看评估数据，新模型可能看起来更差。然而，之前的评估是在半自动创建的维基百科数据上进行的，这使得模型更容易获得高分。当我们添加预训练词向量并将spacy pretrain命令支持集成到模型训练流程中时，模型的准确度应会进一步提高。

用于训练的新CLI功能

spaCy v2.2包含了对训练和数据开发工作流程的几个可用性改进，特别是针对文本分类。改进了错误消息，更新了文档，并使评估指标更加详细——例如，评估现在默认提供每个实体类型和每个文本类别的准确度统计。

最有用的改进之一是在spacy train命令行界面中集成了对文本分类器的支持。现在可以像训练解析器、实体识别器或词性标注器一样，编写如下命令：

python -m spacy train en /output /train /dev --pipeline textcat --textcat-arch simple_cnn --textcat-multilabel

关于所需数据格式的更多信息，可以在API文档中阅读。为了让训练更加容易，还引入了一个新的debug-data命令，用于验证训练和开发数据，获取有用的统计数据，并发现诸如无效实体标注、循环依赖、低数据标签等问题。在训练前检查数据应该能节省大量时间，因为训练数小时后遇到错误绝不是什么有趣的事。

更小的磁盘占用，更好的语言资源处理

随着spaCy支持更多语言，磁盘占用空间一直在稳步上升，特别是在添加了基于查找的词形还原表支持后。这些表以前存储为Python文件，在某些情况下变得相当大。我们已经将这些查找表转换为gzip压缩的JSON格式，并将其移出到一个单独的包spacy-lookups-data中，如果需要，可以将其与spaCy一起安装。根据你的系统，你的spaCy安装现在应该会小5-10倍。

pip install -U spacy[lookups]

什么时候需要查找包？ 预训练模型已经包含它们的数据文件，因此只有在需要为尚未提供预训练模型且不由第三方库支持的语言使用词形还原时，或者在使用spacy.blank创建空白模型并希望它们包含词形还原规则和查找表时，才需要安装查找数据。

在底层，大型语言资源现在由一个一致的Lookups API提供支持，在编写自定义组件时也可以利用这个API。自定义组件通常需要可供Doc、Token或Span对象访问的查找表。自然的位置是在共享的Vocab中——这正是Vocab对象存在的目的。现在，自定义组件也可以使用新的lookups API在那里放置数据。

DocBin用于高效序列化

高效的序列化对于大规模文本处理非常重要。对于许多用例，一个好方法是将spaCy的Doc对象序列化为numpy数组，使用Doc.to_array方法。这允许你选择关心的属性子集，使序列化非常快速。然而，这种方法确实会丢失一些信息。值得注意的是，所有的字符串都表示为64位哈希值，因此在反序列化Doc时，需要确保其他进程中这些字符串是可用的。

新的DocBin类帮助高效地序列化和反序列化Doc对象集合，自动处理许多细节。如果使用像Dask这样的多进程库，这个类会特别有帮助。以下是一个基本用法示例：

import spacy
from spacy.tokens import DocBin

doc_bin = DocBin(attrs=["LEMMA", "ENT_IOB", "ENT_TYPE"], store_user_data=True)
texts = ["Some text", "Lots of texts...", "..."]
nlp = spacy.load("en_core_web_sm")
for doc in nlp.pipe(texts):
    doc_bin.add(doc)
bytes_data = doc_bin.to_bytes()

# 稍后反序列化，例如在新进程中
nlp = spacy.blank("en")
doc_bin = DocBin().from_bytes(bytes_data)
docs = list(doc_bin.get_docs(nlp.vocab))

在内部，DocBin将每个Doc对象转换为numpy数组，并维护所有管理的Doc对象所需的字符串集合。这意味着添加的文档越多，每个文档的存储效率就越高——因为可以更有效地共享字符串。序列化格式本身是gzip压缩的msgpack，这应该便于未来扩展格式而不破坏向后兼容性。

10倍更快的短语匹配

spaCy的PhraseMatcher类提供了一种高效的方法，用于执行具有大量查询的精确匹配搜索。它专为诸如查找维基百科中所有实体提及，或从大型术语列表中查找所有药物或蛋白质名称等用例设计。PhraseMatcher使用的算法有点特别：它利用了spaCy的Token对象指向在所有实例间共享的Lexeme结构这一事实。单词被标记为可能开始、包含或结束至少一个查询，然后使用Matcher对象在这些抽象标签上进行搜索，最后一步过滤掉潜在的不匹配。

先前PhraseMatcher算法的关键优势在于其扩展到大型查询集的性能。然而，当使用较少查询时，它不一定那么快——这使得其性能特点有点反直觉——特别是因为该算法是非标准的，并且依赖于spaCy的实现细节。最后，随着库的发展，它对实现细节的依赖引发了许多维护问题，导致了一些细微的错误，使某些查询无法匹配。为了解决这些问题，v2.2用一个更直接的基于字典树（trie）的算法替换了PhraseMatcher。因为搜索是在词元而不是字符上执行的，匹配速度非常快——即使在实现使用Cython数据结构进行优化之前。以下是在10,000篇维基百科文章上进行搜索的快速基准测试。

# 查询	# 匹配数	v2.1.8 (秒)	v2.2.0 (秒)
10	0	0.439	0.027
100	795	0.457	0.028
1,000	11,376	0.512	0.043
10,000	105,688	0.632	0.114

当使用少量查询时，新实现的性能提高了近20倍——即使在使用10,000个查询时，仍然快了近5倍。新实现的运行时间大约随着查询数量每增加一个数量级而翻倍，这表明在大约100万查询时，运行时间可能会持平。然而，先前算法的运行时间主要对匹配数量（包括完全匹配和部分匹配）敏感，而不是查询短语的数量——所以这实际上取决于找到了多少匹配。可能有些查询集由于查询以常见词（如“the”）开头，会产生大量的部分匹配。新实现的性能应该更加一致，我们预计在几乎所有情况下它都会更快。如果确实存在先前实现表现更好的用例，请告知我们。

新视频系列

如果你错过了，可能也会对我们与数据科学讲师Vincent Warmerdam合作制作的新手向视频教程系列感兴趣。Vincent正在构建一个系统，用于自动检测大量文本中的编程语言。可以跟随他从最初的想法到原型，再到数据收集和从头开始训练统计命名实体识别模型的整个过程。

我们对这个系列感到兴奋，因为我们正试图避免教程中的一个常见问题。大多数教程只向你展示“一帆风顺”的路径，一切都完全按照作者的意图进行。问题比技术本身更大、更根本：“画猫头鹰的其余部分”这个梗之所以引起广泛共鸣是有原因的。避免这个问题的最佳方法是将铅笔交给其他人，以便真正看到这个过程。前两集已经发布，还有更多内容即将推出！

资源

• spaCy v2.2：v2.2的新功能
• 发布说明：详细概述
• spaCy模型目录：下载预训练模型
  更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）或者 我的个人博客 https://blog.qife122.com/
  对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）