1、研發(fā)背景

1.1 我們想要解決什么問題？

我們期望平臺能夠覆蓋的三類運(yùn)營訴求如下：

（1）突發(fā)事件的應(yīng)對：包括不限于外部的不可抗力影響，網(wǎng)絡(luò)上的熱點(diǎn)事件、爆倉等突發(fā)事件，在搜索&推薦等個(gè)性化流量場景下，單純依靠算法模型的學(xué)習(xí)來適應(yīng)，時(shí)間上不被業(yè)務(wù)方接受。

（2）新品/新人等缺少數(shù)據(jù)的情況：在扶持新品、留存新人等問題上，新品召回難、個(gè)性化分?jǐn)?shù)低導(dǎo)致排名靠后無法曝光，而新人缺少畫像也會對推薦效果造成影響。因此對于新品的加權(quán)、新人定向投放需要頻繁調(diào)整的情況，往往需要人工進(jìn)行變更。

（3）平臺的實(shí)驗(yàn)/探索項(xiàng)目：如品類價(jià)格帶分布控制，一些探索嘗試性的實(shí)驗(yàn)，需要先小流量定向推送指定商品進(jìn)行實(shí)驗(yàn)，取得一定結(jié)果、經(jīng)驗(yàn)后，再進(jìn)行優(yōu)化、推全等情況。需要在圈品、圈人、AB實(shí)驗(yàn)、數(shù)據(jù)大盤等多角度進(jìn)行分析；頻繁的調(diào)整策略打法，也需要技術(shù)側(cè)進(jìn)行迭代升級。

1.2 為什么要做成平臺？

不搭建平臺，我們也快速地落地過高UE商品加權(quán)、價(jià)格力商品扶持等業(yè)務(wù)方訴求，做法一般是通過對召回引擎中的商品打上標(biāo)記，在上游系統(tǒng)識別到某次請求復(fù)合業(yè)務(wù)的定向投放規(guī)則時(shí)，對有標(biāo)記的商品進(jìn)行加權(quán)。同時(shí)統(tǒng)計(jì)埋點(diǎn)數(shù)據(jù)，評估商品實(shí)驗(yàn)組與基準(zhǔn)對照組的diff，確保扶持的力度符合業(yè)務(wù)預(yù)期。而平臺化在初期投入大量研發(fā)成本的原因主要是針對以下兩點(diǎn)：

（1）研發(fā)&時(shí)間成本：每個(gè)策略的新增都需要從商品打標(biāo)到引擎，在線鏈路對指定流量的判別、算法加權(quán)、實(shí)時(shí)數(shù)據(jù)反饋、離線數(shù)據(jù)報(bào)表等環(huán)節(jié)進(jìn)行迭代，需要BI、引擎dump、召回層、預(yù)估算法、實(shí)時(shí)數(shù)倉等多個(gè)團(tuán)隊(duì)投入合計(jì)至少10~12人日的研發(fā)資源，同時(shí)PMO、各團(tuán)隊(duì)leader及PM、項(xiàng)目聯(lián)調(diào)、測試資源、線上變更CR等間接投入也會積少成多。

（2）多場景問題：不同場景重復(fù)建設(shè)也會帶來成本的增加不再贅述，更多的是相同的用戶在不同場景有各自的分流規(guī)則，如何統(tǒng)一的進(jìn)行AB實(shí)驗(yàn)和數(shù)據(jù)統(tǒng)計(jì)分析也存在著一定問題。一部分商品加權(quán)也必然會擠占其他商品自然曝光的流量，這部分被擠占的流量是我們的運(yùn)營成本。如何評估各場景的ROI，在單個(gè)場景效果不盡如人意的情況停止投放如何復(fù)盤該場景的資源投入，也是我們需要面對的問題。

1.3我們是怎么做的？

上述的三類問題其實(shí)可以統(tǒng)一抽象為：用戶隨時(shí)可以選擇一個(gè)商品集，在指定的流量下(人群標(biāo)簽、query類目、品牌、AB實(shí)驗(yàn)分組、時(shí)間段等)進(jìn)行某項(xiàng)扶持（加權(quán)、保量、曝光占比、按比例提升等）。我們大體將實(shí)現(xiàn)該能力的系統(tǒng)劃分為5個(gè)模塊，如下圖所示：

（1）流量運(yùn)營中心：支持運(yùn)營同學(xué)自由配置策略，更換商品集、調(diào)整投放條件、完整的審批流程、報(bào)表的查閱等等運(yùn)營操作；策略的新增及變更不再需要需求排期和研發(fā)周期的漫長等待。

（2）流量服務(wù)中心：用于將運(yùn)營配置的流量規(guī)則與在線請求做匹配，同時(shí)負(fù)責(zé)串聯(lián)算法中控、調(diào)控商品召回、埋點(diǎn)上報(bào)、容災(zāi)限流等工作，是調(diào)控鏈路的樞紐。

（3）數(shù)據(jù)計(jì)算中心：主要是兩部分職責(zé)，其一是將運(yùn)營配置的商品集、站內(nèi)基礎(chǔ)數(shù)據(jù)，商品增量目標(biāo)完成情況等離線數(shù)據(jù)全量更新至搜索引擎。另一部分則是在線鏈路的分鐘級統(tǒng)計(jì)實(shí)時(shí)數(shù)據(jù)，商品的分實(shí)驗(yàn)、分策略、分場景實(shí)時(shí)累計(jì)數(shù)據(jù)同步給算法中控做決策，及搜索引擎實(shí)時(shí)更新召回過濾條件的依據(jù)。

（4）流量算法中控：調(diào)控鏈路召回的商品需要由中控根據(jù)商品特征、用戶畫像、預(yù)估分、目標(biāo)達(dá)成進(jìn)度及增長速度等系數(shù)，實(shí)時(shí)調(diào)整每個(gè)被調(diào)控品的調(diào)控力度，負(fù)責(zé)平滑控制和過量熔斷等職責(zé)，是整個(gè)調(diào)控系統(tǒng)的大腦。

（5）保障設(shè)施：圍繞著穩(wěn)定性、問題定位效率等角度建設(shè)的基礎(chǔ)設(shè)施，不做贅述。

下面對技術(shù)鏈路進(jìn)行展開。

2、技術(shù)鏈路

2.1 業(yè)務(wù)架構(gòu)：

經(jīng)過2022 Q4季度的研發(fā)工作，當(dāng)前場景已經(jīng)覆蓋了交易搜索及部分推薦場景。線上支持業(yè)務(wù)策略包括：新品保量、高UE商品加權(quán)、重復(fù)曝光/獵奇商品曝光比例下調(diào)等業(yè)務(wù)訴求。同時(shí)調(diào)控為了更多個(gè)性化流量通道的接入也完成了非文本個(gè)性化多路召回等通用能力的建設(shè)工作。運(yùn)營后臺的通用報(bào)表、審批流程、變更歷史對比等能力基本建設(shè)完成。

2.2 工程鏈路：

· 藍(lán)色框?yàn)樾?022 Q4建設(shè)，白色框?yàn)镼3季度已完成功能

當(dāng)離線數(shù)據(jù)小時(shí)級更新至引擎后，整個(gè)系統(tǒng)的request從左上方各場景進(jìn)入，攜帶文本query或用戶特征trigger來到調(diào)控server，調(diào)控server將根據(jù)requestInfo與流控運(yùn)營后臺推送的plan（針對某些請求調(diào)控某商品集抽象為一個(gè)plan） list進(jìn)行匹配。結(jié)合生效的策略ID構(gòu)建query進(jìn)行調(diào)控引擎召回。召回結(jié)果配合算法中控產(chǎn)出<action, weight> (調(diào)控方式，力度)，給到上游對精排結(jié)果進(jìn)行重排序，同時(shí)需要上游協(xié)助埋點(diǎn)的信息也同步落盤。實(shí)時(shí)數(shù)倉采集埋點(diǎn)后按照相應(yīng)規(guī)則進(jìn)行計(jì)算，反饋給中控及實(shí)時(shí)update調(diào)控引擎。

調(diào)控server內(nèi)部職責(zé)如下：

各handler分別負(fù)責(zé)生效策略判別、召回策略分發(fā)，退場兜底機(jī)制、AB分桶、實(shí)時(shí)計(jì)算埋點(diǎn)構(gòu)造，調(diào)用算法中控等，詳細(xì)實(shí)現(xiàn)不做展開。

基于搜神自研引擎的流控召回邏輯：

流控引擎當(dāng)前支持面向搜索場景的文本召回及面向推薦的X2i兩類召回，trigger -> 商品的映射關(guān)系、底層數(shù)據(jù)與自然召回保持一致，候選集也是搜推場景召回候選集的真子集，可以確保相關(guān)性分層、真假曝光過濾等邏輯與各場景對齊；類目預(yù)測、貨號識別復(fù)用QP結(jié)果，推薦trigger和用戶行為序列也是復(fù)用的上游結(jié)果，因此單獨(dú)的調(diào)控召回鏈路并不會導(dǎo)致體驗(yàn)問題。

另外針對于保量類型的新品調(diào)控，我們借助搜神自研引擎的擴(kuò)展能力，定制了目標(biāo)達(dá)成過濾filter以及優(yōu)先級低于相關(guān)性的sort插件，一定程度上緩解了新品召回難得問題。

2.3 其他模塊：

2.3.1  實(shí)時(shí)數(shù)據(jù)：

中控的平滑控制、目標(biāo)達(dá)成熔斷機(jī)制以及引擎sort/filter插件依賴的實(shí)時(shí)數(shù)據(jù)如下：

以上指標(biāo)基于客戶端上報(bào)的埋點(diǎn)、服務(wù)端日志kafaka、odps維表經(jīng)實(shí)時(shí)數(shù)倉團(tuán)隊(duì)計(jì)算所得，計(jì)算邏輯簡化如下：

2.3.2 效果數(shù)據(jù)：

商品效率報(bào)表，指商品在實(shí)驗(yàn)組對照組的表現(xiàn)的絕對值、相對值差異，涵蓋曝光、點(diǎn)擊、成交、qvctr、cvr，pv 價(jià)值等指標(biāo)。某個(gè)調(diào)控策略(plan)對這一批商品的影響則需要限制商品是被調(diào)控品，流量也必須是在指定的場景、人群特征、實(shí)驗(yàn)、類目等條件下的效率報(bào)表，這部分不難理解。

AB實(shí)驗(yàn)分流，由調(diào)控server承接各個(gè)來源的請求，并進(jìn)行統(tǒng)一兩層正交AB，調(diào)控分層實(shí)驗(yàn)組對照組邏輯如下：

a. 獨(dú)立實(shí)驗(yàn)

1. i. 對照組：獨(dú)立實(shí)驗(yàn)對照組（固定）
2. ii. 實(shí)驗(yàn)組：策略(plan)配置的實(shí)驗(yàn)組，根據(jù)每個(gè)策略的配置決定

b. 公共實(shí)驗(yàn)（公共實(shí)驗(yàn)一個(gè)流量分組可能疊加多個(gè)實(shí)驗(yàn)，根據(jù)不同的商品范圍查看各自對品維度的影響）：

2. i. 對照組：公共實(shí)驗(yàn)對照組（固定）
3. ii. 實(shí)驗(yàn)組：策略(plan)配置的實(shí)驗(yàn)組，根據(jù)每個(gè)策略的配置決定

以上，BI團(tuán)隊(duì)可給出針對部分新品的某個(gè)扶持策略(plan)為例，可觀測的報(bào)表類似如下：

實(shí)時(shí)+離線的數(shù)據(jù)鏈路最終服務(wù)于調(diào)控引擎和算法中控

2.3.3 算法中控 ：

應(yīng)對定量目標(biāo)的保量需求，算法中控依托實(shí)時(shí)反饋數(shù)據(jù)進(jìn)行的PID計(jì)算邏輯如下：

• 排序依據(jù)的score=rs*權(quán)重+相關(guān)性分 或者 score=rs*pctr/median(pctr)*權(quán)重 +相關(guān)性分權(quán)重= 1+ pid_score，權(quán)重區(qū)間 [0.1,10]
  pid_score=(當(dāng)前目標(biāo)曝光-當(dāng)前累計(jì)曝光量)/當(dāng)前目標(biāo)曝光*KI
  當(dāng)前目標(biāo)曝光=計(jì)劃目標(biāo)*當(dāng)前時(shí)間曝光比例

應(yīng)對曝光占比類型的比例調(diào)控需求稍有差異：

占比低于目標(biāo)時(shí)扶持：

占比高于目標(biāo)時(shí)打壓：

3、值得一提的

3.1 借鑒廣告體系的獨(dú)立召回鏈路

相比于之前的工作經(jīng)驗(yàn)和其他平臺的調(diào)研結(jié)果來看，類似廣告投放體系的獨(dú)立召回鏈路有如下幾點(diǎn)特征：

（1）在新品扶持等領(lǐng)域，依賴于自然召回后再判斷是否為調(diào)控品的邏輯，在針對“召回難”問題上并沒有特別好的方案，往往是通過粗排白名單等方式對粗排進(jìn)行暴力干預(yù)，白名單存在上限以及相關(guān)性差的問題并沒有被解決。而獨(dú)立的召回鏈路中，我們天然的將底池限定為有且僅有調(diào)控商品，在相關(guān)性分層符合要求的情況下，調(diào)控商品的位置不會被非調(diào)控品擠占。同時(shí)依賴搜神自研引擎定制的達(dá)成率邏輯，也能防止部分調(diào)控商品擠占其他調(diào)控商品流量的問題。線上實(shí)際可保障99%的新品能夠獲得調(diào)控帶來的有效增量曝光(曝光位置提前)，同時(shí)整體保量目標(biāo)達(dá)成率也可以滿足業(yè)務(wù)要求

（2）在增量曝光的判斷上更為準(zhǔn)確：自然未能召回，僅調(diào)控有招回的概念，可以幫助我們判斷，無論這個(gè)商品的坑位是否發(fā)生變化，僅調(diào)控鏈路召回必然是增量曝光。有助于后續(xù)繼續(xù)推進(jìn)基于運(yùn)營分組預(yù)算管理的后臺系統(tǒng)

（3）前置過濾對比后置過濾，可以在有限的召回量內(nèi)，給予其他商品更多機(jī)會

（4）負(fù)向上有一定缺陷，獨(dú)立鏈路召回的數(shù)量小于整體召回?cái)?shù)量，會導(dǎo)致打壓效果下降。這一點(diǎn)還是反作弊平臺及風(fēng)控系統(tǒng)黑名單直接對接商品底池的方式更為專業(yè)。

3.2 跨場景統(tǒng)一的AB實(shí)驗(yàn)

各場景各服務(wù)單獨(dú)對接AB平臺，相互之間是隔離的，哈希規(guī)則也是定制化的。后續(xù)我們是期望多場景聯(lián)合調(diào)控中，增量目標(biāo)的分配比例可以動(dòng)態(tài)自動(dòng)最優(yōu)調(diào)配，同時(shí)回收各場景的ROI指標(biāo)。熟悉報(bào)表的同學(xué)可以看到，即便是去萬三高客單后的AB數(shù)據(jù)，同一個(gè)實(shí)驗(yàn)組多個(gè)實(shí)驗(yàn)的情況下，指標(biāo)仍有差異。獨(dú)立統(tǒng)一的調(diào)控正交分層可以保證無論是搜索還是推薦過來的同一個(gè)用戶，命中的實(shí)驗(yàn)或者說策略是相同的，聯(lián)合調(diào)控可據(jù)此分層數(shù)據(jù)做參考。

4、后續(xù)方向

（1）完善平臺能力：

1. 基本能力建設(shè)，包括撈月組件的接入，打通圈品集信息，實(shí)現(xiàn)一站式圈品及圈品規(guī)則維護(hù)；人群規(guī)則平臺的接入，簡化在線服務(wù)FeatureCondition的判別流程
2. 調(diào)控平臺運(yùn)營中心易用性及使用體驗(yàn)上的建設(shè)工作，從數(shù)據(jù)分析、跨平臺信息的打通、小工具、去除冗余操作及預(yù)警通知等方面打磨產(chǎn)品，從“能用”到“好用”的長期目標(biāo)
3. 后臺增加配置中心，ark配置可視化，減少復(fù)雜json的變更成本；后期實(shí)現(xiàn)一鍵降級等功能；增加debug工具，測試在線系統(tǒng)召回、權(quán)重是否符合預(yù)期，提升debug及線上問題定位效率
4. 異常熔斷機(jī)制完善，異常通知能夠傳達(dá)到owner及運(yùn)營負(fù)責(zé)人，異常損失效果可評估。

（2）非商品調(diào)控能力建設(shè)：

1. 底紋詞&搜索發(fā)現(xiàn)詞、搜索框下拉推薦詞等詞導(dǎo)購場景覆蓋，與query直達(dá)相結(jié)合，能夠通過更多低成本的場景支持業(yè)務(wù)扶持指定貨品的訴求
2. 社區(qū)內(nèi)容作為得物的核心場景，且當(dāng)前社區(qū)內(nèi)容中的商品標(biāo)簽、動(dòng)態(tài)詳情頁商品卡片已經(jīng)建立了內(nèi)容引導(dǎo)交易的良好機(jī)制，無論是針對商品標(biāo)簽的內(nèi)容調(diào)控，還是定向?yàn)樽髡咄扑痛龀稚唐返奶崾镜确较?，都存在著探索的空間和價(jià)值，期待后續(xù)可以探索社區(qū)&交易聯(lián)合調(diào)控的落地場景。

（3）支撐場景擴(kuò)展：

1. 支持更多推薦場景，期望后續(xù)能夠在品牌落地頁、分類tab等場景進(jìn)行實(shí)驗(yàn)，挖掘不同類型的商品集合在不同場景的ROI最優(yōu)方案。
2. 跨場景聯(lián)合調(diào)控能力探索，跨場景目標(biāo)分配、商品質(zhì)量預(yù)估及評估、跨場景核心指標(biāo)對齊等角度進(jìn)行探索；幫助業(yè)務(wù)方在精細(xì)化人貨匹配上的探索拿到結(jié)果。