推薦算法的基本原理表述起來比較簡單，但是具體實施起來還是比較復雜。沒有任何一個標準的推薦系統，可以適用全部的情形，在真正實現的過程中，需要對算法有融匯貫通的掌握，以及對業務本身有深刻的理解。本章會介紹一些碎片化的推薦系統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. 總結

本期總結了推薦系統實現過程中一些需要特別注意的地方。

結束之前，討論另一個問題，推薦系統的產品經理需要懂算法么？

答案也很簡單，一定要懂。如果不懂算法，就只能是做簡單的評估并提出改進，很難有系統性的優化方案。懂算法也不是要知道具體怎么實現，而是要知道實現的原理，這樣才能更好地把產品需求轉為推薦策略，并且和算法工程師商量出解決方案。

#專欄作家#

潘一鳴，公眾號：產品邏輯之美，人人都是產品經理專欄作家。畢業于清華大學，暢銷書《產品邏輯之美》作者；先后在多家互聯網公司從事產品經理工作，有很多復雜系統的構建實踐經驗。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。