【51CTO.com原創(chuàng)稿件】 推薦系統(tǒng)的核心排序算法已經(jīng)從傳統(tǒng)的 LR、GBDT 等模型進(jìn)化到了 Deep&Wide、DeepFM、PNN 等若干深度模型和傳統(tǒng)模型相結(jié)合的階段。

如何結(jié)合各個(gè)業(yè)務(wù)數(shù)據(jù)的特點(diǎn)，設(shè)計(jì)合適的深度推薦算法，同時(shí)設(shè)計(jì)合理的架構(gòu)保證深度學(xué)習(xí)算法的穩(wěn)定運(yùn)行，成為企業(yè)在推動(dòng)基于深度學(xué)習(xí)的推薦系統(tǒng)落地的難點(diǎn)。

2018 年 11 月 30 日-12 月 1 日，由 51CTO 主辦的 WOT 全球人工智能技術(shù)峰會(huì)在北京粵財(cái) JW 萬豪酒店隆重舉行。

本次峰會(huì)以人工智能為主題，360 人工智能研究院的技術(shù)經(jīng)理張康在推薦搜索專場與來賓分享"基于深度學(xué)習(xí)的推薦系統(tǒng)在 360 的應(yīng)用"的主題演講，為大家詳細(xì)闡述在 360 的各種場景下，基于深度學(xué)習(xí)的推薦系統(tǒng)的各種應(yīng)用。

本次分享分為如下兩大部分：

• 推薦系統(tǒng)相關(guān)算法***研究進(jìn)展
• 深度推薦系統(tǒng)在 360 的應(yīng)用實(shí)踐

推薦系統(tǒng)相關(guān)算法***研究進(jìn)展

在介紹應(yīng)用系統(tǒng)之前，首先讓我們從抽象的層次上理解一下，在圖像領(lǐng)域的相關(guān)概念。

上圖是我們對推薦系統(tǒng)的一個(gè)分層與抽象。在頂層，我們可以理解為是一個(gè)函數(shù)。

其中 U 代表用戶、I 代表需要推薦的商品、C 代表上下文、Y 則是我們需要優(yōu)化的目標(biāo)。

當(dāng)然，不同的應(yīng)用場景，Y 的取值會(huì)有一定的差異。如果我們的目標(biāo)是點(diǎn)擊率的話，那么 Y 的取值就是 0 和 1。

而如果我們要預(yù)估某個(gè)時(shí)長的話，那么 Y 的取值就變成了實(shí)數(shù)，它對應(yīng)的就是某個(gè)回歸問題。可見，根據(jù)不同的場景，定義好 Y 是至關(guān)重要的。

如果是從算法人員的角度出發(fā)，他們會(huì)認(rèn)為定義 Y、和對 F 求解的優(yōu)化是非常重要的。

而在業(yè)務(wù)方的那些做產(chǎn)品的人看來，U 的反饋則更為重要，如果出現(xiàn)用戶投訴的話，那么該算法也就失敗了。

另外，他們也會(huì)關(guān)注 I。由于 I 的背后實(shí)際上關(guān)聯(lián)的是商家，那么同樣要避免出現(xiàn)用戶對于 I 的抱怨。可見，不同角色對于此公式的關(guān)注點(diǎn)是不相同的。

在上面抽象圖的中間，我們一般會(huì)把頂層簡單的數(shù)學(xué)公式拆分成三個(gè)不同的算法模塊：

• 召回（Recall）
• 排序（Rank）
• 策略（或稱重排序 Rerank）

目前市面上的一些工業(yè)領(lǐng)域和學(xué)術(shù)界的論文，大部分會(huì)重點(diǎn)研究和討論 Rank，畢竟 Rank 是非常重要的。

而對于那些針對 Recall 和 Rerank 的技術(shù)而言，由于它們并不適合被抽象成為一個(gè)統(tǒng)一的理論架構(gòu)，因此相關(guān)的論文也不多。后面我們會(huì)重點(diǎn)討論有關(guān)召回部分的內(nèi)容。

經(jīng)歷了上面兩個(gè)抽象層次，圖中的底層就需要讓推薦系統(tǒng)服務(wù)于“線上”了。

它由五大關(guān)鍵部分所組成：

• ETL 對數(shù)據(jù)的清洗。不同于那些已經(jīng)準(zhǔn)備好了數(shù)據(jù)集的傳統(tǒng)競賽，我們面臨的是在真實(shí)的線上場景中所產(chǎn)生的日志數(shù)據(jù)，它們不但“臟”，而且體量非常大。

因此，我們需要有一個(gè)對應(yīng)的數(shù)據(jù)清洗場景，以緩解系統(tǒng)的處置壓力。

• Server 模塊。針對各種排序和召回的模型場景，我們需要提供實(shí)時(shí)的服務(wù)。

因此服務(wù)端不但需要具有高性能的計(jì)算能力，同時(shí)也需要我們的架構(gòu)能夠應(yīng)對大規(guī)模的深度學(xué)習(xí)與計(jì)算。如有必要，還可能會(huì)用到 GPU 等硬件。

• Platform。這里主要是指深度學(xué)習(xí)或者機(jī)器學(xué)習(xí)的訓(xùn)練平臺(tái)。在各種算法上線之后，隨著在線學(xué)習(xí)的推進(jìn)，其模型不可能一成不變。

有的它們需要被“日更”，甚至是以分鐘為單位進(jìn)行更新。因此我們需要有一個(gè)良好的深度學(xué)習(xí)平臺(tái)提供支持。

• 測試。推薦系統(tǒng)在上線之后，需要被不斷的迭代與優(yōu)化，因此我們需要通過測試來查看效果。

在系統(tǒng)的起步階段，用戶數(shù)量迅速上升，而實(shí)驗(yàn)的整體數(shù)量則不多，因此我們很容易通過對***用戶的切分，來開展與流量相關(guān)的實(shí)驗(yàn)。

但是隨著業(yè)務(wù)的發(fā)展，用戶數(shù)量不再呈爆發(fā)式增長，而我們每天又需要進(jìn)行成百上千次實(shí)驗(yàn)，所以我們需要選用 A/B 測試的實(shí)驗(yàn)平臺(tái)，以方便算法人員加速迭代的進(jìn)程。

• 報(bào)表。之前在與業(yè)務(wù)方合作時(shí)，我們發(fā)現(xiàn)：他們幾乎每個(gè)人都在通過自行編寫簡單腳本的方式獲取所需的報(bào)表，因此其工作的重復(fù)度相當(dāng)高。

然而，由于許多報(bào)表的計(jì)算都是簡單算子的累加，如果我們擁有一個(gè)簡單且統(tǒng)一的平臺(tái)，就能夠幫助大家獲取常用的指標(biāo)，進(jìn)而加速整個(gè)系統(tǒng)的迭代。

從深度推薦系統(tǒng)的發(fā)展來看，最早出現(xiàn)的是傳統(tǒng) LR（線性回歸）的機(jī)器學(xué)習(xí)。

之后，隨著特征交叉需求的增多，出現(xiàn)了非線性回歸和使用 FM 來實(shí)現(xiàn)二階特征交叉。

近年來，隨著深度學(xué)習(xí)在圖像領(lǐng)域的廣泛應(yīng)用，如今大家也將它們引入到了推薦系統(tǒng)之中。

不過，相對于圖像領(lǐng)域動(dòng)輒一兩百層的神經(jīng)網(wǎng)絡(luò)深度而言，推薦系統(tǒng)的深度只有四到六層。

如今各家“大廠”都能夠提供諸如 FNN、DFM、以及 Google Wide&Deep 之類的算法，我們很難斷言哪種模型更好。

因此大家在進(jìn)行模型選取的時(shí)候，應(yīng)當(dāng)注意自己的系統(tǒng)偏好，保持與業(yè)務(wù)的強(qiáng)關(guān)聯(lián)性。

上圖借用的是阿里的 DIEN（Deep Interest Evolution Network），他們和我們現(xiàn)在的工作有著相似之處，特別是圖中虛線框里的兩個(gè)創(chuàng)新點(diǎn)。我會(huì)在后面進(jìn)行著重分析。

平時(shí)，我們在閱讀各種論文時(shí)，很容易產(chǎn)生一種錯(cuò)覺：那些作者為了突出自己的貢獻(xiàn)，經(jīng)常會(huì)著重描寫模型上的創(chuàng)意，體現(xiàn)并抽象其核心的思想，讓大家認(rèn)為該部分的占比能達(dá)到 80%。

而實(shí)驗(yàn)部分都只是一些標(biāo)準(zhǔn)的數(shù)據(jù)集，經(jīng)常一筆帶過。實(shí)際上，他們在模型側(cè)的工作量一般只有 20%，其他的 80% 則花在了做實(shí)驗(yàn)上。

具體說來，我們可以開展如下各種實(shí)驗(yàn)：

• 在拿到原始的線上日志數(shù)據(jù)之后，我們需要對它們做分析、統(tǒng)計(jì)和處理，以方便我們后期進(jìn)行模型訓(xùn)練。
• 特征設(shè)計(jì)、交叉和服務(wù)，包括：是否要將特征值離散化，是否要放大時(shí)間窗口等。
• 模型選擇，我們需要全面考慮計(jì)算的開銷，甚至要考慮自己的平臺(tái)上是否有 GPU，倘若沒有，則不應(yīng)選擇過于復(fù)雜的模型。同時(shí)，我們也要根據(jù)核心算法，制定召回和仲裁策略。
• ***是真正傳統(tǒng)意義上的實(shí)驗(yàn)，包括離線評測、線上 A/B 和實(shí)驗(yàn)分析等，這些都會(huì)與前面的四項(xiàng)有所關(guān)聯(lián)。

深度推薦系統(tǒng)在 360 的應(yīng)用實(shí)踐

下面，我們來討論一下深度推薦系統(tǒng)在 360 中幾個(gè)場景應(yīng)用的落地。如圖的三款應(yīng)用在技術(shù)上呈由淺入深、由簡單到復(fù)雜的遞進(jìn)關(guān)系。

場景一：App 推薦

360 手機(jī)助手，類似于應(yīng)用市場。圖中紅框里顯示的都是系統(tǒng)推薦的內(nèi)容，包括：“今日熱點(diǎn)”和“大家都在玩”等，這些都是與用戶的個(gè)性化喜好相關(guān)的。我們直接從用戶的下載和轉(zhuǎn)化率，來判定系統(tǒng)推薦的效果。

套用前面提到的三個(gè)層次：

• 抽象定義層。由于我們做的是一個(gè)離線系統(tǒng)，因此我們對 C 考慮并不多，主要將重點(diǎn)放在了 U 和 I 上。該場景下的 U 屬于億級(jí)，而 I 只有萬級(jí)，畢竟我們只需要在萬級(jí)的 App 庫里做推薦。
• 算法策略層。由于 I 的量級(jí)比較小，我們當(dāng)時(shí)就“簡單粗暴”地直接在這個(gè)萬級(jí)用戶庫里做了用戶匹配和推薦，而并沒有執(zhí)行召回策略。我們首先通過簡單的算法做出了一個(gè)初版模型。

為了查看效果，我們通過迭代、優(yōu)化和序列預(yù)測，來預(yù)測用戶下一次會(huì)安裝哪一種 App。而 Rank 和 Rerank 部分的邏輯，由于主要涉及到各種線上的業(yè)務(wù)邏輯，因此是由業(yè)務(wù)方來完成的。

• 架構(gòu)層。它對應(yīng)的是我們的天級(jí)離線中心，在特征上并不復(fù)雜，僅通過 Embedding 特征的運(yùn)用就完成了。

上圖是我們對于模型的邏輯進(jìn)化路徑。上圖的左側(cè)與 Google Wide&Deep 的思路是很相似的，只不過我們用的特征非常少。

上方藍(lán)色部分是用戶 App 序列的 ID 列表，我們使每個(gè) App 都有一個(gè)特征向量，然后做若干層的 MLP，***做分類，從而預(yù)測某個(gè)用戶下一步可能安裝的 App。

后來，隨著與業(yè)務(wù)人員的交流，我們在模型中加入了用戶的瀏覽歷史、搜索歷史、關(guān)鍵詞特征、和 App 特征等元素，不過其本質(zhì)上也都是行為的序列。

考慮到簡單的 MLP 已不太適合，因此我們就嘗試采用了 RNN 的方法進(jìn)行數(shù)據(jù)建模，于是就有了如下圖進(jìn)化后的網(wǎng)絡(luò)：

雖然該圖的上層分類與前面類似，但是下面的 browse 卻值得大家注意：當(dāng)你把用戶的搜索行為加到自己的特征里時(shí)，請注意調(diào)整時(shí)間序列，不然很容易會(huì)導(dǎo)致該搜索詞變成了一個(gè)搜索系統(tǒng)。

即：你的本意是通過用戶的搜索詞，來反應(yīng)他的興趣，并預(yù)測他要下載的 App。

但是，如果不做處理的話，就可能導(dǎo)致你的系統(tǒng)只是在模擬某個(gè)線上的搜索。

上面這張圖是將兩個(gè)模型的不同結(jié)果進(jìn)行了比較。它們分別對每個(gè) App 的 Embedding 向量進(jìn)行了可視化。我們將 App 的 Embedding 向量取出，并投影到二維圖上。

我們根據(jù) App 原來所隸屬的大類，來判斷經(jīng)過模型學(xué)習(xí)后，如果能將大類拉得比較散的話，那么效果就會(huì)更好些。

可見，在左邊 MLP 的中間，各種類型的交疊比較嚴(yán)重。而在我們換成了 RNN 模型之后，它們就顯得分散了許多。我們籍此來直觀地認(rèn)為改進(jìn)后的模型更好。

根據(jù)上面將 RNN 的效果與 MLP 的效果所進(jìn)行的數(shù)據(jù)比較，我們可以看出：在 Top1 上的差異并不太大，僅提升了 1 個(gè)點(diǎn)。

當(dāng)然，這可能對于線上系統(tǒng)的提升會(huì)反應(yīng)得顯著一些，但是對于我們的離線系統(tǒng)，提升反應(yīng)就沒那么明顯了。這便是我們整個(gè)團(tuán)隊(duì)在推薦領(lǐng)域的***次試水。

場景二：360 搜索和導(dǎo)航

有了前面 App 推薦的經(jīng)驗(yàn)積累，我們嘗試的第二個(gè)項(xiàng)目是“常搜詞”。即：360 頁面有自己的搜索和導(dǎo)航，而在搜索框的下方，我們會(huì)放置六到七個(gè)用戶經(jīng)常搜索、或者是時(shí)常用到的關(guān)鍵詞。

如此，用戶在打開導(dǎo)航時(shí)就能看到自己想看的東西，這不但減少了他們在操作上的復(fù)雜度，還提升了用戶在使用上的滿意度。

在該場景下，由于我們的導(dǎo)航每天都有好幾億次的 PV（Page View），因此使用該功能的用戶有著***的體量，即 U 為***。

同時(shí)，為了定義“常搜詞”，我們對 query（查詢）進(jìn)行了清洗，過濾掉了一些非常“長尾”的 query，只留下一些有實(shí)體字的、較為明確的 query。因此，此處的 I 就根據(jù) query 的數(shù)量被設(shè)定為了***。

由于該業(yè)務(wù)本身已存在了較長時(shí)間，因此在算法策略上也已實(shí)現(xiàn)一些較為完善的召回（Recall），例如：

• 搜索詞：是根據(jù)用戶的搜索行為，召回一些新的關(guān)鍵詞。
• URL：是根據(jù)用戶瀏覽器里面的瀏覽記錄，再輸入一些關(guān)鍵詞。
• 廣告：是通過滿足用戶的興趣匹配，精準(zhǔn)地投放商業(yè)化的廣告詞。
• 百科：是判斷用戶可能感興趣的知識(shí)，投放相應(yīng)的百科詞匯。

另外在 Rank 方面，我們著手將線上系統(tǒng)從以前簡單的 LR+FTRL，升級(jí)并優(yōu)化成為了 DNN 模型。

在架構(gòu)上，由于該導(dǎo)航系統(tǒng)的特點(diǎn)是用戶使用頻次不高，而我們的推薦可能每天只會(huì)被早晚各用一次，因此我們的目標(biāo)是天級(jí)離線更新。

其對應(yīng)的特征部分，則主要是基于用戶的搜索日志和瀏覽日志，來進(jìn)行的一些統(tǒng)計(jì)特征的設(shè)定。

讓我們來看看其中幾個(gè)權(quán)重比較正向的特征，例如：

• week_freq_num 特征，描述了用戶常搜詞匯的概率分布，即：如果某個(gè)用戶在過去一段時(shí)間窗口內(nèi)成均勻的訪問趨勢，則說明這是經(jīng)常性的需求。該特征比較重要。
• global_query_uv 特征，此類全網(wǎng)特征能夠在一定程度上反映商品的質(zhì)量。我們籍此在原有特征的基礎(chǔ)上擴(kuò)展到成千上萬個(gè)。

在我們將模型調(diào)整成為 DNN 之后，系統(tǒng)的 AUC 從 7 提到 8。之后我們還增加了一些其他能夠提升 AUC 的特征。

為了細(xì)粒度地分析 DNN 模型的召回策略在上線之后所產(chǎn)生的影響，我們拿它與傳統(tǒng)的 LR+FTRL 模型進(jìn)行了對比。

途中兩處 CTR 較高，它們都與用戶的搜索和瀏覽行為相關(guān)，并且能夠真正反映他們的需求。

由于此類搜索、瀏覽和 MLP 的點(diǎn)擊率本身就比較高，因此我們需要在此基礎(chǔ)上有一個(gè)量的提升。

另外在上圖中，雖然與個(gè)性化相關(guān)的廣告部分略有提升，但是 ys_mid_hist 是有所下跌的。

通過分析，我們發(fā)現(xiàn)該模型當(dāng)時(shí)在排序時(shí)，傾向于把策略后排，其導(dǎo)致的結(jié)果是：用戶在界面上默認(rèn)只能看到六個(gè)推薦詞，而實(shí)際上其旁邊有一個(gè)往下點(diǎn)的箭頭，在被點(diǎn)擊之后才會(huì)出現(xiàn)很多的詞匯。

因此，如果某些推薦詞匯被排到了第六名之后的話，那么它們被點(diǎn)擊的可能性就非常小。這也說明了默認(rèn)六個(gè)詞的重要性。

同時(shí)，這也提示了我們：在做數(shù)據(jù)時(shí)，需要重點(diǎn)關(guān)注那些用戶通過點(diǎn)擊下拉按鈕去訪問的詞匯，那些數(shù)據(jù)才更能夠說明用戶對某些詞匯的強(qiáng)烈需要。總的說來，我們協(xié)助業(yè)務(wù)側(cè)將 2017 年 Q1 的收入提升了 5%。

場景三：快視頻

基于前面兩個(gè)項(xiàng)目所積累的經(jīng)驗(yàn)，我們?nèi)榈赝度肓说谌齻€(gè)項(xiàng)目—快視頻。其主要的業(yè)務(wù)形式是個(gè)性化的消息推送，與大家手機(jī)上的通知欄推送相類似。

但是，略有不同的是：我們并非每日都定時(shí)推送，而是會(huì)根據(jù)用戶的反饋偏好，去調(diào)整推薦的數(shù)量、頻率和時(shí)間。

同時(shí)，這對于將一些尚未養(yǎng)成每日到我們的 App 里觀看視頻的用戶來說，能夠起到一定“拉活”的作用。

在此，我們?nèi)匀惶子们懊娴娜齻€(gè)層次。在頂層，由于該 App 上線之后，視頻庫的規(guī)模和用戶的數(shù)量都增長得非常迅速，因此 U 和 I 都具有***。

在召回策略上，圖中列出了五種重要的召回。前三項(xiàng)分別是：語義、視覺和行為召回。我們統(tǒng)一地對它們進(jìn)行了重點(diǎn)優(yōu)化。

而在距離用戶更近的 Rank 部分，我們通過收斂，采用了 LSTM + Attention 的模型。

前面介紹過的兩個(gè)項(xiàng)目都僅僅是以天為單位進(jìn)行更新，因此對算法人員的壓力并不大，只需采用定時(shí)任務(wù)便可。

而在這個(gè)場景中，由于它是一個(gè)對用戶進(jìn)行實(shí)時(shí)在線推薦的系統(tǒng)，如果采用“天級(jí)更新”頻率的話，會(huì)給用戶帶來較差的體驗(yàn)。

因此無論是對召回的數(shù)據(jù)流、模型的更新、還是在線的服務(wù)，我們都認(rèn)真進(jìn)行了架構(gòu)設(shè)計(jì)。

我們來看看剛才提到的三個(gè)召回策略：行為、語義和視覺。在此，我們將它們統(tǒng)一到了 Embedding 框架之中，以便從視頻的不同角度進(jìn)行描述和特征表示，而不必關(guān)心后續(xù)有關(guān)設(shè)計(jì)域值、隊(duì)列長度等問題。

通過執(zhí)行統(tǒng)一的流程，我們能夠更直觀的體現(xiàn)出各種視頻在特征領(lǐng)域下召回的根據(jù)。

例如圖中黑體字是某個(gè)視頻的 title（標(biāo)題），明顯，它是有關(guān)傳授烹飪知識(shí)的召回：

• 就行為模型而言，它通過對用戶行為序列的協(xié)同與分割，為每個(gè)視頻分配各種特征向量。

其特點(diǎn)是：會(huì)產(chǎn)生一定的擴(kuò)散效果。即，你會(huì)在上圖中發(fā)現(xiàn)，該召回的前兩個(gè)結(jié)果已經(jīng)不再關(guān)注烹飪，而是擴(kuò)散到了其他領(lǐng)域。只有第三個(gè)召回才是真正有關(guān)于烹飪的。

• 語義模型，重點(diǎn)關(guān)注的是視頻標(biāo)題的語義表示，通過語法和語義的相似性，此類召回能夠抓住標(biāo)題中關(guān)鍵性的動(dòng)詞與名詞，然后進(jìn)行相應(yīng)的交叉和擴(kuò)散等操作。
• 視覺模型，是通過抽取視頻的特征，來實(shí)現(xiàn)召回。它與標(biāo)題的語義關(guān)聯(lián)性不強(qiáng)，就算標(biāo)題與烹飪無關(guān)，只要在視頻中大量出現(xiàn)食物的圖像，便可以表示并召回。

由上可見，我們通過不同的 Embedding，就可以實(shí)現(xiàn)多樣的召回策略。

下面我們重點(diǎn)介紹語義模型。我們所得到的輸入數(shù)據(jù)是公司過往生成的查詢、與搜索數(shù)據(jù)，或是其他的業(yè)務(wù)線積累的標(biāo)簽數(shù)據(jù)，例如由網(wǎng)頁標(biāo)題所抽象出來的簡單標(biāo)簽。

這些標(biāo)簽既有自動(dòng)生成的，也有通過人工修正和 rebind（重新連接）產(chǎn)生的。它們都具有一定的實(shí)際價(jià)值。

為了給每個(gè) title 產(chǎn)生相應(yīng)的表征，我們構(gòu)建了一項(xiàng)任務(wù)：首先是對每個(gè)句子進(jìn)行分詞，以得到相應(yīng)的字/詞向量，然后通過 CNN 網(wǎng)絡(luò)進(jìn)行處理，***對目標(biāo)予以多分類、多標(biāo)簽，從而預(yù)測該標(biāo)簽準(zhǔn)確性。

對于上述任務(wù)，我們除了嘗試過 CNN 模型之外，還在不改變 task 的情況下試用了雙向的 LSTM，即 bi-LSTM。接著，我們需要對該語義模型進(jìn)行評測。

在此業(yè)務(wù)場景下，我們?nèi)斯?biāo)出了幾千個(gè)具有良好多樣性的數(shù)據(jù)，并將其作為離線評測的指標(biāo)，以此來檢查通過語義模型召回標(biāo)注數(shù)據(jù)的結(jié)果相關(guān)性。上圖左側(cè)的表格就是我們測試的結(jié)果。

我們在此比較了幾種常見的語義建模的模型、及其對應(yīng)的優(yōu)化。表格的中間列是 Title2Tags，即通過標(biāo)題來預(yù)測對應(yīng)的標(biāo)簽。

至于右邊列：Title2UnionTags，我們對應(yīng)地發(fā)現(xiàn)到：如果只有單個(gè)標(biāo)題，則語義往往會(huì)被遺漏。

如上圖右側(cè)的例子所示：無論是人工寫的標(biāo)題，還是自動(dòng)生成的，如果我們將多個(gè)標(biāo)簽放到一塊兒，句子中的語義則會(huì)更準(zhǔn)確地被覆蓋到。

另外我們后續(xù)對數(shù)據(jù)的清洗，也能夠提升原句子的標(biāo)簽數(shù)量，進(jìn)而大幅提升模型的整體效果。

上圖是我們開篇引用過的阿里 DIEN，在其虛線框中有兩個(gè)創(chuàng)新點(diǎn)，分別是 AUGRU（即 Attention 與 GRU 的合并）和輔助的 loss。

雖然 loss 對模型的提升效果非常明顯，可惜我們在模型設(shè)計(jì)時(shí)，過于關(guān)注 Attention 的 layer 和下沉到用戶序列上的特征，因此我們將來尚有改進(jìn)的空間。

上圖便是我們當(dāng)時(shí)對不同排序模型的評測結(jié)果。

可見我們在系統(tǒng)架構(gòu)的設(shè)計(jì)上，既有諸如到臺(tái)服務(wù)、日志搜集、和報(bào)表等離線部分，又有實(shí)時(shí)的在線更新。

同時(shí)，我們也與業(yè)務(wù)方的在線系統(tǒng)保持著實(shí)時(shí)性的交互，以便他們按需獲取推送的數(shù)據(jù)。另外在最上層，我們?yōu)闃I(yè)務(wù)方也提供了多種安全策略和分桶策略。

上圖便是我們從 2017 年 11 月 1 日到 2018 年 1 月 31 日的 CTR 曲線。

雖然有某些“坑點(diǎn)”所導(dǎo)致的曲線波動(dòng)，但是整體趨勢還是向上的，特別是在我們更換了 Attention 模型之后，提升的幅度能夠達(dá)到 10%，進(jìn)而有效地幫助業(yè)務(wù)方實(shí)現(xiàn)了“拉活”和保持更多的活躍用戶。

綜上所述，我們基于深度學(xué)習(xí)的推薦系統(tǒng)就是根據(jù)上述三個(gè)層次，一步一步地通過迭代和優(yōu)化發(fā)展起來的。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】