推薦算法線上Serving

推薦系統的實時性

實驗結果顯示,模型更新越慢,效果就越差;

 

一. 推薦系統「 特徵」的實時性:推薦系統的更新速度越快,越能夠反應用戶最近的用戶習慣,越能夠給用戶進行越有時效性的推薦。

系統“實時”地收集推薦系統模型所需的輸入特徵,使推薦系統能夠總是使用最新的特徵進行預測和推薦。

1. 客戶端實時性(無延遲):如果客戶端能夠緩存session內部的行爲,作爲與上下文特徵同樣的實時特徵傳給推薦服務器,那麼推薦模型就能夠實時得到session內部行爲特徵,進行實時的推薦。

2. 近線流式計算準實時性(分鐘級別的延遲:storm,spark streaming,flink等;計算該時間窗口內的特徵,例如:一個物品在該時間窗口內的曝光次數,點擊次數,一個用戶在該時間窗口內的點擊話題分佈等。

3. 離線訓練(小時級的延遲):HDFS+Spark; 多個數據源的數據join,延遲信號的合併。

比如用戶的曝光、點擊、轉化數據往往是在不同時間到達HDFS的,有些遊戲類應用的轉化數據的延遲甚至高達幾個小時,因此也只有在這一階段才能夠進行全量特徵以及相應label的抽取和合並。也只有在全量特徵準備好之後,才能夠進行更高階的特徵組合的工作。這往往是無法在客戶端和流處理平臺平臺上進行的。


 

二. 推薦系統「 模型」的實時性:推薦系統更新的越快,模型更容易發現最新流行的數據pattern,越能夠讓模型反應找到最新的流行趨勢。

特徵實時性再強,影響的範圍也僅限於當前用戶,要想快速抓住系統級別的全局的數據變化和新產生的數據pattern,就必須加強“模型”的實時性。

舉例來說: 拿某電商網站雙十一的大量促銷活動來說。特徵的實時性會根據用戶最近的行爲更快的發現用戶可能感興趣的商品,但絕對不會發現用戶相似人羣最新的偏好,商品之間最新的相關性信息,新活動的趨勢信息等。

1. 模型訓練全量更新(天級延遲):spark+tensorflow;

2. 模型訓練增量更新(小時延遲):

由於僅利用增量樣本進行學習,因此模型在多個epoch之後也是收斂到新樣本的最優點,而很難收斂到"原所有樣本+增量樣本"的全局最優點

因此在實際的推薦系統中,往往採用增量更新與全局更新相結合的方式,在進行幾輪增量更新後,在業務量較小的時間窗口進行全局更新,糾正模型在增量更新過程後中積累的誤差。在“實時性”和“全局最優”中間進行取捨和權衡。

3. 模型訓練實時更新(秒延遲):

在線學習是在每次獲得一個新樣本的時候就實時更新模型。如果使用general的SGD方法,在線學習會導致一個很嚴重的問題,就是模型的稀疏性很差,打開過多“碎片化”的不重要特徵。(微軟的RDA,google的FOBOS和最著名的FTRL等,都是爲了解決線上學習稀疏化的問題)

A. 模型的局部更新:

Facebook的GBDT+LR:GBDT更新慢;所以Facebook的線上部署是:每天訓練一次GBDT模型,固定GBDT模型後,準實時的訓練LR模型以快速捕捉數據整體的變化。

Embedding層+神經網絡:Embedding層一層的參數往往佔深度學習模型90%以上。因此Embedding層的更新會拖累模型整體的更新速度,因此業界也往往採用embedding層單獨訓練甚至預訓練,embedding層以上的模型部分高頻更新的策略。

B. 客戶端模型的實時更新:

用戶embedding的實時更新:對於物品embedding的更新來說,往往需要全局的數據,因此只能在服務器端進行整體的更新;而對用戶embedding來說,則更多依賴於用戶自身的數據。那麼把用戶embedding的更新過程移植到客戶端來做,就能夠實時地把用戶最近的行爲數據反應到用戶的embedding中來,從而通過實時改變用戶embedding的方式完成實時推薦。

例如:把用戶最近點擊過的item的embedding求avg-pooling/max-pooling(或者通過一個簡單的網絡),實時得到user-embedding。

 

三. 線上實時平臺

1. 自研:上線FTRL的過程就是從參數服務器或內存數據庫(不需要更新參數,所以用Redis就夠了;如果要更新參數,用Redis就會造成兩臺機器上同時要更新的w有一臺被忽略了,而用ps-lite可以讓兩臺的g都順序加到w上)中得到模型參數,然後用Java實現模型inference的邏輯。

2. 現在業界的很多公司其實採用了“複雜網絡離線訓練,生成embedding存入內存數據庫,線上實現LR或淺層NN等輕量級模型擬合優化目標”的上線方式。

百度雙塔模型:分別用複雜網絡對“用戶特徵”和“廣告特徵”進行了embedding化,在最後的交叉層之前,用戶特徵和廣告特徵之間沒有任何交互,這就形成了兩個獨立的“塔”,因此稱爲雙塔模型。(有點兒像DSSM的Query和Doc都是一樣的經過網絡)。

在完成雙塔模型的訓練後,可以把最終的用戶embedding和廣告embedding存入內存數據庫,在線上inference時,只需要實現最後一層的邏輯,在從內存數據庫中取出用戶embedding和廣告embedding之後,通過簡單計算即可得到最終的預估結果。(類似facebook的“召回”階段,把video的embedding們全存下來了,user的embedding一到直接KNN查找)

用戶側塔的embedding通常是要經過網絡得到的:用戶側塔的原始特徵通常比較動態,一個是通常包含context特徵,比如請求時間、當前地理位置之類的,這些都是沒法離線準備好embedding的;二是對新用戶embedding沒辦法離線提前準備好

3. PMML:“預測模型標記語言”,作爲中間媒介連接離線訓練平臺和線上預測平臺。

4. Tensorflow Serving及其改造:

利用TensorFlow自帶的模型序列化函數可將訓練好的模型參數和結構保存至某文件路徑。

涉及到模型更新,整個docker container集羣的維護和按需擴展等一系例工程問題;此外,TensorFlow Serving的性能問題也仍被業界詬病。

定製案例:A. 砍掉了傳輸,砍掉了數據打包再拆開的環節(序列化和反序列化),砍掉了一些爲了通用但實際對我們大多數互聯網業務沒用的步驟;B. session run外面包了一層自研的server,比grpc更可控,性能調優還是更多的在模型本身。C.兩種思路,一是把模型分裂成embedding和nn網絡,弊端就是分裂模型了,不方便;另一種思路就是把TF裏的PS(parameter-server?)給改造線上可用,這種思路優點很明顯,更通用易擴展,但缺陷就是改造難度不好估量,不知是否行得通

 

 

最常見的實時性,除了排序的特徵實時性和召回實時性外。通常,從產品角度會有個強插邏輯(強制召回下發最近一個正反饋相似資源

模型的實時性可以參考阿里媽媽(書裏有)最近做的強化學習模型,採用markov模型,可以實現千pv千面

Facebook在2016年的client-side模型

廣告確實和推薦場景完全不同,用戶點擊了某個廣告也不能說明他非常喜歡看這類廣告,從動機上來說,廣告的行爲就是完全不同的。

"知乎和抖音這種體驗,在信息流裏都是基本操作。實現這個大概需要幾點:1、用戶行爲反饋實時回傳;2、根據用戶實時行爲有特定的實時召回源,比如同上次點擊/本session內所有點擊平均相似度最接近的N個內容;3、保證實時召回源的內容可以排出去(如果有價值的話),這裏需要通過rank模型相關特徵保障:如果有召回源相關特徵(match類特徵)基本上已經可以做到,也就是如果實時召回的內容真的有價值,那麼這個召回源召回的內容在排序時權重自然高,體現在該召回源的match類特徵上。另外還可以試試跟abb那樣,增加每個待排序內容同用戶近期點擊的內容、近期沒點擊內容的相似度特徵,abb的實踐看這兩個特徵也很強"

"知乎 timeline 對用戶行爲反饋的實時性主要通過如下方式實現:1)kafka + spark streaming 收集用戶 last-n 行爲(延時大概是 2 分鐘以內,大部分是 1 分鐘);2)採用 last-n + itemcf 的方式召回與用戶最近閱讀行爲相似的內容。沒有做特別的 rerank 提權策略,主要還是 ranking 模型能夠學習到召回的內容與 item 之間的 match 信息(last-n 同時更新了用戶的實時興趣,是 ranking 模型的特徵)。"

模型實時性很重要:特別是樣本分佈變化大的場景,例如大促(大促,大促前夕,春節情人節等某些節假日用戶行爲發生重大變化時,在線學習可以更快的抓住全局層面的新的數據模式。其實每天的不同時段商品的ctr也不同,模型訓練的過程可以看成是在擬合這個ctr的過程。如果樣本量夠大,把hour作爲特徵,理論上也能擬合不同時段的ctr。

正樣本的延遲問題:在商品cvr的學習中特別明顯(還有遊戲內購買類的曝光轉化延遲)。比如我們將窗口設爲1小時,那麼1小時後的成交正樣本可能就被丟棄了,同時還導致模型之前學習到了假的負樣本。建議是以更大的weight回刷這個正樣本(做錯誤轉化信號的補償性重新練)。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章