演算法講解網站
演算法導論
數據結構 嚴蔚敏
數據結構與演算法分析——c語言描述
演算法珠璣
c編程專家
這幾個都可以考慮.
❷ 二十七、ElasticSearch聚合分析中的演算法講解
1、易並行聚合演算法，三角選擇原則，近似聚合演算法
（1）、易並行聚合演算法：比如max
（2）、不易的，如count(distinct)
（2）精準+大數據：hadoop，批處理，非實時，可以處理海量數據，保證精準，可能會跑幾個小時
（3）大數據+實時：es，不精準，近似估計，可能會有百分之幾的錯誤率
（4）、近似聚合演算法
如果採取近似估計的演算法：延時在100ms左右，0.5%錯誤
如果採取100%精準的演算法：延時一般在5s~幾十s，甚至幾十分鍾，幾小時， 0%錯誤
2、cardinality去重及演算法優化和HLL演算法分析
es，去重，cartinality metric，對每個bucket中的指定的field進行去重，取去重後的count，類似於count(distcint)
precision_threshold優化准確率和內存開銷可以提高去重性能
cardinality演算法，會佔用precision_threshold * 8 byte 內存消耗，100 * 8 = 800個位元組
HyperLogLog++ (HLL)演算法性能優化
默認情況下，發送一個cardinality請求的時候，會動態地對所有的field value，取hash值; 將取hash值的操作，前移到建立索引的時候
3、percentiles百分比演算法以及網站訪問時延統計
需求：比如有一個網站，記錄下了每次請求的訪問的耗時，需要統計tp50，tp90，tp99
tp50：50%的請求的耗時最長在多長時間
tp90：90%的請求的耗時最長在多長時間
tp99：99%的請求的耗時最長在多長時間
數據：
不同概率百分比之間的防問效率：
分組統計防問百分比，並計算平均值
4、percentile ranks網站訪問時延SLA統計
SLA：就是你提供的服務的標准
例以地區分組，計算以不同時間的響應百分比
5、doc value原理
（1）index-time生成
PUT/POST的時候，就會生成doc value數據，也就是正排索引
（2）核心原理與倒排索引類似
正排索引，也會寫入磁碟文件中，os cache先進行緩存，以提升訪問doc value正排索引的性能，如果os cache內存大小不足夠放得下整個正排索引，doc value，就會將doc value的數據寫入磁碟文件中
（3）性能問題：
es官方是建議，es大量是基於os cache來進行緩存和提升性能的，不建議用jvm內存來進行緩存，那樣會導致一定的gc開銷和oom問題給jvm更少的內存，給os cache更大的內存。
（4）、column壓縮
doc1: 550
doc2: 550
doc3: 500
合並相同值，550，doc1和doc2都保留一個550的標識即可
（1）所有值相同，直接保留單值
（2）少於256個值，使用table encoding模式：一種壓縮方式
（3）大於256個值，看有沒有最大公約數，有就除以最大公約數，然後保留這個最大公約數
（4）如果沒有最大公約數，採取offset結合壓縮的方式：
如果的確不需要doc value，比如聚合等操作，那麼可以禁用，減少磁碟空間佔用
PUT my_index
{
"mappings": {
"my_type": {
"properties": {
"my_field": {
"type": "keyword"
"doc_values": false
}
}
}
}
}
6、對於分詞的field執行aggregation，發現報錯。。。
如果直接對分詞field執行聚合，報錯，大概意思是說，你必須要打開fielddata，然後將正排索引數據載入到內存中，才可以對分詞的field執行聚合操作，而且會消耗很大的內存
給分詞的field，設置fielddata=true，發現可以執行
也可以用內置field不分詞，對string field進行聚合
7、分詞field+fielddata的工作原理
（1）、不分詞的所有field，可以執行聚合操作 --> 如果你的某個field不分詞，那麼在index-time時，就會自動生成doc value --> 針對這些不分詞的field執行聚合操作的時候，自動就會用doc value來執行
（2）、分詞field，是沒有doc value的。在index-time，如果某個field是分詞的，那麼是不會給它建立doc value正排索引的，因為分詞後，佔用的空間過於大，所以默認是不支持分詞field進行聚合的
fielddata載入到內存的過程是lazy載入的，對一個analzyed field執行聚合時，才會載入，而且是field-level載入的。一個index的一個field，所有doc都會被載入，而不是少數doc，不是index-time創建，是query-time創建
為什麼fielddata必須在內存？因為分詞的字元串，需要按照term進行聚合，需要執行更加復雜的演算法和操作，如果基於磁碟和os cache，那麼性能會很差。
8、fielddata相關優化配置
（1）、內存限制
indices.fielddata.cache.size: 20%，超出限制，清除內存已有fielddata數據，fielddata佔用的內存超出了這個比例的限制，那麼就清除掉內存中已有的fielddata數據
默認無限制，限制內存使用，但是會導致頻繁evict和reload，大量IO性能損耗，以及內存碎片和gc
（2）監控fielddata內存使用
GET /_stats/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?fields=*
GET /_nodes/stats/indices/fielddata?level=indices&fields=*
（3）、circuit breaker斷路器
如果一次query load的feilddata超過總內存，就會oom --> 內存溢出
circuit breaker會估算query要載入的fielddata大小，如果超出總內存，就短路，query直接失敗
indices.breaker.fielddata.limit：fielddata的內存限制，默認60%
indices.breaker.request.limit：執行聚合的內存限制，默認40%
indices.breaker.total.limit：綜合上面兩個，限制在70%以內
（4）、fielddata filter的細粒度內存載入控制
min：僅僅載入至少在1%的doc中出現過的term對應的fielddata
比如說某個值，hello，總共有1000個doc，hello必須在10個doc中出現，那麼這個hello對應的fielddata才會載入到內存中來
min_segment_size：少於500 doc的segment不載入fielddata
載入fielddata的時候，也是按照segment去進行載入的，某個segment裡面的doc數量少於500個，那麼這個segment的fielddata就不載入
（5）、fielddata預載入
query-time的fielddata生成和載入到內存，變為index-time，建立倒排索引的時候，會同步生成fielddata並且載入到內存中來，這樣的話，對分詞field的聚合性能當然會大幅度增強
（6）、global ordinal序號標記預載入
有很多重復值的情況，會進行global ordinal標記
doc1: status1
doc2: status2
doc3: status2
doc4: status1
status1 --> 0 status2 --> 1
doc1: 0
doc2: 1
doc3: 1
doc4: 0
建立的fielddata也會是這個樣子的，這樣的好處就是減少重復字元串的出現的次數，減少內存的消耗
❸ Hulu的推薦演算法課程（7月15號發布）
最近，Hulu又推出了推薦演算法課程，關鍵是免費的，太良心了有沒有。平常動輒幾百幾千的小象學院的課程，現在統統不要錢。我聽了第一節，感覺實用性很強，肯定不會有很深入的講解，適合學生和想入場推薦系統的演算法工程師來學習。同時Hulu提供了幾道推薦演算法的面試題，大家可以體會一下。
第一節課主要講了幾種基礎的推薦演算法模型（協同過濾，因式分解機，邏輯回歸，提升樹）
推薦演算法在使用場景有：
1 視頻網站，推薦視頻（例如hulu，抖音等）
2 網購網站，推薦商品（例如京東，淘寶，Amazon）
3 新聞網站，推薦新聞（例如今日頭條）
推薦演算法的基礎假設：
1 信息過載
2 用戶不確定自己想看的內容
協同過濾演算法是一種上下文無關的推薦演算法
它的初衷是用戶的歷史和未來趨勢保持一致
協同過濾演算法有兩種：基於用戶的推薦演算法和基於物品的推薦演算法
基於用戶的推薦演算法：通過找到類似的用戶，從而做推薦
基於物品的推薦演算法：通過購買或者點贊的產品從而做推薦
好處:
簡單，可解釋性強
缺點：
需要佔用存儲（維護矩陣），稀疏矩陣問題
上下文無關的推薦演算法
初衷：發現高維特徵
進一步完善矩陣分解：
u表示平均打分在目錄中
表示商品間的打分差異
表示用戶的打分差異
優點：
更泛化性（即使兩個用戶沒有給相同商品打分），節約存儲空間（只需要保存兩個低維向量）
缺點：
不好解釋；更加稀疏
初衷：增加上下文信息到模型，把推薦系統作為一個分類問題來解決
用戶，商品，上下文信息可以被轉化為分類變數（比如性別，時間區間等）
最後加入sigmoid函數映射到0-1空間中。
好處：可解釋性比較強；可以並行快速訓練；訓練開銷比較低；可以在線訓練
缺點：需要特徵工程；模型的表達能力差
初衷：考慮到特徵間的交叉
)
好處：表達能力比較強；很好泛化能力了；相對低的訓練開銷
缺點：做更高層的特徵交叉比較難
提升樹是基於Boosting的原理：使用多個弱分類器串列成集成分類器
提升樹演算法是通過集合多個決策樹而得到的
第一道：從基於用戶的協同過濾和基於物品的協同過濾的原理思考，下列場景中使用哪種協同過濾演算法更加適合？為什麼？
（1）新聞資訊推薦
新聞網站更適用於基於用戶的協同過濾演算法，興趣相似的用戶關注的新聞相似的概率比較大。
（2）電商網站推薦
電商網站更適用於基於物品的協同過濾演算法，使用用戶關注或者購買過的物品可以更精準推薦他未來購買的物品。
第二道：為什麼邏輯回歸模型在工業界受到了廣泛應用？LR相對於其他的模型，尤其是GBDT模型，突出的優點是什麼？
邏輯回歸可解釋性強，並且可以在線計算。相對於GBDT串聯型結構，LR可以並行，所以得到工業界的歡迎。
第三道：為什麼說提升樹模型（GBDT)難以並行化？從Boosting方法的角度上給出簡單的解釋。
Boosting是通過不斷增加新的模型預測，這種方式是無法並行化操作。
出自：世相科技
歡迎點贊支持
❹ 07_推薦系統演算法詳解
基於人口統計學的推薦與用戶畫像、基於內容的推薦、基於協同過濾的推薦。
1、基於人口統計學的推薦機制( Demographic-based Recommendation)是一種最易於實現的推薦方法，它只是簡單的根據系統用戶的基本信息發現用戶的相關程度，然後將相似用戶喜愛的其他物品推薦給當前用戶。
2、對於沒有明確含義的用戶信息(比如登錄時間、地域等上下文信息)，可以通過聚類等手段，給用戶打上分類標簽。
3、對於特定標簽的用戶，又可以根據預設的規則(知識)或者模型，推薦出對應的物品。
4、用戶信息標簽化的過程一般又稱為 用戶畫像 ( User Profiling）。
（1）用戶畫像( User Profile)就是企業通過收集與分析消費者社會屬性、生活習慣、消費行為等主要信息的數據之後，完美地抽象出一個用戶的商業全貌作是企業應用大數據技術的基本方式。
（2）用戶畫像為企業提供了足夠的信息基礎，能夠幫助企業快速找到精準用戶群體以及用戶需求等更為廣泛的反饋信息。
（3）作為大數據的根基，它完美地抽象出一個用戶的信息全貌，為進一步精準、快速地分析用戶行為習慣、消費習慣等重要信息，提供了足夠的數據基礎。
1、 Content- based Recommendations(CB)根據推薦物品或內容的元數據，發現物品的相關性，再基於用戶過去的喜好記錄，為用戶推薦相似的物品。
2、通過抽取物品內在或者外在的特徵值,實現相似度計算。比如一個電影,有導演、演員、用戶標簽UGC、用戶評論、時長、風格等等，都可以算是特徵。
3、將用戶(user)個人信息的特徵(基於喜好記錄或是預設興趣標簽)，和物品(item)的特徵相匹配，就能得到用戶對物品感興趣的程度。在一些電影、音樂、圖書的社交網站有很成功的應用,有些網站還請專業的人員對物品進行基因編碼/打標簽(PGC）。
4、 相似度計算：
5、對於物品的特徵提取——打標簽(tag)
- 專家標簽(PGC）
- 用戶自定義標簽(UGC)
- 降維分析數據,提取隱語義標簽(LFM)
對於文本信息的特徵提取——關鍵詞
- 分詞、語義處理和情感分析(NLP)
- 潛在語義分析(LSA）
6、 基於內容推薦系統的高層次結構
7、 特徵工程
（1）特徵( feature)：數據中抽取出來的對結果預測有用的信息。
特徵的個數就是數據的觀測維度。
特徵工程是使用專業背景知識和技巧處理數據，使得特徵能在機器學習演算法上發揮更好的作用的過程。
特徵工程一般包括特徵清洗(采樣、清洗異常樣本)，特徵處理和特徵選擇。
特徵按照不同的數據類型分類，有不同的特徵處理方法：數值型、類別型、時間型、統計型。
（2）數值型特徵處理
用連續數值表示當前維度特徵，通常會對數值型特徵進行數學上的處理，主要的做法是歸一化和離散化。
* 幅度調整歸一化：
特徵與特徵之間應該是平等的，區別應該體現在 特徵內部 。
例如房屋價格和住房面積的幅度是不同的，房屋價格可能在3000000~15000000(萬)之間,而住房面積在40-300(平方米)之間，那麼明明是平等的兩個特徵，輸入到相同的模型中後由於本身的幅值不同導致產生的效果不同，這是不合理的
* 數值型特徵處理——離散化
離散化的兩種方式：等步長——簡單但不一定有效；等頻——min -> 25% -> 75% -> max
兩種方法對比：
等頻的離散化方法很精準，但需要每次都對數據分布進行一遍從新計算，因為昨天用戶在淘寶上買東西的價格分布和今天不一定相同，因此昨天做等頻的切分點可能並不適用，而線上最需要避免的就是不固定，需要現場計算，所以昨天訓練出的模型今天不一定能使用。
等頻不固定，但很精準，等步長是固定的，非常簡單，因此兩者在工業上都有應用。
（3） 類別型特徵處理
類別型數據本身沒有大小關系，需要將它們編碼為數字，但它們之間不能有預先設定的大小關系，因此既要做到公平，又要區分開它們，那麼直接開辟多個空間。
One-Hot編碼/啞變數：One-Hot編碼/啞變數所做的就是將類別型數據平行地展開，也就是說，經過One-Hot編碼啞變數後，這個特徵的空間會膨脹。
（4） 時間型特徵處理
時間型特徵既可以做連續值,又可以看做離散值。
連續值：持續時間(網頁瀏覽時長)；間隔時間(上一次購買/點擊離現在的時間間隔)。
離散值：一天中哪個時間段；一周中的星期幾；一年中哪個月/星期；工作日/周末。
（5） 統計型特徵處理
加減平均：商品價格高於平均價格多少，用戶在某個品類下消費超過多少。
分位線：商品屬於售出商品價格的分位線處。
次序性：商品處於熱門商品第幾位。
比例類：電商中商品的好/中/差評比例。
8、 推薦系統常見反饋數據 ：
9、 基於UGC的推薦
用戶用標簽來描述對物品的看法，所以用戶生成標簽(UGC)是聯系用戶和物品的紐帶，也是反應用戶興趣的重要數據源。
一個用戶標簽行為的數據集一般由一個三元組(用戶,物品,標簽)的集合表示，其中一條記錄(u,i,b)表示用戶u給物品打上了標簽b。
一個最簡單的演算法：
- 統計每個用戶最常用的標簽
- 對於每個標簽,統計被打過這個標簽次數最多的物品
- 對於一個用戶，首先找到他常用的標簽，然後找到具有這些標簽的最熱門的物品，推薦給他
- 所以用戶u對物品i的興趣公式為 ，其中 使用戶u打過標簽b的次數， 是物品i被打過標簽b的次數。
簡單演算法中直接將用戶打出標簽的次數和物品得到的標簽次數相乘，可以簡單地表現出用戶對物品某個特徵的興趣。
這種方法傾向於給熱門標簽(誰都會給的標簽,如「大片」、「搞笑」等)、熱門物品(打標簽人數最多)比較大的權重，如果一個熱門物品同時對應著熱門標簽,那它就會「霸榜」，推薦的個性化、新穎度就會降低。
類似的問題,出現在新聞內容的關鍵字提取中。比如以下新聞中,哪個關鍵字應該獲得更高的權重?
10、 TF-IDF：詞頻逆文檔頻率 ( Term Frequency- -Inverse Document Frequency,TF-DF)是一種用於資訊檢索與文本挖掘的常用加權技術。
TFDF是一種統計方法，用以評估一個字詞對於一個文件集或一個語料庫中的其中份文件的重要程度。字詞的重要性隨著它在文件中出現的次數成正比增加，但同時會隨著它在語料庫中出現的頻率成反比下降。
TFIDF=TF IDF
TF-IDF的主要思想是 ：如果某個詞或短語在一篇文章中出現的頻率TF高，並且在其他文章中很少出現，則認為此詞或者短語具有很好的類別區分能力，適合用來分類。
TF-DF加權的各種形式常被搜索引擎應用，作為文件與用戶查詢之間相關程度的度量或評級。
詞頻( Term Frequency,TF) ：指的是某一個給定的詞語在該文件中出現的頻率。這個數字是對詞數的歸一化，以防止偏向更長的文件。(同一個詞語在長文件里可能會比短文件有更高的詞數,而不管該詞語重要與否。） ，其中 表示詞語 i 在文檔 j 中出現的頻率， 表示 i 在 j 中出現的次數， 表示文檔 j 的總詞數。
逆向文件頻率( Inverse Document Frequency,IDF) ：是一個詞語普遍重要性的度量，某一特定詞語的IDF，可以由總文檔數目除以包含該詞語之文檔的數目，再將得到的商取對數得到 ，其中 表示詞語 i 在文檔集中的逆文檔頻率，N表示文檔集中的文檔總數， 表示文檔集中包含了詞語 i 的文檔數。
（11） TF-IDF對基於UGC推薦的改進 ： ，為了避免熱門標簽和熱門物品獲得更多的權重，我們需要對「熱門進行懲罰。
借鑒TF-IDF的思想，以一個物品的所有標簽作為「文檔」，標簽作為「詞語」，從而計算標簽的「詞頻」(在物品所有標簽中的頻率)和「逆文檔頻率」(在其它物品標簽中普遍出現的頻率）。
由於「物品i的所有標簽」 應該對標簽權重沒有影響，而 「所有標簽總數」 N 對於所有標簽是一定的，所以這兩項可以略去。在簡單演算法的基礎上,直接加入對熱門標簽和熱門物品的懲罰項： ，其中， 記錄了標簽 b 被多少個不同的用戶使用過， 記錄了物品 i 被多少個不同的用戶打過標簽。
（一）協同過濾（Collaborative Filtering, CF）
1、基於協同過濾(CF)的推薦：基於內容( Content based,CB)主要利用的是用戶評價過的物品的內容特徵，而CF方法還可以利用其他用戶評分過的物品內容。
CF可以解決CB的一些局限：
- 物品內容不完全或者難以獲得時,依然可以通過其他用戶的反饋給出推薦。
- CF基於用戶之間對物品的評價質量，避免了CB僅依賴內容可能造成的對物品質量判斷的干。
- CF推薦不受內容限制，只要其他類似用戶給出了對不同物品的興趣，CF就可以給用戶推薦出內容差異很大的物品(但有某種內在聯系)
分為兩類：基於近鄰和基於模型。
2、基於近鄰的推薦系統：根據的是相同「口碑」准則。是否應該給Cary推薦《泰坦尼克號》?
（二）基於近鄰的協同過濾
1、 基於用戶（User-CF）： 基於用戶的協同過濾推薦的基本原理是，根據所有用戶對物品的偏好，發現與當前用戶口味和偏好相似的「鄰居」用戶群，並推薦近鄰所偏好的物品。
在一般的應用中是採用計算「K-近鄰」的演算法；基於這K個鄰居的歷史偏好信息，為當前用戶進行推薦。
User-CF和基於人口統計學的推薦機制：
- 兩者都是計算用戶的相似度，並基於相似的「鄰居」用戶群計算推薦。
- 它們所不同的是如何計算用戶的相似度：基於人口統計學的機制只考慮用戶本身的特徵，而基於用戶的協同過濾機制可是在用戶的歷史偏好的數據上計算用戶的相似度，它的基本假設是，喜歡類似物品的用戶可能有相同或者相似的口味和偏好。
2、基於物品（Item-CF）：基於項目的協同過濾推薦的基本原理與基於用戶的類似，只是使用所有用戶對物品的偏好，發現物品和物品之間的相似度，然後根據用戶的歷史偏好信息，將類似的物品推薦給用戶。
Item-CF和基於內容(CB)的推薦
- 其實都是基於物品相似度預測推薦，只是相似度計算的方法不一樣，前者是從用戶歷史的偏好推斷，而後者是基於物品本身的屬性特徵信息。
同樣是協同過濾，在基於用戶和基於項目兩個策略中應該如何選擇呢?
- 電商、電影、音樂網站,用戶數量遠大於物品數量。
- 新聞網站，物品(新聞文本)數量可能大於用戶數量。
3、 User-CF和Item-CF的比較
同樣是協同過濾，在User-CF和ltem-CF兩個策略中應該如何選擇呢？
Item-CF應用場景
- 基於物品的協同過濾( Item-CF ) 推薦機制是 Amazon在基於用戶的機制上改良的一種策略因為在大部分的Web站點中，物品的個數是遠遠小於用戶的數量的，而且物品的個數和相似度相對比較穩定，同時基於物品的機制比基於用戶的實時性更好一些，所以 Item-CF 成為了目前推薦策略的主流。
User-CF應用場景
- 設想一下在一些新聞推薦系統中，也許物品一一也就是新聞的個數可能大於用戶的個數，而且新聞的更新程度也有很快，所以它的相似度依然不穩定，這時用 User-cf可能效果更好。
所以，推薦策略的選擇其實和具體的應用場景有很大的關系。
4、 基於協同過濾的推薦優缺點
（1）基於協同過濾的推薦機制的優點：
它不需要對物品或者用戶進行嚴格的建模，而且不要求對物品特徵的描述是機器可理解的，所以這種方法也是領域無關的。
這種方法計算出來的推薦是開放的，可以共用他人的經驗，很好的支持用戶發現潛在的興趣偏好。
（2）存在的問題
方法的核心是基於歷史數據，所以對新物品和新用戶都有「冷啟動」的問題。
推薦的效果依賴於用戶歷史好數據的多少和准確性。
在大部分的實現中，用戶歷史偏好是用稀疏矩陣進行存儲的，而稀疏矩陣上的計算有些明顯的問題，包括可能少部分人的錯誤偏好會對推薦的准確度有很大的影響等等。
對於一些特殊品味的用戶不能給予很好的推薦。
（三）基於模型的協同過濾
1、基本思想
（1）用戶具有一定的特徵，決定著他的偏好選擇
（2）物品具有一定的特徵，影響著用戶需是否選擇它。
（3）用戶之所以選擇某一個商品，是因為用戶特徵與物品特徵相互匹配。
基於這種思想，模型的建立相當於從行為數據中提取特徵，給用戶和物品同時打上「標簽」；這和基於人口統計學的用戶標簽、基於內容方法的物品標簽本質是一樣的，都是特徵的提取和匹配。
有顯性特徵時(比如用戶標簽、物品分類標簽)我們可以直接匹配做出推薦；沒有時，可以根據已有的偏好數據，去發據出隱藏的特徵,這需要用到隱語義模型(LFM)。
2、基於模型的協同過濾推薦，就是基於樣本的用戶偏好信息，訓練一個推薦模型,然後根據實時的用戶喜好的信息進行預測新物品的得分，計算推薦
基於近鄰的推薦和基於模型的推薦
- 基於近鄰的推薦是在預測時直接使用已有的用戶偏好數據，通過近鄰數據來預測對新物品的偏好(類似分類)
- 而基於模型的方法，是要使用這些偏好數據來訓練模型，找到內在規律，再用模型來做預測(類似回歸)
訓練模型時，可以基於標簽內容來提取物品特徵，也可以讓模型去發據物品的潛在特徵；這樣的模型被稱為 隱語義模型 ( Latent Factor Model,LFM)。
（1）隱語義模型(LFM)：用隱語義模型來進行協同過濾的目標：
- 揭示隱藏的特徵,這些特徵能夠解釋為什麼給出對應的預測評分
- 這類特徵可能是無法直接用語言解釋描述的,事實上我們並不需要知道,類似「玄學」
通過矩陣分解進行降維分析
- 協同過濾演算法非常依賴歷史數據，而一般的推薦系統中，偏好數據又往往是稀疏的；這就需要對原始數據做降維處理。
- 分解之後的矩陣，就代表了用戶和物品的隱藏特徵
隱語義模型的實例：基於概率的隱語義分析(pLSA)、隱式迪利克雷分布模型(LDA)、矩陣因子分解模型(基於奇異值分解的模型,SVD)
（2）LFM降維方法——矩陣因子分解
（3）LFM的進一步理解
我們可以認為，用戶之所以給電影打出這樣的分數，是有內在原因的，我們可以挖掘出影響用戶打分的隱藏因素，進而根據未評分電影與這些隱藏因素的關聯度，決定此未評分電影的預測評分。
應該有一些隱藏的因素，影響用戶的打分，比如電影：演員、題材、年代…甚至不定是人直接可以理解的隱藏因子。
找到隱藏因子，可以對user和Iiem進行關聯(找到是由於什麼使得user喜歡/不喜歡此Item,什麼會決定user喜歡/不喜歡此item)，就可以推測用戶是否會喜歡某一部未看過的電影。
（4）矩陣因子分解
（5）模型的求解——損失函數
（6）模型的求解演算法——ALS
現在，矩陣因子分解的問題已經轉化成了一個標準的優化問題，需要求解P、Q，使目標損失函數取最小值。
最小化過程的求解，一般採用隨機梯度下降演算法或者交替最小二乘法來實現交替最小二乘法( Alternating Least Squares,ALS)
ALS的思想是，由於兩個矩陣P和Q都未知,且通過矩陣乘法耦合在一起，為了使它們解耦，可以先固定Q，把P當作變數，通過損失函數最小化求出P，這就是一個經典的最小二乘問題；再反過來固定求得的P，把Q當作變數，求解出Q：如此交替執行，直到誤差滿足閱值條件，或者到達迭代上限。
（7）梯度下降演算法