「建構企業級推薦系統系列」實時個性化推薦介紹

作者 | gongyouliu

編輯 | auroral-L

随着網際網路的深入發展和産品布局的多元化，越來越多的企業通過提供快節奏的産品及服務消耗使用者的碎片化時間，進而赢得使用者的青睐。這類産品通過便捷的UI互動來跟使用者進行實時互動，在極短的時間内給使用者“獎賞”，讓使用者欲罷不能，根本停不下來。這類産品普遍用到的一個技術就是實時個性化推薦技術。

相比于傳統的個性化推薦每天更新使用者的推薦結果，實時推薦基于使用者最近幾秒的行為實時調整使用者的推薦結果。實時推薦系統讓使用者當下的興趣立刻回報到了推薦結果的變化上，可以給使用者所見即所得的視覺體驗，它牢牢地抓住了使用者的興趣，讓使用者沉浸在其中。實時推薦技術大量用于現在的主流産品上，基本上你常用的網際網路APP的核心推薦算法都已經實時化了，包括頭條、淘寶、快手、B站等等，毫不誇張地說實時推薦是推薦系統未來的發展趨勢。

在本篇文章中，我們就來講解實時個性化推薦相關的知識點。具體來說，我們會從實時推薦系統背景介紹、實時推薦系統的價值、實時推薦系統的應用場景、實時推薦系統的整體架構、實時推薦系統的技術選型、實時推薦算法與工程實作介紹、建構實時推薦系統面臨的困難與挑戰、實時推薦系統的未來發展等8個方面來進行講解。期望本文可以幫助讀者全方位地了解實時推薦系統相關的業務、原理與技術細節，本文可以作為讀者學習和建構實時推薦系統的參考指南。

一、實時推薦系統背景介紹

所謂實時推薦系統，就是根據使用者目前行為或者使用者的主動操作(如下拉、滑動等)，推薦系統實時更新展示給使用者的推薦結果，前端快速反應使用者的興趣變化，給使用者視覺上的沖擊與強感覺。大家比較熟悉的實時推薦系統是今日頭條、抖音、快手上的推薦(參見下面圖1)，通過下拉或者上下滑動來實時更新推薦清單。如果實時推薦的結果采用瀑布流的形式呈現給使用者，一般也将實時推薦稱為資訊流推薦，如今日頭條推薦、微信朋友圈“看一看”等都可以這麼叫。

圖1：今日頭條、抖音、快手上的實時推薦

實時推薦系統不是一種新的推薦算法(當然會對算法進行适當的調整優化，以适應實時性的需要)，而是一種新的推薦形态，一種新的工程架構，是将傳統的T+1(按天)推薦調整為秒級推薦，是處理效率的極大提升。處理速度提升了，當然對算法、工程架構、互動方式也提出了新的要求。

任何事情的出現和發展一定是有相關背景的，實時推薦也不例外，我認為主要有如下幾個原因導緻實時推薦的出現和火爆：

1.技術的進步

首先是智能手機的普及和攝像技術、無線網絡的發展，讓每個人都成為資料生産方，我們時時刻刻都在制造資料。資料量的爆發增長，推動了大資料與雲計算技術的出現和發展。大資料和雲計算讓我們可以更快、更便捷、更高效地處理大規模的海量資料，實時資料處理成為可能，這是實時推薦系統出現的先決條件。

2.産品的“快消”化、使用者時間的碎片化

新技術本身就是一種資源，是以一般一種新技術出現會帶來非常大的紅利期，出現一段較長時間的技術應用爆發期。在新紅利的刺激下，越來越多的創業者尋找機會和突破，期望從紅利中分一杯羹。技術催化了各種各樣的産品，像頭條、快手、抖音等無不都是在這樣的背景下産生的。這類産品有一個特點，屬于“快消類”産品(使用者消費一個标的物所花時間較短)，消費的也是使用者的碎片化時間，使用者在地鐵上、公交上、吃飯排隊、甚至上廁所都可以高效使用這類産品。産品的“快消”化、使用者時間的碎片化，這要求産品需要實時響應使用者的需求，對使用者的行為作出及時回報，這正是實時推薦系統擅長的方向，因而實時推薦最早在這些産品上出現就不足為奇了。

3.人機互動方式的便捷性

觸屏技術的發展，讓使用者與産品互動更加友善快捷，互動可以在瞬間完成，毫無障礙，無任何學習成本。快捷的互動自然要求産品可以進行快速的響應，這也間接催生了實時推薦技術的普及和發展。

4.人天生喜歡動态變化的東西、人的需求也越來越主動

移動網際網路時代，使用者每時每刻都線上。人的大腦是無法停下來的(即使是睡着了，也在做夢，大腦也沒停)，一定要注意到一件事情，這就是人的注意力，靜止不變的東西是很難吸引使用者興趣的，實時推薦對使用者回報做實時調整，是動态變化的過程，更容易吸引使用者的關注。年輕一代更希望對生活有控制權，對産品也一樣，希望自己可以把控産品的互動邏輯和結果展示，實時個性化推薦的這種下拉更新推薦結果的方式就很自然地将控制權交給了使用者。

5.資訊産生的速度更加快速

前面提到攝像頭技術的發展等讓資訊産生的速度按照指數方式增長，資訊産生的速度遠大于人類消費資訊的速度。而實時推薦提升了資訊分發的效率，可以讓資訊得到更加有效的分發與利用，是以也是提升資源使用效率的一種方式。

6.激烈的産品競争

當移動網際網路紅利結束之時，沒有太多新的流量注入，所有的産品在争奪固有的流量，産品之間的競争愈發激烈，誰能更好地服務使用者，誰就能在激烈的市場競争中赢得主動權。實時個性化推薦由于跟使用者的實時互動性，可以更好地滿足使用者的需求，讓使用者沉浸在其中，是以可以極大地提升使用者的體驗，這讓實時推薦技術成為産品争奪使用者和流量的有力武器。

實時推薦是技術發展和産品疊代的必然趨勢，也是人類自身訴求滿足的有效方式，這隻是實時推薦技術出現和發展的必要條件。實時推薦之是以這麼火爆，成為當今絕大多數産品的标配，并且也是推薦系統未來發展的趨勢，是因為實時推薦系統極具價值。實時推薦是非常有業務價值的，這就是我們下節要講解的内容。

二、實時推薦系統的價值

實時推薦系統通過降低使用者的行為和系統的回報之間的時間間隔，讓使用者可以馬上享受到自我行為的獎賞，這本身就是一種使用者價值的展現。具體來說，實時推薦系統的價值至少可以從如下4個次元來展現。

1.提升使用者體驗，提升使用者的滿意度

在實時推薦系統中，使用者可以實時與推薦子產品互動，推薦模型實時給使用者做出回報，提升了使用者與産品互動的頻率。使用者的每次互動都帶來了新的刺激，這讓使用者更願意沉浸在其中，進而滿足了使用者的某種心理需求，而使用者需求滿足的程度決定了使用者對産品的滿意度。是以，實時個性化推薦一定是可以提升使用者滿意度的。

2.提升使用者粘性，提升使用者使用時長

從産品來看，實時推薦可以讓使用者實時獲得回報，使用者的需求得到即刻的滿足，這讓使用者非常興奮，停不下來，不知不覺中花了大把的時間，消費了大量的内容。總體來說，提升了使用者的粘性，讓使用者更願意駐留更多的時間。

3.增加内容的曝光、分發與消費

實時個性化推薦大大提升了内容的流轉效率，可以更快地将内容分發到每個使用者手中，直覺地呈現在使用者眼前，内容不再是沉入資訊海洋的石塊，而是高效流轉的“寶藏”。分發效率的提升，讓内容制作方可以得到更多的曝光，獲得更多使用者的關注。更多的曝光和更多的粉絲，當然可以通過變現産生不菲的商業收入。

4.增加産品的商業化能力

實時推薦增加了内容的曝光機會，提升了标的物的流轉效率，讓單個推薦位的點選和轉化大大提升。好的實時推薦能夠抓住使用者的眼球，讓使用者沉浸其中，提升了使用者購買商品(如果是電商實時推薦)的機率。即使是今日頭條這類提供非賣品标的物的産品，實時推薦中還可以整合資訊流廣告，讓更多的廣告得到曝光，進而增加廣告的CPM，這也是一種價值變現的好方式。

正因為實時推薦的巨大價值，讓當今的網際網路産品開發者非常心動，期望在自己的産品中整合實時推薦功能。那麼實時推薦可以用到哪些産品中呢？這就是下節要分享的主要内容。

三、實時推薦系統的應用場景

實時推薦系統根據使用者的當下行為作出快速回報，給使用者提供所見即所得的推薦，這一般也要求使用者的行為是可以在短期内完成的，即使用者”消費“一個标的物不會花很長時間。推薦系統需要在短期内就知道使用者是否對該标的物感興趣，才能基于使用者行為給使用者實時回報。

基于上面的分析，我認為“内容”消費完所花時間較短，使用者希望短時間擷取資訊的産品比較适合實時推薦，即提供“快消“類标的物的産品是比較适合做實時推薦的，而像長視訊、小說閱讀等APP是不太适合做實時推薦的。拿電影來說，使用者看完一個電影需要花費2個小時左右，很大機率使用者沒有時間再接着去看另一部喜歡的。如果該電影使用者看了幾分鐘就退出來了，這頂多算負回報，沒有正回報(使用者看完了或者看了很長時間)，我們也沒法給使用者實時推薦他喜歡的，這也是這類産品不太适合做實時推薦的原因。

前面已經提到長視訊類、小說閱讀類不适合做實時推薦。下面我們來列舉一下适合做實時推薦的常用産品形态，給讀者提供一個參考。适合做實時推薦的産品主要包括如下6大類别：

1.新聞資訊類

使用者閱讀一條文本新聞時間一般不會很長，幾分鐘就夠了，是以是滿足做實時推薦條件的。如今日頭條、騰訊新聞、網易新聞、趣頭條、手機百度APP資訊流等等都提供了實時推薦的能力。

圖2：今日頭條、網易新聞、手機百度APP通過下拉滑動為使用者提供實時個性化新聞推薦

2.短視訊類

短視訊也是一類時長較短的産品，滿足“快消”産品的特性，是以是實時推薦非常好的應用場景，目前主流的短視訊應用，如快手、抖音、好看視訊、哔哩哔哩等都提供了實時推薦形态。

 圖3：快手、抖音、B站首頁通過下拉滑動為使用者提供實時個性化推薦

3.婚戀、陌生人社交類

對于婚戀、陌生人交友類軟體，使用者隻要對陌生人的長相或者相關簡介有個基本了解就可以決定要不要聊下去，決策時間不需要很長，是以是适合做實時推薦的。像世紀佳緣、陌陌、探探等都提供了實時推薦能力。

圖4：陌陌、世紀佳緣、探探上下滑動或者通過左右滑動來選擇感興趣的人

4.直播類

直播類雖然播放時長會很長(很多主播一次性可能直播幾個小時)，但使用者隻要進去看幾分鐘就可以知道是不是自己喜歡的類型了，是以直播類也是适合實時推薦的，像鬥魚、虎牙、映客等在首頁就包含實時推薦子產品。

圖5：鬥魚、虎牙、映客首頁通過下拉滑動為使用者提供實時個性化推薦

5.電商類

電商類APP，如手機淘寶、京東、拼多多，首頁都提供了實時推薦的能力，使用者隻要下拉重新整理，系統會自動重新整理給你的推薦結果。一般使用者決定是否要買一個商品也不需要投入很多的時間決策，看下圖檔和詳情頁簡介就知道了。是以，電商類産品是适合做實時推薦的。

圖6：淘寶、京東、拼多多首頁通過下拉滑動為使用者提供實時個性化推薦

6.音樂、電台類

音樂類、電台類APP，使用者消費一首歌也就幾分鐘，也是滿足實時推薦場景的，下面這3個APP都提供了實時推薦的能力。

圖7：喜馬拉雅、酷狗音樂、豆瓣FM上的實時個性化推薦

我們在上面基本列舉了市面上主流的提供了實時推薦能力的APP，這些APP都滿足我們前面提到的可以做實時推薦的條件。當然這個條件不是絕對的，需要根據具體的應用場景和限制條件再綜合分析。我們電視貓上在首頁就提供了長視訊的近實時推薦，電視貓的産品應用于家庭場景中，家中一般多人使用，使用者平均使用時長比手機長得多，操作主要靠遙控器，操作相對手機端極為不便，并且使用者可以一鍵(傳回鍵)回到首頁，這些條件導緻首頁暴露給使用者是比較頻繁的。是以，基于上面幾個特點，我們在首頁提供近實時回報的興趣推薦，隻要使用者看過某些視訊時長達到一定值(我們認為使用者喜歡)就更新興趣推薦。

圖8：電視貓首頁近實時回報的興趣推薦子產品

這裡最後還要提一點，即使你的産品适合做實時推薦，實時推薦産品一定要放到首頁這種使用者觸點多的位置，不然很難最大化發揮個性化推薦的價值。想象一下，你将實時個性化推薦産品安放到一個非常隐蔽的地方，使用者很難找到，即使你推薦的再準有什麼用呢？好的東西就是要讓使用者多使用，使用者的回報就是推薦模型的資料源，使用者和産品互動的過程是一個正向的回報環，互動越多，收集的資料就越多，基于這些資料訓練出的推薦模型就越精準，通過使用者與(實時推薦)産品的協同進化，推薦會越來越有商業價值。

四、實時推薦系統的整體架構

實時推薦系統需要基于使用者的實時回報行為來近實時更新使用者的推薦結果，是以需要對推薦算法進行實時調整，實時資料處理與實時模組化一定是實時推薦系統中最重要的一種技術。目前，推薦系統一般應用于提供toC服務的網際網路産品中，這類産品使用者基數大，資料量多，一般需要大資料平台來進行處理，對資料進行ETL、構模組化型特征，我們這裡講解的實時推薦系統的整體架構是建立在大資料技術基礎上的。

在大資料的發展史上先後出現了兩種資料處理的架構，這兩種架構剛好也是實時推薦系統算法建構的原型，下面我們分别對這兩種架構進行介紹，并說明怎麼基于這兩種架構來建構實時推薦系統。

1.Lambda架構

目前的主流大資料平台一般将使用者行為日志分為離線部分和實時部分(參見下圖)。離線部分進入數倉供離線任務進行處理，包括各種按天統計的報表、T+1的推薦業務(非實時推薦，一般每天更新一次)。實時部分一般進入消息隊列(如Kafka)，供實時處理程式消費，如各類實時監控、大屏展示報表等。

圖9：主流大資料平台将日志分别通過批和流兩種邏輯進行分發，供不同業務處理

Lambda架構(見參考文獻1)就是上面這種思路的高度抽象，它是著名的流式處理架構Storm的作者Nathan Marz最先提出來的。Lambda架構一般分為3個子產品：Batch Layer、Speed Layer、Serving Layer，Batch Layer負責處理離線的大規模資料，Speed Layer負責處理實時收集到的使用者行為資料，而Serving Layer将離線和實時兩部分結果基于一定的規則或算法進行彙集、排序，并最終對使用者(既可以是終端使用者也可以是公司内部的其他業務部門)提供服務，下圖即是Lambda架構的抽象業務處理邏輯。

圖10：Lambda架構示意圖

一般使用者行為資料從底層的資料源開始，按照一定的資料規範和協定(比如采用Json格式)進入大資料平台，在大資料平台中經過Kafka、Logstash等資料元件進行收集，然後分成兩條線進行計算。一條線是進入流式計算平台（例如 Storm、Flink或者Spark Streaming），計算一些實時名額或訓練實時模型；另一條線進入批量資料處理離線計算平台（例如Map Reduce、Hive，Spark SQL等），計算T+1的相關業務名額或者訓練離線模型，這些名額或者模型(結果)需要第二天才能算出。

Lambda架構曆經多年發展，其優點是穩定，對于實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體規劃。将實時計算和離線計算高峰分開，可以極大化利用伺服器資源，減少對使用者的影響，這種架構支撐了資料行業的早期發展，但是它也有一些缺點，這些缺點導緻Lambda架構不适應部分資料分析業務的需求，具體缺點如下：

• 實時與批量計算結果不一緻引起的資料口徑問題：因為批量和實時計算走的是兩套計算架構，使用的是不同的計算程式，算出的結果往往不同，特别是對于那些累積的名額，時間長了容易産生誤差。是以，需要一套完善的機制來保證計算的一緻性，糾正資料偏差。

• 批量計算在計算視窗記憶體在無法算完的風險：在IOT時代，資料量級越來越大，經常發現夜間隻有4、5個小時的時間視窗用于離線計算，已經無法完成白天20多個小時累計的資料計算。怎麼保證早上上班前準時出資料報表已成為大資料團隊頭疼的問題。叢集之間不同作業之間的依賴關系及資源占用等更加劇了這種情況的發生。

• 資料源變化都要重新開發，開發周期長：每次資料源的格式變化，業務的邏輯變化都需要針對ETL和Streaming做開發修改，整體開發周期很長，業務反應不夠迅速。

• 伺服器存儲大：資料倉庫的典型設計，會産生大量的中間結果表，造成資料急速膨脹，加大了伺服器存儲壓力。

上面對Lambda架構進行了初略的介紹，那麼下面我們來講解怎麼基于Lambda架構來建構實時個性化推薦系統，我們先給出架構圖(見下面圖11)，這裡包含離線算法子產品(對應Lambda架構中的Batch Layer)、實時算法子產品(對應Lambda架構中的Speed Layer)、融合子產品(是Lambda架構中Serving Layer抽取出來的一部分，對于推薦算法來說，它比一般的資料處理更複雜，為了減輕Serving層的壓力，将複雜的與業務邏輯相關的計算操作獨立出來形成一個單獨的子產品)，下面我們來逐一說明各個子產品的作用。

圖11：基于Lambda架構的實時個性化推薦算法架構

• 離線算法子產品

離線算法子產品基于使用者長期行為資料訓練召回模型和排序模型，最終生成離線推薦結果。離線部分由于使用的是曆史資料，每天更新一次，模型可以較複雜，隻要在一天之内計算完成即可，最終算出的是基于使用者曆史興趣的推薦結果。

• 實時算法子產品

實時算法子產品基于使用者最近的興趣來獲得給使用者的推薦，比如可以基于使用者最近一次操作的标的物，召回與該标的物最相似的标的物作為召回結果，後面可以基于使用者整體興趣對召回的标的物進行排序，獲得使用者的近實時推薦結果。

• 融合子產品

融合子產品基于給使用者的離線推薦結果和實時推薦結果，通過利用合适的業務規則、政策以及複雜的排序算法對推薦結果進行排序，獲得給使用者的最終推薦。

混合子產品的具體實作方式可以多種多樣，上面提到的是其中的一種，還可以基于生成的離線推薦結果，實時推薦基于近期興趣讀取并更新離線推薦結果獲得最終的推薦。在電視貓中部分實時推薦就是采用的該方式：離線推薦結果插入CouchBase推薦庫，實時推薦程式獲得使用者最後播放記錄的相似視訊，然後從CouchBase中讀取該使用者的推薦結果，将剛剛計算好的相似視訊(基于一定規則)替換掉取出的推薦結果的部分視訊，再插入CouchBase，進而修改了推薦結果，獲得實時推薦的效果。

對于業務規則比較簡單的情況，可以将融合子產品放到Web Server中(見下面圖12)，整體架構跟上面介紹的類似，隻不過這裡事先計算出離線推薦和實時推薦結果，最終在Web Server中對兩類推薦結果進行聚合，而上面介紹的是将集合過程獨立出來成為一個子子產品。

圖12：在web server中進行融合的實時推薦業務架構圖

上述方法還可以進行适當的改進，就是首選利用曆史資料訓練好召回和排序模型，按照上面架構部署，等推薦業務跑起來後，直接就接入實時資料流，不需要再處理曆史資料了(因為模型已經基于曆史資料進行了訓練)，在實時流運作的過程中可以逐漸疊代優化召回和排序模型。這裡需要對模型進行實時學習更新，我們将這種學習過程稱為增量學習。增量學習利用了最新的使用者行為資料，一般可以穩定提升模型性能。在生産實踐中，增量學習根據增量的時效性有三種不同粒度，其中T+1增量模式是，load已有模型的checkpoint，采用批訓練模式，模型全量部署上線，更新時效性為天級别，小時級增量模式是，使用實時樣本進行流式訓練，但部署過程依舊采用全量模型切換，更新時效性為小時級。第三種(也是最完美的)增量學習解決方案是流式訓練模型、實時用于模型預測，這種方案就不用離線子產品了，這就是我們下面要講到的Kappa架構了。

Lambda架構采用分而治之的思路通過将使用者行為分為離線部分和實時部分，分别進行處理和模組化，最終再彙聚兩部分的資訊獲得最終的結果。對于目前的實時推薦，Lambda架構是一種可行有效的實施方案。結合前面介紹的Lambda架構的缺點及作者自己實施實時推薦的經驗，對于實時推薦系統，Lambda架構最大的問題主要有如下三點：

• 實時處理和離線處理是不同的技術，實作離線推薦和實時推薦的子產品需要采用不同的代碼來實作，開發和維護成本明顯偏高。
• 在銜接實時推薦和離線推薦時，會存在資訊的備援或者缺失。離線推薦處理的資料到今天零點，而最理想的狀态是實時從零點開始對目前所有的使用者資訊進行處理和模組化，而在具體實施時，有各種問題、限制導緻資料的銜接存在斷檔或者重複使用的情況。
• 在最終給使用者推薦時，需要融合實時推薦結果和離線推薦結果，進一步增加了流程和複雜度。

鑒于上述問題，我們可以采用一套統一的處理架構，這就是下面我們要介紹的Kappa架構。

2.Kappa架構

Kappa 架構是LinkedIn的Jay Kreps結合實際經驗和個人體會，針對Lambda架構進行深度剖析，分析其優缺點并采用的替代方案(讀者可以檢視參考文獻2，對Kappa架構進行更深入了解)。Lambda 架構的一個很明顯的問題是需要維護兩套分别跑在批處理和實時計算系統上面的代碼，而且這兩套代碼需要緊密配合，對增量求和統計還得産出一樣的結果。是以對于設計這類系統的人來講，要面對的問題是：為什麼我們不能改進流計算系統讓它能處理這些問題？為什麼不能讓流系統來解決資料全量處理的問題？流計算天然的分布式特性注定其擴充性比較好，能否加大并發量來處理海量的曆史資料？基于種種問題的考慮，Jay提出了Kappa這種替代方案。

Kappa架構通過剔除Lambda架構中的批處理部分簡化了Lambda架構。為了取代批量處理，資料隻需通過流式計算系統快速加工處理。Kappa體系結構中的規範資料存儲不是使用類似于SQL的關系資料庫或類似于Cassandra的鍵值存儲，而是一個隻能追加資料的不可變日志系統。從日志中，資料通過計算系統流式傳輸，并輸入輔助存儲器作為字典庫供服務使用。典型的Kappa架構如下圖：

圖13：Kappa架構

Kappa架構的核心思想，包括以下三點：

• 用Kafka或者類似MQ隊列系統收集各種各樣的資料，你需要幾天的資料量就儲存幾天到消息隊列中。
• 當需要全量重新計算時，重新起一個流計算執行個體，從頭開始讀取資料進行處理，并輸出到一個新的結果存儲中。
• 如果需要對業務流程和計算邏輯調整，重新開機一個新的計算執行個體，當新的執行個體做完後，停止老的流計算執行個體，并把老的一些結果删除。

Kappa架構的優點在于将實時和離線代碼統一起來，友善維護而且統一了資料口徑的問題。而Kappa的缺點也很明顯：

• 流式處理對于曆史資料的高吞吐量力不從心：所有的資料都通過流式計算，即便通過加大并發執行個體數亦很難适應IOT時代對資料查詢響應的即時性要求。
• 開發周期長：在Kappa架構下由于采集的資料格式的不統一，在對資料進行調整或相容時每次都需要開發不同的Streaming程式，導緻開發周期長。
• 伺服器成本浪費：Kappa架構的核心實作需要依賴外部高性能存儲Redis、HBase等服務作為中間存儲器。但是這2種系統元件，又并非專門設計來滿足全量資料存儲的，會占用較多的記憶體及CPU資源，對伺服器成本有較大浪費。

上面我們對Kappa架構進行了簡單介紹，那麼基于Kappa架構怎麼建構推薦系統呢？其實這個問題是比較簡單的，Kappa架構簡化了Lambda架構，隻保留了實時處理部分，針對推薦系統也是一樣的。Kappa架構建構推薦系統隻做實時推薦部分，具體架構圖見下面圖14。

圖14：基于Kappa架構的實時個性化推薦算法架構

按照上面架構部署好推薦業務，算法在剛剛啟動時，先将所有離線資料一次性按照實時流的方式灌入，逐漸線上學習召回和排序模型，等曆史資料處理好了，就直接處理流式資料了，最終變成了流式處理。這裡需要強調的一點是，召回和排序模型是一個逐漸學習和訓練的過程，這對模型是有一定要求的，有些模型是不适合這樣訓練的。我們在電視貓的業務中對短視訊的實時相似推薦就采用了這種模式，由于我們計算相似度是基于标簽來計算的，就是簡單的向量相似度計算，模型不複雜是可以采用上面的方法的。

另外一種方式是模型訓練好，直接部署上去，根據使用者最近的行為實時建構最新的特征向量，将新特征向量灌入模型，獲得新的推薦。為了利用最新的資料，模型還可以隔一段時間重新訓練一次。TensorFlow Serving就是采用的該模式，并且模型可以熱更新，這類模型一般也是比較複雜的模型，如深度學習模型等。這裡不是從零開始學習模型，而是預訓練讓模型有一個很高的起點，再從起點開始學習。訓練模型的過程中也用到了離線技術，是以模糊了跟Lambda架構的關系。

目前強化學習(強化學習是智能體（Agent）以“試錯”的方式進行學習，通過與環境進行互動獲得的獎賞指導行為，目标是使智能體獲得最大的獎賞)在大的網際網路公司已經部分用在推薦業務中(見參考文獻10)，強化學習這種跟環境進行實時互動的學習範式本質上就是Kappa架構。

上面我們講到的實時推薦的Lambda架構和Kappa架構都是采用了事先将推薦結果計算出來的方式，這屬于事先計算型，實際上也是可以采用實時裝配型的，對這兩種推薦系統提供web服務的方式，讀者可以參考《推薦系統提供web服務的2種方式》這篇文章進行詳細了解，這裡不贅述。

上面我們對目前主流的兩種實時推薦架構進行了說明，并沒有講相關的具體工程技術，我們在下一節對相關技術進行介紹。

五、實時推薦系統的技術選型

實時推薦系統與實時大資料處理密不可分，是以建構實時推薦系統的技術一定是離不開實時大資料技術的，目前比較主流的實時大資料處理架構主要有Spark Streaming， Flink 、Storm等，這些架構都可以用于做實時推薦。基于實時推薦的兩種實作架構Lambda和Kappa，這裡會涉及到離線處理和實時處理(Lambda有離線處理子產品而Kappa沒有，不過Kappa中涉及到的模型也會進行離線訓練)，下面我們分别從離線處理和實時處理的技術選型來分别介紹。

1.離線部分算法的技術選型

離線部分可以選擇的工業級技術有Spark、MapReduce、TensorFlow等。MapReduce由于對疊代運算不是很友好，不太适合複雜的機器學習模型，建議還是采用Spark和TensorFlow。

Spark中包含很多資料ETL算子和算法庫，很多算法可以直接使用，Spark MLlib中直接有ALS矩陣分解推薦算法，其他推薦算法也可以基于Spark的API自行開發。針對複雜的深度學習算法目前是不太适合在Spark上運作的，Spark的新版本3.0應該會增加對深度學習更好的支援。

TensorFlow可以實作非常多的複雜算法，在工業界也非常流行。不過TensorFlow的分布式計算沒有Spark這麼友好。一般企業是基于Hadoop/Spark來建構大資料平台的，如果利用TensorFlow來實作部分算法的話，是需要打通大資料與TensorFlow兩套體系的。

基于上面的分析，作者建議如果在人力不足或者不是非用TensorFlow不可的情況下，還是采用Spark平台更合适，大資料和推薦兩套業務共用了一套架構體系，技術棧更加統一簡單。

2.實時部分算法的技術選型

實時部分可以采用的技術非常多，常見的有Storm、Flink、Spark Streaming等。目前Storm沒有以前那麼流行了，建議還是采用Flink和Spark Streaming這兩套中的一種。如果你們團隊已經在使用Spark了，開始做實時處理或者實時推薦業務，那最好還是用Spark Streaming，畢竟都是Spark一套體系，API規範都保持一緻，技術棧也更統一。Spark Streaming雖然實時性方面不如Flink，但是對于實時推薦來說，做到秒級實時就足夠了。

作者公司最早是基于Hadoop/Spark體系來建構大資料的，順其自然地推薦系統也是基于Spark來建構的，最近幾年開始做實時推薦，也是采用Spark Streaming架構，目前看下來，整套架構都可以很好地處理離線推薦、實時推薦等各類推薦場景。

這些架構目前在雲計算公司都有現成的PAAS或者SAAS服務可供選擇，對于初創團隊或者剛開始啟動推薦業務的團隊，建議可以采買相關雲服務，這樣整個系統更加輕量，維護成本低，團隊應該将核心放到業務和算法上。

六、實時推薦算法與工程實作介紹

在第四第五節我們介紹了實時推薦系統的架構和技術選型，有了這些基礎準備我們就能夠非常友善地開發實時推薦算法了。推薦算法是推薦系統中最核心的元件之一，在本節我們就來講講有哪些可以用于實時推薦的算法。這裡我們講的實時推薦算法是指可以利用流資料來訓練，可以進行線上學習的推薦算法，而不關注Lambda架構中離線部分的推薦算法。

我們在前面的推薦算法系列文章中部分講解了實時推薦算法的工程實作，這裡将相關資源列舉出來，讀者可以進行有針對性地學習和了解。

1.實時協同過濾算法

《協同過濾推薦算法》第四節“近實時協同過濾算法的工程實作”對實時協同過濾算法進行了詳細講解，這裡采用的是利用Spark Streaming和HBase作為算法實作和存儲的工具。

2.實時矩陣分解算法

《矩陣分解推薦算法》第五節“近實時矩陣分解算法”對騰訊在2016年發表的一篇基于Storm來實作的近實時矩陣分解的算法原理及工程實作細節進行了介紹。

3.實時因子分解機

《因子分解機》第六節“近實時分解機”有對分解機實時實作的簡單介紹，其中給了很多參考文獻，可以作為讀者學習的參考資料。

4.基于内容推薦的實時算法

基于内容的推薦，不需要其他使用者的行為，隻需學習到待推薦使用者的興趣偏好特征就可以給使用者進行推薦了，相比協同過濾類算法更簡單更容易實作，是以也是非常适合做實時推薦的。

業界比較出名的線上學習算法FTRL(Google最早提出，見參考文獻6)，可以實時訓練很多機器學習算法(如logistic回歸)，可以與推薦系統的排序階段。目前比較熱門的深度學習技術也可以進行線上學習，讀者可以閱讀參考文獻4、5進行了解。在工業界，螞蟻金服的AI團隊對TensorFlow的底層架構進行了修改優化(見參考文獻9)，使之适應實時學習，并在支付寶的推薦業務中得到了很好的應用。

參考文獻7、8分别介紹了鳳凰新聞和愛奇藝的實時推薦的工程實作細節，讀者可以參考。另外參考文獻3比較詳細介紹了Netflix的推薦系統的工程實作介紹，其中也包括實時實作部分，采用的是Lambda架構的模式。Netflix推薦系統是業界做得非常好的典範，值得讀者深入了解。從這篇參考文獻也可以看到要做好實時推薦系統是非常複雜的，需要面臨非常多的技術、工程挑戰，在下一節我們就會對這方面進行詳細介紹。

七、建構實時推薦系統面臨的困難和挑戰

實時推薦系統需要實時處理使用者行為，并基于使用者行為給使用者提供近實時的推薦，時間上的及時響應，對整個推薦系統的架構、算法都提出了極高的要求。設計實時推薦系統面臨的挑戰主要展現在如下幾個方面：

1. 算法架構

實時推薦系統需要實時收集使用者行為，對使用者行為進行實時ETL處理，實時挖掘使用者興趣變化，實時訓練模型，實時更新推薦結果。對資料分析處理、資料存儲、接口通路等需要提供基礎能力支撐。整個推薦過程是一個相當長的鍊路，每一個環節都不能出錯，對資料處理和分析響應的及時性要求極高。

2. 算法模型

對于線上學習類的推薦算法模型，建構實時推薦系統還需要模型層面的支援，不管是召回還是排序，都需要能夠相容實時資料，能夠實時訓練。傳統的算法是不滿足條件的，比如Logistic回歸就不适合用于實時訓練，它通過改進後的FTRL是可以進行實時訓練的。

3. 産品互動

實時推薦的結果需要以使用者易于了解和操作的方式展現給使用者，是以需要設計一個良好的産品互動界面，讓使用者易于了解，易于操作，更好地感受到個性化推薦帶來的價值。像今日頭條首創的下拉的互動産品形态就是比較好的一種實時互動形态，使用者完全掌握主動權，不喜歡就滑一滑獲得新的一批推薦。

總之，實時推薦系統是一個複雜的體系工程，我們需要在算法架構、算法模型、産品互動等多個方面做得出色才能打造出一個使用者體驗好、有商業價值的實時推薦系統。

八、實時推薦系統的未來發展

前面對實時推薦相關的産品、架構、算法等進行了深入的介紹，我們知道了實時推薦的價值和面臨的挑戰。很多公司的推薦産品也進行了實時化改造，充分享受到了實時推薦給産品帶來的紅利。實時推薦是随着移動網際網路的起步和發展逐漸發展成熟起來的，曆史不超過10年，未來實時推薦還有很大的發展空間。在本節作者基于自己的了解來對實時推薦的未來發展進行一些預判和思考，希望給讀者提供一些參考和借鑒。

1.實時推薦是未來推薦發展的方向

實時推薦可以跟使用者進行更加及時、高效地互動，有利于使用者更好地使用産品，使用者體驗也更加真實自然，是以相比傳統的T+1推薦系統更具商業價值。未來越來越多的企業會意識到實時推薦的價值，實時推薦一定是未來推薦系統發展的重點方向之一。

随着網絡基礎設施在世界更廣泛的範圍覆寫，越來越多的人會享受到資訊技術帶來的紅利，實時推薦系統也會覆寫到更多的人群。5G技術的發展，讓人們擷取資訊更加友善及時，複雜的多媒體資訊也可以在瞬間完成下載下傳和上傳，雲計算、AI技術的發展可以讓更多的複雜高效算法應用于實時推薦，這些基礎技術條件的成熟驅動着實時推薦朝着更流行、更普及、更精準的方向發展。

另外，社會的發展也讓人類趨向于越來越個性化，人們期望更好地表達自我、滿足自我，實時推薦可以讓使用者獲得主動權和控制權，獲得更加及時的回報。資訊的生産也将更加實時、多樣、龐雜，這些資訊的分發和消費問題都可以利用實時推薦來很好地解決。

2.每個人有望擁有為自己服務的個性化算法

目前所有的實時推薦算法都是在雲端部署，終端通過跟雲端互動獲得個性化推薦，這種方式會受到網絡等多種外界因素的影響，對于及時跟使用者互動是有一定副作用的。随着晶片技術和AI技術的進步，目前邊緣計算是非常火的一個領域，邊緣計算是在終端上直接完成計算，盡量不與或者少與雲端互動，這極大地提升了處理的效率，受到網絡等其他因素的影響也會更少，像無人駕駛這類技術的成熟是非常依賴邊緣計算技術的進步的。

對于實時推薦系統，在雲端實時處理龐大海量的使用者資訊為使用者進行推薦已經非常費力，在終端完成這個事情是一種比較有創意的想法。具體的做法可以是先在雲端基于全量資料離線訓練一個複雜的模型，并将該模型同步到終端，終端基于該模型和使用者的實時互動資訊，實時優化該模型，讓該模型跟着使用者的行為一起進化，最終越來越适配使用者的興趣特征。

圖15：在終端上增量學習模型，為使用者提供更加個性化的實時推薦

上面這種部署實時推薦算法的方式，更容易做到實時化，不受網絡因素的影響，同時模型也是為使用者量身打造的，更滿足使用者口味。當然，這對終端性能、存儲能力、模型實時訓練等提出了很高的要求。但不可否認，這一定是一個值得嘗試的，有巨大應用價值的方向。TensorFlow Lite已經朝着這個方向邁進了一大步，TensorFlow Lite 允許使用者在多種裝置上運作 TensorFlow 模型。在資料庫方面，CouchBase也提供了CochBase Mobile解決方案，讓移動端的資料存儲跟雲端可以做到實時關聯。

基于上面的介紹，我是非常看好實時推薦在終端上的部署的，雖然目前在業界沒有成熟的終端推薦解決方案，但我相信那些有前瞻性思維的公司一定是在朝着這個方向嘗試的。

3.實時推薦應用場景的多樣性

目前實時推薦系統主要應用于移動端，随着物聯網和智能家居的發展，更多的智能終端産品如雨後春筍般出現，實時推薦系統一定會落地到更多的産品、應用到更多的場景中。

我們公司的産品電視貓應該是業界比較早将實時推薦系統應用于家庭大屏中的，目前在短視訊、首頁長視訊推薦都做到了實時化，并産生了巨大的業務價值。智能電視上的實時推薦應用目前隻是起步階段，當華為、OPPO等大廠入局家庭大屏，一定會帶來更多的新應用，這時實時推薦就會蓬勃發展起來。

在智能音箱、車載系統上，由于互動方式的變化(這些系統一般用語音進行互動)，對産品形态有極大影響，目前作者還沒有看到在這些硬體上有相關的智能推薦形态出現。由于互動方式的限制以及可能沒有螢幕，這些硬體上如果有推薦形态，那也一定會采用實時推薦的模式。

4.實時互動方式趨于多元化

目前移動屏上的實時推薦産品，使用者都是通過滑動觸摸的方式跟推薦系統互動的，這種互動方式是非常自然友善的，正因為友善的互動才讓實時推薦有如此大的爆發力。

在智能電視上的互動目前主要靠遙控器，作者在電視貓上部署的實時興趣推薦(參見第三節的圖8)，由于是長視訊推薦及遙控器互動的限制，目前沒有直接的使用者互動，當使用者看一個節目再傳回到興趣推薦子產品時，系統會自動更新推薦結果。而我們部署的短視訊資訊流推薦采用的是無限右滑的互動方式(見下面圖16)。

圖16：電視貓音樂資訊流推薦采用遙控器無限右滑的方式與使用者進行互動

前面提到的在智能音箱和車載軟體上，使用者的互動方式是語音互動，利用語音互動怎麼進行個性化推薦，目前沒有相關的産品形态出現，這值得大家來思考和探索。

當然，随着VR/AR/MR等虛拟現實、增強現實技術的成熟和産品形态的完善，在這些智能裝置上的實時推薦可以采用更多的互動方式，比如語音、手勢、甚至表情、眼動、思維意識控制等。這些是更加遙遠和值得期待的事情了。

總結

作者在這篇文章中對實時個性化推薦系統進行了全面的介紹。我們了解了實時推薦系統産生的背景，在社會發展、技術進步、互動便捷、資訊爆炸、時間碎片化、激烈的市場競争等多種因素的驅使下，實時推薦系統的出現是必然的現象。

實時推薦系統相比傳統的T+1推薦，可以更好地滿足使用者的訴求，讓使用者掌握更多的控制權，可以極大地提升使用者體驗，讓使用者沉浸其中，這也帶來了極大的商業價值，是以實時推薦系統在各種移動産品中遍地開花，成為主流的推薦産品形态。

實時推薦系統由于要對資訊進行實時處理，對技術架構、工程體系、算法實作等多個方面提出了更高的要求，需要算法工程師采用創新的方式來實作，本文也對相關的架構和算法進行了比較全面的歸納和講解。

基于實時推薦系統的使用者價值和商業價值，在5G技術、物聯網、AI等多種技術的發展和驅動下，實時個性化推薦一定是未來推薦系統發展的核心方向，未來的産品有望在終端上為每個人部署個性化的、量身定制的實時個性化推薦。實時推薦系統也必将在應用場景、互動方式上進行發展和突破。

本文從比較全面的視覺給讀者提供了全新的思考次元來認識和了解實時推薦系統。鑒于實時推薦系統的重要性，每個從事推薦算法的工程師、産品經理(特别是資料和AI産品經理)、甚至是營運人員都需要對實時推薦有一定的了解，而本文是你了解實時推薦系統的一扇窗。

參考文獻

1. [書] Big Data: Principles and best practices of scalable realtime data systems
2. [Kappa架構介紹] http://milinda.pathirage.org/kappa-architecture.com/
3. [System Architectures for Personalization and Recommendation] https://netflixtechblog.com/system-architectures-for-personalization-and-recommendation-e081aa94b5d8
4. [2018] Online Deep Learning: Learning Deep Neural Networks on the Fly
5. [2019] Addressing delayed feedback for continuous training with neural networks in CTR prediction
6. [2011] Follow-the-regularized-leader and mirror descent: Equivalence theorems and l1 regularization
7. [資訊流推薦在鳳凰新聞的業務實踐] https://mp.weixin.qq.com/s/aCTP4OCGyWxWGrlCFHSYJQ
8. [線上學習在愛奇藝資訊流推薦業務中的探索與實踐] https://mp.weixin.qq.com/s/aQOcnWV2L_VY3ChrSXXxWA
9. [螞蟻金服核心技術：百億特征實時推薦算法揭秘] https://mp.weixin.qq.com/s/6h9MeBs89hTtWsYSZ4pZ5g
10. [2018 Youtube] Top-K Off-Policy Correction for a REINFORCE Recommender System