保舉算法的基來源根基理表述起來比較簡單，但是具體實施起來還是比較復雜。沒有任何一個尺度的保舉系統，可以適用全部的情形，在真正實現的過程中，需要對算法有融匯貫通的掌握，以及對業務自己有深刻的理解。本章會介紹一些碎片化的保舉系統notes。

1. 要解決哪些bad case?

這個問題是保舉系統被設計出來的根本，產品遇到了哪些bad case,無法通過現有的機制實現，而必然要通過保舉系統才能解決?

以傳統門戶而言，之所以用保舉系統，是因為隨著受眾的增多，受眾對于新聞的偏好越來越多樣化，而針對全體人的保舉系統并不能滿足所有人的需求。編纂默認只會保舉絕大多數人喜歡的內容，國內的情況就是“強奸新聞”和“奇聞異獸”，但是這顯然不滿足高端用戶的需求。相反會降低門戶產品的調性，造成高端用戶的流失。保舉系統就可以按照差別人的需求推送差別的內容，解決這個問題。

這里的要解決的case，如下：

如何讓互聯網新聞偏好者的首頁主要是互聯網新聞而非大眾新聞。如果讓女性用戶首頁不出現大量男權色彩重的新聞，好比“強奸新聞”。

只有明確了bad case，才知道了解決問題的標的目的。

2. 設計怎樣的合理路徑？

保舉系統最終形態是基于機器學習的保舉系統，那么如果設計一個一個月就上線的保舉系統，怎樣既保證有效性，同時也又保證最后的合理演化?

舉個例子，如果最終路徑是無人駕駛電動車代步。有兩種演化方案：

方案一：電動滑板 → 電動自行車 → 電動摩托車 → 無人駕駛電動車方案二：汽油動力汽車 → 混合動力汽車 → 電動汽車 → 無人駕駛電動車

方案一看似不停演進，其實每一次都是很大成本的重構。而第二個方案，則能看到清晰的技術演化路線，駕駛動力在演化，最終是無人駕駛系統的上線，而大的架構沒有修改。

我一直覺得一個產品經理的能力很大程度表現在架構思維和中間版本的設計。

具體到保舉系統的設計，短期內要看到效果，一開始直接上CF，是不明智的，一開始直接上基于語義分析的保舉方法也是不明智的。而如果是利用現有內容信息進行人工干預的聚類，利用這個內容聚類去實現用戶聚類，則更加明智一些。后續轉為自動化聚類也更加合理。

3. 可調整性

保舉系統最需要考慮的問題是，如果出現了問題，怎么可以快速調整來滿足需求？

辦法無外乎三種：提權，降權，屏蔽。

這里就要求，權重是否能夠快速調整？召回策略是否能夠快速調整？只有系統級別支持粒度較細的權重調整策略，以及靈活的召回策略，才能夠保證策略的快速調整，保證保舉系統的可持續迭代。

這也是不建議直接上線CF或者機器學習的原因，因為CF和機器學習等策略，一開始可調整性比較差，前期無法快遞迭代，可能對于項目而言，就是死刑。

4. 離線評估、 灰度上線和用戶反饋

離線評估是指在發布之前，需要去檢驗典型的bad case 是否解決。是否達成一開始的目標，如果沒有，，則需要繼續調整對應算法，直到能夠明顯解決問題。

灰度上線則也是穩妥的辦法。一開始保舉系統必然是充滿了各種問題，所以為了解決這個問題，剛開始上線必然不能直接全量上線。正確的做法是，灰度上線一段時間期間，快速的按照用戶反饋迭代算法，再考慮全量上線。

用戶反饋的方案包孕但不限于：用戶問卷，負反饋操作入口。典型的負反饋入口如下（今日頭條）：

5. 說服別人的數據

所有改進工作效率的系統，都會觸碰別人的利益。這句話話值得讀三遍。

保舉系統正是這樣。如果沒有保舉系統，運營或者編纂能確定所有的位置應該擺放什么內容。有了保舉系統，本來10個人做的事情可以3個人能做完。那么這個部門裁誰？沒有保舉系統，可能有一些特定KPI完成的余地，甚至可能有利益輸送的空間，現在交給保舉系統，這個損失怎么辦？

另一方面，并不是所有人都有技術信仰，覺得保舉系統能比運營或編纂的經驗判斷會比保舉系統差，如果領導自己對保舉系統有懷疑，這也會是一大阻力。

保舉系統最開始的目標并不是要大范圍的上線，而且證明本身能替代編纂或者運營，而是要能夠說服別人，保舉系統是可用的。這樣才會減少阻力。最常見的做法是在運營或編纂不會干預的地方，上線保舉策略。因為這些地方上線保舉，業務數據是絕對的增量。或者如果在重要運營位上線，必然不要改變運營或者編纂最好的位置，而是在相對次要的位置增加保舉模塊兒。

而只有在這些位置不停迭代系統，效果足夠好之后，達到能夠說服別人的時候，再考慮進一步推進保舉系統的覆蓋率。

6. AB test

標簽：烏魯木齊 九江 林芝 鹽城 東營