阿里新一代Rank技術

導讀: 本文的主題爲新一代Rank技術,由來自阿里巴巴定向廣告團隊的周國睿老師分享,主要介紹當前團隊在排序算法方面的新工作和新想法。

01 新一代Rank技術背景介紹

在分享之前先介紹下阿里巴巴整個淘系內部的定向廣告形態。

1. 電商場景下定向廣告形態

電商場景下定向廣告的形態主要分爲兩種,一種是非商品主體的,比如首頁焦點圖上的Banner廣告,主體可能是一個店鋪,或者是一系列商品的集合頁。另一種是以商品主體的,本身是商品的一種展示,這兩種不同的廣告形態,在定向廣告業務中都存在,且各自扮演着重要的角色。廣告顯式展示給用戶的內容主要是一些圖片和文字,同時在系統內部廣告是用賬戶體系ID來描述的,比如廣告ID,Item ID,Shop ID等。排序系統中很重要的一件事的是預估在一個場景下給出用戶和一個廣告,以及用戶對廣告的操作反饋。

2. Delineate Rank

這裏簡單介紹一下我對Ranking問題的一個理解。Ranking特別是在電商場景下,要做的是生成一個有序的topk的最終展示結果,讓展示結果是挑出的最好的集合,並以一個最合理的順序去展示,使收益最大。對於Ranking 技術來說其Fotmulation是在有限的計算資源的情況下如何去最大化展示的集合,使整個Rankging的結果收益最大化,需要在有限的算力下去設計有效的算法-架構,使得最後的Ranking的結果變得更好。

前幾年因爲硬件計算能力的發展以及整體互聯網行業的蓬勃發展提供了足量的數據,Ranking相關的算法進入到深度學習時代,模型、技術創新層出不窮。但是近期技術逐步進入到深水區,特別是近段時間深度學習的基礎技術沒有太多的突破,整個算法紅利在近幾年逐步消失。從我們自己團隊的視角來說,以一個比較侷限的視野來看,從MLR到DIEN,一直到SIM,整個效果的增長是有的,但是整個算力的需求也在增加,在同樣的算力需求下對效果的增長的邊際已經非常明顯,此時我們的算力也觸碰到了瓶頸。

面對這些問題我們團隊能做什麼?

挑戰&機遇

  • 模型持續深挖:在資源有限下尋找更有效的算法、模型設計。形成單點效果空間突破-> 堅持模型創新。我們選擇在整個Ranking模型上去持續的做創新,認爲Ranking model還是有比較大的空間,希望能引入一些業務和產品上新的insight和對模型一些新的理解,在單點打開空間,做出一些突破。
  • 架構&算法co-design:堅持設計思路上兼顧算法和架構,更柔性的算法和架構關係->架構&算法同步向前。堅定架構&算法co-design的一個思想,架構和算法一定要同步往前跑,不能先有算法再有架構或者先有架構再有算法。算法和架構無法達成一致的步調是不符合實際的技術需要的,更多的時候可能是團隊合作的問題,這樣的情況下去做技術的創新成本會比較高,迭代效率也會比較低。
  • 算力危機:DL技術迅速吞噬硬件帶來的算力紅利,算力需求增量帶來效果增長邊際效應明顯->需要把算力優化納入算法視野。DL的技術和以前的技術有比較大區別,他的更新迭代頻率非常的快,很快的就把業界這幾年積累的硬件算力的紅利開銷掉了。這導致我們的算力瓶頸會非常明顯。雖然計算成本隨着時間依舊是線性增長的,但商業機構的預算是有限的,特別當你處在一個急要還要且要的環境。所以我們需要把算力的優化也納入到整個算法設計中和算法優化中。而不是簡單的把它當做一個獨立的、外沿的限制條件。

3. Outline

接下來我分享兩個方面的工作:

算法 | 定向廣告新一代CTR模型:Search-based Interest Model ( SIM )

SIM是我們建模用戶全生命週期興趣的工作,讓模型使用的用戶行爲的信息長度從過去的1000提升到10000的量級,這個量級應該可以在大部分的場景進行建模的用戶全生命週期的用戶行爲。

算力 | 定向廣告新一代個性化算力引擎:Dynamic Computation Allocation Framework ( DCAF )

DCAF是在算力分配方面的工作,我們設計了一套新的算力視角下的一個引擎方案:動態算力分配。主要思想是面對不同的請求流量和請求用戶來分配不同的計算資源用不同的算法方案來處理,以達到在一定的有限的資源下系統收益最大化。

02 回顧定向廣告模型

1. 回顧定向廣告模型

先回顧下阿里巴巴的定向廣告模型的發展:定向廣告在16年通過一個比較簡單的embedding&MLP的方式進入到一個深度學習的領域,在16~18這3年裏在電商這個場景沿着興趣建模的視角,提出了DIN和DIEN。不過從最早的MLR到DIEN的工作中很多的用戶行爲的序列信息使用長度都集中在100這個量級,視角都集中在用戶近期或者說實時的興趣該如何建模。

在18年~19年我們開始嘗試做長期用戶興趣建模的工作,提出了MIMN,把用戶行爲序列的建模提升到了1000這個量級。在後續是持續想做用戶全生命週期的建模的工作,最近我們公開了一個新的工作Search-based Interest Model,把整個用戶行爲序列建模的長度從1000提升到10000的量級,這是一個平均的數字,我們統計實際最長用戶大概是50000的量級。這個能力可以認爲是能覆蓋其互聯網的全生命週期的用戶行爲序列建模。

2. 談談爲什麼要做life-long視角用戶建模

在講Search-based Interest Model是什麼之前,談談我們團隊爲什麼一直堅持要做life-long視角用戶建模。

電商和線下購物的區別

電商優勢在於更高效的信息交互。在app上瀏覽商品,成本很低,幾秒鐘就可以看很多的商品,如果要瀏覽具體商品的詳情頁要點擊進去可能不到 1 分鐘,結構化的信息就會展示在你面前,交互非常便捷。用戶和系統的交互會比線下購物發生更頻繁的交互行爲,也讓我們拿到更多的數據,電商很大的優勢就是可以利用互聯網積攢起來的用戶的行爲數據和用戶的數據來給用戶提供個性化的服務。雖然電商的整個交互的行爲很多,但是還是有一些問題的。以淘寶舉例,它是處在興趣釋放的末端的,很多的行爲數據是偏決策結果的數據,而不是決策邏輯的數據,舉例:我昨天看這就是街舞,覺得dancer們hiphop的穿搭很好看,於是我產生了新的興趣去買相關的商品,在淘寶裏邊通過搜索瀏覽相關的商品,淘寶人知道的是你近期瀏覽了hipphop相關的商品,以及發生的一些行爲,但是他並不知道這個興趣觸發的邏輯。

而線下的購物是不一樣的,線下的時候雖然我們瀏覽商品的效率較低,但是對每件心儀商品做決策的邏輯信息是更豐富的。比如我們可能會和導購溝通材質,溝通品牌理念,溝通季節,購買用途等等。只不過線下雖然獲取信息更豐富,但是卻沒有有效記錄信息的技術。

淘寶等處於成交末端或者說興趣末端,沒有用戶關於決策邏輯的數據。這就要求電商要想發揮優勢,需要更好的利用用戶的決策結果數據,也就是行爲數據,我們纔有可能去推斷用戶背後決策的邏輯,更好的建模用戶的興趣變化和當前的興趣。

過去Ranking相關的算法通常比較"短",普遍只能有效利用大概100個量級的行爲數據,也說明了只是觀測了很小的一部分的data。我們以淘寶爲例,大部分用戶行爲數據,如果統計一個比較長的週期,其交互行爲量是遠超100的量級的,甚至有的用戶到50000多次。如果我們只用用戶近期的或短期的一些用戶行爲建模模型會引發非常多的問題。當然我們可以安慰自己說生產線上不能理想化,但是這個做法本身是在忽視用戶的長期的興趣,或者用戶長期堅持的興趣偏好在系統裏的一個表現,某種程度上是不夠尊重用戶的。

如果只用用戶的短期行爲訓練模型具體會帶來哪些問題呢?

熱點支配的問題

比如最近突然一個熱點出現了,這種風格或者商品非常熱門,好多用戶都有與之相關的交互行爲。那這些用戶的所有興趣都在這個熱點上麼?其實並不是,這可能只是短期的熱點效應。如果從用戶全生命週期的行爲來看,所有用戶都是不同的,他們都有自己獨立的興趣。但是我們只關心短期的的用戶行爲序列,這些不同是無法發現的,模型很可能因短期的用戶行爲誤判,被這些熱點所支配,給所用用戶都推薦熱門。

長期興趣的缺失

很多的用戶的長期興趣比如對價格、材質、風格的偏好等,只是用短短的100個左右的行爲是很難建模這些信息捕捉用戶長期的偏好的。即使在短期的用戶序列裏,用戶的行爲也是多種多樣的,類目豐富的。這樣具體到某個方面,比連衣裙這個類目,可能最近的100多次行爲,只有兩三次或者五六次的行爲與連衣裙相關。顯然這麼少的行爲信息很難確定用戶的購買風格和對材質的要求。

系統視野侷限

這個是個更嚴肅的問題,當前的推薦或廣告系統大部分的技術是data-driven。數據訓練模型,模型決定展示的結果從而決定收集的數據。這是一個數據閉環,如果在這樣的框架下,我們僅通過短期行爲去建模用戶興趣,整個系統會被鎖死在一個短期興趣視野下,看不到甚至不知道長期興趣對結果會不會有效果,因爲這不在系統的觀測視野內。

因此我們一直堅持去做用戶全生命週期的用戶建模,我們認爲這樣的建模思路也是在更尊重用戶。

3. life-long視角用戶建模挑戰

長期興趣面對的核心挑戰並不是過去提出的算法方案在離線階段建模精準度不夠,或者無法建立長期興趣的模型。而是在於我們試圖解決的是一個真實世界的一個問題。過去的算法方案如果試圖建模長期興趣,那麼這樣的算法複雜度對於在線系統來說是一定無法接受的。比如我們套用之前的DIN和DIEN,對一個10000長度的用戶行爲做服務,算法複雜度在用戶興趣的計算方面會隨着用戶長度的增加而線性增加,那麼可以想象我們線上的服務性能是無法抗住這樣的壓力的。另一點是真實的在線預估系統,對一個用戶請求,需要對非常多的廣告做預估,並且實時的去請求用戶的行爲序列數據,那麼在線的存儲和在線的數據的通訊都會隨着用戶行爲序列的增加而線性增長,這些問題看上去似乎是不可解的。

4. Memory-based模型嘗試:MIMN

在18年和19年我們嘗試去解決長期興趣建模存在的相關的問題,做了個Memory-base的一個方案MIMN。MIMN的想法是我們過去算法的問題在於算法複雜度和算法行爲序列長度在在線部分線性相關的,如果我們有個辦法可以用Memory矩陣來去encode我的用戶行爲序列,把一個變長的用戶行爲序列無論其長度是多少,都encode到一個固定size的Memory矩陣去。那我們在在線的時候就用這個固定size的Memory矩陣去計算相關的ctr,這樣把興趣建模的計算和CTR預估的在線計算解耦開來,異步進行,興趣建模的計算就不再是在線預估的瓶頸。

MIMN的思想是對用戶的每一個新增行爲,去判斷該行爲是屬於哪個方面的興趣,對應的寫入到Memory矩陣中對應的slot去更新該方面興趣的描述。用一個固定size的Memory矩陣去記錄用的多方面的興趣。那麼這個興趣記錄的過程是和單純的ctr預估是解耦的,MIMN能把我們整個用戶行爲序列的建模拉長並且能解決之前的問題。

5. Memory-based方法的問題

在解決了諸多的挑戰把MIMN真實的落地後線上後,它確實有顯著的效果,但是很遺憾還是有很多的問題:

一個是在系統的可迭代性方面存在很多問題。工業界要解決的問題和學術界不太一樣,不是一個靜態的問題或者某固定的數據集,去刷指標就可以了。工業界要解的問題是一個動態的問題。比如我們每天用戶的行爲都會新增,每一天都會遇到一個新的樣本,每一天模型的參數可能就需要實時的更新來捕捉這些數據的變化。那MIMN的問題就出現了,我們不停的把用戶的行爲通過memory的方式encode的到memory矩陣中去,那麼這個encode的方式不論是embedding的方式或其他方式寫入,我們是以什麼樣的頻率去更新encode本身的參數。那假設上一個版本的encode參數已經把一部分行爲信息寫入memory了,那麼encode的參數更新後,要不要把它擦除掉。然後把所有的用戶的行爲序列都要寫入或者全量更新一遍。全量更新一遍的代價是很大的,我們該怎麼解決這些問題呢,這些問題就很複雜。在MIMN的paper中我們就已經詳細的討論了怎麼去緩解這些問題,確實是有些方案能緩解這些問題,但是確實增加了系統未來迭代的負擔。

另一個問題也是比較致命的,因爲我們面臨的是一個真實的線上系統。那麼受限於計算、通信、存儲各方面的壓力,MIMN的memory size也不能是無限大的。要在一個有限的空間裏去encode一個10000量級長度的用戶行爲信息,在現有的memory net work相關技術上我們沒有找到可行的方案來避免這些行爲數據中的信息重複、信息噪聲、信息漂移等問題。在我們的場景,MIMN做到1000的長度,在更長的長度幾乎就失效了。

6. 回顧定向廣告模型

再回看興趣建模帶來的啓示:

從DIN和DIEN來看,興趣建模的一個關鍵點是用候選的目標商品信息和廣告信息對用戶行爲信息做Search,提取行爲信息中有效的部分,輔助建模最後的CTR預估。簡單來說就是說把用戶行爲裏面和候選目標商品相關信息搜索出來,然後去建模,效果很好。但是MIMN無法對原始用戶行爲信息做搜索,因爲MIMN已經提前將用戶的行爲信息做了一次encoding。但是encoding必然會遇到噪聲的問題。我們需要找到一個方法可以通過目標商品的信息對用戶全生命週期的信息去做搜索,根據搜索到的相關信息做預估建模。如何有效和高效的對用戶全生命週期的用戶行爲信息做search呢,沿着這個思路出發我們做了Search-based Interest Model。

03 定向廣告新一代CTR模型

1. 定向廣告新一代CTR模型:Search-based Interest Model

Search-based Interest Model的整個思路如上圖所示,直接用類似DIN或者DIEN的方案對全行爲序列search無疑是在線計算時無法接受的,因此我們想到了能否把搜索解開來,在文中我們提出了兩階段的search模式:general search 和 exact search。從精度角度我們將搜索拆解爲一個相對粗糙普適的搜索和一個更爲具體精確的搜索。從計算過程角度我們希望general search的大部分計算可以離線完成,並且將歷史行爲的數量縮小到幾百的量級,給exact search部分的建模保留充足的計算複雜度空間。

具體來說我們知道候選的商品信息是什麼,我們拿到需要被預估的商品信息後,可以像信息檢索一樣,對用戶的10000多個行爲序列構建一個快速查詢的索引。待預估商品的信息可以當做是一個query去用戶的所有行爲中,查詢與其相關的行爲子序列。這個行爲子序列的長度是可以根據系統能力和使用場景控制,比如是100個量級。到100這個量級,如何去利用這個子行爲序列的做法就很多了,比如說DIN,DIEN等方法都可以使用,這時候可以做一個比較精細的信息建模,比如說ctr建模。

2. General Search

General search我們在文中提出了兩種方案,第一種方案是參數化、較通用的一種方案,我們稱之爲soft search。此方案我們把用戶的原始行爲信息和候選的目標商品向量化,讓這個向量化具有空間度量性,比如說相似的或者相關的商品在內積空間裏距離更近。如此,通過一些最近鄰相關的一些檢索,比如說MIPS的一些方法,依此構建一個高效的索引,在線時候就能很快的根據候選商品信息,對原始長度10000的行爲序列,檢索到一個長度可能在100左右的相關用戶行爲子序列。這個思路和很多團隊採用的向量召回的思路比較相近。值得一提的是怎麼去做向量化,SIM不是做的相似的度量,而是單獨的建立了一個點擊預估任務。因爲我們的目標不是讓相似的商品近同,而是讓候選目標商品是通過向量距離找到和自己ctr預估的相關的行爲,最後的目標是一個ctr的任務。對用戶的所有行爲序列的向量化,通過內積判斷一個權重,使得點擊率預估的更準,找到使這個點擊率更相關的這部分行爲子序列。如果直接把用戶的原始行爲子序列輸入,那麼離線訓練可能達到10000長度,訓練上也不太能接受。但是這個模塊實際上需要訓練的是對行爲id和商品id的向量,而不是把點擊率預估的多準。所以這裏有個技巧,可以對樣本的原始行爲序列進行隨機採樣,比如把10000的長度直接採樣到1000或100使得訓練引擎能承受的級別,這樣依舊可以滿足向量的訓練。這部分我們進行過測試,採樣和切入一小部分數據不採樣,最後的效果是接近的,能保證這個向量是可以用於構建快速檢索索引。

另一個General search的方案是我們把它稱之爲Hard search。在實踐過程中,我們發現電商數據天然的賬戶體系或者結構性讓general search有更簡單的實現方式。電商場景用戶行爲大部分交互對象也是item,item有其固有的類目信息category,我們可以對每個用戶的歷史行爲基於category構建一層索引,類目相關的行爲可以離線進行掛載。整體用戶的行爲數據會被構建爲一個key1-key2-value的結構,一級索引 key1爲user,二級索引key2爲類目category,value爲該類目下的行爲序列,或者也可以進一步擴展爲類目相關的行爲序列。在線的時候根據用戶信息以及每個預估目標商品的類目進行general search,得到一個和當前item相關的子序列。general search後的結果根據我們的數據特性大致會從幾萬的原始行爲量級降低到幾百,這個量級就可以輕鬆的完成在線通信、實時的exact search計算以及CTR的計算。需要注意的是無論是索引結構存放的數據和general search後的結果,都是用戶的行爲序列原始信息,可以是原始的ID序列。這樣保障了我們對信息僅僅做了general search這一步選擇維度的過濾,沒有類似embedding這樣的信息壓縮,最大程度的保留了原始信息。

當然了這種簡化的general search在我們的離線實驗中表現的效果還是弱於基於向量檢索的方式,但是其實現成本非常低,只需要有一個支持key-key-value存儲的data base就能輕鬆的實現。同時在線計算部分只增加了exact search的計算開銷,能比較輕鬆的在線服務。並且其對未來的進一步模型迭代也未增加太多成本。綜合下來我們選擇了這個簡化版本的SIM。用category或者其他粒度合適的item描述信息作爲一個固定的索引結構,新增的行爲可以增量的更新這個索引,訓練的時候索引部分是非參的,不會在訓練過程中變化。因此可以用最新的檢索結果可以對所有的參數進行端到端的訓練,相當的輕便,非常適合在實際工業場景中部署。當然所處的數據環境如果沒有對行爲數據進行類似category這樣的結構化處理,那麼就得想辦法構建其他的索引結構了。

3. SIM視角下的RTP系統

整個Search-based Interest Model 以 Hard search的方案上線後對整個RTP的系統的改造是比較小的。在線預估時會先計算待預估的商品候選集合,一共有多少個unique類目 ( 我們的系統裏平均有幾十個 ),我們再把userid和類目id拼起來,拼成可能提出的請求的key1-key2請求串,去請求構建好的歷史行爲索引,把相關的長期行爲子序列拿過來,做ctr的預估。SIM對比上一代模型在QPS性能上表現的其實是差不多,但是RTP的rt會增加5ms左右的時間,原因是exact search部分對長期行爲子序列的處理增加了計算,會有一部分的時間開銷。同時增加了一個額外行爲序列的請求,即使是並行也會增加一部分rt。相對於SIM帶來的增益,5ms對我們來說是可以接受的。最後我們用hard search 模式的SIM在線上取得了不錯的效果,具體數字不再介紹,只要是有過相關工作的朋友都會知道這種方法肯定是有效的,這種效果來源,並不是我們模型設計的多麼精細,而是我們有效的用到了更長的用戶行爲序列。

4. SIM效果

這裏面有值得一提的一點是,過去我們在短期行爲序列建模的時候,行爲發生的時間信息,我們驗證了大部分是沒有效果。但是在長期行爲序列裏,特別是幾年的行爲序列,時間信息就變得有效了,具體time info的使用論文裏有介紹,這裏就不細節展開了。

右邊這個圖,是我們想去驗證SIM做long-term的興趣建模時到底有沒有做到長期興趣建模?我們統計了DIEN和SIM在實際在線的推薦結果。d_category的定義:與用戶點擊的item 類目相同的行爲最近發生日期離當前的天數。同時我們簡單的將過去14天內的行爲類目覆蓋的點擊行爲定義爲短期,超過14天的定義爲長期。比如圖中40~60這個部分,就是指SIM推薦且被用戶點擊的item,該用戶在過去的僅在40~60天有過同類目的行爲,在其他時間都沒有與相同類目的item發生交互。同時縱座標表示SIM的推薦且被點擊的item在不同興趣時間跨度上的數量,我們可以看到雖然SIM和DIEN主要的推薦結果還是集中於近期部分,但是在長期部分SIM的推薦且被點擊的結果是顯著高於DIEN的。這說明SIM真正更多的推薦出了用戶偏向長期行爲相關的結果,且用戶進行了點擊,側面說明SIM相對更好的建模了長期興趣。相對DIEN來說SIM真正的給用戶展示的更多長期興趣相關的東西並且用戶點擊了,說明用戶對此感興趣,這是有效的推薦。這對我們來說是一個非常興奮的消息,也說明一直以來我們堅持的事情得到了印證。這個思想我們也開始召回、粗排等模塊進行嘗試,並且取得了一些初步效果。

04 DCAF動態算力分配

接下來我們將分享工作,是在算力優化方面的工作,在這個方向其實我們做的工作比較多,因爲時間關係,這裏介紹比較新穎的一個,給大家介紹下:DCAF動態算力分配。

我們先來回顧一下過去的算力、架構算法的關係。在深度學習時代之前,因爲整個模型的變更,包括架構的變更頻率非常短,可能大部分的時候的模型都是不變的,我們在做一些關於數據流、或者特徵相關的工作。在這種情況下,算力更多的時候像是一個約束條件,少有和算法以及系統架構聯合起來考慮。

但是深度學習時代不一樣,深度學習模型開發成本比較低,誰都可以試一試。整個的模型變化頻率比較高,同時不同的模型之間的算力需求相比差別非常的大,同時模型OP單元化,一個模型型的整個算力開銷基本上是可預估的,這個時候就給算法、架構、算力聯合優化提供了條件。

1. 傳統Cascade System

接下來介紹的工作,主要解決的是系統引擎裏的個性化算力分配相關工作。

過去展示廣告或者推薦系統因受最大資源限制,會把給一條請求從全商品庫到最終展示結果的流程分爲好多個模塊。一般分爲:召回、粗排、排序,重排等模塊。各個模塊的候選集大小依次縮小,把大的問題切成好多個子問題,團隊中人員組織也往往是這麼分配。每個子模塊自己的一個目標,有自己的一個候選集的大小,有自己的計算資源等等,用這種方法還挺好的,也挺有效的,把這個複雜的問題,切分成幾個子問題,但他一定不是最優解。舉個例子,這裏面每個模塊的候選集到底該是多少,什麼樣的大小是最合理的?每個模塊應該投入的成本是多大?每個模塊該給他分配多少的計算資源,給他多少的rt時間,很多時候可能大概率沒有在這方面考慮優化,甚至他可能還會引發一些團隊的一些摩擦,比如說我做Ranking的,這個地方模型rt時間做的長了,別人的空間就變小。如果從全鏈路的去考慮這件事情,這種cascade system一定不是最優的,還有一點,我們每個模塊兒的結果都在注重個性化,不同的用戶或者對不同的請求的結果是不一樣的,那麼問題就來了,爲什麼這個鏈路整個引擎的設計思路以及算力分配的這個方案,候選集的大小,模型要給每條流量一模一樣,爲什麼不能對不同的流量候選的大小不一樣,或者算力分配的資源不一樣,Latency限制不一樣,整個模型不一樣,這個地方自由度是一定能夠帶來效果的收益,在有限的計算力的情況下,去優化整個的結果,那所以我們就定義了這樣的一個個性化商品分配的一個問題。

2. Why個性化算力分配

因此我們希望探索一個問題,對於系統的每一條請求,在不同的算力限制下,得到不同的算法方案,最後結果的系統收益其實是不同的。舉個例子,我們客觀的來講,對於不同的用戶請求來說,對於廣告收入來說,不同的用戶潛力肯定是不一樣的。整個收益價值如平均的ecpm是不一樣的。如果在推薦上假設我的目標要優化整個成交額,不同的用戶,在不同的時期,當時的購買力都是不一樣。對於最大化的系統的收益來說,每條流量的潛在收益不一樣,那麼我們爲什麼要給每條流量分配同樣的計算力?用同樣的計算方案?能不能夠,比如說對算力不敏感的流量,分配少一點的計算資源,對價值很低的,分配少一點的計算資源。對於那些潛在價值高,同時對算力敏感的流量提高算力,提高模型複雜度。不僅是算法結果不同,而是對不同的流量算法方案也不同,做到真正的個性化系統服務。

3. DCAF

我們這裏把整個動態算力分配定義爲一個組合優化的問題。

i:流量,j:算力分配方案

qj:執行算力方案j時,計算資源消耗

Qij:對於流量i,執行算力方案j時,取得的收益

C:總體最大計算資源上限

計算資源是各種各樣的,我們要使得累計起來的計算資源,在這個C的業務限制下,我們去最大化,得到最大化收益

Xij意思是在i上選擇各種方案j。最後問題轉化爲對偶優化問題,這裏推導就不展開了,最後可以發現,整個全局最優可以推導到單條流量的具體的最優方案,那這種情況下就能對的整個算力做一個更優分配。

4. DCAF調控

這個想法是做個性化算力分配,實現平臺算力收益空間最大。在在線系統看來,不僅僅以這個流量視角可以分配不同的算力或者用策略讓整個的收益空間更大,或者達到同樣的收益的情況下用的計算資源更小。同時,我們還能根據在線系統的狀態去動態地調節我每一條流量的最大算力的C,從而保障系統穩定性。比如在一批流量最大化的算力上改變C,晚上可能會整個流量比較低,那我可以根據我在線系統的latency、QPS,GPU 使用率等系統指標來動態地調整算力的上下限,讓我們的系統保證一定是在一個平穩的狀態下運行的,而不是人工的去運維。我們可以通過C來動態的調解系統資源邊界,同時動態的調節各個算法。這個方案在618的時候開了一個實驗集羣,做實驗非常有效,首先這個系統的運行非常平穩,無論說當前的狀態怎樣,第二點是我們確實能夠在達到同樣的廣告效果,比如關注的收入,在保證收入和點擊率的這個情況下,我們可以達到用更少的計算資源就能完成。

5. DCAF實驗結果

這裏是用歷史的真實數據做的模擬情況。

圖中上面兩紅色條線指用同樣的算力,既用同樣的計算資源C不變的情況下,做平均分配或者做動態分配,可以看到在最高點的時候ecpm會增加3.7%。下面兩條黃色線對比,在保證動態分配方案的ecpm和平均分配是一樣的情況下,算力可以減少多少,可以看出計算資源能夠減少49%。假設要減少49%的計算資源,不以最優化分配的策略而是隨機的來分配哪些流量增加算力,哪些流量減少算力,則整個ecpm會達36.8%的降幅。而DCAF通過這個模擬可以看出是不會有任何ecpm的損失的。圖中的數據是通過歷史數據離線模擬的情況,因爲我們在真實求解的時候,Qij每條流量不同的算力方案執行的收益是不確定的。舉例說明,比如說qj可以是不同的模型,對不同的流量採用不同的模型,也可以是不同的流量採用不同的候選集大小方案,這個收益在離線時候可以通過日誌可以模擬出來,但是對於沒有去付出算力的情況下,是要通過預估,預估就會帶來一定的精度漂移。實際上,在做到同樣的ecpm水平的情況下,我們在線只能減少大概25%的計算資源開銷。

相關工作的細節是有公開的,大家可以去閱讀相關論文,有相關的問題和想法,可以跟我郵件溝通。

05 心得分享

最後,分享一點心得:

第1點 ,算法&工程co-design,定向廣告團隊持續的做一些微小的工作,有個很大的因素在於算法和工程非常和諧,並且共同的堅持算法&工程co-design的一個理念。大家都認爲在最初設計的時候,要共同考慮算法&工程,算法&工程同步前進。這個合作關係就不只是嘴上說說,更多是做出來的。很多時候這些項目是共同來考慮,這就讓我們整個迭代的成本降低了,在最開始選擇方案的時候,不需要算法證明什麼,或者工程今天就要搞這個技術路線,之後算法再受限的迭代。這種緊密的合作保障在設計方案之初,就從算法&工程的視角協同考慮,整個迭代成本非常低,迭代的速度變快。

第2點 ,從作爲算法工程師的視角來講,雖然現在技術是Data-driven的,但是算法工程師自己是不能僅唯數據論,做算法研究不能把目標定義爲在某個data下,提升某個技術指標,或者只關心現在看到這個結果。有很多task的一些問題,因爲整個數據循環,很難通過唯數據論就找到大部分的答案。如果算法工程師也跟model一樣,僅僅通過數據現象去指導自己的思路。我們就會像線上的模型一樣,被數據探索空間限制住。模型本就是我們這些技術人員設計出來,如果我們也只從當下看到的數據裏面去找答案,那麼我們的視野也是侷限。我們需要有對一些問題有更多的相信和堅持,如explore、fairness、尊重用戶,我們相信去研究這些問題是有收益的,我自己非常相信這一點,一直以來堅持這一點。我們要做的事情不僅僅是提升目前數據上的一個指標,而是提供更好的技術能力,更尊重用戶,提供更好的服務,把這系統裏面我們能知道的,我們去相信有人性的一些問題解決掉。我相信未來會有更多的同學能夠加入相關的研究當中來,現在看到的相關的工作還比較少,但是肯定會在短期之內就會有一些非常有代表性的工作爆發出來。總歸念念不忘,必有迴響,相信這些堅持會看到一些結果。

作者介紹

周國睿,阿里巴巴高級算法專家

周國睿,北京郵電大學碩士。研究領域包括大規模機器學習、自然語言處理、計算廣告、推薦系統等。目前在阿里媽媽定向廣告團隊,負責排序算法和算法平臺相關的工作。研究成果發表於KDD/AAAI/CIKM等會議,其研究工作均落地於實際系統。

本文來自 DataFunTalk

原文鏈接

阿里新一代Rank技術

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