本文內容來自神策數據《智能推薦——應用場景與技術難點剖析》閉門會分享內容整理，分享者將我們介紹：如何從四個方面做一個推薦系統。

在工作中，大家遇到的與推薦系統相關的問題是：“數據太稀疏、數據沒有形成閉環、數據沒辦法跟其他系統結合”等等。

這些內容是擺在我們面前的實際問題，那么當我們真正要開始做一個推薦系統時，需要從幾方面考慮問題呢？

1. 算法：到底應該選擇什么樣的算法？無論是協同過濾還是其他算法，都要基于自己的業務產品。

2. 數據：當確定了算法時，應該選擇什么樣的數據？怎樣加工數據？用什么樣方法采集數據？

有句話叫做“機器學習=模型+數據”，即便擁有了一個很復雜的模型，在數據出現問題的情況下，也無法在推薦系統里面發揮很好的效果。

3. 在線服務：當模型訓練完畢，數據準備充分之后，就會面對接收用戶請求返回推薦結果的事項，這其中包含兩個問題：

（1）返回響應要足夠迅速，如果當一個用戶請求后的一秒鐘才返回推薦結果，用戶很可能因喪失耐心而流失；

（2）如何讓推薦系統具有高可擴展性。當 DAU 從最初的十萬漲到一二百萬時，推薦系統還能像最初那樣很好地擋住大體量的請求嗎？這都是在線服務方面需要考慮和面臨的問題。

4. 評估效果：做好上述三點，并不代表萬事大吉。

一方面，我們要持續迭代推薦算法模型與結構；另一方面要去構建一套比較完整、系統的評價體系和評估方法，去分析推薦效果的現狀以及后續的發展。

我會從以上四個方面，跟大家分享一下我們在實際情況中遇到的一些問題以及總結出的解決方法。

一、算法

在各種算法中，大家最容易想到的就是一種基于標簽的方法。

如上圖所示，標簽可分為兩種：

1. 用戶標簽：

假設我們擁有一部分用戶標簽，知道每一個用戶的年齡、性別等信息，當某類年齡和某種性別的用戶喜歡過某一個物品時，我們就可以把該物品推薦給具有同樣年齡、性別等用戶標簽的其他用戶。

2. 內容標簽：

與用戶標簽的思路相似，如果用戶喜歡過帶有內容標簽的物品，我們就可以為他推薦具有同樣標簽的內容。

但很明顯，這種基于標簽的方法有一個重要的缺點——它需要足夠豐富的標簽。也許在多產品中，可能并沒有標簽或者標簽數量非常稀疏，所以標簽的方法顯然不足以應對。

另外，協同過濾也是一種非常經典、被較多人提及的一種方法，是一種常見且有效的思路。

隨著技術的不斷發展，基本從 2012 年以后，深度學習幾乎被整個機器學習界進行反復的討論和研究。

谷歌在 2016 年提出一套基于深度學習的推薦模型，用深度學習去解決推薦的問題，利用用戶的行為數據去構建推薦算法。

1. 深度學習的目的之一：向量化

推薦系統其實是在做一個關于“匹配”的事情，把人和物做匹配。

看似很難的推薦系統，其實也有簡單的思路——做人和物的匹配，把該用戶可能感興趣的物品推薦給他（她）。

如果站在數學的角度去思考這個問題，我們如何去計算人和物的相似度匹配呢？

在推薦領域，深度學習的目的之一就是嘗試將人和物向量化，即把某個人和某個物品學習成一種統一的表示方式，隨后在這個統一的表示方式中計算這個人和物品的相似度，當人和物都映射到同一個可比較的空間中時，就能夠基于計算結果去執行相關的內容推薦。

把最終的結果映射到這張二維的平面圖表里，用戶認為相似的內容就會映射在向量上。當擁有內容向量之后，之后再將用戶映射進來即可。

比如：用戶到達了上圖某個地方，根據他所處的位置，可以向其推送教育、娛樂、科學、地理等內容。

講到這里，有些朋友就會提出疑問：既然深度學習如此復雜，那在實踐中究竟有沒有作用？

其實，站在實戰經驗的角度來看，當具備一定的數據量時，會帶來比較明顯的效果提升。但當你要去搭建一個深度學習模型的時候，可能真的會遇到很多問題。

比如：用多少數據量去訓練模型是可以的？訓練數據該用什么格式？多“深”才算深度模型？訓練模型太慢了怎么辦等。

這些關于在搭建深度學習模型時遇到的困難與解決方法，會在以后跟大家分享。

2. 冷啟動

冷啟動是算法部分經常遇到的問題。

在冷啟動階段，數據比較稀疏，很難利用用戶的行為數據實現個性化推薦。

冷啟動的問題分為兩種：新內容的冷啟動、新用戶的冷啟動。

接下來，我們分享一下新內容的冷啟動要如何實現：

舉個例子：

資訊場景的需求往往是將發布的新內容（如 10 分鐘內發布的內容），以實時且個性化的方式分發到用戶的推薦結果中去。

上圖這篇文章在 17:41 發出，那么就需要在極短的時間內根據這篇文章的內容去做一些個性化的相關推薦。

此文內容圍繞美食展開，用戶點開這篇文章之后，文章的相關推薦里面就要有跟美食相關的一些內容。

當我們要在如此實時的環境中實現推薦效果的話，其實沒辦法去依賴用戶的行為。這時，我們嘗試提供一種思路，一種基于深度學習的語義理解模型。這個模型跟我們前面分享的內容有一個很大的區別就是——不需要用戶行為，只需要分析用戶文本，基于用戶的內容去給每一篇文章生成一個向量。

這和前面提到的模型也有相通的地方：

• 用深度學習的思路去解決問題；
• 用向量化的思路解決問題，我們只需要訓練出文章的語義向量，獲得文章與文章之間的相似度，從而得知文章和用戶之間的相關性。

3. 召回、排序、規則

如今的推薦系統已經做得相當復雜，特別是在一些大規模的應用場景中。

比如說：今日頭條的 Feed 流，淘寶的“猜你喜歡”等，都擁有一個非常復雜的推薦系統，這個推薦系統中的各個模塊可能會涉及到很多的實驗算法。在一個系統中，出現 10 個或者 20 個模型都很常見。

那么怎么把這些模型有效地融合成一個真正的系統呢？

召回

召回，即從海量的內容里去召回每一個用戶他可能感興趣的內容。前提是——擁有海量的內容，因為當內容不足時，也就不需要去搭建復雜的推薦系統。

所以，當有海量 Item 時，需要用召回的算法，從不同類別的內容里為用戶生成可能感興趣的內容。

比如：某位用戶既喜歡體育內容，也喜歡軍事內容。那么在第一步，無論用哪些模型，都希望達到為該用戶生成一些體育、軍事相關內容的效果。

另一個用戶可能喜歡美食和游戲，在召回階段，我們就希望通過模型去為他生成一些美食和游戲相關的內容。

在召回階段可能就會存在許多個模型。而經過召回階段之后，盡管生成的是該用戶可能感興趣的內容，但這些內容實際并沒有融合到一起，是一種亂序的狀態。

排序

排序，即將召回出來的內容做統一排序。

排序過程其實就是給每部分內容打分的過程，預測每一個用戶對每一部分內容的感興趣程度，從而獲知每一個用戶對每部分內容的偏好程度。

規則

推薦系統常常跟產品或者業務場景緊密相連，而在產品中一定有一些需求是無法用模型來解決的——因為模型只能從用戶行為或者文本內容中去發掘用戶和物品之間的關系，所以有些常見的業務需求要通過規則去實現。

舉個例子：

部分推薦場景中會出現一些運營精選的內容，運營同事的需求是：保證每十條內容中都有一條編輯精選內容，而這個需求，只能通過規則實現，而不是通過算法。

一個比較復雜的推薦系統通常分為召回、排序、規則這三個步驟：

首先召回用戶感興趣的內容，第二為用戶生成一個排序列表，第三用規則解決一些產品、運營方面提出的需求。

二、數據

總是會聽到一個這樣的說法，“推薦算法的效果是由模型與數據所決定的”；即模型只占推薦效果中的一部分，另外一個非常重要的部分就是數據。

那么我們究竟需要哪些數據？在一個實際的推薦系統中，哪些數據是有可能發揮作用的？我們又能拿到哪些數據？

通常來說一般會有四類數據：用戶行為、物品信息、用戶畫像以及外部數據。

1. 用戶行為

用戶行為數據最為重要，幾乎沒有哪一個推薦系統可以直接表示不需要用戶行為數據。

一方面，用戶行為數據是訓練模型中的一個重要數據來源；另外一方面，需要通過用戶的行為反饋，技術同事才能知道推薦系統到底做得如何。

搭建推薦系統的一個秘籍就是積累用戶行為數據，如果沒有將重要的用戶行為做采集，例如在電商場景中，如果只是記錄最終的下單數據，那么離推薦系統的數據要求還是有一定的距離。

2. 物品信息

物品信息指推薦系統中能采集到的描述每一個內容的信息。

以電商場景為例：在錄入一件具體物品時，錄入商品的品牌、價格、品類、上架時間等就是我們要收集的物品信息。

假設在電商場景中，如果并不清楚每個商品的品牌，也就無法從一些物體的描述信息中去提取某個商品到底屬于何種品牌，那么推薦效果自然受到限制。

當物品信息采集得足夠豐富時，對推薦系統的效果就會有一定的幫助。

3. 用戶畫像

在傳統的思路中，認為用戶畫像里面存儲的實際還是用戶的標簽。

但在很多實際場景中標簽數量少、維度粗，可能根本不具備去給用戶打標簽的能力，這種傳統的“標簽式”想法，就會限制搭建推薦系統的思路。

而從深度學習的角度出發：用戶畫像中儲存的并不是通常理解的“標簽”，他可能存儲的是這個人的向量。

深度學習是把人和物品做向量化，但這個向量是不可被理解的，即我們可能并不知道這個向量表示的是什么意思。

當我們看到某個用戶對應的向量，我們也不知道他是對體育、音樂或是娛樂感興趣，但我們仍能夠通過向量去為他推薦其感興趣的內容。

4. 外部數據

有的人會迷信外部數據，覺得自己的數據量不夠，所以一定要去購買阿里或者是騰訊的外部數據來充實用戶畫像，從而提高推薦系統的效果；甚至有人認為推薦系統效果不好，是因為沒有外部數據。

但其實，外部數據對于推薦系統的效果，個人認為還需要一個極為謹慎的推理和驗證。

首先，要先驗證自己的這批用戶群跟所購買的外部數據能發生多少交集。假如一個游戲平臺，購買了阿里的外部數據，而這樣的外部數據可能只能告訴你用戶到底是喜歡買衣服、買車還是買電子產品，這樣的信息對游戲平臺有用嗎？

假設購買的外部數據恰好命中了業務場景，可能會發揮一定的作用，但實際上，能夠同時命中用戶群體和標簽的情況也并不常見。

大家不要認為上述的 4 種數據比較容易理解，所以獲取時也會比較簡單。

其實我和我們神策團隊在去構建一個實際的推薦系統時，消耗我們人力的地方往往不是算法，反而是怎么去得到正確的數據。接下來我們以用戶行為數據為例，與大家分享應該如何獲取我們所需要的用戶行為數據？

這時候我們就要思考，當我們想去獲取用戶行為數據時，到底希望用戶行為數據能給我們帶來什么樣的作用？

我總結為以下幾個方面：

1. 我們希望用戶行為數據能用來訓練模型，這是非常重要的一個方面。

比如：我給某個用戶推薦十件商品，其中有兩件商品發生了點擊行為，模型中就會覺得這兩條數據是正例，其他是負例。所以，我們需要用戶行為數據作為模型的訓練數據。

2. 我們希望用戶行為數據能夠驗證效果。

推薦系統上線之后，需要用戶行為數據來反饋推薦到底做得怎么樣。

比如：點擊率上升說明效果變好，點擊率下降、負反饋變多、用戶流失，說明推薦系統可能出現了問題。

3. 我們希望用戶行為數據能夠支持我們去看 A/B Test 效果。

模型上線一定要基于 A/B Test，我們需要知道此次上線到底比之前的推薦算法、推薦系統等效果如何。

這樣，我們才能判斷這一次的迭代是否有效，如果有效就將其全量；如果無效，則進一步迭代。

4. 我們希望它能夠幫助我們分析問題。

我們將推薦系統上線之后，可能會碰到一些懊惱的問題。

比如：點擊率并沒有發生變化，甚至效果變差，畢竟不可能每一次迭代的效果都是上升的，所以我們希望行為數據能夠定位到此次推薦系統上線后效果不理想的原因；如果上線后效果不錯，此時我們希望行為數據能夠分析到底是哪些因素使效果變好。

那我們應該如何去獲取滿足我們這些需求的行為數據呢？

以曝光日志中的第一個字段 exp_id 為例，exp_id 的中文的意思是實驗 ID。

前面提到了我們希望用戶行為數據是能支持 A/B Test 的，那么如何知道每一條數據是來自哪一組實驗呢？

此時，我們需要一個 exp_id 字段去記錄每一條曝光日志是來自哪組實驗。

當我們再次分析 A/B Test 效果時，就可以根據一個 exp_id 字段去區分不同實驗所帶來的曝光和點擊。

在曝光日志中我們常常討論如何設計一些常用字段，而另外一個具體問題就是——我們怎么去采集這些數據？

簡單來說，當用戶在產品里面發生一些用戶行為，怎么把這個數據最終落到服務器的日志中，從而用于模型訓練和效果分析呢？

做用戶行為的采集，通常有兩種方式：

1. 自助埋點，客戶端先把用戶的行為記錄下來，之后傳給服務端，服務端再去傳給推薦引擎。
2. ?SDK 埋點，我們直接使用 SDK 去做推薦引擎的埋點。

SDK 埋點有兩個方面的優勢：

1. SDK 埋點的接入成本低，它有比較成熟的埋點事件和埋點驗證方案。另外 SDK 有埋點接口和文檔指導客戶埋點，無需關注上報問題。
2. SDK 埋點的容錯性比較高。如果是自助埋點，從客戶端到推薦引擎經過了服務端，數據出現問題，難以回溯埋點問題、傳輸問題、數據質量維護成本高，SDK 埋點就會相對方便。

那么當有了行為數據之后，如何去訓練模型？

通常會有以下幾個步驟：

1. 構造正負例。比如：給用戶推薦十條商品，有幾條發生點擊，就有幾條正例，其他沒有發生點擊就是負例。
2. 構造特征工程。稍后會以一個電商場景為例，具體講解通常情況下，如何構造特征工程。
3. 數據采樣。數據采樣對整個模型訓練的效果影響較大。

下面以電商場景為例，講解如何做特征工程，主要分為兩個方面：

1. 商品維度。在商品的維度里，我們可能關注一些商品的品類、品牌、價格、所面向的性別，以及各種用戶行為反饋的一些數據，比如：點擊率、收藏比率等。這些內容一方面體現了商品本身的一些屬性，同時還體現商品的質量。
2. 用戶層面，通常首先考慮用戶的年齡和性別。因為在電商領域中男性所偏重的商品和女性之間存在較大差異。另外還有用戶的品類偏好、品牌偏好，以及價格偏好等。

在數據方面，跟大家分享一下我在實際工作中遇到的“坑”：

某一次小的流量上線之后，我和團隊成員發現效果不如預期，根據以往的實踐經驗來說，不應該是這么差的結果，當我們去分析數據時，發現有兩個方面的數據異常：

1. 命中行為模型的用戶較少。通常情況下，只要不是一個新用戶，理論上來說，都應該能夠命中我的行為模型。我們當時的新用戶比例在 20% 以下，而命中模型的用戶大概僅為 30%，說明大量的用戶沒有命中到模型。

2. 很多請求的 ID 未出現在日志中。當時我們懷疑，是否我們的推薦結果被別人作弊刷掉了。因為用“作弊”能很好地解釋這些請求并未落到日志中的原因。

但最終，我們發現并不是作弊的問題，而是因為用戶 ID 沒有統一：前端在用他們理解的一套用戶 ID 體系打日志，但是后端在用另外一套用戶 ID 體系發送請求。

于是所有的數據無法對上，后端過來的請求總是新用戶，而訓練出來的模型命中不了任何用戶。

最終，我們建立了一系列的方法和工具以及流程去保證整個用戶 ID 體系的一致性。

以上就是神策數據算法專家對推薦系統的實踐與思考的前兩點“算法”與“數據”的分享，由于篇幅限制，“在線服務”和“效果評估”將在下一篇文章進行介紹，希望對你有幫助！

最后，告訴大家一個好消息：

為了幫助在運營進階路上，執著前進的伙伴們能夠更快速的提升，我們聯合了騰訊、百度等擁有10年以上經驗沉淀的實戰派導師，推出了【運營總監修煉之道】，至今已幫助5000多名運營管理者和進階者，掌握了更加系統全面的運營專業知識和管理思路，在處理類似運營戰略規劃、不同渠道運營策略和流量變現、品牌營銷玩法、數據分析等實際問題時有更清晰的解決方向！

掃描二維碼添加小助手了解詳情，還可以回復“筆記”領取【運營總監課程學習筆記】哦！

再猶豫，機會就沒啦~

分享者：胡士文

本文由 @神策數據 整理發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議