作者 | 家宏 順輝 國梁等

在深度學習時代，算力的需求和消耗日益增長，如何降低算力成本，提高算力效率，逐漸成為一個重要的新課題。智能算力旨在對流量算力進行精細化和個性化分配，從而實現(xiàn)系統(tǒng)算力約束下的業(yè)務(wù)收益最大化。

1 業(yè)務(wù)背景

隨著美團外賣業(yè)務(wù)的飛速發(fā)展，外賣廣告系統(tǒng)壓力變得越來越大，算力開始成為新的瓶頸。2021年上半年，外賣廣告的數(shù)條業(yè)務(wù)線開始出現(xiàn)算力資源不足的情況，算力分配效率亟待提升。在外賣場景下，流量呈現(xiàn)明顯的雙峰結(jié)構(gòu)，廣告系統(tǒng)在高峰時段面臨較大的性能壓力，非高峰時段存在大量算力冗余。智能算力旨在對流量算力進行精細化和個性化分配，從而實現(xiàn)系統(tǒng)算力約束下的業(yè)務(wù)收益最大化。

本文是廣告智能算力系列文章的第二篇，在第一篇《美團外賣廣告智能算力的探索與實踐》中[1]，我們對阿里DCAF[2]線性規(guī)劃求解方案進行了外賣場景下的優(yōu)化，落地了彈性隊列局部最優(yōu)算力分配方案（以下簡稱“第一期”）。如上圖所示，外賣展示廣告鏈路中，召回通道和模型決策均使用固定策略，在算力不足時會丟失部分優(yōu)質(zhì)流量帶來的收益。

在本文中，我們提出了基于進化算法的多動作算力決策方法ES-MACA（Evolutionary Strategies based Multi-Action Computation Allocation）。在外賣廣告鏈路上，同時決策彈性通道、彈性隊列和彈性模型三個動作。在后置動作決策中，我們考慮前置模塊的決策引起的狀態(tài)變化，同時使用多任務(wù)模型聯(lián)合建模實現(xiàn)系統(tǒng)仿真模擬（離線仿真+收益預估，實現(xiàn)不同決策動作下的收益評估功能），實現(xiàn)全鏈路最優(yōu)算力分配。相對第一期內(nèi)容，ES-MACA在外賣展示廣告業(yè)務(wù)線上取得CPM+1.x%、收入+1.x%的效果。

2 整體思路

為了應(yīng)對極大的在線流量壓力和龐大的候選集，外賣廣告投放系統(tǒng)將整個檢索過程設(shè)計成候選集依次遞減的漏斗型級聯(lián)架構(gòu)，主要包含召回、粗排、精排、機制等模塊。在第一期中，我們把算力分配的手段定義為彈性動作，并結(jié)合外賣場景歸納了彈性隊列、彈性模型、彈性通道和彈性鏈路等四種動作，具體動作的定義如下：

• 彈性隊列：線上檢索是一個漏斗的過程，不同價值流量可以在級聯(lián)漏斗的各模塊中分配不同候選隊列長度。
• 彈性模型：在模型預估服務(wù)中，對于不同價值流量可以選擇不同大小模型，大模型相對小模型預估效果更好的同時，消耗的算力也更多。
• 彈性通道：在召回場景中，不同價值流量可以選擇不同復雜度的召回通道和召回通道的路數(shù)。
• 彈性鏈路：在檢索鏈路上，不同價值流量可以選擇不同復雜度的檢索鏈路。

2.1 算力分配問題形式化描述

在一個包含M個算力決策模塊的鏈路中，全鏈路最優(yōu)的智能算力的目標可通用的描述為：通過智能化決策M個模塊的算力檔位，在整體算力滿足約束的條件下，使得整體流量收益最大化。該問題的一般形式化描述為：以上是多個算力決策模塊的場景，在外賣展示廣告中，對算力和收益較為敏感的決策模塊為廣告召回策略、精排隊列長度和精排預估模型，分別對應(yīng)彈性通道、彈性隊列和彈性模型三個動作。在本期中，我們同時考慮彈性通道、彈性隊列和彈性模型三個模塊的算力聯(lián)合決策。在多個模塊聯(lián)合決策時，同一個請求的不同模塊動作之間互相會產(chǎn)生影響。如下圖所示，彈性通道決策結(jié)果決定了真實召回隊列（包括候選隊列的長度和廣告類型等信息），直接影響了彈性隊列的輸入狀態(tài)。同理，彈性隊列的決策結(jié)果影響了彈性模型的輸入狀態(tài)。因此，在多動作聯(lián)合建模中，我們增加了請求“狀態(tài)”特征，讓決策動作與系統(tǒng)產(chǎn)生交互，更好地擬合系統(tǒng)狀態(tài)的過程。

2.2 挑戰(zhàn)分析

外賣智能算力第一期中，我們針對外賣廣告場景，在DCAF方案的基礎(chǔ)上進行了一系列探索和改進，并初次進行了模型彈性分配的嘗試，取得了不錯的收益。近年，阿里CRAS[3]方案給出了一種應(yīng)用于預排、粗排和精排隊列聯(lián)合優(yōu)化的聯(lián)合最優(yōu)算力分配線性規(guī)劃方案。從彈性動作的分類來看，該方案以一種優(yōu)雅的方式解決了三個彈性隊列的聯(lián)合優(yōu)化問題，CRAS通過一些數(shù)據(jù)分析和合理假設(shè)，將原始問題拆解為三個互相獨立且相似子問題，然后分別對三個子問題進行求解。

但是已有方案是基于線性規(guī)劃方案的，且僅關(guān)注一個或多個彈性隊列優(yōu)化問題，在面對非彈性隊列動作組合，如彈性通道和彈性模型時，方案無法直接遷移。特別地，在約束條件或優(yōu)化目標發(fā)生變化時，線性規(guī)劃方案需要重新對特定業(yè)務(wù)問題進行建模和求解，需消耗大量的人力；此外，目前已有線性規(guī)劃方案的問題建模和求解過程中往往包含一些業(yè)務(wù)數(shù)據(jù)相關(guān)的強假設(shè)，這些假設(shè)在新的業(yè)務(wù)上可能難以滿足，這進一步使得已有方案難以拓展遷移到新的業(yè)務(wù)問題上。

由于外賣場景的LBS限制，外賣廣告的候選隊列相對非LBS電商場景較短，不需要經(jīng)過復雜的預排-粗排-精排的過程。在全鏈路上，我們更關(guān)注召回通道、精排隊列長度、精排預估模型等模塊的算力分配，這些模塊其實對算力更加敏感。整體來看，美團外賣廣告場景全鏈路最優(yōu)算力分配的挑戰(zhàn)主要包括以下兩個方面。通用化問題

• 挑戰(zhàn)點：已有方案與業(yè)務(wù)耦合過重，一方面，在約束條件或優(yōu)化目標發(fā)生變化時，線性規(guī)劃方案需要重新對特定業(yè)務(wù)問題進行建模；另一方面，對特定的業(yè)務(wù)線，往往需要根據(jù)業(yè)務(wù)數(shù)據(jù)特性增加一些強假設(shè)。外賣廣告目前包括十余條業(yè)務(wù)線，每條業(yè)務(wù)線中又存在多個算力決策場景，若對每條業(yè)務(wù)線的每個場景都單獨建模，人力成本巨大。
• 應(yīng)對思路：采用通用解決方案并沉淀為基礎(chǔ)通用能力，為廣告業(yè)務(wù)的不同算力決策場景賦能，降本增效。

序列決策問題

• 挑戰(zhàn)點：在全鏈路算力分配時，多個決策模塊之間互相耦合，共同對影響當前流量的最終算力和收益。如下圖所示，前置動作決策后，需要跟真實環(huán)境交互才能獲取動作決策后的交互結(jié)果，模塊之間涉及到系統(tǒng)狀態(tài)轉(zhuǎn)移，需要在最后一個決策模塊完成決策后才能獲得流量收益，這使得我們難以通過常規(guī)方式建模。

• 應(yīng)對思路：在全鏈路最優(yōu)算力分配問題建模過程中，增加系統(tǒng)在各鏈路上的“狀態(tài)”轉(zhuǎn)移過程，后置模塊根據(jù)前置模塊的決策結(jié)果和請求狀態(tài)進行決策。

綜合考慮以上兩個問題，我們將外賣廣告全鏈路最優(yōu)算力分配問題建模為多階段決策問題（每個決策模塊對應(yīng)一個決策階段），按時間順序依次決策召回方案、截斷隊列和預估模型。每個階段中，由Agent與環(huán)境交互和決策，Agent參數(shù)可使用進化算法或強化學習求解。

全鏈路算力分配過程可建模為馬爾科夫決策過程（Markov Decision Process, MDP）或部分可觀測馬爾科夫決策過程（Partially Observable Markov Decision Process，POMDP）。如上圖所示，狀態(tài)轉(zhuǎn)移發(fā)生在相鄰的兩個階段之間，各階段分別有不同的候選動作（如召回策略，截斷長度和預估模型編號等），Reward則在最后一個階段動作執(zhí)行后通過系統(tǒng)反饋獲得。

我們可以收集在線日志數(shù)據(jù)，使用離線強化學習（Offline RL）求解Agent；在不擔心線上收益受損的情況下，也可以使用在線強化學習（Online RL）求解Agent。但由于業(yè)務(wù)場景復雜，各階段算力約束難以統(tǒng)一，不管是離線強化學習還是在線強化學習，都面臨多階段強約束難以建模和求解的問題。

而進化算法作為一種應(yīng)用廣泛、魯棒性強的全局優(yōu)化方法，有以下優(yōu)點：

• 避免局部最優(yōu)：進化算法參數(shù)搜索過程具有一定的隨機性，不易陷入局部最優(yōu)；
• 可并行化：進化算法參數(shù)搜索過程可并行，可緩解評估過程耗時問題；
• 應(yīng)用廣泛：進化算法可以能夠處理不連續(xù)、不可微和非凸優(yōu)化問題，且不需要過多先驗知識；
• 簡單易用：一些進化算法，比如交叉熵方法（Cross-Entropy Method，CEM）可以優(yōu)雅地解決各種約束問題，不需要直接求解約束問題。

進化算法能很好地解決外賣廣告場景中的問題，既容易擴展到其他業(yè)務(wù)線，又能非常方便地建模各種決策問題。因此，本期我們選擇進化算法來求解外賣場景全鏈路最優(yōu)算力分配問題。在后續(xù)工作中，我們會嘗試使用強化學習方案求解。如本節(jié)迭代路徑（圖）所示，我們在1.5期中嘗試了基于進化算法的單動作算力決策方法ES-SACA（Evolutionary Strategies based Single-Action Computation Allocation），驗證了進化算法在算力分配場景的有效性。接下來，本文主要介紹基于進化算法的多動作算力決策方法ES-MACA。

3 方案設(shè)計

為了實現(xiàn)廣告系統(tǒng)全鏈路上的最優(yōu)算力分配，我們設(shè)計了如下決策方案：

離線訓練：隨機選擇決策Agent參數(shù)，批量回放歷史流量，Agent與廣告投放模擬系統(tǒng)進行交互，完成狀態(tài)轉(zhuǎn)移過程。根據(jù)系統(tǒng)返回的Reward優(yōu)化決策Agent參數(shù)，最終輸出離線最優(yōu)Agent參數(shù)，并同步到線上。

在線決策：對于線上單條請求，使用離線最優(yōu)Agent與線上系統(tǒng)進行交互和決策。

在本期中，我們使用進化算法求解Agent參數(shù)。進化算法參數(shù)尋優(yōu)的核心是組合動作價值評估，由于涉及到狀態(tài)轉(zhuǎn)移過程，組合動作價值評估不再是一個簡單的監(jiān)督學習問題，Agent需要依次與系統(tǒng)交互并執(zhí)行決策動作，直到最后一個階段的動作完成時才能從系統(tǒng)中取得收益。一種簡單的方案是讓Agent在線學習，與系統(tǒng)交互的同時優(yōu)化自身參數(shù)，但在線學習會影響業(yè)務(wù)收益，這對我們來說是不可接受的。為了解決這個問題，我們通過構(gòu)造廣告投放模擬器，模擬線上廣告系統(tǒng)環(huán)境，由該模擬器與Agent進行交互，并反饋收益（Reward）。

3.1 全鏈路最優(yōu)算力決策

3.1.1 問題建模

根據(jù)外賣廣告的投放場景，我們基于進化算法對整個問題建模如下：

（1）彈性通道：召回動作，一維向量 , 表示是否該通道是否召回。

（2）彈性隊列：截斷長度，整數(shù)值。

（3）彈性模型：模型編號，整數(shù)值。

• 狀態(tài)：上下文特征，請求隊列特征等（后置決策模塊的狀態(tài)依賴前置模塊的決策，比如彈性通道的決策直接影響了彈性隊列時隊列長度）。
• 動作：在不同階段定義不同。
• Reward：收益目標為業(yè)務(wù)收益，為了保證求解參數(shù)符合算力約束條件，在Reward中添加算力約束條件。對于越嚴格的約束條件，算力系數(shù) 越大。

3.1.2 離線參數(shù)求解

離線參數(shù)求解主要分為進化算法參數(shù)尋優(yōu)和Reward評估兩個模塊。

• 參數(shù)尋優(yōu)模塊：實現(xiàn)通用的進化算法尋參流程，負責參數(shù)初始化、參數(shù)評估（依賴Reward評估模塊）、參數(shù)采樣和參數(shù)進化等過程，并最終輸出最優(yōu)參數(shù)。
• Reward評估模塊：根據(jù)指定Agent的具體參數(shù)，批量回放線上流量，讓Agent與環(huán)境進行交互（離線仿真），最后根據(jù)交互結(jié)果預估當前參數(shù)對應(yīng)的收益。

3.1.2.1 參數(shù)尋優(yōu)

參數(shù)尋優(yōu)模塊使用進化算法求解參數(shù)。本文以CEM為例，對參數(shù)求解過程進行詳細講解：

1. 參數(shù)初始化：初始化參數(shù)均值和方差，根據(jù)指定的均值和方差隨機采樣N組參數(shù)。
2. Reward評估

• 離線仿真：回放流量，讓當前參數(shù)對應(yīng)的Agent與離線模擬器交互，完成狀態(tài)轉(zhuǎn)移過程，在所有模塊決策完成后，離線仿真模塊輸出回放流量交互結(jié)果。
• 收益預估：根據(jù)回放流量交互結(jié)果，預估當前交互結(jié)果下的期望收益。

3. 參數(shù)挑選：按照參數(shù)合并流量期望收益，挑選使得所有流量整體收益最高的Top-K組參數(shù)。
4. 參數(shù)進化：根據(jù)Top-K參數(shù)，計算新的參數(shù)均值和方差。
5. 參數(shù)采樣：根據(jù)新的均值和方差，重新采樣N組參數(shù)，并跳轉(zhuǎn)到第二步，直到參數(shù)均值和方差收斂。

Tips：NES方案在本場景中效果不如CEM，原因是NES對帶約束問題（特別是多約束問題）Reward設(shè)計要求過高，在真實場景中難以求解到嚴格滿足約束的參數(shù)。3.1.2.2 Reward評估離線Reward評估流程：在離線訓練時，對于選定的Agent和歷史流量。

• Step1：模擬器構(gòu)造流量初始狀態(tài)特征，并反饋給Agent。
• Step2：Agent根據(jù)模擬器給出的流量狀態(tài)特征進行召回通道檔位決策。
• Step3：模擬器按照Agent給出的召回決策結(jié)果進行隊列召回，并將召回結(jié)果反饋給Agent。
• Step4：Agent根據(jù)召回結(jié)果及初始流量狀態(tài)進行隊列長度決策。
• Step5：模擬器按照Agent給出的隊列長度決策結(jié)果模擬截斷操作，反饋截斷后的隊列狀態(tài)給Agent。
• Step6：Agent根據(jù)截斷隊列進行預估模型編號決策。
• Step7：模擬器根據(jù)模型編號決策給出廣告列表集合以及決策相關(guān)特征。
• Step8：將離線模擬的廣告列表結(jié)果輸入收益預估模型，預估每條請求對應(yīng)的離線收益。
• Step9：統(tǒng)計整體流量的Reward，作為當前Agent策略的評估結(jié)果。

3.1.2.2.1 離線仿真

在線環(huán)境交互面臨的困境（離線仿真的必要性）：理論上，決策Agent與在線環(huán)境交互能獲得最真實Reward（收益）反饋，但直接利用在線流量探索會導致以下問題：

• 在線收益損失：在線探索Agent收益的過程是有損的，特別是在策略學前期，策略決策幾乎是隨機的，線上算力約束和收益都無法得到保障。
• 流量利用率低：Agent學習往往需要幾十甚至上百輪的訓練，每輪訓練中又包含多組可行參數(shù)，為了積累置信的流量數(shù)據(jù)，每組參數(shù)的流量不能太少，總體來說訓練時間和效率將是難以接受的。

離線仿真的最終目標：復現(xiàn)線上交互邏輯和收益反饋。

• 基本思路：雖然無法完全復現(xiàn)線上的復雜環(huán)境，但參照線上環(huán)境交互邏輯，可以通過離線廣告系統(tǒng)模擬器在效率和準確性之間做一個取舍。
• 其他模塊：為了達成這個目標，對于特定的廣告隊列信息，我們可以使用有監(jiān)督學習模型對其流量Reward進行預估。

離線仿真+收益預估解決方案：

• 線上隨機探索流量：在線留下少量隨機探索流量，隨機決策每個階段的候選動作，同時記錄流量日志和線上系統(tǒng)的交互結(jié)果。
• 離線仿真系統(tǒng)：對歷史流量日志，仿照線上邏輯，模擬召回，隊列截斷、粗排CTR預估等邏輯生成離線交互結(jié)果。
• 收益預估：作為離線Reward評估的核心模塊，收益預估決定了參數(shù)的進化方向，我們將在下一節(jié)對收益預估方案進行詳細介紹。

3.1.2.2.2 收益預估

目標和挑戰(zhàn)點

• 數(shù)據(jù)稀疏問題：由于建模鏈路較長，在用戶轉(zhuǎn)化數(shù)據(jù)非常稀疏的情況下，大部分流量都沒有轉(zhuǎn)化動作發(fā)生（意味著商家收益為0）。

• 目標：基于線上空白流量和隨機探索流量，預估請求在不同動作下的期望收益。
• 挑戰(zhàn)點：不同于傳統(tǒng)廣告中“用戶-廣告”粒度的局部鏈路CTR、CVR以及GMV預估任務(wù)，本文是請求粒度的全鏈路收益預估，包含了請求曝光、點擊、下單（轉(zhuǎn)化）的整個過程，問題更加復雜，特別是面臨數(shù)據(jù)稀疏問題。

模型預估方案

• 考慮到商家收益數(shù)據(jù)過于稀疏，曝光、點擊數(shù)據(jù)則較為稠密，同時考慮到曝光（平臺收益）、點擊、下單（商家收益）等行為是強相關(guān)的行為，本次預估方案使用多任務(wù)模型聯(lián)合建模。

• 模型設(shè)計
• 特征工程
• 將各階段的特征離散化后通過Embedding加入模型中。
• 根據(jù)不同隊列長度下的流量數(shù)據(jù)分布情況，將隊列長度等特征進行人工分桶再通過Embedding加入模型中。

3.1.3 在線決策

對于線上單條請求，使用離線最優(yōu)Agent與線上系統(tǒng)進行交互和決策。和離線評估流程一致，依次按照如下流程執(zhí)行決策過程：

• Step1：系統(tǒng)反饋流量初始狀態(tài)至Agent。
• Step2：Agent根據(jù)系統(tǒng)流量狀態(tài)進行召回通道檔位決策。
• Step3：系統(tǒng)按照Agent給出的召回決策結(jié)果進行隊列召回，并將召回結(jié)果反饋給Agent。
• Step4：Agent根據(jù)召回結(jié)果及初始流量狀態(tài)進行隊列長度決策。
• Step5：系統(tǒng)按照Agent給出的隊列長度決策結(jié)果執(zhí)行截斷操作，反饋截斷后的隊列狀態(tài)給Agent。
• Step6：Agent根據(jù)截斷后隊列狀態(tài)進行預估模型編號決策。
• Step7：系統(tǒng)按照Agent給出的模型編號調(diào)用預估服務(wù)。

3.2 系統(tǒng)建設(shè)

在智能算力第一期中，我們已經(jīng)完成了以決策組件為核心，以采集、調(diào)控和離線組件為支撐的智能算力系統(tǒng)基本建設(shè)。在本期中，我們圍繞著從單動作局部最優(yōu)決策擴展到多動作組合最優(yōu)決策的核心需求。在系統(tǒng)建設(shè)上，除了多動作組合最優(yōu)決策的基本能力建設(shè)外，更關(guān)注的智能算力系統(tǒng)的穩(wěn)定性和通用性建設(shè)，從而支撐智能算力系統(tǒng)在外賣廣告全業(yè)務(wù)線的全面應(yīng)用。

3.2.1 決策組件Agent

決策組件Agent作為智能算力系統(tǒng)的客戶端，嵌入到廣告投放系統(tǒng)中各個模塊，負責系統(tǒng)流量算力的分發(fā)決策。在本期中，我們主要在決策能力上進行了輕量化、精細化迭代，以及相關(guān)能力的標準化建設(shè)。

在決策能力上

建設(shè)輕量的多動作組合決策能力：我們基于進化算法實現(xiàn)了輕量的多動作組合決策能力，進化算法相關(guān)前文已經(jīng)介紹，這里主要介紹下輕量化。

• 為什么需要輕量化：在廣告投放系統(tǒng)中，對于線上的時延要求非常嚴苛，在多動作下需要進行序列決策，決策次數(shù)理論上等于決策動作的數(shù)量，因此智能算力決策必須在效果不降（或微降）下盡可能的輕量化，才能滿足線上RT要求。
• 如何建設(shè)：(1) 模型本地化，減少網(wǎng)絡(luò)時延，這個也是將決策能力封裝到SDK而不是建設(shè)模型決策服務(wù)的主要原因。(2) 模型輕量化，通過特征工程工作，盡可能地減少特征數(shù)量，減少在線特征處理的性能壓力。(3) 決策并行處理，決策動作盡量和線上已有流程并行處理，減少整體鏈路耗時。
• 輕量化效果：多動作組合決策相對單動作決策，廣告鏈路耗時：TP99+1.8ms、TP999 +2.6ms，滿足線上RT要求。

建設(shè)精細化的系統(tǒng)狀態(tài)反饋控制能力：我們基于系統(tǒng)狀態(tài)的實時收集和PID反饋控制算法，對算力檔位參數(shù)進行微調(diào)，實現(xiàn)廣告投放系統(tǒng)在動態(tài)算力分配過程中的穩(wěn)定性保障。

• 為什么需要精細化：在廣告投放系統(tǒng)中，穩(wěn)定性非常重要，從單動作決策到復雜的多動作決策，智能算力決策的參數(shù)檔位越來越多，對系統(tǒng)穩(wěn)定性影響也越來越大，粗粒度的系統(tǒng)狀態(tài)反饋控制已經(jīng)無法保障系統(tǒng)穩(wěn)定。在第一期彈性隊列方案中也出現(xiàn)過穩(wěn)定性調(diào)控異常的情況，在只依據(jù)粗粒度的整體集群系統(tǒng)狀態(tài)數(shù)據(jù)進行穩(wěn)定性調(diào)控時，會偶發(fā)單機性能異常引起整體集群狀態(tài)變化劇烈，導致算力調(diào)控不穩(wěn)定。
• 如何建設(shè)：一方面是系統(tǒng)狀態(tài)數(shù)據(jù)的精細化，數(shù)據(jù)粒度從集群細化到機房和單機，同時數(shù)據(jù)指標支持細粒度的自定義擴展。另一方面是系統(tǒng)調(diào)控目標和策略的精細化，調(diào)控目標從集群的整體穩(wěn)定細粒度到機房和單機穩(wěn)定，我們將系統(tǒng)狀態(tài)實時反饋控制的最小單位定義為一個調(diào)控器，對于每一個調(diào)控目標，需要一個或一組調(diào)控器支持。另外，為更好地支持單機粒度的反饋控制，我們將系統(tǒng)狀態(tài)反饋控制能力從調(diào)控組件遷移復用到了決策組件，決策組件可以通過容器信息讀取和攔截的方式，直接采集部分單機粒度的狀態(tài)指標，并將調(diào)控結(jié)果作用到嵌入的機器，形成閉環(huán)調(diào)控；單機粒度的反饋控制不再強依賴采集組件的鏈路反饋，系統(tǒng)狀態(tài)反饋的時延，也從秒級降低到了毫秒級，極大地提高了反饋控制的準確性和效率。

在標準化建設(shè)上

在多動作組合決策下對在線決策有了新的要求，一方面需要考慮通用性，做好基礎(chǔ)能力沉淀，另一方面需要和上層業(yè)務(wù)減少耦合，從而賦能更多動作和業(yè)務(wù)場景；同時外賣廣告工程架構(gòu)已經(jīng)完成了階段性的??平臺化建設(shè)??[4]，其中標準化是平臺化建設(shè)的基礎(chǔ)，因此智能算力決策組件分別從功能、數(shù)據(jù)、流程上進行了標準化建設(shè)。智能算力的標準化建設(shè)，對智能算力從單動作決策到多動作組合決策再擴展到各大業(yè)務(wù)場景（點—>線—>面）的全面建設(shè)，具有重要意義。

• 功能標準化

我們將最小不可拆分的功能單元抽象為Action，在智能算力決策鏈路上的Action主要有：實驗、特征拉取、特征計算、詞典處理、參數(shù)處理、DCAF決策、ES-MACA決策、系統(tǒng)狀態(tài)反饋控制、日志收集、監(jiān)控等。通過Action的復用和擴展，提高在新動作場景和業(yè)務(wù)線上的接入效率。

• 數(shù)據(jù)標準化

在廣告工程平臺化建設(shè)中，使用上下文Context描述Action執(zhí)行的環(huán)境依賴，包含輸入依賴、配置依賴、環(huán)境參數(shù)依賴等。在智能算力在線決策中，我們在廣告基礎(chǔ)Context下擴展了智能算力Context，封裝和維護智能算力的環(huán)境依賴，主要包含標準化的輸入輸出、決策特征、決策參數(shù)、決策策略等，Action間基于Context實現(xiàn)數(shù)據(jù)交互。

• 流程標準化

業(yè)務(wù)的調(diào)用流程是完成功能和數(shù)據(jù)的組合，統(tǒng)一的流程設(shè)計模式是業(yè)務(wù)功能復用和提效的核心手段，我們基于平臺化建設(shè)的管理平臺和調(diào)度引擎，通過對Action的可視化拖拽，實現(xiàn)了智能算力功能的DAG編排和調(diào)度。

3.2.2 采集和調(diào)控組件

采集組件負責實時采集廣告投放系統(tǒng)的狀態(tài)數(shù)據(jù)，并進行標準化預處理，調(diào)控組件一方面依賴狀態(tài)數(shù)據(jù)實現(xiàn)對整個系廣告投放統(tǒng)狀態(tài)的實時感知和系統(tǒng)模塊粒度的算力調(diào)控；另一方面作為智能算力系統(tǒng)的中控服務(wù)，負責智能算力系統(tǒng)的系統(tǒng)管理，包含業(yè)務(wù)管理、策略管理、動作管理以及元信息管理等。

我們將系統(tǒng)狀態(tài)實時反饋控制的最小單位定義為一個調(diào)控器，對于每一個動作決策，會涉及一到多個模塊的算力變化，而每個模塊的算力變化會帶來多個數(shù)據(jù)指標的變化，因此對于一個動作可能需要配置多個調(diào)控器。從單動作決策擴展到多動作，這些調(diào)控器的數(shù)量會越來越多，如何提高對調(diào)控器的管理和接入效率，是一個關(guān)鍵問題。這里我們主要進行了異構(gòu)數(shù)據(jù)標準化、調(diào)控流程通用化建設(shè)，基本實現(xiàn)了新調(diào)控場景的配置化接入，無需開發(fā)和發(fā)版。

異構(gòu)數(shù)據(jù)標準化采集組件有多個異構(gòu)數(shù)據(jù)源，包含來著美團監(jiān)控系統(tǒng)CAT上報的業(yè)務(wù)數(shù)據(jù)、Falcon收集的機器指標數(shù)據(jù)，還有部分決策組件上報的數(shù)據(jù)。經(jīng)過對數(shù)據(jù)格式和內(nèi)容的分析，我們首先將數(shù)據(jù)以系統(tǒng)模塊Appkey進行劃分，Appkey之間數(shù)據(jù)獨立，同時從數(shù)據(jù)類型（Type）出發(fā)，把數(shù)據(jù)分為業(yè)務(wù)指標（Biz）和機器指標（Host）；從數(shù)據(jù)維度（Dimension）出發(fā)，把數(shù)據(jù)分為集群粒度（Cluster）、機房粒度（IDC）、單機粒度（Standalone）；具體的指標（Metric）包含QPS、TP99、FailRate、其他擴展指標等。

調(diào)控流程通用化

有了異構(gòu)數(shù)據(jù)的統(tǒng)一表達，我們就可以設(shè)計通用的調(diào)控流程，我們以ProductId作為調(diào)控業(yè)務(wù)場景的唯一標識，以ControllerId作為調(diào)控器的唯一標識，一個ProductId映射一組ControllerId，每一個調(diào)控器Controller包含輸入指標、調(diào)控策略、策略參數(shù)、輸出結(jié)果。

通用的調(diào)控過程為：獲取配置的輸入指標、調(diào)控策略，基于不同的調(diào)控策略選擇不同的策略參數(shù)，執(zhí)行該調(diào)控策略得到對應(yīng)的輸出結(jié)果。另外，我們對調(diào)控器的調(diào)控效率和穩(wěn)定性進行了優(yōu)化。在外賣的雙峰流量場景下，在非高峰時段，PID算法的累計誤差容易積累過大，導致到了高峰時段調(diào)控周期長，系統(tǒng)狀態(tài)反饋調(diào)節(jié)慢；同時也存在系統(tǒng)抖動或數(shù)據(jù)毛刺產(chǎn)生的不必要調(diào)控的情況。

基于此，我們采用了滑動窗口準入準出的機制，來提高效率和準確性。如下圖所示，我們對于每一個調(diào)控器，維護了一個系統(tǒng)指標的滑動統(tǒng)計窗口，當連續(xù)M次系統(tǒng)指標達到了PID目標值T-設(shè)置的閾值P，該調(diào)控器才成功準入，誤差開始累計；同時當連續(xù)N次系統(tǒng)指標低于PID目標值T-設(shè)置的閾值Q，該調(diào)控器成功準出，累計誤差清零。

3.2.3 離線組件

離線組件負責離線模型訓練和參數(shù)求解等任務(wù)，主要包含樣本收集、模型訓練和參數(shù)求解三個部分。

• 樣本收集：在線上流量中，留出少量隨機探索流量，隨機決策召回通道、隊列長度以及不同預估模型，同時將隨機動作以及系統(tǒng)交互數(shù)據(jù)落表。
• 模型訓練：離線處理隨機流量日志，生成訓練樣本，訓練收益預估的DNN模型。
• 參數(shù)求解：在CEM求解過程中，對于給定的策略，模擬線上交互環(huán)境生成流量請求信息，然后使用收益預估模型預估當前廣告隊列的收益，從而實現(xiàn)CEM策略評估。

4 實驗

4.1 實驗設(shè)置

系統(tǒng)算力容量的選取

算力容量指標選取和第一期一致。一方面，為了保證線上系統(tǒng)能根據(jù)實時流量快速調(diào)整，仍選擇15min作為最小的調(diào)控單元；另一方面，離線模擬選用的系統(tǒng)容量為過去一周的午高峰流量算力。

Baseline選取選取

無智能算力（固定決策）的流量作為對照組。

離線仿真模擬器——流量價值預估

使用過去14天非實驗組數(shù)據(jù)作為訓練集，進行兩階段訓練（一階段全流量訓練，二階段隨機探索流量訓練），使用當日隨機探索流量作為測試集。

離線參數(shù)求解

外賣場景中，同環(huán)比流量變化趨勢基本一致，我們通過重放過去一周流量，離線計算每個時間片內(nèi)（15分鐘為一個時間片）最優(yōu)參數(shù)并存儲為詞表。

4.2 離線實驗

實驗說明：

• Baseline：算力C下的固定決策結(jié)果。
• 僅彈性通道：在“僅彈性通道”實驗中，隊列決策和模型決策使用Baseline固定方案，“僅彈性隊列”和“僅決策模型”實驗組則與之類似。
• 分模塊最優(yōu)：依次學習彈性通道、彈性隊列、彈性模型，當前模塊在學習時前置模塊的參數(shù)固定為已經(jīng)學到的最優(yōu)參數(shù)，后置模塊則使用Baseline固定方案。
• ES-MACA（全鏈路最優(yōu)）：彈性通道+彈性隊列+彈性模型同時學習。

從離線實驗的效果來看，我們有以下結(jié)論：

• 三個單動作的最優(yōu)結(jié)果整體收益加和大于分模塊最優(yōu)，也大于ES-MACA，說明三個模塊策略會相互影響，聯(lián)合優(yōu)化時多動作的收益不是簡單的加和關(guān)系。
• 分模塊最優(yōu)方案效果不如ES-MACA方案效果（ES-MACA對比分模塊最優(yōu)有0.53%的提升），說明后置模塊的策略對前置模塊的決策效果也存在一定影響。

4.3 在線實驗

通過一周的線上ABTest實驗，我們在外賣廣告驗證了本方案的收益如下：

實驗設(shè)計說明：

• Baseline：對照組，無任何智能算力決策。
• 僅彈性隊列：實驗組1，僅決策彈性隊列（與一期方案一致）。
• ES-MACA（全鏈路最優(yōu)）：實驗組2，同時決策彈性通道、彈性隊列和彈性模型。

5 總結(jié)與展望

這篇文章主要從全鏈路最優(yōu)算力決策和系統(tǒng)建設(shè)兩個方面，介紹了美團外賣廣告智能算力從線性規(guī)劃算法到進化算法的技術(shù)演進過程，給出了一種基于進化算法的多動作算力分配方案（ES-MACA）。未來，在算法策略上，我們將嘗試強化學習算法，對系統(tǒng)全鏈路組合下的算力最優(yōu)分配問題進行更精細化的建模和求解；在系統(tǒng)建設(shè)上，我們還將嘗試和美團內(nèi)部基礎(chǔ)架構(gòu)部門進行合作，從在線系統(tǒng)擴展到在線/近線/離線三層系統(tǒng)，通過智能算力統(tǒng)一決策調(diào)度，充分挖掘數(shù)據(jù)和算力的潛力。

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 本文作者

家宏、順輝、國梁、乾龍、樂彬等，均來自美團外賣廣告技術(shù)團隊。