百度搜尋深度學習模型業務及最佳化實踐

如下圖所示，我們問一個河流的長度，搜尋結果精確返回了河流的長度，而不是返回有答案資訊的網頁連結讓使用者依次查詢。能做到這樣，是深度學習起著至關重要的作用，模型從語料中尋找、判斷、擷取準確答案，然後呈現給使用者。此外，使用者還能輸入圖片並詢問圖片的內容是什麼。

縱觀搜尋的發展的歷程，從最初的人工特徵，到淺層的機器學習模型，再到不斷加深的深度學習模型，我們對使用者需求和候選內容的理解能力是持續的提升的，能力提升到一定程度就會影響架構的變化。近幾年，架構最大的變化之一，是大規模的深層知識學習模型和系統的落地。

傳統的檢索的通路的思路，是倒排索引。我們通常理解的索引，是先有文字，再去統計文字中關鍵詞的出現頻次，這是正排。那倒排是什麼？是使用者搜了一個詞，我們去看它出現在哪些文字中。但是在中文語境中，一個句子通常會因為改變一兩個字或詞，整個句子的語義會發生劇烈的變化，比如"山桃紅了" vs "山桃花紅了"，前者描述的是山桃果實的顏色，後者指的是山桃花的顏色。

倒排檢索很難捕捉到這種變化，語義索引就很擅長解決這類問題。

那麼，語義索引是什麼？我們將使用者的query做嵌入表示，對映到一個向量（128/256維）中，然後對全網內容進行檢索、embedding對映至向量空間。我們可以把這個向量空間看作語義空間，在向量空間中越接近，語義就越近似，也就能反饋使用者更加滿意的結果。

很多時候，搜尋和推薦有一定的共性，但也有諸多不同，這裡我對比著講。

搜尋的語義理解模型中，transform 類的結構被廣泛應用，文字作為特徵，詞表範圍一般<20萬，模型深度深，需要的運算量大。

而推薦模型，涉及大量使用者及物料特徵、互動特徵，詞表大小大到TB級，具有寬而較淺的特點。

搜尋模型特點：

△圖片來源：Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[J]. Advances in neural information processing systems, 2017, 30.

CTR/推薦模型特點：

△ctr經典模型 Wide&Deep示意圖 (圖片來源：Cheng H T, Koc L, Harmsen J, et al. Wide & deep learning for recommender systems[C])

語義檢索通路主要包括離線通路（下圖左側）和線上通路（下圖右側）。我們可以看到無論是離線還是線上，都用到了深度學習模型ERNIE。

△圖片來源：Liu Y, Lu W, Cheng S, et al. Pre-trained language model for web-scale retrieval in baidu search[C]

離線側，全網文字數量非常多，都需要檢索到我們的庫中做embedding，這個工作需要離線通路提前算好，存在資料庫中。

搜尋線上推理系統，是根據使用者query進行實時計算並返回結果，模型主要分為三部分：需求分析/query改寫、相關性/排序、分類。

（1）需求分析/query改寫，是透過深度學習模型返回一個語義相近的query

當使用者問：“熔斷是什麼意思啊？” 其中含有口語化表達，透過呼叫深度模型返回一個語義相近的query：“熔斷是什麼意思”，使召回的答案更豐富、準確。

（2）相關性/排序，需要用到粗排/精排模型，將使用者query與title相關的網頁資訊做拼接，讓模型計算相關性，得出的分數決定了返回使用者結果時的排名。

當使用者問：“西安旅遊必去景點攻略”，模型給出的分數越高，就代表網頁和使用者需求越接近，返回“float：0.876”。

（3）分類，即透過模型進行型別識別，返回型別。

當使用者問：“周杰倫 稻香” ，模型識別出這是一個音樂需求，我們就可以為使用者展現音樂型別的卡片。

搜尋離線系統，用於處理時效性不高的任務。搜尋的使用者使用會呈現明顯的波峰波谷形態，尤其是後半夜使用者流量非常低，冗餘的資源就可以進行離線計算，將計算結果存入語料庫。比如文章最開始提到的珠峰海拔的問題，深度模型可以直接從語料庫中抽取答案。還有一些是純粹的離線任務，我們採用批次建庫、批次刷庫的形式拿到索引，並儲存到資料庫中。

搜尋系統中非常多的任務都會用到深度模型，我們希望各使用者、各業務方都能用同一套API來呼叫深度模型，這部分就是我們做的工作了。

在深度推理系統之後，它的後端由於大家模型種類、大小、尺寸都不一樣，包括異構算力，都需要我們把深度模型推理服務部署上去。

那麼，如果併發量變大，我們如何做到均勻排程、讓系統穩定可靠呢？

首先是均勻排程。下圖為公司內部模型部署的一種典型方案，我們每個人拿到的計算機叫做單機，但是單機粒度較大需要進行虛擬化，切分出更小的粒度來提供服務、做擴縮容等，我們稱作例項。

再者是穩定可靠。架構領域有一個非常有名說法，說“架構工作就是在不穩定的硬體之上構建一套穩定的系統”。當我們的例項和機器數量變得多時，某個硬體出故障其實就成為必然現象了，如何及時檢測故障並遷移，保證使用者體驗，就是我們需要保障的事情。

此外，我們還希望整個推理系統的速度足夠快，有足夠高的吞吐，儘可能降低資源成本。如下圖所示，推理系統的請求由brpc輸入，brpc是在公司內部各模組間透過網路呼叫的，可以讓使用者用類似本地函式的呼叫方式呼叫其他服務。系統收到請求後會識別inferfence request裡的資訊，包括要訪問什麼模型、訪問什麼版本、輸入了什麼等，之後進入處理流水線。

處理流水線包含四個部分：

以上是超大規模線上推理系統的概況。

我們的深度模型最佳化，其實是針對某些瓶頸去做最佳化。GPU模型通常面臨著三類瓶頸：IO瓶頸、CPU瓶頸、GPU瓶頸。如下圖所示，訓練的整個過程包括：讀取資料、前向推理、反向傳播，我們推理過程可以拆分成讀取資料、前向推理兩部分。

模型最佳化工作分為三個方面：訓練、推理和小型化。

3.2.1 訓練最佳化

（1）資料讀取

我們針對場景做資料讀取的最佳化。原因是在模型不斷增大後，我們不斷的嘗試將模型切分，在單機多卡上訓練，甚至在多機上訓練，不同的切分方式也會導致很多時候資料處理並沒有對場景做深度適配。

無論用paddle框架或是其他，都會提供很多OP，這是想實現一個功能，就可以用不同的op來達到同樣的功能，這為使用者帶來非常高的自由度。但是不同的op在實際的執行過程中有低效和高效之分的，所以我們一部分工作就是去識別並替換成更高效的實現。

3.2.2 推理最佳化

除了kernel融合/開發、等價替換等，推理最佳化還包括GPU/CPU負載均衡、模型結構剪裁。

（1）GPU/CPU負載均衡

在推理場景，CPU的工作量並不太多，包括預處理、kernel lunch和後處理，我們可以把一些 GPU並不擅長的工作放在CPU執行，包括對訪存比較高但運算量較少的op，放在CPU進行更合理。

（2）模型結構剪裁

3.2.3 模型小型化

小型化分為三個方向：蒸餾、量化、剪枝

（1）服務化蒸餾

蒸餾是一種模型壓縮技術，將一個複雜的、大型的模型 (teacher) 的知識轉移到另一個更小、更簡單的模型(student)中。小模型可以與大模型保持相似的訓練結果。

在實際業務場景中，隨著teacher數量不斷增長，蒸餾過程無法並行，teacher模型前向推理是序列的且耗時佔比會越來越高，成為主要瓶頸。所以從工程師的視角，我們將 teacher放在異構的算力上去推理，一方面將序列的teacher前向推理並行化，另一方面可以將閒置的資源利用起來，如下圖所示，整體加速蒸餾效率。

（2）量化

（3）剪枝