不想當「廚師」的「採購員」不是「好運營」
對於一個內容產品來說，運營的日常的工作中，特別是「內容運營」的同學會經常和推薦算法同學有很多工作上的配合，運營同學像是一個餐館的採購員，負責食材的採買，而推薦同學就像是廚師，結合用戶所點的菜單（偏好）採用對應的食材做成用戶大概率會喜歡的菜餚。
在這個鏈條裏，運營同學在上游，如果引入的內容/創作者不夠優質，就像採買的食材不夠新鮮高質一樣，推薦同學無論怎麼努力都很難做出可口的菜餚。同時還有另一個問題，即便運營同學採買了最好的食材，如果推薦同學做菜的方式有問題，後者沒有最合理的使用食材，也沒有最大限度發揮食材的價值，暴殄天物了。
因此對於運營同學來說，不僅做好自己的上游工作，還非常有必要知道推薦的相關工作，這樣當做出的菜餚不夠好喫時，我們才能及時發現是食材的問題，還是做的方法有問題？更快的進行下一步的調整。
必知一：內容是如何被推薦的？
對於運營同學來說，首先需要了解的是：內容是如何被推薦的？我們引入的創作者和他們的內容，是如何經過層層流程，決定是否被推薦，以及被給到多少流量的？內容在進入系統後整體的處理流程，不同產品和不通過公司的處理是不太一樣的，但是整體邏輯上基本相同，大模塊的業務邏輯基本如下圖。
如上圖所示，當用戶上傳一條內容後，內容會首先經過安全審覈的流程，安全審覈主要是將一些違規，黃色暴力血腥的內容剔除掉，未過審的視頻基本就永久屏蔽或者直接刪除。通過安全審覈後，大部分內容社區會有原創審覈，將一些重複上傳或者搬運的內容過濾掉，原創審覈大部分是依靠機器來審覈的，未通過原創審覈的就只會在用戶自己的個人主頁，或者粉絲的關注頁等私域展示；
通過了原創審覈後的視頻會再進入第一道質量審覈，質量審覈主要是把一些無意義、無主題、雜亂的內容過濾掉，通過了第一道質量審覈後，內容將會被推薦系統納入推薦候選池，然後會給作品最基礎的流量推薦，目的是通過基礎流量後產生的數據初步判斷作品質量的好壞。
如果基礎流量過後的數據反饋較好的話，就會接着加碼給到更多的流量推薦，拿到更多流量推薦後，如果數據表現不好，也會被停止推薦，數據表現好的，會再進入一道內容質量審覈或者舉報審覈，第二道質量審覈主要目的是防止前面的審覈會有漏審，或者有一些不符合社區內容調性的內容出現。舉報審覈是指消費內容用戶主動點擊的舉報，收到過多舉報的內容一定是有潛在風險，需要人工再次審覈。
通過第二道質量審覈，或者舉報審覈後，作品將會被持續給到更多流量，進入一個週期的推薦，成爲內容平臺重點推薦的候選內容。但是在整個持續推薦過程中，還會有一些更細的審覈流程，比如高熱審覈，針對全平臺最熱門的視頻進行審覈，保證沒有風險，同時持續進行用戶舉報審覈，及時發現潛在違規作品。
持續推薦過程中，如果內容的數據反饋出現下滑，那麼會慢慢的進行推薦冷卻，直至停止推薦。
以上所有流程中，被停止推薦的作品，在後續的 過程中，也會因爲一些偶然的觸發或者其它的召回被重新激活，給到更多流量進行推薦。常見的比如遇到節日，過往節日類的內容就會被重新召回推薦。
瞭解了上面的推薦流程後，運營同學就能對整體內容的流轉有一個清晰的認知，可以結合到自己的產品或者業務邏輯，細化整體的流程，這樣當遇到問題的時候，就能及時的知道目前內容處在一個什麼階段。
必知二：推薦系統是如何工作的？
上述的推薦流程中，能幫助我們釐清內容流轉的邏輯，但是在上圖中的流量推薦模塊，到底是如何進行推薦的，我們並不清楚。爲了搞清楚這個問題，我們得先對整體推薦系統有一個瞭解。
如果把推薦系統簡單拆開來看，推薦系統主要是由數據、算法、架構三個方面組成。
- 數據主要提供推薦所必須的信息，包括用戶和內容的特徵信息，用戶對於內容的行爲反饋數據等；
- 算法主要是提供策略和邏輯，在海量的數據下，人工策略已經很難進行分析和干涉，因此需要一套算法來自動的進行信息邏輯處理和返回推薦的內容；
- 架構主要是承載數據和算法的平臺，對接上下游的數據和邏輯，保證系統能夠穩定、實時自動的運行。
常見的推薦系統如下圖所示。
在上圖的推薦架構中，數據存儲模塊，主要是負責存儲內容索引（一種對應到內容的邏輯標識，便於找到內容），用戶特徵（包含用戶的畫像信息，興趣點等），用戶日誌（包含用戶在客戶端對內容產生的一些行爲，比如，點擊，點贊，分享，評論等）
推薦算法部分，會通過內容索引對內容進行召回，召回的候選內容一般都比較多，然後會經過一層過濾，將一些不適合推薦，或者其它運營、審覈邏輯干涉的進行過濾，然後產生的推薦候選池會進行排序，排序通常分爲粗排和精排兩個步驟，排序的方式是通過用戶的特徵，以及用戶的行爲日誌，將內容排成用戶最有可能細化的順序。這樣最終的排序後的內容就會推送到客戶端，按照客戶端實際的展現場景進行展示。
內容展示後，用戶對其產生的行爲就會通過日誌重新上報，然後實時進行日誌的計算，用戶畫像更新和推薦指標更新，比如ctr等，實時計算完成後，再更新到數據存儲中進行最後的存儲，這樣，後續的推薦取得數據都是最新的。
必知三：推薦算法核心兩步：召回+排序
前面的推薦系統結構圖，讓我們知道了推薦的上下游工作原理，也知道推薦系統的組成部分有哪些，在這些組成部分裏，和運營日常工作中交集最多的部分，應該是推薦算法部分，推薦算法中最核心的兩步就是：召回和排序。瞭解了這一塊，基本也就大概明白了推薦算法的原理，以及我們遇到一些推薦問題的時候，大概也能知道是哪一塊出了問題。
我們先來看下「召回」，什麼是召回？召回就是指推薦系統通過某種策略從全量內容池中選取一部分出來。推薦系統召回的方式一般有很多種，比如常見的，熱門召回，協同過濾召回，興趣標籤召回等。單一的召回有自己的優點，但同時缺點也會很明顯，因此爲了有更完整、全面的召回，通常採用的是「多路召回」，如下圖所示：
如上圖所示。如果我們根據召回是否有用戶個性化因素存在來劃分，可以分成兩大類：一類是無個性化因素的召回路，比如熱門內容或者歷史點擊率高的內容的召回；另外一類是包含個性化因素的召回路，比如用戶興趣標籤召回，比如協同過濾召回。
簡單解釋下這幾個常見的召回策略：
- 熱門召回，即全站，當前按照內容各項指標計算得到的綜合分的排序，從這個排序中召回前k1個內容；
- 興趣標籤，指根據用戶偏向的興趣標籤，比如用戶喜歡看體育中的籃球，那麼從籃球這個標籤下召回k2個內容；
- 基於用戶的協同過濾，是指計算出用戶之間的興趣相似度，舉一個簡單的例子，比如用戶A喜歡{a,b,c},用戶B喜歡{a,b,d},那麼我們可以用兩個用戶喜歡集合的交集除以並集，得到兩者的興趣相似度，爲{a,b}/{a,b,c,d}=0.5；這樣我們找到和推薦用戶興趣點最相似的用戶們，推薦其它當前用戶沒有看過的內容，比如給用戶A推薦d；可以按照相似用戶中不同內容的列表召回Top k3個內容；
- 基於內容的協同過濾，和基於用戶的協同過濾類似，這裏我們計算不同內容之間的相似度，計算的方式有很多，簡單的可以直接喜歡兩個內容的用戶數之間的重合度來計算，這樣可以得到和當前內容相似的內容序列，按照相似度進行排序，召回Top K4進行推薦；
- 基於社交關係的召回，一般是通過社交媒體的關係，將用戶的朋友喜歡的內容推薦給用戶，比如微信視頻號裏的，你的朋友點讚的內容推薦；
- 上下文信息召回，是指依照一些時間上下文，位置上下午進行召回，最典型的是在節日期間，召回節日相關內容，還有就是依據地理位置，進行附近的內容召回。
召回之後的排序，一般分成粗排和精排兩個階段；粗排一般對召回的大量內容，進行一些簡單的融合排序，比如多個召回源，各取TOP k，將大量的召回內容，截斷到一個可控的量級（一般到千的量級），不然精排階段會非常耗時，精排一般都採用模型進行排序，排序後召回內容會到百量級。
精排的方式有很多，最初級的是策略規則排序（對各路召回，指定權重和規則進行排序），後續有基於各種模型的排序，有LR（線性迴歸），LR+GBDT（線性迴歸+樹模型），FM（因子分解模型），DNN（深度學習模型）等。各種模型的排序較爲複雜，很多不具備可解釋性，在這裏不再贅述，感興趣的讀者可以自行檢索。
必知四：部分書籍和文章推薦
作爲運營的同學知道了上述的推薦邏輯後，基本能夠很順暢的和推薦同學進行溝通，同時，也能及時發現推薦系統中可能存在的問題，也能在推薦召回部分，用戶畫像，內容特徵等維護根據自己運營的經驗，給出一些自己的看法。
在寫這篇文章過程中，我也參考了一些書籍和文章，推薦給大家。
《推薦系統實戰》：https://book.douban.com/subject/10769749/
推薦系統技術演進趨勢：從召回到排序再到重排：https://zhuanlan.zhihu.com/p/100019681
推薦系統怎樣實現多路召回的融合排序：https://zhuanlan.zhihu.com/p/90796257
【機器學習】邏輯迴歸：https://zhuanlan.zhihu.com/p/74874291