背景

閑魚作為一個(gè)電商場(chǎng)景的app，最豐富的部分就是作為商品寶貝瀏覽承載的feeds，比如首頁(yè)下面的寶貝信息流，搜索結(jié)果頁(yè)以及詳情頁(yè)下面的猜你喜歡，這些feeds場(chǎng)景都少不了推薦算法在背后的支撐。

傳統(tǒng)的推薦算法是依托于云上沉淀的埋點(diǎn)數(shù)據(jù)來。隨著4G網(wǎng)絡(luò)資費(fèi)的下降，產(chǎn)生了越來越多的數(shù)據(jù)，如果將如此大量的數(shù)據(jù)都上傳到運(yùn)算，并且由云端來做中心化的存儲(chǔ)/計(jì)算和處理，不僅會(huì)產(chǎn)生大量無必要的網(wǎng)絡(luò)流量，而且還會(huì)給云端帶來高昂的存儲(chǔ)成本，實(shí)時(shí)性也無法保證。

我們觀察到隨著手機(jī)計(jì)算能力的提升，某些計(jì)算可以在端上直接計(jì)算，再統(tǒng)一上報(bào)到后端，這樣相比云計(jì)算有很多明顯的優(yōu)勢(shì)：

1、更加實(shí)時(shí)性：我們可以在端上完成原始特征的處理和實(shí)時(shí)打分，從原始特征的抽取到計(jì)算結(jié)果的上報(bào)完成，可以在1s左右完成。

2、計(jì)算資源的節(jié)約：大量數(shù)據(jù)如果都匯集到云端上計(jì)算，可能會(huì)造成計(jì)算資源的不足，我們可以將計(jì)算量分散到各個(gè)端上，可以降低計(jì)算資源開銷。

3、多維度數(shù)據(jù)采集：一些類似于細(xì)粒度的行為數(shù)據(jù)、采集頻率過高的數(shù)據(jù)或者涉及用戶隱私的數(shù)據(jù)等，可以在端上直接消費(fèi)掉而不需要上傳。

馬里奧

介紹

馬里奧是閑魚首頁(yè)的一個(gè)創(chuàng)新形式的業(yè)務(wù)，其業(yè)務(wù)邏輯是：用戶在閑魚首頁(yè)feeds部分點(diǎn)擊來一個(gè)寶貝卡片，那么同時(shí)就會(huì)請(qǐng)求云端，根據(jù)后端算法拉取回來算法召回的query詞和對(duì)應(yīng)的推薦寶貝信息，以四個(gè)方塊的形式展示在一個(gè)張卡片中，這樣來給用戶點(diǎn)擊之后，跳到二級(jí)承接頁(yè)面來給用戶推薦更相關(guān)的寶貝，來達(dá)到提升首頁(yè)feeds部分點(diǎn)擊率和成交的效果。

效果圖:

初始版本流程圖:

問題

初始上線之后，我們統(tǒng)計(jì)馬里奧卡片一跳和二跳的ctr，發(fā)現(xiàn)并比不上普通的寶貝，那么問題出在了哪里呢？

分析

閑魚上每天都會(huì)誕生數(shù)以億計(jì)的商品點(diǎn)擊，這里有個(gè)很自然的問題：用戶對(duì)他的這次商品點(diǎn)擊滿意嗎？考慮兩個(gè)簡(jiǎn)單的例子：

1）用戶點(diǎn)擊商品后，在詳情頁(yè)面上停留時(shí)間很短，那么我們可以認(rèn)為這可能是次誤點(diǎn)擊。

2）用戶點(diǎn)擊商品后，他在這個(gè)詳情頁(yè)面上有很多的行為，比如他可能查看了產(chǎn)品參數(shù)、商品的顏色尺碼、或者又點(diǎn)擊了該商品的全部評(píng)價(jià)，最后還通過和賣家進(jìn)行了聊天，那么我們就認(rèn)為這可能是次真實(shí)意愿的點(diǎn)擊，或者說他對(duì)這次點(diǎn)擊滿意度分很高。

那么很自然的，我們推測(cè)，只有在滿意度較高的情況下，我們?nèi)プ鲫P(guān)聯(lián)推薦才是有意義和有價(jià)值的，否則如果用戶誤點(diǎn)擊的情況，我們也去推薦，只會(huì)適得其反，對(duì)此我們進(jìn)行了解法的嘗試。

解法

在這個(gè)場(chǎng)景下，需要在用戶點(diǎn)擊進(jìn)入寶貝詳情，然后離開詳情頁(yè)的時(shí)候，就需要給出用戶對(duì)該寶貝的意向，只有滿足某個(gè)閾值的情況，才應(yīng)該出現(xiàn)馬里奧卡片。這種場(chǎng)景下，如果使用傳統(tǒng)的云端算法，把數(shù)據(jù)都收集好，再計(jì)算出結(jié)果，再返回到端上，這時(shí)候很可能插入卡片的時(shí)機(jī)早就過去了，沒法抓到用戶這個(gè)關(guān)鍵點(diǎn)。因?yàn)橛脩粼跒g覽詳情頁(yè)的過程中，所有的點(diǎn)擊和曝光都是在端上實(shí)時(shí)產(chǎn)生的，很可能在最后一刻退出頁(yè)面之前，用戶都在一直產(chǎn)生有價(jià)值的動(dòng)作，這時(shí)候不斷的往云端回傳數(shù)據(jù)再計(jì)算，顯然是不可行的方案。

當(dāng)用戶在閑魚Feeds頁(yè)點(diǎn)擊推薦商品（如上面左圖的汽車玩具商品）后，進(jìn)行觸發(fā)并展現(xiàn)馬里奧（如上面左圖虛線紅框所示），引導(dǎo)用戶進(jìn)行搜索并進(jìn)行更多商品點(diǎn)擊和下單。不同于Feeds里一般的推薦項(xiàng)，馬里奧的每一次觸發(fā)其實(shí)是存在觸發(fā)成本的。一個(gè)顯然的成本是馬里奧的觸發(fā)會(huì)擠占后續(xù)商品的展現(xiàn)。如果用戶每一次詳情頁(yè)點(diǎn)擊后都觸發(fā)馬里奧，那么就會(huì)有大量的馬里奧被展現(xiàn)，并擠占相應(yīng)的Feeds坑位。當(dāng)馬里奧點(diǎn)擊率相比Feeds過低的時(shí)候，將影響整體Feeds的展現(xiàn)效率及用戶體驗(yàn)。

解法流程圖:

因而在推薦流和搜索結(jié)果流中，觸發(fā)型展現(xiàn)一個(gè)顯而易見的成本是，當(dāng)前觸發(fā)的內(nèi)容展現(xiàn)會(huì)壓縮后續(xù)推薦的內(nèi)容展現(xiàn)。從更高效的流量分發(fā)角度來看，對(duì)這類展現(xiàn)的控制是有必要性的。

不同于此前純?cè)贫说挠|發(fā)展現(xiàn)，云端此前更多做內(nèi)容側(cè)的控制，基于用戶與內(nèi)容的匹配程度去決策是否展現(xiàn)以及展現(xiàn)什么。而端側(cè)用戶更加實(shí)時(shí)、更加詳細(xì)、更加細(xì)粒度的行為，更偏好與刻畫用戶交互習(xí)慣以及對(duì)當(dāng)前觸發(fā)模塊的需求。

為此，我們提出了智能展現(xiàn)模型，通過用戶在端側(cè)的細(xì)粒度交互行為建模用戶對(duì)觸發(fā)模塊的實(shí)時(shí)偏好，將原始的觸發(fā)展現(xiàn)模塊解藕為兩部分:

1、CTR(端):端側(cè)做展現(xiàn)控制：基于用戶當(dāng)下細(xì)粒度交互行為及交互習(xí)慣決定是否請(qǐng)求（展現(xiàn)）相關(guān)模塊

2、CTR(云):云側(cè)做內(nèi)容控制：決定展現(xiàn)的相關(guān)內(nèi)容

所以我們最終采用端計(jì)算和云計(jì)算結(jié)合的方案，所有依賴數(shù)據(jù)都實(shí)時(shí)在端上產(chǎn)生，而且計(jì)算處理數(shù)據(jù)的過程也在端上，借助于集團(tuán)提供的端計(jì)算容器，我們可以很方便的把模型部署到端上并運(yùn)行它得到我們用戶點(diǎn)擊之后對(duì)點(diǎn)擊寶貝的滿意度的數(shù)值。

結(jié)果

新的馬里奧方案，對(duì)整個(gè)鏈路和現(xiàn)有體系是最小侵入，也讓整體更加簡(jiǎn)潔。閑魚馬里奧項(xiàng)目上，智能展現(xiàn)模型在保證94.4%的馬里奧點(diǎn)擊量和96%的二跳點(diǎn)擊量下，馬里奧服務(wù)端請(qǐng)求量減少了-28.0%，點(diǎn)擊率提升+31.1%，成交率增長(zhǎng)了10%。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的闲鱼如何利用端计算提升推荐场景的ctr的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。