【实体关系抽取】OneRel和TPLinker两篇方案的不同之处

0 引言

过去的实体关系抽取方案，基本上都是分步进行：先抽取实体，再抽取关系。结合工业实践，我认为过去的做法好处有如下：

• 解释性强。我可以将实体和关系模型分别调整到最优，而且实体是先设置有类型的，debug极其方便；
• 易扩展。

缺点就不多说了，论文说的很明确——曝光偏差带来的错误积累 和 级联误差。目前我自己在工业上采用的prompt范式的方法（uie模型）会出现一个很大的缺点——随着实体类型和关系类型的增加，推理时间也会随之增加。 因此希望能寻找更快的方法。

1 不同之处

乍一看，这两篇论文的方法很类似，但是我通过细读发现，其实是有很多不同之处，而且这些地方的设计也是非常有针对性。
但首先可以明确的是，这两篇论文的思想或者说架构是一样的。它们的不同主要有以下几点：

• 全连接层的设计 之 $标记$。tag的设计是很不同的，OneRel直接将头尾两个实体的开始和结束对齐，TPLinker是从单个实体范围的标记到链接的标记。前者比后者简洁。
  

• 全连接层的设计 之 $并行$。OneRel的并行是在公式上就设计好了，TPLinker设计的公式上仅仅是针对一种关系，没有在公式上体现并行。但是我觉得TPLinker完全可以进行并行，但是OneRel的作者在实验的时候似乎没有将TPLinker进行并行化处理，我觉得这里有一一点点不太公平。 下图是OneRel的关系嵌入表示。
  

• 全连接层的设计 之 $复杂度$。一开始我注意到OneRel模型的推理时间更长，我就马上明白了WebNLG数据集的关系种类肯定更多，果不其然，WebNLG的关系种类是NYT的近十倍，但是我觉得差距应该更大，除非做了什么不可告人的优化。原因是：OneRel全连接层计算的是关系与实体向量之间的评分来决定标签类型；TPLinker则是直接选出某个标签。也就是说，尽管OneRels使用relu激活，速度比tanh要快，但由于关系会参与前向计算，所以关系的数量决定了OneRel的运算次数。

• 参数量。OneRel没有提及参数量，但是TPLinker提及并比较了，前者的参数量是要更多的，因为后者在稀疏矩阵的存储上还做了优化，但是OneRel对标记的改进导致其不需要且也无法做类似的优化。
  

2 总结

总体来看，如果真的像OneRel实验部分所表述的那样，那么OneRel是非常有价值的一次探索，它从图嵌入技术中得到启发，改变了边和关系的交互方法，理应效果好一些。但是想使用到工业上的话，还有很长的一段路要走。