雷鋒網(wǎng) AI 科技評論按:本文作者石塔西,原載于知乎,雷鋒網(wǎng)已獲授權(quán)。
本文是對阿里的論文《Image Matters: Visually modeling user behaviors using Advanced Model server》的解讀。
初讀此文的標題和摘要,又有 image,又有 CTR,我以為是一種新型的 CNN MLP 的聯(lián)合建模方法。讀下來才知道,本文的重點絕不在什么圖像建模上,壓根就沒 CNN 什么事。想像中的像素級別的建模根本沒有出現(xiàn),商品的圖片利用網(wǎng)上可下載的預訓練好的 VGG16 模型的某個中間層壓縮成 4096 維向量,作為 CTR 模型的原始輸入。
而將圖片引入到推薦/搜索領域,也不是什么新鮮事。不說論文 Related Works 中提到的工作,我自己就做過基于圖片的向量化召回,結(jié)構(gòu)與論文圖 4 中的 Pre-Rank DICM 結(jié)構(gòu)很相似,只不過用戶側(cè)不包含他之前點擊過的商品圖片罷了,在此略下不表。
沒有提出新的圖像建模方法,也并非第一次在推薦算法中使用圖片信息,那么此文的創(chuàng)新點到底在哪里?我覺得,本文的創(chuàng)新點有兩個創(chuàng)新點:
-
之前的工作盡管也在推薦/搜索算法中引入了圖片信息,可是那些圖片只用于物料側(cè),用于豐富商品、文章的特征表示。而阿里的這篇論文,是第一次將圖片用于用戶側(cè)建模,基于用戶歷史點擊過的圖片(user behavior images)來建模用戶的視覺偏好。
接下來會看到,將圖片加入到用戶側(cè)建模,理論上并不復雜,理論上用傳統(tǒng) PS 也可以實現(xiàn),起碼跑個實驗,發(fā)篇論文應該不成問題。但是,如果應用到實際系統(tǒng),圖片特征引入的大數(shù)據(jù)量成為技術瓶頸。為此,阿里團隊為傳統(tǒng) PS 的 server 也增加了「模型訓練」功能,并稱新結(jié)構(gòu)為 Advanced Model Server(AMS)。
基于歷史點擊圖片建模用戶視覺偏好
先談一下第一個「小創(chuàng)新」。之所以說其「小」,是因為通過預訓練的 CNN 模型提取特征后,每張圖片用一個高維(比如 4096)稠密向量來表示。這些圖片向量,與常見的稀疏 ID 類特征經(jīng)過 embedding 得到的稠密向量,沒有質(zhì)的區(qū)別(量的區(qū)別,下文會提到),完全可以復用以前處理 ID embedding 的方法(如 pooling, attention)來處理。
Deep Image CTR Model(DICM)的具體結(jié)構(gòu)如下所示:
DICM 架構(gòu)圖
-
如果只看左邊,就是推薦/搜索中常見的 Embedding MLP 結(jié)構(gòu)。注意上圖中的 Embedding MLP 結(jié)構(gòu)只是實際系統(tǒng)的簡化版本,實際系統(tǒng)中可以替換成 Wide&Deep, DIN, DIEN 等這些「高大上」的東西。
假設一個滿足要求的圖片 embedding model 已經(jīng) ready,即圖中的 embmodel。商品的縮略圖,經(jīng)過 embmodel 壓縮,得到商品的圖片信息(圖中的粉紅色塊)
右邊部分,負責利用圖片建模用戶。將每個用戶點擊過的圖片(user behavior image),經(jīng)過 embmodel 進行壓縮(圖中的藍色塊)。它們與商品圖片(ad image)的 embedding 結(jié)果(粉紅色塊)經(jīng)過attentive pooling 合并成一個向量(桔色塊)表示用戶的視覺偏好
將用戶點擊過的多張圖片的向量(藍色)合并成一個向量(桔色),其思路與 Deep Interest Network 基于 attention 的 pooling 機制大同小異,只不過要同時考慮「id 類特征」與「商品圖片」對用戶歷史點擊圖片的 attention,稱為MultiQueryAttentivePooling。
第 1 步得到基于 id 特征的 embedding 結(jié)果,與第 2 步得到的商品圖片 (ad image) 的 embedding 結(jié)果(粉紅色),與第 3 步得到的表示用戶興趣偏好的向量(桔紅色),拼接起來,傳入 MLP,進行充分的交互
這個模型的優(yōu)勢在于:
-
之前的模型只考慮了傳統(tǒng)的 ID 類特征和物料的圖像信息,這次加入了用戶的視覺偏好,補齊了一塊信息短板
不僅如此,通過 MLP,將傳統(tǒng)的 ID 類特征、物料的圖像信息、用戶的視覺偏好進行充分交互,能夠發(fā)現(xiàn)更多的 pattern。
基于用戶歷史訪問的 item id 來建模用戶的興趣,始終有「冷啟動」問題。如果用戶訪問過一個 embedding matrix 中不存在的 item,這部分信息只能損失掉。而基于用戶歷史訪問的圖片來建模,類似于 content-based modeling,商品雖然是新的,但是其使用的圖片與模型之前見過的圖片卻很相似,從而減輕了「冷啟動」問題。
綜上可見,DICM 的思路、結(jié)構(gòu)都很簡單。但是,上面的描述埋了個大伏筆:那個圖片嵌入模型 embmodel 如何設計?沒有加入圖片、只有稀疏的 ID 類特征時,Embedding MLP 可以通過 Parameter Server 來分布式訓練?,F(xiàn)在這個 embmodel,是否還可以在 PS 上訓練?在回答這個問題之前,讓我們先看看稀疏 ID 特征 Embedding MLP 在傳統(tǒng)的 PS 上是如何訓練的?
稀疏 ID 特征 Embedding MLP 在傳統(tǒng)的 PS 上是如何訓練的?
介紹 PS 的論文、博客汗牛充棟,實在論不上我在這里炒冷飯,但是,我還是要將我實踐過的「基于 PS 訓練的 DNN 推薦算法」,在這里簡單介紹一下,因為我覺得它與《Scaling Distributed Machine Learning with the Parameter Server》所介紹的「經(jīng)典」PS 還是稍稍有所不同,與同行們探討。
基于 PS 的分布式訓練的思想還是很簡單的:
1.一開始是 data parallelism。每臺 worker 只利用本地的訓練數(shù)據(jù)前代、回代,計算 gradient,并發(fā)往 server。Server 匯總(平均)各 worker 發(fā)來的 gradient,更新模型,并把更新過的模型同步給各 worker。這里有一個前提,就是數(shù)據(jù)量超大,但是模型足夠小,單臺 server 的內(nèi)存足以容納。
2.但是,推薦/搜索系統(tǒng)使用超大規(guī)模的 LR 模型,模型參數(shù)之多,已經(jīng)是單臺 server 無法容納的了。這時 Parameter Server 才應運而生,它同時結(jié)合了 data parallelism 與 model parallelism
-
Data parallelism:訓練數(shù)據(jù)依然分布地存儲在各臺 worker node 上,各 worker node 也只用本地數(shù)據(jù)進行計算。
Model parallelism:一來模型之大,單臺 server 已經(jīng)無法容納,所以多臺 server 組成一個分布式的 Key-value 數(shù)據(jù)庫,共同容納、更新模型參數(shù);二來,由于推薦/搜索的特征超級稀疏,各 worker 上的訓練數(shù)據(jù)只涵蓋了一部分特征,因此每個 worker 與 server 之間也沒有必要同步完整模型,而只需要同步該 worker 的本地訓練數(shù)據(jù)所能夠涵蓋的那一部分模型。
所以按照我的理解,PS 最擅長的是訓練稀疏數(shù)據(jù)集上的算法,比如超大規(guī)模 LR 的 CTR 預估。但是,基于 DNN 的推薦/搜索算法,常見模式是稀疏 ID 特征 Embedding MLP,稍稍有所不同
1.稀疏 ID 特征 Embedding,是使用 PS 的理想對象:超大的 embedding 矩陣已經(jīng)無法容納于單臺機器中,需要分布式的 key-value 數(shù)據(jù)庫共同存儲;數(shù)據(jù)稀疏,各 worker 上的訓練數(shù)據(jù)只涵蓋一部分 ID 特征,自然也只需要和 server 同步這一部分 ID 的 embedding 向量。
2.MLP 部分,稍稍不同
-
和計算機視覺中動輒幾百層的深網(wǎng)絡相比,根據(jù)我的經(jīng)驗,縱使工業(yè)級別的推薦/搜索算法,MLP 也就是 3~4 層而已,否則就有過擬合的風險。這等「小淺網(wǎng)絡」可以容納于單臺機器的內(nèi)存中,不需要分布式存儲。
與每臺 worker 只需要與 server 同步本地所需要的部分 embedding 不同,MLP 是一個整體,每臺 worker 都需要與 server 同步完整 MLP 的全部參數(shù),不會只同步局部模型。
所以,在我的實踐中
-
稀疏 ID 特征 Embedding,就是標準的 PS 做法,用 key-value 來存儲。Key 就是 id feature,value 就是其對應的 embedding 向量;
MLP 部分,我用一個 KEY_FOR_ALL_MLP 在 server 中存儲 MLP 的所有參數(shù)(一個很大,但單機足以容納的向量),以完成 worker 之間對 MLP 參數(shù)的同步。
實際上,對 Embedding 和 MLP 不同特性的論述,在《Deep Interest Network for Click-Through Rate Prediction》中也有所論述。阿里的 X-DeepLearning 平臺
-
用 Distributed Embedding Layer 實現(xiàn)了分布式的 key-value 數(shù)據(jù)庫來存儲 embedding。應該是標準的 PS 做法。
用 Local Backend 在單機上訓練 MLP。如何實現(xiàn)各 worker(i.e., local backend)的 MLP 的同步?是否和我的做法類似,用一個 key 在 server 上存儲 MLP 的所有參數(shù)?目前尚不得而知,還需要繼續(xù)研究。
加入圖片特征后,能否繼續(xù)在 PS 上訓練?
按原論文的說法,自然是不能,所以才提出了 AMS。一開始,我以為」PS 不支持圖片」是「質(zhì)」的不同,即 PS 主要針對稀疏特征,而圖片是稠密數(shù)據(jù)。但是,讀完文章之后,發(fā)現(xiàn)之前的想法是錯誤的,稀疏 ID 特征與圖片特征在稀疏性是統(tǒng)一的。
-
某個 worker node 上訓練樣本集,所涵蓋的 item id 與 item image,只是所有 item ids/images 的一部分,從這個角度來說,item id/image 都是稀疏的,為使用 PS 架構(gòu)提供了可能性
item image 經(jīng)過 pre-trained CNN model 預處理,參與 DICM 訓練時,已經(jīng)是固定長度的稠密向量。Item id 也需要 embedding 成稠密向量。從這個角度來說,item id/image 又都是稠密的。
正因為稀疏 ID 特征與圖片特征,本質(zhì)上沒有什么不同,因此 PS 無須修改,就可以用于訓練包含圖片特征的 CTR 模型(起碼理論上行得通),就是文中所謂的 store-in-server 模式。
-
圖片特征存入 PS 中的 server,key 是 image index,value 是經(jīng)過 VGG16 提取出來的稠密向量
訓練數(shù)據(jù)存放在各 worker 上,其中圖片部分只存儲 image index
訓練中,每個 worker 根據(jù)各自本地的訓練集所包含的 image index,向 server 請求各自所需的 image 的 embedding,訓練自己的 MLP
一切看上去很美好,直到我們審視 VGG16 提取出來的 image embedding 到底有多長?
-
原論文中提到,經(jīng)過試驗,阿里團隊最終選擇了 FC6 的輸出,是一個 4096 長的浮點數(shù)向量。而這僅僅是一張圖片,每次迭代中,worker/server 需要通信的數(shù)據(jù)量是 mini-batch size * 單用戶歷史點擊圖片數(shù) (i.e., 通常是幾十到上百) * 4096 個浮點數(shù)。按照原論文中 table 2 的統(tǒng)計,那是 5G 的通訊量。
而一個 ID 特征的 embedding 才用 12 維的向量來表示。也就是說,引入 image 后,通訊量增長了 4096/12=341 倍。
(或許有心的讀者問,既然 4096 的 image embedding 會造成如此大的通訊壓力,那為什么不選擇 vgg16 中小一些層的輸出呢?因為 vgg16 是針對 ImageNet 訓練好的,而 ImageNet 中的圖片與淘寶的商品圖片還是有不小的差距(淘寶的商品圖片應該很少會出現(xiàn)海象與鴨嘴獸吧),因此需要提取出來的 image embedding 足夠長,以更好地保留一些原始信息。原論文中也嘗試過提取 1000 維的向量,性能上有較大損失。)
正是因為原始圖片 embedding 太大了,給通信造成巨大壓力,才促使阿里團隊在 server 上也增加了一個「壓縮」模型,從而將 PS 升級為 AMS。
AMS 的技術細節(jié),將在下一節(jié)詳細說明。這里,我覺得需要強調(diào)一下,由于加入圖片而需要在 AMS,而不是 PS 上訓練,這個變化是「量」變引起的,而不是因為原來的 ID 特征與圖片這樣的多媒體特征在「質(zhì)」上有什么不同。比如,在這個例子中,
-
使用 AMS 是因為 image 的原始 embedding 由 4096 個浮點數(shù)組成,太大了
之所以需要 4096 個浮點數(shù),是因為 vgg16 是針對 ImageNet 訓練的,與淘寶圖片相差較大,所以需要保留較多的原始信息
如果淘寶專門訓練一個針對商品圖片的分類模型,那么就有可能拿某個更接近 loss 層、更小的中間層的輸出作為 image embedding
這樣一來,也就沒有通信壓力了,也就無需 server 上的「壓縮」模型了,傳統(tǒng)的 PS 也就完全可以勝任了。
所以,AMS 并不應該是接入多媒體特征后的唯一選擇,而 AMS 也不僅僅是針對多媒體特征才有用。應該說,AMS 應該是針對「embedding 過大、占有過多帶寬」的解決方案之一。
Advanced Model Server(AMS)架構(gòu)
上一節(jié)講清楚了,AMS 是為了解決「image 的原始 embedding 過大,造成太大通信壓力」的問題而提出的。在這一節(jié)里,我們來看看 AMS 是如何解決這一問題的。
AMS 的解決方案也很簡單:
-
為每個 server 增加一個可學習的「壓縮」模型(論文中的 sub-model,其實就是一個 4096-256-64-12 的金字塔型的 MLP)
當 worker 向 server 請求 image embedding 時,server 上的「壓縮」模型先將原始的 4096 維的 image embedding 壓縮成 12 維,再傳遞給 worker,從而將通訊量減少到原來的 1/340
該「壓縮」模型的參數(shù),由每個 server 根據(jù)存在本地的圖片數(shù)據(jù)學習得到,并且在一輪迭代結(jié)束時,各 server 上的「壓縮」模型需要同步。
每個 server 上都有這樣一個這個可學習的「壓縮」模型,要能夠利用存放在本地的數(shù)據(jù)(這里就是 4096 長的 image 原始 embedding)前代、回代、更新權(quán)重,并且各 server 的模型還需要同步,簡直就是 worker 上模型的翻版。將 worker 的「訓練模型」的功能復制到 server,這也就是 Advanced Model Server 相比于傳統(tǒng) Parameter Server 的改進之處。
AMS 是本文最大的創(chuàng)新點。本來還想再費些筆墨詳細描述,最后發(fā)現(xiàn)不過是對原論文 4.2 節(jié)的翻譯,白白浪費篇幅罷了,請讀者移步原論文。其實,當你明白了 AMS 要解決什么樣的問題,那么原論文中的解決方案,也就是一層窗戶紙罷了,簡單來說,就是將 worker 上的模型前代、回代、更新、同步代碼移植到 server 端罷了。最后加上原論文中的圖 2,以做備忘。
AMS 交互流程
總結(jié)
以上就是我對 Deep Image CTR Model(DICM)兩個創(chuàng)新點的理解。根據(jù)原論文,無論是離線實驗還是線上 AB 測試,DICM 的表現(xiàn)都比不考慮用戶視覺偏好的老模型要更加優(yōu)異。DICM 開啟了在推薦系統(tǒng)中引入多媒體特征的新篇章。
小結(jié)一下 DICM 的成就與思路:
-
DICM,第一次將圖片信息引入到用戶側(cè)建模,通過用戶歷史上點擊過的圖片(user behavior images)建模用戶的視覺偏好,而且將傳統(tǒng)的 ID 類特征、物料的圖像信息、用戶的視覺偏好進行充分交互,能夠發(fā)現(xiàn)更多的 pattern,也解決了只使用 ID 特征而帶來的冷啟動問題。
但是,引入 user behavior images 后,由于 image 原始 embedding 太大,給分布式訓練時的通信造成了巨大壓力。為此,阿里團隊通過給每個 server 增加一個可學習的「壓縮」模型,先壓縮 image embedding 再傳遞給 worker,大大降低了 worker/server 之間的通信量,使 DICM 的效率能夠滿足線上系統(tǒng)的要求。這種為 server 增加「模型訓練」功能的 PS,被稱為 AMS。
最后,還應該強調(diào),引發(fā) PS 升級到 AMS 的驅(qū)動力,是「量變」而不是「質(zhì)變」。圖片之類的多媒體特征,既不是 AMS 的唯一用武之地,也不應是 AMS 壟斷的專利。選擇哪種訓練架構(gòu),需要我們根據(jù)業(yè)務、數(shù)據(jù)的特點做出判斷,切忌迷信「銀彈」。
版權(quán)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻,該文觀點僅代表作者本人。本站僅提供信息存儲空間服務,不擁有所有權(quán),不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容, 請發(fā)送郵件至 舉報,一經(jīng)查實,本站將立刻刪除。