简介
实体解析 (ER) 是消除实体歧义的过程, 实现方法是将文本提及的内容映射到查找知识库 (KB) 中最合适的现实名称。 例如,将 `
madrid fc` 解析为 `
Real Madrid Club de Fútbol,`,其中前者是后者的众多释义之一。 实体解析通常还有很多其他叫法,例如实体匹配、实体链接、记录链接或记录重复数据删除。 实体解析是 MindMeld 的
NLP 管道的一个组成部分,用于对照预填充的知识库进行匹配,消除在用户输入中识别的任何实体的歧义。 请查看
官方文档,了解如何为实体解析器创建知识库,并在构建 MindMeld 应用时使用此知识库。近来,MindMeld 提供了两种实体解析选择:一种基于
Elasticsearch 全文搜索和分析引擎,另一种基于简单的精确匹配算法,作为回退选项。 随着 MindMeld 应用日益多样化,这些选项可能并不总是具备可行性。 为了提供扩展支持,MindMeld 现在提供两个额外的实体解析选项:一个基于
TF-IDF,另一个基于预先训练的神经模型表示(
BERT、
GloVe、
fastText 等)。 值得注意的是,这些新选项不依赖 Elasticsearch(及其服务)。 在深入了解这些新选项之前,我们先快速回顾一下如何在 MindMeld 中构建实体知识库。 以下是
食品订购蓝图中的一个示例,其中包含为消除食品名称歧义而创建的知识库:
实体解析知识库快照
可以看到,`cname` 字段(规范名称)和 `whitelist` 字段例示了每种食品的一些通俗用法,`id` 字段引用的是知识库中唯一的、官方认可的记录。 这三个字段大体构成了知识库中的一个实体对象。 `cname` 字段中的文本通常用于对话响应,而 `whitelist` 字段中的文本则与规范名称一起用作消除歧义的别名。 通常,如果 `whitelist` 字段填充得很全面(例如,包含替代用法、拼写错误、简短形式等),实体解析器会获得最佳结果。 在某些应用中,这种数据管理过程可能很冗长乏味,但在处理高度专业化领域的实体时是不可避免的。
详细了解新增解析器
在精确匹配之外的解析器中,第一步是为需要消除歧义的输入文本以及作为消除歧义别名的知识库中的所有条目(cname 加 whitelist)获得一个向量表示。 然后,通过使用某种形式的矢量相似性匹配(例如余弦相似性),对别名进行评分和排序。 在新增的实体解析选项中,基于 TF-IDF 的解析器在计算稀疏向量上的余弦相似性之前,会精选各种 n 元语法特征(即表层文本特征)。 另一方面,预先训练的基于嵌入器的解析器在文本的密集向量表示上使用余弦相似性进行匹配。 与其他方法相比,利用预先训练的嵌入器进行实体解析有一些优势。 例如,它们可以提供对文本的语义理解,无需大量填充白名单(例如,“表现低于预期”相当于“表现不佳”),并可实现向多语言实体匹配的轻松过渡(例如,推断西班牙语中的 `tercio` 与英语中的 `third` 含义相同)。 然而,预训练和推理之间的差异,例如输入文本长度的差异,会使预先训练的嵌入器处于劣势。 此外,由于底层的密集向量计算,嵌入器模型的推理时间可能比其他解析器选项长。 但如果调整得当,嵌入器模型的性能将超越主要基于表面级文本特征的其他解析器选项。 下面的分析中,将预先训练的基于嵌入器的解析器与 Elasticsearch 和 TF-IDF 实体解析器进行了比较。 为该比较策划的数据集既包括表层文本匹配,也包括语义匹配。
不同解析器的性能
使用各种内部精选数据集进行实验后,得出了不同实体解析器在短文本实体匹配方面的平均性能。 此处将排名第一的检索得分作为准确性的衡量标准:
不同实体解析器的性能
预先训练的 BERT 变体可作为
Huggingface 句子转换器的一部分使用,该图仅显示了前 5 个表现最佳的变体的分数。 预先训练的词嵌入模型(例如 fastText)的性能通常逊色于 BERT 嵌入器模型或基于 TF-IDF 的解析器。 如此低的性能,可能是域偏移和缺乏微调导致的。 使用性能最佳的 BERT 变体 (‘
distilbert-base-nli-stsb-mean-tokens’) 的不同配置进行进一步分析,得出以下结果:
使用性能最佳的 BERT 变体时不同配置的性能
结果表明,诸如
BERTScore 之类的替代相似性分数不具备竞争优势。 此外,利用余弦相似性时将 BERT 模型的不同层连接起来,可以获得与 Elasticsearch 不相上下的性能增益。 这一点十分直观,因为 BERT 的不同层可以捕获补充信息。 即使在
量化 BERT 变体以减少内存占用和时间复杂度后,性能也仅下降 2-3%。 此外,当对输入中包含拼写错误的随机噪声数据进行评估时,基于 TF-IDF 的解析器性能优于其他解析器。 这可能是由于该解析器捕获了不同的 n 元语法集。 (在这个实验中,白名单文本被重复用作测试实例,并在其中诱导拼写错误。 因此,在噪声百分比为 0% 时,观察到的准确率为 100%,原因在于所有测试实体全部出现在白名单中!)
拼写错误引起的文本匹配性能问题
最后,下图说明了不同解析器选项之间推理时间复杂度的差异:
(从左到右依次为:最精确的 BERT、TF-IDF 和 Elasticsearch)。在不同规模的知识库中进行测量时每个实体的推理时间。 X 轴显示知识库的大小,Y 轴显示每个实体的时间(以毫秒为单位)。 黄色是对输入文本进行编码的推理时间,绿色是相似度计算的推理时间。 TF-IDF 和 Elasticsearch 的时间复杂度相当,而性能最佳的 BERT 变体量化后速度降到了原来的 1/20。 当我们不连接最上面的 4 层时,速度缓慢情况有所改善,速度仅降至原来的 1/10,但同时会损害精确度。
选择并配置实体解析器
MindMeld 实体解析器的配置可根据所使用的解析器接受各种可配置参数。 以下代码段在应用的 `config.py` 中提供,使用从 Huggingface 选择的经过预先训练的 BERT 模型:
ENTITY_RESOLVER_CONFIG = { ‘model_type’: ‘resolver’, ‘model_settings’: { ‘resolver_type’: ‘sbert_cosine_similarity’, ‘pretrained_name_or_abspath’: ‘distilbert-base-nli-stsb-mean-tokens’, … } } 可以通过修改 `embedder_type` 参数使用其他嵌入器模型:
ENTITY_RESOLVER_CONFIG = { ‘model_type’: ‘resolver’, ‘model_settings’: { ‘resolver_type’: ’embedder_cosine_similarity’, ’embedder_type’: ‘glove’, … } } 还可以在使用嵌入器模型时指定运行时配置,如 `batch_size`,以及嵌入器模型特定配置。 要加载基于 TF-IDF 的解析器,可以执行以下操作:
ENTITY_RESOLVER_CONFIG = { ‘model_type’: ‘resolver’, ‘model_settings’: { ‘resolver_type’: ‘tfidf_cosine_similarity’, … } } 对于知识库中的每个实体对象,还会计算特殊嵌入(即所有别名嵌入的平均值/最大池),并将其用于解析(如果已配置)。 这种特殊嵌入通常会提高解析器的准确性,且只会略微增加计算开销。 有关完整详细信息和所有可配置选项,请参阅
官方文档中的“配置”部分。
结束寄语和未来工作模式
总之,建议使用基于 Elasticsearch 的解析器,除非特殊场景要求不能使用此解析器。 作为备用选项,当需要更多语义匹配时,可以使用基于嵌入器模型的解析器,如果不存在特别要求,可以使用基于 TF-IDF 的解析器。 MindMeld 中的 ER 模块尚未提供任何 API 来衡量哪个解析器最适合您的应用。 请继续关注我们计划增加的支持,以及优化基于嵌入器模型的解析器的方法。
注册 Webex 访问我们的
主页或直接
与我们联系,寻求帮助。
点击此处详细了解 Webex 提供的产品和服务,注册免费账户。