58同城作為中國(guó)最大的分類信息網(wǎng)站，向用戶提供找房子、找工作、二手車和黃頁(yè)等多種生活信息。在這樣的場(chǎng)景下，推薦系統(tǒng)能夠幫助用戶發(fā)現(xiàn)對(duì)自己有價(jià)值的信息，提升用戶體驗(yàn)，本文將介紹58同城智能推薦系統(tǒng)的技術(shù)演進(jìn)和實(shí)踐。

58同城智能推薦系統(tǒng)大約誕生于2014年（C++實(shí)現(xiàn)），該套系統(tǒng)先后經(jīng)歷了招聘、房產(chǎn)、二手車、黃頁(yè)和二手物品等產(chǎn)品線的推薦業(yè)務(wù)迭代，但該系統(tǒng)耦合性高，難以適應(yīng)推薦策略的快速迭代。58同城APP猜你喜歡推薦和推送項(xiàng)目在2016年快速迭代，產(chǎn)出了一套基于微服務(wù)架構(gòu)的推薦系統(tǒng)（Java實(shí)現(xiàn)），該系統(tǒng)穩(wěn)定、高性能且耦合性低，支持推薦策略的快速迭代，大大提高了推薦業(yè)務(wù)的迭代效率。此后，我們對(duì)舊的推薦系統(tǒng)進(jìn)行了重構(gòu)，將所有業(yè)務(wù)接入至新的推薦系統(tǒng)，最終成功打造了統(tǒng)一的58同城智能推薦系統(tǒng)。下面我們將對(duì)58同城智能推薦系統(tǒng)展開(kāi)介紹，首先會(huì)概覽整體架構(gòu)，然后從算法、系統(tǒng)和數(shù)據(jù)三方面做詳細(xì)介紹。

整體架構(gòu)

首先看一下58同城推薦系統(tǒng)整體架構(gòu)，一共分?jǐn)?shù)據(jù)層、策略層和應(yīng)用層三層，基于58平臺(tái)產(chǎn)生的各類業(yè)務(wù)數(shù)據(jù)和用戶積累的豐富的行為數(shù)據(jù)，我們采用各類策略對(duì)數(shù)據(jù)進(jìn)行挖掘分析，最終將結(jié)果應(yīng)用于各類推薦場(chǎng)景。

• 猜你喜歡：58同城最重要的推薦產(chǎn)品，推薦場(chǎng)景包括APP首頁(yè)和不同品類的大類頁(yè)，目標(biāo)是讓用戶打開(kāi)APP或進(jìn)入大類頁(yè)時(shí)可以快速找到他們想要的帖子信息，這主要根據(jù)用戶的個(gè)人偏好進(jìn)行推薦。
• 詳情頁(yè)相關(guān)推薦：用戶進(jìn)入帖子詳情頁(yè)，會(huì)向用戶推薦與當(dāng)前帖子相關(guān)的帖子。該場(chǎng)景下用戶意圖較明顯，會(huì)采用以當(dāng)前帖子信息為主用戶偏好信息為輔的方式進(jìn)行推薦。
• 搜索少無(wú)結(jié)果推薦：用戶會(huì)通過(guò)品類列表頁(yè)上的篩選項(xiàng)或搜索框進(jìn)入品類列表頁(yè)獲取信息，若當(dāng)前篩選項(xiàng)或搜索條件搜索出的結(jié)果較少或者沒(méi)有結(jié)果，便會(huì)觸發(fā)推薦邏輯進(jìn)行信息推薦。此時(shí)會(huì)結(jié)合當(dāng)前搜索條件的擴(kuò)展以及用戶偏好信息進(jìn)行推薦。
• 個(gè)性化推送（Push）：在用戶打開(kāi)APP前，將用戶感興趣的信息推送給他們，促使用戶點(diǎn)擊，提高用戶活躍度。這里包含推送通知的生成和推送落地頁(yè)上帖子列表的生成兩個(gè)推薦邏輯。值得一提的是推送是強(qiáng)制性的推薦，會(huì)對(duì)用戶形成騷擾，因此如何降低用戶騷擾并給用戶推薦真正感興趣的信息尤為重要。
• Feed流推薦：我們的推薦產(chǎn)品在某些推薦場(chǎng)景下是以Feed流的形式展現(xiàn)的，例如APP消息中心的今日推薦場(chǎng)景、推送落地頁(yè)場(chǎng)景。用戶可以在這些頁(yè)面中不斷下拉刷新消費(fèi)信息，類似時(shí)下火熱的各大資訊Feed流推薦。

推薦系統(tǒng)是一個(gè)復(fù)雜的工程，涉及算法策略、工程架構(gòu)和效果數(shù)據(jù)評(píng)估三方面的技術(shù)，后文將分別從這三方面介紹58同城推薦系統(tǒng)。

算法

推薦涉及了前端頁(yè)面到后臺(tái)算法策略間的各個(gè)流程，我們將推薦流程抽象成如下圖所示的召回、排序、規(guī)則和展示四個(gè)主要環(huán)節(jié)：

• 召回環(huán)節(jié)即使用各種算法邏輯從海量的帖子中篩選出用戶感興趣的帖子候選集合，一般集合大小是幾十到上百。
• 排序即對(duì)候選集合中的帖子進(jìn)行打分排序，這里一般會(huì)使用機(jī)器學(xué)習(xí)排序模型，排序環(huán)節(jié)會(huì)生成一個(gè)排序列表。
• 規(guī)則環(huán)節(jié)即我們可能對(duì)排序列表采取一定的規(guī)則策略，最終生成一個(gè)包含N條結(jié)果的列表。例如在規(guī)則環(huán)節(jié)我們可能會(huì)采取不同的去重策略，如文本去重、圖片去重、混合去重等，可能會(huì)采取不同的列表打散策略，可能會(huì)迭代產(chǎn)品經(jīng)理提出的各種規(guī)則邏輯。由于推薦系統(tǒng)的最終評(píng)價(jià)是看統(tǒng)計(jì)效果，因此各種人為的規(guī)則都會(huì)影響最終結(jié)果，我們抽象出規(guī)則環(huán)節(jié)后便可以對(duì)任何邏輯做線上ABTest，最終評(píng)價(jià)相關(guān)邏輯是否合理。
• 生成N條推薦結(jié)果列表后，不同的前端展示方式也會(huì)影響最終的推薦效果，例如不同的UI設(shè)計(jì)，采用大圖模式還是小圖模式，頁(yè)面上展示哪些字段都會(huì)影響用戶在推薦列表頁(yè)上的點(diǎn)擊，因此在推薦產(chǎn)品迭代過(guò)程中不同的展示樣式迭代也很重要。

在上述的四個(gè)環(huán)節(jié)中，召回和排序是推薦系統(tǒng)最重要的兩個(gè)環(huán)節(jié)。規(guī)則和展示樣式一般變化周期較長(zhǎng)，而召回和排序有很大的挖掘空間，會(huì)被不斷的迭代，我們的推薦算法工作也主要是圍繞召回和排序進(jìn)行。下圖是我們推薦算法的整體框架，主要包括基礎(chǔ)數(shù)據(jù)的計(jì)算以及上層的召回策略和排序模型的迭代。

基礎(chǔ)數(shù)據(jù)計(jì)算主要包括用戶標(biāo)簽和帖子標(biāo)簽的挖掘，這部分工作由用戶畫(huà)像、搜索和推薦多個(gè)團(tuán)隊(duì)共同完成，最終各團(tuán)隊(duì)共享數(shù)據(jù)。基于用戶注冊(cè)時(shí)填寫的基礎(chǔ)屬性信息和用戶行為日志，可以挖掘出用戶人口屬性和興趣偏好信息，如用戶的年齡、性別、學(xué)歷、收入等基礎(chǔ)屬性，用戶感興趣的地域商圈、二手房均價(jià)、廳室、裝修程度等偏好信息。帖子標(biāo)簽挖掘包括提取帖子的固定屬性、挖掘衍生屬性以及計(jì)算動(dòng)態(tài)屬性。固定屬性直接從帖子數(shù)據(jù)庫(kù)提取即可，如分類、地域、標(biāo)題、正文、圖片、房源價(jià)格、廳室、小區(qū)等。我們還會(huì)基于貼子信息是否完備、價(jià)格是否合理、圖片質(zhì)量好壞、發(fā)帖人質(zhì)量等多個(gè)維度來(lái)計(jì)算帖子質(zhì)量分。基于用戶行為日志數(shù)據(jù)可以計(jì)算帖子的PV、UV、點(diǎn)擊率、轉(zhuǎn)化率、停留時(shí)長(zhǎng)等動(dòng)態(tài)屬性。這些數(shù)據(jù)最終會(huì)在召回環(huán)節(jié)和排序環(huán)節(jié)使用，例如基于用戶標(biāo)簽和帖子標(biāo)簽可以進(jìn)行興趣召回，將用戶標(biāo)簽和帖子標(biāo)簽作為特征迭代機(jī)器學(xué)習(xí)模型。

召回主要負(fù)責(zé)生成推薦的候選集，我們采用多種召回源融合的方式來(lái)完成該過(guò)程。我們先后迭代了如下各類召回策略：

• 熱門召回。基于曝光和點(diǎn)擊日志，我們會(huì)計(jì)算不同粒度的熱門數(shù)據(jù)。以二手車業(yè)務(wù)線為例，從粗粒度到細(xì)粒度的數(shù)據(jù)包括：城市下的熱門商圈、商圈下的熱門車系和品牌、特定車系和品牌下的熱門車源等。每一個(gè)車源的熱度我們通過(guò)最近一段時(shí)間內(nèi)帖子的PV、UV、CTR等指標(biāo)來(lái)衡量，這里的CTR會(huì)通過(guò)貝葉斯和COEC做平滑處理。熱門召回策略會(huì)在冷啟動(dòng)時(shí)被大量采用。
• 地域召回。58同城是向用戶提供本地生活服務(wù)類信息，用戶的每次訪問(wèn)都會(huì)帶上地域信息，如選擇的城市、定位的地點(diǎn)等。我們主要結(jié)合地域信息和熱門數(shù)據(jù)做召回，如附近最新或最熱帖子召回、城市熱門帖子召回等。
• 興趣召回?；谔踊A(chǔ)屬性字段和帖子標(biāo)簽信息，我們構(gòu)建了一套帖子檢索系統(tǒng)，通過(guò)該系統(tǒng)能夠以標(biāo)簽或?qū)傩宰侄螜z索出最新發(fā)布的帖子。在用戶畫(huà)像中，我們計(jì)算了每個(gè)用戶的興趣標(biāo)簽，因此基于用戶興趣標(biāo)簽便能在檢索系統(tǒng)中檢索出一批帖子，這可以作為一種召回源。此外，在帖子詳情頁(yè)相關(guān)推薦場(chǎng)景中，我們也可以利用當(dāng)前帖子的屬性和標(biāo)簽信息去檢索系統(tǒng)中檢索出相關(guān)帖子作為召回?cái)?shù)據(jù)源。這兩種檢索召回其實(shí)就是我們常說(shuō)的基于內(nèi)容的推薦。
• 關(guān)聯(lián)規(guī)則。這里并非直接采用傳統(tǒng)Apriori、FP-growth關(guān)聯(lián)規(guī)則算法，而是參考關(guān)聯(lián)規(guī)則思想，將最近一段時(shí)間中每個(gè)用戶點(diǎn)擊所有物品當(dāng)做一次事務(wù)，由此計(jì)算兩兩物品之間的支持度，并在支持度中融入時(shí)間衰減因子，最終可以得到每個(gè)物品的topK個(gè)關(guān)聯(lián)性強(qiáng)的物品。這種召回方式其實(shí)類似協(xié)同過(guò)濾中的item相似度矩陣計(jì)算，我們主要將其應(yīng)用在詳情頁(yè)相關(guān)推薦中。
• 協(xié)同過(guò)濾。我們使用Spark實(shí)現(xiàn)了基于User和基于Item的批量協(xié)同過(guò)濾計(jì)算，由于數(shù)據(jù)量大，批量計(jì)算會(huì)較消耗時(shí)間，我們又實(shí)現(xiàn)了基于Item的實(shí)時(shí)協(xié)同過(guò)濾算法。通常情況下我們會(huì)直接將用戶的推薦結(jié)果列表作為一種召回源，而在詳情頁(yè)相關(guān)推薦場(chǎng)景，我們還會(huì)使用協(xié)同過(guò)濾計(jì)算出的Item相似度矩陣，將帖子最相似的topK個(gè)帖子也作為一種召回源。
• 矩陣分解。我們引入了SVD算法，將用戶對(duì)帖子的點(diǎn)擊、收藏、分享、微聊和電話等行為操作看作用戶對(duì)帖子進(jìn)行不同檔次的評(píng)分，從而構(gòu)建評(píng)分矩陣數(shù)據(jù)集來(lái)做推薦。
• DNN召回。Google在YouTube視頻推薦上使用了DNN來(lái)做召回，我們也正在進(jìn)行相關(guān)嘗試，通過(guò)DNN來(lái)學(xué)習(xí)用戶向量和帖子向量，并計(jì)算用戶最相近的topK個(gè)帖子做為召回源。

上述不同的召回算法都產(chǎn)生出了一部分推薦候選數(shù)據(jù)，我們需要將不同的召回?cái)?shù)據(jù)融合起來(lái)以提高候選集的多樣性和覆蓋率，這里我們主要使用兩種召回融合策略：

• 分級(jí)融合。設(shè)置一個(gè)候選集目標(biāo)數(shù)量值，然后按照效果好壞的次序選擇候選物品，直至滿足候選集大小。假設(shè)召回算法效果好壞的順序是A、B、C、D，則優(yōu)先從A中取數(shù)據(jù)，不足候選集目標(biāo)數(shù)量時(shí)則從B中取數(shù)據(jù)，依次類推。我們的系統(tǒng)支持分級(jí)融合策略的配置化，不同召回算法的先后順序可以靈活配置。這里的效果好壞順序是根據(jù)離線評(píng)價(jià)和線上評(píng)價(jià)來(lái)決定的，例如離線我們會(huì)比較不同召回算法的召回率和準(zhǔn)確率，線上我們會(huì)比較最終點(diǎn)擊或轉(zhuǎn)化數(shù)據(jù)中不同召回算法的覆蓋率。
• 調(diào)制融合。按照不同的比例分別從不同召回算法中取數(shù)據(jù)，然后疊加產(chǎn)生最終總的候選集。我們的系統(tǒng)也支持調(diào)制融合策略的配置化，選擇哪些召回算法、每種召回算法的選擇比例均可以靈活配置。這里的比例主要根據(jù)最終線上點(diǎn)擊或轉(zhuǎn)化數(shù)據(jù)中不同召回算法的覆蓋率來(lái)設(shè)置。

召回環(huán)節(jié)新召回源的添加或者新融合策略的上線，例如開(kāi)發(fā)了一種新召回算法、需要修改調(diào)制融合策略中的配比等，我們都會(huì)做線上ABTest，最終通過(guò)比較不同策略的效果來(lái)指導(dǎo)我們的迭代。值得一提的是，召回環(huán)節(jié)我們還會(huì)有一些過(guò)濾規(guī)則，例如過(guò)濾低質(zhì)量帖子、在某些特定場(chǎng)景下對(duì)召回算法產(chǎn)生的結(jié)果加一些條件限制等。

排序環(huán)節(jié)我們主要采用Pointwise方法，為每個(gè)帖子打分并進(jìn)行排序，通過(guò)使用機(jī)器學(xué)習(xí)模型預(yù)估帖子的點(diǎn)擊率、轉(zhuǎn)化率和停留時(shí)長(zhǎng)等多指標(biāo)來(lái)做排序。早期我們主要優(yōu)化點(diǎn)擊率，目前我們不僅關(guān)注點(diǎn)擊率外還會(huì)注重轉(zhuǎn)化率的提高。在58同城的產(chǎn)品場(chǎng)景中，轉(zhuǎn)化主要指用戶在帖子詳情頁(yè)上的微聊、打電話操作。

排序離線流程主要包括樣本生成和選擇、特征抽取、模型訓(xùn)練和評(píng)價(jià)。首先對(duì)埋點(diǎn)日志中的曝光、點(diǎn)擊、轉(zhuǎn)化和停留時(shí)長(zhǎng)等數(shù)據(jù)做抽取解析，如基于曝光序列號(hào)關(guān)聯(lián)各類操作、解析埋點(diǎn)參數(shù)（例如日志中記錄的實(shí)時(shí)特征）、解析上下文特征等，并同時(shí)打上label，生成模型樣本。然后對(duì)樣本進(jìn)行過(guò)濾，例如過(guò)濾惡意用戶樣本、過(guò)濾無(wú)效曝光樣本等。然后對(duì)樣本做特征抽取，生成帶特征的樣本，我們主要從用戶、帖子、發(fā)帖人和上下文四個(gè)維度做特征工程。之后，按照一定正負(fù)樣本比例做采樣，最終進(jìn)行模型訓(xùn)練和評(píng)估，離線評(píng)估指標(biāo)主要參考AUC，離線效果有提升后會(huì)進(jìn)行ABTest上線，逐步迭代。我們先后迭代上線了如下排序策略：

• 規(guī)則序。早期未上線機(jī)器學(xué)習(xí)模型時(shí)，對(duì)候選集中的帖子會(huì)直接使用刷新時(shí)間、統(tǒng)計(jì)CTR或者一些產(chǎn)品規(guī)則來(lái)做排序。
• 單機(jī)器學(xué)習(xí)模型。我們最早實(shí)踐的是LR模型，它是線性模型，簡(jiǎn)單高效、可解釋性好，但對(duì)特征工程要求較高，需要我們自己做特征組合來(lái)增強(qiáng)模型的非線性表達(dá)能力，早期我們使用LibLinear來(lái)訓(xùn)練模型，后來(lái)遷移到了Spark上。之后我們引入了XGBoost樹(shù)模型，它非線性表達(dá)能力強(qiáng)、高效穩(wěn)定，是目前開(kāi)源社區(qū)里最火熱的模型之一，最初我們采用單機(jī)版本訓(xùn)練，后期將XGBoost部署在我們的yarn集群上，使用分布式版本進(jìn)行訓(xùn)練。同時(shí)，我們應(yīng)用了FM模型，相比于LR模型它引進(jìn)了特征組合，能夠解決大規(guī)模稀疏數(shù)據(jù)下的特征組合問(wèn)題，我們主要使用分布式FM （DiFacto，F(xiàn)M on Yarn）來(lái)進(jìn)行模型訓(xùn)練。上述這些模型都是批量更新，通常是一天更新一次，為了快速捕捉用戶行為的變化，我們還引入Online Learning模型，主要嘗試應(yīng)用FTRL方式去更新LR模型，在某些場(chǎng)景下獲得了穩(wěn)定的效果提升。
• 融合模型。類似Facebook、Kaggle的做法，我們實(shí)踐了GBDT+LR和GBDT+FM的模型融合方案。首先利用XGBoost對(duì)原始特征做處理生成高階特征，然后輸入到LR和FM模型中，目前我們的點(diǎn)擊率預(yù)估模型中效果最佳的是GBDT+LR融合模型，轉(zhuǎn)化率預(yù)估模型中效果最佳的是GBDT+FM融合模型。此外，我們還會(huì)嘗試將某個(gè)單指標(biāo)（如點(diǎn)擊率）下多個(gè)模型的預(yù)測(cè)結(jié)果進(jìn)行融合（如相加或相乘等），也會(huì)將多個(gè)指標(biāo)（點(diǎn)擊率、轉(zhuǎn)化率和停留時(shí)長(zhǎng)）的模型進(jìn)行融合（如相乘）以觀察效果。
• 深度模型。深度學(xué)習(xí)正逐漸被各大公司應(yīng)用于推薦系統(tǒng)中，我們也正在進(jìn)行嘗試。目前，我們已將FNN（Factorisation machine supported neuralnetwork）模型應(yīng)用在我們的推薦排序中，相比單機(jī)器學(xué)習(xí)模型，F(xiàn)NN有較穩(wěn)定的效果提升，但比融合模型效果要稍差，目前我們正在進(jìn)行深度模型的調(diào)優(yōu)，并在嘗試引入Wide&Deep等其他深度模型。

基于上述基礎(chǔ)機(jī)器學(xué)習(xí)工具，目前我們主要會(huì)迭代點(diǎn)擊率、轉(zhuǎn)化率和停留時(shí)長(zhǎng)預(yù)估模型，線上會(huì)ABTest上線單指標(biāo)模型、多指標(biāo)融合模型，以提高推薦效果。

架構(gòu)

對(duì)于推薦系統(tǒng)來(lái)說(shuō)，一套支撐算法策略高效迭代的推薦后臺(tái)系統(tǒng)至關(guān)重要，我們基于微服務(wù)架構(gòu)設(shè)計(jì)了推薦后臺(tái)系統(tǒng)，它擴(kuò)展性好、性能高，系統(tǒng)架構(gòu)如下圖所示，系統(tǒng)分為數(shù)據(jù)層、邏輯層和接入層，數(shù)據(jù)層提供各類基礎(chǔ)數(shù)據(jù)的讀取，邏輯層實(shí)現(xiàn)召回和排序策略并支持不同策略的ABTest，接入層對(duì)外提供了通用的訪問(wèn)接口。

數(shù)據(jù)層提供推薦邏輯所需要的各類數(shù)據(jù)，這些數(shù)據(jù)存儲(chǔ)在WRedis、文件、WTable等多種設(shè)備上，我們將所有數(shù)據(jù)的讀取都封裝成RPC服務(wù)，屏蔽了底層的存儲(chǔ)細(xì)節(jié)。這里包括檢索服務(wù)、召回源讀取服務(wù)、帖子特征中心和用戶特征中心：

• 檢索服務(wù)。我們搭建了一套搜索引擎用做召回檢索，支持基于各類搜索條件去檢索數(shù)據(jù)，例如可以檢索出價(jià)格在200萬(wàn)至300萬(wàn)之間的回龍觀兩室的房源、檢索出中關(guān)村附近的最新房源。該服務(wù)主要應(yīng)用于這幾類場(chǎng)景：在猜你喜歡推薦場(chǎng)景中基于用戶標(biāo)簽去檢索帖子、在相關(guān)推薦場(chǎng)景中基于當(dāng)前帖子屬性去檢索相關(guān)帖子、冷啟動(dòng)時(shí)基于地域信息召回附近的帖子等。
• 召回源讀取服務(wù)。提供各類召回源數(shù)據(jù)的讀取，這些召回源數(shù)據(jù)通過(guò)離線或?qū)崟r(shí)計(jì)算得到，包括熱門數(shù)據(jù)、協(xié)同過(guò)濾數(shù)據(jù)、關(guān)聯(lián)規(guī)則數(shù)據(jù)、矩陣分解結(jié)果等。該服務(wù)設(shè)計(jì)得較靈活，支持任意召回源的增加。
• 帖子特征中心。提供帖子所有屬性字段的讀取，在召回、排序和推薦主體邏輯中會(huì)使用到這些帖子屬性，一般情況我們會(huì)在召回環(huán)節(jié)讀取出所有帖子屬性，然后應(yīng)用于排序和規(guī)則邏輯中。召回得到的候選集大小一般是幾十到幾百，為了支持高性能的批量讀取，我們選擇使用WRedis集群存儲(chǔ)帖子屬性，并通過(guò)多線程并發(fā)讀取、緩存、JVM調(diào)優(yōu)等多項(xiàng)技術(shù)保證服務(wù)性能。目前，該服務(wù)每天承接數(shù)億級(jí)請(qǐng)求，平均每次讀取150條數(shù)據(jù)，耗時(shí)保證在2ms之內(nèi)。
• 用戶特征中心。UserProfile數(shù)據(jù)包括用戶離線/實(shí)時(shí)興趣標(biāo)簽、人口屬性等，該數(shù)據(jù)會(huì)在召回環(huán)節(jié)使用，例如使用用戶興趣標(biāo)簽去檢索帖子作為一種召回源，也會(huì)在排序環(huán)節(jié)使用，例如將用戶標(biāo)簽作為機(jī)器學(xué)習(xí)排序模型的特征。

邏輯層實(shí)現(xiàn)了詳細(xì)的推薦策略，包括推薦主體服務(wù)、召回服務(wù)、排序服務(wù)和ABTest實(shí)驗(yàn)中心。這些服務(wù)由不同的開(kāi)發(fā)人員維護(hù)，保證了推薦策略的高效迭代，例如召回和排序是我們經(jīng)常迭代的環(huán)節(jié)，由不同的算法人員來(lái)完成，召回服務(wù)和排序服務(wù)的分離降低了耦合，提高了迭代效率。

• 推薦主體服務(wù)。接收推薦請(qǐng)求，解析推薦場(chǎng)景參數(shù)，調(diào)用用戶特征中心獲取用戶信息，請(qǐng)求ABTest實(shí)驗(yàn)中心獲取對(duì)應(yīng)場(chǎng)景的ABTest實(shí)驗(yàn)參數(shù)，如召回策略號(hào)、排序算法號(hào)、規(guī)則號(hào)和展示號(hào)。然后將推薦場(chǎng)景參數(shù)、ABTest實(shí)驗(yàn)參數(shù)等發(fā)送至召回服務(wù)獲得候選集列表，之后再調(diào)用排序服務(wù)對(duì)候選集進(jìn)行排序，最終對(duì)排序列表做相關(guān)規(guī)則處理，將結(jié)果列表封裝返回。
• 召回服務(wù)。接收?qǐng)鼍皡?shù)和召回策略號(hào)參數(shù)，調(diào)用檢索服務(wù)和召回源讀取服務(wù)讀取各類召回?cái)?shù)據(jù)，并進(jìn)行分級(jí)融合或調(diào)制融合。我們實(shí)現(xiàn)了召回策略的配置化，一個(gè)召回號(hào)對(duì)應(yīng)一種召回策略，策略采用哪種融合方式、每種融合方式下包含哪些召回源、不同召回源的數(shù)量均通過(guò)配置來(lái)完成。我們將召回配置進(jìn)行Web化，算法或產(chǎn)品人員只需在Web頁(yè)面上配置即可生效策略。此外，召回層還包括一些過(guò)濾規(guī)則，例如過(guò)濾低質(zhì)量信息、過(guò)濾用戶歷史瀏覽記錄、過(guò)濾產(chǎn)品指定的符合某些特定條件的數(shù)據(jù)等。
• 排序服務(wù)。接收?qǐng)鼍皡?shù)、用戶信息、候選集列表和排序算法號(hào)等參數(shù)，調(diào)用機(jī)器學(xué)習(xí)排序模塊，對(duì)候選集列表做排序。我們?cè)O(shè)計(jì)了一套通用的特征提取框架，保證機(jī)器學(xué)習(xí)離線模型訓(xùn)練和線上排序共用相同的特征提取代碼，并靈活支持不同模型之間的特征共享。在排序服務(wù)中上線一種模型成本很低，只需要提供模型文件和特征配置文件即可，后續(xù)我們將會(huì)對(duì)排序配置進(jìn)行Web化，簡(jiǎn)化上線流程。目前，我們的排序服務(wù)中運(yùn)行了基于LR、XGBoost、FM、XGBoost+LR、XGBoost+FM、DNN的幾十個(gè)排序模型。
• ABTest實(shí)驗(yàn)中心。我們?cè)O(shè)計(jì)了一套靈活通用的ABTest實(shí)驗(yàn)平臺(tái)（內(nèi)部稱作“日晷”）來(lái)支持推薦系統(tǒng)的策略迭代，它包括流量控制、實(shí)時(shí)效果數(shù)據(jù)統(tǒng)計(jì)和可視化等功能，支持用戶在Web頁(yè)面上配置實(shí)驗(yàn)和流量，并能展示實(shí)時(shí)效果數(shù)據(jù)。這套實(shí)驗(yàn)平臺(tái)不僅可以應(yīng)用于推薦系統(tǒng)，還可以用于任何其它需要做ABTest實(shí)驗(yàn)的業(yè)務(wù)系統(tǒng)中，它支持多層ABTest實(shí)驗(yàn)，能充分利用每份流量去完成業(yè)務(wù)迭代。例如我們的推薦系統(tǒng)ABTest實(shí)驗(yàn)就包含召回、排序、規(guī)則和展示四層，不同層之間實(shí)現(xiàn)了流量的重新打散，保證了不同層之間實(shí)驗(yàn)的正交性。當(dāng)請(qǐng)求到達(dá)我們的推薦系統(tǒng)時(shí)，推薦主體服務(wù)便請(qǐng)求“日晷”以獲得該請(qǐng)求對(duì)應(yīng)的召回號(hào)、排序號(hào)、規(guī)則號(hào)和展示號(hào)等實(shí)驗(yàn)參數(shù)，之后該請(qǐng)求便會(huì)被這些實(shí)驗(yàn)參數(shù)打上標(biāo)記，貫穿于后續(xù)的推薦流程，決定每層中將走哪部分邏輯，最終這些實(shí)驗(yàn)參數(shù)會(huì)記錄到后臺(tái)和客戶端埋點(diǎn)日志中，用于最終的實(shí)驗(yàn)效果統(tǒng)計(jì)。

接入層直接和客戶端交互，從客戶端接收請(qǐng)求并調(diào)用推薦主體服務(wù)獲得推薦帖子id列表，然后查詢出帖子詳細(xì)屬性返回給客戶端做展示。在大部分推薦場(chǎng)景中，接入層由業(yè)務(wù)方維護(hù)，可能是PHP或Java實(shí)現(xiàn)的http接口；也有少部分場(chǎng)景的接入層是我們自主維護(hù)，我們采用58自研的MVC框架WF實(shí)現(xiàn)了相關(guān)http接口。

我們采用58自研的RPC框架SCF實(shí)現(xiàn)了上述微服務(wù)架構(gòu)的推薦系統(tǒng)，采用58自研的監(jiān)控系統(tǒng)WMonitor實(shí)現(xiàn)了推薦系統(tǒng)的立體監(jiān)控，整個(gè)技術(shù)棧是Java。我們采用多線程、異步、緩存、JVM調(diào)優(yōu)、降級(jí)、限流等措施保證了推薦系統(tǒng)的穩(wěn)定和高可用，目前我們的推薦系統(tǒng)日均處理數(shù)億的推薦請(qǐng)求，平均耗時(shí)約30毫秒。

數(shù)據(jù)

這里的數(shù)據(jù)主要指推薦埋點(diǎn)數(shù)據(jù)和推薦效果數(shù)據(jù)：埋點(diǎn)數(shù)據(jù)是推薦系統(tǒng)的基石，模型訓(xùn)練和效果數(shù)據(jù)統(tǒng)計(jì)都基于埋點(diǎn)數(shù)據(jù)，需保證埋點(diǎn)數(shù)據(jù)的正確無(wú)誤；效果數(shù)據(jù)是對(duì)推薦系統(tǒng)的評(píng)價(jià)，指引推薦策略的迭代，構(gòu)建完備的效果數(shù)據(jù)體系至關(guān)重要。

我們的推薦埋點(diǎn)日志數(shù)據(jù)包括曝光日志、點(diǎn)擊日志、轉(zhuǎn)化日志和頁(yè)面停留時(shí)長(zhǎng)日志等，這些日志數(shù)據(jù)都需要客戶端通過(guò)埋點(diǎn)來(lái)產(chǎn)生。這里簡(jiǎn)單解釋一下這些操作的含義：客戶端請(qǐng)求一次推薦接口得到推薦結(jié)果列表叫做一次曝光；用戶點(diǎn)擊推薦結(jié)果列表上的某條帖子進(jìn)入帖子詳情頁(yè)叫做一次點(diǎn)擊；用戶在帖子詳情頁(yè)上進(jìn)行微聊、打電話、收藏等操作叫做轉(zhuǎn)化；用戶在帖子詳情頁(yè)上的閱讀時(shí)間叫做頁(yè)面停留時(shí)長(zhǎng)。這里的曝光、點(diǎn)擊和轉(zhuǎn)化是一個(gè)漏斗，操作數(shù)量是逐漸遞減的趨勢(shì)。由于58同城上用戶對(duì)帖子的訪問(wèn)可能來(lái)源于推薦、搜索和運(yùn)營(yíng)活動(dòng)頁(yè)等場(chǎng)景，為了標(biāo)識(shí)出推薦產(chǎn)生的點(diǎn)擊/轉(zhuǎn)化/停留時(shí)長(zhǎng)，我們需要在埋點(diǎn)中加入推薦相關(guān)的參數(shù)。我們將埋點(diǎn)參數(shù)設(shè)計(jì)成一個(gè)固定格式的字符串，它包含了曝光唯一序列號(hào)、推薦位標(biāo)識(shí)、召回號(hào)、排序號(hào)、規(guī)則號(hào)、展示號(hào)、帖子id列表、帖子id等字段，這些字段將會(huì)作用于機(jī)器學(xué)習(xí)模型訓(xùn)練樣本生成和推薦效果統(tǒng)計(jì)中。埋點(diǎn)參數(shù)主要分為列表參數(shù)和單貼參數(shù)兩類：推薦接口返回一個(gè)帖子列表，會(huì)對(duì)應(yīng)返回一個(gè)列表參數(shù)，包含了曝光序列號(hào)、推薦位標(biāo)識(shí)、召回號(hào)、排序號(hào)、規(guī)則號(hào)、展示號(hào)、帖子id列表等字段；返回的帖子列表中，每個(gè)帖子會(huì)對(duì)應(yīng)返回一個(gè)單貼參數(shù)，包含曝光序列號(hào)、推薦位標(biāo)識(shí)、召回號(hào)、排序號(hào)、規(guī)則號(hào)、展示號(hào)、帖子id等字段?？蛻舳说玫酵扑]接口返回的埋點(diǎn)參數(shù)后，會(huì)將列表參數(shù)埋入到曝光日志中，將單貼參數(shù)埋入到點(diǎn)擊日志、轉(zhuǎn)化日志和停留時(shí)長(zhǎng)日志當(dāng)中，注意這里埋點(diǎn)時(shí)需要推薦列表頁(yè)向帖子詳情頁(yè)傳遞單貼參數(shù)，一般需要通過(guò)修改跳轉(zhuǎn)協(xié)議來(lái)實(shí)現(xiàn)。最終埋點(diǎn)日志中有了這些參數(shù)后，我們便可基于曝光唯一序列號(hào)將曝光、點(diǎn)擊、轉(zhuǎn)化、時(shí)長(zhǎng)數(shù)據(jù)join起來(lái)，產(chǎn)生模型訓(xùn)練樣本以及漏斗效果數(shù)據(jù)。值得一提的是，我們采取透?jìng)鞯姆绞皆谕扑]后臺(tái)、接入層、客戶端間傳遞埋點(diǎn)參數(shù)字符串，所有埋點(diǎn)參數(shù)由推薦系統(tǒng)后臺(tái)生成，接入層和客戶端均不做任何處理。埋點(diǎn)參數(shù)僅由我們推薦一方負(fù)責(zé)，這樣能夠避免多方改動(dòng)埋點(diǎn)參數(shù)，從而減少埋點(diǎn)錯(cuò)誤的可能性，由于是透?jìng)魈幚?，也便于今后埋點(diǎn)參數(shù)的擴(kuò)展。

埋點(diǎn)數(shù)據(jù)是推薦系統(tǒng)的基石，不能有遺漏或者錯(cuò)誤，這就要求我們嚴(yán)格把控開(kāi)發(fā)測(cè)試流程，尤其是APP上的埋點(diǎn)，若發(fā)版之后發(fā)現(xiàn)有錯(cuò)誤，便要等到下一次發(fā)版時(shí)解決?？蛻舳碎_(kāi)發(fā)和測(cè)試同事不清楚埋點(diǎn)參數(shù)的含義但熟練掌握測(cè)試環(huán)境部署及擁有Android和IOS測(cè)試機(jī)，而推薦后臺(tái)同事清楚埋點(diǎn)參數(shù)含義但對(duì)測(cè)試環(huán)境較生疏并缺乏測(cè)試機(jī)，因此我們總結(jié)出了測(cè)試同事負(fù)責(zé)環(huán)境部署、推薦后臺(tái)同事負(fù)責(zé)檢驗(yàn)埋點(diǎn)參數(shù)的測(cè)試流程，詳細(xì)流程如下圖所示。此外，58同城上的APP開(kāi)發(fā)比較復(fù)雜，不同產(chǎn)品線各自開(kāi)發(fā)自己的APP業(yè)務(wù)模塊，APP平臺(tái)方開(kāi)發(fā)主模塊，每次發(fā)版前都有一個(gè)集成階段，合并所有業(yè)務(wù)方提交的代碼，產(chǎn)生最終的APP包，集成階段很可能會(huì)發(fā)生業(yè)務(wù)方埋點(diǎn)未生效的情況。因此，我們的埋點(diǎn)測(cè)試包括業(yè)務(wù)方內(nèi)部測(cè)試和集成測(cè)試兩個(gè)階段，以保證埋點(diǎn)萬(wàn)無(wú)一失。

我們的推薦效果數(shù)據(jù)是一個(gè)多維數(shù)據(jù)集，我們主要關(guān)注推薦位上的點(diǎn)擊、轉(zhuǎn)化、停留時(shí)長(zhǎng)等指標(biāo)。日常工作中我們需要從不同業(yè)務(wù)線、不同客戶端、不同推薦位、不同推薦算法等多個(gè)維度去分析這些指標(biāo)數(shù)據(jù)，例如我們會(huì)觀察房產(chǎn)和車在相同推薦位上的數(shù)據(jù)對(duì)比、猜你喜歡場(chǎng)景上不同召回或排序算法的數(shù)據(jù)對(duì)比、二手房詳情頁(yè)在Android和IPhone上數(shù)據(jù)對(duì)比等。各種數(shù)據(jù)分析對(duì)比能幫助我們優(yōu)化推薦策略，甚至能發(fā)現(xiàn)某些業(yè)務(wù)線功能邏輯上的隱藏BUG，例如在我們推薦項(xiàng)目攻堅(jiān)階段，我們通過(guò)分析比較二手房詳情頁(yè)在Android和IPhone兩端的推薦效果，發(fā)現(xiàn)了IPhone上詳情頁(yè)瀏覽回退的BUG，最終反饋給業(yè)務(wù)方并解決了該問(wèn)題，該BUG的解決使得我們?cè)诙址吭斍轫?yè)推薦位上的推薦點(diǎn)擊量提高了數(shù)十萬(wàn)。

我們從離線和實(shí)時(shí)兩方面構(gòu)建推薦效果數(shù)據(jù)，數(shù)據(jù)統(tǒng)計(jì)流程如下圖所示：

早期，離線效果數(shù)據(jù)統(tǒng)計(jì)是通過(guò) MapReduce + Hive + MySQL 來(lái)實(shí)現(xiàn)的，我們首先會(huì)編寫MapReduce程序?qū)υ悸顸c(diǎn)日志進(jìn)行抽取生成Hive表，然后會(huì)編寫大量的Hive SQL來(lái)統(tǒng)計(jì)各類指標(biāo)數(shù)據(jù)，并將結(jié)果數(shù)據(jù)寫入MySQL數(shù)據(jù)表，最終做可視化展示和郵件報(bào)表。由于我們比較的維度和指標(biāo)多，Hive SQL語(yǔ)句的編寫消耗了我們不少人力。在數(shù)據(jù)平臺(tái)部門部署了Kylin多維分析系統(tǒng)后，我們將效果數(shù)據(jù)統(tǒng)計(jì)工作遷移到了Kylin上，我們只需要設(shè)計(jì)好Hive源數(shù)據(jù)表，并設(shè)置好維度和度量，Kylin便能根據(jù)維度和度量來(lái)自動(dòng)預(yù)計(jì)算結(jié)果數(shù)據(jù)，這省去了我們編寫Hive SQL的工作，大大提高了效率。關(guān)于如何利用Kylin構(gòu)建多維數(shù)據(jù)集可以參考此文《基于Kylin的推薦系統(tǒng)效果評(píng)價(jià)系統(tǒng)》。

實(shí)時(shí)效果數(shù)據(jù)我們采用Storm + HBase 來(lái)計(jì)算，實(shí)時(shí)效果數(shù)據(jù)主要用于異常埋點(diǎn)監(jiān)控、新上線推薦算法效果快速反饋、模型異常監(jiān)控等，我們實(shí)現(xiàn)了一個(gè)包含較少維度的多維數(shù)據(jù)統(tǒng)計(jì)，今后我們將嘗試引入Druid等實(shí)時(shí)多維分析系統(tǒng)來(lái)完善推薦實(shí)時(shí)效果數(shù)據(jù)的建設(shè)。

總結(jié)

本文介紹了58同城智能推薦系統(tǒng)在算法、工程和數(shù)據(jù)三方面的技術(shù)演進(jìn)。我們?cè)谧罱荒昙涌炝送扑]業(yè)務(wù)的迭代速度，接入了房產(chǎn)、車等業(yè)務(wù)線在APP、PC、M三端共計(jì)近百個(gè)推薦位，我們的推薦點(diǎn)擊占比指標(biāo)（推薦位上產(chǎn)生的點(diǎn)擊量在總體點(diǎn)擊量中的占比）相比一年之前提高了2~3倍，達(dá)到了20%~30%，每天能夠產(chǎn)生數(shù)千萬(wàn)的推薦點(diǎn)擊量，為業(yè)務(wù)線帶來(lái)了流量提升。

任何推薦系統(tǒng)的發(fā)展必會(huì)經(jīng)歷推薦位擴(kuò)充和推薦算法深入優(yōu)化兩個(gè)階段，流量指標(biāo)可以通過(guò)擴(kuò)充推薦位來(lái)快速提高，當(dāng)推薦位穩(wěn)定之后，就需要依賴更加深入的算法優(yōu)化來(lái)繼續(xù)提高指標(biāo)，而此時(shí)的效果提升也會(huì)相對(duì)緩慢。目前，我們的流量指標(biāo)已相對(duì)穩(wěn)定，我們會(huì)更進(jìn)一層去關(guān)注轉(zhuǎn)化指標(biāo)，提高用戶進(jìn)入帖子之后與發(fā)帖人進(jìn)行微聊或電話溝通的可能性，幫助用戶找到真正有用的信息。