關係重疊?實體巢狀?曝光偏差?這個模型統統都搞得定!

PaperWeekly發表於2020-11-17

本文提出了一種新的實體關係聯合抽取標註方案,可在一個模型中實現真正意義上的單階段聯合抽取,不存在曝光偏差,並且同時可解決多關係重疊多關係實體巢狀的問題。

閱讀本文大約需要 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

六、未來的工作

這裡主要提一下值得改進的地方:

  1. 論文中 token 對的向量表示採用的是直接拼接,這種簡單的方式可能並不能展現出最佳的效能。
  2. 實體和關係的識別使用的都是相同的向量表達,這可能會相互干擾。[4] 最新的兩篇相關論文也指出了使用不同的特徵去分別解決兩個任務可能對效能有提升: A Frustratingly Easy Approach [4], Two are Better than One [5]。
  3. 模型將原本長度為 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

相關文章