前言
相信很多小伙伴都聽說過大數據、AI推薦、千人千面等高大上的話語；也經常看到很多App應用中，會經常推薦一些商品給我們，什么猜你喜歡，重點推薦等業務。
很多小伙伴應該也去網上進行了了解，發現真的是一頭霧水，尤其看到了一些算法時，那些數學公式看了就頭疼。今天就嘗試着介紹一下精准推薦的整體架構，以及核心算法的實現原理，盡量能讓小伙伴們能夠看懂。
注意：看此篇文章的小伙伴需要有一定的java基礎，以及elasticsearch知識哦
推薦架構
以下是常規的推薦系統架構圖
上面架構圖的流程從2個維度方面看
從用戶請求路徑
1）用戶終端發起請求，傳入核心標記UserId
因為有些平台中會有很多地方有推薦業務，如：購物車下面【精品推薦】，商品詳情里面的【猜你喜歡】，商品列表中的【熱門推薦】等；所以終端會經常帶上場景這個參數，不同的場景會對應不同模型數據
2）后台接口再發起調用推薦服務
3）任何的精准推薦都會三個階段：召回、排序、業務重排；
這三個是什么意思呢？弄個圖簡要說明就明白了
通過已經步驟，我們就可以達到推薦的功效，千人千面；整個過程中的最核心的就是召回算法、排序算法；我們再從后台方面去看，數據分析維度的路徑。
從數據分析路徑
任何的分析都需要有素材，素材是什么？其實就是這幾年小伙伴們聽的最多的大數據；何為大數據？簡單理解就是數據量多，數據維度多。我們可以通過這么多的數據去進行分析。
上面的推薦架構圖中：
-
我們通過在終端進行埋點，收集用戶行為日志；存儲到大數據平台。
-
集合業務數據，收集用戶偏好行為數據，如：收藏、點贊、評論等；存儲到大數據平台。
-
基於大數據平台的數據，通過一些算法對數據進行分析，得到一個訓練模型。
-
通過訓練出來的模型，就可以獲得相關的推薦數據。
-
把獲得的推薦數據保存到mysql/redis等持久化工具中。
為了達到用戶請求性能，會把推薦的數據提前存儲到數據庫中；保證用戶體驗。
算法模型
什么是算法？什么是模型？ 給大家舉個小學一年級的題目
Plain Text
題目：找出規律，填寫下面的值
1、3、5、7、9、11、13、？、？
大家一看就知道答案了是吧，我們這里不是討論的最終答案是什么，我們來分析一下答案是怎么來的？
看到上面的題目，我們來分解一下；我們已經知道一組數據
Plain Text
1、3、5、7、9、11、13
這些數據其實相當於我們采集過來的已知數據。
上面的題目現在我們需要根據已知的數據，推測出下2個數字是多少？
即相當於我們知道了用戶的行為數據，然后預測推薦商品給用戶。
算法
根據上面的題目我們一看就知道是第二個數比第一個數大2，即 x2 = x1 + 2；在數學上面專業名詞，就是等差數列。這個就是簡單的算法，也可以理解為算法公式。
訓練模型
在我們推薦系統中會有個模型這個概念，那什么是模型呢？ 我們繼續沿用上面的題目。我們深入思考一下，為什么我們知道算法公式是 x2 = x1 + 2？
是不是因為我們發現 1和3之間相差2，然后在發現3和5之間相差2，5和7相差2，一直到11和13之間相差2；所以我們決策，我們發現了這列數據的規律，就是x2 = x1 + 2。
那在我們推薦系統中，訓練模型的思路也是這樣的，我們先從采集的數據中拿出部分數據，如：1、3、5、7。我們先從這個部分數據中尋找規律，我們得到了類似x2 = x1 + 2的公式；
然后我們在利用這個公式推導出剩余的已知數據，如：我們可以根據這個公式推導出后面的9、11、13。然后發現和我們數據是一致的，我們就可以認為這個算法可行。
上面的第一次拿出來的部分測試專業術語就是訓練數據，剩余的數據就叫測試數據
1、3、5、7為訓練數據；9、11、13為測試數據
在推薦系統中這個整個過程就可以理解為模型的訓練，因為真實的場景中數據維度很多，不可能像我們這個簡單的例子；真實場景中我們需要用到的如協同過濾LFM、ALS算法、LR邏輯回歸等算法
總結一下
算法
Plain Text
就是一種解決問題的思路算法公式。
模型：理解為一段程序
Plain Text
是通過算法+數據進行分析過程的一段程序。
需要數據作為入參，程序體作為算法；執行后返回具體的推薦數據。
所以數據量、維度的多少會直接影響模型的准確率
下面我們來介紹一下在推薦系統中常用到的算法
傳統推薦算法
我們還是來舉個案例，有個圖書平台，需要開發個推薦系統，現在擁有的已知數據如下
我們發現上圖中列為書名，行為用戶；里面的值1代表已讀。值為空的代表沒有讀過。那么現在基於這些數據如何進行推薦呢？我們來看看傳統的推薦思路
基於用戶的協同過濾算法(UserCF)
本質從用戶角度出發
首先需要找到和他們看了同樣書的其他用戶，然后給他們推薦那些用戶喜歡的其他書，也就是從用戶共性出發。這種思路專業術語就是UserCF
如上面的例子，張三和李四都看了《java編程思想》，那么系統就認為二者有共性。
所以就推薦給張三，李四曾經看過的書《孫子兵法》。
那推薦給李四的書，即是張三曾經看過的《人人都是產品經理》
基於物品的協同過濾算法(ItemCF)
本質從商品角度出發
需要給他們推薦和他們已經看的書相似的書。
就是從書的共性出發，張三看了《JAVA編程思想》，屬於IT方面的書籍，那么系統可以推薦給張三《大前端自我修養》或《游戲開發》。這種思路專業術語就是ItemCF
UserCF與ItemCF
從兩個算法的原理可以看到，UserCF的推薦結果着重於反映和用戶興趣相似的小群體的熱點，而ItemCF的推薦結果着重於維系用戶的歷史興趣。換句話說，UserCF的推薦更社會化，反映了用戶所在的小型興趣群體中物品的熱門程度，而 ItemCF的推薦更加個性化，反映了用戶自己的興趣傳承。
UserCF適用場景
Plain Text
1）在新聞網站中，用戶的興趣不是特別細化，絕大多數用戶都喜歡看熱門的新聞。即使是個性化，也是比較粗粒度的，比如有些用戶喜歡體育新聞，有些喜歡社會新聞，UserCF可以給用戶推薦和他有相似愛好的一群其他用戶今天都在看的新聞，這樣在抓住熱點和時效性的同時，保證了一定程度的個性化。
2）UserCF 適合用於新聞推薦的另一個原因是從技術角度考量的。因為作為一種物品，新聞的更新非常快，每時每刻都有新內容出現，而ItemCF需要維護一張物品相關度的表，如果物品更新很快，那么這張表也需要很快更新，這在技術上很難實現。絕大多數物品相關度表都只能做到一天一次更新，這在新聞領域是不可以接受的。而 UserCF 只需要用戶相似性表，雖然UserCF對於新用戶也需要更新相似度表，但在新聞網站中，物品的更新速度遠遠快於新用戶的加入速度，而且對於新用戶，完全可以給他推薦最熱門的新聞，因此 UserCF 顯然是利大於弊。
ItemCF適用場景
Plain Text
1）在圖書、電子商務和電影網站，比如亞馬遜、豆瓣、Netflix中，ItemCF 則能極大地發揮優勢。首先，在這些網站中，用戶的興趣是比較固定和持久的。這些系統中的用戶大都不太需要流行度來輔助他們判斷一個物品的好壞，而是可以通過自己熟悉領域的知識自己判斷物品的質量。因此，這些網站中個性化推薦的任務是幫助用戶發現和他研究領域相關的物品。此外，這些網站的物品更新速度不會特別快，一天一次更新物品相似度矩陣對它們來說不會造成太大的損失，是可以接受的。
總結
上面介紹了UserCF和ItemCF協同算法，也是在之前常用的推薦算法；不過這幾年又出來了一個協同算法LFM（隱語義模型），隱語義模型的核心思想是通過隱含特征 ( latent factor ) 聯系用戶興趣和物品。
舉個例子，用戶A的興趣涉及偵探小說、科普圖書以及一些計算機技術書，而用戶B的興趣比較集中在數學和機器學習方面。
要給 A 和 B 推薦圖書：
對於UserCF，首先需要找到和他們看了同樣書的其他用戶（興趣相似的用戶），然后給他們推薦那些用戶喜歡的其他書；
對於ItemCF，需要給他們推薦和他們已經看的書相似的書，比如作者B看了很多關於數據挖掘的書，可以給他推薦機器學習或者模式識別方面的書。
其實上面的推薦缺少了用戶興趣和物品之間的關系，也就是用戶A和用戶B之間有一定的相似度，但不是完全一樣
如：用戶A興趣偵探小說，計算機技術；用戶B興趣偵探小說，經濟學；那很有可能會把經濟學類的書推薦給用戶A。
那如何解決呢？我們只要加上用戶興趣和物品之間的關系就可以了。可以先對書和物品的興趣進行分類。對於某個用戶，首先得到他的興趣分類，然后從分類中挑選他可能喜歡的物品。
這個基於興趣分類的方法大概需要解決三個問題：
(1) 如何給物品進行分類？
(2) 如何確定用戶對哪些類的物品感興趣，以及感興趣的程度？
(3) 對於一個給定的類，選擇哪些屬於這個類的物品推薦給用戶，以及如何確定這些物品在一個類中的權重？
這個就是LFM所要解決的問題，我們會在下一篇文章中給大家進行分享，謝謝！！！
看完三件事❤️
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
- 點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
- 關注公眾號 『 阿風的架構筆記 』，不定期分享原創知識。
- 同時可以期待后續文章ing🚀
- 關注后回復【666】掃碼即可獲取架構進階學習資料包