推薦系統中的推薦理由實現,有什麼好的思路嗎?

用一些生硬字元串拼接是我現在想到的辦法。


在美國亞馬遜做推薦的時候,我們做過一些比較大膽的嘗試,也是我自己看好的方向,雖然最後因為某些原因沒有繼續下去。我們那時做推薦是朝更人性化的方向,舉些做過推薦理由的例子:
1. 推薦這部電影的原因是因為他得了Oscar。(根據過去發現你對得獎的片比較感興趣)
2. 推薦Harry Potter第二集是因為你6天前買了第一集。(根據你過去看續集的習慣)
3. 推薦產品A是因為你朋友下周生日,而A是他喜歡的。(或許你可以買來送給他)
。。。等等。單獨每個的覆蓋率不會高,但轉化率非常高。

每個物品都有它特殊的屬性在,只要朝人性化的方向去想,挖掘一些比較有影響力的屬性出來,對購買決策會有幫助。另,推薦應該是個一般人很可以容易理解的東西,這會影響用戶的信任。


在我過去的個性化推薦實踐經歷里,一直認為顯性的展示推薦理由是不那麼「自然」、不那麼有效的方式。這樣的考慮主要是基於兩個原因:

其一,無論是 CF,matrix factorization 還是 feature engineering, 基於統計機器學習的推薦演算法基本都是「黑盒」模式的,雖然我們可以抽取出類似「75%購買了 A 商品的用戶還購買了 B」,或者「影響購買 A 商品的因素是 F1,F2 和 F3」 這樣從數據的角度來看很有說服力的結論,但這些是數據上的關聯,相關性不等於因果性,相信大家都明白這個道理。用戶對推薦理由的訴求是知其然還要知其所以然,而演算法上,我們僅僅做到了前半部分。

其二,無論怎樣拼接和構造推薦理由,它看起來都像是機器產生的,遠達不到朋友之間的推薦那種自然而然的效果,更像是個蹩腳的店員徒勞的向你推銷些你早已知道的東西。推薦理由,說到底,是個人機交互的問題,不夠友好、自然的方式,不會起到太好的效果。

不過現在,我對這個問題的看法有些轉變,過去幾年 AI 領域的進展使得我們能夠期待以更加「自然」、更加有效的方式來進行人機交互。說到這裡插一句,CF 一直頂著經典個性化推薦演算法的名頭,但在我看來,它的實質其實是 collective intelligence,而非 personalization。如果我們能夠以自然語言、對話的方式把待推薦的 item 傳遞給用戶,那麼就是真正的個性化的推薦,也是知其然而知其所以然的推薦。並且真正解決了個性化推薦的產品形態、用戶認知、推薦理由等一系列問題。

這會不會是下一代推薦系統?


  1. 非常同意 @陳義 的回答,首先要弄清楚為什麼需要「推薦理由」這麼一個東西,你用這個東西解決什麼問題?順著這個思路往下找就對了。
  2. 針對問題中的問題,其實是個具體情況具體分析的事情。比如,如果是電商,推薦理由可以是「買了這個東東的還買了xx」,更細緻一點的可以統計一個百分比出來,這個參考Amazon/噹噹,都做得不錯了;如果是社會化網路,推薦理由可以是「在你的圈子裡面張三、李四等5人都xx」;如果是豆瓣,評論是強項,比如電影「愛情與靈藥」,豆瓣推出來的評論是「炮友終成眷屬」,我立馬就去看了。。。
  3. 最後,不要為了推薦而做推薦。推薦是基礎設施,如果你想做的好,需要正確對待這件事情,願意做相應的投入。如果按照這個思路做,你就會發現「推薦理由」根本就不是問題,是水到渠成的事情。問題裡面提到的「用一些生硬字元串拼接」,我真的建議慎重考慮,這樣做很可能壞了推薦引擎的名聲,砸了自己的飯碗。

和任何其他的任務一樣,首先要弄清楚為什麼需要「推薦理由」這麼一個東西。就我能想到的應用來看,推薦理由主要有兩方面的作用。

1. 用戶總是希望自己有最後的決定權,如果系統推薦的商品不滿意,得有辦法讓用戶改進它。對於這類需求,需要簡潔地告訴用戶系統的推薦邏輯,比如「因為你喜歡A所以給你推薦了B」,用戶可以依此來修改興趣列表,調整推薦結果。當然,這並不總是可能的,大多數推薦演算法的結果用戶很難操控。

2. 讓用戶更快速地判斷推薦結果是不是真的符合自己的興趣。在有些領域,比如圖書推薦,這一般不是太大的問題,因為用戶可以根據圖書的標題判斷。但在另外一些領域,比如新浪微博或知乎的朋友推薦,這顯然是個很大的問題。在這種情況下,怎麼合理地填寫推薦理由,這本身就是一個數據分析和數據挖掘的工作。


推薦的演算法總是可以用比較精鍊語言概括其思想的。
比如@谷文棟 提到的兩個主要描述,就是很好的推薦理由。剩下的是補充細節。
比如是因為產品相似,就告訴用戶A和B在那些項方面相似;如果是社會化推薦,就告訴用戶究竟是誰都關注產品。
這樣用演算法思想作為骨幹,用項目細節來豐富。推薦理由就不會離譜,也不會太單調了。


謝邀,做過一點推薦系統的工作

首先本題目下大部分的回答都是從技術視角切入這個問題。

我想從商業視角去切入。

所謂商業視角就是我們為什麼要給推薦系統加個推薦理由?他本質是想達到什麼商業目的?

我們一定是希望它有助於我們推薦系統的目標。比如提高ctr比如說提高購買率。從這個視角你可以進一步思考,當人給你推薦一個商品或者一個新聞的時候他會說什麼?

1. 首先他說的很可能不是實話,不是真正的理由。你見過商場導購這麼說嗎:先生這是我們店的爆款,根據我目測您的購買能力和穿衣風格這件衣服您有最高的購買幾率。所以推薦給你。你可以試試這麼干能不能賣出一件衣服。

我想真正的導購是這麼說的:美女這件衣服好適合你啊!你好瘦啊!你穿著顯得腿好長啊……

所以首先包括我自己在內很多人設計的推薦理由可能在商業上就錯了,用戶想聽的並不是真話,然而僅通過數據生成的推薦理由只能是大實話。這就輸在了起跑線。

2. 所以我們需要的是用戶想聽到的,看到了就會點進去的話。所以我們需要的可能不是這個商品有多少人購買了,這個商品根據你瀏覽記錄推薦這種。但是不管怎樣我們已經有優化目標了,那總能轉化為一個優化、搜索、機器學習問題。


---------------------------------------------------------------------------------------------------------------


想了解推薦理由的實現需要首先了解推薦系統


現代的推薦系統一般分為兩步:觸發、排序


觸發一般是用啟發式的方法做的,比如cf,比如利用你瀏覽過的商品找近鄰商品,比如用你的user tag找近鄰商品等等。但是一般是計算量比較小的方法,因為這一步要把商品從幾千萬(甚至更大)縮小到一個比較小的候選集上。推薦理由一般是在這一步進行計算的。因為和下一步的機器學習排序相比,這一步的參數空間比較小,是可以很好的提前算好理由存下來的。


排序就是機器學習排序了,用機器學習模型預測你的ctr或者購買率之類的優化目標,把預測值高的排在前面。這一步理論上也是可以做推薦理由的,因為機器學習模型大多都是很稀疏的,導致這個商品排序高的特徵其實很少,在這些特徵里預定義好一些可以用來講推薦理由的特徵,一旦命中就生成,也是可以的。唯一問題在於機器學習模型特徵往往會做很極致的特徵工程,而做特徵工程和特徵的可解釋性可能是有矛盾的,這樣就不容易做到好解釋。而且機器學習都是實時計算,會給系統帶來延時,特徵的空間往往又比較大。


舉一個例子,如果你用過QQ音樂,或者可以打開淘寶首頁,你經常會看到推薦理由。從推薦理由你大概就能猜到他們的觸發策略是怎麼設計的。不過當然實際上有一些策略是並不會顯示在推薦理由中的,因為實在太晦澀了。


推薦系統的評判標準

首先我們得明確什麼是好的推薦系統。可以通過如下幾個標準來判定。

用戶滿意度 描述用戶對推薦結果的滿意程度,這是推薦系統最重要的指標。一般通過對用戶進行問卷或者監測用戶線上行為數據獲得。

預測準確度 描述推薦系統預測用戶行為的能力。一般通過離線數據集上演算法給出的推薦列表和用戶行為的重合率來計算。重合率越大則準確率越高。

覆蓋率 描述推薦系統對物品長尾的發掘能力。一般通過所有推薦物品佔總物品的比例和所有物品被推薦的概率分布來計算。比例越大,概率分布越均勻則覆蓋率越大。

多樣性 描述推薦系統中推薦結果能否覆蓋用戶不同的興趣領域。一般通過推薦列表中物品兩兩之間不相似性來計算,物品之間越不相似則多樣性越好。

新穎性 如果用戶沒有聽說過推薦列表中的大部分物品,則說明該推薦系統的新穎性較好。可以通過推薦結果的平均流行度和對用戶進行問捲來獲得。

驚喜度 如果推薦結果和用戶的歷史興趣不相似,但讓用戶很滿意,則可以說這是一個讓用戶驚喜的推薦。可以定性地通過推薦結果與用戶歷史興趣的相似度和用戶滿意度來衡量。

簡而言之,一個好的推薦系統就是在推薦準確的基礎上,給所有用戶推薦的物品盡量廣泛(挖掘長尾),給單個用戶推薦的物品盡量覆蓋多個類別,同時不要給用戶推薦太多熱門物品,最牛逼的則是能讓用戶看到推薦後有種「相見恨晚」的感覺。

推薦系統的分類


日常生活中,我們會遇到各種各樣的推薦,比如推薦給我們一個餐廳或者一個商品。在這個過程中,推薦者會給出各種各樣的理由以打動我們來接受他們的推薦。同樣,在線上系統,好的推薦系統的不僅能對用戶的歷史行為數據進行深入分析挖掘,將用戶最感興趣的物品推薦給用戶,同時也能對推薦的結果給出合理的解釋。

生成推薦理由主要目的包括:
1)透明性。能讓推薦系統更加透明,推薦理由能讓用戶理解生成推薦結果的計算過程,同時也可以解釋一個物品比另一個物品更受歡迎的原因。
2)正確性。基於推薦理由,用戶可以比較自己的需求和實際提供的物品特性,從而確認推薦物品的質量,驗證推薦結果的準確性。
3)說服力。給出推薦物品的正面信息以打動用戶,改變和強化用戶對此物品的正面觀點,使其接受推薦結果並進行點擊、收藏或者購買等行為。
4)滿意度。推薦理由使推薦結果看上去更加友好,極大的改善了用戶體驗。

綜上,推薦理由的生成可以從多方面考慮,比如物品本身的流行度和熱度、物品之間的關聯性、其他用戶對此物品的看法、基於當前用戶的什麼行為給出的結果。從推薦理由的生成過程來看,一般分為兩大類,一類是靜態推薦理由,另一類是動態推薦理由

1)靜態推薦理由。顧名思義,這類推薦理由是靜態的,也就是推薦理由字面上不會有什麼變化信息。一般是基於用戶歷史的各種行為,如點擊、交易、收藏、評論等,結合物品信息(如分類、標籤)和時間維度(如小時,日,月)等進行統計分析,離線生成各種各樣的榜單結果,如「月票榜靈異類本月前十」、「24小時靈異類熱銷前十」、「喜歡權謀、爭霸、轉世類型的人會喜歡這本書」。
2)動態推薦理由。這類推薦理由會隨著用戶的行為動態變化,在很多場景下是和推薦演算法直接相關的。尤其在個性化推薦系統中,推薦理由會呈現「千人千面的效果」。推薦演算法的解釋性因演算法而已,如SVD幾乎無法解釋,但是協同過濾就非常容易解釋。在相關推薦中,可以生成的推薦理由有「50%的用戶還購買了」、「70%的用戶還瀏覽了」。在個性推薦中,生成的推薦理由千變萬化,如「猜你喜歡」、「根據你的閱讀口味為你推薦」、「買了&<物品名&>的用戶還買了」。

推薦理由的生成對推薦效果有直接影響,在實際應用中,會隨著推薦結果的各種指標變化,對應的文案也需要不斷優化。對於同一物品的不同推薦理由的展現場景,也有多種考慮,以實際業務而定。


記得之前看過一篇paper,好像是這篇:The Reason Why: A Survey of Explanations for Recommender Systems 不知道對你是否有啟發,你可以看看。


首先我們要知道推薦解釋是幹嘛的?推薦解釋是推薦中很重要的一部分,主要功能是增加用戶對推薦系統的理解和信任。
可以基於推薦系統的實現原理來做推薦解釋。
譬如做好友推薦,實現方法很多。冷啟動時,基於用戶的資料進行推薦,推薦解釋就是同高中同大學等等。當用戶在社區中逐漸活躍,與更多的人建立起了好友關係,這時大部分的推薦都是基於網路拓撲關係進行的推薦。譬如A與B之間有30個共同鄰居,A與C之間有5個共同鄰居,直覺看來A和B更容易建立好友關係,推薦解釋就為共同鄰居數。與陌生人相比,用戶更傾向於相信自己朋友的建議。所以我們經常看見一些諸如你的朋友XXX在玩什麼遊戲,你也來加入吧等等。如果實現推薦的方式是基於興趣的,也可以直接解釋為用戶興趣標籤。
另外也可以展示精準的數據做解釋。
我們可以使用精確的數據來吸引用戶。譬如我們推薦或推廣某個遊戲時,很多語言都是過於蒼白,展示數據也許會效果不錯。譬如你的256個好友中有128個好友在玩XX APP,他們一共發了1024個feed,其中有16個與你有關。這樣的解釋就很容易引起用戶的好奇。同樣,在商品推薦或好友推薦中,使用一些關聯規則,就可以用數據來解釋。如你添加了A為好友,我們連續推薦你一系列人,解釋為添加了A的人有64%的幾率添加了B,有32%的幾率添加了C等等。


為什麼要給用戶一個「推薦理由」呢?用戶在乎的只是你的推薦是否和胃口,如果符合,你告訴他這是「我們猜……」用戶反而會覺得很驚喜,反之用戶不喜歡,則引導用戶「告訴系統她可能喜歡什麼。後者的實現方法,一方面是對推薦產品的屬性進行細緻的分拆歸類和標識,然和與用戶反饋過來的數據進行匹配推薦;另一方面向「無反饋」用戶提供幾個模板,比如產品屬性大致分為:開心、憂鬱、平淡、痛恨四種,可以讓用戶選擇其中一種,然後以該屬性為起點不斷推薦,從用戶後續反饋的數據來不斷調整細化;最後一種就是「從眾」策略,給出一些個性鮮明的人的品位,讓用戶選擇是否體驗一下他的品位?從而獲取到後續數據……總之推薦不能做無源之水,所謂推薦理由不過是一個引導用戶提交個人品位的數據的過程,盡量將這個過程變得簡單、有趣就好,剩下的就只是對演算法的不斷改進了。


此外,理由也是需要多樣的,不要讓用戶覺得你就一個理由用來用去。


關於推薦的可解釋性現在會議文獻里越來越多的提及。實踐證明複雜的解釋不靠譜,比如基於model里貢獻較大的feature等,於是目前產品上線的推薦理由基本都是預定義的規則短語。BTW:一個經驗是推薦理由不一定非要和被推薦的過程match,比如給定一個推薦結果,任何講的通的理由都可以拿來展示,但這個結果被推薦的真正原因可能是別的。


理由或許可用一些數字來表示,或者一句簡短語句,但是也不一定要有。
我個人覺得推薦首先要基於業務;另外有個思路就是不一定推薦他們都購買的東西(按概率之類),應該推薦他可能自己瀏覽不到,購買量不多,但是他喜歡的東西,一些隱蔽的東西。


「經群眾舉報」


簡單來說一下我的看法:

從人機交互角度出發, 所有計算機可以描述的東西, 在現實中都可以被真實事件所還原.
推薦本身如果拋開機器從人工角度出發, 必然有對目標用戶數據的相關分析做依據. 再通過對分析結果的一系列衍化來匹配給用戶

當然實現的方法也非常多, 但是一定有一種演算法在裡邊:
1. 針對用戶的使用習慣收集用戶的信息(對特定訪問事物做標記以達到跟蹤目的)
如: 分類 標籤 性別 年齡 性格 喜歡的顏色
甚至基於其它同好用戶相關特徵, 衍化和推測當前用戶特徵

2. 組合用戶特徵值, 設定權重, 設定用戶相關特徵標籤(如: 家庭主婦/職場精英/貪玩/購物狂)
可進行深層次的事件挖掘, 如:
? 年齡增長: 今年16/過兩年18, 女孩從16到18是會產生興趣愛好的變化的
? 身份變化: 學生-工作狂, 女孩-家庭主婦, 單身-人妻或別人老公
? 環境變化: 訪問地點變化
? 層次變化
? 經濟狀況變化
? 社交群體變化
等等...

3. 建立事件體系機制(這個可以設計一套後台更新系統,可以自己定製一些更新規則), 進行用戶數據後台靜默更新(當然主要目的是更新用戶的特徵值)
事件體系的目的是多維度更新用戶特徵值, 所以應該圍繞第二條的一些可能性的變化來做規則
如:
事件1: 更新用戶是否生日/用戶朋友是否有朋友生日(有好友關係體系的話)
事件2: 更新用戶年齡變化(比如到達了18歲, 或者到達了20歲, 或其它)
事件3: 更新用戶價格觀念特徵(比如,以前經常看均價100左右的東西,在某一天漲到200了)
事件4: 更新用戶關注度變化(比如以前經常看娛樂新聞,在某一天看政治新聞比較多了)
以上每一個事件的產生了變化都會對用戶的特徵值產生一個影響,或大或小

4. 根據不同的特徵值設計訪問對象的標籤, 將標籤與特徵值建立匹配權重, 根據權重總和決定推薦, 推薦理由與特徵值掛鉤

實現的效果可能是:
當系統發現一個本來愛玩的女孩子突然經常看奶粉和尿布的時候, 我們可能知道這個女孩變成了一位寶媽, 如果這位位寶媽, 本身是一個非常愛美的人士, 那麼這時候除了奶粉和尿布, 那麼適合寶媽的化妝品和服飾也許也是他需要的, 由此想到應該還有一位寶爸, 那麼適合寶爸的東西有時候也是他需要的東西

總之說起來簡單, 做起來可能非常的麻煩, 類似於大數據挖掘一樣
以人腦思維的角度出發概括總結為
推薦什麼: 物品特徵
為什麼推薦: 用戶特徵
推薦依據: 用戶特徵和物品特徵的關聯性(更新用戶特徵的事件中應該決定了動機,比如更新用戶生日特徵的動機是什麼, 每一個更新動機的描述其實就是推薦理由)


這個問題我正好可以答,因為剛剛看過一篇相關paper.
簡而言之一切的推薦原因都可以劃分為大致兩類, 第一類是有共同愛好(share the same interest), 第二類是此對象和源對象是在同一群體中(比如社交關係中是同學,在同一高中群體中, etc). 由此產生的系統貼label時可以用0~1之間的數表示其sociality和authority的傾向。


這個問題我理解是在問最後推薦理由文案的生成方式,而不是理由的來源。
既然說生成方式的話,其實不管怎麼樣,都只有一種答案吧,就是拼接漢字
樓主所說的生硬字元串拼接,應該算是最簡單的方式了,如果想取得更好的效果,比較方便的方法應該還是人工研究所有可能的推薦理由文案,根據自己所掌握的語言知識,做一些語法或者其他方面的局部優化。考慮到目前的推薦系統推薦理由種類不會太多,人工處理應該是最好的方法。當推薦理由種類特別多人工已經完全無法處理的時候,可能需要人工去處理一些,找到一些規律之後再用NLP的方法去解決。不過這恐怕也是所有用人工智慧方法解決問題的普遍思路吧。


產品展示結果時,目標是將item與user連接起來。
user看到item的信息(標題/圖標/標籤),做出決策是否點擊該item。
item的信息有時無法合理的將user與item連接起來,這時候便需要推薦理由了。


幾乎所有推薦系統的推薦理由模塊在設計時,都要涉及到這三個基本的維度:產生方式,採用信息和推薦演算法。

產生方式包括黑盒和白盒模式,區別在於是否公開推薦過程使用的演算法。在白盒模式中,推薦理由能夠直接反映推薦系統生成推薦結果所使用的具體方法,具有良好的用戶體驗;採用黑盒模式的原因,主要包括基於保密原因不願公開實現細節,或者是計算方式過於繁瑣複雜,缺乏簡潔直觀的推薦理由使用戶能夠一目了然。

採用信息,表示生成推薦理由使用了哪些輸入信息,主要可分為用戶畫像(生成推薦理由時考慮到用戶的個體特性,譬如說基於用戶的人口學特徵、用戶偏好以及用戶的行為特徵);物品信息(推薦理由的生成依賴於物品的特定信息);替代商品(推薦理由中包含了對替代商品的評價意見)。
推薦演算法,顧名思義,即是推薦過程中使用的計算方法,推薦系統的主流演算法包括基於內容的推薦,協同過濾,和基於知識的推薦,對於不同的演算法推薦理由有相對應的展現形式。


同時,可以採用靜態推薦理由與動態推薦理由結合的方法來生產最終的推薦理由。靜態推薦理由挖掘模塊可以通過分析數據統計系統內容,將每個待推薦對象各種統計數據生成用戶可直觀理解的推薦理由,這些統計數據包括,物品不同指標下的榜單信息構成理由,物品的用戶行為信息構成理由,和物品的用戶行為趨勢信息構成理由。而動態推薦理由挖掘模塊,對每個待推薦內容根據傳入的推薦上下文自動進行運算,並給出相應的動態推薦理由。根據每次輸入的參數不同,給出的推薦理由也各不相同。在針對某次具體應用場景的實施應用中,動態推薦理由包括,按地域或時間生成的推薦理由,按傳入的用戶歷史的瀏覽行為生成的推薦理由,和按物品的關鍵詞、屬性、類別等生成的推薦理由。


推薦閱讀:

自然語言處理的master和PhD比較是完全沒有優勢嗎?
什麼是Word2Vec模型?它如何實現?
在不考慮語音輸入的前提下,訊飛輸入法和搜狗輸入法哪個更好?
古詩為什麼能自動生成?

TAG:推薦引擎 | 移動應用推薦 | 自然語言處理 | 推薦系統 | 分詞 | 推薦理由 | 推薦系統實現 |