“實時推薦”為什么在長視頻推薦領域碰壁了?

5 評論 10333 瀏覽 18 收藏 12 分鐘

編輯導讀:為什么短視頻如此讓人上癮?其中很大一部分原因是實時推薦的功勞。通過消費用戶在最近的幾分鐘內(nèi)或者一段時間內(nèi)瀏覽的內(nèi)容偏好,形成對該用戶的一個短暫的認知,再通過這個認知趕緊去內(nèi)容池中找到對應的內(nèi)容推薦給用戶。然而,這個功能在長視頻領域中卻屢屢碰壁,這是為什么呢?

高實時推薦一般在短視頻領域使用比較廣泛,指的是算法模型通過消費用戶在最近的幾分鐘內(nèi)或者一段時間內(nèi)瀏覽的內(nèi)容偏好,形成對該用戶的一個短暫的認知,再通過這個認知趕緊去內(nèi)容池中找到對應的內(nèi)容推薦給用戶。這個系統(tǒng)反饋的時間也許是我上面提到的幾分鐘,或者是幾十秒。

而與之對應的就是T+1的更新,T+1更新其實就是前一天推薦系統(tǒng)根據(jù)用戶歷史行為為每一個用戶計算好了一個推薦隊列放著,當用戶開機后,客戶端主動去請求這部分數(shù)據(jù),將內(nèi)容推給用戶。這部分數(shù)據(jù)一天內(nèi)都是不會更新的。

在項目實現(xiàn)過程中,我們發(fā)現(xiàn)高實時推薦的CTR較T+1推薦CTR提升很多,于是大家開始慶祝,這個項目有效果,CTR提升很多!

但是,當我們深入去想的話,在很高的CTR背后,是用戶在干什么呢?試想一下,假如他找到了自己的喜歡的電影,安安靜靜坐那兒看了,用戶還需要不斷地刷新頁面,讓客戶端不斷去請求算法,算法再去執(zhí)行召回-排序-去重-打散等等策略,占用服務器性能去為用戶推送內(nèi)容,然后用戶不厭其煩點擊,返回,點擊,返回。

高實時只不過將這一歷程從原來T+1更新的N天變成了N分鐘。

高CTR在這里,就似乎成了一個應試指標。成了像是一種政治正確的產(chǎn)物,是推薦系統(tǒng)對結(jié)果的不自信產(chǎn)生的一個額外的替補策略,但他又是必要的—為了項目最終數(shù)據(jù)效果好看,我們編制了一個美麗的謊言。為什么說是美麗的謊言呢?

一、決策路徑不適用

和短視頻不一樣的是,用戶決定是否看一部電影和決定是不是看一個短視頻的路徑是不一樣的。短視頻中,用戶決定看或者不看,根據(jù)抖音短視頻的一份報告,決策點通常在第5秒,用戶通過判斷前5秒的信息而決定手指是不是要向上滑動,對于推薦系統(tǒng)來說,去嘗試實驗的成本是低廉的,用戶決策的成本也十分低廉,于是,推薦算法完全可以指定feed流的刷新機制設置在用戶決定了看了幾部視頻、 跳過了幾部視頻之后,甚至,我們可以設定給不同的模型的用戶以不同的刷新機制–有的用戶興趣較多且隨時間、環(huán)境、熱點事件變動,有的用戶興趣單一受時間影響較少,這就對推薦模型和策略產(chǎn)品經(jīng)理有了更高的要求了。

而用戶要看一部長視頻,不論是電視劇,還是電影,還是綜藝,他們的決策路徑可能是這樣的,要先了解,再查看,有可能再試看,或者搜索一下。用戶總面對自己即將付出可預見時間代價的事情的決策路徑,一般呈現(xiàn)線性函數(shù)遞增關系,即預期支付成本越高、決策周期越長。以我自己為例,我通常選片的路徑-先看看熱門影片top榜單有沒有自己喜歡的,在看看新片電影有沒有喜歡的,最后實在沒有再去看看分類入口找找有沒有。

這樣來看的話,高實時推薦的CTR的提升似乎是必然的結(jié)果,為什么這么說?

二、CTR提升是必然結(jié)果

CTR的計算方式是點擊/曝光,T+1頻次的曝光和高實時的曝光場景下每個內(nèi)容平均曝光次數(shù)為N1和N2,而T+1時間內(nèi)某個頁面的內(nèi)容曝光總次數(shù)為M,曝光總內(nèi)容數(shù)為X,我們假設用戶對某一個內(nèi)容點擊每次曝光時概率不變,為Z,這大概率也是不會變的。

CTR=N*X*Z/M,有了這些變量之后因素影響之后,我們再去看看用戶看每個頁面的停留時間。假設用戶在頁面停留時間一致,這大概率也是一致的,即整個頁面內(nèi)容曝光的總次數(shù)M不變,平均每個內(nèi)容每次曝光被點擊的概率Z不變,變動的只有N和X。

這樣看來,用戶在原有推薦邏輯較低的CTR可能只是被強行瀏覽了自己不想要看到的內(nèi)容而且不能刷新只能反復上下操作遙控器找片,單影片曝光次數(shù)N值增加了,這樣的無效曝光被系統(tǒng)抓取,而高CTR可能是用戶發(fā)現(xiàn)了內(nèi)容可以刷新之后,就在這樣的一個頁面開始了找片之旅,曝光的內(nèi)容基數(shù)變大了,但內(nèi)容平均曝光次數(shù)降為了1。

原來推薦20個內(nèi)容可能只能有2個內(nèi)容是用戶愿意點擊的,但這20個內(nèi)容確因為刷新機制同樣獲取M次數(shù)的曝光,確只獲取了2個點擊;而高實時推薦確在M次數(shù)的曝光前提下,為用戶推薦了60個內(nèi)容,其中確有6個內(nèi)容是用戶愿意點擊的。

堆內(nèi)容數(shù)量?這是推薦系統(tǒng)最擅長的事情,推薦系統(tǒng)利用高實時的優(yōu)勢,在單位時間內(nèi)為用戶推薦了多倍于X1場景的內(nèi)容數(shù),其實每次刷新召回的內(nèi)容用戶感興趣的還是那么多,這么來看的話,CTR自然而然會升高了。

簡而言之,就是我們在有限的曝光次數(shù)里,推了更多的內(nèi)容給用戶,將那些無效的曝光分給了更多的內(nèi)容,這才使得CTR提高了。但其實我們推送單位數(shù)量內(nèi)容的有效內(nèi)容率都是一樣的。當然,這也只是我基于計算公式假設得出來的結(jié)果,其中設置M不變多少也是不十分科學的,但這樣的公式卻可以大體說明高實時推薦所帶來CTR提升的背后原因是什么。

三、不考慮內(nèi)容遍歷、場景適配的性能堆砌

長視頻和短視頻最核心的其中一個區(qū)別在于內(nèi)容池數(shù)量的問題,短視頻領域因為UGC的屬性,可以不斷生產(chǎn)內(nèi)容,而長視頻沒有這個優(yōu)勢,一個大型廠商電影電視劇的內(nèi)容數(shù)量一定是有限的,而且有長尾效應的限制,用戶所消費的內(nèi)容更加少之又少。

高實時推薦更加適用于短視頻領域的原因也有其中,場景變化更多的、內(nèi)容量更多,他保證了一個給一個用推薦的內(nèi)容永遠不會高度重復,可以為他們在公車上看跑車、廁所里看段子、家里看小姐姐、公司摸魚時看學習小課堂的適配更多場景。

而長視頻,更多的觀影場景比較單一,要么在家和家人看劇,要么假期自己一個人好好看部電影,如果在單位時間為用戶消耗了太多的內(nèi)容,用戶選得煙花繚亂,那推薦系統(tǒng)可用的內(nèi)容資產(chǎn)將會逐漸變少,快速實現(xiàn)了遍歷,到山窮水盡之時,用戶會說,你怎么每天給我推同樣的內(nèi)容?我不需要。當這個情況發(fā)生,我們又如何去做呢?

所以,或許我們在長視頻推薦實現(xiàn)時,也得去考量一下我們有多少東西可以推給用戶,讓決策變得更加審慎、更加精細一點,而不是粗暴堆砌性能,滿足用戶一時的選片之歡,而消耗了自己未來的將要給用戶的資產(chǎn)吧。

四、總結(jié)

高實時推薦只不過是我們將用戶選片的場景從分類tab搬到了首頁推薦上,把本屬于分類TAB的點擊給了首頁推薦,把本該屬于單個內(nèi)容的重復曝光均攤給了推薦隊列里的每個內(nèi)容,從而夾帶私活。推薦系統(tǒng)干了自己擅長的事情獲得了CTR的替身,皆大歡喜。但似乎,推薦系統(tǒng)嘗試去解決的在準確性的問題,也許始終沒有解決吧。

假如要我去衡量推薦算法在長視頻領域的優(yōu)劣程度,可能會說:每個用戶的終端曝光多少部電影后,用戶做了進入觀影的決定。推薦算法或者人工運營,需要去解決的可能更多的是去幫助用戶縮短決策路徑,是讓用戶在有限的開機幾分鐘內(nèi)的時間里、或者某個周末找片的過程中,更快更好地找到自己想看的片,然后舒舒服服的看一部電影,順便提高會員VIP的付費比例。

影響內(nèi)容CTR的因素有很多,但內(nèi)容的基本面永遠是核心要素 ,在長視頻推薦領域,無限制的實時動態(tài)刷新,或者單純千篇一律的一天硬推一部分內(nèi)容,或許都是不可行的。前者只不過是用算法的優(yōu)勢幫助了用戶獲得了本不該屬于他的CTR,而后者確需要很精準的策略才能替身CTR,同時,我們還要去考量諸如內(nèi)容遍歷、內(nèi)容召回率等等問題,綜合看,我們要去做什么呢,能做什么呢,或者不該做什么呢?

這其中的中和之道,也只能由策略產(chǎn)品經(jīng)理和算法工程師一步步去探索了。

 

本文由 @汪仔0741 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 人才人才

    回復
    1. 哈哈哈??

      回復
  2. 這個計算公式CTR=N*X*Z/M里,N*X是不是就等于M?

    來自北京 回復
    1. 不加限定時間來說是的,但其實在大屏終端推薦來講,單位時間內(nèi)的M相對固定,而實時推薦和人工推薦的N.X都是不一樣的,所以更加精準來說,這個M應該是單位時間內(nèi)的曝光次數(shù)。

      回復
    2. 多謝啦

      來自北京 回復