在深度學習時代,算力的需求和消耗日益增長,如何降低算力成本,提高算力效率,逐漸成為一個重要的新課題。智慧算力旨在對流量算力進行精細化和個性化分配,從而實現系統算力約束下的業務收益最大化。本文主要介紹了美團外賣廣告智慧算力從線性規劃演算法到進化演算法的技術演進過程,給出了一種基於進化演算法的多動作算力分配方案,希望能給大家帶來一些幫助或者啟發。
1 業務背景
隨著美團外賣業務的飛速發展,外賣廣告系統壓力變得越來越大,算力開始成為新的瓶頸。2021年上半年,外賣廣告的數條業務線開始出現算力資源不足的情況,算力分配效率亟待提升。在外賣場景下,流量呈現明顯的雙峰結構,廣告系統在高峰時段面臨較大的效能壓力,非高峰時段存在大量算力冗餘。智慧算力旨在對流量算力進行精細化和個性化分配,從而實現系統算力約束下的業務收益最大化。
本文是廣告智慧算力系列文章的第二篇,在第一期《美團外賣廣告智慧算力的探索與實踐》中[1],我們對阿里DCAF[2]線性規劃求解方案進行了外賣場景下的優化,落地了彈性佇列區域性最優算力分配方案(以下簡稱“第一期”)。如上圖所示,外賣展示廣告鏈路中,召回通道和模型決策均使用固定策略,在算力不足時會丟失部分優質流量帶來的收益。
在本文中,我們提出了基於進化演算法的多動作算力決策方法ES-MACA(Evolutionary Strategies based Multi-Action Computation Allocation)。在外賣廣告鏈路上,同時決策彈性通道、彈性佇列和彈性模型三個動作。在後置動作決策中,我們考慮前置模組的決策引起的狀態變化,同時使用多工模型聯合建模實現系統模擬模擬(離線模擬+收益預估,實現不同決策動作下的收益評估功能),實現全鏈路最優算力分配。相對第一期內容,ES-MACA在外賣展示廣告業務線上取得CPM+1.x%、收入+1.x%的效果。
2 整體思路
為了應對極大的線上流量壓力和龐大的候選集,外賣廣告投放系統將整個檢索過程設計成候選集依次遞減的漏斗型級聯架構,主要包含召回、粗排、精排、機制等模組。在第一期中,我們把算力分配的手段定義為彈性動作,並結合外賣場景歸納了彈性佇列、彈性模型、彈性通道和彈性鏈路等四種動作,具體動作的定義如下:
- 彈性佇列:線上檢索是一個漏斗的過程,不同價值流量可以在級聯漏斗的各模組中分配不同候選佇列長度。
- 彈性模型:在模型預估服務中,對於不同價值流量可以選擇不同大小模型,大模型相對小模型預估效果更好的同時,消耗的算力也更多。
- 彈性通道:在召回場景中,不同價值流量可以選擇不同複雜度的召回通道和召回通道的路數。
- 彈性鏈路:在檢索鏈路上,不同價值流量可以選擇不同複雜度的檢索鏈路。
2.1 算力分配問題形式化描述
在一個包含M個算力決策模組的鏈路中,全鏈路最優的智慧算力的目標可通用的描述為:通過智慧化決策M個模組的算力檔位,在整體算力滿足約束的條件下,使得整體流量收益最大化。
該問題的一般形式化描述為:
以上是多個算力決策模組的場景,在外賣展示廣告中,對算力和收益較為敏感的決策模組為廣告召回策略、精排佇列長度和精排預估模型,分別對應彈性通道、彈性佇列和彈性模型三個動作。
在本期中,我們同時考慮彈性通道、彈性佇列和彈性模型三個模組的算力聯合決策。
在多個模組聯合決策時,同一個請求的不同模組動作之間互相會產生影響。如下圖所示,彈性通道決策結果決定了真實召回佇列(包括候選佇列的長度和廣告型別等資訊),直接影響了彈性佇列的輸入狀態。同理,彈性佇列的決策結果影響了彈性模型的輸入狀態。因此,在多動作聯合建模中,我們增加了請求“狀態”特徵,讓決策動作與系統產生互動,更好地擬合系統狀態的過程。
2.2 挑戰分析
外賣智慧算力第一期中,我們針對外賣廣告場景,在DCAF方案的基礎上進行了一系列探索和改進,並初次進行了模型彈性分配的嘗試,取得了不錯的收益。近年,阿里CRAS[3]方案給出了一種應用於預排、粗排和精排佇列聯合優化的聯合最優算力分配線性規劃方案。從彈性動作的分類來看,該方案以一種優雅的方式解決了三個彈性佇列的聯合優化問題,CRAS通過一些資料分析和合理假設,將原始問題拆解為三個互相獨立且相似子問題,然後分別對三個子問題進行求解。
但是已有方案是基於線性規劃方案的,且僅關注一個或多個彈性佇列優化問題,在面對非彈性佇列動作組合,如彈性通道和彈性模型時,方案無法直接遷移。特別地,在約束條件或優化目標發生變化時,線性規劃方案需要重新對特定業務問題進行建模和求解,需消耗大量的人力;此外,目前已有線性規劃方案的問題建模和求解過程中往往包含一些業務資料相關的強假設,這些假設在新的業務上可能難以滿足,這進一步使得已有方案難以擴充遷移到新的業務問題上。
由於外賣場景的LBS限制,外賣廣告的候選佇列相對非LBS電商場景較短,不需要經過複雜的預排-粗排-精排的過程。在全鏈路上,我們更關注召回通道、精排佇列長度、精排預估模型等模組的算力分配,這些模組其實對算力更加敏感。
整體來看,美團外賣廣告場景全鏈路最優算力分配的挑戰主要包括以下兩個方面。
通用化問題
- 挑戰點:已有方案與業務耦合過重,一方面,在約束條件或優化目標發生變化時,線性規劃方案需要重新對特定業務問題進行建模;另一方面,對特定的業務線,往往需要根據業務資料特性增加一些強假設。外賣廣告目前包括十餘條業務線,每條業務線中又存在多個算力決策場景,若對每條業務線的每個場景都單獨建模,人力成本巨大。
- 應對思路:採用通用解決方案並沉澱為基礎通用能力,為廣告業務的不同算力決策場景賦能,降本增效。
序列決策問題
- 挑戰點:在全鏈路算力分配時,多個決策模組之間互相耦合,共同對影響當前流量的最終算力和收益。如下圖所示,前置動作決策後,需要跟真實環境互動才能獲取動作決策後的互動結果,模組之間涉及到系統狀態轉移,需要在最後一個決策模組完成決策後才能獲得流量收益,這使得我們難以通過常規方式建模。
- 應對思路:在全鏈路最優算力分配問題建模過程中,增加系統在各鏈路上的“狀態”轉移過程,後置模組根據前置模組的決策結果和請求狀態進行決策。
綜合考慮以上兩個問題,我們將外賣廣告全鏈路最優算力分配問題建模為多階段決策問題(每個決策模組對應一個決策階段),按時間順序依次決策召回方案、截斷佇列和預估模型。每個階段中,由Agent與環境互動和決策,Agent引數可使用進化演算法或強化學習求解。
全鏈路算力分配過程可建模為馬爾科夫決策過程(Markov Decision Process, MDP)或部分可觀測馬爾科夫決策過程(Partially Observable Markov Decision Process,POMDP)。如上圖所示,狀態轉移發生在相鄰的兩個階段之間,各階段分別有不同的候選動作(如召回策略,截斷長度和預估模型編號等),Reward則在最後一個階段動作執行後通過系統反饋獲得。
我們可以收集線上日誌資料,使用離線強化學習(Offline RL)求解Agent;在不擔心線上收益受損的情況下,也可以使用線上強化學習(Online RL)求解Agent。但由於業務場景複雜,各階段算力約束難以統一,不管是離線強化學習還是線上強化學習,都面臨多階段強約束難以建模和求解的問題。
而進化演算法作為一種應用廣泛、魯棒性強的全域性優化方法,有以下優點:
- 避免區域性最優:進化演算法引數搜尋過程具有一定的隨機性,不易陷入區域性最優;
- 可並行化:進化演算法引數搜尋過程可並行,可緩解評估過程耗時問題;
- 應用廣泛:進化演算法可以能夠處理不連續、不可微和非凸優化問題,且不需要過多先驗知識;
- 簡單易用:一些進化演算法,比如交叉熵方法(Cross-Entropy Method,CEM)可以優雅地解決各種約束問題,不需要直接求解約束問題。
進化演算法能很好地解決外賣廣告場景中的問題,既容易擴充套件到其他業務線,又能非常方便地建模各種決策問題。因此,本期我們選擇進化演算法來求解外賣場景全鏈路最優算力分配問題。在後續工作中,我們會嘗試使用強化學習方案求解。
如本節迭代路徑(圖)所示,我們在1.5期中嘗試了基於進化演算法的單動作算力決策方法ES-SACA(Evolutionary Strategies based Single-Action Computation Allocation),驗證了進化演算法在算力分配場景的有效性。接下來,本文主要介紹基於進化演算法的多動作算力決策方法ES-MACA。
3 方案設計
為了實現廣告系統全鏈路上的最優算力分配,我們設計瞭如下決策方案:
離線訓練:隨機選擇決策Agent引數,批量回放歷史流量,Agent與廣告投放模擬系統進行互動,完成狀態轉移過程。根據系統返回的Reward優化決策Agent引數,最終輸出離線最優Agent引數,並同步到線上。
線上決策:對於線上單條請求,使用離線最優Agent與線上系統進行互動和決策。
在本期中,我們使用進化演算法求解Agent引數。進化演算法引數尋優的核心是組合動作價值評估,由於涉及到狀態轉移過程,組合動作價值評估不再是一個簡單的監督學習問題,Agent需要依次與系統互動並執行決策動作,直到最後一個階段的動作完成時才能從系統中取得收益。一種簡單的方案是讓Agent線上學習,與系統互動的同時優化自身引數,但線上學習會影響業務收益,這對我們來說是不可接受的。為了解決這個問題,我們通過構造廣告投放模擬器,模擬線上廣告系統環境,由該模擬器與Agent進行互動,並反饋收益(Reward)。
3.1 全鏈路最優算力決策
3.1.1 問題建模
根據外賣廣告的投放場景,我們基於進化演算法對整個問題建模如下:
- 狀態:上下文特徵,請求佇列特徵等(後置決策模組的狀態依賴前置模組的決策,比如彈性通道的決策直接影響了彈性佇列時佇列長度)。
動作:在不同階段定義不同。
- 彈性通道:召回動作,一維向量 $(a_1, a_2, a_3, ...)$,$a_i \in \{0,1\}$ 表示是否該通道是否召回。
- 彈性佇列:截斷長度,整數值。
- 彈性模型:模型編號,整數值。
- Reward:收益目標為業務收益,為了保證求解引數符合算力約束條件,在Reward中新增算力約束條件。對於越嚴格的約束條件,算力系數$\lambda_n$越大。
3.1.2 離線引數求解
離線引數求解主要分為進化演算法引數尋優和Reward評估兩個模組。
- 引數尋優模組:實現通用的進化演算法尋參流程,負責引數初始化、引數評估(依賴Reward評估模組)、引數取樣和引數進化等過程,並最終輸出最優引數。
- Reward評估模組:根據指定Agent的具體引數,批量回放線上流量,讓Agent與環境進行互動(離線模擬),最後根據互動結果預估當前引數對應的收益。
3.1.2.1 引數尋優
引數尋優模組使用進化演算法求解引數。本文以CEM為例,對引數求解過程進行詳細講解:
- 引數初始化:初始化引數均值和方差,根據指定的均值和方差隨機取樣N組引數。
Reward評估
- 離線模擬:回放流量,讓當前引數對應的Agent與離線模擬器互動,完成狀態轉移過程,在所有模組決策完成後,離線模擬模組輸出回放流量互動結果。
- 收益預估:根據回放流量互動結果,預估當前互動結果下的期望收益。
- 引數挑選:按照引數合併流量期望收益,挑選使得所有流量整體收益最高的Top-K組引數。
- 引數進化:根據Top-K引數,計算新的引數均值和方差。
- 引數取樣:根據新的均值和方差,重新取樣N組引數,並跳轉到第二步,直到引數均值和方差收斂。
Tips:NES方案在本場景中效果不如CEM,原因是NES對帶約束問題(特別是多約束問題)Reward設計要求過高,在真實場景中難以求解到嚴格滿足約束的引數。
3.1.2.2 Reward評估
離線Reward評估流程:在離線訓練時,對於選定的Agent和歷史流量。
- Step1:模擬器構造流量初始狀態特徵,並反饋給Agent。
- Step2:Agent根據模擬器給出的流量狀態特徵進行召回通道檔位決策。
- Step3:模擬器按照Agent給出的召回決策結果進行佇列召回,並將召回結果反饋給Agent。
- Step4:Agent根據召回結果及初始流量狀態進行佇列長度決策。
- Step5:模擬器按照Agent給出的佇列長度決策結果模擬截斷操作,反饋截斷後的佇列狀態給Agent。
- Step6:Agent根據截斷佇列進行預估模型編號決策。
- Step7:模擬器根據模型編號決策給出廣告列表集合以及決策相關特徵。
- Step8:將離線模擬的廣告列表結果輸入收益預估模型,預估每條請求對應的離線收益。
- Step9:統計整體流量的Reward,作為當前Agent策略的評估結果。
3.1.2.2.1 離線模擬
線上環境互動面臨的困境(離線模擬的必要性):理論上,決策Agent與線上環境互動能獲得最真實Reward(收益)反饋,但直接利用線上流量探索會導致以下問題:
- 線上收益損失:線上探索Agent收益的過程是有損的,特別是在策略學前期,策略決策幾乎是隨機的,線上算力約束和收益都無法得到保障。
- 流量利用率低:Agent學習往往需要幾十甚至上百輪的訓練,每輪訓練中又包含多組可行引數,為了積累置信的流量資料,每組引數的流量不能太少,總體來說訓練時間和效率將是難以接受的。
離線模擬的最終目標:復現線上互動邏輯和收益反饋。
- 基本思路:雖然無法完全復現線上的複雜環境,但參照線上環境互動邏輯,可以通過離線廣告系統模擬器在效率和準確性之間做一個取捨。
- 其他模組:為了達成這個目標,對於特定的廣告佇列資訊,我們可以使用有監督學習模型對其流量Reward進行預估。
離線模擬+收益預估解決方案:
- 線上隨機探索流量:線上留下少量隨機探索流量,隨機決策每個階段的候選動作,同時記錄流量日誌和線上系統的互動結果。
- 離線模擬系統:對歷史流量日誌,仿照線上邏輯,模擬召回,佇列截斷、粗排CTR預估等邏輯生成離線互動結果。
- 收益預估:作為離線Reward評估的核心模組,收益預估決定了引數的進化方向,我們將在下一節對收益預估方案進行詳細介紹。
3.1.2.2.2 收益預估
目標和挑戰點
- 目標:基於線上空白流量和隨機探索流量,預估請求在不同動作下的期望收益。
挑戰點:不同於傳統廣告中“使用者-廣告”粒度的區域性鏈路CTR、CVR以及GMV預估任務,本文是請求粒度的全鏈路收益預估,包含了請求曝光、點選、下單(轉化)的整個過程,問題更加複雜,特別是面臨資料稀疏問題。
- 資料稀疏問題:由於建模鏈路較長,在使用者轉化資料非常稀疏的情況下,大部分流量都沒有轉化動作發生(意味著商家收益為0)。
模型預估方案
模型設計
- 考慮到商家收益資料過於稀疏,曝光、點選資料則較為稠密,同時考慮到曝光(平臺收益)、點選、下單(商家收益)等行為是強相關的行為,本次預估方案使用多工模型聯合建模。
特徵工程
- 將各階段的特徵離散化後通過Embedding加入模型中。
- 根據不同佇列長度下的流量資料分佈情況,將佇列長度等特徵進行人工分桶再通過Embedding加入模型中。
3.1.3 線上決策
對於線上單條請求,使用離線最優Agent與線上系統進行互動和決策。和離線評估流程一致,依次按照如下流程執行決策過程:
- Step1:系統反饋流量初始狀態至Agent。
- Step2:Agent根據系統流量狀態進行召回通道檔位決策。
- Step3:系統按照Agent給出的召回決策結果進行佇列召回,並將召回結果反饋給Agent。
- Step4:Agent根據召回結果及初始流量狀態進行佇列長度決策。
- Step5:系統按照Agent給出的佇列長度決策結果執行截斷操作,反饋截斷後的佇列狀態給Agent。
- Step6:Agent根據截斷後佇列狀態進行預估模型編號決策。
- Step7:系統按照Agent給出的模型編號呼叫預估服務。
3.2 系統建設
在智慧算力第一期中,我們已經完成了以決策元件為核心,以採集、調控和離線元件為支撐的智慧算力系統基本建設。在本期中,我們圍繞著從單動作區域性最優決策擴充套件到多動作組合最優決策的核心需求。在系統建設上,除了多動作組合最優決策的基本能力建設外,更關注的智慧算力系統的穩定性和通用性建設,從而支撐智慧算力系統在外賣廣告全業務線的全面應用。
3.2.1 決策元件Agent
決策元件Agent作為智慧算力系統的客戶端,嵌入到廣告投放系統中各個模組,負責系統流量算力的分發決策。在本期中,我們主要在決策能力上進行了輕量化、精細化迭代,以及相關能力的標準化建設。
在決策能力上
建設輕量的多動作組合決策能力:我們基於進化演算法實現了輕量的多動作組合決策能力,進化演算法相關前文已經介紹,這裡主要介紹下輕量化。
- 為什麼需要輕量化:在廣告投放系統中,對於線上的時延要求非常嚴苛,在多動作下需要進行序列決策,決策次數理論上等於決策動作的數量,因此智慧算力決策必須在效果不降(或微降)下儘可能的輕量化,才能滿足線上RT要求。
- 如何建設:(1) 模型本地化,減少網路時延,這個也是將決策能力封裝到SDK而不是建設模型決策服務的主要原因。(2) 模型輕量化,通過特徵工程工作,儘可能地減少特徵數量,減少線上特徵處理的效能壓力。(3) 決策並行處理,決策動作儘量和線上已有流程並行處理,減少整體鏈路耗時。
- 輕量化效果:多動作組合決策相對單動作決策,廣告鏈路耗時:TP99+1.8ms、TP999 +2.6ms,滿足線上RT要求。
建設精細化的系統狀態反饋控制能力:我們基於系統狀態的實時收集和PID反饋控制演算法,對算力檔位引數進行微調,實現廣告投放系統在動態算力分配過程中的穩定性保障。
- 為什麼需要精細化:在廣告投放系統中,穩定性非常重要,從單動作決策到複雜的多動作決策,智慧算力決策的引數檔位越來越多,對系統穩定性影響也越來越大,粗粒度的系統狀態反饋控制已經無法保障系統穩定。在第一期彈性佇列方案中也出現過穩定性調控異常的情況,在只依據粗粒度的整體叢集系統狀態資料進行穩定性調控時,會偶發單機效能異常引起整體叢集狀態變化劇烈,導致算力調控不穩定。
- 如何建設:一方面是系統狀態資料的精細化,資料粒度從叢集細化到機房和單機,同時資料指標支援細粒度的自定義擴充套件。另一方面是系統調控目標和策略的精細化,調控目標從叢集的整體穩定細粒度到機房和單機穩定,我們將系統狀態實時反饋控制的最小單位定義為一個調控器,對於每一個調控目標,需要一個或一組調控器支援。另外,為更好地支援單機粒度的反饋控制,我們將系統狀態反饋控制能力從調控元件遷移複用到了決策元件,決策元件可以通過容器資訊讀取和攔截的方式,直接採集部分單機粒度的狀態指標,並將調控結果作用到嵌入的機器,形成閉環調控;單機粒度的反饋控制不再強依賴採集元件的鏈路反饋,系統狀態反饋的時延,也從秒級降低到了毫秒級,極大地提高了反饋控制的準確性和效率。
在標準化建設上
在多動作組合決策下對線上決策有了新的要求,一方面需要考慮通用性,做好基礎能力沉澱,另一方面需要和上層業務減少耦合,從而賦能更多動作和業務場景;同時外賣廣告工程架構已經完成了階段性的平臺化建設[4],其中標準化是平臺化建設的基礎,因此智慧算力決策元件分別從功能、資料、流程上進行了標準化建設。智慧算力的標準化建設,對智慧算力從單動作決策到多動作組合決策再擴充套件到各大業務場景(點—>線—>面)的全面建設,具有重要意義。
- 功能標準化
我們將最小不可拆分的功能單元抽象為Action,在智慧算力決策鏈路上的Action主要有:實驗、特徵拉取、特徵計算、詞典處理、引數處理、DCAF決策、ES-MACA決策、系統狀態反饋控制、日誌收集、監控等。通過Action的複用和擴充套件,提高在新動作場景和業務線上的接入效率。
- 資料標準化
在廣告工程平臺化建設中,使用上下文Context描述Action執行的環境依賴,包含輸入依賴、配置依賴、環境引數依賴等。在智慧算力線上決策中,我們在廣告基礎Context下擴充套件了智慧算力Context,封裝和維護智慧算力的環境依賴,主要包含標準化的輸入輸出、決策特徵、決策引數、決策策略等,Action間基於Context實現資料互動。
- 流程標準化
業務的呼叫流程是完成功能和資料的組合,統一的流程設計模式是業務功能複用和提效的核心手段,我們基於平臺化建設的管理平臺和排程引擎,通過對Action的視覺化拖拽,實現了智慧算力功能的DAG編排和排程。
3.2.2 採集和調控元件
採集元件負責實時採集廣告投放系統的狀態資料,並進行標準化預處理,調控元件一方面依賴狀態資料實現對整個系廣告投放統狀態的實時感知和系統模組粒度的算力調控;另一方面作為智慧算力系統的中控服務,負責智慧算力系統的系統管理,包含業務管理、策略管理、動作管理以及元資訊管理等。
我們將系統狀態實時反饋控制的最小單位定義為一個調控器,對於每一個動作決策,會涉及一到多個模組的算力變化,而每個模組的算力變化會帶來多個資料指標的變化,因此對於一個動作可能需要配置多個調控器。從單動作決策擴充套件到多動作,這些調控器的數量會越來越多,如何提高對調控器的管理和接入效率,是一個關鍵問題。這裡我們主要進行了異構資料標準化、調控流程通用化建設,基本實現了新調控場景的配置化接入,無需開發和發版。
異構資料標準化
採集元件有多個異構資料來源,包含來著美團監控系統CAT上報的業務資料、Falcon收集的機器指標資料,還有部分決策元件上報的資料。經過對資料格式和內容的分析,我們首先將資料以系統模組Appkey進行劃分,Appkey之間資料獨立,同時從資料型別(Type)出發,把資料分為業務指標(Biz)和機器指標(Host);從資料維度(Dimension)出發,把資料分為叢集粒度(Cluster)、機房粒度(IDC)、單機粒度(Standalone);具體的指標(Metric)包含QPS、TP99、FailRate、其他擴充套件指標等。
調控流程通用化
有了異構資料的統一表達,我們就可以設計通用的調控流程,我們以ProductId作為調控業務場景的唯一標識,以ControllerId作為調控器的唯一標識,一個ProductId對映一組ControllerId,每一個調控器Controller包含輸入指標、調控策略、策略引數、輸出結果。通用的調控過程為:獲取配置的輸入指標、調控策略,基於不同的調控策略選擇不同的策略引數,執行該調控策略得到對應的輸出結果。
另外,我們對調控器的調控效率和穩定性進行了優化。在外賣的雙峰流量場景下,在非高峰時段,PID演算法的累計誤差容易積累過大,導致到了高峰時段調控週期長,系統狀態反饋調節慢;同時也存在系統抖動或資料毛刺產生的不必要調控的情況。
基於此,我們採用了滑動視窗准入準出的機制,來提高效率和準確性。如下圖所示,我們對於每一個調控器,維護了一個系統指標的滑動統計視窗,當連續M次系統指標達到了PID目標值T-設定的閾值P,該調控器才成功准入,誤差開始累計;同時當連續N次系統指標低於PID目標值T-設定的閾值Q,該調控器成功準出,累計誤差清零。
3.2.3 離線元件
離線元件負責離線模型訓練和引數求解等任務,主要包含樣本收集、模型訓練和引數求解三個部分。
- 樣本收集:線上上流量中,留出少量隨機探索流量,隨機決策召回通道、佇列長度以及不同預估模型,同時將隨機動作以及系統互動資料落表。
- 模型訓練:離線處理隨機流量日誌,生成訓練樣本,訓練收益預估的DNN模型。
- 引數求解:在CEM求解過程中,對於給定的策略,模擬線上互動環境生成流量請求資訊,然後使用收益預估模型預估當前廣告佇列的收益,從而實現CEM策略評估。
4 實驗
4.1 實驗設定
系統算力容量的選取
算力容量指標選取和第一期一致。一方面,為了保證線上系統能根據實時流量快速調整,仍選擇15min作為最小的調控單元;另一方面,離線模擬選用的系統容量為過去一週的午高峰流量算力。
Baseline選取
選取無智慧算力(固定決策)的流量作為對照組。
離線模擬模擬器——流量價值預估
使用過去14天非實驗組資料作為訓練集,進行兩階段訓練(一階段全流量訓練,二階段隨機探索流量訓練),使用當日隨機探索流量作為測試集。
離線引數求解
外賣場景中,同環比流量變化趨勢基本一致,我們通過重放過去一週流量,離線計算每個時間片內(15分鐘為一個時間片)最優引數並儲存為詞表。
4.2 離線實驗
-- | Reward |
---|---|
Baseline(系統算力容量=C) | +0.00% |
僅彈性通道(系統算力容量=C) | +1.x% |
僅彈性佇列(系統算力容量=C) | +3.x% |
僅彈性模型(系統算力容量=C) | +1.x% |
分模組最優(系統算力容量=C) | +5.x% |
ES-MACA(系統算力容量=C) | +5.x% |
實驗說明:
- Baseline:算力C下的固定決策結果。
- 僅彈性通道:在“僅彈性通道”實驗中,佇列決策和模型決策使用Baseline固定方案,“僅彈性佇列”和“僅決策模型”實驗組則與之類似。
- 分模組最優:依次學習彈性通道、彈性佇列、彈性模型,當前模組在學習時前置模組的引數固定為已經學到的最優引數,後置模組則使用Baseline固定方案。
- ES-MACA(全鏈路最優):彈性通道+彈性佇列+彈性模型同時學習。
從離線實驗的效果來看,我們有以下結論:
- 三個單動作的最優結果整體收益加和大於分模組最優,也大於ES-MACA,說明三個模組策略會相互影響,聯合優化時多動作的收益不是簡單的加和關係。
- 分模組最優方案效果不如ES-MACA方案效果(ES-MACA對比分模組最優有0.53%的提升),說明後置模組的策略對前置模組的決策效果也存在一定影響。
4.3 線上實驗
通過一週的線上ABTest實驗,我們在外賣廣告驗證了本方案的收益如下:
CPM | GMV | 收入 | CTR | CVR | 機器資源 | |
---|---|---|---|---|---|---|
Baseline(系統算力容量=C) | +0.00% | +0.00% | +0.00% | +0.00% | +0.00% | +0.00% |
僅彈性佇列(系統算力容量=C) | +0.x% | +2.x% | -0.x% | +0.x% | +1.x% | -0.05% |
ES-MACA(系統算力容量=C) | +1.x% | +2.x% | +1.x% | +0.x% | +1.x% | -0.41% |
實驗設計說明:
- Baseline:對照組,無任何智慧算力決策。
- 僅彈性佇列:實驗組1,僅決策彈性佇列(與一期方案一致)。
- ES-MACA(全鏈路最優):實驗組2,同時決策彈性通道、彈性佇列和彈性模型。
5 總結與展望
這篇文章主要從全鏈路最優算力決策和系統建設兩個方面,介紹了美團外賣廣告智慧算力從線性規劃演算法到進化演算法的技術演進過程,給出了一種基於進化演算法的多動作算力分配方案(ES-MACA)。
未來,在演算法策略上,我們將嘗試強化學習演算法,對系統全鏈路組合下的算力最優分配問題進行更精細化的建模和求解;在系統建設上,我們還將嘗試和美團內部基礎架構部門進行合作,從線上系統擴充套件到線上/近線/離線三層系統,通過智慧算力統一決策排程,充分挖掘資料和算力的潛力。
6 參考文獻
- [1] 順輝、家巨集、宋偉、國樑、乾龍、樂彬等,美團外賣廣告智慧算力的探索與實踐。
- [2] Jiang, B., Zhang, P., Chen, R., Luo, X., Yang, Y., Wang, G., ... & Gai, K. (2020). DCAF: A Dynamic Computation Allocation Framework for Online Serving System. arXiv preprint arXiv:2006.09684.
- [3] Yang, X., Wang, Y., Chen, C., Tan, Q., Yu, C., Xu, J., & Zhu, X. (2021). Computation Resource Allocation Solution in Recommender Systems. arXiv preprint arXiv:2103.02259.
- [4] 樂彬、國樑、玉龍、吳亮、磊興、王焜、劉研、思遠等,廣告平臺化的探索與實踐 | 美團外賣廣告工程實踐專題連載。
7 本文作者
家巨集、順輝、國樑、乾龍、樂彬等,均來自美團外賣廣告技術團隊。
閱讀美團技術團隊更多技術文章合集
前端 | 演算法 | 後端 | 資料 | 安全 | 運維 | iOS | Android | 測試
| 在公眾號選單欄對話方塊回覆【2021年貨】、【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞,可檢視美團技術團隊歷年技術文章合集。
| 本文系美團技術團隊出品,著作權歸屬美團。歡迎出於分享和交流等非商業目的轉載或使用本文內容,敬請註明“內容轉載自美團技術團隊”。本文未經許可,不得進行商業性轉載或者使用。任何商用行為,請傳送郵件至tech@meituan.com申請授權。