柚子快報(bào)激活碼778899分享:推薦系統(tǒng)架構(gòu)
柚子快報(bào)激活碼778899分享:推薦系統(tǒng)架構(gòu)
推薦系統(tǒng)架構(gòu)
推薦和搜索系統(tǒng)核心的的任務(wù)是從海量物品中找到用戶感興趣的內(nèi)容。在這個(gè)背景下,推薦系統(tǒng)包含的模塊非常多,每個(gè)模塊將會(huì)有很多專業(yè)研究的工程和研究工程師,作為剛?cè)腴T的應(yīng)屆生或者實(shí)習(xí)生很難對(duì)每個(gè)模塊都有很深的理解,實(shí)際上也大可不必,我們完全可以從學(xué)習(xí)好一個(gè)模塊技術(shù)后,以點(diǎn)帶面學(xué)習(xí)整個(gè)系統(tǒng),雖然正式工作中我們放入門每個(gè)人將只會(huì)負(fù)責(zé)的也是整個(gè)系統(tǒng)的一部分。但是掌握推薦系統(tǒng)最重要的還是梳理清楚整個(gè)推薦系統(tǒng)的架構(gòu),知道每一個(gè)部分需要完成哪些任務(wù),是如何做的,主要的技術(shù)棧是什么,有哪些局限和可以研究的問題,能夠?qū)ξ覀儗W(xué)習(xí)推薦系統(tǒng)有一個(gè)提綱挈領(lǐng)的作用。
所以這篇文章將會(huì)從系統(tǒng)架構(gòu)和算法架構(gòu)兩個(gè)角度出發(fā)解析推薦系統(tǒng)通用架構(gòu)。系統(tǒng)架構(gòu)設(shè)計(jì)思想是大數(shù)據(jù)背景下如何有效利用海量和實(shí)時(shí)數(shù)據(jù),將推薦系統(tǒng)按照對(duì)數(shù)據(jù)利用情況和系統(tǒng)響應(yīng)要求出發(fā),將整個(gè)架構(gòu)分為離線層、近線層、在線層三個(gè)模塊。然后分析這三個(gè)模塊分別承擔(dān)推薦系統(tǒng)什么任務(wù),有什么制約要求。這種角度不和召回、排序這種通俗我們理解算法架構(gòu),因?yàn)楦嗟氖强紤]推薦算法在工程技術(shù)實(shí)現(xiàn)上的問題,系統(tǒng)架構(gòu)是如何權(quán)衡利弊,如何利用各種技術(shù)工具幫助我們達(dá)到想要的目的的,方便我們理解為什么推薦系統(tǒng)要這樣設(shè)計(jì)。
而算法架構(gòu)是從我們比較熟悉的召回、粗排、排序、重排等算法環(huán)節(jié)角度出發(fā)的,重要的是要去理解每個(gè)環(huán)節(jié)需要完成的任務(wù),每個(gè)環(huán)節(jié)的評(píng)價(jià)體系,以及為什么要那么設(shè)計(jì)。還有一個(gè)重要問題是每個(gè)環(huán)節(jié)涉及到的技術(shù)棧和主流算法,這部分非常重要而且篇幅較大,所以我們放在下一個(gè)章節(jié)講述。
架構(gòu)設(shè)計(jì)是一個(gè)非常大的話題,設(shè)計(jì)的核心在于平衡和妥協(xié)。在推薦系統(tǒng)不同時(shí)期、不同的環(huán)境、不同的數(shù)據(jù),架構(gòu)都會(huì)面臨不一樣的問題。網(wǎng)飛官方博客有一段總結(jié):
We want the ability to use sophisticated machine learning algorithms that can grow to arbitrary complexity and can deal with huge amounts of data. We also want an architecture that allows for flexible and agile innovation where new approaches can be developed and plugged-in easily. Plus, we want our recommendation results to be fresh and respond quickly to new data and user actions. Finding the sweet spot between these desires is not trivial: it requires a thoughtful analysis of requirements, careful selection of technologies, and a strategic decomposition of recommendation algorithms to achieve the best outcomes for our members. “我們需要具備使用復(fù)雜機(jī)器學(xué)習(xí)算法的能力,這些算法要可以適應(yīng)高度復(fù)雜性,可以處理大量數(shù)據(jù)。我們還要能夠提供靈活、敏捷創(chuàng)新的架構(gòu),新的方法可以很容易在其基礎(chǔ)上開發(fā)和插入。而且,我們需要我們的推薦結(jié)果足夠新,能快速響應(yīng)新的數(shù)據(jù)和用戶行為。找到這些要求之間恰當(dāng)?shù)钠胶獠⒉蝗菀祝枰钏际鞈]的需求分析,細(xì)心的技術(shù)選擇,戰(zhàn)略性的推薦算法分解,最終才能為客戶達(dá)成最佳的結(jié)果?!?/p>
所以在思考推薦系統(tǒng)架構(gòu)考慮的第一個(gè)問題是確定邊界:知道推薦系統(tǒng)要負(fù)責(zé)哪部分問題,這就是邊界內(nèi)的部分。在這個(gè)基礎(chǔ)上,架構(gòu)要分為哪幾個(gè)部分,每一部分需要完成的子功能是什么,每一部分依賴外界的什么。了解推薦系統(tǒng)架構(gòu)也和上文講到的思路一樣,我們需要知道的是推薦系統(tǒng)要負(fù)責(zé)的是怎么問題,每一個(gè)子模塊分別承擔(dān)了哪些功能,它們的主流技術(shù)棧是什么。從這個(gè)角度來閱讀本文,將會(huì)有助于讀者抓住重點(diǎn)。
系統(tǒng)架構(gòu)
推薦系統(tǒng)架構(gòu),首先從數(shù)據(jù)驅(qū)動(dòng)角度,對(duì)于數(shù)據(jù),最簡單的方法是存下來,留作后續(xù)離線處理,離線層就是我們用來管理離線作業(yè)的部分架構(gòu)。在線層能更快地響應(yīng)最近的事件和用戶交互,但必須實(shí)時(shí)完成。這會(huì)限制使用算法的復(fù)雜性和處理的數(shù)據(jù)量。離線計(jì)算對(duì)于數(shù)據(jù)數(shù)量和算法復(fù)雜度限制更少,因?yàn)樗耘糠绞酵瓿桑瑳]有很強(qiáng)的時(shí)間要求。不過,由于沒有及時(shí)加入最新的數(shù)據(jù),所以很容易過時(shí)。
個(gè)性化架構(gòu)的關(guān)鍵問題,就是如何以無縫方式結(jié)合、管理在線和離線計(jì)算過程。近線層介于兩種方法之間,可以執(zhí)行類似于在線計(jì)算的方法,但又不必以實(shí)時(shí)方式完成。這種設(shè)計(jì)思想最經(jīng)典的就是Netflix在2013年提出的架構(gòu),整個(gè)架構(gòu)分為
離線層:不用實(shí)時(shí)數(shù)據(jù),不提供實(shí)時(shí)響應(yīng);近線層:使用實(shí)時(shí)數(shù)據(jù),不保證實(shí)時(shí)響應(yīng);在線層:使用實(shí)時(shí)數(shù)據(jù),保證實(shí)時(shí)在線服務(wù);
補(bǔ)充(推薦系統(tǒng)通用技術(shù)架構(gòu)_嗶哩嗶哩_bilibili):
設(shè)計(jì)思想
網(wǎng)飛的這個(gè)架構(gòu)提出的非常早,其中的技術(shù)也許不是現(xiàn)在常用的技術(shù)了,但是架構(gòu)模型仍然被很多公司采用。
這個(gè)架構(gòu)為什么要這么設(shè)計(jì),本質(zhì)上是因?yàn)橥扑]系統(tǒng)是由大量數(shù)據(jù)驅(qū)動(dòng)的,大數(shù)據(jù)框架最經(jīng)典的就是lambda架構(gòu)和kappa架構(gòu)。而推薦系統(tǒng)在不同環(huán)節(jié)所使用的數(shù)據(jù)、處理數(shù)據(jù)的量級(jí)、需要的讀取速度都是不同的,目前的技術(shù)還是很難實(shí)現(xiàn)一套端到端的及時(shí)響應(yīng)系統(tǒng),所以這種架構(gòu)的設(shè)計(jì)本質(zhì)上還是一種權(quán)衡后的產(chǎn)物,所以有了下圖這種模型:
上面是網(wǎng)飛的原圖,我搬運(yùn)了更加容易理解的線條梳理后的結(jié)構(gòu):
整個(gè)數(shù)據(jù)部分其實(shí)是一整個(gè)鏈路,主要是三塊,分別是
**客戶端及服務(wù)器實(shí)時(shí)數(shù)據(jù)處理、流處理平臺(tái)準(zhǔn)實(shí)時(shí)數(shù)據(jù)處理和大數(shù)據(jù)平臺(tái)離線數(shù)據(jù)處理這三個(gè)部分。**
看到這里,一個(gè)很直觀的問題就是,為什么數(shù)據(jù)處理需要這么多步驟?這些步驟都是干嘛的,存在的意義是什么?
我們一個(gè)一個(gè)來說,首先是客戶端和服務(wù)端的實(shí)時(shí)數(shù)據(jù)處理。這個(gè)很好理解,這個(gè)步驟的工作就是記錄。將用戶在平臺(tái)上真實(shí)的行為記錄下來,比如用戶看到了哪些內(nèi)容,和哪些內(nèi)容發(fā)生了交互,和哪些沒有發(fā)生了交互。如果再精細(xì)一點(diǎn),還會(huì)記錄用戶停留的時(shí)間,用戶使用的設(shè)備等等。除此之外還會(huì)記錄行為發(fā)生的時(shí)間,行為發(fā)生的session等其他上下文信息。
這一部分主要是后端和客戶端完成,行業(yè)術(shù)語叫做埋點(diǎn)。所謂的埋點(diǎn)其實(shí)就是記錄點(diǎn),因?yàn)閿?shù)據(jù)這種東西需要工程師去主動(dòng)記錄,不記錄就沒有數(shù)據(jù),記錄了才有數(shù)據(jù)。既然我們要做推薦系統(tǒng),要分析用戶行為,還要訓(xùn)練模型,顯然需要數(shù)據(jù)。需要數(shù)據(jù),就需要記錄。
第二個(gè)步驟是流處理平臺(tái)準(zhǔn)實(shí)時(shí)數(shù)據(jù)處理,這一步是干嘛的呢,其實(shí)也是記錄數(shù)據(jù),不過是記錄一些準(zhǔn)實(shí)時(shí)的數(shù)據(jù)。很多同學(xué)又會(huì)迷糊了,實(shí)時(shí)我理解,就是當(dāng)下立即的意思,準(zhǔn)實(shí)時(shí)是什么意思呢?準(zhǔn)實(shí)時(shí)的意思也是實(shí)時(shí),只不過沒有那么即時(shí),比如可能存在幾分鐘的誤差。這樣存在誤差的即時(shí)數(shù)據(jù),行業(yè)術(shù)語叫做準(zhǔn)實(shí)時(shí)。那什么樣的準(zhǔn)實(shí)時(shí)數(shù)據(jù)需要記錄呢?在推薦領(lǐng)域基本上只有一個(gè)類別,就是用戶行為數(shù)據(jù)。也就是用戶在觀看這個(gè)內(nèi)容之前還看過哪些內(nèi)容,和哪些內(nèi)容發(fā)生過交互。理想情況這部分?jǐn)?shù)據(jù)也需要做成實(shí)時(shí),但由于這部分?jǐn)?shù)據(jù)量比較大,并且邏輯也相對(duì)復(fù)雜,所以很難做到非常實(shí)時(shí),一般都是通過消息隊(duì)列加在線緩存的方式做成準(zhǔn)實(shí)時(shí)。
最后我們看第三個(gè)步驟,叫做離線數(shù)據(jù)處理,離線也就是線下處理,基本上就沒有時(shí)限的要求了。
一般來說,離線處理才是數(shù)據(jù)處理的大頭。所有“臟活累活”復(fù)雜的操作都是在離線完成的,比如說一些join操作。后端只是記錄了用戶交互的商品id,我們需要商品的詳細(xì)信息怎么辦?需要去和商品表關(guān)聯(lián)查表。顯然數(shù)據(jù)關(guān)聯(lián)是一個(gè)非常耗時(shí)的操作,所以只能放到離線來做。
接下來詳細(xì)介紹一下這三個(gè)模塊。
離線層
離線層是計(jì)算量最大的一個(gè)部分,它的特點(diǎn)是不依賴實(shí)時(shí)數(shù)據(jù),也不需要實(shí)時(shí)提供服務(wù)。需要實(shí)現(xiàn)的主要功能模塊是:
數(shù)據(jù)處理、數(shù)據(jù)存儲(chǔ);特征工程、離線特征計(jì)算;離線模型的訓(xùn)練;
這里我們可以看出離線層的任務(wù)是最接近學(xué)校中我們處理數(shù)據(jù)、訓(xùn)練模型這種任務(wù)的,不同可能就是需要面臨更大規(guī)模的數(shù)據(jù)。離線任務(wù)一般會(huì)按照天或者更久運(yùn)行,比如每天晚上定期更新這一天的數(shù)據(jù),然后重新訓(xùn)練模型,第二天上線新模型。
離線層優(yōu)勢和不足
離線層面臨的數(shù)據(jù)量級(jí)是最大的,面臨主要的問題是海量數(shù)據(jù)存儲(chǔ)、大規(guī)模特征工程、多機(jī)分布式機(jī)器學(xué)習(xí)模型訓(xùn)練。目前主流的做法是HDFS,收集到我們所有的業(yè)務(wù)數(shù)據(jù),通過HIVE等工具,從全量數(shù)據(jù)中抽取出我們需要的數(shù)據(jù),進(jìn)行相應(yīng)的加工,離線階段主流使用的分布式框架一般是Spark。所以離線層有如下的優(yōu)勢:
可以處理大量的數(shù)據(jù),進(jìn)行大規(guī)模特征工程;可以進(jìn)行批量處理和計(jì)算;不用有響應(yīng)時(shí)間要求;
但是同樣的,如果我們只使用用戶離線數(shù)據(jù),最大的不足就是無法反應(yīng)用戶的實(shí)時(shí)興趣變化,這就促使了近線層的產(chǎn)生。
近線層
近線層的主要特點(diǎn)是準(zhǔn)實(shí)時(shí),它可以獲得實(shí)時(shí)數(shù)據(jù),然后快速計(jì)算提供服務(wù),但是并不要求它和在線層一樣達(dá)到幾十毫秒這種延時(shí)要求。近線層的產(chǎn)生是同時(shí)想要彌補(bǔ)離線層和在線層的不足,折中的產(chǎn)物。
它適合處理一些對(duì)延時(shí)比較敏感的任務(wù),比如:
特征的事實(shí)更新計(jì)算:例如統(tǒng)計(jì)用戶對(duì)不同type的ctr,推薦系統(tǒng)一個(gè)老生常談的問題就是特征分布不一致怎么辦,如果使用離線算好的特征就容易出現(xiàn)這個(gè)問題。近線層能夠獲取實(shí)時(shí)數(shù)據(jù),按照用戶的實(shí)時(shí)興趣計(jì)算就能很好避免這個(gè)問題。實(shí)時(shí)訓(xùn)練數(shù)據(jù)的獲?。罕热缭谑褂肈IN(阿里巴巴使用)、DSIN(阿里巴巴使用)這行網(wǎng)絡(luò)會(huì)依賴于用戶的實(shí)時(shí)興趣變化,用戶幾分鐘前的點(diǎn)擊就可以通過近線層獲取特征輸入模型。模型實(shí)時(shí)訓(xùn)練:可以通過在線學(xué)習(xí)的方法更新模型,實(shí)時(shí)推送到線上;
近線層的發(fā)展得益于最近幾年大數(shù)據(jù)技術(shù)的發(fā)展,很多流處理框架的提出大大促進(jìn)了近線層的進(jìn)步。如今Flink、Storm等工具一統(tǒng)天下。
在線層
在線層,就是直接面向用戶的的那一層了。最大的特點(diǎn)是對(duì)響應(yīng)延時(shí)有要求,因?yàn)樗侵苯用鎸?duì)用戶群體的,你可以想象你打開抖音淘寶等界面,幾乎都是秒刷出來給你的推薦結(jié)果的,不會(huì)說還需要讓你等待幾秒鐘時(shí)間。所有的用戶請(qǐng)求都會(huì)發(fā)送到在線層,在線層需要快速返回結(jié)果,它主要承擔(dān)的工作有:
模型在線服務(wù);包括了快速召回和排序;在線特征快速處理拼接:根據(jù)傳入的用戶ID和場景,快速讀取特征和處理;AB實(shí)驗(yàn)(一種通過對(duì)比兩個(gè)版本的性能、用戶體驗(yàn)等指標(biāo)來優(yōu)化產(chǎn)品或服務(wù)的方法)或者分流:根據(jù)不同用戶采用不一樣的模型,比如冷啟動(dòng)用戶和正常服務(wù)模型;運(yùn)籌優(yōu)化和業(yè)務(wù)干預(yù):比如要對(duì)特殊商家流量扶持、對(duì)某些內(nèi)容限流;
典型的在線服務(wù)是用過RESTful/RPC等提供服務(wù),一般是公司后臺(tái)服務(wù)部門調(diào)用我們的這個(gè)服務(wù),返回給前端。具體部署應(yīng)用比較多的方式就是使用Docker在K8S部署。而在線服務(wù)的數(shù)據(jù)源就是我們?cè)陔x線層計(jì)算好的每個(gè)用戶和商品特征,我們事先存放在數(shù)據(jù)庫中,在線層只需要實(shí)時(shí)拼接,不進(jìn)行復(fù)雜的特征運(yùn)算,然后輸入近線層或者離線層已經(jīng)訓(xùn)練好的模型,根據(jù)推理結(jié)果進(jìn)行排序,最后返回給后臺(tái)服務(wù)器,后臺(tái)服務(wù)器根據(jù)我們對(duì)每一個(gè)用戶的打分,再返回給用戶。
在線層最大的問題就是對(duì)實(shí)時(shí)性要求特別高,一般來說是幾十毫秒,這就限制了我們能做的工作,很多任務(wù)往往無法及時(shí)完成,需要近線層協(xié)助我們做。
算法架構(gòu)
我們?cè)谌腴T學(xué)習(xí)推薦系統(tǒng)的時(shí)候,更加關(guān)注的是哪個(gè)模型AUC更高(ROC曲線下的面積)、topK(選擇置信度分?jǐn)?shù)最高的K個(gè)結(jié)果進(jìn)行評(píng)估)效果好,哪個(gè)模型更加牛逼的問題,從基本的協(xié)同過濾到點(diǎn)擊率預(yù)估算法,從深度學(xué)習(xí)到強(qiáng)化學(xué)習(xí),學(xué)術(shù)界都始終走在最前列。一個(gè)推薦算法從出現(xiàn)到在業(yè)界得到廣泛應(yīng)用是一個(gè)長期的過程,因?yàn)樵趯?shí)際的生產(chǎn)系統(tǒng)中,首先需要保證的是穩(wěn)定、實(shí)時(shí)地向用戶提供推薦服務(wù),在這個(gè)前提下才能追求推薦系統(tǒng)的效果。
算法架構(gòu)的設(shè)計(jì)思想就是在實(shí)際的工業(yè)場景中,不管是用戶維度、物品維度還是用戶和物品的交互維度,數(shù)據(jù)都是極其豐富的,學(xué)術(shù)界對(duì)算法的使用方法不能照搬到工業(yè)界。當(dāng)一個(gè)用戶訪問推薦模塊時(shí),系統(tǒng)不可能針對(duì)該用戶對(duì)所有的物品進(jìn)行排序,那么推薦系統(tǒng)是怎么解決的呢?對(duì)應(yīng)的商品眾多,如何決定將哪些商品展示給用戶?對(duì)于排序好的商品,如何合理地展示給用戶?
所以一個(gè)通用的算法架構(gòu),設(shè)計(jì)思想就是對(duì)數(shù)據(jù)層層建模,層層篩選,幫助用戶從海量數(shù)據(jù)中找出其真正感興趣的部分。
召回
召回層的主要目標(biāo)時(shí)從推薦池中選取幾千上萬的item,送給后續(xù)的排序模塊。由于召回面對(duì)的候選集十分大,且一般需要在線輸出,故召回模塊必須輕量快速低延遲。由于后續(xù)還有排序模塊作為保障,召回不需要十分準(zhǔn)確,但不可遺漏(特別是搜索系統(tǒng)中的召回模塊)。
如果沒有召回層,每個(gè)User都能和每一個(gè)Item去在線排序階段預(yù)測目標(biāo)概率,理論上來說是效果最好,但是是不現(xiàn)實(shí)的,線上不延遲允許,所以召回和粗排階段就要做一些候選集篩選的工作,保證在有限的能夠給到排序?qū)尤プ鼍诺暮蜻x集的時(shí)間里,效果最大化。另一個(gè)方面就是通過這種模型級(jí)聯(lián)的方式,可以減少用排序階段擬合多目標(biāo)的壓力,比如召回階段我們現(xiàn)在主要是在保證Item質(zhì)量的基礎(chǔ)上注重覆蓋率多樣性,粗排階段主要用簡單的模型來解決不同路的召回和當(dāng)前用戶的相關(guān)性問題,最后截?cái)嗟?k個(gè)以內(nèi)的候選集,這個(gè)候選集符合一定的個(gè)性化相關(guān)性、視頻質(zhì)量和多樣性的保證,然后做ranking去做復(fù)雜模型的predict。
目前基本上采用多路召回解決范式,分為非個(gè)性化召回和個(gè)性化召回。個(gè)性化召回又有content-based、behavior-based、feature-based等多種方式。
召回主要考慮的內(nèi)容有:
考慮用戶層面:用戶興趣的多元化,用戶需求與場景的多元化:例如:新聞需求,重大要聞,相關(guān)內(nèi)容沉浸閱讀等等考慮系統(tǒng)層面:增強(qiáng)系統(tǒng)的魯棒性;部分召回失效,其余召回隊(duì)列兜底不會(huì)導(dǎo)致整個(gè)召回層失效;排序?qū)邮?,召回?duì)列兜底不會(huì)導(dǎo)致整個(gè)推薦系統(tǒng)失效系統(tǒng)多樣性內(nèi)容分發(fā):圖文、視頻、小視頻;精準(zhǔn)、試探、時(shí)效一定比例;召回目標(biāo)的多元化,例如:相關(guān)性,沉浸時(shí)長,時(shí)效性,特色內(nèi)容等等可解釋性推薦一部分召回是有明確推薦理由的:很好的解決產(chǎn)品性數(shù)據(jù)的引入;
粗排
粗排的原因是有時(shí)候召回的結(jié)果還是太多,精排層速度還是跟不上,所以加入粗排。粗排可以理解為精排前的一輪過濾機(jī)制,減輕精排模塊的壓力。粗排介于召回和精排之間,要同時(shí)兼顧精準(zhǔn)性和低延遲。目前粗排一般也都模型化了,其訓(xùn)練樣本類似于精排,選取曝光點(diǎn)擊為正樣本,曝光未點(diǎn)擊為負(fù)樣本。但由于粗排一般面向上萬的候選集,而精排只有幾百上千,其解空間大很多。
粗排階段的架構(gòu)設(shè)計(jì)主要是考慮三個(gè)方面,一個(gè)是根據(jù)精排模型中的重要特征,來做候選集的截?cái)?,另一部分是有一些召回設(shè)計(jì),比如熱度或者語義相關(guān)的這些結(jié)果,僅考慮了item側(cè)的特征,可以用粗排模型來排序跟當(dāng)前User之間的相關(guān)性,據(jù)此來做截?cái)啵@樣是比單獨(dú)的按照item側(cè)的倒排分?jǐn)?shù)截?cái)嗟玫礁觽€(gè)性化的結(jié)果,最后是算法的選型要在在線服務(wù)的性能上有保證,因?yàn)檫@個(gè)階段在pipeline中完成從召回到精排的截?cái)喙ぷ?,在延遲允許的范圍內(nèi)能處理更多的召回候選集理論上與精排效果正相關(guān)。
精排
精排層,也是我們學(xué)習(xí)推薦入門最常常接觸的層,我們所熟悉的算法很大一部分都來自精排層。這一層的任務(wù)是獲取粗排模塊的結(jié)果,對(duì)候選集進(jìn)行打分和排序。精排需要在最大時(shí)延允許的情況下,保證打分的精準(zhǔn)性,是整個(gè)系統(tǒng)中至關(guān)重要的一個(gè)模塊,也是最復(fù)雜,研究最多的一個(gè)模塊。
精排是推薦系統(tǒng)各層級(jí)中最純粹的一層,他的目標(biāo)比較單一且集中,一門心思的實(shí)現(xiàn)目標(biāo)的調(diào)優(yōu)即可。最開始的時(shí)候精排模型的常見目標(biāo)是ctr,后續(xù)逐漸發(fā)展了cvr等多類目標(biāo)。精排和粗排層的基本目標(biāo)是一致的,都是對(duì)商品集合進(jìn)行排序,但是和粗排不同的是,精排只需要對(duì)少量的商品(即粗排輸出的商品集合的topN)進(jìn)行排序即可。因此,精排中可以使用比粗排更多的特征,更復(fù)雜的模型和更精細(xì)的策略(用戶的特征和行為在該層的大量使用和參與也是基于這個(gè)原因)。
精排層模型是推薦系統(tǒng)中涵蓋的研究方向最多,有非常多的子領(lǐng)域值得研究探索,這也是推薦系統(tǒng)中技術(shù)含量最高的部分,畢竟它是直接面對(duì)用戶,產(chǎn)生的結(jié)果對(duì)用戶影響最大的一層。目前精排層深度學(xué)習(xí)已經(jīng)一統(tǒng)天下了,精排階段采用的方案相對(duì)通用,首先一天的樣本量是幾十億的級(jí)別,我們要解決的是樣本規(guī)模的問題,盡量多的喂給模型去記憶,另一個(gè)方面時(shí)效性上,用戶的反饋產(chǎn)生的時(shí)候,怎么盡快的把新的反饋給到模型里去,學(xué)到最新的知識(shí)。
重排
常見的有三種優(yōu)化目標(biāo):Point Wise、Pair Wise 和 List Wise。重排序階段對(duì)精排生成的Top-N個(gè)物品的序列進(jìn)行重新排序,生成一個(gè)Top-K個(gè)物品的序列,作為排序系統(tǒng)最后的結(jié)果,直接展現(xiàn)給用戶。重排序的原因是因?yàn)槎鄠€(gè)物品之間往往是相互影響的,而精排序是根據(jù)PointWise得分,容易造成推薦結(jié)果同質(zhì)化嚴(yán)重,有很多冗余信息。而重排序面對(duì)的挑戰(zhàn)就是海量狀態(tài)空間如何求解的問題,一般在精排層我們使用AUC作為指標(biāo),但是在重排序更多關(guān)注NDCG等指標(biāo)。
重排序在業(yè)務(wù)中,獲取精排的排序結(jié)果,還會(huì)根據(jù)一些策略、運(yùn)營規(guī)則參與排序,比如強(qiáng)制去重、間隔排序、流量扶持等、運(yùn)營策略、多樣性、context上下文等,重新進(jìn)行一個(gè)微調(diào)。重排序更多的是List Wise作為優(yōu)化目標(biāo)的,它關(guān)注的是列表中商品順序的問題來優(yōu)化模型,但是一般List Wise因?yàn)闋顟B(tài)空間大,存在訓(xùn)練速度慢的問題。
由于精排模型一般比較復(fù)雜,基于系統(tǒng)時(shí)延考慮,一般采用point-wise方式,并行對(duì)每個(gè)item進(jìn)行打分。這就使得打分時(shí)缺少了上下文感知能力。用戶最終是否會(huì)點(diǎn)擊購買一個(gè)商品,除了和它自身有關(guān)外,和它周圍其他的item也息息相關(guān)。重排一般比較輕量,可以加入上下文感知能力,提升推薦整體算法效率。比如三八節(jié)對(duì)美妝類目商品提權(quán),類目打散、同圖打散、同賣家打散等保證用戶體驗(yàn)措施。重排中規(guī)則比較多,但目前也有不少基于模型來提升重排效果的方案。
混排
多個(gè)業(yè)務(wù)線都想在Feeds流中獲取曝光,則需要對(duì)它們的結(jié)果進(jìn)行混排。比如推薦流中插入廣告、視頻流中插入圖文和banner等??梢曰谝?guī)則策略(如廣告定坑)和強(qiáng)化學(xué)習(xí)來實(shí)現(xiàn)。
總結(jié)
整篇文章從系統(tǒng)架構(gòu)梳理了Netfliex的經(jīng)典推薦系統(tǒng)架構(gòu),整個(gè)架構(gòu)更多是偏向?qū)崟r(shí)性能和效果之間tradeoff的結(jié)果。如果從另外的角度看推薦系統(tǒng)架構(gòu),比如從數(shù)據(jù)流向,或者說從推薦系統(tǒng)各個(gè)時(shí)序依賴來看,就是我們最熟悉的召回、粗排、精排、重排、混排等模塊了。這種角度來看是把推薦系統(tǒng)從前往后串起來,其中每一個(gè)模塊既有在離線層工作的,也有在在線層工作的。而從數(shù)據(jù)驅(qū)動(dòng)角度看,更能夠看到推薦系統(tǒng)的完整技術(shù)棧,推薦系統(tǒng)當(dāng)前面臨的局限和發(fā)展方向。
召回、排序這些里面單拿出任何一個(gè)模塊都非常復(fù)雜。這也是為什么大家都說大廠擰螺絲的原因,因?yàn)楹芸赡苣硞€(gè)人只會(huì)負(fù)責(zé)其中很小的一個(gè)模塊。許多人說起自己的模塊來如數(shù)家珍,但對(duì)于全局缺乏認(rèn)識(shí),帶來的結(jié)果是當(dāng)你某天跳槽了或者是工作內(nèi)容變化了,之前從工作當(dāng)中的學(xué)習(xí)積累很難沉淀下來,這對(duì)于程序員的成長來說是很不利的。
所以希望這篇文章能夠幫助大家在負(fù)責(zé)某一個(gè)模塊,優(yōu)化某一個(gè)功能的時(shí)候,除了能夠有算法和數(shù)據(jù),還能能夠考慮對(duì)整個(gè)架構(gòu)帶來的影響,如何提升整體的一個(gè)性能,慢慢開闊自己的眼界,構(gòu)建出一個(gè)更好的推薦系統(tǒng)。
參考資料
《從零開始構(gòu)建企業(yè)級(jí)推薦系統(tǒng)》Netflix回顧經(jīng)典,Netflix的推薦系統(tǒng)架構(gòu)大數(shù)據(jù)處理中的Lambda架構(gòu)和Kappa架構(gòu)張俊林:推薦系統(tǒng)技術(shù)演進(jìn)趨勢推薦算法架構(gòu)1:召回/等微信"看一看"多模型內(nèi)容策略與召回阿里粗排技術(shù)體系推薦系統(tǒng)架構(gòu)與算法流程詳解業(yè)內(nèi)推薦系統(tǒng)架構(gòu)介紹推薦系統(tǒng)筆記,一張圖看懂系統(tǒng)架構(gòu)
柚子快報(bào)激活碼778899分享:推薦系統(tǒng)架構(gòu)
推薦文章
本文內(nèi)容根據(jù)網(wǎng)絡(luò)資料整理,出于傳遞更多信息之目的,不代表金鑰匙跨境贊同其觀點(diǎn)和立場。
轉(zhuǎn)載請(qǐng)注明,如有侵權(quán),聯(lián)系刪除。