【推薦系統那些事兒·三】推薦策略設計的Notes
1. 要解決哪些bad case?
這個問題是推薦系統被設計出來的根本，產品遇到了哪些bad case,無法通過現有的機制實現，而一定要通過推薦系統才能解決?
以傳統門戶而言，之所以用推薦系統，是因為隨著受眾的增多，受眾對於新聞的偏好越來越多樣化，而針對全體人的推薦系統並不能滿足所有人的需求。編輯默認只會推薦絕大多數人喜歡的內容，國內的情況就是「強姦新聞」和「奇聞異獸」，但是這顯然不滿足高端用戶的需求。相反會降低門戶產品的調性，造成高端用戶的流失。推薦系統就可以根據不同人的需求推送不同的內容，解決這個問題。
這裡的要解決的case如下：
如何讓互聯網新聞偏好者的首頁主要是互聯網新聞而非大眾新聞。
如果讓女性用戶首頁不出現大量男權色彩重的新聞，比如「強姦新聞」。
只有明確了bad case，才知道了解決問題的方向。
2. 設計怎樣的合理路徑？
推薦系統最終形態是基於機器學習的推薦系統，那麼如果設計一個一個月就上線的推薦系統，怎樣既保證有效性，同時也又保證最後的合理演化?
舉個例子，如果最終路徑是無人駕駛電動車代步。有兩種演化方案：
方案一：電動滑板>>電動自行車>>電動摩托車>>無人駕駛電動車
方案二：汽油動力汽車>>混合動力汽車>>電動汽車>>無人駕駛電動車
方案一看似不斷演進，其實每一次都是很大成本的重構。而第二個方案，則能看到清晰的技術演化路線，駕駛動力在演化，最終是無人駕駛系統的上線，而大的架構沒有修改。
我一直覺得一個產品經理的能力很大程度體現在架構思維和中間版本的設計。
具體到推薦系統的設計，短期內要看到效果，一開始直接上CF，是不明智的，一開始直接上基於語義分析的推薦方法也是不明智的。而如果是利用現有內容信息進行人工干預的聚類，利用這個內容聚類去實現用戶聚類，則更加明智一些。後續轉為自動化聚類也更加合理。
3.可調整性
推薦系統最需要考慮的問題是，如果出現了問題，怎麼可以快速調整來滿足需求？
措施無外乎三種：提權，降權，屏蔽。
這裡就要求，權重是否能夠快速調整？召回策略是否能夠快速調整？只有系統級別支持粒度較細的權重調整策略，以及靈活的召回策略，才能夠保證策略的快速調整，保證推薦系統的可持續迭代。
這也是不建議直接上線CF或者機器學習的原因，因為CF和機器學習等策略，一開始可調整性比較差，前期無法快遞迭代，可能對於項目而言，就是死刑。
4. 離線評估、 灰度上線和用戶反饋
離線評估是指在發布之前，需要去檢驗典型的bad case 是否解決。是否達成一開始的目標，如果沒有，則需要繼續調整對應演算法，直到能夠明顯解決問題。
灰度上線則也是穩妥的措施。一開始推薦系統一定是充滿了各種問題，所以為了解決這個問題，剛開始上線一定不能直接全量上線。正確的做法是，灰度上線一段時間期間，快速的根據用戶反饋迭代演算法，再考慮全量上線。
用戶反饋的方案包括但不限於：用戶問卷，負反饋操作入口。典型的負反饋入口如下（今日頭條）：
5.說服別人的數據
所有改進工作效率的系統，都會觸碰別人的利益。這句話話值得讀三遍。
推薦系統正是這樣。如果沒有推薦系統，運營或者編輯能確定所有的位置應該擺放什麼內容。有了推薦系統，原來10個人做的事情可以3個人能做完。那麼這個部門裁誰？沒有推薦系統，可能有一些特定KPI完成的餘地，甚至可能有利益輸送的空間，現在交給推薦系統，這個損失怎麼辦？
另一方面，並不是所有人都有技術信仰，覺得推薦系統能比運營或編輯的經驗判斷會比推薦系統差，如果領導本身對推薦系統有懷疑，這也會是一大阻力。
推薦系統最開始的目標並不是要大範圍的上線，並且證明自己能替代編輯或者運營，而是要能夠說服別人，推薦系統是可用的。這樣才會減少阻力。最常見的做法是在運營或編輯不會幹預的地方，上線推薦策略。因為這些地方上線推薦，業務數據是絕對的增量。或者如果在重要運營位上線，一定不要改變運營或者編輯最好的位置，而是在相對次要的位置增加推薦模塊兒。
而只有在這些位置不斷迭代系統，效果足夠好之後，達到能夠說服別人的時候，再考慮進一步推進推薦系統的覆蓋率。
6. AB test
之前在講搜索的時候，我也是在最後強調了AB test的重要性。推薦和搜索一樣，本身極大依賴參數的配置。而這些參數的配置並沒有通用的法則，同時也依賴各個平台自身具體的情況，只能在了解其原理的基礎上，不斷迭代摸索。在演算法迭代的過程中，能夠測試其效果是演算法迭代的核心。只有能同時在線上部署多套搜索演算法，並且監控其效果，推薦的迭代和改進才能展開。而這一切的基礎，正是一個看不見的功能：AB test機制。7. 總結
本期總結了推薦系統實現過程中一些需要特別注意的地方。
結束之前，討論另一個問題，推薦系統的產品經理需要懂演算法么？
答案也很簡單，一定要懂。如果不懂演算法，就只能是做簡單的評估並提出改進，很難有系統性的優化方案。懂演算法也不是要知道具體怎麼實現，而是要知道實現的原理，這樣才能更好地把產品需求轉為推薦策略，並且和演算法工程師商量出解決方案。
By the way
最近手上的幾個項目都到了比較緊張的時期，所以更新會慢一下，也正在考慮更新一些組織難度沒那麼高的內容。本專欄的關注者我大致看了下，產品經理居多。對於入行比較短的，應該比較關注怎麼系統地提高自己，對於老司機，也會有給自己手下新人推薦書的需求。下一期我會給出一份新人產品經理書單，希望能在偷懶的同時，也解決一些大家的問題，歡迎關注專欄並閱讀下期。
------------------------------------
下期預告：【番外·一】給新人產品經理的一份書單
推薦閱讀：項亮《推薦系統實踐》
猜你喜歡：做個夠用的搜索，其實也很簡單（一）搜索的原理
推薦閱讀：
※360 安全衛士和 360 殺毒有哪些不可取之處？
※極客公園創新大會（2013年1月12日）乾貨分享有哪些？
※身為數據分析師，卻被業務當做取數機？
※如何防止創意被盜？
※如何評價微博新版客戶端中類似視頻播放的動圖展示方式？