OPPO智慧增長演算法核心架構與應用
本文將分享在智慧手機這一製造行業下,OPPO Andes智慧雲團隊所採用的智慧增長演算法的核心架構,以及相關的應用場景。
01 行業背景
智慧手機行業作為典型的硬體製造業,與大眾生活息息相關。
國家統計局統計顯示手機上網人數10.65億人,還未手機上網的一般是未成年、老年人,手機行業幾乎沒有增量。在存量使用者需求端,使用者的換機週期越來越長。去年和前年的對比,1-2年的持機使用者佔比從15%下降到13%,2~3年的使用者佔比從28%下降到22%,3~4年的使用者佔比從24%增加到28%,4年及以上的使用者佔比從28%增加到31%。
從供給端看,20年、21年經歷了供給內卷,所有廠商都在瘋狂出新品,競爭剩餘的增量。去年新品數量恢復到19年水平,但是上市2年以上的機型逐年下降,主要原因可能是老機型產品沒有競爭力,被迫退出市場。進入23年,國內安卓陣營競爭更加劇烈,在微博、B站等社群都能看出戰場痕跡。
隨著智慧手機風口過去,手機公司可能面臨許多挑戰。一般來說,它們可以從以下四個方向來應對這些挑戰:
第一個方向是擴充高價值市場,例如海外已開發國家或國內高階市場。
第二個方向是增加手機的附加值,例如提升手機網際網路服務的平均使用者收入(ARPU)。
第三個方向是增加新的運營主線,例如擴充智慧穿戴裝置或汽車行業。
第四個方向是提升渠道效率和營銷模式,例如增加效果營銷,或透過線下和線上渠道的互補來促進使用者的粘性。
OPPO在過去兩年的智慧增長探索中,主要積累了第三和第四個方向上的經驗。接下來將分享相關的增長策略。
02 演算法架構
近年來,在深度學習的推動下,各行業的智慧演算法架構基本上都採用TensorFlow或PyTorch作為底座,以此為基礎進行構建,降低了技術門檻,同時享受到了技術紅利,做出有行業特色的創新和優勢。就手機行業而言,它既擁有網際網路巨頭的資料優勢,又面臨著製造業智慧改造的挑戰。
以下是OPPO團隊的整體演算法架構。手機增長的演算法架構主要包括基礎資料、資料建設、特徵畫像、模型建設和應用場景這五個部分。
基礎資料方面,手機增長演算法所需的主要資料包括:
手機狀態:一般是作業系統層面的各類字串或數值型別的狀態資料,主要用於建模使用者生命週期。
商品屬性:指待售商品的一些基本屬性,如記憶體、大小、賣點、權益等。
訂單資料:指使用者購買手機時的關鍵資料。
營銷投放:指在智慧增長過程中干預使用者的資料,通常包括RTA、RTB以及廣告投放的資料,或其他訊息日誌。
實時行為:主要描述使用者在手機上的部分實時反饋。
素材:為提升干預效果而準備的一些內容。
為了提升資料複用效率和擴充套件性,要在基礎資料的基礎上,做一系列標準化、規範化處理,再基於手機的流轉關係抽取使用者的流轉關係圖。這裡的自然人是描述手機和自然人的對映關係。完成資料建設後,特徵畫像的建設和業界大多數做法比較相似,包括實時統計類、實時序列類、內容理解、使用者長期畫像,不過也有一部分是行業特有的,手機流轉畫像和營銷節點畫像,主要刻畫手機市場的競爭關係和因應手段。
在模型建設方面,我們採用了以下方法:
因果模型(Uplift):用於刻畫營銷的邊際收益,並減少負向干預,用於換機預測。
PU-learning方法:用於準確找到干預的精準人群,減少對使用者資訊的干擾。
多模態理解:主要用於文字和影像的預訓練。
PID方法:主要是一種自動控制能力,用於滿足大部分場景的自動約束需求。
AIGC方法:透過Stable Diffusion模型的能力,輸出圖片素材。
CTR和CVR:主要用於鏈路上點選率和轉化率的預估。
這些模型和演算法的應用場景包括以下幾個方面:
RTA和RTB:涉及廣告投放場景,包括域內和域外的廣告投放。
社群和商城:指OPPO的自有平臺,是使用者運營和手機自營的營銷核心渠道。
權益和Push:綜合干預渠道。
以上就是OPPO演算法層面的整體架構。
從工程層面,我們看下怎麼解決智慧改造的技術方案。最最側的智選模組,完成演算法場景的自動接入。手機增長涉及的鏈路很長,比如從新機賣點洞察、人群營銷洞察、新機預熱、首銷、促銷,並且每個鏈路的場景很多,智選主要滿足了場景快速接入的需求,並且解耦運營、工程、演算法,支撐演算法專注在效果最佳化上。營銷雲主要用於素材生成、廣告投放管理、分析監控。中間引擎模組是推薦引擎,透過召回、粗排、精排、重排、策略運算元的自由組合,滿足定製化需求。為了進一步提升引擎的靈活性,我們對多樣性、多目標、重排、策略模組做了DSL改造,支撐團隊的演算法探索。另外由於機器成本的約束,上面的很多步驟在使用時都可以0成本的插拔,以降低延遲、提升吞吐。
上述演算法架構主要是基於OPPO的Andes智慧雲完成的。得益於智慧雲的基礎設施的靈活性和易用性,我們在協作方面,特別是跨團隊、跨部門和跨系統的協作上擁有較好的解決方案。
03 應用場景
接下來將分享4 個具體的應用場景案例,第一個案例是基於 AIGC 的內容供給;第二個案例是在商城中,基於多場景、多目標、多模態的推薦;第三個案例是基於因果推斷的精準人群定位;第四個案例是在手機行業裡的廣告精準營銷。
1.第一個應用場景:基於AIGC的內容供給
首先,我們意識到在非演算法領域或傳統制造行業中,業務團隊可能需要一些科普才能理解內容供給的重要性。因此,我們與業務夥伴合作時採用了講道理和資料展示的方式,在一些小的場景中透過實驗驗證了擴大內容供給量的益處。我們觀察到,透過增加內容供給量,可以顯著提高點選率,獲得15%的點選率提升,從而達成了共識。
另一個挑戰是供給效率和人力成本。最初,內容供給的流程依賴於人工,即設計師輸出一些素材,經過安全稽核後投放到線上。這個過程相對低效。為此,我們團隊進行了第一次改造,採用工程模板製圖的方式。這樣,內容供給的流程發生了改變:設計師集中精力在模板創作上,然後透過模板生成大量候選素材,經過初審和安全稽核後進行投放。透過這次改造,每天初審的內容數量顯著增加。然而,也出現了新的問題:模板的重複率較高,生成的候選素材資訊量不足,容易讓使用者感到千篇一律。
目前,隨著AIGC技術的不斷成熟,我們調研了AIGC的相關方案,並發現該技術實際上可以增加模板的創作難度同時增加資訊量。因此,我們與相關的團隊合作,引入AIGC技術來增加素材創作的資訊量,以提升使用者體驗。
目前,我們使用的AIGC模型主要是CLIP模型,它的主要思路是透過大量的影像資料和文字資料進行模型預訓練,使模型能夠理解影像和自然語言之間的對應關係,從而實現跨模態的語義推理。為了實現這個目標,我們生成模型的框架涉及兩個元件。第一個是影像編碼器,基於Transformer架構,將影像特徵轉化為Embedding向量。第二個是文字編碼器,基於VILT架構,將自然語言轉化為特徵向量。基於這兩種向量,我們結合交叉熵學習和對比學習的方法,進行模型的訓練。在預訓練階段,我們參考了一些開源資料和OPPO私有的影像和文字資料,並在Andes智慧雲的GPU叢集上進行訓練。
在生成部分,我們經過了多次嘗試,以使AIGC輸出的內容符合廣告投放的需求。目前發現,透過新增關鍵詞、賣點、營銷話術、圖文風格、負面反饋以及影像細節的提示,可以有助於生成素材。最右側的示例展示了結合素材和模板生成的最終結果,其中背景圖就是一個例子。
2.第二個應用場景:多場景、多目標的多模態推薦
如上圖所示,我們目前的業務場景主要是在商城介面進行推薦。例如,在首頁的橫幅廣告部分、格子位、瀑布流推送以及積分、社群、優惠券發放等場景中進行推薦。
在演算法介面方面,我們已經接入了近幾百個業務場景,需要關注點選率、轉化率、GMV等業務指標。同時,手機行業記憶體在人力約束,這對演算法提出了不同的需求。
我們一開始就採用了跨場景多目標的模型方案來進行推薦,隨著場景的增加,我們不斷對模型進行迭代最佳化。後來,我們還增加了一些非產品內容的推薦,例如社群、影片等。此外,對於內容素材的需求,我們也需要在多模態模型中引入一些新的能力。
經過不斷迭代,我們的模型如上圖所示。左側部分是多模態的理解,模型主要基於ViLT的結構。透過對比發現,經過業務資料微調的ViLT模型比公開的ViIT模型效果更好。我們進行了大量的分析,發現實際業務場景的資料與公開資料集存在較大差異,特別是在營銷話術等垂直領域方面。右側部分是推薦模型,該模型結構融合了最新論文的進展。底層模型主要基於歷史行為、上下文和候選物料三個部分。對於候選物料,我們目前採用對應的多模態預訓練特徵。實時統計的行為會使用Encoding 的方法進行向量化表示,而上下文內容我們會額外區分場景和domain特徵進行向量化。
在多模態多感場景感知模組中,我們主要使用Transformer和場景專屬的方法。在最上層,我們為目標設定了專門的tower,最終得到目標的比例結果。經過測試對比,我們發現引入AITM的多目標校準方法可以獲得一定的收益。在多目標層面,與傳統電商相比,我們會加入更多的目標,這與行業特點有關。例如,在手機行業中,每個使用者可能需要兩三年才會更換手機,這導致轉化率很低。同時,換機使用者中復購的比例也較低。因此,為了準確捕捉使用者當前的換機意圖,我們需要增加其他目標來輔助發現使用者的意圖,例如評論檢視、時長相關和商險相關的目標。得到這些目標後,我們使用近似排序公式計算得分,該得分是各個目標的連乘結果。同時,每個目標受到三個超引數α、β、γ的約束,目前這些超引數透過離散超參模型學習得到。
經過多次迭代,包括增加更多目標、引入多模態、最佳化超引數等措施,相較於原有模型,我們在轉化率(CVR)上取得了累計20%以上的收益。
3.第三個應用場景:基於因果推斷的精準人群
手機行業中的“精準人群”概念與電商平臺的劃分有所不同,這是因為使用者購買手機的行為具有不一樣的特點。舉個例子,假設使用者A,他可能會選擇繼續購買當前品牌的手機,也可能會換到其他品牌。對於已購買當前品牌的使用者,他們可能有兩種行為,一種是自己使用手機(留存),另一種是贈送給他人。然而,由於線上和線下資料的隱私安全等問題,手機公司只能獲取到部分購買和換機的資料。手機行業的增長目標是透過現有資料識別出購機和留存使用者,並透過營銷活動增加商品的粘性。這就是精準人群的背景場景。
因此,在演算法團隊進行人群建模時,主要關注兩個指標:準確率和召回率。通常情況下,我們很難獲取到完整準確的營銷資料,因此在實踐中,我們會花費更多時間進行特徵畫像和使用者分析,透過多種方法挖掘真實的購機使用者,併疊加相應的模型方案,從而得到最終的精準人群。
我們採用了多種方法,例如Look-Alike、PU-learning和Graph-learning等方法,來獲取相對精準的人群。
在營銷中,只有精準人群是不足夠的,因為對於營銷四象限圖中的B、C、D三個象限的人群進行營銷可能效果甚微,不符合預期。我們的核心目標仍然是針對A人群,因此這個問題實際上轉化為一種因果推斷的問題。
在演算法層面上,在滿足一定條件的情況下,因果推斷可以等價於計算Uplift,這種模型通常有三種建模思路:
Two-Model:分別建模基準組、控制組的模型,兩者相減就是結果。缺點是兩個模型有誤差累積
Single-Model:參考推薦領域的多目標模型,解決了模型誤差
Direct-Model:直接建模ITE
在典型的推廣搜演算法領域,假設訓練資料和預測資料獨立同分布,能不斷產出很好的結果。在因果推斷上,由於一個人要麼有干預、要麼沒有干預,沒辦法在同一環境下同時觀察到基準組、控制組的結果。因此需要使用因果模型來解決uplift建模問題。Uplift建模時有兩個挑戰:
由於業務需求,導致兩組資料的分佈不同。
一般業務只會保留很小一部分使用者作為基準組,樣本數量不均,也會給模型建模帶來困難。
我們嘗試了DESCN的論文思路,使用了干預組和控制組的全樣本,這樣的結構相當於使用了Single-Model的思路實現。這篇論文主要創新點在於使用了meta-learning的思想,引入一個網路來學習中間變數treatment。
在深入迭代時我們還會遇到具體的業務問題,比如在t1時間段,業務需要干預左邊和右邊的人群,過了一段時間後在t2時刻,業務需要干預中間的人群,在t3時刻干預的人群又變了。這種業務人群變化劇烈的問題給因果推斷提出了更高的挑戰。
我們是這麼來看待這個問題,這個問題本質上屬於曝光選擇偏差的問題,需要對曝光bias給消除掉才能準確建模。我們參考了EUEN(Explicit Uplift Effect Network 顯式提升效應網路)的論文方法,μt(X,最終的uplift) = μc(x, 控制組的轉化率) + ω(X, 曝光機率) · τe(X, 曝光組的uplift)。基於樣本是否曝光的修正,降低業務曝光選擇偏差導致的模型有偏。
由於因果推斷的反事實特性,上線驗證成本很高,所有的最佳化都會優先在離線驗證全部細節,離線保證了正確性,再開展線上實驗。在當前的增量實驗裡能看到和最初的監督模型,在增量ROI上提升了11.3%。
4.第四個應用場景:廣告精準營銷
對於手機廠商來說,資料隱私是至關重要的,所有資料都必須保持在公司內部,不允許洩露。因此,在進行營銷活動時,我們首先考慮的是資料安全性,在域外投放或者在其他廣告平臺基於人群包投放的這類方法是行不通的。我們採用了一些更安全的方法來獲取流量,如實時API(RTA)和實時競價(RTB)的模式。基於RTA和RTB,我們還建立了內部的營銷雲平臺,用於整合不同渠道的流量,以提高迭代效率。
簡單介紹一下RTA和RTB。RTA代表實時API(Real Time API),它決定了我們是否選擇某個流量。RTB代表實時競價(Real Time Bidding),它決定了我們是否參與競價以及以何種價格參與競爭某個流量。
接下來介紹一些與廣告精準營銷相關的獨特技術。
在RTB渠道的競價過程中,模型主要考慮三個目標:競價成功率、點選率和轉化率。競價成功率指的是在基礎出價下成功獲得流量的機率,該目標用於後續的價格調整策略;轉化率指的是使用者點選後進行轉化的機率,該目標也會影響出價策略的調整,並且在很大程度上決定了整體投放的投資回報率(ROI)。
模型的整體結構與多工多路輸出(MMOE)的結構相似,我們額外增加了每個目標單獨的輸出層。特徵部分主要包括長期特徵、實時特徵和多模態特徵。透過觀察發現,渠道的實時特徵對ROI影響非常大,而多模態特徵對於冷啟動問題非常有幫助。
我們發現,在RTB中,點選率(CTR)預估的準確性對於流量競價的投資回報率(ROI)有很大的影響。例如,如果CTR的預估值高於實際統計值,會導致競得的流量價值高於實際值,從而降低投放的ROI;而如果CTR的預估值低於實際統計值,則會導致競得率下降,無法獲得足夠的流量,無法充分利用預算。
我們的目標是希望模型的預估值和後驗統計值能夠在相應的水平線上,以準確預估真實情況。通常情況下,原始模型和後驗模型之間存在一定的差距,需要進行調整。我們當前的校準策略是採用了特徵敏感的樹模型的分箱策略,參考了一篇22年的公開論文。相對於原有的模型,經過CTR分桶校準後的模型,PCOC值會下降約44%。PCOC反映了預估值和真實值之間的偏差。PCOC值下降意味著模型更加準確,相應的ROI也會有較大提升。
下面介紹我們在投放時的出價策略。我們在RTB上採用了與業界常規不同的公式,考慮了更多因素。首先是素材的基礎出價,然後是素材的CTR打分。我們還會預估素材的流量價值,主要包括轉化率、使用者換機機率以及在換機時成為增量使用者的機率。此外,我們還會考慮預算和ROI的限制。同時,我們還會增加競得率因子。所有這些因素透過連乘計算。在實際應用中,我們可能會對計算結果進行排序或進行截斷操作。
經過多次迭代和實驗,我們發現,針對ROI的這些多因素考慮可以使其提升約25%。
04 總結和展望
在手機行業做增長的過程中,有一些方法論是必要的,其中最重要的是要確定一個北極星指標,即定義出識別增長的核心指標。我們大致梳理了一下,包括新機啟用、老使用者留存、復購率、使用者流失以及干預的投資回報率(ROI)等宏觀指標。這些宏觀指標對於製造行業尤其重要,能夠顯著幫助我們凝聚資料業務邏輯的共識。除了北極星指標外,我們在具體的鏈路上也制定了可量化的指標。總結來說,主要包括以下幾塊內容:
首先是新機洞察,這是增長的源泉,透過深入瞭解其中的邏輯,能夠顯著提升業務。這部分主要包括行業特點的分析,如競品的賣點分析、同期市場的社會分析,以及可應用於營銷的策略和首銷期使用者的反饋。
第二個是營銷敏感人群,我們關注的是一些演算法指標,包括準確率、召回率、AUCC(Average Uplift in Conversion Rate)和AUUC(Average Uplift in User Conversion)。後兩個指標與因果推斷相關。
接下來是從花錢的角度來看增長,大致可以分為免費增長和付費增長兩類。在免費增長方面,我們注重透過提升現有流量的效率來實現增長,關注的指標有很多,例如點選率、競得率、轉化率、品類流轉和增量ROI等。這些指標可能會隨著迭代的進行而增加或剔除,以符合當前的業務需求。
在付費增長方面,我們主要關注預算分配等指標。預算分配不僅限於廣告領域,還包括不同渠道和資源方之間的動態排程,比如京東和自營之間的動態分配,或者首周不同時間段的預算排程。我們總結發現,在不同時間段或跨渠道之間進行資源分配對於投放ROI具有非常大的影響。
來自 “ DataFunTalk ”, 原文作者:吳存華;原文連結:https://server.it168.com/a2023/1101/6827/000006827402.shtml,如有侵權,請聯絡管理員刪除。
相關文章
- 以智慧資料架構,挖掘增長金礦架構
- 有道詞典Flutter架構與應用Flutter架構
- 微核心架構在大型前端系統中的應用架構前端
- 一文搞懂應用架構的3個核心概念應用架構
- 遊戲類應用增長策略:應用交叉推廣與定期更新遊戲
- Hulu大資料架構與應用經驗大資料架構
- Hadoop(一)Hadoop核心架構與安裝Hadoop架構
- MVP應用架構模式MVP應用架構模式
- 常用核心架構架構
- 微核心架構架構
- SaaS架構:應用服務、應用結構設計架構
- Android架構系列-MVP架構的實際應用Android架構MVP
- Adjust與Facebook聯合釋出《全球移動應用增長報告》:遊戲和娛樂類應用登上增長榜首遊戲
- 瞭解安卓架構(linux核心層、系統執行庫層、應用框架層、應用層)安卓架構Linux框架
- 如何應用雲架構DevOps?架構dev
- 隱式呼叫架構風格的概念與應用(轉)架構
- 架構師必備:HBase行鍵設計與應用架構
- 移動應用的測試策略與測試架構架構
- 基於TRIZ架構下的網路安全與應用架構
- Zeppelin:用於區塊鏈應用的開源安全智慧合約架構區塊鏈架構
- 如何利用資料架構帶動企業增長?架構
- Django與微服務架構:構建可擴充套件的Web應用Django微服務架構套件Web
- 一文解讀智慧遠端監考方案的技術架構與應用實景架構
- Google官方應用程式架構指南Go架構
- [譯] 在 Kubernetes 之上架構應用架構
- 應用架構圖的設計應用架構
- Vue底層架構及其應用Vue架構
- 應用架構指南全新發布應用架構
- Web3.0應用程式架構Web架構
- TOGAF企業架構與軟體架構的對應圖架構
- 攻擊JavaWeb應用————6、程式架構與程式碼審計JavaWeb架構
- 攻擊JavaWeb應用[6]-程式架構與程式碼審計JavaWeb架構
- Flutter 在流式場景下的架構設計與應用Flutter架構
- 一文搞懂SaaS應用架構:應用服務、應用結構、應用互動設計應用架構
- 傳統應用系統架構向微服務應用架構升級的實戰案例微服務應用架構
- 微服務核心架構梳理微服務架構
- Linux 核心 101:NUMA架構Linux架構
- kafka核心架構詳解Kafka架構