演算法工程師如何拿結果:走過低谷,先立信念

張哥說技術發表於2023-12-22

演算法工程師如何拿結果:走過低谷,先立信念

來源:阿里雲開發者

阿里妹導讀

作者結合自己在推薦演算法領域的工作經驗討論“如何拿結果”這個問題。

引言

到了績效季前整理收益和工作的時候,有時候會遇到明明好像幹了很多事情,但是收益一言難盡的情況。畢竟“為過程鼓掌,為結果買單”,老寫鼓掌的事情也沒人買單。而到了新財年開始,我們刷刷寫完OKR後,心裡會給自己打氣,“這次一定!“,但同時心裡也會悄悄打鼓“到底怎麼樣才能拿到結果呢?”。
如果把個人在職場的成長想象成一座大廈的構建的話,拿結果的能力就是最下面的地基,樓能有多高,能屹立多久不倒就看地基牢不牢了。我見過一些一畢業因為機緣就帶很大團隊的同學,在老闆力挺下屬給力的時候還能順風順水,一旦人員和環境發生變化,沒有真正拿結果能力的人就成了沙灘邊裸泳的人了。
我們自然都不想成為那個裸泳的人,筆者在這裡結合自己在推薦演算法領域的工作經驗討論下“如何拿結果”這個問題。

一、複雜性和不確定性

為什麼演算法工程師遇到拿不到結果或收益的情況看起來有點多,也更讓人焦慮呢?主要原因在於我們是在面對一個複雜系統做不確定性的工作,結果並不是一個即時的反饋。
首先來看複雜系統,複雜系統第一個顯著的特點是它是由多個模組有機組合形成的,即使每兩個模組之間的互動關係很清楚,放在一起就往往呈現一種混沌之態。從時間軸來觀察,我們能看到複雜系統的另一面,時延性。即我們對這個系統作出了一些改動,要滯後一段時間才能看到效果。
還有一個不確定本身是在建模的目標上,例如推薦系統本質上建模的使用者側的工作就是建模一群簡化的大腦或者大腦的一部分,即人對於內容的偏好。正如賈伯斯曾經提到的那樣,人們並不是那麼擅長表達自己喜歡什麼。而不同人對於內容的偏好也不盡相同,即使有兩個人都完整地看完了一部相同的劇集,他們所喜愛的明星也可能不同。經常會遇到的一個問題是:“為什麼我不喜歡這個你給我推薦”,或者映象問題“為什麼我喜歡那個你沒給我推”。具體到每次最佳化迭代,我們可以看到點選率等指標顯著地上漲了,但是還是無法明確地解釋為什麼現在這個內容對某個使用者相比之前排得更靠前了。
時間延遲是另外一個複雜性的問題,如果我們對系統的操作要隔很久才會得到反饋的話,在這個時間過程中所產生的新的變數並不能很好地被我們所感知和處理,導致我們不能準確地把握我們之前的操作,對於這個系統的影響到底是正向還是負向,影響程度是大還是小也就無法進一步操作了。
忽視時延問題有時會讓我們盲目快節奏迭代,根據實時監控和小時級資料在一些假陽性結果裡happy地走上一條不歸路。我有看到過這種情況,策略或模型裡有幾個超引數是可以調的,發現負向了,趕緊調調某個引數;過幾個小時覺得微正了,又想再調調能不能正更多;結果另外一個指標負了,我又再調調另外一個超參。結果折騰了一個禮拜,結果一直在AA-Diff內,週報都沒法寫。

二、信念

在這種不確定系統下工作,我們有時候會出現一段時間拿不到結果的情況,也不太清楚接下來該往哪裡走,會特別迷茫,甚至會懷疑自己。
這種時候信念是能幫助我們走過上面這一段段黑暗的光,一個可以燎原的小小的火種。
而所謂的信念,指的是相信自己能做出東西。支撐這個信念的一方面是樂觀的心態,另外一方面更重要的是過去成功的經驗路徑。
樂觀的心態還是可以有理論支撐的,也就是機器學習中的 "No Free Lunch Theory (NFLT)"。這個定理告訴我們,沒有一種機器學習演算法可以在所有情況下都比另一種更好。每個公司的使用者都會有一些差異,同一個產品的不同頁面和模組使用者行為分佈也會有差異,產品隨著新老使用者變遷分佈也會發生變化。此外產品上總是忍不住做一些改版或者心智調整的工作,會帶來分佈的驟變。總之,以前的模型,別人的模型肯定都沒有那麼適用了,我們肯定是有空間可以做事情的。
失敗不是成功之母,成功才是。那麼對於校招/剛進入職場的同學如何建立起自己成功的路徑呢?簡而言之有兩條可行的大道。
第一條是從自己的技術/學術積累入手,在初步瞭解業務問題和邏輯框架後,結合自己的學術/技術積累,找到問題的切入點。比如自己對圖模型的相關工作比較瞭解,目前系統裡的召回大部分是行為base的I2I,U2I等,我是否能基於圖模型做一些工作。
第二條路是從業務入手,在淺層地瞭解業務後,找到一個或多個點,不停地dig in,深挖,發現資料和分佈的異常。對於推薦系統來說,常用的方法就是對人群和物料進行切片,找到一個使用者-物料對的子集,這塊推薦有異常便是一個機會點。異常的表現一般是資料指標不合常理的低,但真正要把Ta做高,對於一些成熟場景來說也絕非易事。如何進行資料分析挖掘提效點,後文將會具體展開。

三、原則

最後我們來聊聊拿結果的原則,即要事第一。當我們覆盤為什麼沒有拿到結果時,要麼是不懂判斷什麼是要事,要麼是不懂什麼叫做第一。
那麼如何來判斷什麼是重要的事情。我們可以有三個視角:老闆視角,業務視角,技術視角。首先最簡單的是老闆視角,你多和Leader/老闆溝通,大致上就能知道他最關注的事情是什麼。如果有一些變化你覺得可能會導致重要性發生調整,可以及時溝通確認。
其次是業務視角,基於你對產品和業務的理解。舉個例子,商業化一般是公司的核心目標,但是不同的階段商業化的重要程度不一樣。有的時候願意多犧牲一些商業化的利益,甚至承受一些虧損,來追求規模上的增長。規模的增長往往與使用者的留存和活躍相關,這裡月活和日活也有一些細微的差別。以線上影片網站來說,使用者的停留時長與使用者的留存乃至會員轉化都有比較強的正相關關係,那麼這個時候,系統的目標就不能單單追求點選率,還得考慮時長這種目標來建模了。
業務上我們還需要看到的一個點是,產品形態上app是由很多個頁面組成,業務也會分屬很多個團隊負責,各個頁面和各個團隊追求的目標也不盡相同。比如典型的雙列Feed 一般分為外流和內流,對於使用者播放轉化這一目標來說,內流毫無增量的貢獻,更適合以時長以及下滑深度等而不是點選率類指標作為其目標。
技術視角對重要判斷也有自身的三個角度。
一是for PR(Public Relation,這裡指對外展示公司或者團隊的技術先進性),主要關注的是創新性和如何蹭熱點。對應的產出一般是Paper,或者是大會上的專題分享等。如果一個技術點在當前SOTA(state of Art)基礎上有明確的創新,值得整理發表論文或者分享,那麼Ta的重要性可以提升一些。
二是我們通常說的技術包裝,有一些工作往往從創新度上還沒有達到直接可以整理發表的水平,但是我們也付出了很多精力去做,也拿到了一些結果,但是在總結通曬的時候常常讓人感覺平平無奇。但是有些同學明明線上收益和我們差不多,但是PPT/Doc卻很有深度的樣子,圖『琳琅滿目』,邏輯一套一套的。是不是人家會『包裝』而我不會?
其實我個人更願意把技術包裝叫做技術規劃或者技術遠見。就像是一棵樹,它結果的時候一般在年度或者半年度的績效總結或者晉升場合上,但是種子在大半年前甚至更早就已經種下了。我們往往喜歡用擁抱變化作為沒有長期或者成體系技術規劃的藉口,但是很少檢討自己是否能更好地抓住一些不變和本質的東西。亞馬遜創始人貝索斯曾說過:我經常被問到一個問題:“未來十年,會有什麼樣的變化?”但我很少被問到:“未來十年,什麼是不變的?”。我認為第二個問題比第一個問題更重要,因為你需要將你的戰略建立在不變的事物上。回到演算法的工作中,不變的業務中的一些具體問題,比如:新的物料來了如何高效地冷啟,同時能快速發現其中優質內容放大;父母和小孩共用裝置如何做更好地推薦等等。如果兩份任務同時擺在我們面前,一份任務更能解決業務或者系統的本質問題,那麼Ta的優先順序就更高。
三是技術債的角度,往往我們為了完成一些短期的任務,程式碼和系統會逐漸演化成一座shit mountain,那麼在初期就需要儘可能好的框架設計,維護中做好防止劣化。這個東西短期不需要考慮,拉長到半年或者一年還是會有一些影響,比如資源是模型複雜度的約束,如果複雜度的增長遠快於收益的增長,後期模型就迭代不動了。此外如果為了滿足短期的需求,拆分了巨多不按照通常的『召回-粗排-精排-重排』路徑的鏈路去強插和配比例透出,後期就很難去融合,這也變相降低了模型迭代的影響面。
知道什麼是要事,那接下來的事情就是做到“第一”了。第一簡而言之就是集中優勢兵力去打殲滅戰。另外一個相關但是沒那麼重要的事情是如果減少給不重要的事情投入兵力。我們需要把80%以上的精力和時間都放到這件要事上,從各個角度去揣摩它,試探它,分析它。

來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70024923/viewspace-3001165/,如需轉載,請註明出處,否則將追究法律責任。

相關文章