柚子快報激活碼778899分享：推薦系統(tǒng)架構(gòu)

http://yzkb.51969.com/

推薦系統(tǒng)架構(gòu)

推薦和搜索系統(tǒng)核心的的任務(wù)是從海量物品中找到用戶感興趣的內(nèi)容。在這個背景下，推薦系統(tǒng)包含的模塊非常多，每個模塊將會有很多專業(yè)研究的工程和研究工程師，作為剛?cè)腴T的應(yīng)屆生或者實習(xí)生很難對每個模塊都有很深的理解，實際上也大可不必，我們完全可以從學(xué)習(xí)好一個模塊技術(shù)后，以點帶面學(xué)習(xí)整個系統(tǒng)，雖然正式工作中我們放入門每個人將只會負(fù)責(zé)的也是整個系統(tǒng)的一部分。但是掌握推薦系統(tǒng)最重要的還是梳理清楚整個推薦系統(tǒng)的架構(gòu)，知道每一個部分需要完成哪些任務(wù)，是如何做的，主要的技術(shù)棧是什么，有哪些局限和可以研究的問題，能夠?qū)ξ覀儗W(xué)習(xí)推薦系統(tǒng)有一個提綱挈領(lǐng)的作用。

所以這篇文章將會從系統(tǒng)架構(gòu)和算法架構(gòu)兩個角度出發(fā)解析推薦系統(tǒng)通用架構(gòu)。系統(tǒng)架構(gòu)設(shè)計思想是大數(shù)據(jù)背景下如何有效利用海量和實時數(shù)據(jù)，將推薦系統(tǒng)按照對數(shù)據(jù)利用情況和系統(tǒng)響應(yīng)要求出發(fā)，將整個架構(gòu)分為離線層、近線層、在線層三個模塊。然后分析這三個模塊分別承擔(dān)推薦系統(tǒng)什么任務(wù)，有什么制約要求。這種角度不和召回、排序這種通俗我們理解算法架構(gòu)，因為更多的是考慮推薦算法在工程技術(shù)實現(xiàn)上的問題，系統(tǒng)架構(gòu)是如何權(quán)衡利弊，如何利用各種技術(shù)工具幫助我們達(dá)到想要的目的的，方便我們理解為什么推薦系統(tǒng)要這樣設(shè)計。

而算法架構(gòu)是從我們比較熟悉的召回、粗排、排序、重排等算法環(huán)節(jié)角度出發(fā)的，重要的是要去理解每個環(huán)節(jié)需要完成的任務(wù)，每個環(huán)節(jié)的評價體系，以及為什么要那么設(shè)計。還有一個重要問題是每個環(huán)節(jié)涉及到的技術(shù)棧和主流算法，這部分非常重要而且篇幅較大，所以我們放在下一個章節(jié)講述。

架構(gòu)設(shè)計是一個非常大的話題，設(shè)計的核心在于平衡和妥協(xié)。在推薦系統(tǒng)不同時期、不同的環(huán)境、不同的數(shù)據(jù)，架構(gòu)都會面臨不一樣的問題。網(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)考慮的第一個問題是確定邊界：知道推薦系統(tǒng)要負(fù)責(zé)哪部分問題，這就是邊界內(nèi)的部分。在這個基礎(chǔ)上，架構(gòu)要分為哪幾個部分，每一部分需要完成的子功能是什么，每一部分依賴外界的什么。了解推薦系統(tǒng)架構(gòu)也和上文講到的思路一樣，我們需要知道的是推薦系統(tǒng)要負(fù)責(zé)的是怎么問題，每一個子模塊分別承擔(dān)了哪些功能，它們的主流技術(shù)棧是什么。從這個角度來閱讀本文，將會有助于讀者抓住重點。

系統(tǒng)架構(gòu)

推薦系統(tǒng)架構(gòu)，首先從數(shù)據(jù)驅(qū)動角度，對于數(shù)據(jù)，最簡單的方法是存下來，留作后續(xù)離線處理，離線層就是我們用來管理離線作業(yè)的部分架構(gòu)。在線層能更快地響應(yīng)最近的事件和用戶交互，但必須實時完成。這會限制使用算法的復(fù)雜性和處理的數(shù)據(jù)量。離線計算對于數(shù)據(jù)數(shù)量和算法復(fù)雜度限制更少，因為它以批量方式完成，沒有很強(qiáng)的時間要求。不過，由于沒有及時加入最新的數(shù)據(jù)，所以很容易過時。

個性化架構(gòu)的關(guān)鍵問題，就是如何以無縫方式結(jié)合、管理在線和離線計算過程。近線層介于兩種方法之間，可以執(zhí)行類似于在線計算的方法，但又不必以實時方式完成。這種設(shè)計思想最經(jīng)典的就是Netflix在2013年提出的架構(gòu)，整個架構(gòu)分為

離線層：不用實時數(shù)據(jù)，不提供實時響應(yīng)；近線層：使用實時數(shù)據(jù)，不保證實時響應(yīng)；在線層：使用實時數(shù)據(jù)，保證實時在線服務(wù)；

補(bǔ)充(推薦系統(tǒng)通用技術(shù)架構(gòu)_嗶哩嗶哩_bilibili)：

設(shè)計思想

網(wǎng)飛的這個架構(gòu)提出的非常早，其中的技術(shù)也許不是現(xiàn)在常用的技術(shù)了，但是架構(gòu)模型仍然被很多公司采用。

這個架構(gòu)為什么要這么設(shè)計，本質(zhì)上是因為推薦系統(tǒng)是由大量數(shù)據(jù)驅(qū)動的，大數(shù)據(jù)框架最經(jīng)典的就是lambda架構(gòu)和kappa架構(gòu)。而推薦系統(tǒng)在不同環(huán)節(jié)所使用的數(shù)據(jù)、處理數(shù)據(jù)的量級、需要的讀取速度都是不同的，目前的技術(shù)還是很難實現(xiàn)一套端到端的及時響應(yīng)系統(tǒng)，所以這種架構(gòu)的設(shè)計本質(zhì)上還是一種權(quán)衡后的產(chǎn)物，所以有了下圖這種模型：

上面是網(wǎng)飛的原圖，我搬運(yùn)了更加容易理解的線條梳理后的結(jié)構(gòu)：

整個數(shù)據(jù)部分其實是一整個鏈路，主要是三塊，分別是

**客戶端及服務(wù)器實時數(shù)據(jù)處理、流處理平臺準(zhǔn)實時數(shù)據(jù)處理和大數(shù)據(jù)平臺離線數(shù)據(jù)處理這三個部分。**

看到這里，一個很直觀的問題就是，為什么數(shù)據(jù)處理需要這么多步驟？這些步驟都是干嘛的，存在的意義是什么？

我們一個一個來說，首先是客戶端和服務(wù)端的實時數(shù)據(jù)處理。這個很好理解，這個步驟的工作就是記錄。將用戶在平臺上真實的行為記錄下來，比如用戶看到了哪些內(nèi)容，和哪些內(nèi)容發(fā)生了交互，和哪些沒有發(fā)生了交互。如果再精細(xì)一點，還會記錄用戶停留的時間，用戶使用的設(shè)備等等。除此之外還會記錄行為發(fā)生的時間，行為發(fā)生的session等其他上下文信息。

這一部分主要是后端和客戶端完成，行業(yè)術(shù)語叫做埋點。所謂的埋點其實就是記錄點，因為數(shù)據(jù)這種東西需要工程師去主動記錄，不記錄就沒有數(shù)據(jù)，記錄了才有數(shù)據(jù)。既然我們要做推薦系統(tǒng)，要分析用戶行為，還要訓(xùn)練模型，顯然需要數(shù)據(jù)。需要數(shù)據(jù)，就需要記錄。

第二個步驟是流處理平臺準(zhǔn)實時數(shù)據(jù)處理，這一步是干嘛的呢，其實也是記錄數(shù)據(jù)，不過是記錄一些準(zhǔn)實時的數(shù)據(jù)。很多同學(xué)又會迷糊了，實時我理解，就是當(dāng)下立即的意思，準(zhǔn)實時是什么意思呢？準(zhǔn)實時的意思也是實時，只不過沒有那么即時，比如可能存在幾分鐘的誤差。這樣存在誤差的即時數(shù)據(jù)，行業(yè)術(shù)語叫做準(zhǔn)實時。那什么樣的準(zhǔn)實時數(shù)據(jù)需要記錄呢？在推薦領(lǐng)域基本上只有一個類別，就是用戶行為數(shù)據(jù)。也就是用戶在觀看這個內(nèi)容之前還看過哪些內(nèi)容，和哪些內(nèi)容發(fā)生過交互。理想情況這部分?jǐn)?shù)據(jù)也需要做成實時，但由于這部分?jǐn)?shù)據(jù)量比較大，并且邏輯也相對復(fù)雜，所以很難做到非常實時，一般都是通過消息隊列加在線緩存的方式做成準(zhǔn)實時。

最后我們看第三個步驟，叫做離線數(shù)據(jù)處理，離線也就是線下處理，基本上就沒有時限的要求了。

一般來說，離線處理才是數(shù)據(jù)處理的大頭。所有“臟活累活”復(fù)雜的操作都是在離線完成的，比如說一些join操作。后端只是記錄了用戶交互的商品id，我們需要商品的詳細(xì)信息怎么辦？需要去和商品表關(guān)聯(lián)查表。顯然數(shù)據(jù)關(guān)聯(lián)是一個非常耗時的操作，所以只能放到離線來做。

接下來詳細(xì)介紹一下這三個模塊。

離線層

離線層是計算量最大的一個部分，它的特點是不依賴實時數(shù)據(jù)，也不需要實時提供服務(wù)。需要實現(xiàn)的主要功能模塊是：

數(shù)據(jù)處理、數(shù)據(jù)存儲；特征工程、離線特征計算；離線模型的訓(xùn)練；

這里我們可以看出離線層的任務(wù)是最接近學(xué)校中我們處理數(shù)據(jù)、訓(xùn)練模型這種任務(wù)的，不同可能就是需要面臨更大規(guī)模的數(shù)據(jù)。離線任務(wù)一般會按照天或者更久運(yùn)行，比如每天晚上定期更新這一天的數(shù)據(jù)，然后重新訓(xùn)練模型，第二天上線新模型。

離線層優(yōu)勢和不足

離線層面臨的數(shù)據(jù)量級是最大的，面臨主要的問題是海量數(shù)據(jù)存儲、大規(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)行批量處理和計算；不用有響應(yīng)時間要求；

但是同樣的，如果我們只使用用戶離線數(shù)據(jù)，最大的不足就是無法反應(yīng)用戶的實時興趣變化，這就促使了近線層的產(chǎn)生。

近線層

近線層的主要特點是準(zhǔn)實時，它可以獲得實時數(shù)據(jù)，然后快速計算提供服務(wù)，但是并不要求它和在線層一樣達(dá)到幾十毫秒這種延時要求。近線層的產(chǎn)生是同時想要彌補(bǔ)離線層和在線層的不足，折中的產(chǎn)物。

它適合處理一些對延時比較敏感的任務(wù)，比如：

特征的事實更新計算：例如統(tǒng)計用戶對不同type的ctr，推薦系統(tǒng)一個老生常談的問題就是特征分布不一致怎么辦，如果使用離線算好的特征就容易出現(xiàn)這個問題。近線層能夠獲取實時數(shù)據(jù)，按照用戶的實時興趣計算就能很好避免這個問題。實時訓(xùn)練數(shù)據(jù)的獲取：比如在使用DIN(阿里巴巴使用)、DSIN(阿里巴巴使用)這行網(wǎng)絡(luò)會依賴于用戶的實時興趣變化，用戶幾分鐘前的點擊就可以通過近線層獲取特征輸入模型。模型實時訓(xùn)練：可以通過在線學(xué)習(xí)的方法更新模型，實時推送到線上；

近線層的發(fā)展得益于最近幾年大數(shù)據(jù)技術(shù)的發(fā)展，很多流處理框架的提出大大促進(jìn)了近線層的進(jìn)步。如今Flink、Storm等工具一統(tǒng)天下。

在線層

在線層，就是直接面向用戶的的那一層了。最大的特點是對響應(yīng)延時有要求，因為它是直接面對用戶群體的，你可以想象你打開抖音淘寶等界面，幾乎都是秒刷出來給你的推薦結(jié)果的，不會說還需要讓你等待幾秒鐘時間。所有的用戶請求都會發(fā)送到在線層，在線層需要快速返回結(jié)果，它主要承擔(dān)的工作有：

模型在線服務(wù)；包括了快速召回和排序；在線特征快速處理拼接：根據(jù)傳入的用戶ID和場景，快速讀取特征和處理；AB實驗(一種通過對比兩個版本的性能、用戶體驗等指標(biāo)來優(yōu)化產(chǎn)品或服務(wù)的方法)或者分流：根據(jù)不同用戶采用不一樣的模型，比如冷啟動用戶和正常服務(wù)模型；運(yùn)籌優(yōu)化和業(yè)務(wù)干預(yù)：比如要對特殊商家流量扶持、對某些內(nèi)容限流；

典型的在線服務(wù)是用過RESTful/RPC等提供服務(wù)，一般是公司后臺服務(wù)部門調(diào)用我們的這個服務(wù)，返回給前端。具體部署應(yīng)用比較多的方式就是使用Docker在K8S部署。而在線服務(wù)的數(shù)據(jù)源就是我們在離線層計算好的每個用戶和商品特征，我們事先存放在數(shù)據(jù)庫中，在線層只需要實時拼接，不進(jìn)行復(fù)雜的特征運(yùn)算，然后輸入近線層或者離線層已經(jīng)訓(xùn)練好的模型，根據(jù)推理結(jié)果進(jìn)行排序，最后返回給后臺服務(wù)器，后臺服務(wù)器根據(jù)我們對每一個用戶的打分，再返回給用戶。

在線層最大的問題就是對實時性要求特別高，一般來說是幾十毫秒，這就限制了我們能做的工作，很多任務(wù)往往無法及時完成，需要近線層協(xié)助我們做。

算法架構(gòu)

我們在入門學(xué)習(xí)推薦系統(tǒng)的時候，更加關(guān)注的是哪個模型AUC更高(ROC曲線下的面積)、topK(選擇置信度分?jǐn)?shù)最高的K個結(jié)果進(jìn)行評估)效果好，哪個模型更加牛逼的問題，從基本的協(xié)同過濾到點擊率預(yù)估算法，從深度學(xué)習(xí)到強(qiáng)化學(xué)習(xí)，學(xué)術(shù)界都始終走在最前列。一個推薦算法從出現(xiàn)到在業(yè)界得到廣泛應(yīng)用是一個長期的過程，因為在實際的生產(chǎn)系統(tǒng)中，首先需要保證的是穩(wěn)定、實時地向用戶提供推薦服務(wù)，在這個前提下才能追求推薦系統(tǒng)的效果。

算法架構(gòu)的設(shè)計思想就是在實際的工業(yè)場景中，不管是用戶維度、物品維度還是用戶和物品的交互維度，數(shù)據(jù)都是極其豐富的，學(xué)術(shù)界對算法的使用方法不能照搬到工業(yè)界。當(dāng)一個用戶訪問推薦模塊時，系統(tǒng)不可能針對該用戶對所有的物品進(jìn)行排序，那么推薦系統(tǒng)是怎么解決的呢？對應(yīng)的商品眾多，如何決定將哪些商品展示給用戶？對于排序好的商品，如何合理地展示給用戶？

所以一個通用的算法架構(gòu)，設(shè)計思想就是對數(shù)據(jù)層層建模，層層篩選，幫助用戶從海量數(shù)據(jù)中找出其真正感興趣的部分。

召回

召回層的主要目標(biāo)時從推薦池中選取幾千上萬的item，送給后續(xù)的排序模塊。由于召回面對的候選集十分大，且一般需要在線輸出，故召回模塊必須輕量快速低延遲。由于后續(xù)還有排序模塊作為保障，召回不需要十分準(zhǔn)確，但不可遺漏（特別是搜索系統(tǒng)中的召回模塊）。

如果沒有召回層，每個User都能和每一個Item去在線排序階段預(yù)測目標(biāo)概率，理論上來說是效果最好，但是是不現(xiàn)實的，線上不延遲允許，所以召回和粗排階段就要做一些候選集篩選的工作，保證在有限的能夠給到排序?qū)尤プ鼍诺暮蜻x集的時間里，效果最大化。另一個方面就是通過這種模型級聯(lián)的方式，可以減少用排序階段擬合多目標(biāo)的壓力，比如召回階段我們現(xiàn)在主要是在保證Item質(zhì)量的基礎(chǔ)上注重覆蓋率多樣性，粗排階段主要用簡單的模型來解決不同路的召回和當(dāng)前用戶的相關(guān)性問題，最后截斷到1k個以內(nèi)的候選集，這個候選集符合一定的個性化相關(guān)性、視頻質(zhì)量和多樣性的保證，然后做ranking去做復(fù)雜模型的predict。

目前基本上采用多路召回解決范式，分為非個性化召回和個性化召回。個性化召回又有content-based、behavior-based、feature-based等多種方式。

召回主要考慮的內(nèi)容有：

考慮用戶層面：用戶興趣的多元化，用戶需求與場景的多元化：例如：新聞需求，重大要聞，相關(guān)內(nèi)容沉浸閱讀等等考慮系統(tǒng)層面：增強(qiáng)系統(tǒng)的魯棒性；部分召回失效，其余召回隊列兜底不會導(dǎo)致整個召回層失效；排序?qū)邮?，召回隊列兜底不會?dǎo)致整個推薦系統(tǒng)失效系統(tǒng)多樣性內(nèi)容分發(fā)：圖文、視頻、小視頻；精準(zhǔn)、試探、時效一定比例；召回目標(biāo)的多元化，例如：相關(guān)性，沉浸時長，時效性，特色內(nèi)容等等可解釋性推薦一部分召回是有明確推薦理由的：很好的解決產(chǎn)品性數(shù)據(jù)的引入；

粗排

粗排的原因是有時候召回的結(jié)果還是太多，精排層速度還是跟不上，所以加入粗排。粗排可以理解為精排前的一輪過濾機(jī)制，減輕精排模塊的壓力。粗排介于召回和精排之間，要同時兼顧精準(zhǔn)性和低延遲。目前粗排一般也都模型化了，其訓(xùn)練樣本類似于精排，選取曝光點擊為正樣本，曝光未點擊為負(fù)樣本。但由于粗排一般面向上萬的候選集，而精排只有幾百上千，其解空間大很多。

粗排階段的架構(gòu)設(shè)計主要是考慮三個方面，一個是根據(jù)精排模型中的重要特征，來做候選集的截斷，另一部分是有一些召回設(shè)計，比如熱度或者語義相關(guān)的這些結(jié)果，僅考慮了item側(cè)的特征，可以用粗排模型來排序跟當(dāng)前User之間的相關(guān)性，據(jù)此來做截斷，這樣是比單獨的按照item側(cè)的倒排分?jǐn)?shù)截斷得到更加個性化的結(jié)果，最后是算法的選型要在在線服務(wù)的性能上有保證，因為這個階段在pipeline中完成從召回到精排的截斷工作，在延遲允許的范圍內(nèi)能處理更多的召回候選集理論上與精排效果正相關(guān)。

精排

精排層，也是我們學(xué)習(xí)推薦入門最常常接觸的層，我們所熟悉的算法很大一部分都來自精排層。這一層的任務(wù)是獲取粗排模塊的結(jié)果，對候選集進(jìn)行打分和排序。精排需要在最大時延允許的情況下，保證打分的精準(zhǔn)性，是整個系統(tǒng)中至關(guān)重要的一個模塊，也是最復(fù)雜，研究最多的一個模塊。

精排是推薦系統(tǒng)各層級中最純粹的一層，他的目標(biāo)比較單一且集中，一門心思的實現(xiàn)目標(biāo)的調(diào)優(yōu)即可。最開始的時候精排模型的常見目標(biāo)是ctr,后續(xù)逐漸發(fā)展了cvr等多類目標(biāo)。精排和粗排層的基本目標(biāo)是一致的，都是對商品集合進(jìn)行排序，但是和粗排不同的是，精排只需要對少量的商品(即粗排輸出的商品集合的topN)進(jìn)行排序即可。因此，精排中可以使用比粗排更多的特征，更復(fù)雜的模型和更精細(xì)的策略（用戶的特征和行為在該層的大量使用和參與也是基于這個原因）。

精排層模型是推薦系統(tǒng)中涵蓋的研究方向最多，有非常多的子領(lǐng)域值得研究探索，這也是推薦系統(tǒng)中技術(shù)含量最高的部分，畢竟它是直接面對用戶，產(chǎn)生的結(jié)果對用戶影響最大的一層。目前精排層深度學(xué)習(xí)已經(jīng)一統(tǒng)天下了，精排階段采用的方案相對通用，首先一天的樣本量是幾十億的級別，我們要解決的是樣本規(guī)模的問題，盡量多的喂給模型去記憶，另一個方面時效性上，用戶的反饋產(chǎn)生的時候，怎么盡快的把新的反饋給到模型里去，學(xué)到最新的知識。

重排

常見的有三種優(yōu)化目標(biāo)：Point Wise、Pair Wise 和 List Wise。重排序階段對精排生成的Top-N個物品的序列進(jìn)行重新排序，生成一個Top-K個物品的序列，作為排序系統(tǒng)最后的結(jié)果，直接展現(xiàn)給用戶。重排序的原因是因為多個物品之間往往是相互影響的，而精排序是根據(jù)PointWise得分，容易造成推薦結(jié)果同質(zhì)化嚴(yán)重，有很多冗余信息。而重排序面對的挑戰(zhàn)就是海量狀態(tài)空間如何求解的問題，一般在精排層我們使用AUC作為指標(biāo)，但是在重排序更多關(guān)注NDCG等指標(biāo)。

重排序在業(yè)務(wù)中，獲取精排的排序結(jié)果，還會根據(jù)一些策略、運(yùn)營規(guī)則參與排序，比如強(qiáng)制去重、間隔排序、流量扶持等、運(yùn)營策略、多樣性、context上下文等，重新進(jìn)行一個微調(diào)。重排序更多的是List Wise作為優(yōu)化目標(biāo)的，它關(guān)注的是列表中商品順序的問題來優(yōu)化模型，但是一般List Wise因為狀態(tài)空間大，存在訓(xùn)練速度慢的問題。

由于精排模型一般比較復(fù)雜，基于系統(tǒng)時延考慮，一般采用point-wise方式，并行對每個item進(jìn)行打分。這就使得打分時缺少了上下文感知能力。用戶最終是否會點擊購買一個商品，除了和它自身有關(guān)外，和它周圍其他的item也息息相關(guān)。重排一般比較輕量，可以加入上下文感知能力，提升推薦整體算法效率。比如三八節(jié)對美妝類目商品提權(quán)，類目打散、同圖打散、同賣家打散等保證用戶體驗措施。重排中規(guī)則比較多，但目前也有不少基于模型來提升重排效果的方案。

混排

多個業(yè)務(wù)線都想在Feeds流中獲取曝光，則需要對它們的結(jié)果進(jìn)行混排。比如推薦流中插入廣告、視頻流中插入圖文和banner等?？梢曰谝?guī)則策略（如廣告定坑）和強(qiáng)化學(xué)習(xí)來實現(xiàn)。

總結(jié)

整篇文章從系統(tǒng)架構(gòu)梳理了Netfliex的經(jīng)典推薦系統(tǒng)架構(gòu)，整個架構(gòu)更多是偏向?qū)崟r性能和效果之間tradeoff的結(jié)果。如果從另外的角度看推薦系統(tǒng)架構(gòu)，比如從數(shù)據(jù)流向，或者說從推薦系統(tǒng)各個時序依賴來看，就是我們最熟悉的召回、粗排、精排、重排、混排等模塊了。這種角度來看是把推薦系統(tǒng)從前往后串起來，其中每一個模塊既有在離線層工作的，也有在在線層工作的。而從數(shù)據(jù)驅(qū)動角度看，更能夠看到推薦系統(tǒng)的完整技術(shù)棧，推薦系統(tǒng)當(dāng)前面臨的局限和發(fā)展方向。

召回、排序這些里面單拿出任何一個模塊都非常復(fù)雜。這也是為什么大家都說大廠擰螺絲的原因，因為很可能某個人只會負(fù)責(zé)其中很小的一個模塊。許多人說起自己的模塊來如數(shù)家珍，但對于全局缺乏認(rèn)識，帶來的結(jié)果是當(dāng)你某天跳槽了或者是工作內(nèi)容變化了，之前從工作當(dāng)中的學(xué)習(xí)積累很難沉淀下來，這對于程序員的成長來說是很不利的。

所以希望這篇文章能夠幫助大家在負(fù)責(zé)某一個模塊，優(yōu)化某一個功能的時候，除了能夠有算法和數(shù)據(jù)，還能能夠考慮對整個架構(gòu)帶來的影響，如何提升整體的一個性能，慢慢開闊自己的眼界，構(gòu)建出一個更好的推薦系統(tǒng)。

參考資料

《從零開始構(gòu)建企業(yè)級推薦系統(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)

柚子快報激活碼778899分享：推薦系統(tǒng)架構(gòu)

http://yzkb.51969.com/

推薦文章