知乎從問答起步，已逐步成長為一個大規(guī)模的綜合性知識內(nèi)容平臺，截止目前，用戶數(shù)突破 2.2 億，有超過 3000 萬的問題被提出，并獲得超過 1.3 億個回答。同時，知乎內(nèi)還沉淀了數(shù)量眾多的優(yōu)質(zhì)文章、電子書以及其它付費內(nèi)容。

因此，在鏈接人與知識的路徑中，知乎存在著大量的推薦場景。粗略統(tǒng)計，目前除了首頁推薦之外，我們已存在著 20 多種推薦場景;并且在業(yè)務(wù)快速發(fā)展中，不斷有新的推薦業(yè)務(wù)需求加入。在這個背景之下，構(gòu)建一個較通用的且便于業(yè)務(wù)接入的推薦系統(tǒng)就變成不得不做的事了。

重構(gòu)推薦系統(tǒng)需要考慮哪些因素?如何做技術(shù)選型?重構(gòu)的過程中會遇到哪些坑?希望知乎的踩坑經(jīng)驗?zāi)芙o你帶來一些思考。

背景

在講通用架構(gòu)的設(shè)計之前，我們一起回顧一下推薦系統(tǒng)的總體流程和架構(gòu)。通常，因為模型所需特征及排序的性能考慮，我們通常將簡單的推薦系統(tǒng)分為召回層和 ranking 層，召回層主要負(fù)責(zé)從候選集合中粗排選擇待排序集合，之后獲取 ranking 特征，經(jīng)過排序模型，挑選出推薦結(jié)果給用戶。

簡單推薦模型適合一些推薦結(jié)果要求單一，只對單目標(biāo)負(fù)責(zé)的推薦場景，比如新聞詳情頁推薦、文章推薦等等。但在現(xiàn)實中，作為通用的推薦系統(tǒng)來說，其需要考慮用戶的多維度需求，比如用戶的多樣性需求、時效性需求、結(jié)果的滿足性需求等。因此就需要在推薦過程中采用多個不同隊列，針對不同需求進(jìn)行排序，之后通過多隊列融合策略，從而滿足用戶不同的需求。

從我們知乎來說，也大體是這樣一個發(fā)展路線，比如今年的 7 月份時，因為一些業(yè)務(wù)快速發(fā)展且架構(gòu)上相對獨立的歷史原因，我們的推薦系統(tǒng)存在多套，并且架構(gòu)相對簡單。以其中一個推薦架構(gòu)設(shè)計相對完善的系統(tǒng)為例，其總體架構(gòu)是這樣的?？梢钥闯?，這個架構(gòu)已經(jīng)包含了召回層和 ranking 層，并且還考慮了二次排序。

那么存在哪些問題呢?

首先，對多路召回支持不友好。現(xiàn)有架構(gòu)的召回是耦合在一起的，因此開發(fā)調(diào)研成本高，多路召回接入相對困難。

然后，召回階段只使用 Redis 作為召回基礎(chǔ)。Redis 有很多優(yōu)點，比如查詢效率高，服務(wù)較穩(wěn)定。但將其作為所有召回層的基礎(chǔ)，就放大了其缺點，***不支持稍復(fù)雜的召回邏輯，第二無法進(jìn)行大量結(jié)果的召回計算，第三不支持 embedding 的召回。

第三點，總體架構(gòu)在實現(xiàn)時，架構(gòu)邏輯剝離不夠干凈，使得架構(gòu)抽樣邏輯較弱，各種通用特征和通用監(jiān)控建設(shè)都較困難。

第四點，我們知道，在推薦系統(tǒng)中，特征日志的建設(shè)是非常重要的一個環(huán)節(jié)，它是推薦效果好壞的重要基礎(chǔ)之一。但現(xiàn)有推薦系統(tǒng)框架中，特征日志建設(shè)缺乏統(tǒng)一的校驗和落地方案，各業(yè)務(wù)『各顯神通』。

第五點，當(dāng)前系統(tǒng)是不支持多隊列融合的，這就嚴(yán)重限制了通用架構(gòu)的可擴(kuò)展性和易用性。因此，我們就準(zhǔn)備重構(gòu)知乎的通用推薦服務(wù)框架。

重構(gòu)之路

在重構(gòu)前的考慮

***，語言的選擇。早期知乎大量的服務(wù)都是基于 Python 開發(fā)的，但在實踐過程中發(fā)現(xiàn) Python 資源消耗過大、不利用多人協(xié)同開發(fā)等各種問題，之后公司進(jìn)行了大規(guī)模的重構(gòu)，現(xiàn)在知乎在語言層面的技術(shù)選型上比較開放，目前公司內(nèi)部已有 Python、Scala、Java、Golang 等多種開發(fā)語言項目。那么對于推薦系統(tǒng)服務(wù)來說，由于其重計算，多并發(fā)的特點，語言的選擇還是需要考慮的。

第二，架構(gòu)上的考慮，要解決支持多隊列混排和支持多路召回的問題，并且其設(shè)計***是支持可插拔的。

第三，召回層上，除了傳統(tǒng)的 Redis 的 kv 召回(部分 cf 召回，熱門召回等等應(yīng)用場景)，我們還需要考慮一些其他索引數(shù)據(jù)庫，以便支持更多索引類型。

首先我們先看語言上的選擇，先總體上比較一下各種語言的特點，我們簡單從如下幾個方面進(jìn)行比較。

從性能上，依照公開的 benchmark，Golang 和 Java、Scala 大概在一個量級，是 Python 的 30 倍左右。其次 Golang 的編譯速度較快，這點相對于 Java、Scala 具有比較明顯的優(yōu)勢，再次其語言特性決定了 Golang 的開發(fā)效率較高，此外因為缺乏 trycatch 機(jī)制，使得使用 Golang 開發(fā)時對異常處理思考較多，因此其上線之后維護(hù)成本相對較低。但 Golang 有個明顯缺陷就是目前第三方庫較少，特別跟 AI 相關(guān)的庫。

那么基于以上優(yōu)缺點，我們重構(gòu)為什么選擇 Golang?

1、Golang 天然的優(yōu)勢，支持高并發(fā)并且占用資源相對較少。這個優(yōu)勢恰恰是推薦系統(tǒng)所需要的，推薦系統(tǒng)存在大量需要高并發(fā)的場景，比如多路召回，特征計算等等。

2、知乎內(nèi)部基礎(chǔ)組件的 Golang 版生態(tài)比較完善。目前我們知乎內(nèi)部對于 Golang 的使用越來越積極，大量基礎(chǔ)組件都已經(jīng) Golang 化，包括基礎(chǔ)監(jiān)控組件等等，這也是我們選擇 Golang 的重要原因。

但我需要強(qiáng)調(diào)一點，語言的選擇不是只有唯一答案的，這是跟公司技術(shù)和業(yè)務(wù)場景結(jié)合的選擇。

講完語言上的選擇，那么為了在重構(gòu)時支持多隊列混排和支持多路召回，我們架構(gòu)上是如何來解決的?

這點在設(shè)計模式比較常見，就是『抽象工廠模式』：首先我們構(gòu)建隊列注冊管理器，將回調(diào)注冊一個 map 中，并將當(dāng)前服務(wù)所有隊列做成 json 配置的可自由插拔的模式，比如如下配置，指定一個服務(wù)所需要的全部隊列，存入 queues 字段中。

通過 name 來從注冊管理器的 map 中調(diào)取相應(yīng)的隊列服務(wù)。

之后呢我們就可以并發(fā)進(jìn)行多隊列的處理。

對于多路召回，及整個推薦具體流程的可插拔，與上面處理手法類似，比如如下隊列：

我們可以指定所需召回源，指定 merger 策略等等，當(dāng)某個過程不需處理，會按自動默認(rèn)步驟處理，這樣在具體 Queue 的實現(xiàn)中就可以通過如下簡單操作進(jìn)行自由配置。

我們講完了架構(gòu)上一些思考點和具體架構(gòu)實現(xiàn)方案，下面就是關(guān)于召回層具體技術(shù)選型問題。

我們先回顧一下，在常用的推薦召回源中，有基于 topic(tag)的召回、實體的召回、地域的召回、CF(協(xié)同過濾)的召回以及 NN 產(chǎn)生的 embedding 召回等等。那么為了能夠支持這些召回，技術(shù)上我們應(yīng)該如何來實現(xiàn)呢?

我們先從使用角度看一下常用的 NoSQL 數(shù)據(jù)庫產(chǎn)品，Redis 是典型的 k-v 存儲，其簡單、并且高性能使得其在業(yè)內(nèi)得到大量使用，但不支持復(fù)雜查詢的問題也讓 Redis 在召回復(fù)雜場景下并不占優(yōu)，因此一般主要適用于 kv 類的召回，比如熱門召回，地域召回，少量的 CF 召回等等。而 HBase 作為海量數(shù)據(jù)的列式存儲數(shù)據(jù)庫，有一個明顯缺點就是復(fù)雜查詢性能差，因此一般適合數(shù)據(jù)查詢量大，但查詢簡單的場景，比如推薦系統(tǒng)當(dāng)中的已讀已推等等場景。而 ES 其實已經(jīng)不算是一個數(shù)據(jù)庫了，而是一個通用搜索引擎范疇，其***優(yōu)點就是支持復(fù)雜聚合查詢，因此將其用戶通用基礎(chǔ)檢索，是一個相對適合的選擇。

我們上面介紹了通用召回的技術(shù)選型，那么 embedding 召回如何來處理呢，我們的方案是基于 Facebook 開源的 faiss 封裝，構(gòu)建一個通用 ANN(近似最近鄰)檢索服務(wù)。faiss 是為稠密向量提供高效相似度搜索和聚類的框架。其具有如下特性：1、提供了多種 embedding 召回方法;2、檢索速度快，我們基于 python 接口封裝，影響時間在幾 ms-20ms 之間;3、c++ 實現(xiàn)，并且提供了 python 的封裝調(diào)用;4、大部分算法支持 GPU 實現(xiàn)。

從以上介紹可以看出，在通用的推薦場景中，我們召回層大體是基于 ES+Redis+ANN 的模式進(jìn)行構(gòu)建。ES 主要支持相對復(fù)雜的召回邏輯，比如基于多種 topic 的混合召回;Redis 主要用于支持熱門召回，以及規(guī)模相對較小的 CF 召回等;ANN 主要支持 embedding 召回，包括 nn 產(chǎn)出的 embedding、CF 訓(xùn)練產(chǎn)出的 embedding 等等。

介紹完以上思考點，我們總體的架構(gòu)就基本成型了，具體如下圖所示。該框架可以支持多隊列融合，并且每個隊列也支持多路召回，從而對于不同推薦場景能夠較好的支持，另外，我們召回選擇了 ES+Redis+ANN 的技術(shù)棧方案，可以較好支持多種不同類型召回，并達(dá)到服務(wù)線上的最終目的。

重構(gòu)遇到的一些問題及解決方案

1、離線任務(wù)和模型的管理問題。我們做在線服務(wù)的都有體會，我們經(jīng)常容易對線上業(yè)務(wù)邏輯代碼更關(guān)注一些，而往往忽視離線代碼任務(wù)的管理和維護(hù)。但離線代碼任務(wù)和模型在推薦場景中又至關(guān)重要。因此如何有效維護(hù)離線代碼和任務(wù)，是我們面臨的***個問題。

2、特征日志問題。在推薦系統(tǒng)中，我們常常會遇到特征拼接和特征的『時間穿越』的問題。所謂特征時間穿越，指的是模型訓(xùn)練時用到了預(yù)測時無法獲取的『未來信息』，這主要是訓(xùn)練 label 和特征拼接時時間上不夠嚴(yán)謹(jǐn)導(dǎo)致。如何構(gòu)建便捷通用的特征日志，減少特征拼接錯誤和特征穿越，是我們面臨的第二個問題。

3、服務(wù)監(jiān)控問題。一個通用的推薦系統(tǒng)應(yīng)該在基礎(chǔ)監(jiān)控上做到盡可能通用可復(fù)用，減少具體業(yè)務(wù)對于監(jiān)控的開發(fā)量，并方便業(yè)務(wù)定位問題。

4、離線任務(wù)和模型的管理問題。

在包括推薦系統(tǒng)的算法方向中，需要構(gòu)建大量離線任務(wù)支持各種數(shù)據(jù)計算業(yè)務(wù)，和模型的定時訓(xùn)練工作。但實際工作中，我們往往忽略離線任務(wù)代碼管理的重要性，當(dāng)時間一長，各種數(shù)據(jù)和特征的質(zhì)量往往無法保證。為了盡可能解決這樣的問題，我們從三方面來做，***，將通用推薦系統(tǒng)依賴的離線任務(wù)的代碼統(tǒng)一到一處管理;第二，結(jié)合公司離線任務(wù)管理平臺，將所有任務(wù)以通用包的形式進(jìn)行管理，這樣保證所有任務(wù)的都是依賴***包;第三，建設(shè)任務(wù)結(jié)果的監(jiān)控體系，將離線任務(wù)的產(chǎn)出完整監(jiān)控起來。

5、特征日志問題。

Andrew Ng 之前說過：『挖掘特征是困難、費時且需要專業(yè)知識的事，應(yīng)用機(jī)器學(xué)習(xí)其實基本上是在做特征工程?！晃覀兝硐胫械耐扑]系統(tǒng)模型應(yīng)該是有干凈的 Raw Data，方便處理成可學(xué)習(xí)的 Dataset，通過某種算法學(xué)習(xí) model，來達(dá)到預(yù)測效果不斷優(yōu)化的目的。

但現(xiàn)實中，我們需要處理各種各樣的數(shù)據(jù)源，有數(shù)據(jù)庫的，有日志的，有離線的，有在線的。這么多來源的 Raw Data，不可避免的會遇到各種各樣的問題，比如特征拼接錯誤，特征『時間穿越』等等。

這里邊反應(yīng)的一個本質(zhì)問題是特征處理流程的規(guī)范性問題。那么我們是如何來解決這一點呢，首先，我們用在線代替了離線，通過在線落特征日志，而不是 Raw Data，并統(tǒng)一了特征日志 Proto，如此就可以統(tǒng)一特征解析腳本。

6、服務(wù)監(jiān)控問題。

在監(jiān)控問題上，知乎搭建了基于 StatsD + Grafana + InfluxDB 的監(jiān)控系統(tǒng)，以支持各種監(jiān)控日志的收集存儲及展示?；谶@套系統(tǒng)，我們可以便捷的構(gòu)建自己微服務(wù)的各種監(jiān)控。

我們這里不過多介紹通用監(jiān)控系統(tǒng)，主要介紹下，基于推薦系統(tǒng)我們監(jiān)控建設(shè)的做法。首先先回顧一下我們推薦系統(tǒng)的通用設(shè)計上，我們采用了『可插拔』的多隊列和多召回的設(shè)計，那么可以在通用架構(gòu)設(shè)計獲取到各種信息，比如業(yè)務(wù)線名，業(yè)務(wù)名，隊列名，process 名等等。如此，我們就可以將監(jiān)控使用如下方式實現(xiàn)，這樣就可以通用化的設(shè)計監(jiān)控，而不需各個推薦業(yè)務(wù)再過多設(shè)計監(jiān)控及相關(guān)報警。

按照如上實現(xiàn)之后，我們推薦系統(tǒng)的監(jiān)控體系大概是什么樣子?首先各個業(yè)務(wù)可以通過 grafana 展示頁面進(jìn)行設(shè)置。我們可以看到各個 flow 的各種數(shù)據(jù)，以及召回源的比例關(guān)系，還有特征分布，ranking 得分分布等等。

未來挑戰(zhàn)講完了遇到的一些問題之后，我們來看一下未來的挑戰(zhàn)。隨著業(yè)務(wù)的快速發(fā)展，數(shù)據(jù)和規(guī)模還在不斷擴(kuò)張，架構(gòu)上還需要不斷迭代;第二點，隨著推薦業(yè)務(wù)越來越多，策略的通用性和業(yè)務(wù)之間的隔離如何協(xié)調(diào)一致;第三點，資源調(diào)度和性能開銷也需要不斷優(yōu)化;***，多機(jī)房之間數(shù)據(jù)如何保持同步也是需要考慮的問題。

總 結(jié)

***，我們做個簡單總結(jié)：***點，重構(gòu)語言的選擇，關(guān)鍵要跟公司技術(shù)背景和業(yè)務(wù)場景結(jié)合起來;第二點，架構(gòu)盡量靈活，并不斷自我迭代;第三點，監(jiān)控要早點開展，并盡可能底層化、通用化。