今天談下突發熱門話題對於推薦系統的考驗。內容推薦系統，本質上是一種人物喜好與內容的信息匹配。在大部分情況下，推薦系統可以離線的根據每名用戶的歷史觀看記錄以及每個內容的屬性訓練模型，並且實現推薦。但是，當一個非常熱門的話題爆發了，例如李小璐PGONE事件這樣整個平臺的內容和人們的關注點都會聚焦到一個問題上，究竟會對推薦系統造成哪些影響呢？傲海爲您細細道來。
架構考驗
目前市面上絕大部分的內容推薦都是基於離線計算的架構實現的。離線計算的含義是每天系統把全量數據下載到存儲空間中，對於每個用戶的喜好做計算並把結果反饋給推薦引擎。在離線計算框架下，每個用戶的待推薦內容都是前一天算好的，對於新產生的內容往往沒有那麼強的感知。
但是有的同學會問：“爲什麼我在每個新聞客戶端還是可以看到最新的突發新聞推薦呢？這與離線的推薦架構不符啊？”那是因爲很多內容推薦客戶端爲了防止熱門新聞無法被實時推薦的問題，在給用戶的推薦列表中添加了一部分有利於最新新聞的規則，比如推薦引擎會設定“李小璐PGONE”新聞出現在每個用戶的待推薦列表。這種規則其實並不是一個基於算法的實時推薦實現。
那麼如何做到實時推薦熱門新聞呢？這要求推薦系統需要建立在一個實時計算框架上，目前業內主流的是Flink或者Spark-streaming。在這種框架下實現的流式推薦引擎，數據通過Kafka流入，通過流式框架實時構建新聞特徵，並且代入模型進行推薦排序。
而實時推薦框架相比於離線推薦框架會複雜的多，比如在實時推薦框架下一旦出現數據阻塞或者服務掛掉，failover機制就會比離線系統複雜得多，這點在之後的文章我會再介紹。
性能考驗
前面介紹了計算框架，那麼光有流式框架是不夠的，突發新聞產生後，對於整個架構的性能也有很高要求，因爲這種事件會造成系統中的待推薦內容爆發式增長，更會造成每個用戶的行爲屬性大幅度變更。
在推薦系統中，每個待推薦內容、每個用戶都會通過一個embedding向量表示，這些向量需要全量數據在一起做很多矩陣運算得到。如果系統中突然增加大量的待推薦內容，比如“李小璐出軌”、“PGONE李小璐視頻”、“李小璐PGONE親嘴”，這些新聞會在短時間爆發性增長，系統如果想基於這些內容作推薦，需要在短時間內消耗大量的計算量去做內容的embedding。
對於每個用戶來講，行爲屬性也很有可能在短時間內大幅度改變，比如A用戶之前可能不是一個很八卦的人，關心的內容都是養生、軍事、科技。突然A發現李小璐出軌這個事很好玩，然後大範圍查看相關娛樂新聞。對於A的embedding向量需要重新計算才準確。諸如此類的計算能力，也是事實計算系統能否完成基於熱點內容推薦的關鍵。
寫到最後~每次這種喫瓜事件出來，都是對各個推薦系統的一次大考，大家可以用心看下哪家的推薦系統推薦的最符合你對這個瓜的預期，用心去感受推薦系統的魅力，謝謝~