Haiyang Yu, et.al “Bridging Text and Knowledge with Multi-Prototype Embedding for Few-Shot Relational Triple Extraction”, COLING 2020
1 简介
这篇是第一个做小样本实体关系抽取的文章，方法就是 ProtoNet + TransE（用来表示关系的 prototype） + JULE（用他的思想做 prototype-aware regularization）。方法感觉还挺有意思，又跟我之前做表示学习的经历联系了起来。另外，这篇文章作为小样本实体关系抽取的 baseline，性能很差，有很大的提升空间，也是值得探索的。
2 方法
由三个部分组成：Instance Encoder 给句子编码，Hybrid Prototype 得到实体和关系分别的 prototype，Prototype-Aware Regularization 让句子离 prototype 近一些，prototype 之间远一些（总之，让 embedding 空间的特征表达能力更好）。下面分别描述。
哦对，在说模型之前，要先说一下文章里奇怪的划分 n-way 的方法。作者说，实体关系三元组的类别其实用实体类别就能区分了，因此 n-way 是每类有 n 句包含同一关系的句子，里面实体的类型具体都是什么，不管。因此文章中，头实体和尾实体的 prototype $head_{proto}$ $tail_{proto}$ 都是相对于关系的类别而言的，一类关系的头实体有一个 prototype，而不是按照实体的类别分的。这应该是实体识别成绩极差的原因——实体的 prototype 不是很 make sense。
当然，也可以换一种方式理解。一个关系的头尾实体，应该也就只有几种实体类别组合得到，于是这里实体的 prototype 也可以理解成这种组合之后集合的 prototype？但是这些集合是有交叉的，这真的能在某一个 embedding 空间找到互相独立的子空间结构吗？我觉得不行，这不合理。不过作者似乎觉得可以，因此作者后面加入 Prototype-Aware Regularization，让这些 prototype 更分散——我觉得这一步在原理上是不对的。
2.1 Instance Encoder
使用 Bert + CRF 序列标注。这里的标注不区分实体类别，只有 {B-Head, I-Head, B-Tail, I-Tail, O, X} 这些，只标注“是否为头尾实体”，文中说“X is any remaining fragments of tokens split by the tokenizer.”我没看懂。
2.2 Hybrid Prototypical Learning
CRF 解码得到句子 i 的 embedding 之后，从里面挑出头实体第一个 token 的 embedding 和尾实体第一个 token 的 embedding 来作为这句话头尾实体的 embedding。
那么这一类关系对应的头尾实体的 prototype 就用 Hatt-proto 的方法 attention 求和：$$head_{proto} = \frac{1}{|S_k|}\sum_{head_i\in S_k}\alpha_hhead_i \qquad tail_{proto} = \frac{1}{|S_k|}\sum_{tail_i\in S_k}\alpha_ttail_i$$ $$\alpha_h = \frac{\exp(e_{h_i})}{\sum_{m=1}^k\exp(e_{h_m})}\quad e_{h_i} = head_{proto}^TQ$$ $$\alpha_t = \frac{\exp(e_{t_j})}{\sum_{n=1}^k\exp(e_{t_n})}\quad e_{t_j} = tail_{proto}^TQ$$
具体我就略了。
关系的 prototype 真的很简单，由表示句子的 $sent_{proto}$ 和表示知识限制的 $kg_{proto}$ 拼成：$$relation_{proto} = [sent_{proto};kg_{proto}]$$
其中 $sent_{proto}$ 就是每一类样本的 [CLS] embedding 平均而成，$kg_{proto}$ 使用 TransE 的思想：$$kg_{proto} = |head_{proto} – tail_{proto}|W_r$$
2.3 Prototype-Aware Regularization
就是让 prototype 之间更远，support set 每个例子都和 prototype 更近，想法就类似我之前看过的 JULE 这篇文章。两者分别搞一个损失，加到总的损失里面。
3 实验与结果
作者说 models trained on more laborious tasks may achieve better performances than using the same configurations at both training and test stages. Therefore, we set N = 20 to construct the train- support sets for 5-way and 10-way tasks.
没看错，这里是 f1。entity 计算的时候要 span 完全正确，relation 计算时只要句子对应的 relation 类别正确就好，triple 就是我都要.jpg
- 实体抽取性能不行
- CRF、prototype-aware regularization、attention 都有用（用处从大到小排序）
4 总结与疑问
文章中说，relation 会隐含对于实体的限制，比如 Born in relation suggests that the type of head entity must be PERSON, and vice versa. 作者说使用 TransE 的 embedding 方法（文中叫 hybrid prototypical learning）就能 explicitly inject knowledge constraints。我感觉这里说的不太准确。
首先，作者这里实体的 prototype 只是相对于关系而言分类的、一组实体类别构成的一个集合的 prototype，所以这个例子在这篇文章中其实应该是 “head entity must be entities in the group which contains possible entities for this relation”。
我们知道，TransE 用求差表达关系，这只能限制这两个实体的相对位置。而例子里面的“head entity must be xx”相当于限制实体的绝对位置。文章后半部分的 prototype-aware regularization 倒才限制了 prototype 在 embedding 空间中的绝对位置。这两个 loss 让不同类远一些，同一类紧密一些，也就是要让不同 relation 的 entity 集合分开的更多一些。这里的 entity 集合就是用关系来指导建成的，所以可以说是把关系对实体的限制加了进来。那从这个角度想，好像作者这样划分实体的 prototype 也是有点道理哈。
不过，我们知道，对于关系抽取，实体信息很重要。这样划分实体 prototype，根本都没有包含实体的信息。这里需要思考。比如，在训练时能不能用 gold 实体信息在一个新的特征空间搞出每类实体的 prototype？甚至直接用实体类别名作为 meta information，弄出一些 prototype，让这些具体的实体类别的 prototype 为关系引导的实体 prototype 和关系 prototype 提供一些信息？至少，我觉得这篇文章的首要改进肯定是引入实体类别信息。
另外，他这个关系抽取的部分，我感觉基本上只是靠 $sent_{proto}$ 起作用，前面实体识别性能太差了，说不定 $kg_{proto}$ 完全是反向的干扰呢。
另外，明明 pipeline 方法能达到大约 0.7 * 0.9 的 f1，用这个 joint 方法 f1 只有 0.25… 这毕竟是 FSL joint 方法的第一篇，所以能发文章，如果要在 0.25 的基础上改进，是不是要超过 pipeline 方法才能发呢？我顿时又觉得这个方向没啥吸引力了…
5 TODO
Zhi-Xiu Ye and Zhen-Hua Ling. 2019. Multi-level matching and aggregation network for few-shot relation classification. ArXiv, abs/1906.06678.
Ningyu Zhang, Shumin Deng, Zhanlin Sun, Xi Chen, Wei Zhang, and Huajun Chen. 2018. Attention-based capsule networks with dynamic routing for relation extraction. arXiv preprint arXiv:1812.11321.