Google 在 2018 年公佈 BERT 的工作之後，引起了 NLP 學術圈以及工業界的極大關注。無論是在各個公司的應用場景中，還是在一些公開的 Benchmark 上，BERT 的效果都得到了驗證。所以國內很多公司都在跟蹤 BERT 的研究，並基於自己實際的業務場景做了針對性的調整與應用。
本文來自 PaperWeekly 和 biendata 組織的企業 AI 技術實戰講座。作者爲美團 NLP 中心的王金剛，主要內容是 BERT 在美團搜索場景中的一些落地實踐。
本文首先概括介紹了 BERT 和後續擴展工作（BERTology），接着介紹了美團如何訓練 BERT 以及在實際業務場景中的 BERT 應用案例。第三部分主要美團如何在搜索相關的場景的任務上中落地 BERT 應用。此外我們將講座中比較有價值的問答內容也做了整理，希望也能解答部分讀者疑問。
本期直播視頻回放：
https://www.bilibili.com/video/BV1vC4y147px
作者簡介：王金剛，博士，研究方向爲自然語言處理。在 AAAI，IJCAI，SIGIR，EMNLP、TKDE 等頂級會議和期刊上發表十多篇文章，同時也是 SIGIR，CIKM，AAAI 的審稿人。王金剛 2018 年底加入美團 NLP 中心，負責美團本地生活服務領域預訓練語言模型工作以及情感分析相關業務。
關於BERT
1.1 NLP預訓練發展史
先來回顧一下 NLP 的發展史，上圖來自微軟亞洲研究院周明在 ACL 2019 大會上的 keynote 演講。雖然有時候大家會說 BERT 是橫空出世，效果特別好，但這方面的工作並非一蹴而就。
這方面最早的研究是大家很熟悉的 Word2Vec，在 NLP 的幾乎所有任務中都會有應用。最開始大家可能是用 one-hot 向量來初始化一些 NLP 的任務或者網絡，但 Word2Vec 出來之後，基本上大家就都改爲使用這個稠密的向量，用 Word2Vec 來初始化 NLP 的網絡。
之後一直到 2018 年，Allen AI 研究所的 ELMo 問世。相對於 Word2Vec，ELMo 不再是靜態的 Word Embedding，而是會考慮上下文的影響。隨着算力增加，GPU 硬件資源越來越好，模型也就可以做得越來越深、越來越大。所以 OpenAI 關於 GPT 的工作就出現了。
GPT 其實比 BERT 出來得要更早一些，但是由於它宣傳方面沒有 Google 的聲音大，所以導致大家更關注後來 BERT 的工作，對 GPT 可能沒有那麼關注。後來 OpenAI 看到 BERT 取得這麼大的關注和成功之後，就又搞了 GPT2，把層數加深到 24 層。
BERT 後續的一些發展也列在圖 1 時間軸的最右邊，包括國內的百度和清華關於 ERNIE 的工作，然後還有 Google 的 XLNet。後來還有一些基於 BERT 的各種擴展。
BERT徹底火了之後，對 NLP 的學術研究和產業應用帶來了根本上（或者說是研究範式上）的變化。NLP 領域可以做到像 CV 領域一樣，用大量的圖片數據（如 ImageNet 數據）做預訓練模型，應用到自己具體的任務。CV 領域中，如果要做目標檢測或圖像分割，可以基於預訓練模型做個簡單的 Fine-tune，然後在只有少量標註樣本的目標任務上取得很好的效果。
BERT 相關預訓練模型出來之後，我們也可以做到通過預訓練語言模型對海量的無標註語料進行學習。模型收斂之後，通用效果很好，在小量的標註樣本上可以做具體的 NLP 任務。像分類、搜索、推薦任務中的語義分析、問答、對話，其實都可以通過小量標註樣本把 BERT 很強大的語意理解能力遷移到具體的目標任務上。
1.2 BERT介紹
上圖是 BERT 整個的結構，以及輸入、輸出。上圖左邊是 BERT 的網絡結構，可以看到它有 12 層 Transformer 結構，更大的網絡有時候會堆疊 24 層。上圖中間放大了每個 Transformer 內部的一些結構。做 NLP 方向的同學肯定會對 Transformer 比較熟。
Transformer 其實是 2017 年，Google 的論文《Attention Is All You Need》提出的。其實在 2017 年、2018 年，BERT 出來之前，Transformer 的應用就非常廣泛了。
大家如果做生成任務，會知道我們現在主流的模型是 Seq2Seq 生成模型。一個 Encoder 一個 Decoder。最開始大家用 BiLSTM、GRU，後來 Transformer 出來之後，我們就已經在使用 Transformer 了。不用說國外的 Google，國內的阿里、騰訊的翻譯君、百度翻譯，都已經大規模遷到基於 Transformer 架構的翻譯模型上面去了。
上圖右邊最上面是 BERT 模型的輸入。輸入 Embedding 其實有三種，它會在 input 這一端做一些調整。比如它除了本身的 Token Embedding 之外，會拼一些所謂的 Segment Embedding。如果有下句預測的任務，因爲有兩句話，所以需要區分 segment，也就有了 Segment Embedding 的概念。
另外需要考慮的是，因爲完全基於 Self-Attention 結構，所以需要考慮每個詞在句中的相對位置，這樣就會有一個 Position Embedding 的概念。
所謂的預訓練其實就是兩個任務，一個是 Masked Language Model，我們簡稱 MLM。MLM 是指把文本中的某個詞掩掉，通過上下文來預測這個詞是什麼，這個過程其實是學一個語言模型。第二個是下句預測任務，通過 SEP 標籤拼接的兩句話，做一些相關的預測。
BERT 主要通過這兩個預訓練任務的聯合訓練，來實現模型對自然語言文本的理解。因此，基於 BERT，如果我們有一個預訓練好的模型，就可以在具體的任務上做 Fine-tune。
從 Google 官方公佈來看，其實我們能做四大類任務：
第一種是句間關係任務。也就是輸入兩個句子，判斷一下兩者之間的關係。因爲前面有 CLS 位的 Token Embedding，所以可以基於 CLS，接一個 softmax，判斷一下兩個句子關係的任務。
第二種是單句分類的任務，這在自然語言推理判斷文本相似度方面比較常見。單句分類是指，對輸入的一句話，做一些單句分類。比如說我們業務上會有一些頻道識別、意圖分析，以及情感分析。
第三類是序列標註的任務，類似於 NER 不再依賴 CLS 位的序列標註，基於每個 Token 可以出一個預測，相當於完成整個序列的預測任務。
第四類是問答任務，類似於機器閱讀理解或是抽取式問答。
以上就是基於 BERT 我們能做的一些主要的下游的任務。
另外 BERT 火了之後，大家普遍認爲，因爲基於 BERT 的擴展工作會越來越多，所以會發展出一個 BERTology 的概念。我們最近審的 SIGIR、ACL 文章的時候也發現基於 BERT 擴展工作越來越多，大家做得也都越來越像。
上圖是清華大學劉知遠老師他們組裏的同學畫的 BERT 發展關係圖。可以看到早期的 ELMo、BERT、GPT 以及 ERNIE 這些名字，其實這些都是，他們起這些名字就是，基本上都是往《芝麻街》中卡通人物的名字。
我大概把這工作分了三類，因爲相關的擴展不是這篇文章的重點，所以可能比較簡略。大家如果對 BERT 的發展脈絡有興趣，可以去看一下張俊林老師《從Word Embedding 到 BERT 模型——自然語言處理中的預訓練技術發展史》這篇技術科普的文章。
學術方面，最近復旦大學的黃萱菁老師也發表了一篇關於 pre-train language model 的英文綜述論文，那篇文章對最近的工作梳理特別全面。
1.3 BERTology
下面分三部分講一下對過去 BERTology 一些工作的總結。
1.3.1 融入外部知識
ERNIE（BAIDU）：百度的 ERNIE 就是一個對 BERT 的改造。因爲 Google 中文的 BERT 是基於字的，會有一些缺陷，所以百度開始做 ERNIE，把 MLM 的任務改成掩藏一個實體，讓模型預測提前識別好的實體，增強語言模型的能力。這樣就不再是預測單字。因爲中文更多時候表達的是完整的語言，所以需要理解實體或詞。
ERNIE（Tsinghua）：清華的模型也叫 ERNIE，它不僅僅是基於簡單的實體了，還會考慮 Graph Embedding 的概念。通過 Graph Embedding 的信息，input 將其送到預訓練裏，而且還使用了 TransE 來獲取 Graph Embedding，融入到預訓練裏。
K-BERT（北大-騰訊）：此後，北大和騰訊提出了基於知識的 K-BERT。他們也是試圖將知識圖譜中的信息融入到 BERT 中。
1.3.2 更改預訓練目標
ERNIE 2.0：除了加入知識以外，ERNIE 後來也出了 2.0 版本，在訓練任務上做了更多的改進，不只是包括 MLM 和 NSP，甚至還要做一些句法結構上的預測、句子重排序、上下文等七種新的無監督任務。通過來回切換不同任務的訓練，來提高預訓練語言模型的通用能力。
RoBERTa 和 SpanBERT：另外就是影響力比較大的兩個工作，Facebook 後來做的 RoBERTa 和 SpanBERT，他們會把任務變得更難一些，除了簡單的掩碼（掩一個單詞或者一個實體），還會預測一下 Span 或者 Entity 左右的 boundary 在哪裏？這樣的話就引入了一個 SBO 的 loss。
同樣他們認爲 NSP 任務是沒什麼用的，所以就把整個 NSP 預訓練任務給去掉了。其實我們在做的時候也發現，NSP 任務的 accuracy 很快會到 98%、99%，之後很長一段時間就不再漲了，所以主要訓練的就是 MLM 任務。
另外，RoBERTa 加了更多的訓練語料，訓練的時間會更久，也有更大的 batch size，並且提出了動態的 mask 機制，取得了很好的效果。
如果大家有興趣的話，可以去找現在中文開源的兩個版本的預訓練語言模型，在上面 Fine-tune 一下，會比原生 BERT 的效果好一些。
1.3.3 更改模型結構
ALBERT：還有一類工作是修改模型結構。比如 Google 後來出的 ALBERT。之前 BERT 模型太大、太重了，很多時候對硬件的資源要求會比較大。ALBER T相當於是對原來的 BERT 模型做了一些精簡。
ELECTRA：在預訓練語言任務裏，引入了對抗學習的概念，就是 ELECTRA，也有一些最新的工作。最近也有人在 ELECTRA 上面做了一些實驗，似乎對結果有爭議。我們暫時還沒有跟進 ELECTRA 這個工作，所以也沒有結論。
美團的BERT實踐
第二部分我來介紹一下美團在實際業務上的探索和實踐，整個業務圖如上，顯示了美團具體的技術路線（編注：MT-BERT 即美團 BERT，下同）。
第一步，低精度量化實現訓練加速。最初我們是有計算平臺的，GPU 資源也比較充分，可以從頭跑預訓練。美團的業務語料也比 Google 中文純百科的數據大得多，在跑預訓練時發現訓練起來會特別慢，就嘗試了做了業界內各種低精度量化的工作，其中主要是混合精度。
開了混合精度之後，訓練速度確實有一定提高。我們和英偉達合作較多，對方推出一些新的 feature 後，我們也會及時跟進、嘗試，比如優化 Transformer 的結構，細化到一些 OP 層級的優化，通過這些來實現整個訓練的加速。
第二步，模型預訓練完成領域遷移。當我們有了一個訓練好的，通用語料預訓練語言模型之後，會在美團的整個業務領域進行遷移訓練，相當於是做一個 Domain Adaptation，當通用語料 loss 差不多收斂之後，開始加美團點評的業務語料，讓模型來完成領域遷移。
第三步，預訓練中融入知識圖譜實體信息。這一步會做一些類似之前 ERNIE 的相關工作，我們圖譜做得比較好，有一個叫“美團大腦”的餐飲娛樂知識圖譜，其中的一些實體關係已經整理得差不多了。通過前面的 EntityMask 方式，可以利用這些實體的信息。
第四步，微調支持不同類型的業務需求。有了這些預訓練語言模型之後，就可以在不同的業務上做一些嘗試，支持不同業務方的需求。這裏我簡單列了一些（見上圖），其實現在還有一些跟搜索，尤其是搜索排序業務上的合作，但是目前還沒有對外發表技術文章，美團技術人員那邊要求我們還是儘量講之前發過的工作，所以挑了一些已發表的工作，待會向大家簡單介紹一下。
2.1 數據和算力
預訓練語料的規模可見上圖。美團的客服日誌是有一些對話數據的。有很多 UGC，也就是用戶評論。去掉一些不太好的、質量比較差的評論，僅優質點評的語料我們就有 90 億規模的字，Google 中文只有 3 億，相比來看我們語料層面上其實是大很多。
有同學問到 Horovod，那其實是 Uber 開源的分佈式框架，我們是基於 TensorFlow 來做的，在多機多卡的情況下，尤其在集羣的情況下，分佈式訓練的效率會比TF原生的分佈式框架快很多。上圖中右邊不是我們數據，這是英偉達官方給的數據，可以看到在吞吐量上提的挺明顯的。
2.2 美團BERT預訓練
把預訓練工作總結一下，主要是四點：
第一部分是低精度量化，這是爲了加速訓練和推理過程。精度默認是 Float32 類型，這會有一些不必要的傳參和一些不必要的表示，會降低精度，表示成 Float16 類型，做混合精度的訓練，對訓練是有很大的加速的。
第二部分是做領域的自適應。在美團業務場景下我們有大量的語料，在原來技術上大量地對其再繼續訓練，實現從通用領域到業務領域上的遷移。
第三部分我們會把實體知識用到預訓練裏。其實這塊我們沒有像清華的 ERNIE 那樣用一些 Graph Embedding，我們發現尤其是在業務場景下，圖譜越大，關係有時候會變得稀疏，效果反而會有影響，所以我們只考慮實體。
第四部分由於涉及到業務的上線，BERT 原生 base 是 12 層，對上線的挑戰很大，所以我們爲了滿足上線的要求做了優化，包括模型的裁剪、知識蒸餾，還有一些 Fast Transformer 優化，通過多種方式實現模型的輕量化。
以上我們企業工作的概括介紹，接下來依次來展開具體講解。
2.2.1 混合精度加速
混合精度方面,我們開了 FP32 跟 FP16 的混合訓練之後,從測試來看, 最後訓練基本上是加速了兩倍多，對我們的幫助還挺大的。後來我們用 100 多張卡的集羣來跑預訓練的話，跑一個 base，大概一週之內基本上就收斂充分了。如果是 train large 的話可能也能控制到一週到兩週之間，帶來的提速還挺明顯的。
2.2.2 領域自適應
上圖是在通用 Benchmark 上跟我們自己的 Benchmark 上一些指標的對比。我選了 ERNIE 最開始用上面公開的中文的一些 Benchmark 數據集，比如 NER 的、LCQMC 語義相似度的、有情感分析、有 DBQA，以及自然語言推理的一些任務。
首先 Google BERT 訓練得並不充分，即使不換數據，不加數據,只是接着再跑一跑，效果就有提升，我們也加了一些通用語料進去，在 Google 基礎上可以看到在各個任務上都有持續的提升。
在我們自己的數據集上，比如說 Query 的意圖分類、Query 的成分分析，還有一些細粒度情感分析任務上，相比於 Google 原生 BERT 的指標明顯提高。
2.2.3 知識融入
另外就是知識融入，有同學問 K-BERT，其實我們的做法偏簡單，我們做的就是 Whole Word Masking，只不過我們的 entity 是取了圖譜的實體。
美團 O2O 場景的語料偏生活服務類，比圖實體會有一些菜，一些大家團購的團單，所以我們會對這些詞做一些遮蔽，然後用模型去預測，通過這種方式來強化預訓練語言模型對場景的自適應，或者是對任務上優化的表現。
2.2.4 模型輕量化
如上圖，爲了模型要上線需要做一些輕量化的工作（編注：MBM，是 Meituan -Mini-BERT 的縮寫），主要是兩個思路：
第一個模型裁剪，如果對性能要求不是那麼高的話，Fine-tune 的過程中就可以減少層數，結構少了，參數小了之後，推理的時間也會變小，可能在實際場景下，上線不會像 12 層那麼難。
第二個是模型蒸餾， Hinton 做了 Knowledge Distillation，後續好多人將其用到了 BERT，通過 BERT 12 層的原始模型蒸餾一個小模型出來，蒸餾的過程中可以做很多變化，比如說層數可以減，其他參數也都可以減，通過這種方式把模型變小。
我們在 Query 意圖分類任務裏直接做一個裁剪，因爲我們這邊的 Query 大部分是一些短 Query，對 12 層模型的需求沒有那麼重的情況下，我們就直接繼續裁剪了一個 4 層的小模型出來。
有同學也問到整個響應時間，比如說我們在這邊單 Query 的情況下響應時間，如果說我們用一個全尺寸的 12 層的話大概在 13 毫秒，我們做到 4 層之後就能降到 6 毫秒，基本上省了一半的時間。前面也提到還有 Fast Transformer 優化，來進一步壓縮響應時間。
美團搜索場景中的應用
前面提到了 BERT 在做下游任務時可以做很多微調，從上圖能看到主要有四大類，但是我們對機器閱讀理解任務沒有太多的業務場景，主要做了其他三類：單句分類、句間關係（句對分類）和序列標註的任務。
上圖概括了我們不同的業務場景分爲單句分類、句間關係和序列標註三種任務類型。尤其在搜索場景下，大量的需求是做響應召回，之前可能只需用 DSSM 來做，現在也想試一試基於 BERT，用 Embedding 做向量召回或者相似度的計算，所以我們基於 BERT 做一些編碼來支持語義表示的需求。
下面從單句分類、句間關係和序列標註三方面因此展開來講。
3.1 單句分類
3.1.1 情感分析
首先是單句分類，先看上圖是簡單的情感分析，一個具體的情感分析在美團和點評的場景下，UGC 佔比會很高，用戶會寫各種各樣的評價。
而且每個人給分、打星級的尺度和力度，跟他寫的內容有時候不太 match，比如有的人傾向於給高分，但他寫負分評價，這種情況下，我們就需要對句子做整句的情感極性的判斷，幫助業務方過濾負面評論，完成業務上的優化。
3.1.2 句子級情感分析
再看上圖的句子級情感分析，這塊最開始是一個雙向的 GRU 的網絡，有了 BERT 之後，我們直接基於 BERT 的 CLS 做一個 Fine-tune，上圖中的數據表明效果有明顯的提升，大多時候句子集的情感分析是需要離線，相當於 T+1 的更新就可以，這塊對線上沒有太多的要求，所以我們基本上是離線進行批量的處理，我們點評全量的不同業務場景下的情感分析的請求，來幫他們做負面內容的過濾，包括垃圾評論的識別和廣告過濾。
3.1.3 細粒度情感分析
接下來講情感分析中比較重要的工作，也就是細粒度情感分析，如果大家是點評的重度用戶，你可以發現商家點評詳情頁有一些精選點評模塊（如上圖），這個模塊有一些不同的情感標籤，比如說口味贊、裝修精美或交通不便這種稍微偏負面的標籤，用戶可以參考這些標籤，提前做決策是否要去這家店消費。
這就涉及到需要對用戶很長的一段評論，做很細的情感分析，學術界的定義是 Aspect-based Sentiment Analysis，我需要判斷評論在每個 aspect 上，是正向、負向，還是中立的。如果能把一些標籤識別得很好，用戶點了這個具體的標籤，就能把相應的評論看一下，比如點“空間小”的標籤，有一些相關的評論能出來，這對用戶做選店，消費等決策有很大的幫助。
上圖是 2018 年美團跟創新工廠聯合舉辦的 AI CHALLENGER 比賽，我們把這個數據放出去過，爲比賽做單獨的 Track。
我們的數據集的成本其實挺高，當時爲了比賽，公司出錢請人去做很細粒度的標註。這塊是人工定義好的，是偏業務層面的 aspect，主要維度還是業務方來定，因爲他們有專業知識。
比如美食，要看用戶會關注哪些維度，有地點、商家服務、價格、環境、菜是否好喫，當時大概有 20 個維度，後續也一直在擴充，維度會越來越豐富。這其實是一個四分類任務，對每個點評需要判斷在 aspect 上來判斷是正面、負面或者中性，還是壓根就沒有提到，這也是一個單句分類任務。
上圖可以看到我們基於 BERT 搞了一個多任務學習的框架，現在做情感分析沒太考慮圖片的問題，圖片會有一些多模態的問題，但是我們現在有同學在做多模態知識圖譜，就把圖片的信息考慮進去了。
我們回來說細粒度情感分析網絡結構，有 20 個分類，不同的 aspect 會有分類。和前面句子情感分析一樣，之前也是按雙向 GRU 網絡來做，後來我們把圖示中間部分整個換成基於 BERT 做出來的 Token Embedding，相當於是對 20 個 aspect classifier 做一個分類，這塊我們考慮做聯合訓練，可以部分減輕不同 aspect 上數據分佈不均勻的問題。
另外還有一個好處，比如說這 20 個 aspect 有足夠的數據每個都能做好，但當新加一個業務的 aspect 進來，初期業務方只能標小量的數據，有了 BERT 之後，結合多任務學習的框架，即使有小量的數據，從上圖能看到，我們也能做到基本比單獨訓練好很多的效果。
上圖是我們早期的一些工作。BERT 剛出來時，好多人在思考如何應用，應用方式有兩種，一種是 Feature-based，就像我們之前用的是 Word2Vec 一樣，直接 Embedding 出來，加到之前的任務的網絡裏。
第二部分不論直接基於 BERT CLS 也好，基於後邊 Token Embedding 也好，都可以做一個Fine-tune，到底哪種方式好？我們當時做了一個詳細的實驗，尤其在 ABSA 任務上，也就是細粒度情感分析任務，我們對比了之前比較主流的兩種 ABSA 的方案，這是在 2016 年、2017 年兩個影響力比較大的工作。
我們做了各種對比實驗，基本上來看，在 ABSA 任務上效果比較好的還是推薦直接做 Fine-tune。Fine-tune 的時候我們試了基於 CLS 直接分類，也試了基於後邊 Token Embedding 的方式來做。實際來看還是基於 Token Embedding 直接做 Fine-tune，在我們這個場景下效果是最好的。
可能有人會問聯合訓練怎麼做，這塊其實有很多做法，我們做簡單的，20 個領域可以加一個超參，設置不同的權重再放到一起，通過數據驅動的方式來學權重。
還有另外一種方式，因爲不同 aspect 之間的關聯性不太一樣的，可以考慮不同 aspect 之間的一些 relation。然後可以做一些新的正則項，或者是手動加一些權重加進去，效果就會提升。我們當時在中間又加了一層 Attention 網絡，讓它自己去學不同的權重。因爲每個 aspect 數據量不太一樣，所以通過機制來學不同的權重。
3.1.4 Query意圖識別
接下來看單句分類關於 Query 意圖識別的應用。Query 意圖識別在美團和點評兩側的搜索裏是一個很重的模塊。這涉及到不同業務流量的劃分，比如如果本來是外賣的用戶請求，你把它劃分成了旅遊或者是到店的請求的話，兩個業務方都會來找你，這就比較麻煩。
所以我們對搜索的 Query 意圖會有多分類的需求，上圖顯示了我們當時用裁剪後的 BERT 對比之前線上的 SVM 或者是一些規則的模型在指標上的提升。其中有一些是上線 AB 的指標，有些是人工抽檢指標。可以看到在 Query 短的情況下， BERT 相比傳統模型是有很大的優勢的。
3.1.5 推薦理由場景化分類
另外一個應用是推薦理由的場景化分類。大家如果用過點評和美團，可以看到不同的商家 POI 會有一些推薦理由或者可解釋理由。其作用是用戶搜到一個結果之後，要顯示出這家店有哪些特色？爲什麼會被召回？或者會有一些亮點推薦。
比如有一家店，如果在一些推薦場景下沒有用 Query，把這個店推薦給用戶，可能需要一條理由，比如這家店的特色是什麼，然後就是在不同的場景下，需要給出相應的推薦理由。
另外與 Query 相關或與用戶相關，我們會做一些個性理由推送。如果大家是美團和點評的資深用戶，肯定見過各種各樣的推薦理由。這是因爲數據的主要來源是用戶的評論，不管是抽取、基於模板匹配、基於搜索、都依賴於整個的 UGC 的供給。
不同的業務方，需要從推薦理由本身很大的推薦理由池中做細分。比如同樣是關於一家店的推薦理由，在點評上和在美團外賣的兩個場景下，需求不太一樣，例如在點評上搜索美食，推薦理由可以是關於這家店的服務態度怎麼樣、地理位置偏不偏、好不好找等等。
但是在外賣的場景下，用戶不太會在意這個店在哪？服務好不好？主要是看配送速度、菜的口味怎麼樣？這就涉及到了場景的細分。
給定一個關於這個店的推薦理由，我們需要做一種業務場景的區分，這其實也是單句分類 BERT 的應用場景。包括酒店推薦，我們也會有一些推薦理由，細分到酒店是否有自己的特色，刪除不相關的推薦理由，這樣就不會報 bad case。
前面提到的推薦理由，也是一個分類任務，可以理解爲關於一家店有很多的推薦理由，但是比如說這家店出現在外賣的場景下，推薦理由如果不是關於配送關於美食，出現了其他理由，比如說服務，這就是一個負例，需要把它從我的池子裏刪掉，這樣就不會報 bad case 出來。
3.2 句間關係-Query改寫語義一致性檢測
下面介紹一下美團在句間關係場景下與點評合作的關於 Query 語義一致性檢測的業務。
Query 改寫是搜索 Query 中很重要的組成部分。尤其像美團生活服務類業務，更加依賴 Query 改寫，因爲不知道用戶會搜什麼關鍵詞。比如“游泳”，用戶就可能會搜“小孩游水”、“兒童游泳”；再比如“自行車”，由於南北方言的差異，北方說“自行車”，南方就可能會說“單車”，本質上搜索的是同一事物。
Query Doc 自來有一些語義上的 gap，會產生上下位詞的概念。比如“理髮”的搜索，就會有“剪髮”、“造型”和“剪頭”。
另外關於一詞多義，比如“結婚照”的搜索，可能是“婚紗照”，也可能是“證件照”，這兩個關鍵詞本質是不太一樣的。如果改錯模型的話，負面影響會特別大，比如將原本正確的例子改成錯誤的，導致處理的結果完全不相關，是很惡劣的 bad case。所以生成改寫模型之後，需要對語義是否一致進行檢測。
這也是能夠應用 BERT 的場景。比如上圖的場景中，“聲樂培訓”、“學唱歌”兩個詞是改寫的一個 pair，經過人工 review 確認正確以後，作爲訓練樣本對 BERT 做分類的模型進行訓練。
所有改寫的 pair 上線之前，都需要經過訓練好的 BERT 模型打分，只有模型判對，確認是同一個語義，才認爲這是可以上線且符合線上要求的正確改寫。如果模型判錯，就可以直接去掉了。這樣就可以避免線上出現很惡劣的改寫的 case。
3.3 序列標註-Query成分分析
最後來講講序列標註：Query 成分分析，成分分析只是美團內部的叫法，這其實是一個 NER 的任務，可以應用於酒店搜索的場景中。酒店搜索場景下，有時候用戶輸入的 Query 具有一些複合目的，對 Query 做成分分析，後續可以進行一些指導召回的操作。
如右圖，搜索的是“北新涇五星級”，這裏有兩個意圖：第一，北新涇是地標，搜索的是北新涇附近的酒店；第二，五星級是對酒店星級的要求。右圖呈現的結果其實是一個 bad case，“北新涇五星級”，地理位置是對的，但是呈現了很多經濟型的酒店，與“五星級”不符。
所以需要對 Query 做細粒度成分識別，也就是進行 NER 序列標註，有時還需要識別核心成分。比如電商或者是 O2O 的用戶搜索很隨意，可能只是關鍵詞的堆砌，這種情況下就需要識別用戶搜索的核心詞，如果整個 Query 串召回沒有結果，就需要進行丟詞，只保留用戶搜索的核心成分，然後做二次召回，看是否能夠召回一些相關的結果。
我們基於 BERT 做了一個 NER 任務。之前大家做基於 BERT 的 NER 任務，效果最好的應該就是 BiLSTM 上面拼 CRF 的方法。
我們直接基於中文字的BERT模型做識別，前面對 BME 的標籤識別，可以看到一些 POI，比如上圖中的一些城市。其實 BERT 直接 Token Embedding，softmax就可以進行判斷了，從 benchmark 指標上來看，效果差不多。
我們也試過 BERT 直接拼 CRF，指標表現確實會好一些。這裏可以和大家分享一個點：如果直接 softmax，前一步相當於是每個 Token Embedding 進行預測，看似整體的準確率高，但是分析抽檢的時候可能會出現標籤跳變的 case，比如本來應該是 BME， E 沒識別出來就有可能識別成下一個標籤了，這樣整個的識別不完整。而如果加了 CRF，bad case 就會大大減少。
這是有關序列標註上的任務。前面講的這些任務，基本上是我們 2019 年與搜索的業務方的合作，進行的一些嘗試。
3.4 MT-BERT一站式訓練和推理平臺
另外再講講下美團的一站式訓練和推理平臺。由於我們組人力資源有限，我們和每個業務部分都要對接需求、對接數據需求， 還要幫助他們訓練模型，做 benchmark 測試，最後交付，工作量比較大，對算法人力的要求特別高。
業務方的，包括算法工程師，不只是想優化業務算法，也想嘗試 BERT 的優勢，但是由於涉及到預訓練語言模型核心的代碼與模型，沒辦法減輕任務量。
後來我們就與公司工程團隊合作推出一站式訓練和推理平臺。好多公司應該已經有了自己的機器學習平臺，類似於阿里有 PAI，百度有 PaddlePaddle 機器學習平臺，美團也有一套自己的機器學習平臺，我們與自己的機器平臺合作，將預訓練好語言模型上傳，有 12 層的全尺寸的模型，也有蒸餾好的 6 層小模型，甚至也支持基於這些模型進行層數的裁剪。
使用者只需要上傳自己的業務數據，點幾個按鈕，就可以對自己的具體任務做一定 Fine-tune 比如平臺支持一些句間關係的任務、單句分類的任務、序列標註任務等等。
我們有這個平臺之後，相當於是對整個業務層面的支持，也爲算法同學減輕壓力、提高人力效率。
上圖是早期相關的一些工作，大家可以直接去美團技術團隊的微信公衆號上找我們技術文章，文章敘述得比我今天講得更加全面。
Q&A環節
Q：數據標註大概多少？
A：如果是問關於情感分析的部分，那個數據集是爲了 AI CHALLENGER 比賽公司花錢專門標註的一批數據，數據量特別大。如果只想問不同任務下需要標多少數據才能跑這個 Fine-tune，就要看業務場景了，比較難的任務，可能需要多標註一些，比較簡單的任務，可能少標幾千條，效果也還能過得去，也能支持。
Q：模型蒸餾具體怎麼做？
A：模型蒸餾的部分可以看一下 Hinton 那篇關於 Knowledge distillation 知識蒸餾的文章。簡言之，可以把 BERT 看作 teacher model，目標網絡就是 student model。同樣的訓練的數據，大模型是怎麼預測的，小模型也學着預測 distribution。這樣就可以把大模型的能力遷移到小模型上去。
Q：蒸餾到什麼模型?
A：我們是蒸餾到不同的小層數上，小 BERT 模型，但現在也有一些工作：把 BERT 蒸餾成一些小的 CNN 模型或者是其他的一些模型也是可以的。
Q：蒸餾只在下游任務做嗎？
A：蒸餾不只是在下游任務進行，預訓練的時候也可以進行，我們就有一個例子是直接在預訓練裏開了蒸餾，相當於直接預訓練一個 6 層的小模型出來，後續不同的任務，可以直接基於 6 層的小模型進行 Fine-tune 的。
Q：蒸餾模型的泛化性能?
A：這個我們沒有深入考慮，因爲不同業務場景是具體到我們的任務上了，一旦要做蒸餾、裁剪，就已經是在考慮模型上線了，也就不太考慮泛化性，而是針對具體任務單獨優化一套模型。
Q：語義模型的訓練數據的覆蓋度是什麼樣的？
A：這個問題，我不是特別清楚，因爲訓練數據主要還是和業務方合作，由他們提供。我不明白你說的訓練的覆蓋度是什麼？是指覆蓋線上流量嗎？如果只覆蓋線上流量的話，我們就用來做訓練數據，基本上是按流量的分佈採的，比如不同的業務流量上，我們會根據佔比採一些，來實現整個業務場景的覆蓋。
Q：搜索的意圖識別是分類的識別嗎？
A：對，搜索的意圖識別主要就是分類的識別，但也會有一些類目的預測，這個工作我們也在做。這些信號我剛纔也提到了，在美團和點評兩邊的搜索中 Query understanding 是很大的一個模塊，這個模塊會涉及到很多信號，也就是意圖識別、類目預測，這些詞權，都需要做。
Q：工程化的加速？
A：加速主要分兩部分，一個是剛纔提到的混合精度，另一個就是 FastTransformer 的優化，Google release 的 BERT 中使用的還是原來的 Transformer，英偉達自己的 FastTransform，相當於是在 OP 層面做一些優化，如果基於英偉達的 Transform 實現 BERT，推理速度會有一些提升。
Q：關於實習招聘跟正式員工招聘？
A：大家可以關注一下美團技術團隊的公衆號，應該是有投遞郵箱，如果感興趣的話就直接走郵箱投遞就行了。
Q：蒸餾和 ALBERT 比較？
A：蒸餾沒有和 ALBERT 比，我們其實後來沒再嘗試 ALBERT，因爲我們大多還是做一些業務的支持，就我今天主要介紹那些工作，後續的我們就沒太 follow 了，沒有自己去實現過。
Q：搜索可能是剛纔 Query 的意圖分類，爲什麼不是一些相似度？
A：其實是有相似度的任務的，但是我今天的 talk 沒列出來，因爲我們還在嘗試，關於 BERT 怎麼在搜索，尤其在 relevance model 使用，也是最近研究的一個熱點，在 SIGIR 相關的一些會上，最近的文章也挺多的。但從我們自己的嘗試來看，還是挺難的。
Google 之前發博客說，他們用 BERT 改善了 10% 的線上搜索流量，但其實是用到了精選摘要的頻道，也就是 Featured Snippets，比如搜索天爲什麼是藍的，出來的第一個結果，會把相關文章裏內容的回答摘出來，其實就可以用 BERT 優化，相當於是做機器閱讀理解任務。但是我們的場景不太一樣，所以我們就沒太做機器閱讀理解的任務。我們預訓練 BERT 其實是從頭開始訓練的。
Q：預訓練有多少卡？
A：我們公司有那種計算平臺集羣，大概應該是 100 多張卡，100 張卡以上，如果只是 train 一個 base 的話會很快,因爲你看訓練曲線，其實三四天就收斂差不多了，然後要是跑一週的話，後三到四天，曲線就是緩慢的上升。
基本上是一週內能 train 一個比較好的模型，large 的話時間會長一些，可能得一週半到兩週之間，我們這邊也跑過 large，但是 large 有一個問題在於不同任務上，large 模型有時候會表現得不太穩定，所以我們儘可能是應用在下游任務。
Q：能在其他數據集上微調嗎？
A：可以的，訓練完可以用數據集微調，但要看數據量多大。如果是無監督的語料，其實不叫微調，那其實就是做一個 continue training，這其實在早期的 NLP 任務裏也有。比如想做一個領域的遷移，訓練過程中可以分 batch，整體上風險會比較大。慢慢把新的數據集加進去，作爲一種領域的遷移，作爲 continue training 是可以的。
Q：推薦理由?
A：剛纔可能講得有點快。我們推薦理由的分類，本質上是對於評論的分類，但是推薦理由我們已經針對每個商家做好了，會有各種方式，比如抽取式、生成式，也有模板類型的。比如線上的索引，就有幾百條推薦理由可以用。
到具體的推薦場景下或者到外賣的情況下，每個場景又不太一樣，所以需要對推薦理由做一些針對業務場景的分類，也就是一個單句分類的任務。
Q：蒸餾的 performance 會下降嗎？
A：會，在 benchmark 上基本會有一到兩個百分點的下降，但是具體任務上能保持原模型 98% 左右的性能。
Q：微調有什麼 tricks？
A：微調好像還真沒有太多特別的 tricks，我覺得具體任務具體分析，可能需要看一下，一般可能就是 epoch 別跑太多，一般 2 到 3 個，看微調的數據量有多大，可以調一調 learning rate，不同任務上可能對 learningrate 敏感度不太一樣。
Q：知識圖譜在美團業務的應用？
A：可以看下美團技術團隊的公衆號，之前王仲遠老師有一篇名是《美團大腦》的文章，對美團知識圖譜在業務上的應用進行了比較全面的介紹。我們現在 BERT 的工作裏沒有用圖像，基本上還是純文本。
Q：細粒度情感分類怎麼做的？
A：細粒度情感分類，在我們的場景下是對每句話做一個多分類。
Q：多 loss 訓練?
A：因爲我們會有多個 aspect 的分類，比如有 10 個 aspect category，那就是做 10 個 aspectcategory 的多分類任務，最簡單的多任務學習，就是把 loss 簡單相加。直接這樣 train 的話，效果比單獨做有提升。
但是有個問題，不同 aspect 可能缺的數據不太一樣，這樣的話一些數據比較少的 aspect 任務可能會被帶偏，所以這裏需要做一些 loss 上的約束或者說做一些優化。其實有很多可挖掘的部分，不同 aspect 之間關聯程度這塊可以做一些考慮和嘗試。
Q：句向量可以用 BERT 做嗎？
A：可以的，我們最近也在嘗試。但是有一個問題在於，BERT 的原生向量維度比較高，會有 768 維。如果Doc量特別大，尤其是在工業的場景下，億量級 Doc 的話，用 Faiss 也好，用其他也好，建索引的成本比較高。要是做向量召回，或是做向量相似度計算的話，EMNLP2019 有一篇關於 Sentence-BERT 的文章在做這方面的嘗試，可以看一下。另外可以考慮通過蒸餾或是其他的方式，把向量維度減下來，這樣可能上線實際用起來效果會比較好。
Q：GCN 的推薦場景？
A：有其他團隊在做，這方面後續應該也會有技術文章發到美團技術團隊的公衆號上，可以關注一下。
Q：如何融合圖像數據到 BERT 裏邊？
A：我們現在還沒做到這個層面，但是有很多相關的研究，可以去關注一下。現在做多模態的預訓練語言模型，會把視覺的信號用進去，主要還是視頻和圖片的信息，這方面已經有好多論文可以去找一下。
Q：Query 太短，BERT 效果會不會好？
A：在我們的場景下對意圖做分類，效果還挺好的，而且把 BERT 裁減到 4 層以後，還會比一些傳統的方法的效果更好。
Q：低星好評，高星差評，具體是如何處理的？
A：我覺得這個問題是涉及到業務層面的策略了，其實我們沒太考慮這個問題，主要還是對用戶的評論內容，做情感分析的分類，具體怎麼展示，這可能是業務層面上的考慮。
Q：數據少的 aspectloss 怎麼約束？
A：其實可以做一些簡單的實驗，比如數據量少的話，希望模型多學到一點東西，其實是把它 loss scale 一下，儘可能在多任務裏，權重會高一些，看看這樣有沒有效果。
Q：BERT 太敏感？
A：對，這個問題確實是存在的，而且也不只是 BERT 的問題，可能現在很多的深度學習模型都存在這個問題。做一些簡單詞替換的時候，分類結果或者是一些預測結果就產生了變化，這其實也是一個研究方向，怎麼樣提高現在預訓練語言模型的魯棒性、穩定性。
Q：多任務裏面，多 loss 相加?
A：我們其實不是簡單的相加，剛纔的分享中也展示了一下，我們的模型中間會有一個 attention 層，去學不同 aspect category 之間的關係，由此來調節不同的時間權重，我們的 aspect-category 是預先定義好的，也就是業務上需要的 aspect。
Q：地圖信息團隊？
A：這我還不太確定，因爲現在我們的模型已經在機器學習平臺上面了，所以不同的業務團隊都可以使用那個模型去做一些微調，我不確定其他團隊有沒有在用。
Q：關於 target-oriented 和 aspectterm
A：target-oriented 和 aspect term 應該都是細粒度情感分析。如果細分的話，我們做的其實是叫作 aspect-category 的任務，你說的 target-oriented 和 aspectterm，是更細化了，我們現在的數據裏其實是沒有標 target 和 term 的，所以任務不太一樣。
Q：用 BERT 來做情感分類的性價比高？
A：我覺得從兩方面考慮，比如做具體的任務，直接用 BERT 進行 Fine-tune 的話，事實上效果已經比好多傳統模型好了，有一個這麼好的 baseline，尤其在工業界做算法，是可以節省很多精力進而去做一些業務上的深入思考。以前我們需要嘗試各種模型的做法時間成本是很高的。所以看思考這個問題的角度，如果說對硬件資源的消耗，確實是比傳統的模型高一些，但是 BERT 尤其能幫忙算法工程師節約大量的時間成本，從這一點來看，我覺得這個投入產出比是值得的。
Q：BERT 預測都非常自信，所有的預測正負都分得特別開。
A：我們也發現 BERT 預測結果會直接分到 0.99，差的就零點零零幾，但是在具體業務上應用的話，有時候需要卡一些閾值，做一些處理。這方面我們其實是在與搜索合作，尤其關於排序任務上的嘗試，會發現有這個問題，我們其實是針對具體的任務去做不同 loss，因爲進行簡單 Fine-tune 的話，是基於分類的 pointwise loss，但是如果是做排序，有時候會有一種 pairwise loss 或者需要考慮一些 listwise 的 loss，如果你能把這些 loss 改進一下加進去，其實是能夠部分解決分類平面分得特別開的問題。
Q：具體的 aspect 標註數據？
A：具體量級我沒有特別清晰的印象，句子維度應可能至少有 10 萬或是 20 萬，針對這個數據我們也在準備一個論文，後續可能會開放，也能下載，大家到時候可以關注一下。
Q：CPU 能達到線上十來毫秒的速度嗎？
A：線上十來毫秒的速度，不是 CPU，那都是 GPU，CPU 沒這麼快。
Q：BERT 怎麼使用用戶行爲數據？
A:這個問題其實可以關注一下搜狗搜索的一些工作，他們之前應該也有分享過：把前後的用戶點擊拼成一個序列來做，有點類似於現在做序列推薦的任務。
Q：關於 WeakSupervision
A：不知道 supervision 具體是指什麼，我們現在有好多樣本就是Distant Supervision的，我們會從用戶的點擊數據裏取出一些弱監督的訓練樣本。
更多閱讀
#投 稿 通 道#
讓你的論文被更多人看到
如何才能讓更多的優質內容以更短路徑到達讀者羣體，縮短讀者尋找優質內容的成本呢？答案就是：你不認識的人。
總有一些你不認識的人，知道你想知道的東西。PaperWeekly 或許可以成爲一座橋樑，促使不同背景、不同方向的學者和學術靈感相互碰撞，迸發出更多的可能性。
PaperWeekly 鼓勵高校實驗室或個人，在我們的平臺上分享各類優質內容，可以是最新論文解讀，也可以是學習心得或技術乾貨。我們的目的只有一個，讓知識真正流動起來。
???? 來稿標準：
• 稿件確係個人原創作品，來稿需註明作者個人信息（姓名+學校/工作單位+學歷/職位+研究方向）
• 如果文章並非首發，請在投稿時提醒並附上所有已發佈鏈接
• PaperWeekly 默認每篇文章都是首發，均會添加“原創”標誌
???? 投稿郵箱：
• 投稿郵箱：[email protected]
• 所有文章配圖，請單獨在附件中發送
• 請留下即時聯繫方式（微信或手機），以便我們在編輯發佈時和作者溝通
????
現在，在「知乎」也能找到我們了
進入知乎首頁搜索「PaperWeekly」
點擊「關注」訂閱我們的專欄吧
關於PaperWeekly
PaperWeekly 是一個推薦、解讀、討論、報道人工智能前沿論文成果的學術平臺。如果你研究或從事 AI 領域，歡迎在公衆號後臺點擊「交流羣」，小助手將把你帶入 PaperWeekly 的交流羣裏。
