什么?!“路由器”也会做信息抽取了?
文 | 雨城
編 | QvQ
前幾周,一個“撞臉”路由器的聯合抽取模型TPLinker橫空出世,將NYT數據集的分數直接刷上了90,提高了2個百分點。賣萌屋邀請到作者雨城,來聊一聊他們在關系抽取上的工作。目前,該工作已經被COLING 2020接收。
背景
關系抽取 是從非結構化文本中抽取實體和關系的文本處理技術,屬于自然語言處理中的常見任務。它是自然語言理解的基礎,在智能問答、信息檢索等領域有重要應用。簡單來說就是給定一段文本,要抽出其中的(subject, predicate, object)三元組。例如:
?{'text':?'《邪少兵王》是冰火未央寫的網絡小說連載于旗峰天下','relation_list':?[{'subject':?'邪少兵王',?'object':?'冰火未央',?'predicate':?'作者'},]}pipeline的方法一般先做實體識別,再對實體對進行關系分類。這類方法忽略了實體與關系之間的聯系,而且存在誤差累積的問題。
為了充分利用實體與關系的交互信息和依賴關系,聯合抽取的思路應運而生,即在一個模型中同時對實體和關系進行統一抽取。較早的聯合抽取方法,如NovelTagging,沒法解決關系重疊的問題。當一個或一對實體同時出現在多個關系時,單純的序列標注就不再管用了,例如:
| 單實體重疊 | 周星馳主演了《喜劇之王》和《大話西游》。 | (周星馳,演員,喜劇之王)(周星馳,演員,大話西游) |
| 實體對重疊 | 由周星馳導演并主演的《功夫》于近期上映。 | (周星馳,演員,功夫)(周星馳,導演,功夫) |
后來提出的一些方法已經可以解決重疊問題,如CopyRE 、CopyMTL、CasRel(HBT)等,但它們在訓練和推理階段的不一致性導致存在曝光偏差。即在訓練階段,使用了golden truth作為已知信息對訓練過程進行引導,而在推理階段只能依賴于預測結果。這導致中間步驟的輸入信息來源于兩個不同的分布,對性能有一定的影響。
雖然這些方法都是在一個模型中對實體和關系進行了聯合抽取,但從某種意義上它們“退化”成了“pipeline”的方法,即在解碼階段需要分多步進行,這也是它們存在曝光偏差的本質原因。
本文提出了一種新的實體關系聯合抽取標注方案,可在一個模型中實現真正意義上的單階段聯合抽取,不存在曝光偏差,保證訓練和測試的一致性。并且同時可解決多關系重疊和多關系實體嵌套的問題。
論文題目:
《TPLinker: Single-stage Joint Extraction of Entities and Relations Through Token Pair Linking》
論文鏈接:
https://arxiv.org/abs/2010.13415
源碼鏈接:
github.com/131250208/TPlinker-joint-extraction
Arxiv訪問慢的小伙伴也可以在 【夕小瑤的賣萌屋】訂閱號后臺回復關鍵詞 【1110】 下載論文PDF~
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?City,?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!
未來的工作
這里主要提一下值得改進的地方:
論文中token對的向量表示采用的是直接拼接,這種簡單的方式可能并不能展現出最佳的性能。
實體和關系的識別使用的都是相同的向量表達,這可能會相互干擾。最新的兩篇相關論文也指出了使用不同的特征去分別解決兩個任務可能對性能有提升: A Frustratingly Easy Approach, Two are Better than One。
模型將原本長度為N的序列擴展成了O(N2)的序列,這無疑增加了開銷,使得處理長文本變得比較昂貴。
后臺回復關鍵詞【入群】
加入賣萌屋NLP/IR/Rec與求職討論群
有頂會審稿人、大廠研究員、知乎大V和妹紙
等你來撩哦~
?
[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
總結
以上是生活随笔為你收集整理的什么?!“路由器”也会做信息抽取了?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: FedNLP: 首个联邦学习赋能NLP的
- 下一篇: EdgeBERT:极限压缩,比ALBER