搜索推荐系统实战：终极奥秘
搜索推薦系統實戰篇-下篇
一切源于煉丹筆記，我只是敲了敲代碼。搜索推薦系統實戰：起始篇
搜索推薦系統實戰：進化篇
搜索推薦系統實戰：終極奧秘
Bias問題是推薦系統長期需要考慮的一個問題，舉些簡單的例子：
- 如果我們使用傳統的推薦系統對我們數據進行建模優化，就會形成流行度bias的問題，導致越流行的商品越流行，銷量越高的商品的銷量越多，這很不利于小商家的發展，尤其是新入駐的賣家等，由于得不到曝光而慢慢流失。
- 在建模的過程中，商品的曝光位置我們只有在商品已經被曝光之后才可以拿到，而很多用戶對于曝光位置是非常敏感的，如果這些曝光之后的信息沒法在建模的過程中被使用，那么也會帶來性能損失的問題。
- ...
關于推薦系統中Bias的造成，大家可以參考下面的框架。
1. 推薦系統中的反饋循環
我們可以將推薦系統的循環表述為下面的幾個階段。
1.1 User -> Data
1.2 Data -> Model
基于收集到的數據進行推薦模型的學習,從歷史的交互中學習用戶的喜好,并且預測用戶可能購買某個商品的概率等;
1.3 Model -> User
將推薦的結果返回給用戶,以滿足用戶的信息需求。這一階段將影響用戶未來的行為和決策。
通過上面的循環,用戶和推薦系統在交互的過程中,用戶的行為通過推薦進行更新,這樣土建系統可以通過利用更新的數據進行自我強化。
關于Bias和Debias的問題，也一直是工業界和學術圈的一大研究課題。至于詳細的研究細節，推薦大家閱讀下面的論文：
- Bias and Debias in Recommender System: A Survey and Future Directions
此處不再進行過多的闡述，僅介紹我們在position bias的一些思考。
2. PositionBias的處理方式
2.1 當特征加入
消除推薦系統中的位置偏置，一種常見的做法就是將position信息當作是特征加入到模型當中，具體的做法如下：
- 在訓練階段將位置作為一個特征加入到模型中；
- 而在預測階段置為0或者一個統一的常數，如下圖所示；
因為position在線下是可以直接拿到的，但是在上線的過程中是拿不到的，所以在預測階段經常會帶來一些不確定的效果。
2.2 另起一個shallow tower預測位置信息
通過一個shallow tower（可理解為比較輕量的模型）來預測位置偏置信息，輸入的特征主要是一些和位置偏置相關的特征。
在多任務模型的子任務最后的sigmoid前，將shallow tower的輸出結果加入進去。而在預測階段，則不考慮shallow tower的結果。值得注意的是，位置偏置信息主要體現在CTR預估中，而用戶觀看視頻是否會點擊喜歡或者用戶對視頻的評分，這些是不需要加入位置偏置信息的。
2.3 概率拆分：用戶看到物品的概率*物品點擊的概率
該方法基于這樣一個假設，即一個商品只有在被用戶看到時才被用戶點擊。更具體地說，我們認為商品被用戶點擊的概率取決于兩個因素：
假設商品被用戶看到，那么我們有：
我們做進一步的假設：
- 一個商品被看到的概率只與相關位置被觀察到的概率有關；
- 一個商品被點擊的概率是和位置無關的;
2.4 一些實驗
我們分別對三種策略進行建模，發現：
- 把position進行embedding然后直接當作特征加入到模型中進行訓練，然后在inference階段全部設置為某個固定的值，例如0，基本沒什么提升；
- 另起一個分支，把position的位置信息emebdding之后接MLP并將最后的輸入進行sigmoid與預測的pCTR的預估值相乘，作為最終的預測；在預測的階段，我們分別將position全部設置為0，以及不生效該分支的預測結果；
- 在position側加入用戶/商品的簡單信息之后接MLP并將最后的輸入進行sigmoid與預測的pCTR的概率相乘，作為最終的預測；預測的時候我們不生效該Position側網絡；
后面兩種策略在實驗的過程中，可以帶來微弱的提升，但是沒有論文中那么明顯，可能和數據集以及應用的場景相關。
注意：如果是Cotrain的框架，Position在建模的時候只需要加入到CTR分支即可。
特征工程目前依然是建模過程中最為核心的一塊，也是提升最快最簡單的部分；有些公司的搜索推薦團隊只使用了embedding相關的信息，并希望通過embedding的交叉或者序列等信息建模得到最終的推薦結果，并沒有加入非常多人為構建的特征。
但在很多的場景下，特征工程還是非常重要的。尤其是在有好幾年數據積累的場景中，數據量是非常大的，甚至可以上PB級別，在建模的過程中基本上是不大可能把所有的數據全部使用上，我們一般會選擇使用最新的數據，但為了盡可能不浪費老的數據信息，會選擇通過特征工程的方式從老的數據集中提取盡可能多的信息。為模型帶來提升，而在我們的實踐中，也發現，特征工程帶來的提升還是非常大的。
1. 特征工程技巧(From RecSys2020 Tutorial)
在最近的RecSys大會上，也出現了關于推薦系統特征工程的Tutorial，但里面更多的是關于各類特征如何處理的問題，更像是AutoML的東西。
1.1 類別特征(Categorical)
常見的策略有三種：
1.2 非結構化的列表
常采用的特征工程策略為：
1.3 數值特征
1.4 時間戳特征
1.5 時間序列
1.6 文本
1.7 圖像
1.8 社交圖
1.9 地理位置
2. 海量特征工程
上面內容更多的是一些基礎的特征處理技巧。很多較為傳統，如果轉化業務中該如何構建特征工程呢？此處我們描述一套特征框架，過多的細節不闡述，畢竟是很多大佬打磨了很多從非常多的實踐中實踐得到的，而且也不一定各種業務都會100%有效。
首先我們建模的目的是為了預估：
找到所有商品中最有可能被購買的那一件，然后曝光給用戶。從上面的定義中，我們可以發現，特征至少可以劃分為下面的幾塊。
2.1 用戶相關的特征
這塊特征實在是有些多，還有一些專門做用戶畫像的組。包含的特征有很多：
- 用戶的固定屬性特征，比如：用戶的性別、年齡、身高其它信息；
- 用戶的歷史統計特征，比如：過去某段時間的購買率、點擊率、消費次數、平均每次消費額、平均消費間隔、最近一次消費的時間等等。
- 用戶的其它特征，比如：喜好特征， 實時行為建模，更細粒度的對當前請求下的興趣刻畫與描述等等；
這塊特征非常多，很多組都有一套自己的特征組。
2.2 商品相關的特征
和用戶的特征類似，商品的特征也是海量的：
- 商品的固定屬性特征，比如：商品的上架時間、商品的體積、商品的價格、是否是當季商品、是否促銷、是否有優惠活動等等；
- 商品的歷史統計特征，比如：商品的歷史點擊率、商品的曝光次數、商品的加購率、商品的購買率、商品上次被購買的時間等等；
- 商品的其它特征，比如：商品是否有代言，代言人，代言人的粉絲情況等等；
這塊特征非常多，很多組都有一套自己的特征組。
2.3 Query相關的特征
這塊在搜索相關的競賽中，也是非常多的，參見阿里媽媽IJCAI2018年的競賽：
- Query的固定屬性特征，比如：Query的embedding，Query中關鍵詞的統計信息；
- Query的歷史統計特征，比如：Query的歷史出現次數，Query的歷史點擊率，購買率等等；
- Query的其它特征：近義詞的次數等；
這塊的特征和用戶以及商品是類似的，也是自成一套。
2.4 上下文特征
- 地點、時間、網絡信號形式、使用的app等信息；
2.5 交叉特征
特征交叉這塊是探討最多的，因為交叉信息實在是太多了，從很多大佬的分享以及相關的數據競賽最后的分享方案中，我們也發現：短短的幾個原始字段在進行交叉之后都可以得到成百上千的特征，更別說是在工業界了，工業界的字段都有幾百個，甚至會有上千個，所以這塊要是單純的做特征交叉，可以枚舉幾個月甚至幾年。
從kaggle的諸多特征專家寫的write-ups來看，特征又可以分為：二階的交叉，三階的交叉，四階的交叉......
這么做下去，幾乎是一個天文數字，再加上這么大的數據量，我們對每個新構建的特征進行驗證，耗費的資源也將會是一個天文數字，而且存儲資源也是無法接受的，舉個最簡單的例子，我們做用戶和商品的二階交叉特征，
- 在很多朋友，用戶都是上千萬甚至是上億的，商品的個數更不用說了，最少也是上百萬的，所以簡單的交叉可能會帶來上億*上百萬的個數，當然實踐中肯定沒這么多，如果從存儲的代價角度看，這將會是一個非常巨大的負擔。
- 從上面的角度來看，做用戶和Query和商品的三階交叉將會是一種巨大的負擔。
大家都知道這些特征是非常有用的，但是直接做交叉的代價又是巨大的，怎么辦呢？我們可以使用下面的兩個技巧來進行處理。
1.Top截斷：
這幾乎在所有的大數據競賽中都有提到，例如IJCAI18年的競賽就是，在我們的數據量非常大的時候，我們會選擇保留排序之后TopN的信息，例如：
- 保留用戶最常購買的TopN個Item的點擊率，購買率等等；
- 保留用戶最常訪問的TopN個Query的點擊率，購買率等等；
- 保留Query下最常購買的TopN個Item的點擊率，購買率等等；
- ...
2.轉變為分布表示：
該技巧也主要來源于推薦相關的競賽，以及AAA21年最新的競賽分享中，大致的思路是將原先的直接統計user+item的信息轉而去統計其它的特征：
- 先統計商品的歷史點擊率，然后拼接到商品信息中，當做商品的統計信息，然后再統計用戶關于商品的這些統計信息的統計特征。
該方法被稱之為用商品的點擊/購買分布來表示用戶。類似的，商品也可以用用戶來表示，即。
- 先統計用戶的歷史點擊率，然后拼接到用戶信息中，當做用戶的統計信息，然后再統計商品關于用戶的這些統計信息的統計特征。
這種用交叉信息的一側主體的統計信息來表示另外一側主體的策略也是極其方便的一種策略。
2.6 其它新技術帶來的特征
這塊的特征如果從技術的角度來看都是可以被包含到上面的幾大類中的，但是因為這些特征是通過最新的一些硬件或者其它的技術發展帶來的，例如邊緣計算等，此處我們將其單獨列舉出來作為一節。
最典型的一些特征就是阿里巴巴EdgeRec文章中所列舉的：
2.7 上游特征
這個在KDD20的競賽中有看到，大致就是利用模型上游的很多統計或者其它模型輸出的一些特征，每個公司產出的可能不一樣，此處不做過多描述。
2.8 實驗小結
上面的特征工程只是冰山一角，因為隨著業務相關的數據集的擴充，肯定也會涉及到非常多其它相關的特征。比如與圖片相關的特征，用戶購買商品之后對于商品的文字評價等等諸多的信息，這些都可以作為商品或者用戶商品相關的信息加入模型。
整體來說，特征作為模型的輸入能帶來非常大的幫助，所以還是非常重要的，我們通過特征工程的方式能在原先的基礎上帶來非常大的提升。
在第一篇文章我們就說了，搜索推薦的問題依據平臺的發展有無窮無盡的問題需要思考，感覺是做不完的。單單就提升轉化率這個任務來看，就可以分為下面幾個階段：
- 模型提效/壓縮等：從數據收集的層面、特征數據集質量、標簽質量、數據的使用、模型的Loss、整體框架設計（此框架下的優化）、局部各個子模塊設計（交叉，序列，Dense側等等）、數據特征工程等等角度對模型進行優化。但其實這只是非常小的一部分，還有非常多待解決的問題，包括：
- 交叉特征帶來的冗余問題；Dense特征的篩選；
- 各種Bias問題的Debias策略研究；
- 模型的上下游聯動；
- 各種特殊時間的處理，比如促銷的數據怎么使用？在雙十一這種特殊場景如何建模等等？
- 端上信息的建模（雖然建模方式類似），但是對于邊緣技術等要求在不斷提高；
- 模型的壓縮，降本等；
- 模型資源配置：
- 隨著算法紅利越來越少，模型怎么也不可能達到100%的效果，越往后往上的紅利將會越少，后面整個算法組一年也很難提升1%，這個時候可能就會考慮計算資源縮減的問題，即降本的問題，所以此時會考慮模型機器內存等的工程問題，進行降本；
- 模型管理，文檔/Code沉淀管理/指標監控管理：
- 很多團隊初期瘋狂輸出，提升模型的效果，但并不是所有人都有做文檔的習慣，做Code的沉淀，后期可能更多的會關注在這塊；
- 很多東西初期、中期、甚至后期都很亂，包括線下/線上嘗試評估之類的，代碼管理，指標監控等等；
上面的內容側重在提升轉化率的問題方面，當然能做的肯定不止上面所列舉的。隨著平臺的發展，平臺老大對于平臺的定位不同，比如考慮平臺的健康發展，就會考慮曝光的商品數，用戶的復購率等等，換了指標之后可能要做的東西又可以再來一套。隨著時代的發展，很多新的元素的融入，比如現在的視頻直播帶貨等等，這些元素又可以做好幾年，整了半年的模型，只能感慨：活到老，學到老，碼到老啊！
總結
以上是生活随笔為你收集整理的搜索推荐系统实战：终极奥秘的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 负样本修正：既然数据是模型的上限，就不要
- 下一篇： 搜索推荐系统实战：进化篇