本文內容來自神策數據《智能推薦——應用場景與技術難點剖析》閉門會分享內容整理，分享者為神策數據算法專家胡士文，分享主題為《推薦系統的實踐與思考》，前面我們介紹了算法和數據部分（ ），本篇文章將繼續介紹推薦系統的在線服務和評估方法。
推薦系統之在線服務
在解決了算法和數據層面的問題之後，我們需要構建一個推薦系統的在線服務，用來響應用戶的推薦請求。假設企業初期的 DAU 是 10 萬，當 DAU 漲到一百萬的時候，希望能夠通過增加機器的形式，解決服務性能響應的問題。如果每當 DAU 擴大時就要去重構推薦服務的話，代價實在太大，所以我們希望我們的推薦服務具備高可擴展性。
另外一些常見的需求是：如何實現高維向量的查詢和計算？如何滿足不同場景時效性不同的需求？監控和報警怎麼做……
儘管深度學習的模型複雜、效果又好，但哪怕把模型訓練出來之後，等過渡到在線服務時還是會遇到很大的挑戰。今天我就幾個實踐問題在這裡跟大家做一些分享。
1.如何做高維的向量查詢？
舉個例子。假設目前有 10 萬個商品，每一個商品擁有一個向量的話，就會有 10 萬個向量，當用戶來到後，一個用戶對應一個向量，這個時候我們需要在這 10 萬個項目裡面去查找到跟這一個用戶向量最匹配的 100 個或者 500 個向量。同時還要保證在足夠短的時間之內（10-20 毫秒）將向量找出，所以在響應時間的層面還面臨著較大的挑戰。
我們的解決方案是運用一個叫做 Faiss 的工具，它可以解決大規模的向量的相似度查找問題，且最大可支持 10 億規模的內容空間。簡而言之，當我們有 10 億商品的時候，仍可以用此組件去做基於向量的相似度查找。
2.如何讓推薦系統的在線服務具備高可擴展性？
我一直在強調，我希望我們的可擴展性是水平的，流量上來之後，僅通過加機器的方式就能解決服務的壓力。我們的思路是，把在線服務分為三組：在線存儲、在線服務群、模型服務群。
我們把模型服務和在線服務做一些邏輯上的解耦，從而保證整個架構在可擴展性上是水平的，這樣既可去單加模型服務也可以去單加在線服務，解決服務器上的壓力。
3.不同場景下不同的時效性，該如何支持？
我作為一個技術的人員，在做 Feed 流時經常會接到產品經理如下的需求，比如，需要在綜合頻道推薦最近 3 天的文章，最近 7 天的視頻；歷史頻道的數據量對時效性要求沒那麼高，需要推薦近 30 天的文章和最近 60 天的視頻；相關文章中要求推薦最近 7 天的文章，相關視頻中推薦近 30 天的視頻。
這些需求嚴格上來說是非常合理的，因為這是基於產品本身以及用戶對於此產品的訴求，但這些需求其實會給推薦系統帶來很大的問題。
我們簡單來計算一下場景數量。
產品經理需要我們支持文章推薦和視頻推薦兩種類型，同時還要分成不同的頻道，而綜合頻道和其他小頻道所涵蓋的內容和範圍又不一樣，小頻道少則十幾個，匹配上兩種架構類型，大概 2×10=20 份數據，再加上相關文件的推薦，可能會產生 40 份數據。
為了支持不同的時效性，我就需要維護 40 套不同的數據，在推薦系統裡面維護 40 套數據意味著維護成本和出錯的風險都相當大。40 套數據，可能擁有 40 條邏輯，40 個數據流，一旦發生人員變動，對於接手的人員來說簡直噩夢。
所以我們在整體的架構中，會去為不同場景、不同時效性設計一整套的工具和流程來解決諸如此類的問題，這可以使我們的線上管理較為簡潔，不會出錯但又非常靈活，即使有其他的時效性需求時，也能很容易地加入。
推薦系統之效果評估
評估一個推薦系統，會涉及到一些常用指標：點擊率、點擊人數比、人均點擊次數、留存率、轉化率等。
1. 點擊人數比
指點擊的人數除以推薦的曝光人數，這是一個用來衡量推薦系統觸達率的一個重要指標。在評估一個模型效果時，可能點擊率上漲，但點擊人數比並沒有變化，這說明推薦結果只對於部分老用戶產生比較好的效果，對於觸達不到的用戶，仍然沒有成功吸引他們來使用我們的推薦系統，所以點擊人數比與點擊率是對推薦系統在不同方面的評估。
2. 人均點擊次數
指每個人在推薦系統裡面平均每天點擊了多少次。人均點擊次數是需要大家持續去關注的指標，因為這個指標真正體現出用戶在這款產品中的使用深度。
3. 留存率和轉化率
留存率和轉化率實際上來說對於推薦系統來說，可能並不是一個那麼直接的指標，比如推薦對留存的影響到底有多大，很大程度上決定於不同的產品形態，但它仍是我們去評估推薦系統的一個指標，至少我們需要知道此次推薦系統的迭代到底對於留存率的影響有多大，如果迭代後的留存率下降，即使點擊率和點擊人數比都在上升，可能這一次迭代仍不能上線，因為它影響了留存的指標。
還有一些方面，其實在之前的文章中神策數據 VP 張濤：個性化推薦從入門到精通（附推薦產品經理修煉秘籍）已經跟大家提到過。
時效性。如果我們在做一個新聞產品的推薦系統，那麼給用戶推薦的內容就應該是實時的，而不是上週發生的事情。
多樣性。多樣性其實是容易被忽視的一個指標，因為如果不追求多樣性的話，點擊率的數據會好看一點。
不知道大家有沒有這樣的體驗，如果你對體育內容感興趣，慢慢的你所有的推薦內容都變成了體育相關，似乎很難看到其他內容，推薦的內容越來越窄。短期來說，提升多樣性可能會讓點擊率有一些損失，但是長期來說，多樣性是為了提升整個產品用戶體驗所做的一種優化，這裡需要考慮長期和短期的權衡。
穩定性。如果服務器經常掛掉，或者說響應時間總是五秒鐘，這樣的服務基本上是不可用的，我們一定要站在服務的角度去評估我們的推薦系統。
覆蓋率。覆蓋率指能夠推薦出來足夠多的長尾內容，一個 UGC 平臺，需要去鼓勵一些用戶讓他們來生成內容，即使是一些很小的用戶，即使沒有粉絲，我也希望他的內容可以有一些曝光，有曝光就會有人去點贊，久而久之會形成一種良性循環。
如果平臺總是分發一些大 V 的內容，平臺裡小白用戶的使用和體驗就會變得非常糟糕，慢慢的就沒有這些小的內容窗口了，平臺將被大 V 佔領，所以覆蓋率也是一個推薦系統需要考慮的指標。
至於具體需要去考慮哪些指標，以及怎麼去制定這些指標，我覺得要根據不同的產品形態以及產品不同的階段而定。
那麼面對這些指標，我們有給力的分析工具去支持我做這件事情嗎？比如我想對比推薦系統的轉化率和另外一個 banner 的轉化率區別的時候，我們的分析工具具備這種能力嗎？
在我的日常工作中，是依據神策分析去做整個轉化率漏斗分析，以及留存分析等。留存分析其實是一種比較複雜的分析方法，它強調的維度比較多，它可能要從各個時間段以及各個條件去分析用戶的留存行為。
如果想要去分析推薦效果對於留存的影響，可以直接在神策分析中去做留存率的分析。
另外，跟大家分享一些關於迭代的思路。
以下圖為例，我們分析推薦系統在 12 月 18 號新增用戶上的不同表現。
我們想知道，對於新用戶和老用戶而言，推薦系統的這次迭代表現究竟如何。
從圖中可知，新用戶在第二天有一個明顯的提升，但是老用戶並沒有。說明這一次模型的上線對於新用戶而言效果是較好的，我們要進一步去分析——為什麼會對新用戶的效果提升明顯而對老用戶沒什麼效果。
可能是因為使用的數據採樣方式對於新用戶更加有利，或者是因為對於新用戶的特徵反饋比較及時，而對老用戶的一些長期特徵做了一些不太合適的處理方式等等，都有可能。
所以，實現一個好用的推薦系統，可能面臨這幾方面的挑戰：
第一，數據獲取和處理質量，就是我前面提到的如何做數據的採集，以及如何做特徵工程。
第二，將算法跟業務結合，我們怎麼去深入地理解業務場景，以及去選擇合適的算法方案。
第三，構建推薦系統和評價體系，以及如何去解決在線服務這部分的挑戰。
第四，成本控制，當我們去從頭構建算法、數據、在線服務以及評估方法這幾個方面的事情時，人力和時間都會耗費相當大的成本。
最後回答演講剛開始時大家問我的一個問題——如何搭建一個閉環，讓其流程化體系化。其實就是神策智能推薦系統的核心優勢——全流程、實時、可快速迭代的推薦閉環。
通過我的分享，大家也可以看到我們在實際構建一個推薦系統時，會遇到各種各樣的問題，基於之前的經驗，數據質量是非常需要注意的一部分。它包括全端採集數據、數據處理和建模、標籤體系和用戶畫像建立。
接著，當我們有了數據後我們就去構建算法，我們擁有豐富的算法建模經驗，並且數據基於神策分析，擁有實時數據反饋和快速的建模能力。
在算法生效之後，我們會對結果進行多維的驗證分析，一方面我們要對於本次的推薦效果有一個認知，另外一方面要明白後續將如何改進。同時，在我們提供的解決方案裡，還有兩個比較重要的環節。
第一，神策數據是一家支持私有化部署的公司，所以神策智能推薦系統同樣支持私有化部署，一整套系統都部署在客戶自己的服務器層。
第二，具有開放性。各種中間數據和接口客戶都可以自己去調用，比如我們幫助客戶採集行為數據，在構建整個推薦系統時所生成的各種用戶畫像和模型結果，以及內容分析的一些結果，還有各個階段產生的一些模型方法，客戶都可以去調動。神策數據的解決方案是一個開放性的白盒，從實驗設計，到數據的採集，到中間的特徵工程，到模型構建，到最終推薦結果，裡面的數據和接口都可供客戶訪問和查看。
最後，我想強調兩點內容：
第一，推薦系統不只是算法，它是一個系統工程，算法只佔四個部分中的一部分，通常我們去實現一個推薦系統時，構建算法的時間通常只佔 20% 到 30%。
第二，數據先行，數據是一切算法的前提，根據過去的經驗總結，很多時候真的不是因為模型的問題，也不是因為服務的問題，而就是因為數據沒有做對，導致我們推薦系統的效果沒有那麼符合預期。
以上就是我從多年的工作經驗和實踐中總結出的一些關於推薦系統的思考，希望能對大家的工作有所啟發。
更多互聯網乾貨和案例，可關注【神策數據】公眾號瞭解~
閱讀更多 神策數據 的文章
