離線推薦存量問題，在feed架構儲存的資料也有比較多，原有設計都是為了避免離線推薦資料消費完無資料可推薦，但這個對於業務的調整都沒感知，比如內容敏感下架，使用者興趣變化；
推薦資料不足，離線推薦的資料會很快受到使用者的重新整理過量快速消費完，導致召回源資料不足，多樣性不夠，需要補充引擎；目前解決方式是基於sparkstreaming實現的準實時推薦，這個設計也是為了能快速響應使用者的消費推薦，以免離線推薦快速消費完。但這個如果能即時推薦，可以兩塊更完美解決，將非同步計算更多壓在序列計算，需要解決效能問題；業務邏輯實現也可以統一，方便維護與迭代；
推薦池流動，後續需要快速讓推薦池內容流動起來，現在拿到的推薦資料不在推薦池了；
由於沒有高度抽象召回方式 ，策略平台上需要開發比較多的元件才能滿足個性化召回；
當天使用者沒上來，則沒有浪費計算，這是離線推薦弊端
效能，邏輯會全壓在召回服務上；
如何做到通用化；
減少介面開發工作，提高演算法與後端工程師對接效率
支援實時推薦架構
不同業務場景，各自實現召回引擎模型，對應模型儲存、檔案格式有很多種
重複開發，對接效率較慢，管理麻煩，不同開發風格效能也有風險問題
實時推薦訴求
定義標準，主要的幾種演算法生成模型格式，線上服務引擎使用格式，介面標準；
模型發布，模型管理服務化，打通模型平台
打通機器學習平台、推薦策略平台，元件模組通用化
輸入：user—》user畫像—》取出長期，短期，實時等偏 好idlist—>id召回—》合併所有id集合—》過濾—》粗排序
需要實時將使用者畫像輸入到模型生成向量，可以考慮非同步準實時方式生成，線上服務時只關注取生成的向量
輸入：user—》user畫像—>vector-->向量召回檢索—》過濾—》粗排序
推薦系統架構 推薦系統（1） 業界推薦系統架構
1.1業界主流推薦系統架構 業界推薦系統通用架構 1.2使用者本身資料 1.3物品本身資料 1.4使用者行為資料 2.1基於離線訓練的推薦系統架構設計 常用演算法 邏輯回歸 logistics regression 梯度提公升決策樹 gbdt 和因式分解 fm 架構設計 2.2面向深度學習的推薦系統...
雲時代架構之360推薦系統架構演進
由 amazon 發揚光大的。推薦系統也是現在熱門的人工智慧分支之一，但凡人工智慧類的落地，都需要具備這幾個基本元素才行 資料 演算法 場景 計算力。推薦系統也不例外，而剛好，現在的時代，這些元素的獲得成本相比十年前已經小了很多。未來隨著各種硬體裝置越來越智慧型，萬物互聯得越來越緊密，人們的個性化需...
推薦系統架構
實時性 推薦系統要根據使用者的上下文來實時更新推薦內容，使用者的興趣也是隨著時間而改變的，需要實時更新。其中，前三者是和機器學習沒有任何關係的，但卻是推薦效果最好的三種方式。一般說來，這部分內容應該佔到總的推薦內容的80 左右，另外20 則是對長尾內容的個性化推薦。核心模組 資料路徑 1 請求的重新...