最近幾個月，在主業做推薦演算法之外的時間，我其實一直比較好奇下面兩個問題：
問題一：Bert 原始的論文證明了：在 GLUE 這種綜合的 NLP 資料集合下，Bert 預訓練對幾乎所有型別的 NLP 任務（生成模型除外）都有明顯促進作用。但是，畢竟 GLUE 的各種任務有一定比例的資料集合規模偏小，領域也還是相對有限，在更多領域、更大規模的資料情況下，是否真的像 Bert 原始論文裡的實驗展示的那樣，預訓練技術對於很多應用領域有了很大的促進作用？如果有，作用有多大？這種作用的大小與領域相關嗎？這是我關心的第一個問題。
問題二：Bert 作為一項新技術，肯定還有很多不成熟或者需要改進的地方，那麼，Bert 目前面臨的問題是什麼？後面有哪些值得改進的方向？這是我關心的第二個問題。
陸陸續續地，我收集到了截止到 19 年 5 月底為止發表的，大約 70-80 篇與 Bert 相關的工作，剛開始我是準備把關於這兩個問題的答案寫在一篇文章裡的，寫著寫著發現太長，而兩個主題確實也可以獨立分開，所以就改成了兩篇。
這一篇是回答第一個問題的，主題集中在各個 NLP 領域的 Bert 應用，一般這種應用不涉及對 Bert 本身能力的改進，就是單純的應用併發揮 Bert 預訓練模型的能力，相對比較簡單；至於對 Bert 本身能力的增強或者改進，技術性會更強些，我歸納了大約 10 個 Bert 的未來改進方向，放在第二篇文章裡，過陣子會把第二篇再改改發出來，在那篇內容裡，會歸納梳理 Bert 未來可能的發展方向。
這兩篇文章對讀者的知識結構有一定要求，建議在看之前，先熟悉下 Bert 的工作機制，可以參考我之前介紹 Bert 的文章：
https://zhuanlan.zhihu.com/p/49271699
本篇文章主要回答第一個問題，除此外，從應用的角度看，Bert 比較擅長處理具備什麼特性的任務？不擅長處理哪些型別的應用？哪些 NLP 應用領域是 Bert 擅長但是還未開墾的處女地？Bert 的出現對 NLP 各個領域的傳統技術會造成怎樣的衝擊？未來會形成統一的技術方案嗎？包括 Bert 時代我們應該如何創新？…….. 這些問題也會有所涉及，並給出我個人的看法。
在回答這些問題之前，我先講講我對 Bert 的一些務虛的看法，原先的內容本來在本文的這個位置，因為太長，之前已經摘出單獨發了，如果感興趣的話，可以參考下文：
https://zhuanlan.zhihu.com/p/65470719
百花齊放：Bert 在 NLP 各領域的應用進展
自從 Bert 誕生，到目前轉眼半年過去了，如果歸納一下，目前出現了大量使用 Bert 來在 NLP 各個領域進行直接應用的工作，方法都很簡單直接，效果總體而言比較好，當然也需要分具體的領域，不同領域受益於 Bert 的程度不太相同。
本節對這些工作分領域介紹及做一些帶我個人主觀色彩的判斷和分析。
應用領域：Question Answer (QA，問答系統) 與閱讀理解
QA 中文一般叫做問答系統，是 NLP 的一個重要應用領域，也是個具有很長曆史的子領域了，我記得我讀書的時候，差一點就選了這個方向做博士開題方向…… 好險…… 當時的技術發展水準，我記得是各種 trick 齊飛，靠譜共不靠譜技術一色….. 當然，其實我最終還是選擇了一個更糟糕的博士開題方向 ……. 這應該是墨菲定律的一個具體例子？「選擇大於努力」，這個金句，一直被證明，從未被顛覆。在讀博士們請留心下這句肺腑之言，一定選好開題方向。當然，有時候能夠選什麼方向也由不得你，上面是說在你有選擇自由的時候需要注意的地方。
QA 的核心問題是：給定使用者的自然語言查詢問句 Q，比如問「美國曆史上最像 2B 鉛筆的總統是誰？」，希望系統從大量候選文件裡面找到一個語言片段，這個語言片段能夠正確回答使用者提出的問題，最好是能夠直接把答案 A 返回給使用者，比如上面問題的正確答案：「特 · 不靠譜 · 間歇腦抽風 · 朗普」。
很明顯，這是個很有實用價值的方向，其實搜尋引擎的未來，很可能就是 QA + 閱讀理解，機器學會閱讀理解，理解了每篇文章，然後對於使用者的問題，直接返回答案。
QA 領域是目前 Bert 應用效果最好的領域之一，甚至有可能把「之一」都能拿掉。我個人認為，可能的原因是 QA 問題比較純粹。所謂的「純粹」，是說這是個比較純粹的自然語言或者語義問題，所需要的答案就在文字內容裡，頂多還需要一些知識圖譜，所以只要 NLP 技術有提升，這種領域就會直接受益。當然，可能也跟 QA 問題的表現形式正好比較吻合 Bert 的優勢有關。那麼 Bert 特別適合解決怎樣的問題？在本文後面專門會分析這個事情。
目前不同的在 QA 領域利用 Bert 的技術方案大同小異，一般遵循如下流程：
QA 應用 Bert，從流程角度，一般分為兩個階段：檢索 + QA 問答判斷。首先往往會把比較長的文件切割成段落或者句子 n-gram 構成的語言片段，這些片段俗稱 Passage，然後利用搜尋裡的倒排索引建立快速查詢機制。
第一個階段是檢索階段，這個和常規的搜尋過程相同，一般是使用 BM25 模型（或者 BM25+RM3 等技術）根據問句查詢可能的答案所在候選段落或者句子；第二個階段是問答判斷。
在訓練模型的時候，一般使用 SQuAD 等比較大的問答資料集合，或者手上的任務資料，對 Bert 模型進行 Fine-tuning；在應用階段，對於第一階段返回的得分靠前的 Top K 候選 Passage，將使用者問句和候選 passage 作為 Bert 的輸入，Bert 做個分類，指出當前的 Passage 是否包括問句的正確答案，或者輸出答案的起始終止位置。這是一個比較通用的利用 Bert 最佳化 QA 問題的解決思路，不同方案大同小異，可能不同點僅僅在於 Fine-tuning 使用的資料集合不同。
QA 和閱讀理解，在應用 Bert 的時候，在某種程度上是基本類似的任務，如果你簡化理解的話，其實可以把上述 QA 流程的第一階段扔掉，只保留第二階段，就是閱讀理解任務應用 Bert 的過程。
當然，上面是簡化地理解，就任務本身來說，其實兩者有很大的共性，但是也有些細微的區別；一般普通 QA 問題在找答案的時候，依賴的上下文更短小，參考的資訊更區域性一些，答案更表面化一些；
而閱讀理解任務，要正確定位答案，所參考的上下文範圍可能會更長一些，部分高難度的閱讀理解問題可能需要機器進行適當程度的推理。總體感覺是閱讀理解像是平常 QA 任務的難度加大版本任務。但是從 Bert 應用角度，兩者流程近似，所以我直接把這兩個任務並在一起了。我知道，上面的話估計會有爭議，不過這個純屬個人看法，謹慎參考。
前面提過，QA 領域可能是應用 Bert 最成功的一個應用領域，很多研究都證明了：應用 Bert 的預訓練模型後，往往任務都有大幅度的提升。下面列出一些具體例項。
而閱讀理解任務，應用 Bert 後，對原先的各種紛繁複雜的技術也有巨大的衝擊作用，前幾年，我個人覺得儘管閱讀理解領域提出了很多新技術，但是方法過於複雜了，而且有越來越複雜化的趨向，這絕對不是一個正常的或者說好的技術發展路線，我覺得路子有可能走歪了，而且我個人一直對過於複雜的技術有心理排斥感，也許是我智商有限理解不了複雜技術背後的深奧玄機？
不論什麼原因，反正就沒再跟進這個方向，當然，方向是個好方向。而 Bert 的出現，相信會讓這個領域的技術迴歸本質，模型簡化這一點會做得更徹底，也許現在還沒有，但是我相信將來一定會，閱讀理解的技術方案應該是個簡潔統一的模式。至於在閱讀理解裡面應用 Bert 的效果，你去看 SQuAD 競賽排行榜，排在前列的都是 Bert 模型，基本閱讀理解領域已經被 Bert 屠榜了，由這個也可以看出 Bert 在閱讀理解領域的巨大影響力。
應用領域：搜尋與資訊檢索（IR）
對於應用 Bert，搜尋或 IR 的問題模式及解決方案流程和 QA 任務是非常相近的，但是因為任務不同，所以還是有些區別。
搜尋任務和 QA 任務的區別，我綜合各方面資訊，列一下，主要有三點：
首先，儘管兩個任務都是在做 Query 和 Document 的匹配，但是匹配時側重於哪些因素，這兩個任務是不同的。兩個文字的「相關性」和「語義相似性」代表的內涵是有差異的；所謂「相關性」，更強調字面內容的精確匹配，而「語義相似性」則多涵蓋了另外一個意思：就是儘管字面不匹配，但是深層語義方面的相近。QA 任務對於這兩者都是重視的，可能偏向語義相似性更多一些，而搜尋任務更偏重文字匹配的相關性方面。這是兩個任務的第一個不同。
其次，文件長度的差異。QA 任務往往是要查詢問題 Q 的答案，而答案很可能只是一小段語言片段，在 Passage 這個較短的範圍內，一般會包含正確答案，所以 QA 任務的答案一般比較短，或者說搜尋物件比較短就可以覆蓋正確答案，即 QA 任務的處理物件傾向於短文字；而對搜尋任務來說，文件普遍比較長。儘管在判斷文件是否與查詢相關時，也許只依賴長文件中的幾個關鍵 Passage 或者幾個關鍵句子，但是關鍵片段有可能散落在文件的不同地方。在應用 Bert 的時候，因為 Bert 對於輸入長度有限制，最長輸入允許 512 個單位。於是，如何處理長文件，對於搜尋來說比較重要；
再次，對於 QA 這種任務來說，可能文字內包含的資訊足夠作出判斷，所以不需要額外的特徵資訊；而對於搜尋這種任務，尤其是現實生活中的實用化的搜尋，而非性質比較單純的評測中的 Ad hoc 檢索任務。在很多時候，僅僅靠文字可能無法特別有效地判斷查詢和文件的相關性，其它很多因素也嚴重影響搜尋質量，比如連結分析，網頁質量，使用者行為資料等各種其它特徵也對於最終的判斷也起到重要作用。而對於非文字類的資訊，Bert 貌似不能很好地融合並體現這些資訊。推薦領域其實也跟搜尋一樣，面臨類似的問題。
儘管講了這麼多領域間的區別，但是其實也沒什麼用，如果你看目前見到的用 Bert 改進檢索領域的工作，尤其是 Passage 級別的資訊檢索問題，可能你無法分辨現在在做的是搜尋問題還是 QA 問題。當然，對於長文搜尋，搜尋還是有單獨的問題需要處理。為何會出現這種無法分辨 QA 及搜尋任務的現象呢？這是因為目前出現的利用 Bert 改進檢索的工作，一方面比較集中在 Passage 級別；另外一方面通常任務是 Ad Hoc 檢索，以內容匹配為主，與真實搜尋引擎利用的主要特徵差異比較明顯。主要應該是這兩個原因造成的。
我們再歸納下在 Ad Hoc 檢索任務中一般如何應用 Bert: 一般也是分成兩個階段，首先利用 BM25 等經典文字匹配模型或者其它簡單快速的模型對文件進行初步排序，取得分前列 Top K 文件，然後用複雜的機器學習模型來對 Top K 返回結果進行重排序。應用 Bert 的地方明顯在搜尋重排序階段，應用模式與 QA 也是類似的，就是把 Query 和 Document 輸入 Bert，利用 Bert 的深層語言處理能力，作出兩者是否相關的判斷。如果是 Passage 級別的短文件檢索，其實流程基本和 QA 是一樣的；而如果是長文件檢索，則需要增加一個如何處理長文件的技術方案，然後再走 Bert 去做相關性判斷。
所以，對於如何在資訊檢索領域應用 Bert，我們從兩個不同的角度來說：短文件檢索和長文件檢索。
對於短文件檢索而言，你把它看成 QA 任務，其實問題也不大。所以這裡不細說了，直接上結果。幾個工作在 Passage 級別文件檢索任務中的效果，可以參考這個 PPT 所列內容：
從上面各種實驗資料可以看出：對於短文件檢索來說，使用 Bert 後，效能一般都有大幅度的提升。
對於長文件檢索任務，因為 Bert 在輸入端無法接受太長的輸入，則面臨一個如何將長文件縮短的問題。其它過程和短文件檢索基本雷同。那麼怎麼解決搜尋中的長文件問題呢？可以參考下列論文的思路。
論文：Simple Applications of BERT for Ad Hoc Document Retrieval
這篇論文首次在資訊檢索領域應用 Bert，並且證明了 Bert 對於搜尋應用能有效提升效果。它同時做了短文件和長文件的實驗。短文件利用 TREC 2014 的微博資料。引入 Bert 後，在微博搜尋任務上，相對目前最好的檢索模型，在不同的微博搜尋任務中有 5% 到 18% 的效果提升，相對基準方法（BM25+RM3, 這是一個強基準，超過大多數其它改進方法）有 20% 到 30% 的效果提升。
第二個資料集是 TREC 長文件檢索任務，這裡就體現出搜尋和 QA 任務的不同了。因為要搜尋的文件比較長，在重排序階段，很難把整個文件輸入到 Bert 中，所以這個工作採取了一個簡單的方法：把文件分割成句子，利用 Bert 判斷每個句子和查詢 Q 的相關性，然後累加得分最高的 Top N 句子（結論是取得分最高的 3 個句子就夠了，再多效能會下降），獲得文件和查詢 Q 的相關性得分，這樣就將長文件問題轉化成了文件部分句子的得分累加的模式。實驗表明相對強基準 BM25+RM3，使用 Bert 會有大約 10% 的效果提升。
一種搜尋領域長文件的解決思路
從上面這篇文章對搜尋長文件的處理過程，我們可以進一步對此問題進行深入思考。考慮到搜尋任務的特殊性：文件和使用者查詢的相關性，並不體現在文章中的所有句子中，而是集中體現在文件中的部分句子中。
如果這個事實成立，那麼一種直觀地解決搜尋任務中長文件問題的通用思路可以如下：先透過一定方法，根據查詢和文件中的句子，判斷兩者的相關性，即產生判斷函式 Score=F (Q,S)，根據 Score 得分篩選出一個較小的句子子集合 Sub_Set (Sentences)，由這些句子來代表文件內容。
這樣即可將長文有針對性地縮短。從和查詢相關性的角度來說，這樣做也不會損失太多資訊。關鍵是這個 F（Q，S）函式如何定義，不同的定義方法可能產生表現不同的效果。這個 F 函式，可以被稱為搜尋領域文件的句子選擇函式，這個函式同樣可以使用不同的 DNN 模型來實現。這裡是有很多文章可做的，有心的同學可以關注一下。
如果歸納一下的話：在搜尋領域應用 Bert，如果是 Passage 這種短文件搜尋，往往效果有非常巨大的提升；而目前長文件的搜尋，使用 Bert 也能有一定幅度的提升，但是效果不如短文件那麼明顯，很可能原因在於搜尋的長文件處理方式有它自己的特點，還需要繼續摸索更合理的更能體現搜尋中長文件特性的方法，以進一步發揮 Bert 的效果。
應用領域：對話系統／聊天機器人（Dialog System or Chatbot）
聊天機器人或者對話系統最近幾年也非常活躍，這與市面上出現大量的聊天機器人產品有關係。個人私見，這個方向是符合未來發展趨勢的方向，但是目前的技術不夠成熟，難以支撐一個能夠滿足人們心目中期望的好用產品，所以我個人不是太看好這個方向近期內的產品形態，主要還是目前技術發展階段所限，支撐不起一個好的使用者體驗。這是題外話。
聊天機器人從任務型別劃分的話，常見的有日常聊天以及任務解決型。日常聊天好理解，就是漫無目的地閒聊，幫你打發時間，當然前提是你得有空閒時間需要被它打發掉。我發現低齡兒童很可能是這個任務型別的目標受眾，兩年前我家閨女能興致勃勃地跟 Siri 聊半個小時，聊到 Siri 都嫌她煩了。當然，Siri 收到的最後一句話往往是這樣的：「Siri，你太笨了！」
任務解決就是幫著使用者解決一些日常事務，解決日常碰到的實際問題。比如，99% 的直男，一年中會因為忘記一些節假日被女友或者老婆噴得患上節假日恐懼症，有了聊天機器人，你就再也不用怕了。
你可以跟聊天機器人說：「以後但凡是節假日，你記得提醒我，幫我給 XX 訂束花。」於是，你在一年的 365 天裡，有 364 天會收到聊天機器人的 500 多個提醒，這樣你再也不用怕被噴了，生活會變得越來越美好。
而且假如萬一你中年失業，因為對送花這個事情特別熟悉，所以估計去開個連鎖花店，說不定過幾年就上市了，也許比瑞幸咖啡上市速度還快…… 這就是任務解決型聊天機器人帶給你的切實的好處，不湊巧還能推著你意外地走向人生巔峰。
上面開個玩笑，如果從技術角度看的話，聊天機器人主要面臨兩種技術挑戰。
其一：對於單輪對話來說，就是一問一答場景，任務解決型聊天需要從使用者的話語中解析出使用者的意圖。比如到底使用者是想要訂餐還是點歌，一般這是個分類問題，叫使用者意圖分類，就是把使用者的意圖分到各種服務型別裡面；
另外如果使用者意圖敲定，那麼根據意圖要抽取出一些關鍵元素，比如訂機票，需要抽取出出發地、目的地、出發時間、返程時間等資訊。目前一般採用槽填充（Slot Filling）的技術來做，一個關鍵元素就是一個槽位（Slot），從使用者互動中抽取出的這個槽位對應的取值，就是 Filling 過程。
比如點歌場景下，有一個槽位就是「歌手」，而如果使用者說「播放 TFBoys 的歌」，那麼經過槽位填充，會得到「歌手」槽位對應的取值「歌手 = TFBoys」，這就是典型的槽位填充過程。
論文「BERT for Joint Intent Classification and Slot Filling」即是利用 Bert 解決單輪會話的會話意圖分類以及槽位填充任務的。解決方法也很直觀，輸入一個會話句子，Transformer 的 [CLS] 輸入位置對應高層 Transformer 位置輸出句子的意圖分類，這是一個典型地應用 Bert 進行文字分類的方法；
另外一方面，對於會話句中的每個單詞，都當作一個序列標註問題，每個單詞在 Transformer 最高層對應位置，分類輸出結果，將單詞標註為是哪類槽的槽值的 IOE 標記即可。這是典型的用 Bert 解決序列標註的思路。而這個方法則透過 Bert 同時做了這兩件事情，這點還是挺好的。
透過採用 Bert 預訓練過程，在兩個資料集合上，在意圖分類任務上效果提升不太明顯，可能是基準方法本身已經把指標做得比較高了；槽值填充方面，與 RNN+Attention 等基準方法相比，兩個資料集合表現不一，一個資料集合效果提升 2%，另外一個提升 12% 左右。總體而言，表現還行，但是不突出。
其二：對於多輪會話來說，就是說使用者和聊天機器人互動問答好幾個回合的場景下，如何改進模型，讓聊天機器人記住歷史的使用者互動資訊，並在後面的應答中正確地使用歷史資訊，就是個比較重要的問題，這也很大程度上影響使用者對於聊天機器人到底有多智慧的體驗。
所以，如何有效融入更多的歷史資訊，並在上下文中正確地場合正確地使用歷史資訊，就是模型改進的關鍵。
那麼如果把 Bert 應用在多輪會話問題上，會是什麼效果呢？論文 Comparison of Transfer-Learning Approaches for Response Selection in Multi-Turn Conversations 給出了實驗結果。
它利用 GPT 及 Bert 等預訓練模型改進多輪對話中如何融入歷史資訊，來對下一句選擇的問題。效果提升明顯，Bert 效果優於 GPT，GPT 效果明顯優於基準方法。Bert 相對基準方法，在不同資料集合下，效果提升幅度在 11% 到 41% 之間。
總之，Bert 應用在聊天機器人領域，潛力應該還是比較大的。單輪會話的問題相對比較簡單；多輪會話中，如何融入上下文這個問題，還是比較複雜，我相信 Bert 在這裡能夠發揮較大的作用。
應用領域：文字摘要
文字摘要有兩種型別，一種是生成式的（Abstractive Summarization），輸入是較長的原始文件，輸出的內容不侷限於在原文出現的句子，而是自主生成能夠體現文章主要思想的較短的摘要；另外一種是抽取式的（Extractive Summarization），意思是從原始文件中選擇部分能夠體現主題思想的句子，摘要是由文中抽出的幾個原始句子構成的。
下面分述兩種不同型別的摘要任務，在應用 Bert 時的要點。
生成式文字摘要
很明顯，生成式摘要任務，從技術體系來說，符合典型的 Encoder-Decoder 技術框架：原始文章從 Encoder 輸入，Decoder 生成語句作為摘要結果。既然是這樣，要想利用 Bert 的預訓練成果，無非體現在兩個地方，一個地方是 Encoder 端，這個好解決，只需要用預訓練好的 Bert 模型初始化 Encoder 端 Transformer 引數即可，簡單直觀無疑義；
另外一個地方是在 Decoder 端，這個地方要應用 Bert 就比較麻煩，主要的問題在於：儘管也可以用 Bert 的預訓練引數初始化 Decoder 對應的 Transformer 引數，但是目前各種實驗證明這麼做效果不好，主要是因為：Bert 在預訓練的時候，採用的是雙向語言模型的模式。
而一般的 NLP 任務在 Decoder 階段的生成過程，是從左到右一個單詞一個單詞逐步生成的。所以，這與 Bert 的雙向語言模型訓練模式不同，無法有效利用 Bert 在預訓練階段學習好的下文的資訊提示作用。於是，造成了 Bert 的預訓練模型無法在 Decoder 端充分發揮作用。
所以，如果採取 Encoder-Decoder 框架做生成式的文字摘要，要想發揮出 Bert 的威力，並不容易。因為它面臨與 Bert 做 NLP 生成類任務完全相同的問題，而 Bert 目前在生成模型方面是個難題，儘管最近出了幾個方案，但是實際上，這個問題貌似仍然並沒有被很好地解決，所以它是嚴重依賴 Bert 生成模型的技術進展的。
至於如何在生成類任務中發揮 Bert 的潛力，這是 Bert 模型改進的一個重要方向，關於目前的解決方案及效果評價，我會放在下一篇「模型篇」裡分析，所以這裡暫時略過不表。
抽取式文字摘要
抽取式文字摘要則是個典型的句子分類問題。意思是模型輸入文章整體的文字內容，給定文中某個指定的句子，模型需要做個二分類任務，來判斷這個句子是不是應該作為本文的摘要。
所以，抽取式文字摘要本質上是個句子分類任務，但是與常規文字分類任務相比，它有自己獨特的特點，這個特點是：輸入端需要輸入整個文章內容，而分類的判斷物件僅僅是當前要做判斷的某個句子，整個文章只是對當前句子進行判斷的一個上下文，但是又必須輸入。
而一般的文字或者句子分類，輸入的整體就是判斷物件，不存在多出來的這個上下文的問題。這是它和普通的文字分類任務的最主要區別。
所以說，對於抽取式文字摘要任務，儘管可以把它看成個句子分類任務，但是它的輸入內容和輸出物件不太匹配，這個是關鍵差異。於是，在模型輸入部分如何表達這種句子和文章的隸屬關係方面，需要花些心思。
如果要用 Bert 做抽取式摘要，也就是用 Transformer 作為特徵抽取器，並用 Bert 的預訓練模型初始化 Transformer 引數，以這種方式構建一個句子的二分類任務。從模型角度，Bert 肯定是可以支援做這個事情的，只需要用 Bert 的預訓練模型初始化 Transformer 引數即可。
問題的關鍵是：如何設計並構建 Transformer 的輸入部分？要求是：輸入部分同時要輸入文章整體的內容，並指出當前要判斷的句子是哪個句子。所以，這裡的關鍵是 Transformer 模型的輸入和輸出如何構造的問題，而模型本身應用 Bert 成果則沒什麼問題，算是一種常規的 Bert 應用。
我以前發過一篇思維方法論方面的文章：
https://zhuanlan.zhihu.com/p/51934140
現在可以套用一下這個方法，也就是在沒看到別人怎麼做之前，自己想想你會怎麼做。所以，在沒有看到用 Bert 做抽取式摘要的論文前，我自己拍腦袋想了想，發現比較容易想到的有下面兩種方法：
方法一：把 Transformer 的輸入分為兩個部分，第一個部分是文章原文。當然，目前 Bert 支援的最大輸入長度 512，所以原文也不能太長；第二個部分是當前要判斷的句子。
兩者之間加個分隔符 <SEP>；輸出部分則要求最開始的 [CLS] 輸入位置對應的 Transformer 最高層輸出 0/1 兩種分類結果，如果結果是 1，則意味著這個句子可以作為摘要句，0 則意味著此句不會作為摘要句。
只要依次對文中每個句子都如此判斷一下，把分類為 1 的句子按照句中順序拼接，就可以得到文字摘要。這是一種可能的方法；目前我尚未看到如此做的模型，當然，我自己也覺得這個方式繁瑣了些。
方法二：Transformer 的輸入部分只有一個部分，就是文章本身的完整的內容，由多個句子構成。如果是這種輸入，那麼帶來的新的問題是：我們怎麼知道當前要判斷哪個句子是否適合作為摘要句呢？
可以這麼做：在 Transformer 的輸入部分，在每個句子頭加入一個句子起始標記 <BOS>, 或者把這個分隔符號理解為是句子之間的分隔符也可以；或者也可以在句子的對應 Embedding 里加入句子編號，用來區分不同句子的界限應該也可以 (Bert 的輸入部分除了常規的單詞 embedding。
對於多句子型別任務，還有句子的 embedding，屬於相同句子的單詞共享相同的句子 embedding)。儘管可以有不同的具體做法，但是核心思想是相近的：就是在輸入端明確加入一些標記符號，用來區分不同的句子。
輸入部分的問題解決了，於是，剩下的問題就是 Transformer 的輸出部分怎麼設計了。同樣的，這裡可能有幾種不同的做法。拍下腦袋，比如可以模仿閱讀理解的輸出，要求 Transformer 的輸出部分輸出若干個句子的 <起始 Position, 終止 Position>，這是一種可能做法。
比如也可以在最開始的輸入 [CLS] 符號對應的 Transformer 最高層 Embedding 上面上面繫結 K 個輸出頭，每個輸出頭輸出被選為摘要的句子編號，指定最多輸出 K 個摘要句子，這是另外一種可能做法。
除此外，還有其它的可能做法，比如也可以在 Transformer 的最高層各個單詞的 embedding 序列裡，找出輸入側對應的句子頭位置 < BOS > 的相應位置的高層 Embedding 資訊，每個 < BOS > 對應的輸入位置對應高層 embedding 作為這個句子的資訊整合，在這個句子資訊 Embeddding 基礎上設計分類層，這樣等於給每個句子進行分類。
還有其它做法嗎？應該還有。比如還可以把摘要看成一個類似分詞或者 POS 的單字 / 單詞分類問題，每個輸入單詞對應的 Transformer 高層節點，要求對每個單詞進行分類，而輸出的類別可以設計為 [BOS (摘要句子起始單詞標記)，MOS（摘要句子句中單詞標記），EOS（摘要句子結束單詞標記），OOS（非摘要句單詞標記）]，這也是一種可能的做法，這是把摘要看成序列標註問題來做的。當然，你也可以拍拍腦袋，估計還有很多其它做法。
目前有個論文（Fine-tune BERT for Extractive Summarization）是做抽取式文字摘要的。它的具體做法基本遵循上面講的方法二的框架，在輸入部分用特殊分隔符分隔開不同的句子，每個句子加入句子頭標記 <CLS>，在輸出部分則要求在輸入為 < CLS > 位置對應的 Transformer 最高層 embedding 之上，構建輸出層，用來判斷這個句子是否會被選為摘要句子。
和上面的敘述方法不同的地方是：它在 < CLS > 輸出層和真正的分類層之間又多加入了一個網路層，用來整合文章中不同句子之間的關係，比如用線性分類 /transformer/RNN 等模型來整合句子間的資訊，然後在此基礎上，再輸出真正的句子分類結果。
不過，從試驗結果看，其實這個新加入的中間網路層，使用不同模型效果差不太多，這說明在這裡加入新的網路層並沒有捕獲新的資訊，我個人覺得這塊是可以拿掉簡化一下模型的。至於用上述思路引入 Bert 預訓練模型的摘要系統，從效果上看，雖然優於目前的 SOTA 模型，但是並沒有超過太多。而這說明了什麼呢？這是值得思考的一個問題。
應用領域：NLP 中的資料增強
我們知道，在 CV 領域中，影像資料增強對於效果有非常重要的作用，比如影像旋轉或者摳出一部分圖片作為新增的影像訓練例項。其實，NLP 任務也面臨類似的需求，之所以會有這種需求，是因為：如果訓練資料越充分，能夠覆蓋更多的情形，那麼模型效果越好，這個道理好理解。問題是怎麼才能低成本地擴充任務地新訓練資料。
當然，你可以選擇人工標註更多的訓練資料，但無奈人工標註訓練資料成本太高，能否藉助一些模型來輔助作出新的訓練資料例項，以此來增強模型效能呢？NLP 資料增強就是幹這個事情的。
回到我們的主題上來：能否利用 Bert 模型來擴充人工標註好的訓練資料？這是在資料增強領域應用 Bert 的核心目標。目標很明確，剩下的問題是具體的方法而已。這個領域算是比較有新意的 Bert 應用領域。
論文：Conditional BERT Contextual Augmentation
這是個比較有趣的應用，來自於中科院信工所。它的目的是透過改造 Bert 預訓練模型，來產生新增的訓練資料，以此來增強任務分類效果。就是說對於某個任務，輸入訓練資料 a，透過 Bert，產生訓練資料 b，利用 b 來增強分類器效能。
它的改造方法如下：將 Bert 的雙向語言模型，改造成條件語言模型。所謂「條件」，意思是對於訓練資料 a，Mask 掉其中的某些單詞，要求 Bert 預測這些被 Mask 掉的單詞，但是與通常的 Bert 預訓練不同的是：它在預測被 Mask 掉的單詞的時候，在輸入端附加了一個條件，就是這個訓練資料 a 的類標號，假設訓練資料的類標號已知，要求根據訓練資料 a 的類標號以及上下文，透過 Bert 去預測某些單詞。之所以這樣，是為了能夠產生更有意義的訓練資料。
比如對於情感計算任務來說，某個具備正向情感的訓練例項 S，mask 掉 S 中的情感詞「good」，要求 Bert 生成新的訓練例項 N，如果不做條件約束，那麼 Bert 可能產生預測單詞「bad」，這也是合理的，但是作為情感計算來說，類別的含義就完全反轉了，而這不是我們想要的。
我們想要的是：新產生的訓練例子 N，也是表達正向情感的，比如可以是「funny」，而如果加上類標號的約束，就可以做到這一點。具體增加約束的方式，則是將原先 Bert 中輸入部分的 Sentence embedding 部分，替換成輸入句子的對應類標號的 embedding，這樣就可以用來生成滿足類條件約束的新的訓練資料。這個做法還是很有意思的。
如果將透過 Bert 產生的新訓練資料增加到原有的訓練資料中，論文證明了能夠給 CNN 和 RNN 分類器帶來穩定的效能提升。
另外一篇論文 Data Augmentation for BERT Fine-Tuning in Open-Domain Question Answering 也涉及到了 NLP 中的資料增強，不過這個資料增強不像上面的文章一樣，訓練資料透過 Bert 產生，貌似是在 QA 問題裡面採用規則的方式擴充正例和負例，做例子本身沒什麼特別的技術含量，跟 Bert 也沒啥關係。
它探討的主要是在 Bert 模型下的 QA 任務中，如何使用這些增強的訓練資料。有價值的結論是：如果同時增加透過增強產生的正例和負例，有助於增加 Bert 的應用效果；而且 Stage-wise 方式增加增強資料（就是原始訓練資料和增強訓練資料分多個階段依次進行訓練，而且距原始訓練資料越遠的應該越先進行 Fine-tuning），效果好於把增強資料和原始資料混合起來單階段訓練的模式。
所以，上面兩個文章結合著看，算是用 Bert 產生新的訓練例項以及如何應用這種增強例項的完整過程。
應用領域：文字分類
文字分類是個 NLP 中歷史悠久，源遠流長….. 總之比較成熟的應用領域。它的意思是給定一個文件，模型告訴這是哪個類別，是講的「體育」還是「娛樂」，總之就是這個意思。
那麼，Bert 應用在這個領域效果如何呢？目前也有工作。
論文：DocBERT: BERT for Document Classification
在四個常用的標準文字分類資料集合上，利用 Bert 的預訓練模型進行了效果測試，應該說效果能夠達到以及超過之前的各種方法，但是總體而言，相對之前的常用方法比如 LSTM 或者 CNN 模型，提升幅度不算太大，基本提升幅度在 3% 到 6% 之間。
對於文字分類，Bert 並未能夠獲得非常大的效果提升，這個結果其實是可以理解的。因為把一個還比較長的文件分到一個類別裡，這種任務偏語言淺層特徵的利用，而且指示性的單詞也比較多，應該算是一種比較好解決的任務，任務難度偏簡單，Bert 的潛力感覺不太容易發揮出來。
應用領域：序列標註
嚴格地說，序列標註並非一個具體地應用領域，而是 NLP 中一種問題解決模式。很多 NLP 任務都可以對映為序列標註問題，比如分詞，詞性標註，語義角色標註等等，非常多。
它的一個特點是：對於句子中任意一個單詞，都會有一個對應的分類輸出結果。在原始的 Bert 論文裡面也給出了序列標註任務如何使用 Bert 的預訓練過程，實際應用的時候，應用模式就是那種模式。
如果不考慮具體應用場景，把不同應用場景對映到序列標註這種問題解決模式的話，目前也有一些工作使用 Bert 來增強應用效果。
論文：Toward Fast and Accurate Neural Chinese Word Segmentation with Multi-Criteria Learning
這個工作使用 Bert 作為多標準分詞的特徵抽取器。所謂多標準，是指的同一個語言片段，在不同場景下可能有不同粒度的分詞結果。
它使用 Bert 預訓練的 Transformer 作為主要特徵抽取器，針對不同資料集合可能分詞標準不同，所以在 Transformer 之上，為每個分詞資料集合構建一個獨有的引數頭，用來學習各自的標準。同時增加一個共享的引數頭，用來捕捉共性的資訊。
在此之上，再用 CRF 來做全域性最優規劃。這個模型在多個分詞資料集合上取得了最高的分詞效果。不過總體而言，效果提升不太明顯。這也可能與之前的技術方法已經把分詞解決的還比較好，所以基準比較高有關係。
論文：BERT Post-Training for Review Reading Comprehension and Aspect-based Sentiment Analysis
這個工作做了兩個事情，一個是閱讀理解，另外一個是情感計算。其中情感計算的 Aspect Extract 任務是採用序列標註的方式做的，利用 Bert 的預訓練過程後，與之前的最好方法比，效果提升不明顯。
論文：Multi-Head Multi-Layer Attention to Deep Language Representations for Grammatical Error Detection
這個工作主要解決的應用問題是句法錯誤檢測。把這個問題對映成了序列標註問題，使用 Bert 預訓練後，效果提升明顯，與基準方法比，效能有大幅度地提高；
上文在談對話系統應用領域時，還提到過一個單輪對話系統利用 Bert 進行槽位填充的工作，也是對映成序列標註問題來解決的，那個工作結論是兩個資料集合，一個提升 2%，一個提升 12%。
綜合看，大部分序列標註任務在利用了 Bert 後，儘管把任務效果都能做到當前最好，但是效果提升幅度，與很多其它領域比，不算大。這可能跟具體的應用領域有關係。
應用領域：其它
除了上面我進行了歸類的 Bert 應用外，還有零星一些其它領域的 Bert 應用工作，這裡簡單提幾句。
論文：Assessing BERT's Syntactic Abilities
這個工作對 Bert 的句法分析能力做了測試，使用主語 - 謂語一致性任務做為測試任務。與傳統表現較好的 LSTM 模型做了對比，測試資料表現 Bert 效果大幅超過 LSTM 的效果，當然作者強調因為一些原因這個資料不可直接對比。不過至少說明 Bert 在句法方面是不弱於或者強於 LSTM 的。
另外，還有兩篇做 NLP to SQL 的工作（Achieving 90% accuracy in WikiSQL/ Table2answer: Read the database and answer without SQL），意思是不用你寫 SQL 語句，而是用自然語言發出命令，系統自動轉化成可執行的 SQL 語句，使用 Bert 後，也取得了一定幅度的效能提升。我理解這種任務因為是領域受限的，所以相對容易些，我個人對這個方向也沒啥興趣，所以這裡不展開了，感興趣的可以找論文看。
除此外，還有兩篇做資訊抽取的工作，使用 Bert 後，效果也比較一般，這個領域其實是值得深入關注的。
目前已經發表的 Bert 應用，絕大部分基本都已經被我歸類到上面各個領域裡了。這裡明確提到的論文，都是我認為有一定參考價值的一部分，並不是全部，我篩掉了一批我認為質量不是太高，或者參考價值不大，或者我認為方法過於複雜的工作，這點還請注意。當然，一定也有一部分有價值的工作，因為沒有進入我狹窄的視野，所以沒有被列入，這也是有可能的。
永珍歸宗：事實，其實和你想的也許不一樣
上面介紹了不少 NLP 領域如何應用 Bert 提升效果，方法眾多，效果各異，容易讓人看起來眼花繚亂，不太能摸著頭腦。也許你在沒看這些內容之前，腦子裡就一個印象：Bert 大法好，對 NLP 各種應用都能有很大效能提升作用。事實是這樣嗎？其實並不是。在你看完上面的內容後，看到了五彩繽紛絢爛多彩的各種方法，可能更容易犯暈，感覺沒啥結論可下，此刻眼裡正閃耀著迷茫的光芒…….
其實，這都是表面現象。我在這裡總結一下。純個人分析，不保證正確性，猜對算碰巧，猜錯也正常。
儘管看上去有各種各樣不同的 NLP 任務，其實如何應用 Bert，一切答案在原始的 Bert 論文裡，大部分都講到了。其利用 Bert 的過程是基本一樣的，核心過程都是用 Transformer 作為特徵抽取器，用 Bert 預訓練模型初始化 Transformer 的引數，然後再用當前任務 Fine-tuning 一下，僅此而已。
如果我們再細緻一些，分任務型別來看的話，歸納下，結論很可能會是這樣的；
如果應用問題能夠轉化成標準的序列標註問題（分詞 / 詞性標註 / 語義角色標註 / 對話槽位填充 / 資訊抽取等，很多 NLP 任務可以轉化為序列標註的問題解決形式），或者單句或文件分類問題（文字分類 / 抽取式文字摘要可以看成一種帶上下文的單句分類問題），那麼可以直接利用 Bert 的預訓練過程，任務無需特殊改造；
目前已有實驗結果，貌似說明在這兩類任務中，使用 Bert 應該能夠達到最好的效果，但是與之前未採納 Bert 的最好模型比，多數任務效能提升似乎相對有限。這其中有什麼深層的原因嗎？我有個判斷，後面會說；
如果是短文件的雙句關係判斷任務，比如典型的就是 QA / 閱讀理解 / 短文件搜尋／對話等任務，一般利用 Bert 的方式也是直觀的，就是 Bert 原始論文中提出的兩個句子間加分隔符輸入的方式，不需要特殊改造。目前看，這類任務，利用 Bert 後往往效能有大幅度的提升。
但是，為什麼你在看上文的時候，會覺得看上去有很多不同的各異的模型呢？主要是因為有些 NLP 領域，儘管利用 Bert 的過程其實就是上面的過程，但是需要單獨解決自己任務的一些特點問題，比如搜尋領域的長文件輸入問題怎麼解決，搜尋領域的粗排序需要有其它方法；
對於抽取式摘要來說，輸入輸出如何設計是個問題，因為它和普通的文字分類不太一樣；比如多輪對話系統的歷史資訊如何利用，需要有個歷史資訊融合或者選擇的方法存在…… 諸如此類。其實關鍵的應用 Bert 的部分，並無特殊之處。這一切冥冥中，早已經在原始的 Bert 論文裡講過了。「被酒莫驚春睡重，賭書消得潑茶香，當時只道是尋常。」很多事，不過如此。
經過我此番任性的解釋，此刻，您眼中迷茫的光芒，熄滅了嗎？還是更熾熱了？
看我 72 變：對應用問題的重構
如果上面的判斷正確的話，你應該問自己一個問題：「既然看上去貌似 Bert 更適合處理句子對關係判斷問題。而對於單句分類，或者序列標註問題，儘管有效，但是貌似效果沒那麼好。於是，能不能利用下 Bert 的這一點，怎麼利用呢？比如說能不能把單句分類問題，或者序列標註問題，轉化下問題的表達形式，讓它以雙句關係判斷的表現形態出現呢？」
如果你真能問出這個問題，這意味著，你真是挺適合搞前沿研究的。
事實上，已經有些工作是這麼做了，而且事實證明，如果能夠對應用問題進行重構的話，其它事情都不用做，就能直接提升這些任務的效果，有些任務效果提升還非常明顯。怎麼重構呢？對於某些具備一定特性的 NLP 任務，如果它看上去是單句分類問題，那麼可以透過問題重構，比如引入虛擬句，把單句輸入問題改造成句間關係判斷問題，這樣就能充分發揮 Bert 的這個特性，直接提升效果。
就是這麼重構。
論文：Utilizing BERT for Aspect-Based Sentiment Analysis via Constructing Auxiliary Sentence
這個工作來自復旦大學。它利用 Bert 來最佳化細粒度的情感分類任務。所謂細粒度的情感分類任務，指的是不僅僅對某個句子或者某個實體的整體情感傾向做個整體判斷，而是對實體的不同方面作出不同的判斷，比如例子「LOCATION1 is often considered the coolest area of London.」，就是說某個實體（這裡的例子是某個地點 LOCATION 1）的 A 方面（比如價格 price）是怎樣的情感傾向，B 方面（比如安全性 safety）是怎樣的情感傾向等，細粒度到某個實體的某個方面的情感傾向。
這個工作做得非常聰明，它把本來情感計算的常規的單句分類問題，透過加入輔助句子，改造成了句子對匹配任務（比如上面的例子，可以增加輔助句：「what do you think of the safety of LOCATION 1」）。我們前面說過，很多實驗證明了：Bert 是特別適合做句子對匹配類的工作的，所以這種轉換無疑能更充分地發揮 Bert 的應用優勢。而實驗也證明，經過這種問題轉換，效能有大幅度地提升。
Salesforce 也有個類似想法的工作（Unifying Question Answering and Text Classification via Span Extraction），它的部分實驗結果也表明，單句分類任務，透過加入輔助句，轉化成雙句關係判斷任務，也能提升任務效果。
為什麼對於 Bert 應用來說，同樣的資料，同樣的任務，只需要把單句任務轉成句子對匹配任務，效果就突然變好了呢？這個問題其實是個好問題，在後面我會給兩個可能的解釋。
這個方向是值得進一步深入擴充的，目前工作還不多，我預感這裡還有很大的潛力可以挖掘，無論是探索還是應用角度，應該都是這樣的。
狸貓換太子：Fine-tuning 階段的 In Domain 和 Out Domain 問題
我們知道，在應用 Bert 的時候，真正使用某個應用的資料，是在第二階段 Fine-tuning 階段，透過用手頭任務的訓練資料對 Transformer 進行訓練，調整引數，將 Transformer 的引數針對手頭任務進行 Fine-tune，之後一般會獲得明顯的應用提升。
這裡所謂的 In-Domain 和 Out-Domain 問題，指的是：Out-Domain 意思是你手頭任務有個資料集合 A，但是在 Bert 的 Fine-tuning 階段，用的是其它資料集合 B。知道了 Out-Domain，也就知道 In-Domain 的意思了，就是說用手頭任務資料集合 A 去 Fine-tune 引數，不引入其它資料。
那麼問題是：為什麼手頭任務是 A，要引入資料集合 B 呢？這個在做具體應用的時候，其實還是比較常見的。如果你手頭任務 A 的訓練資料足夠大，其實完全可以走 In-Domain 的路線就夠了。
但是如果你手上的任務 A 訓練資料太小，一般而言，儘管也可以用它去做 Bert 的 Fine-tuning，但是無疑，效果可能有限，因為對於引數規模這麼大的 Bert 來講，太少的 Fine-tuning 資料，可能無法充分體現任務特點。
於是，我們就期待透過引入和手頭任務 A 有一定相近性的資料集合 B，用 B 或者 A+B 去 Fine-tune Bert 的引數，期待能夠從資料集合 B Transfer 些共性知識給當前的任務 A，以提高任務 A 的效果。某種角度上，這有點像 Multi-Task 任務的目標。
那麼新的問題是：既然我們期待資料集合 B 能夠遷移些知識給當前任務 A，那麼這兩個任務或者訓練資料之間必然應該有些共性存在。於是，哪些因素決定了不同性質的資料集合 B 對當前任務 A 的影響呢？這個其實是個很實用也很有意思的問題。
目前針對這些問題，也有一些工作和初步的結論。
論文 ThisIsCompetition at SemEval-2019 Task 9: BERT is unstable for out-of-domain samples 研究了 Out-Domain 對 Target 任務的影響，使用了不同領域的資料，在 Fine-tuning 階段使用了大約數量為 9 千左右的電子領域的訓練資料，而 Target 任務是 Hotel 領域的。
可以看出來，這兩個領域差異還是很大。透過實驗對比，結論是：如果是 Out-Domain 這種情況，Target 任務表現非常不穩定，10 輪測試中，Hotel 任務的效能最低是 0，最高 71，方差 31。可以看出來，這效果簡直是在高空彈跳和坐火箭之間頻繁切換。為什麼會這樣？目前還沒有解釋。這裡是值得深入探討一下的。
從這個工作反向推導，我們可以認為，即使資料 B 相對手頭任務 A 來說是 Out-Domain 的，如果它在領域相似性與手頭任務 A 越接近，效果理應越好，這個貌似比較直觀好理解，但是這是我的反向推論，並沒看到一些具體研究對此進行對比，這個事情是值得做一下的。
另一個工作是 Simple Applications of BERT for Ad Hoc Document Retrieval，儘管它是研究資訊檢索的，但是也設計了一些跟 Out-domain 有關的實驗。
它驗證了 Bert 的 Fine-tuning 階段使用資料的一些特性：在 Fine-tuning 階段的訓練資料 B，與下游任務的資料集合 A 相比，兩者的任務相關性，相比兩者的文字的外在表現形式的相似性來說，對於下游任務更重要。
實驗結論是：對於微博這種下游短文字檢索任務（手頭任務 A），儘管它在表現形式上和 Trec 檢索（Out-Domain 資料 B）這種新聞文字形式上差異較大，但是因為都是檢索任務，所以相對用 QA 任務（另外一個 Out-Domain 資料 B）來 Finetune Bert 來說，效果好，而且好得很明顯。
這說明了，對於 Out-Domain 情況來說，Fine-tuning 任務 B 和下游任務 A 的任務相似性對於效果影響巨大，我們儘可能找相同或者相近任務的資料來做 Fine-tuning，哪怕形式上看上去有差異。
還有一個工作：Data Augmentation for BERT Fine-Tuning in Open-Domain Question Answering。它本身是做資料增強的，不過實驗部分的結果，我相信結論也應該能夠遷移到 Out-Domain 情形，它的結論是：假設有幾個新增的訓練集合，比如 B，C，D 三個新資料集合，每個和 Target 任務 A 的資料差異遠近不同，假設 B 最遠，C 次之，D 和 A 最像。
那麼如果是這樣的資料，一種做法是把 A+B+C+D 放到一起去 Fine-tune 模型，另外一種是由遠及近地分幾個階段 Fine-tune 模型，比如先用最遠的 B，然後用 C，再然後用最近的 D，再然後用 A，這種叫 Stage-wise 的方式。結論是 Stage-wise 模式是明顯效果好於前一種方式的。
另外一點，我相信對於 Out-Domain 情況來說，如果 Fine-tuning 任務和下游任務在有相關性的基礎上，無疑應該是資料量越大，對下游任務的正面影響越大。
所以，如果歸納一下目前的研究結論，以及我自己在現有資料基礎上隨意推理的結論，那麼結論很可能是這樣子的：對於 Out-Domain 情況，首選和手頭任務 A 相同或者相近的任務 B 來做 Fine-tuning，而至於這兩個資料的領域相似性，當然越高越好，而資料規模，也應該是越多越好。
如果有多個不同的資料可以用，那麼根據它們和手頭任務的相似性，由遠及近地分 Stage 去 Fine-tune 模型比較好。當然，這裡面有些因素是我個人無依據的推論，實際情況需要實驗證明，所以還請謹慎參考。
這個方向其實是非常有價值的方向，感覺目前的相關工作還是太少，有些問題也沒說清，這裡是值得深入摸索找到好的經驗的，因為我們平常經常會遇到任務資料不夠的問題，那麼想利用好 Bert 就比較困難，而如果把這個問題研究透徹，對於很多實際應用會有巨大的參考價值。
競爭優勢：Bert 擅長做什麼？
在看完目前幾乎所有已發表的 Bert 應用工作後，事實表明，儘管 Bert 在很多應用領域取得了進展，但是在不同方向上，看上去 Bert 的引入對於應用效果促進作用是不同的，有些表現突出的領域會有甚至 100% 的效果提升，有些領域的提升就表現相對平平。
於是，我問了自己一個新的問題：為什麼會出現這個現象呢？這說明了 Bert 還是有比較適合它的應用場景的，如果找到特別適合 Bert 發揮的場景，則效能往往會有極大地提升，但是如果應用場景不能充分發揮 Bert 的優勢，則雖然也會有些改進，但是改進效果不會特別明顯。
於是，新的問題就產生了：Bert 擅長解決具備什麼樣特性的 NLP 任務呢？什麼樣的場景更適合 Bert 去解決？
為了回答這個問題，我對目前的各種工作做了任務對比，並試圖歸納和推理一些結論，目的是希望找出：具備哪些特性的任務是能夠發揮 Bert 模型的優勢的。分析結果如下，純屬個人判斷，錯誤難免，還請批判性地謹慎參考，以免對您造成誤導。
第一，如果 NLP 任務偏向在語言本身中就包含答案，而不特別依賴文字外的其它特徵，往往應用 Bert 能夠極大提升應用效果。典型的任務比如 QA 和閱讀理解，正確答案更偏向對語言的理解程度，理解能力越強，解決得越好，不太依賴語言之外的一些判斷因素，所以效果提升就特別明顯。
反過來說，對於某些任務，除了文字類特徵外，其它特徵也很關鍵，比如搜尋的使用者行為／連結分析／內容質量等也非常重要，所以 Bert 的優勢可能就不太容易發揮出來。再比如，推薦系統也是類似的道理，Bert 可能只能對於文字內容編碼有幫助，其它的使用者行為類特徵，不太容易融入 Bert 中。
第二，Bert 特別適合解決句子或者段落的匹配類任務。就是說，Bert 特別適合用來解決判斷句子關係類問題，這是相對單文字分類任務和序列標註等其它典型 NLP 任務來說的，很多實驗結果表明了這一點。
而其中的原因，我覺得很可能主要有兩個，一個原因是：很可能是因為 Bert 在預訓練階段增加了 Next Sentence Prediction 任務，所以能夠在預訓練階段學會一些句間關係的知識，而如果下游任務正好涉及到句間關係判斷，就特別吻合 Bert 本身的長處，於是效果就特別明顯。
第二個可能的原因是：因為 Self Attention 機制自帶句子 A 中單詞和句子 B 中任意單詞的 Attention 效果，而這種細粒度的匹配對於句子匹配類的任務尤其重要，所以 Transformer 的本質特性也決定了它特別適合解決這類任務。
從上面這個 Bert 的擅長處理句間關係類任務的特性，我們可以繼續推理出以下觀點：
既然預訓練階段增加了 Next Sentence Prediction 任務，就能對下游類似性質任務有較好促進作用，那麼是否可以繼續在預訓練階段加入其它的新的輔助任務？而這個輔助任務如果具備一定通用性，可能會對一類的下游任務效果有直接促進作用。這也是一個很有意思的探索方向，當然，這種方向因為要動 Bert 的第一個預訓練階段，所以屬於 NLP 屆土豪們的工作範疇，窮人們還是散退、旁觀、鼓掌、叫好為妙。
第三，Bert 的適用場景，與 NLP 任務對深層語義特徵的需求程度有關。感覺越是需要深層語義特徵的任務，越適合利用 Bert 來解決；而對有些 NLP 任務來說，淺層的特徵即可解決問題，典型的淺層特徵性任務比如分詞，POS 詞性標註，NER，文字分類等任務，這種型別的任務，只需要較短的上下文，以及淺層的非語義的特徵，貌似就可以較好地解決問題，所以 Bert 能夠發揮作用的餘地就不太大，有點殺雞用牛刀，有力使不出來的感覺。
這很可能是因為 Transformer 層深比較深，所以可以逐層捕獲不同層級不同深度的特徵。於是，對於需要語義特徵的問題和任務，Bert 這種深度捕獲各種特徵的能力越容易發揮出來，而淺層的任務，比如分詞／文字分類這種任務，也許傳統方法就能解決得比較好，因為任務特性決定了，要解決好它，不太需要深層特徵。
第四，Bert 比較適合解決輸入長度不太長的 NLP 任務，而輸入比較長的任務，典型的比如文件級別的任務，Bert 解決起來可能就不太好。主要原因在於：Transformer 的 self attention 機制因為要對任意兩個單詞做 attention 計算，所以時間複雜度是 n 平方，n 是輸入的長度。
如果輸入長度比較長，Transformer 的訓練和推理速度掉得比較厲害，於是，這點約束了 Bert 的輸入長度不能太長。所以對於輸入長一些的文件級別的任務，Bert 就不容易解決好。結論是：Bert 更適合解決句子級別或者段落級別的 NLP 任務。
也許還有其它因素，不過貌似不如上面四條表現得這麼明顯，所以，我先歸納這四項基本原則吧。
淘金記：如何尋找未開墾的 Bert 應用領域
既然我們歸納出 Bert 擅長做的事情的特點，那麼下一步，我們可以按圖索驥，尋找一些目前還沒有人做，但是又特別適合 Bert 來做的應用領域，然後你可以大施拳腳，拳打腳踢，拳腳相向地去施展自己的才智….
怎麼找這些領域呢？你可以去找找看，哪些應用領域同時符合下面幾個條件中的一個或者幾個，同時符合的條件越多，理論上越適合用 Bert 去做：
輸入不太長，最好是句子或者段落，避免 Bert 長文件的問題；
語言本身就能夠很好的解決問題，不依賴其它型別的特徵；
非生成類任務，避開目前 Bert 做生成類任務效果不夠好的雷點；
最好是能夠涉及到多句子關係判斷類任務，充分利用 Bert 善於做句子匹配任務的特點；
最好是能夠牽扯到語義層級的任務，充分利用 Bert 能夠編碼深層語言知識的優點；
如果是單輸入問題，你想想能不能加入輔助句，把它改造成句子匹配型雙輸入任務；
看到這，您可能開始假裝冒充有好奇心地問我了：那到底哪些應用領域符合這些特點呢？……..
嗯，兄弟，你這不是個好奇心問題，實際是個懶漢問題。我請您吃飯，醋都給你準備好了，現在就差餃子了，就看你的了，麻煩您有問這種問題的時間，還是自己去整餃子吧….. 臨淵羨魚不如退而包餃子…….
新趨勢：Bert 能一統 NLP 的天下嗎
在 Bert 出現之前，NLP 中不同的應用領域，往往各自使用這個領域有特色的不同的模型，看上去五花八門，差別還是比較大的。例如閱讀理解就是各種花樣的 Attention 漫天在飛；搜尋領域雖然也進入 DNN 時代了，但是依託的很多還是 Learning to rank 的框架；文字分類就是典型的 LSTM 的主戰場……..
但是隨著 Bert 的出現，我相信以後這種不同應用領域中，技術手段軍閥混戰，群雄割據的局面不會太持久了，Bert 攜預訓練模型之天子令而號諸侯，應該會逐步用一個相對統一的解決方案，統一掉各個 NLP 應用領域割據的局面，收拾舊山河，朝天闕。這很可能意味著一種 NLP 新時代的開始，因為歷史上貌似還沒有這麼大一統的一個 NLP 模型存在過。
為什麼這麼說呢？其實在本文第一個小節的內容你已經應該可以看出這種端倪了，上面涉及了 NLP 的很多應用領域，雖然說 Bert 在不同應用領域的促進效果不同，有的大，有的小些，但是幾乎沒有例外的是，都已經比之前各個領域的 SOTA 方法效果好了，問題無非是好多少而已，而不是好不好的問題。
而之前不同領域的 SOTA 方法，差異是非常大的，尤其是跨領域的時候，你會看到五花八門的技術方案。而這意味著什麼呢？意味著起碼在上述領域裡，完全可以用 Bert 的架構和模型，替代掉那個領域的其它所有 SOTA 方法。而這又意味著什麼？意味著「分久必合，合久必分」的歷史規律中，分久必合的時代到了，而引領這個潮流的，就是 Bert。
這對你來說又意味著什麼呢？這意味著你要學的東西比之前少太多了，學習 NLP 的投入產出價效比急劇提高。你自己拍著胸脯說，這是不是好事？哎，沒讓你拍別人胸脯啊，兄弟……..
而隨著逐漸對 Bert 本身能力的各種增強，很可能這種統一的步伐會越來越快。我估計這個時間應該在未來 1 年到 2 年，很可能大多數 NLP 子領域都會被統一到 Bert 兩階段 + Transformer 特徵抽取器的方案框架上來。
而我認為這是非常好的事情，因為大家可以把精力投入到增強基礎模型的能力，只要基礎模型能力有提升，意味著大多數應用領域的應用效果會直接獲得提升，而不用一個領域一個領域個性化地想方案去啃，那樣效率有點低。
是否真的會發生這一幕？NLP 覆蓋這麼廣泛子方向的科研範圍，它允許這麼牛 X 模型的存在嗎？讓我們拭目以待。
當然，對此我個人持樂觀態度。
這次先這樣吧，連我自己都覺得太長了，看到最後一句的同學，我為你的好學和耐心點個贊……. 不過請你換位思考一下，你用看完這篇文章的時間估算一下，我寫這篇文章要花多少時間？…… 另外，其實最近一陣子我心情並不是太好，不過，還是得想法設法編些段子來逗您笑……. 寫完這些 AI 的文章，我技術水平沒見提高，不過轉型段子手的可能性確實大多了 ……. 李誕，你給我等著…….
說起來都是淚，其實也無所謂。很多事，不過如此。
作者介紹：張俊林，中國中文資訊學會理事，中科院軟體所博士。目前在新浪微博 AI Lab 擔任資深演算法專家。在此之前，張俊林曾經在阿里巴巴任資深技術專家並負責新技術團隊，以及在百度和用友擔任技術經理及技術總監等職務。出版書籍：《這就是搜尋引擎：核心技術詳解》（該書榮獲全國第十二屆優秀圖書獎）、《大資料日知錄：架構與演算法》。
原文連結：https://zhuanlan.zhihu.com/p/68446772