當前推薦系統的問題
- 冷啓動問題
- 數據稀疏性問題
- 頭部效應
頭部”標的物“被越來越多的用戶”消費“，而質量好的長尾”標的物“由於用戶行爲較少，自身描述信息不足而得不到足夠的關注 - 佛系人羣問題
是指某些用戶的傾向性和偏好不太明顯，比較散亂，沒有表現出對具備某些特徵的標的物強烈的偏好。因此在協同過濾推薦算法中(拿基於用戶的協同過濾來說)，這種偏好性不強的用戶跟其他用戶的相似度都差不多，選擇不同的相似用戶沒啥差別，因此推薦效果不是特別好。這種問題，在多用戶使用同一個設備時是非常明顯的(比如家庭中的智能電視，一家人都用同一個電視在不同時段看自己喜歡的內容，導致該電視上的行爲比較寬泛，無任何特性)。 - 重複推薦
推薦系統可能會推薦非常相關的標的物給用戶，但對用戶來說，這些相關的標的物是重複的、無價值的。在新聞資訊、短視頻類APP的推薦中這種情況是經常發生的。 - 不能察覺興趣變化了
該問題指的是當用戶的興趣穩定下來後，(推薦)系統很難改變對用戶的認知，即使用戶興趣最近變化了，推薦系統還是保留了用戶過往的興趣，除非當用戶新興趣積累到足夠多，所起的作用完全蓋過了老的興趣。一般解決該問題的思路可以對用戶興趣進行時間衰減操作，最近行爲權重更大，越久遠的行爲權重越小。
工程實踐
每一種召回策略可以看成是一個推薦算法，不同召回算法的結果進行合併，混合後的推薦結果作爲數據輸入給後續的排序推薦算法階段進行進一步精細化處理。
在排序階段，對召回階段多種召回算法混合後的推薦結果進行精細排序，因此從召回到排序這兩個階段的pipeline就是前面提到的級聯混合推薦(也就是前面提到的第六種混合推薦算法)策略。
在業務調控階段，會根據業務規則及運營需求，對排序階段的推薦結果進行調整，可能會調整順序，插入需要強運營的標的物，插入廣告等。這一階段的處理是比較偏業務的，不同行業和運營策略所做的處理會很不一樣，這一塊可能會更多偏規則。從排序到業務調控這兩個階段的pipeline沒有被前面提到的7種混合推薦算法覆蓋，算是在真實業務場景下對上述混合推薦算法的一種補充和完善。
實時推薦系統與混合推薦
實時個性化推薦基於用戶最近的行爲近實時更新用戶的推薦列表，對計算能力、算法、服務響應等都有極高的要求。從用戶最近的行爲獲得用戶短期偏好，這算是一種推薦算法，將短期偏好獲得的推薦結果與原來T+1推薦結果融合推薦給用戶也是一種算法的混合，一般可以採用加權的混合方式，最粗暴的方式是將短期偏好推薦結果置於最高的權重，直接放在推薦列表最前面
深度學習等複雜推薦模型整合多數據源
深度學習可以將多種數據整合到一個模型/框架中，獲得非常好的推薦效果(如2016年YouTube的深度學習推薦系統，可以非常容易整合多種信息進行統一學習，見參考文獻7)。深度學習模型這種具備整合用戶行爲數據、標的物metadata數據、用戶畫像數據等數據的能力，是非常有優勢的，相當於將協同過濾、基於內容的推薦等多種算法的能力融合到一個模型中，雖然不是直接將多個模型融合，不在第三部分7大混合推薦方式之列，但這也算是一種多數據源能力的融合，通過整個多數據源獲得比古典的單個推薦模型更好的效果。
特殊情況下的處理策略
推薦系統屬於互聯網軟件服務，任何軟件服務都存在不確定性，因而會存在一定概率出現問題，對推薦系統也不例外。當由於網絡故障或者服務故障導致推薦服務不可用時，如果在客戶端(即APP上)不做異常保護和處理，用戶訪問推薦服務時，會超時，導致無任何推薦結果返回，整個UI展示都將出問題，出現開天窗的現象，這時就需要前端做保護，在極端情況出現時，給出一組備選方案展示出來，這樣雖然推薦的結果不會那麼精準，但不至於什麼結果都沒有，明顯可以提升用戶體驗。
推薦數量不足的增補
在真實工業級推薦場景中，最終的推薦算法一般會給出固定數量的推薦結果(比如50個，但是在前端可能只展現30個)，由於標的物會出現下線、不可用(視頻下線、商品下架等)等情況，當用戶在客戶端請求推薦服務時，推薦接口先獲取推薦列表(一般是一組標的物的id)，再根據列表的id獲得標的物的metadata信息，填充完整後返回前端並展示給用戶，這個過程中會對標的物id進行過濾和檢查，如果下線了或者不可用了會剔除掉。如果某個用戶的推薦列表下線的標的物比較多(這種情況出現的概率一般不大)，導致最終數量不夠前端展現時，一般會採用補足的策略，比如利用熱門推薦的結果填補不足的數量，最終獲得規定好的數量(如前面提到的50個)，這個利用另外一個推薦算法(如熱門推薦)來填補的策略就是摻雜混合策略(第三節的第3個混合推薦策略)
通過混合策略解決用戶冷啓動
