本文提出了一种新的实体干系联结抽取标注规划，可在一个模型中实现真正意义上的单阶段联结抽取，不生存暴光偏向，并且同时可办理多干系堆叠和多干系实体嵌套的问题。
阅读本文大约需要 12 分钟，主要分为以下几个部分：问题背景介绍、idea的由来、标注规划、模型、实验结果、未来工作。对干系抽取任务比较熟悉的同学可以略读或者直接跳过第一部分。
一、背景
干系抽取是从非结构化文本中抽取实体和干系的文本处理技术，属于自然语言处理中的常见任务。它是自然语言理解的基础，在智能问答、信息检索等领域有重要应用。简单来说就是给定一段文本，要抽出其中的（subject, predicate, object）三元组。例如：
{
'text': '《邪少兵王》是冰火未央写的
网络小说连载于旗峰天下',
'relation_list': [
{
'subject': '邪少兵王',
'object': '冰火未央',
'predicate': '作者'
},
]
}
pipeline 的步骤一般先做实体识别，再对实体对进行干系分类。这类步骤忽略了实体与干系之间的联系，而且生存误差累积的问题。
为了充分利用实体与干系的交互信息和依赖干系，联结抽取的思路应运而生，即在一个模型中同时对实体和干系进行统一抽取。较早的联结抽取步骤，如 NovelTagging，没法办理干系堆叠的问题。当一个或一对实体同时出现在多个干系时，单纯的序列标注就不再管用了，例如：
文本
干系
单实体堆叠
周星驰主演了《喜剧之王》和《大话西游》。
（周星驰，演员，喜剧之王）（周星驰，演员，大话西游）
实体对堆叠
由周星驰导演并主演的《功夫》于近期上映。
（周星驰，演员，功夫）（周星驰，导演，功夫）
后来提出的一些步骤已经可以办理堆叠问题，如 CopyRE [1]、CopyMTL [2]、CasRel（HBT）[3]等，但它们在训练和推理阶段生存暴光偏向。即在训练阶段，使用了 golden truth 作为已知信息对训练过程进行引导，而在推理阶段只能依赖于预测结果。这导致中间步骤的输入信息来源于两个不同的分布，对性能有一定的影响。
虽然这些步骤都是在一个模型中对实体和干系进行了联结抽取，但从某种意义上它们“退化”成了“pipeline”的步骤，即在解码阶段需要分多步进行。这也是它们生存暴光偏向的本质原因。
本文提出了一种新的实体干系联结抽取标注规划，可在一个模型中实现真正意义上的单阶段联结抽取，不生存暴光偏向，保证训练和测试的一致性。并且同时可办理多干系堆叠和多干系实体嵌套的问题。
论文标题：
TPLinker: Single-stage Joint Extraction of Entities and Relations Through Token Pair Linking
论文链接：
https://arxiv.org/abs/2010.13415
源码链接：
https://github.com/131250208/TPlinker-joint-extraction
二、Idea的由来
说了那么多，终于要进入正题了。我最初的 idea 是为了办理一个比较极端的情况，暴光偏向的问题其实是“顺便”办理的。在许多干系抽取的比赛数据集中，我发现部分干系的实体生存嵌套，请看以下两个例子：
文本
干系
干系内嵌套
周星驰主演了《喜剧之王》和《大话西游》。
（哈尔滨工业大学，位于，哈尔滨）
干系间嵌套
由周星驰导演并主演的《功夫》于近期上映。
（北京市，包含，通州）（北京市政府，位于，通州）
虽然当前已经有很多步骤可以专门用于识别嵌套实体，但是把它们直接融合到干系抽取中也并不是那么容易。即使可以，多少显得有点笨重。于是，我开始思考如何能够用一个简单直接的步骤识别嵌套实体，并与干系抽取任务优雅融合。
疫情期间，我每天苦思冥想，瞠目抖腿，抓耳挠腮，摇头晃脑，鬼哭狼嚎，差点以头抢地。最后，一拍大腿，嗨，不就是头和尾的区别。只要一个实体的头部 token 和尾部 token 被唯一确定，那它就可以与外部或者内部的其他实体区别开。那么如何确定头尾呢？我们要的不是多个标签，而是一个标签，因为多个标签难免要遇到配对的问题。那么，答案呼之欲出了，就是矩阵。矩阵中的一个点可以确定一对 token。一句话的所有嵌套实体都可以在一个矩阵中被一个点唯一标注，如下图所示：
▲ 嵌套实体标注示例
纵轴为头，横轴为尾，图中的两个红色 1 标签分别标注了（北，市）和（北，府），代表“北京市”和“北京市政府”为两个实体。
实体办理了，那么干系怎么办呢？那是一个下午，落日的余光洒在地板上显得格外刺眼，我看了一眼客厅的沙发，忽然想起了那天夕阳下的思考。一拍脑袋，邻接矩阵不就是用来表示节点干系的吗？实体干系可不可以也用两个 token 的干系来表示呢？答案又呼之欲出了。对，那就是 subject 和 object 的头部 token 以及尾部 token。例如：（周星驰，演员，喜剧之王）-> （周，演员，喜），（驰，演员，王）。
有些同学可能会疑惑为什么还要标尾部 token，头部 token 对的干系不就已经足够表达干系了吗？那是因为如果不确定尾部边界，仍然无缝办理嵌套问题。如前文例子中的“北京市”和“北京市政府”就是共享头部 token 的嵌套实体。
有些小伙伴可能已经看出来了，我们不知不觉就把 subject 和 object 在同一解码阶段确定了下来。于是，暴光偏向就不生存了。
三、标注规划
具体的标注规划如下图所示：
▲ 初始标注规划示例
其中紫色标签代表实体的头尾干系，红色标签代表 subject 和 object 的头部干系，蓝色标签代表 subject 和 object 的尾部干系。至于为什么用颜色区分，是因为这三种干系可能堆叠，所以三种标签是生存于不同矩阵的，这里为了便于阐述，才放在一起。
因为实体尾部不可能出现在头部之前，所以紫色标签是不可能出现在下三角区的，那么这样标就有点浪费资源。能不能不要下三角区？但要注意到，红标和蓝标是会出现在下面的。所以我们把红蓝标映射到上三角区对应位置，并标记为 2，然后弃了下三角区，如下图：
▲ 最终标注规划示例
四、模型
▲ 模型框架
模型结构比较简单，整个句子过一遍 encoder，然后将 token 两两拼接输入到一个全连接层，再激活一下输出作为 token 对的向量表示。最后对 token 对进行分类即可。换句话说，这其实就是一个较长序列的标注过程。
在上图的例子中，可以解码出 5 种干系：
(New York, mayor, De Blasio),
(De Blasio, born in, New York),
(De Blasio, born in, New York City),
(De Blasio, live in, New York),
(De Blasio, live in, New York City)
五、实验结果
截止到论文被接收，该模型在 NYT 和 WebNLG 两个干系抽取任务上都达到了当时的 SOTA 性能。
▲ exp_res1
六、未来的工作
这里主要提一下值得改进的地方：
论文中 token 对的向量表示采用的是直接拼接，这种简单的方式可能并不能展现出最佳的性能。实体和干系的识别使用的都是相同的向量表达，这可能会相互干扰。[4] 最新的两篇相关论文也指出了使用不同的特征去分别办理两个任务可能对性能有提升: A Frustratingly Easy Approach [4], Two are Better than One [5]。模型将原本长度为 N 的序列扩展成了O(N2)的序列，这无疑增加了开销，使得处理长文本变得比较昂贵。另外，矩阵的稀疏性和标签的极度不平衡对性能有一定的影响。
参考文献
[1] Extracting relational facts by an end-to-end neural model with copy mechanism: https://www.aclweb.org/anthology/P18-1047
[2] CopyMTL: Copy Mechanism for Joint Extraction of Entities and Relations with Multi-Task Learning: https://arxiv.org/abs/1911.10438
[3] A novel cascade binary tagging framework for relational triple extraction: https://arxiv.org/abs/1909.03227
[4] A Frustratingly Easy Approach for Joint Entity and Relation Extraction: https://arxiv.org/abs/2010.12812
[5] Two are Better than One: Joint Entity and Relation Extraction with Table-Sequence Encoders: https://arxiv.org/abs/2010.03851
