摘要：前言在上篇文章豆瓣電影，電視劇實(shí)戰(zhàn)中提及到，我和室友們產(chǎn)生了劇荒，萌生出要做一個(gè)個(gè)人用的推薦系統(tǒng)，解決劇荒的問題的想法，經(jīng)過一輪的死纏爛打，這個(gè)個(gè)人推薦系統(tǒng)終于成型了。

在上篇文章豆瓣電影，電視劇DM實(shí)戰(zhàn)中提及到，我和室友們產(chǎn)生了劇荒，萌生出要做一個(gè)個(gè)人用的推薦系統(tǒng)，解決劇荒的問題的想法，經(jīng)過一輪的死纏爛打，這個(gè)個(gè)人推薦系統(tǒng)終于成型了。

今天來分享一下心得，對此感興趣的朋友可以自己對著寫一個(gè)。

首先介紹一下傳統(tǒng)的推薦系統(tǒng)方法，之所以叫它傳統(tǒng)，是因?yàn)榇蟛糠謱W(xué)習(xí)資料上都是用這一個(gè)方法。

我們來假設(shè)有這么一個(gè)矩陣(用python的列表表示):

  [# A B C D E
    [2,0,0,4,4], #1
    [5,5,5,3,3], #2
    [2,4,2,1,2]  #3
    ......
  ]

矩陣的行代表用戶，列表示物品，其交點(diǎn)表示用戶對該物品的評分。

假設(shè)現(xiàn)在用戶1需要選商品，推薦系統(tǒng)則假設(shè)其會(huì)選擇并未選擇過的商品，因此，系統(tǒng)會(huì)在第一行中尋找評分為0的物品，顯然會(huì)找到B和C。這時(shí)，該怎么知道是推薦B還是C呢？(假設(shè)用戶只需推薦一個(gè)),這時(shí)則需要計(jì)算B、C和用戶以前選擇過的物品(已評分)的相似度。

僅僅算出相似度還不夠，因?yàn)槟悴荒芘袛噙@到底是好的那一部分相似還是壞的部分相似。所以這時(shí)，我們需要引入用戶的評分作為相似度計(jì)算的權(quán)重，評分X相似度得到最后的得分（該得分會(huì)一直累加，則B的推薦得分會(huì)是B與A，D，E的相似得分的累加和）。這樣一來，評分低物品的最后得分自然就低，評分高的物品自然得分就高，這時(shí)問題就簡化成排序問題了。

顯然，上述問題的核心在于如何計(jì)算相似度。

這里給出計(jì)算相似度的兩種方法：

歐式距離法
以B和A的相似度為例：
similar = 1/sqrt((0-2)^2 + (5-5)^2 + (4-2)^2 ……) 最后B與A的相似得分還得乘上評分，score = similar * 2

余弦相似度
$$costheta=frac{A cdot B}{||A||||B||}$$
AB為兩列向量，||A||表示A的2范數(shù)
特別注意一點(diǎn)的是，cos的取值是-1~1,我們需要將其歸一化，即把范圍弄成在0~1上。于是相似度計(jì)算公司變成0.5 + 0.5*cos

在上述的內(nèi)容中，我們可以發(fā)現(xiàn)傳統(tǒng)的方法有一個(gè)特出的問題，傳統(tǒng)的算法需要大量的用戶評分，即矩陣的行數(shù)需要較多才能得出的結(jié)果才值得參考。這一個(gè)需求咋看起來是沒什么問題，也符合我們的邏輯，唯有數(shù)據(jù)量足夠，我們才能找到較為準(zhǔn)確的規(guī)律嘛。

但回到我的需求上來說，這可是一個(gè)明顯的缺點(diǎn)，在前言我說明的需求上說過這是一個(gè)給宿舍甚至是個(gè)人使用的推薦系統(tǒng)。

也就是說:

我們無法提供大量數(shù)據(jù)。

我們很懶，我們最可能是告訴系統(tǒng)我從它的推薦中采納了哪一部的電影，而不會(huì)去評分，我們可能告訴它質(zhì)量是否可以接受，但不會(huì)像豆瓣用戶那樣給出0~10的準(zhǔn)確分?jǐn)?shù)。

因此，傳統(tǒng)的推薦算法有很多不適合我需求的地方，但是看問題要看本質(zhì)。無非就是根據(jù)用戶的特性，或者根據(jù)商品特性，進(jìn)行與訓(xùn)練好的模型進(jìn)行相似性比較。抓住這些特點(diǎn)，我做了少少的"創(chuàng)新"

不基于用戶的評分作相似度，而是用商品的label做標(biāo)準(zhǔn)
現(xiàn)在很多商品尤其是音樂或者電影，都會(huì)具有自己的label，比如說喜劇，懸疑，其次還有主演，導(dǎo)演等可以作為其特征。電商平臺(tái)上也有諸如商品種類衣服,女鞋，包包,等，而某些物品，例如衣服，那么衣服的品牌，size，都可以作為用戶的一個(gè)選擇的特征。

用戶模型是動(dòng)態(tài)更新的
這一點(diǎn)不難理解，如果一個(gè)用戶長期使用使用該系統(tǒng)，那么他的選擇中很可能已經(jīng)覆蓋了大量的label，這時(shí)基于label的推薦系統(tǒng)則很難區(qū)分該用戶的喜好。這時(shí)我們有兩個(gè)解決方法。第一個(gè)是允許用戶自定義label，比如SF就可以自定義問題或文章的標(biāo)簽，這樣增大了label的多樣性。當(dāng)然，這個(gè)解決方案只能算一個(gè)緩解的方案，要想徹底解決，我覺得需要給特征選定有效期。
增加有效期后，用戶的選擇可以反應(yīng)出一個(gè)時(shí)間段內(nèi)的需求。假設(shè)這樣一個(gè)場景，一名用戶準(zhǔn)備去旅游了，他可能會(huì)大量瀏覽旅游用品的出售頁面，例如一次性牙膏等，這時(shí)，就可以向該用戶推薦出售旅行用品的網(wǎng)站了。而超過了特征的有效期，例如一周，這時(shí)用戶已經(jīng)旅游回來，因?yàn)樘卣饕呀?jīng)無效，推薦系統(tǒng)不再推薦旅游用品（這樣用戶不會(huì)覺得莫名其妙。個(gè)人經(jīng)歷，現(xiàn)在某些網(wǎng)站就往往會(huì)出現(xiàn)明顯已經(jīng)超過我感興趣時(shí)限的推薦），而是開始重新收集用戶新一周瀏覽的特征，動(dòng)態(tài)構(gòu)建用戶模型，推薦用戶下一階段他可能需要的物品

實(shí)現(xiàn)上述想法，在python中，我們可以這么做,實(shí)現(xiàn)如下字典

record = {
    "labelName":(weight,time),
    "labelName2":(weight,time)
    ……
}

#labelName是標(biāo)簽名稱，在該標(biāo)簽下有一個(gè)元組，元組的第一個(gè)字段是這個(gè)標(biāo)簽的權(quán)重。
#權(quán)重越大，表示用戶越喜歡這個(gè)標(biāo)簽。
#第二個(gè)字段是創(chuàng)建該標(biāo)簽的起始時(shí)間

在實(shí)現(xiàn)推薦時(shí)，則較為容易實(shí)現(xiàn)，給定testList。這時(shí)需要:

創(chuàng)建名res的空字典

遍歷testList，每一個(gè)對象命名為t

遍歷t具有的label，根據(jù)label從record上獲取信息。

同時(shí)獲取當(dāng)前時(shí)間time2，如果time2-time超出了規(guī)定時(shí)限，則該標(biāo)簽的信息無效，忽略該label，同時(shí)刪除record里面的對應(yīng)的字段。

若該標(biāo)簽有效，則t的得分加1，并將t的下標(biāo)index作為key假如到一個(gè)res中

遍歷完成后，對res字典按value排序

最后，可以根據(jù)需要對排序結(jié)果進(jìn)行訪問。比如只獲取最高的前5名。

這樣，一個(gè)適合少用戶的推薦系統(tǒng)就弄出來啦~

現(xiàn)在正在宿舍投入運(yùn)行，至于效果如何可能要一段時(shí)間才知道了

github 地址

說明一下，github上只是提供了一個(gè)實(shí)現(xiàn)了上述改進(jìn)后思路的類recommend.py，并不是一個(gè)成型的推薦系統(tǒng)，你可以下載后，根據(jù)這個(gè)類進(jìn)行二次開發(fā)，比如:

利用flask框架包裝成一個(gè)web應(yīng)用

結(jié)合該類并利用SMTP協(xié)議，弄一個(gè)自動(dòng)往郵箱發(fā)信息的腳本，推薦的電影信息

將類實(shí)例化，弄出簡單的命令行應(yīng)用

遲下我會(huì)上傳一個(gè)使用falsk封裝的一個(gè)簡單的webserver去github,可以通過web API請求，返回json格式的電影信息。

如有錯(cuò)誤，望指正。