前言
相信很多小夥伴都聽說過大資料、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】掃碼即可獲取架構進階學習資料包