Facebook提出生成式实体链接、文档检索，大幅刷新SOTA！
文 | 花小花Posy
導言
最近ICLR的rebutal 前后分數對比出來了，很多評委都改了分數，有改多的，也有改少的。今天給大家介紹的這篇高分論文竟然在rebuttal前后都保持高分，證明評委們對它的認可程度是很高的。
實體檢索任務的定義是：對于一個給定的輸入文本，需要模型從一個候選實體集中找到最相關的候選實體。
比如說，給定輸入 : "In 1503, Leonardo began painting the Mona Lisa"，實體鏈接任務需要檢索出Leonardo指的是知識庫中的實體Leonardo da Vinci。
與之前研究不同的是，這篇文章是第一個用生成實體名稱的方式解決實體檢索問題的工作。咦？用生成模型做實體檢索？很新鮮嗎？跟以往有什么不同嘛？
那我們就在開始介紹正文前，先po下本文所提出的【生成式實體檢索】和傳統的【分類式實體檢索】核心的3點不同吧！
非常硬核的是，本文提出的模型GENRE在3類實體檢索任務，包括20個數據集上幾乎都達到了SOTA或者說非常competitive的結果。
論文題目：
AUTOREGRESSIVE ENTITY RETRIEVAL
論文鏈接:
https://openreview.net/pdf?id=5k8F6UU39V
Arxiv訪問慢的小伙伴也可以在 【夕小瑤的賣萌屋】訂閱號后臺回復關鍵詞 【1230】 下載論文PDF~
生成如何邂逅實體檢索？
實體檢索任務對于知識圖譜中的檢索，QA系統，推薦系統都十分重要。在以往的研究中，實體檢索任務遵循著一個定式：每個實體伴隨著一個唯一原子標簽，所以實體檢索任務被轉換為多分類任務。但是本文卻發現了一個新的范式：除了原子標簽外，Wikipedia文章標題，也可當做實體的唯一表示符, 被稱作實體名稱(Entity Name)。比如實體Tool的兩種標識符分別是：
原子標簽：4713實體名稱：Tool (band)
除唯一性外，實體名稱具有高結構性和組合性，而且在內容上可提供更詳細的信息。比如band就為Tool提供了額外的實體類型信息。
更重要的發現是，這些實體名稱與mention context存在可預測的匹配模式。
mention 指的是自然語言表示實體的文本片段, 比如"Leonardo"是一個mention，"Mona Lisa"也是一個mention。mention的context指的是mention的上下文， 比如上面例子中的"In 1503"和"began painting" 。
文中總結了六種實體名稱和mention+context的匹配類型：
舉個栗子趴：輸入 是下面的句子，高亮部分1是正確的實體名稱。
這個栗子屬于第2種類型，即實體名稱由context中的tokens組成，此處實體名稱是ōwhango railway station，由context中的token ōwhango 與 mention的字符串 railway station組成。
總體而言，這六種類型說明實體名稱和帶mention的input之間存在著固定形式的映射，因此對于一個mention+context或者輸入，是有可能采用生成的方式將其中的mention轉換為一個唯一的實體名稱的。
那么你能你會問, 實體檢索是需要從知識庫或者知識圖譜中檢索已經存在的實體吧，如果生成的實體并不存在知識圖譜中，該怎么辦呢？
這也是本文主要解決的一個問題（用非常機智的方式），先劇透下，核心idea是采用一種受約束的解碼策略，強迫每一個生成的實體屬于預先定義的候選集中。
本文最厲害的點就是對問題的重構，下面讓我們一起來看看作者是怎么用生成做實體檢索的吧！
如何生成實體名稱？
本文提出GENRE (Generative ENtity REtrieval，生成式實體檢索) 模型，生成一個給定輸入到實體名稱。具體是：對于輸入 , 要生成其對應的實體 ，并且 屬于知識庫中的候選實體集合 。 的實體名稱（文本）是一個文本序列 ：
GENRE采用sequence-to-sequence的框架進行生成，利用預訓練語言模型(BART[1]) 計算輸入與每個候選實體 的log-likelihood分數，然后按照分數取top-N個候選實體。從技術上講，GENRE通過fine-tune預訓練語言模型來生成實體名稱。
好了，模型介紹完了！
就這么簡單？？？不會吧？從模型來講確實是如此簡單呀。等等，不對呀！我們還有問題沒解決呢。我們需要生成的實體是有效的實體吧，換句話說生成的實體是來自知識庫KBs中的吧，不能夠隨意生成。確實如此，接下來我們一起看看是如何實現的吧！
如何保證生成的實體屬于KBs中呢？
GENRE在解碼時并沒有在WIkipedia的所有實體(~6M)進行搜索，而是采用了beam search, beams是10，所以只從top10個實體中進行選擇。在解碼時，傳統的方法允許每個位置可以是任何的token，所以無法保證生成的實體一定屬于 。為了保證生成的實體名稱一定屬于 ，所以本文采用了一種受約束的beam search來解決該問題。所謂的約束是通過前綴樹 （trie) 定義的，樹上的每一個節點是詞表中的一個token，節點的孩子表示所有可能的后續tokens。比如Enligh的后續tokens是language和literature，那么在解碼時如果當前詞是English, 那么就下一個token只能從language和literature中選擇。
文中關于模型的核心部分到這里就結束啦！下面我們看看文中測試GENRE的3類實體檢索任務吧！
生成式實體消歧、實體鏈接、文檔檢索
實體消歧：給定一個包含mention的輸入，需要生成mention所指代的是KB中的哪一個實體。
端到端實體鏈接：給定一個文檔，系統需要檢測其中的entity mentions，并將mentions鏈接到KB中相應的實體。比如輸入是 "In 1503, Leonardo began painting the Mona Lisa", 則需要模型檢測出其中的mention是 Leonardo和 Mona Lisa"，然后將其鏈接到KB中的實體Leonardo da Vinci和Mona Lisa。
頁面級別的文本檢索：給定一個包含輸入query，找到其所對應的Wikipedia的文章題目。比如輸入是“Which Florentine painter 1535-1607 used the name Bronzino after the death of his 'uncle'?"，輸出是文章題目名'Bronzino'。
在實體消歧和頁面級別的文本檢索上，直接將數據集中的輸入喂給語言模型就可以。但是生成式的端到端實體鏈接任務相對復雜，我們下面詳細介紹下。這也算是本文的另外一個貢獻，將GENRE框架進行了擴展，并用于生成式端到端的實體鏈接。
生成式的端到端實體鏈接
為了能夠同時檢測和鏈接實體，訓練時encoder的輸入是文本序列，decoder的輸入 是在 基礎上標注了mention和實體鏈接信息，從而監督模型的生成這兩部分信息。比如：
encoder輸入: In 1503, Leonardo began painting the Mona Lisa.?
decoder輸入 : In 1503, [Leonardo](Leonardo da Vinci) began painting the [Mona Lisa](Mona Lisa)。
可以看到，decoder輸入中mention被 [] 標注，且mention對應在KB中的實體被 () 標注。
因為mention是free-form的文本，如果定義所有mentions的前綴樹trie的話，則搜索空間會非常的大。那要怎么辦呢？為解決該問題，文中采用了動態解碼的方式，將解碼分為3個階段，mention的生成，entity的生成，其余tokens的生成。具體來講：
metion的生成: 由 "[" 激活---->從輸入 中復制mention span ----> 生成 "]" 結束。ps: 因為mention span的生成是直接從復制的，所以就不需要去進行大量的空間搜索啦~
entity的生成：由 "]" 激活 ----> 利用entities trie生成有效entity ----> 生成 ")" 結束。
其余tokens的生成: 直接從中復制就好。
可結合下圖中例子加深理解哦：
講了這么多，GENRE的實驗效果如何呢？用實體名稱真的比用實體ID要強很多嘛？我們一起來看一看吧~
Q1: 實體名稱的生成到底靠譜不靠譜？
文中在6個實體消歧數據集上進行了評估，GENRE在實體消歧上的整體性能提升較小，Micro F1比之前SOTA高出了0.8。（小花就不放表格了，省的看得心累）
在8個實體鏈接數據集上的整體Micro F1比之前SOTA高出了1.8。
上圖可以看出其實GENRE的很大程度上依賴于 Der和K50兩個數據集，別的數據集上其實并沒有太大的提升。
這篇文章，最吸引人的是它在頁面級別的文本檢索任務上的實驗結果，杠杠滴！GENRE在的所有數據集上幾乎都取得了SOTA，整體的R-Precision比之前模型高出了13.7！！！（哇塞???? ）
上圖給出了論文在頁面級別文檔檢索上的實驗結果，具體來講：
GENRE最大的提升來自于Slot Filling任務，在兩個數據集分別提升了19.8和17個點。
RAG和DPR+BERT都是在單個任務上分別訓練的，因此可以在單個數據集上進行調優。但是GENRE只需要訓練一個模型，就可以應用到所有任務，而且效果甚好。
DPR和BLINK+flair并沒有在KILT數據集上進行訓練，為了公平比較，作者在附錄中提供了GENRE只在DPR和BLINK數據集上訓練的結果，作者正文說GENRE仍超過他們。(PS: 但是我仔細check了一下，發現只在DPR上訓練時GENRE確實比DPR分別高出11.6，但是只在BLINK數據集上訓練時，卻比BLINK+flair低了12.2）。(不要被騙了哦，~O(∩_∩)O~）
Q2: 實體名稱究竟比實體ID強多少？
接下來終于要到我們最好奇的問題啦：實體名稱到底比實體ID要好多少，能不能有一個更加直觀的對比呢？作者在實體消歧任務上對比了生成實體名稱和生成實體ID的區別:上圖對比了在3種不同匹配類型(mention和實體名稱)下，3種模型的效果區別，我們可以看出：
當mention和實體名稱完全匹配時，GENRE取得了非常高的Micro F1，而使用IDs則降低了20.6。
當部分匹配時，GENRE依舊碾壓ID，說明實體名稱確實是提供了有意義的信息的。這種情況下實體名稱的優勢是，實體名稱可以與mention的cotnext進行更多的細粒度交互，以幫助選擇正確的候選實體。
當完全不匹配時，使用實體名稱和ID的區別相對較小，這說明：1）GENRE是依賴于文本的，2)即使是生成數值信息，模型也是有一定的實體消歧能力的。
Q3: GENRE到底多省Memory?
摘要的一開頭就argue說，我們的模型極大的減少了memory，那"極大"是多大呢？上圖對比了GENRE和其它3個模型的區別，可以看出GENRE使用的memory比BLINK少了12倍，比DPR省了30倍！ 果然是極大的減少了memory，而且效果還如此好！
那么你可能會好奇，GENRE到底是怎么省下的memory呢？
那是因為GENRE只需要保存實體名稱的前綴樹就好(還記得我們前面的那顆English的樹不？），不需要保存實體向量。 其它的模型則需要為每一個實體保存一個稠密向量。比如保存Wikipedia大約6M的實體，每個實體的向量維度是1024，則需要將近24GB的memory。
Takeaway
在結束之前，我們再回顧下最開始圖中【分類式實體檢索】vs【生成式實體檢索】 的3點不同吧！
前人研究大多將實體檢索定義為多分類的問題，mention context和候選實體ID的得分通過點乘計算。這樣的做法有3點不足：
輸入和實體ID之間缺乏細粒度交互：因為實體ID無法提供實體的詳細信息。
需要占用大量的磁盤空間：因為需要存儲大規模知識圖譜的實體稠密向量。
需要使用負采樣：因為候選詞表太大，rank時無法對所有的候選實體計算，需要負采樣幫助訓練。
而本文將實體檢索問題重新定義為生成問題，給定輸入，生成其對應的實體名稱。那么自然地，本文的優勢和主要貢獻就在于：
支持輸入和實體之間的細粒度交互：實體名稱(文章title)提供更詳細的實體描述，使實體與mention context之間的編碼可以有更細粒度的交互。
減少了存儲空間：通過生成的方式加上使用前綴樹來做beam search，GENRE的memory只和詞表大小有關，而和實體的數量無關，從而減少了存儲空間。
不需要負采樣：因為exact softmax loss可以直接計算得到，所有的非golden的token都被當做負樣本了，所以不需要使用負采樣。
（呃????，不都總結了嘛，咋還這么多！）
那來個簡版的吧：本文最大的亮點是引入文章title來替代實體的ID，并將實體檢索問題重新定義為生成問題，“順手”在20個數據集上證明了它的有效性。
花小花的一點碎碎念
從技術上說，就是fine-tune預訓練語言模型來生成實體名稱，聽起來又是最近"老一套"的fine-tuning。但是本文十分巧妙的將預訓練語言模型用在了實體檢索任務上，對任務進行了重定義，這就比較好玩了。并且大量的實驗也證明了其有效性，這就使得它成為ICLR的評委們鐘愛它了（4個評分是：8/8/8/7）。
按照本文的套路的話，是不是分類模型都可以轉化為生成模型去做了？雖然本文是第一篇將生成應用到實體檢索任務，但其本質是如何將一個分類任務轉換為生成任務。這樣一想的話，其實NLP圈子里之前就已經有人這樣去做了。
《DO LANGUAGE MODELS HAVE COMMON SENSE?》[2] 將Winograd Schema Challenge的分類問題轉換為使用語言模型生成概率的問題。COMET[3]將知識圖譜中的三元組分類任務轉化為生成任務：給定首實體和關系，生成尾實體。(小花忽然想到之前COMET的一個"缺點"是會生成不在知識圖譜中的實體，如果想讓它生成的實體都在知識圖譜中的話，可以利用本文用的前綴樹呀！）
將分類任務轉換為生成任務其中一個核心點是如何挖掘可用的文本信息，比如本文中利用文章的title替代數值ID，比如挖掘句子模板將知識圖譜中的關系三元組轉化為純文本的句子。另外在不同的domain會遇到不同的問題，比如本文中面臨的問題就是，如何保證生成的是有效實體。
不碎碎念啦，下面可以跳過...
來小屋有一小陣啦，這也算是第一篇正兒八經寫的文，希望有講清楚哦！終于在小夕姐姐的幫助下確定了筆名“花小花Posy"！??ヽ(°▽°)ノ?，以后就這樣跟大家見面啦！
萌屋作者：花小花Posy
目前在墨爾本大學NLP組讀Ph.D.，主要感興趣方向包括常識問答，知識圖譜，低資源知識遷移。期待有生之年可見證機器真正理解常識的時刻! 知乎ID：花小花Posy
作品推薦：
1.我拿樂譜訓了個語言模型！
2.一句話超短摘要，速覽752篇EMNLP論文
后臺回復關鍵詞【入群】
加入賣萌屋NLP/IR/Rec與求職討論群
后臺回復關鍵詞【頂會】
獲取ACL、CIKM等各大頂會論文集！
?
[1]Bart: Denoising sequence-to-sequence pretraining for natural language generation, translation, and comprehension https://www.aclweb.org/anthology/2020.acl-main.703.pdf
[2]DO LANGUAGE MODELS HAVE COMMON SENSE? ?https://openreview.net/pdf?id=rkgfWh0qKX
[3]COMET: Commonsense Transformers for Automatic Knowledge Graph Construction https://arxiv.org/pdf/1906.05317.pdf
總結
以上是生活随笔為你收集整理的Facebook提出生成式实体链接、文档检索，大幅刷新SOTA！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ACL2020 | 基于Knowledg
- 下一篇： 你的 GNN，可能 99% 的参数都是冗