奇技指南

本文為大家介紹筆者在多年工作中總結的一些關於推薦系統優化的經驗。

本篇為算法系列文章第5篇，由360信息流算法團隊投稿。

前言

我多年以來，一直在從事推薦系統優化相關的工作，雖然期間有過短暫的金融風控經歷，但這絲毫沒有影響我對推薦系統的關注。從最開始的基於餘弦相似度來實現item的協同推薦，到如今各種傳統的、非傳統的；淺層的、深層的；nn的、概率的；判別的、生成式的機器學習算法，我基本上都瞭解並使用過。有時候，面對業務、場景、數據的特殊性，還需要自己琢磨一些算法出來。現在推薦系統對統計學習模型的使用可謂無處不在，同時，行業內的交流也越來越多、越來越通暢，大家所使用的算法和模型也無出同行之右太多。

別人家的道理

然而相信很多同學都有過這樣一種體會，我們既不想錯過任何一場同行間的算法交流，同時又殘酷地發現：各家講的道理似乎都差不多，而且貌似只在他自己的手裡有用，回來之後花了不少成本學著做了上線，效果卻讓人十分沮喪。似乎正應了那句：“縱然聽了很多道理，但依然做不好自己的推薦系統”。同樣，即使這篇短文能夠有幸被您翻閱，它本身也無法直接幫您解決任何系統中存在的實際問題，因為它講的依然是別人家的道理。

做推薦系統的我們幾乎每時每刻都在跟“優化”打交道，這裡講的優化不是建模過程中的優化算法，但我們依然可以通過它來理解優化的本質。算法中的優化，對且僅對一個問題負責，那就是你為算法設定的損失函數。至於這個損失函數設置的否合理，是否能夠解決系統的問題，就不是優化算法能夠決定的了。因此決定一個優化過程是否有效的因素至少包含兩點：

1. 問題的設定；
2. 優化方法或路徑

基於AB實驗的優化週期

我們期望並且假設推薦系統是一個可量化的系統，當然，我們也希望系統中的每一個優化過程也都是可量化、可通過業務指標來真實反應的。然而，真實情況則是，推薦系統中能夠完全量化的優化過程很少。相信你肯定不止一次遇到離線指標槓槓滴，上線AB就強差人意。或者運氣好點，AB實驗有收益，並且長期實驗堅挺依舊，但一放量就又萎了。更有甚者，即使實驗流量放到90%，AB實驗的相對收益依然明顯，但悲劇的是整體指標並沒有在同比、環比上有相應的提升。即使你足夠幸運，實驗流量放到90%以後，不光AB實驗對照有收益，而且整體同環比也有相應的收益。我們仍然面臨著，這個收益能夠持續多長時間，會不會在一段時間之後收益消失的問題。

這一道道關口都闖過之後，才是一個完整的策略優化週期。整個優化週期就像一個剝洋蔥的過程，由外而內一層一層地剝開，最終是否真的如願，有時候真的需要點運氣。

你可能已經發現，上述優化週期過程中的每一步都可能由於各種各樣的問題導致結果與預期不符。即使你足夠高瞻遠矚也有足夠的運氣，能夠走到最後，週期也基本上是以月為單位計時的。這裡面的變數你得認真考慮了。記得有一次推薦算法的分享沙龍上一位同學提問，大概意思是：“我已經做了了2年多的算法優化，各種推薦算法也嘗試了不少，系統就是沒有提升，該怎麼辦？” 我能說什麼呢，如果我們把推薦系統的優化，比喻為武功修行，越往後越難。而所有的算法、框架、技巧等都只是第一層的東西。具備了第一層的技能，只是從事推薦系統優化工作的最基本要求。這只是必要條件，但遠不是充分條件。當你真正完整地走過一個優化週期，並拿到收益，知其然也知其所以然的時候，所謂的算法反而不那麼重要了。就像天龍八部中的喬幫主，在聚賢莊只用“太祖長拳（宋朝開國軍體拳）”就把天下英雄打得哭爹喊娘一樣。

既然推薦系統的優化不取決於算法，那優化又從何而來呢？其實很簡單，系統之所以需要優化，不是因為指標不如人意，或者KPI還未完成。而是我們發現了系統中的某些問題，正是由於這些問題的存在才導致系統的表現不如人意。如果你實在找不到也無法定位系統的問題，或者壓根沒往那方面想，那出於對你負責的態度，奉勸你最好離這項工作遠一點，因為你一定會變得很沮喪，沮喪到讓你懷疑人生！

AB實驗的無能為力

其實直到現在，我們所談論的問題都還是相對友好的。我們假設推薦系統是一個可量化系統，有強有力的工具和平臺支持我們做各種實驗。很多時候我們的優化策略只是沒有對系統產生正向的收益而已。即使策略對系統有傷害，也可以及時地從指標上得到反映，並及時止損。然而，推薦系統中至少還有兩類場景是AB測試無能為力的。

1、非即時反饋策略的優化

這類問題，顧名思義就是短期無法觀察的優化操作，但時間長了又不可觀察。我們完全有理由相信過程中總會發生一些情況來影響策略在未來的表現。尤其是那些在短期會對系統有一定損失的優化，大概率會因為業務指標的壓力而夭折。即使你自己作為優化策略的制定及實施者，也無法保證策略在未來的收益，能夠將現在挖的坑填上。如果填不上咋辦？只能涼拌了。如何取捨就真的考驗人對系統整體的理解了，所謂經驗，不外如是！

2、系統流程的優化

AB系統的適用點在於既定流程相對穩定，只優化其中一個環節的情形。我們針對這個環節實現平行的兩個策略進行對比實驗，得出在當前流程的前置及後置情況下，哪種策略會對系統的指標有正向收益。這裡要注意兩個問題：1，AB實驗的結果不能完全體現兩種策略本身的優劣，是有條件的；2，如果流程中需要優化的環節不止一個，而是一連串。試圖通過幾個環節的優化讓整個流程更合理。問題在於各環節之間是互相影響的，且對系統的影響非正交。為了操作，我們只能將各個環節的組合作為一個獨立的存在，實現從根本上將系統切成完全獨立的流程。你會發現除了人不夠用之外，系統100%的流量也根本不夠用了。

不忘初心，摸著石頭過河

推薦系統的優化似乎並沒什麼確定的策略保證能夠切實有用，甚至我們連如何衡量一個優化策略是否真正起到了作用都極難做到。那我們這些號稱做算法的推薦系統工程師，成天都在瞎忙乎啥？

其實正是因為推薦系統的優化有時候很難量化，所以才需要人在裡面進行把控。如果一切都可以量化，那公司也不用養這些推薦算法工程師了，搞個automl就好了嘛。其實，比起盯著AB指標不放，我們更應該關注一下幾點：

1、不做根本上不正確的事情

我不知道做什麼一定正確，但至少可以知道做什麼一定不正確。雖然我沒吃過豬肉，但我至少見過豬跑。你非要誆我說這頭豬成天掛在樹上練習臂力，因此前腿肉賣的會更貴一些，那就說不過去了。

2、把本該正確的事情做對了

其實多數情況下，我們做的事情並不複雜，也並沒有多高大上。所謂算法無非就是做些加減乘除，再輔以簡單的ETL過程。但很多時候，我們還是會犯很低級的錯誤，導致系統的表現遠低於策略生效的理論值。也導致我們錯誤地認為本該有效的策略無效。為了填這個坑，又不得不做更復雜、看起來更高大上的方案，然後又會挖更大的坑。挖坑界的“蝴蝶效應”就是這麼來的。

3、越簡單、越可靠

越複雜的方案涉及到的環節就越多，需要假設的條件也越多，實施起來出錯的概率當然也就越高。手再穩的人，在概率面前也得認命。如果一個簡單的方案能夠達到理論效果的70%~80%，那我建議不惜一切地擁抱它。

4、適可而止，不做過度優化

從兩方面考慮：

1. 投入產出比：一般來講一個問題的優化，越往後越難。遇到這種情況，別軸，換個問題。我們只需要將一個問題優化到不成為系統的瓶頸即可。這就是系統優化過程中的“跨欄”原則；
2. 推薦系統的易變性：越複雜的方案依賴項及假設會越多，而這些大多數時候並不在你的控制範圍內。如果強制要求依賴項不可變，那這個方案本身又成了系統進一步優化的限制條件。那時你又會陷入如何抉擇的兩難境地。所以，每一步都走的短一點，才能走的更遠一些，步子太大就容易扯著。為什麼學習率設置的不能太大，就是這個道理。

總結

綜上，不論我們是作為算法工程師，還是工程架構師，或者是產品運營，推薦系統優化最根本的要求不是要我們懂多高深的理論和算法，而是要我們認真用心地發現、抽象、定義系統中存在的問題，並儘可能以最直接、最小假設、最不容易出錯的方式去解決它。如此而已，畢竟大多數情況下，“以我們對產品和系統的理解，還真沒到需要拼算法的地步！”

關於360技術

360技術是360技術團隊打造的技術分享公眾號，每天推送技術乾貨內容

更多技術信息歡迎關注“360技術”微信公眾號