“伯樂”流量調控平臺工程視角
1、研發背景
1.1 我們想要解決什么問題？
我們期望平臺能夠覆蓋的三類運營訴求如下：
（1）突發事件的應對：包括不限于外部的不可抗力影響，網絡上的熱點事件、爆倉等突發事件，在搜索&推薦等個性化流量場景下，單純依靠算法模型的學習來適應，時間上不被業務方接受。
（2）新品/新人等缺少數據的情況：在扶持新品、留存新人等問題上，新品召回難、個性化分數低導致排名靠后無法曝光，而新人缺少畫像也會對推薦效果造成影響。因此對于新品的加權、新人定向投放需要頻繁調整的情況，往往需要人工進行變更。
（3）平臺的實驗/探索項目：如品類價格帶分布控制，一些探索嘗試性的實驗，需要先小流量定向推送指定商品進行實驗，取得一定結果、經驗后，再進行優化、推全等情況。需要在圈品、圈人、AB實驗、數據大盤等多角度進行分析；頻繁的調整策略打法，也需要技術側進行迭代升級。
1.2 為什么要做成平臺？
不搭建平臺，我們也快速地落地過高UE商品加權、價格力商品扶持等業務方訴求，做法一般是通過對召回引擎中的商品打上標記，在上游系統識別到某次請求復合業務的定向投放規則時，對有標記的商品進行加權。同時統計埋點數據，評估商品實驗組與基準對照組的diff，確保扶持的力度符合業務預期。而平臺化在初期投入大量研發成本的原因主要是針對以下兩點：
（1）研發&時間成本：每個策略的新增都需要從商品打標到引擎，在線鏈路對指定流量的判別、算法加權、實時數據反饋、離線數據報表等環節進行迭代，需要BI、引擎dump、召回層、預估算法、實時數倉等多個團隊投入合計至少10~12人日的研發資源，同時PMO、各團隊leader及PM、項目聯調、測試資源、線上變更CR等間接投入也會積少成多。
（2）多場景問題：不同場景重復建設也會帶來成本的增加不再贅述，更多的是相同的用戶在不同場景有各自的分流規則，如何統一的進行AB實驗和數據統計分析也存在著一定問題。一部分商品加權也必然會擠占其他商品自然曝光的流量，這部分被擠占的流量是我們的運營成本。如何評估各場景的ROI，在單個場景效果不盡如人意的情況停止投放如何復盤該場景的資源投入，也是我們需要面對的問題。
1.3我們是怎么做的？
上述的三類問題其實可以統一抽象為：用戶隨時可以選擇一個商品集，在指定的流量下(人群標簽、query類目、品牌、AB實驗分組、時間段等)進行某項扶持（加權、保量、曝光占比、按比例提升等）。我們大體將實現該能力的系統劃分為5個模塊，如下圖所示：
（1）流量運營中心：支持運營同學自由配置策略，更換商品集、調整投放條件、完整的審批流程、報表的查閱等等運營操作；策略的新增及變更不再需要需求排期和研發周期的漫長等待。
（2）流量服務中心：用于將運營配置的流量規則與在線請求做匹配，同時負責串聯算法中控、調控商品召回、埋點上報、容災限流等工作，是調控鏈路的樞紐。
（3）數據計算中心：主要是兩部分職責，其一是將運營配置的商品集、站內基礎數據，商品增量目標完成情況等離線數據全量更新至搜索引擎。另一部分則是在線鏈路的分鐘級統計實時數據，商品的分實驗、分策略、分場景實時累計數據同步給算法中控做決策，及搜索引擎實時更新召回過濾條件的依據。
（4）流量算法中控：調控鏈路召回的商品需要由中控根據商品特征、用戶畫像、預估分、目標達成進度及增長速度等系數，實時調整每個被調控品的調控力度，負責平滑控制和過量熔斷等職責，是整個調控系統的大腦。
（5）保障設施：圍繞著穩定性、問題定位效率等角度建設的基礎設施，不做贅述。
下面對技術鏈路進行展開。
2、技術鏈路
2.1 業務架構：
經過2022 Q4季度的研發工作，當前場景已經覆蓋了交易搜索及部分推薦場景。線上支持業務策略包括：新品保量、高UE商品加權、重復曝光/獵奇商品曝光比例下調等業務訴求。同時調控為了更多個性化流量通道的接入也完成了非文本個性化多路召回等通用能力的建設工作。運營后臺的通用報表、審批流程、變更歷史對比等能力基本建設完成。
2.2 工程鏈路：
· 藍色框為新2022 Q4建設，白色框為Q3季度已完成功能
當離線數據小時級更新至引擎后，整個系統的request從左上方各場景進入，攜帶文本query或用戶特征trigger來到調控server，調控server將根據requestInfo與流控運營后臺推送的plan（針對某些請求調控某商品集抽象為一個plan） list進行匹配。結合生效的策略ID構建query進行調控引擎召回。召回結果配合算法中控產出<action, weight> (調控方式，力度)，給到上游對精排結果進行重排序，同時需要上游協助埋點的信息也同步落盤。實時數倉采集埋點后按照相應規則進行計算，反饋給中控及實時update調控引擎。
調控server內部職責如下：
各handler分別負責生效策略判別、召回策略分發，退場兜底機制、AB分桶、實時計算埋點構造，調用算法中控等，詳細實現不做展開。
基于搜神自研引擎的流控召回邏輯：
流控引擎當前支持面向搜索場景的文本召回及面向推薦的X2i兩類召回，trigger -> 商品的映射關系、底層數據與自然召回保持一致，候選集也是搜推場景召回候選集的真子集，可以確保相關性分層、真假曝光過濾等邏輯與各場景對齊；類目預測、貨號識別復用QP結果，推薦trigger和用戶行為序列也是復用的上游結果，因此單獨的調控召回鏈路并不會導致體驗問題。
另外針對于保量類型的新品調控，我們借助搜神自研引擎的擴展能力，定制了目標達成過濾filter以及優先級低于相關性的sort插件，一定程度上緩解了新品召回難得問題。
2.3 其他模塊：
2.3.1 實時數據：
中控的平滑控制、目標達成熔斷機制以及引擎sort/filter插件依賴的實時數據如下：
標簽名 | 描述 | 限制 | 處理邏輯 |
有效調控pv | 商品粒度干預曝光 | 每日0點累計 | key為[planId_場景_cspuId]，value為今日干預曝光累計(每天0點落離線后歸0) |
分場景有效調控PV | 場景粒度干預曝光 | 每日0點累計，場景內所有商品的干預曝光求和 | key為[planId_場景]，區分社區搜索、交易搜索，value為今日干預曝光累計(每天0點落離線后歸0)，=所有item干預曝光和 |
計劃維度有效調控PV | 運營計劃粒度干預曝光 | 每日0點累計，所有場景下的曝光按照計劃id求和 | key為[planId]，value為今日干預曝光累計(每天0點落離線后歸0)，=所有item干預曝光和 |
分場景調控品PV | 場景干預曝光 | 每日0點累計，場景內調控商品的干預曝光求和 | key為[planId_場景_實驗桶] value為今日干預曝光累計(每天0點落離線后歸0)，=odps表中的item干預曝光和 |
計劃維度調控PV | 跨場景計劃維度干預曝光 | 每日0點累計，所有場景下的調控品曝光按照計劃id求和 | key為[planId_實驗桶]，value為今日odps表中的item曝光累計(每天0點落離線后歸0)，=所有item干預曝光和 |
全站商品分場景PV | 場景干預曝光 | 每日0點累計，場景內所有商品的干預曝光求和 | key為[planId_場景_實驗桶_total]，區分搜索、推薦，value為今日干預曝光累計(每天0點落離線后歸0)，=odps表中的item干預曝光和 |
全站商品指定流量下PV | 運營計劃粒度干預曝光 | 每日0點累計，所有場景下所有商品的曝光按照計劃id求和 | key為[planId_實驗桶_total]，value為今日odps表中的item曝光累計(每天0點落離線后歸0)，=所有item干預曝光和 |
千川實時圈品pv | planId_場景_實驗桶 | 各調控策略在不同場景分實驗調控商品曝光數據 | 調控品曝光和，0-24點累計，acm埋點得到planid：cstpl_1-2-3 (1,2,3為planId)，調控kafka得到實驗桶，通過requestid關聯 |
千川實時圈品分實驗pv | planId_實驗桶 | 各調控策略全通道分實驗調控商品曝光數據 | 調控品曝光和，0-24點累計，acm埋點得到planId：cstpl_1-2-3 (1,2,3為planId)，調控kafka得到實驗桶，通過requestid關聯 |
全站商品分實驗PV | planId_場景_實驗桶_total | 各調控策略覆蓋的流量中，所有商品表現 | 所有item曝光和，0-24點累計，根據曝光埋點統計，調控kafka得到實驗桶和planId，通過requestid關聯 |
全站商品分實驗PV | 跨場景分實驗曝光 | 各調控策略覆蓋的流量中，所有商品在所以通道的表現 | 所有item曝光和，0-24點累計，根據曝光埋點統計，調控kafka得到實驗桶和planId，通過requestid關聯 |
以上指標基于客戶端上報的埋點、服務端日志kafaka、odps維表經實時數倉團隊計算所得，計算邏輯簡化如下：
2.3.2 效果數據：
商品效率報表，指商品在實驗組對照組的表現的絕對值、相對值差異，涵蓋曝光、點擊、成交、qvctr、cvr，pv 價值等指標。某個調控策略(plan)對這一批商品的影響則需要限制商品是被調控品，流量也必須是在指定的場景、人群特征、實驗、類目等條件下的效率報表，這部分不難理解。
AB實驗分流，由調控server承接各個來源的請求，并進行統一兩層正交AB，調控分層實驗組對照組邏輯如下：
a. 獨立實驗
- i. 對照組：獨立實驗對照組（固定）
- ii. 實驗組：策略(plan)配置的實驗組，根據每個策略的配置決定
b. 公共實驗（公共實驗一個流量分組可能疊加多個實驗，根據不同的商品范圍查看各自對品維度的影響）：
- i. 對照組：公共實驗對照組（固定）
- ii. 實驗組：策略(plan)配置的實驗組，根據每個策略的配置決定
以上，BI團隊可給出針對部分新品的某個扶持策略(plan)為例，可觀測的報表類似如下：
實時+離線的數據鏈路最終服務于調控引擎和算法中控
2.3.3 算法中控 ：
應對定量目標的保量需求，算法中控依托實時反饋數據進行的PID計算邏輯如下：
- 排序依據的score=rs*權重+相關性分 或者 score=rs*pctr/median(pctr)*權重 +相關性分權重= 1+ pid_score，權重區間 [0.1,10]
pid_score=(當前目標曝光-當前累計曝光量)/當前目標曝光*KI
當前目標曝光=計劃目標*當前時間曝光比例
應對曝光占比類型的比例調控需求稍有差異：
占比低于目標時扶持：
占比高于目標時打壓：
3、值得一提的
3.1 借鑒廣告體系的獨立召回鏈路
相比于之前的工作經驗和其他平臺的調研結果來看，類似廣告投放體系的獨立召回鏈路有如下幾點特征：
（1）在新品扶持等領域，依賴于自然召回后再判斷是否為調控品的邏輯，在針對“召回難”問題上并沒有特別好的方案，往往是通過粗排白名單等方式對粗排進行暴力干預，白名單存在上限以及相關性差的問題并沒有被解決。而獨立的召回鏈路中，我們天然的將底池限定為有且僅有調控商品，在相關性分層符合要求的情況下，調控商品的位置不會被非調控品擠占。同時依賴搜神自研引擎定制的達成率邏輯，也能防止部分調控商品擠占其他調控商品流量的問題。線上實際可保障99%的新品能夠獲得調控帶來的有效增量曝光(曝光位置提前)，同時整體保量目標達成率也可以滿足業務要求
（2）在增量曝光的判斷上更為準確：自然未能召回，僅調控有招回的概念，可以幫助我們判斷，無論這個商品的坑位是否發生變化，僅調控鏈路召回必然是增量曝光。有助于后續繼續推進基于運營分組預算管理的后臺系統
（3）前置過濾對比后置過濾，可以在有限的召回量內，給予其他商品更多機會
（4）負向上有一定缺陷，獨立鏈路召回的數量小于整體召回數量，會導致打壓效果下降。這一點還是反作弊平臺及風控系統黑名單直接對接商品底池的方式更為專業。
3.2 跨場景統一的AB實驗
各場景各服務單獨對接AB平臺，相互之間是隔離的，哈希規則也是定制化的。后續我們是期望多場景聯合調控中，增量目標的分配比例可以動態自動最優調配，同時回收各場景的ROI指標。熟悉報表的同學可以看到，即便是去萬三高客單后的AB數據，同一個實驗組多個實驗的情況下，指標仍有差異。獨立統一的調控正交分層可以保證無論是搜索還是推薦過來的同一個用戶，命中的實驗或者說策略是相同的，聯合調控可據此分層數據做參考。
4、后續方向
（1）完善平臺能力：
- 基本能力建設，包括撈月組件的接入，打通圈品集信息，實現一站式圈品及圈品規則維護；人群規則平臺的接入，簡化在線服務FeatureCondition的判別流程
- 調控平臺運營中心易用性及使用體驗上的建設工作，從數據分析、跨平臺信息的打通、小工具、去除冗余操作及預警通知等方面打磨產品，從“能用”到“好用”的長期目標
- 后臺增加配置中心，ark配置可視化，減少復雜json的變更成本；后期實現一鍵降級等功能；增加debug工具，測試在線系統召回、權重是否符合預期，提升debug及線上問題定位效率
- 異常熔斷機制完善，異常通知能夠傳達到owner及運營負責人，異常損失效果可評估。
（2）非商品調控能力建設：
- 底紋詞&搜索發現詞、搜索框下拉推薦詞等詞導購場景覆蓋，與query直達相結合，能夠通過更多低成本的場景支持業務扶持指定貨品的訴求
- 社區內容作為得物的核心場景，且當前社區內容中的商品標簽、動態詳情頁商品卡片已經建立了內容引導交易的良好機制，無論是針對商品標簽的內容調控，還是定向為作者推送待扶持商品的提示等方向，都存在著探索的空間和價值，期待后續可以探索社區&交易聯合調控的落地場景。
（3）支撐場景擴展：
- 支持更多推薦場景，期望后續能夠在品牌落地頁、分類tab等場景進行實驗，挖掘不同類型的商品集合在不同場景的ROI最優方案。
- 跨場景聯合調控能力探索，跨場景目標分配、商品質量預估及評估、跨場景核心指標對齊等角度進行探索；幫助業務方在精細化人貨匹配上的探索拿到結果。
