本文內(nèi)容整理自 PaperWeekly 和 biendata 在 B 站組織的直播回顧，點(diǎn)擊文末閱讀原文即可跳轉(zhuǎn)至 B 站收看本次分享完整視頻錄像，如需嘉賓課件，請?jiān)?PaperWeekly?公眾號回復(fù)關(guān)鍵詞課件下載獲取下載鏈接。

作者簡介：孟昱先， 香儂科技算法工程師，本科畢業(yè)于北京大學(xué)數(shù)學(xué)系，先后從事負(fù)責(zé)信息抽取、輿情分析等多項(xiàng)產(chǎn)品的研發(fā)工作。?以第一作者身份在 ACL、NeurlPS 等會議發(fā)表多篇文章。

本文將討論如何將命名體識別、指代消解、關(guān)系抽取、文本分類等 NLP 任務(wù)轉(zhuǎn)化為 MRC（機(jī)器閱讀理解）任務(wù)，利用 MRC 框架的 query 所蘊(yùn)含先驗(yàn)信息的優(yōu)勢，不但由此獲得效果上的顯著提高，還將賦予模型 Domain Adaptation、Zero-shot Learning 等多方面的能力。

讓我們先梳理一下 MRC 的基礎(chǔ)知識。

什么是MRC？

MRC 主要分為三個(gè)部分，分別是 context，query 和 answer。所謂 context 可以簡單理解為一段 passage，可以是一句話，也可以是一段話，也就是所謂的語境。query 或者 question 是一個(gè)提問。

我們要針對 context 去提出一個(gè)問題，根據(jù) question 和 context，去文中找到一個(gè) span，它可以是一個(gè)連續(xù)的字符串，從 start 為開始，以end為結(jié)束，將該字串作為這個(gè)問題的答案，這就是我們所說的 answer。

下面是一個(gè)簡單的例子，圖中的 context 是一個(gè)和降水相關(guān)的闡述，然后 question 就是對 passage 提出的問題， answer 就是從這個(gè) context 中畫出了 within a cloud 這一連續(xù)的 span 來作出回答。

MRC框架嘗試解決的NLP任務(wù)

了解了基本結(jié)構(gòu)后，讓我們來看看 MRC 框架可以解決那些類型的 NLP 任務(wù)：

• 第一個(gè)任務(wù)是 NER，即命名實(shí)體識別；

• 第二個(gè)是 Relation Extraction，即關(guān)系抽取；

• 第三個(gè)是 Text Classification，即文本分類；

• 第四個(gè)是 Co-reference Resolution ，即共指消解。

我們首先介紹一下這些任務(wù)都是什么，以及我們?nèi)绾螌⑺鼈冝D(zhuǎn)化為 QA 任務(wù)。

2.1 MRC框架解決NER任務(wù)

NER——命名實(shí)體識別任務(wù)。上圖是我們今年發(fā)表在 ACL 的一篇文章。NER 實(shí)際上就是在給定一段文章或一句話的情況下，識別出內(nèi)容中所有的命名實(shí)體，比如說地名或者是機(jī)構(gòu)名。那么在上圖中的 at the Chinese embassy in France 實(shí)際上就包含三個(gè)命名實(shí)體，其中 Chinese 和 France 是地名， the Chinese embassy in France 是一個(gè)機(jī)構(gòu)名。

那我們?nèi)绾螌⑦@個(gè) NER 的任務(wù)轉(zhuǎn)化為 QA 任務(wù)呢？參照上文所講的三要素 question, context, answer。首先context就是輸入的這句話。那么 query 是什么？

可以通過一個(gè)簡單方法來構(gòu)造，直接去問：which location is mentioned in the context？我們希望對于這一 query 和 context 組合，模型能夠幫我們抽取出 answer。answer 就是兩個(gè)連續(xù)的子串 Chinese 和 France。需要注意的是，query 的構(gòu)造方法還有很多種。

我們還嘗試過另一種方法，直接拿 NER 數(shù)據(jù)集的標(biāo)注規(guī)則，來作為我們的 query，比如說地名的 NER 的標(biāo)注規(guī)則，就是 find all geographical regions, ?such as … 這樣的話我們就能更貼切的讓模型知道什么樣的命名實(shí)體是一個(gè)地名。

2.2 MRC框架解決Relation Extraction任務(wù)

接著我們來看如何把 Relation Extraction 的任務(wù)轉(zhuǎn)換為 QA？上圖是我們發(fā)表在 ACL2019 上的一篇文章。Relation Extraction 一般來說可以分為兩個(gè)步驟，第一個(gè)步驟是先識別出來輸入 passage 的形態(tài)，比如說上圖 passage 中綠色標(biāo)記的就是時(shí)間、紅色的是人名、藍(lán)色的是公司名，以此類推。

第二個(gè)步驟是找出不同的 entity 之間的關(guān)系，比如說大家可以看下面這張表。

比如說 Musk 這個(gè)人，他在 2002 年擔(dān)任 SpaceX 這一公司 CEO。Relation Extraction 其實(shí)就是一個(gè)將非結(jié)構(gòu)化的文檔轉(zhuǎn)化為一個(gè)結(jié)構(gòu)化信息的過程，這個(gè)過程通常是通過先識別 entity，然后再識別 energy 之間的 relation 來完成的。

那我們?nèi)绾螌?Relation Extraction 這個(gè)任務(wù)轉(zhuǎn)化成 QA？第一步先抽取 person，構(gòu)造一個(gè) query 叫做 who is mentioned in the text？這樣的話我們希望模型會根據(jù)這個(gè) query 和 context 進(jìn)行回答，Musk 這個(gè)人出現(xiàn)在了結(jié)果中。

第二步我們會問 Musk 這個(gè)人 which company did Musk work for？這樣的話我們就能可以抽取出來 Musk 為哪些公司工作過。

第三步如果還想抽取他在這個(gè)公司擔(dān)任的職務(wù)，可以再繼續(xù)問 what was Musk’s position in SapceX？模型就會抽取出，他是在 SapceX 擔(dān)任 CEO。

那么類似的也可以抽出來時(shí)間 2002 年，然后我們就會得到一張表。這里有個(gè)問題，比如說 Musk 他既在 SpaceX 工作過，又在 Tesla 工作過，那應(yīng)該怎么去抽取？實(shí)際上閱讀理解的答案也可以是由多個(gè) span 來組成，可以借助 NER 的 BIO 的標(biāo)注方式，從一個(gè) passage 中去抽取多段答案，然后只需要對每一段做 QA，這樣就可以用多輪 QA 的形式來抽出完整的表格。

2.3 MRC框架解決Text Classification任務(wù)

接著看 Text Classification 轉(zhuǎn)化為 QA 任務(wù)的過程。這個(gè)任務(wù)相對簡單，可以直接把原始文本作為 context，query 可以是這個(gè)類別的一個(gè)描述。因?yàn)槭俏谋痉诸?#xff0c;answer 會跟別的 QA 任務(wù)不太一樣，實(shí)際上只需要回答是 yes 或者 no。

借助這個(gè)槽填充機(jī)制，可以比較簡單的實(shí)現(xiàn)任務(wù)轉(zhuǎn)化。我們還嘗試了一些其他的工作，提出使用不同的 query 生成方式。通常我們會使用如上圖左邊 template description 這樣一種方法，也就是給出一個(gè)模板。我們還嘗試了兩種其他的方式，Extractive Description 和 Abstractive Description，這部分后文會詳細(xì)講到。

2.4 MRC框架解決Co-reference Resolution任務(wù)

最后一個(gè)任務(wù)來看 Co-reference，Co-reference 比較有意思，任務(wù)目的是識別一段話中指代同一個(gè)實(shí)體的不同描述，比如說上圖這段話中 Jingle Bells。還有下圖中的 the song 實(shí)際上就是在指代同一個(gè)東西。任務(wù)就是要把這段話中所有可能指代同一個(gè)物體的描述全都抽出來，并做出聚類。

context 是原本的輸入，query 是抽取和 Jingle Bells 所指相同的詞。我們的做法是，構(gòu)造一個(gè) query It was just “” Jingle Bells “”，這里的 mention 是一個(gè) special token，其實(shí)是什么都可以。

然后再匹配前面的 it was just，在原文中出現(xiàn)的 context 作為一個(gè)簡短的 query 來提問。我們期望得到的 answer 就是 the song，這樣的話我們就完成了 Co-reference 任務(wù)到 QA 任務(wù)的轉(zhuǎn)換。

如果沒有答案 answer 就直接是 None 就可以了。

不同NLP任務(wù)轉(zhuǎn)化為MRC的優(yōu)勢

上文轉(zhuǎn)換的多個(gè)任務(wù)中，主要的工作都是在構(gòu)造 query。Context 通常來講就是任務(wù)本來的輸入，核心目標(biāo)就是構(gòu)建 query 或 questions。

和將 context 推給模型來學(xué)習(xí)相比，為什么構(gòu)建 questions 的效果要更好呢？原因在于 questions 是 encode 了一些先驗(yàn)知識的，可以更明確的告訴模型哪些信息或 token 要被注意到，看做一種 hard version of attention。

還是拿 NER 任務(wù)來舉例，比如說 context 是 at the Chinese embassy in France，如果標(biāo)注方式是 annotation guidelines，那么就會提到 geographical regions。

在 Bert 的頭注意力機(jī)制中，government 這些詞如果做可視化的話會被著重強(qiáng)調(diào)的。在這種情況下如果構(gòu)造一個(gè)比較好的 query，在數(shù)據(jù)量很少的情況下也可以抽出高質(zhì)量的結(jié)果。

還有 Domain adaptation 和 Few shot learning 兩個(gè)優(yōu)勢，這兩個(gè)優(yōu)勢都是由第一個(gè)優(yōu)勢引申過來的。我們在前文和 NER 相關(guān)的那篇文章實(shí)驗(yàn)中發(fā)現(xiàn)，在 question 先驗(yàn)知識的幫助下，只需要使用大概占原本數(shù)據(jù)集一半左右的數(shù)據(jù)量就可以達(dá)到原本直接用 encoder 來做的效果。

除此之外，我們認(rèn)為還有一個(gè)非常大的優(yōu)勢，就是它的 flexibility，即靈活性。對于靈活性，下面會通過具體分析上述的任務(wù)來做逐一解釋。

3.1 NER任務(wù)在MRC框架下的優(yōu)勢

和前衛(wèi)的順序一致，先看 NER 問題下 MRC 框架的優(yōu)勢。

目前主流 NER 任務(wù)的大數(shù)據(jù)集主要都解決的是 flat NER，每一個(gè)字可能都只屬于一個(gè) entity，但實(shí)際上在現(xiàn)實(shí)生活中經(jīng)常不是這樣，比如說中國人民解放軍，其中的中國這兩個(gè)字就是一個(gè)國家，但中國人民解放軍可能又是一個(gè)組織，同樣的在上圖這兩個(gè)例子中，蛋白和 DNA 或者說國家和機(jī)構(gòu)其實(shí)都是會有重疊的。

熟悉 NER 同學(xué)都知道常規(guī)解決手段比如 Sequence labeling，會后面加一個(gè) CRF，但這樣做很難解決 NER 之間 overlap 的情況。

而對 MRC 來說這就是非常簡單的一個(gè)問題，因?yàn)槲覀兊?query 構(gòu)造先天的避免了問題，對每一類的 entity 都會問一個(gè)不同的問題，比如說對于圖中的第二句話，我們就可以先問：這句話里出現(xiàn)了哪些地名？

然后 MRC 會告訴我們有 Chinese、France，接著問這句話里又出現(xiàn)了哪些機(jī)構(gòu)名，它會告訴我們是 the Chinese embassy in France，可以看到嵌套命名實(shí)體的情況對于 MRC 框架來說就根本不是一個(gè)問題。

上圖是在 Nested NER 數(shù)據(jù)集上實(shí)驗(yàn)的結(jié)果，大家會發(fā)現(xiàn)我們的優(yōu)點(diǎn)非常明顯，相比于 Flat NER 領(lǐng)先優(yōu)勢是一個(gè)點(diǎn)左右。Nested NER 突破了之前一些方法的瓶頸，所以相應(yīng)的提升會非常的明顯。

3.2 Relation Extraction任務(wù)在MRC框架下的優(yōu)勢

接下來看 relation extraction。一般的方法是，首先提取不同類型的 entities，比如說人名、公司名、時(shí)間等等。第二步就是去構(gòu)造 entity 之間的關(guān)系，比如說這個(gè) Musk 跟 SpaceX 就是 work at 這樣的一種 relation。

這樣操作的問題是很難去解決 hierarchies 的問題，還是看上圖簡單的例子， Musk 可以在不同的公司工作，在一家公司也有可能擔(dān)任多個(gè)職務(wù)，單純的通過 two stages 的方法是解決不了問題的。

那么在 MRC 的框架下，這樣的問題就會迎刃而解，這一切都可以通過多輪問答的形式來解決。上圖是在 relation extraction data 上的實(shí)驗(yàn)結(jié)果。

3.3 Coreference Resolution任務(wù)在MRC框架下的優(yōu)勢

接下來我們講一下 Coreference Resolution 這個(gè)任務(wù)。我們常規(guī)的做法也是分兩步執(zhí)行。第一步是抽取出 mention 指代的 proposal，也就是我認(rèn)為這一段文字或者說在指代某一樣?xùn)|西。

第二步常規(guī)的做法是說對 Mention 之間做一些 linking，比如說這里的 my cat 和 the cat，實(shí)際上指代的是同一個(gè)東西，那么我們希望模型判斷出來它們指代同一個(gè)東西。這里的 my cat 和 Jingle Bells 指代的不是一個(gè)東西，相應(yīng)的我們希望模型去判斷它們不是一個(gè)東西。

這種方法的問題是如果第一步抽取了一些 mention proposal，就會丟失了 mention，到了 mention linking 這一步實(shí)際上就不太可能再把它找回來。那我們 MRC 的這個(gè)框架是怎么解決這個(gè)問題呢？

我們在第一步中可以只抽出 Jingle Bell 這一個(gè)可能的 mention，在第二步，也就是 QA 的這個(gè)步驟，其實(shí)就完全可以通過 QA 的形式把 the song 給找出來，即便 the song 開始并沒有被我們抽成一個(gè) mention proposal。

大家看上面這張實(shí)驗(yàn)里的圖也可以很明顯的發(fā)現(xiàn)我們的 recall 比之前的 SOTA 都要高很多，尤其是在當(dāng)控制了 mention proposal 的數(shù)量的情況下。

3.4 Text Classification任務(wù)在MRC框架下的優(yōu)勢

接下來我們看 text classification 任務(wù)。常規(guī)的方法非常簡單，把這段話輸入一個(gè)模型，得到輸出預(yù)測，直接去拿最終的 representation 來計(jì)算分布。

但實(shí)際上有時(shí)候我們的需求會更加的復(fù)雜，比如說有一個(gè)常見的分類是 aspect sentiment classification。

正常的 sentiment classification 直接去分這句話或者這段話的感情是正面還是負(fù)面，但 aspect sentiment classification 就是要求你去區(qū)分不同的 aspect。

比如 clean updated room 就是說衛(wèi)生環(huán)境很好，friendly efficient staff 可能是說它的服務(wù)很好，rate was too high 可能會說它的價(jià)格不太好，所以它這一段話可能有一部分是某些 aspect 的正面，然后另外一部分又是某些aspect的負(fù)面。

對于一個(gè) encoder 來說，他能夠?qū)W到關(guān)于不同 aspect 以及不同 aspect 的正負(fù)的表示，實(shí)際上都是集中在了最后一層 fully connected layer。最后一層才學(xué)這個(gè)特征，實(shí)際上對于一個(gè)網(wǎng)絡(luò)來說是非常不友好的，實(shí)際上沒有很好的去監(jiān)督他學(xué)習(xí)這個(gè)特征。

那在 MRC 的這個(gè)任務(wù)里，我們其實(shí)通過 description 避開這個(gè)問題。

比如說如果我們要抽取這段話，關(guān)于這個(gè)價(jià)格的情感極性，那么我們就可以去構(gòu)造一個(gè) query 叫做 positive price。那這樣的話 price 和 rate 這種詞就會通過 BERT attention 連接在一起。

所以在這種 hard attention 的情況下，就會非常容易的去預(yù)測每一個(gè) aspect 的類別。

然后接下來詳細(xì)介紹在不同 query 構(gòu)造方法上的探索。本文一共嘗試了三種 query 構(gòu)造方法。

第一種是 template-based，基于模板的方法，正如上文提到的 positive price，就是基于 template 的 query。

之后還有 extractive-based 和 abstractive-based 兩種構(gòu)造方法。extractive-based description 是針對每個(gè) context 都找到與當(dāng)前 context 相關(guān)的 query，然后輸入模型當(dāng)中，在此作為先驗(yàn)知識去幫助模型分類。

比如，要確定這段話是不是在描述車輛相關(guān)的主題， template-based的 description 可以復(fù)述 Wiki 百科上的描述：什么是一輛車？然后把這句話作為 query 輸入模型中。

第二種 query 構(gòu)造方法是 extractive-based 的 description, 該方法對于一段話去抽取一個(gè)連續(xù)的 span 作為可能的 query。

第三種 query 構(gòu)造方法是是 abstractive-based 的 description，利用 Seq2Seq 的模型令 context 去生成一段 description。

后兩種 query 構(gòu)造方法是怎樣的呢？在本文中利用的是強(qiáng)化學(xué)習(xí)的方法，強(qiáng)化學(xué)習(xí)有三個(gè)要素，action，policy，reward。

對于 extractive based 的 query 構(gòu)造方法， action 在本文中實(shí)際指從書中文本中選取一個(gè)文章的 span， policy 在本文中實(shí)際是指要根據(jù)這個(gè)文本判斷這個(gè) span 的起始位置和終點(diǎn)位置，reward 是指當(dāng)把 span 作為我們的 query 之后，整個(gè) QA 模型能夠輸出正確標(biāo)簽的概率，之后可以根據(jù)這個(gè) reward 去做 reinforcement learning。

對于 abstractive based 的構(gòu)造方法，原理也十分類似，區(qū)別在于 action 從原文的 span 變成了直接 Seq2Seq 生成的一個(gè)過程，policy 從原文中選取 span 變成了在此表中選取的過程。Reward 與 extractive based 的方法是一樣的。

實(shí)驗(yàn)結(jié)果如圖所示。從實(shí)驗(yàn)結(jié)果中看出，在文章比較長，比較難分類的情況下，QA 框架下表現(xiàn)很好，這是因?yàn)樵谖恼螺^長的情況下，分類的 attention 機(jī)制實(shí)際上很難去學(xué)習(xí)要重視哪些詞，然后忽略哪些詞，如果加上 query 的先驗(yàn)信息之后，就會比較好地對文章做分類。

生成query的方法

這里總結(jié)一下有哪些生成 query 的方法。第一類方法是 handcrafted rules，正如在做 NER 使用的標(biāo)注的 guideline，或者是文本分類使用的 Wiki 的定義。第二類方法在文本分類中對不同的 text 或者 context 生成不同的 queries，然后用強(qiáng)化學(xué)習(xí)的方法進(jìn)行優(yōu)化。

除了上述介紹的 MRC 的優(yōu)點(diǎn)，由 flexibility 可以引出 MRC 的一個(gè)最后的優(yōu)點(diǎn)。

各種任務(wù)其實(shí)都可以轉(zhuǎn)化為 MRC 的框架，然后再在 MRC 框架下去設(shè)計(jì)一個(gè)大一統(tǒng)的模型來解決問題。Google 的 T5 和這個(gè)十分類似，他們主要做 language model、Masked language model 相關(guān)的訓(xùn)練。但如果把所有的任務(wù)都轉(zhuǎn)化為 MRC 框架下的任務(wù)，可以利用 multitask 的訓(xùn)練方法。

關(guān)于數(shù)據(jù)實(shí)戰(zhàn)派

數(shù)據(jù)實(shí)戰(zhàn)派希望用真實(shí)數(shù)據(jù)和行業(yè)實(shí)戰(zhàn)案例，幫助讀者提升業(yè)務(wù)能力，共建有趣的大數(shù)據(jù)社區(qū)。

更多閱讀

#投 稿?通 道#

?讓你的論文被更多人看到?

如何才能讓更多的優(yōu)質(zhì)內(nèi)容以更短路徑到達(dá)讀者群體，縮短讀者尋找優(yōu)質(zhì)內(nèi)容的成本呢？答案就是：你不認(rèn)識的人。

總有一些你不認(rèn)識的人，知道你想知道的東西。PaperWeekly 或許可以成為一座橋梁，促使不同背景、不同方向的學(xué)者和學(xué)術(shù)靈感相互碰撞，迸發(fā)出更多的可能性。?

PaperWeekly 鼓勵(lì)高校實(shí)驗(yàn)室或個(gè)人，在我們的平臺上分享各類優(yōu)質(zhì)內(nèi)容，可以是最新論文解讀，也可以是學(xué)習(xí)心得或技術(shù)干貨。我們的目的只有一個(gè)，讓知識真正流動起來。

?????來稿標(biāo)準(zhǔn)：

? 稿件確系個(gè)人原創(chuàng)作品，來稿需注明作者個(gè)人信息（姓名+學(xué)校/工作單位+學(xué)歷/職位+研究方向）?

? 如果文章并非首發(fā)，請?jiān)谕陡鍟r(shí)提醒并附上所有已發(fā)布鏈接?

? PaperWeekly 默認(rèn)每篇文章都是首發(fā)，均會添加“原創(chuàng)”標(biāo)志

?????投稿郵箱：

? 投稿郵箱：hr@paperweekly.site?

? 所有文章配圖，請單獨(dú)在附件中發(fā)送?

? 請留下即時(shí)聯(lián)系方式（微信或手機(jī)），以便我們在編輯發(fā)布時(shí)和作者溝通

????

現(xiàn)在，在「知乎」也能找到我們了

進(jìn)入知乎首頁搜索「PaperWeekly」

點(diǎn)擊「關(guān)注」訂閱我們的專欄吧

關(guān)于PaperWeekly

PaperWeekly 是一個(gè)推薦、解讀、討論、報(bào)道人工智能前沿論文成果的學(xué)術(shù)平臺。如果你研究或從事 AI 領(lǐng)域，歡迎在公眾號后臺點(diǎn)擊「交流群」，小助手將把你帶入 PaperWeekly 的交流群里。

總結(jié)

以上是生活随笔為你收集整理的详解如何充分发挥先验信息优势，用MRC框架解决各类NLP任务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。