浅谈嵌套命名实体识别（Nested NER）

©PaperWeekly 原创 · 作者｜张成蹊

单位｜北京大学硕士生

研究方向｜自然语言处理

序

命名实体识别（Named Entity Recognition, 下称 NER）任务，主要目的是从一段话中抽取出其中可能为实体的所有元素。比如：

“Hi Siri, 今天北京天气怎么样？”

如果下游任务要求我们从其中抽取出地点，那我们期望 北京 能被识别成 Location，如果我们希望从中抽取的产品名称，那么 Siri 应该被标记成 Product —— 换言之，能从句子中抽出什么实体，是由我们提前给定的标签集合定义的。

在一个任务型对话系统中，一些可能在后台处理中使用到的实体都应该被抽出来：我们有理由相信，Siri 是真正将 北京 给提取出来了，然后再通过后台查询到了天气~~，而不是找了一个人工客服在后台即时回复~~。

NER 在很多下游任务中都是非常重要的一环。比如在电商行业，我们可能需要从用户的查询中提取出品牌或商品，来针对性地给用户返回内容。金主爸爸可能也希望用户在查指定品牌的时候，将一些商品放在第一位。

在任务型人机对话方面，正如上面所说，一个合格的 Chatbot 需要能够准确地识别时间、地点、事件等元素以回答相关问题或安排日程，同时做到不偷听用户的日常对话。

而嵌套 NER，顾名思义，就是识别的实体中可能会存在嵌套的情况。比如北京大学不仅是一个组织，同时北京也是一个地点；雅诗兰黛小棕瓶是一个产品，同时雅诗兰黛是一个品牌。

准确地识别嵌套内容有什么作用呢？简单来讲，如果一个模型能够识别出北京大学是一个组织，它倾向于将所有出现的北京大学都标记成组织。

但如果它能够在识别前者的同时将北京标记成地点，我们就认为它有能力将所有[地点]大学的模式都识别出来，因为后者的角度，模型学到的是一种 pattern，而非记住了一种具体情况。此外，提取出来的额外信息也能作为辅助特征，增强其他任务的效果。

具体地，我会介绍以下几部分内容：

• 当前普遍使用的传统 NER 解决方案；

• 传统 NER 在解决嵌套 NER 任务时存在的问题；

• 如何解构 NER 任务，从不同的角度解决问题，使模型能够识别嵌套的 NER；

• 介绍近几年嵌套 NER 领域有代表性的解决方案。

从 NER 到 Nested NER

2.1  NER 任务的解决方案

在进入 Nested NER 之前，我们先来简单谈谈目前普通 NER 任务（下称 Flat NER）的解决方案，即，将实体识别当做序列标注问题。

具体来说，对于一个长度为 的句子 ，其中 表示句子中的第 个 token。序列标注即给每个 token 打一个标签，来表示这个 token 所在的实体类别。

一组相邻且类别相同的 token 构成的子序列 就是我们想要的实体。这样，一个抽取实体的问题就被转化为一个给每个 token 进行分类的问题。

在序列标注中，需要定义不同的 Schema，来使得将序列标注的结果从 token 层面提高到实体层面，并且保持其唯一性。定义有效的 Schema 的意义在于消除从 token 标注复原出实体时的歧义，例如：

如果我们希望识别出地点。给定句子：北京市海淀区。我们希望抽取出来两个实体，分别为：北京市+海淀区。然而如果只对每个 token 进行分类，所有的 token 都将被分到 Location 标签中，这样两个相邻的同类型实体边界就无法正确区分开来。

为此，我们需要定义一个 Schema（即类型标签），使得给 token 打完标签之后，能够从 token 复原出实体，同时有效标识两个实体之间的边界。在这里介绍两种最常见的 Schema：

• BIO：即 Beginning、Inside、Outside，对于一个实体的第一个 token，标注为 B-[type]，实体其他位置的 token 标注为 I-[type]，不属于任何实体的 token 标注为 O；这样，对于一个标签数    的实体集，使用 BIO 标注将转变为 个标签；

• BIOES：即 Beginning、Inside、End、Outside、Single。其中 End 用来标识一个实体的结束，而 Single 用来标识仅包含一个 token 的实体。

在给定 BIO 标注 Schema 的前提下，北京市海淀区的标注结果为：B-Location, I-Location, I-Location, B-Location, I-Location, I-Location。能够完整且没有歧义地复原出模型的标注结果。

基于上述表述，我们可以将一个基于序列标注（Sequence Labeling）的 NER 任务解决方案总结为两个简单的步骤：

1. 选择一个有效的标注 Schema；

2. 选择分类模型（常用 CNN/Bi-LSTM/BERT），对每个 token 进行分类；根据分类结果复原出原文中的实体。

2.2 Nested NER

我们现在回头来看嵌套 NER 的解决方式，一步步提出该问题的基础解决方案，并探讨这些方案存在的不足。

很显然，2.1 节中所定义的 Flat NER 解决方案是没有办法解决嵌套情况的，因为在嵌套 NER 中，一个 token 可能分别拥有两个不同的类型。

例如：北京大学中的北同时属于 B-Location，也属于 B-Organization；而京也拥有 I-Location 与 I-Organization 两个标签。

如果从最简单的角度出发，能够想出什么方法，使得现有的NER解决方案支持嵌套的情况呢？

2.2.1 将分类任务的目标从单标签变成多标签

一个容易想到的解决方式是：Schema 不变，模型也不变，将输出从单分类转变为多分类：即在最后分类的时候，从输出一个类到输出所有满足一个指定阈值 的所有类。更为具体地，存在以下两种方案：

• [1] 完全不改变 Schema，只是在输入训练集的时候，训练集中的 label 从原来的 one-hot 编码形式变成一个指定类别的均匀分布；在训练时将损失函数改为 BCE 或 KL-divergence；在进行推理时，给定一个 hard threshold，所有概率超过这个阈值的类别都会被预测出来，当做这个 token 的类。

• [2] 修改 Schema，将可能共同出现的所有类别两两组合，产生新的标签（如：将 B-Location与 B-Organization 组合起来，构造一个新的标签 B-Loc|Org）；这样做的好处是最后的分类任务仍然是一个单分类，因为所有可能的分类目标我们都在 Schema 中覆盖了。

我相信在这些年探索中，这个方案是有学者研究过的，因为它简单易行，改动也小；不过除了 NAACL18 与 ACL19 中的两篇文章仔细探讨了这些方案以外，我很少有见到有使用这种思路解决问题的 paper。因为它存在一些比较明显的问题：

1. （仅针对第一种实现方式）模型学习的目标设置过难，阈值定义比较主观，很难泛化；

2. （仅针对第二种实现方式）指数级增加了标签，导致分布过于稀疏，很难学习；对于多层嵌套，需要定义非常多的复合标签；

3. 以及最初的问题：修改后的 Schema 预测的结果，复原回实体的时候又不再具有唯一性了。

当然，我们仍然能够给模型添加规则与约束，来一一解决这些问题，具体内容在论文中有相应的阐述。

2.2.2 修改模型的Decode过程

在这里，Decode 过程指的是基于模型输出的 token 表示来给 token 分类的过程，在 Sequence Labeling 中指的是 FFN + Softmax/CRF + Argmax 这一套操作。

严格来说，解决方案 1 的第一个实现方式也算是非常 naive 的修改了 Decode 过程，不过在这里我们讨论一些更加有效的方案。

值得注意的是，修改 Decoder 的目的是为了保证能够给一个 token 同时赋予多个类别，所以我们仍然将下面的方案视作 Sequence Labeling 任务（尽管最后输出的 label list 长度可能与 token 的数量不同，但这是因为由原来的单分类变成了多分类所必然导致的）。

• [2] 既然直接使用 FFN 映射做单分类没法解决嵌套问题，做多分类又不容易做work，那是否可以考虑使用生成式的方法，如 seq2seq 中的 Decoder 来逐个生成每个 token 的标签？使用 Decoder 能够将输入的 token 数量与输出的类别数量解绑，允许给token打上超过一个的标签——但是与原来的生成方法不同，除了使用特殊字符[EOS](end of sentence)来标识整个生成过程结束以外，我们需要引入一个特殊字符[EOW](end of word)来标识接下来生成的是属于下一个 token 的标签。

• [3] 使用分层的方式对token的表示进行预测也是一个非常有意思的方案：如果一次分类无法解决实体嵌套的问题，那就对第一次的分类结果继续做分类，如是迭代，直到达到最大迭代次数或是不再有新的实体产生为止。这种解决方案存在的问题是对 Decoder 的学习要求较高，如果前面的迭代过程中出现了错判，这个问题可能会传递到后续迭代过程中。

这一类方法相较于普通的多标签分类，从任务本身的角度来进行设计，通过横向（序列生成）与纵向（分层标注）两个层面修改了原始的 Sequence Labeling 模型将输入 token 与输出 label 强制绑定的形式。

2.2.3 抛弃Sequence Labeling

依稀记得之前看过一篇让我印象深刻的知乎文章，名为"丢掉幻想，全面拥抱Transformer"。借由此名，最后一种解决嵌套 NER 问题的方式可以叫做"丢掉序列标注，全面拥抱 Multi-Stage" 。

我们已经在上文中多次提到，序列标注任务是天然不支持给一个 token 赋予多个标签的，尽管我们已经进行了多个层面的修饰，使它能够应用到多标签分类上。

但是既然它应用到 Nested 任务上时效果并不突出，也没有其不可替代性，为什么不直接舍弃掉这个任务形式，尝试其它的解决方案呢？

撇开原来的 NER 解决方案，从头考虑一个实体识别的方案，我们仍然从一个非常 naive 的 proposal 出发：

将句子 中所有的子序列全部枚举出来，即得到一个子序列集合：。

训练一个分类器  ，负责将子序列映射到给定的标签集合（即：Location, Organization, ..., O）中：