EdgeRec：揭祕邊緣計算在淘寶推薦系統的重要實踐

​1.前言

1.1 邊緣計算 v.s. 雲計算

在過去的這十年裏，依託於大數據，雲計算取得了很是耀眼的發展，與此同時也面臨着一些問題：隨着互聯網應用及用戶規模爆炸式增加，5G普及和帶寬增長會帶來雲端存儲的壓力；目前在線系統部署大規模神經網絡已經日益廣泛，對雲端計算產生巨大壓力；對一些實時性要求比較高的應用來講，與雲端巨大的通訊開銷也是交互和體驗瓶頸；同時雲端「中心化」的計算模式也會帶來運維成本和故障風險。

邊緣計算這個概念其實提出來也已經好久了，隨着近幾年終端設備的存儲計算能力的快速發展，尤爲是智能手機的性能（各類CPU、GPU的跑分，內存愈來愈大）已經成了主要的賣點，其計算能力目前看來遠沒有被充分利用起來。並且，邊緣計算的優點在於下面四點：1）數據本地化，解決雲端存儲及隱私問題；2）計算本地化，解決雲端計算過載問題；3）低通訊成本，解決交互和體驗問題；4）去中心化計算，故障規避與極致個性化。

1.2 推薦系統中的痛點

在全面進入無線的時代，爲了解決信息負載的問題，愈來愈多的推薦場景獲得興起，尤爲是以列表推薦形式爲主的信息流推薦。以手淘信息流爲例，進入猜你喜歡場景的用戶，興趣經常是不明確的，用戶瀏覽時每每沒有明確的商品需求，而是在逛的過程當中逐漸去發現想買的商品。而推薦系統在用戶逛的過程當中，會向客戶端下發並呈現不一樣類型的商品讓用戶從中挑選，推薦系統這個過程當中會去捕捉用戶的興趣變化，從而推薦出更符合用戶興趣的商品。然而推薦系統能不能作到用戶興趣變化時馬上給出響應呢？

推薦系統以往的作法都是經過客戶端請求後觸發雲端服務器的商品排序，而後將排序好的商品下發給用戶，端側再依此作商品呈現。這樣存在下面兩個問題：

推薦系統決策的延遲：因爲雲端服務器的QPS壓力限制，信息流推薦會採用分頁請求的方式，這樣就會致使雲端推薦系統對終端用戶推薦內容調整機會少，沒法及時響應用戶的興趣變化。以下圖所示，用戶在第4個商品的交互代表不喜歡「摩托車」，可是因爲分頁請求只能在50個商品後，那麼當頁後面其餘「摩托車」商品沒法被及時調整。

對用戶行爲的實時感知的延遲：目前推薦系統的個性化都是經過把用戶與商品交互的行爲做爲特徵來表達的，可是用戶的行爲實際上是發生在客戶端上的，推薦系統模型想要拿到用戶的行爲特徵須要把端上數據下發到服務端，此時就會形成延遲的問題，以下圖所示用戶行爲的延遲可能會達到10s~1min。於此同時，因爲網絡帶寬延遲的問題，其餘大量的用戶細節行爲（如商品的實時曝光、用戶的滑動手勢等）是沒法進行建模的。

總結來看，目前推薦系統的痛點是，用戶偏好的變化與推薦系統對用戶感知和對內容的調整時機並不能匹配，會出現推薦的內容並不是用戶當前時刻想要的，用戶瀏覽和點擊意願都會降低。

1.3 邊緣計算+推薦系統

邊緣計算的優點，是讓邊緣節點（這裏指手機端上）具有了「獨立思考」的能力，這讓部分決策和計算再也不依賴於雲端，端側能夠更實時、更有策略的給出結果。說到實時性，5G時代的到來，其低時延特性極大的下降了端和雲的交互時間，但這並不影響咱們利用端智能實現更低成本的決策和快速響應，反而對於端智能來講，好處是能和雲端結合的更緊密。另外因爲在端側可以秒級感知用戶意圖作出決策，產品和用戶貼的更近了，這催生了更多實時性的玩法，產品將再也不侷限於要到固定的時機如分頁請求讓雲端去給到新的內容反饋，而是思考，當用戶表達出來特定的用戶意圖時，產品應該如何提供與意圖相匹配的內容。

EdgeRec端上推薦系統即是藉助於邊緣計算的這種實時感知性和實時反饋性，來解決目前Client-Server架構推薦系統的實時感知、實時反饋能力不足的問題。EdgeRec推薦系統提供了端上用戶意圖感知、端上重排、端上實時插卡等能力。經過在端側秒級感知用戶意圖作出決策，並提供與意圖相匹配的反饋，提高用戶的點擊意願與瀏覽意願，總體改變瀑布流的體感。

2.端上算法模型

2.1 概述

以下圖 (a) 所示，EdgeRec中端上的推薦算法模型主要包含了「端上實時用戶感知」和「端上實時重排」兩個模塊。其中，「端上實時用戶感知」被建模爲Heterogeneous User Behavior Sequence Modeling，包含了「商品曝光行爲序列建模 (Item Exposure (IE) Behavior Sequence Modeling)」和「商品詳情頁行爲序列建模 (Item Page-View (IPV) Behavior Sequence Modeling)」兩部分；「端上實時重排」被建模爲Reranking with Behavior Attention Networks (BAN)。接下來咱們會分別具體介紹這兩個模塊。

2.2 端上實時用戶感知

2.2.1 意義

首先，在個性化搜索和推薦中，「千人千面」來源於特徵的個性化，而「個性化」主要依賴於用戶的行爲數據，參考DIN[1] 等工做，它們都建模了用戶最近交互的商品序列，做爲個性化模型的輸入。可是，前面的工做通常只考慮了用戶和商品的「正反饋」交互（如點擊、成交），不多考慮到用戶與商品的「負反饋」交互（如曝光）。確實，「正反饋」特徵相對來講較爲明確，噪聲也相對較少；可是咱們認爲用戶與商品實時的「負反饋」交互也很重要，舉一個直觀的例子來講：某一類目的商品實時地屢次曝光後，該類目商品點擊率會明顯降低。

另一方面，以前的「個性化模型」的工做通常只考慮了與用戶「交互」的商品特徵，這句話的中心詞是「交互的商品」。可是，用戶與商品的「交互動做」其實也很重要，好比：用戶點擊商品後在詳情頁的行爲反應的是對這個商品真正的偏好，真實的數據裏面可能存在「僞」點擊的狀況；一樣地，若是用戶對某個商品雖然沒有點擊，可是用戶在這個商品上的曝光很是聚焦，也就是商品曝光的停留時長很是長，這種狀況也不能絕對說明這個商品的曝光未點擊表明了用戶不喜歡，尤爲在如今信息流推薦頁面裏面商品的圖片展現愈來愈大，也會透出各類關鍵詞，甚至能夠自動播放視頻，也許點擊對於某些用戶已經成爲了很是「奢侈」的正反饋了。

最後，咱們認爲用戶在推薦場景的「實時行爲」也會很是重要，好比：用戶實時點擊了不喜歡等負反饋，或者某個類目實時屢次曝光卻不點擊，這些都反映了當時用戶的實時偏好，所以推薦系統須要具有實時建模用戶偏好的能力，並及時做出調整。

總結來講，端上實時用戶感知的意義在以下5點：

2.2.2 實時行爲特徵體系

根據上文的分析，相比目前雲端推薦算法的用戶感知建模，端上實時用戶感知要具有如下特色：1）從「依賴正反饋交互「推動爲「同時關注正負反饋交互」，2）從「交互對象商品」改進爲「對商品何種程度的交互」，3）從「準實時交互」推動爲「超實時交互」。而這三個特色要靠端上特徵來體現，基於以上的三個特色，咱們與淘寶客戶端BehaviX團隊一塊兒設計了用於信息流推薦系統的端上實時用戶行爲特徵體系。以下圖所示，端上實時用戶行爲特徵主要包含了「(a) 商品曝光行爲」和「(b) 商品詳情頁行爲」這兩部分。

2.2.3 異構行爲序列建模

這裏有兩方面的異構，第一：「用戶行爲動做 (Action)」和「交互商品(Item)」的異構，第二：「瀑布流（曝光）行爲 (Item Exposure (IE) Behavior)」和「詳情頁（點擊）行爲 (Item Page-View (IPV) Behavior)」的異構。首先咱們介紹一下模型輸入的組織方式：1）用戶一個行爲定義爲一個 Pair <商品 (Item)，動做 (Action)>，行爲序列定義爲 List (<商品 (Item)，動做 (Action)>)；2）商品曝光行爲序列 (Item Exposure (IE) Behavior Sequence)，「商品」是一個曝光的商品，「動做」是用戶在瀑布流對這個商品的交互動做，如曝光時長、滾動速度、滾動方向等；3）商品詳情頁行爲序列 (Item Page-View (IPV) Behavior Sequence)，「商品」是一個點擊的商品，「動做」是用戶在詳情頁對這個商品的交互動做，如停留時長、是否加購、是否收藏等。

上面的模型圖 (a) 中包含了咱們對Heterogeneous User Behavior Sequence Modeling的網絡結構圖的框架，這裏重點說明兩點：1）「商品曝光行爲序列 (IE Behavior Sequence)」和「商品詳情頁行爲序列 (IPV Behavior Sequence)」先分別單獨進行建模，最後再進行融合（若是須要的話）。這裏主要考慮的是點擊行爲通常比較稀疏，而曝光行爲很是多，若是先融合成一條行爲序列再建模的話，極可能模型會被曝光行爲主導。2）商品特徵 (Item) 和行爲動做特徵 (Action) 先分別Encode後，再進行Fusion。這裏主要考慮的是商品特徵和行爲動做特徵屬於異構的輸入，若是下游的任務須要對具體的商品進行Attention的話，只有對同構的輸入Attention纔會有意義，後面講到端上重排模型的時候會再重點說一下這個問題。

這裏，商品特徵序列 (包括 IE Item Sequence和 IPV Item Sequence) 使用GRU網絡進行Encode，動做特徵序列(包括IE Action Sequence和IPV Action Sequence) 直接使用Identity函數進行Encode。商品序列Embedding (包括 IE Item Embedding和 IPV Item Embedding) 和動做序列Embedding (包括 IE Action Embedding和 IPV Action Embedding) 的Fusion採用簡單的Concat操做，獲得行爲序列Embedding (包括 IE Behavior Embedding和 IPV Behavior Embedding)。

2.3 端上重排

2.3.1 意義

端上重排是端上推薦的基礎，擁有實時改變商品推薦順序的能力，能夠把端上重排看作用戶Local域的推薦優化，也就是在當頁推薦結果內進行優化。端上重排依託於實時用戶感知，根據實時的正 / 負反饋（曝光、詳情頁）和更細節的用戶行爲特徵，在信息流裏面不斷地對待排序商品進行從新排序，真正作到信息流的實時感知+實時推薦。

重排序這個任務不管在搜索仍是推薦領域其實都有不少前人的工做 2，這些工做的核心點其實就是context-aware ranking，這裏的context指的是待排序商品之間的上下文，對context的建模能夠多種多樣，好比：RNN，Transformer，或者人工定義全局特徵+DNN。

端上實時重排EdgeRerank這個工做也基於context-aware ranking的基礎，可是這裏的context不只僅包含待排序商品之間的上下文，還包含了用戶實時行爲（實時曝光商品、實時點擊商品、用戶交互行爲）的上下文。經過這些上下文信息，EdgeRerank能夠作到：我知道已經排了啥，也知道用戶在前面排序上的行爲，給我一個待排序的商品上下文，如何排能夠達到最優。下面重點介紹端上重排的模型框架，咱們稱做 Reranking with Behavior Attention Networks (BAN)。

2.3.2 Reranking with Behavior Attention Networks

上面的模型圖 (a) 中包含了咱們對Reranking with Behavior Attention Networks的網絡結構圖的框架。在背景中已經說過，EdgeRerank考慮了兩種上下文信息，對待排序商品之間的上下文建模咱們依舊採用經常使用的序列建模的方法，引入GRU網絡對商品集合進行Encode；爲了考慮到用戶實時行爲的上下文，這裏依舊採用了經常使用的方法，其實就是Attention（有時也被稱做target attention）。回憶一下實時用戶感知裏面，異構行爲序列建模的輸入：用戶一個行爲定義爲一個 Pair <商品，動做>，行爲序列定義爲 List (<商品，動做>)，其中「商品」指的是用戶與之交互的商品，「動做」指的是用戶和商品交互的動做。從上面網絡圖中能夠看到，Attention做用在待排序商品和行爲序列的商品上，其實也就是商品與商品之間。熟悉Attention的同窗應該知道 (Query, Key, Value) 這個三元組，這個模型裏面Query是待排序商品的Encode結果(Candidate Item Embedding)，Key是行爲序列的商品的Encode結果 (包括 IE Item Embedding和 IPV Item Embedding)，Value是行爲序列Fusion後的Embedding結果(包括 IE Behavior Embedding和 IPV Behavior Embedding)。用大白話描述一下motivation：對待排序商品集合裏某一個商品來講，先看看用戶交互過的商品都長啥樣，重點關注下特徵類似的商品，於此同時，再看看用戶在這些商品上的表現是啥，綜合起來都做爲這個商品排序的參考。

3.實驗效果

3.1 離線實驗

爲了驗證將端上實時用戶感知引入到端上重排做爲context的有效性，咱們首先進行了離線實驗。對比方法和實驗結果以下表所示：

實驗結果