[[353273]]

為什么很少做模型

在大家想象當中，可能算法工程師做的事情是今天看paper，明天把paper實現了，后天就上線使用，然后公司的收入刷刷漲，我們的工資、級別也跟著漲。但實際上，大多數崗位下的工程師日常并不是這樣。國外有一個著名的大佬（我忘記名字了）曾經說過，算法工程師有70%的時間是投入在數據上的，花在模型和調參上的只有不到20%。

這句話大家可能或多或少都聽過，但是想必都不是很理解，為什么會這樣呢？為什么不能多花點時間做模型呢？原因也很簡單，并非不想，而是不能。

不能的原因也很有很多，我隨便舉幾個最常見的。

框架限制

模型不能隨便動的原因有很多，一般來說最常見的是框架的限制。這種情況在大公司和小公司里都有，比如之前我在某大公司的時候，公司的框架非常成熟，以至于很少寫代碼去實現某一個模型，而更多的是可視化界面的連線以及設置操作。問題來了，在這個場景當中，可視化界面當中可選的模型是固定的，都是基礎團隊開發好的，他們開發好了這么多模型，我們就只能使用這么多模型，除非我們脫離這整個流程，但顯然這是不可能的。

所以當時在很長的一段時間里，我們只能在有限的模型當中做選擇。直到后來，公司開發出了新的框架工具，可以讓我們自己定制神經網絡的代碼實現深度模型，這才鳥槍換炮迎來了全面升級。

小公司雖然不像大公司這樣有一套成熟且不易改動的框架，但是一般也會有自己的一套流程。比如公司前人留下來鏈路是基于開源xgboost開發的，你想要使用TensorFlow訓練神經網絡模型代替原有的xgboost，一般來說這是肯定有效果的，也一定會迎來提升。但問題是，你可能需要把訓練模型、線上調用模型的整個鏈路都重構。很多算法工程師的開發能力不太行，而且也不太愿意做工程重構的事情，再加上這塊工作量也不小，所以很容易出現的情況就是，大家都明知道怎么做比較好，但是由于投入比較多，大家也都不愿意做，一直delay。

效果難保證

第二個原因是paper上的一些模型和做法，效果其實是很難保證的。如果你讀過paper會發現paper的結論往往都有很多前提。比如某某特定的數據或者是場景，前期強大的recall以及過濾系統，或者是完善的特征準備等等。paper里不會把這些都寫出來，它只會寫上做法以及結果。所以這就導致了，很多paper里寫得天花亂墜的方法，實際應用起來效果可能并不好。

這也不是paper吹牛，而是你沒有同樣的條件。舉個例子，阿里的數據埋點非常精準，精準到用戶從打開app到關閉app的每一個動作和行為都有記錄，每一個商品或者是模塊在用戶處展示了多少時間，甚至是用戶翻頁的速度都有全面完整的記錄。就這種數據，一般規模的小公司根本做不了。你做不了這個數據，你就沒有paper里那些精準的特征。那你如何保證你使用阿里的模型也有同樣的效果呢？

優先級問題

我們都知道，事情根據緊急以及重要可以分成四類，不重要不緊急、緊急不重要、緊急且重要、重要不緊急。很多人也都知道，最重要的事情是把那些重要且不緊急的事情做好。說起來大家都會說，但是實際上未必人人都會這么選。

當你面臨KPI考核壓力的時候，一線的工程師可能就只能盯著緊急的事情做。因為他們需要趕緊做出一點成績來完成自己的業績，完成自己業績的最好方法絕不是去升級或者是更新模型，而是找一些特征做一做，或者是使用一些取巧的方法看看能否提升效果。花時間去更新模型，付出的勞動很大，也不一定有效果。但是做特征代價很小，做了一個沒效果，可以再做一個，迭代也快。

這其實并不完全是工程師鼠目寸光，也是整個職場氛圍的影響的結果。大家都看重業績和績效，以至于大家都陷入了局部最優解，但是卻離整體最優解越來越遠。

要想避免這種情況，需要有高瞻遠矚、統籌規劃的架構師或者是leader，能夠抗住升級模型的風險壓力。對可能出現的情況以及將來要做的事情有充足、詳細的規劃，并且有足夠的經驗應對各種可能出現的事情。但是大家也都知道，擁有這種能力的leader在職場里鳳毛麟角。大公司里都不多見，小公司里就更加難得了。

做哪些數據

說完了模型的問題，我們來聊聊數據，既然不能頻繁地變更模型，工程師們就只能更多地來做數據了，那么工程師們到底又在做哪些數據，需要花費這么多時間呢？

訓練數據

大公司里有完整的流程，我們把流程設計好了之后，訓練數據、測試數據、模型訓練以及部署可以一條龍流水線作業。但是在中小型公司里，這往往是做不到的。

原始數據是不能直接用來訓練模型的，這中間需要復雜的處理流程。首先，需要做采樣。就拿CTR預估的場景來舉例，一般情況下真實場景下的點擊率不會超過10%。但是模型訓練一般正負樣本的比例是1：3左右，那么這就需要我們對負樣本進行采樣。

采樣你還不能直接采，因為可能這些樣本當中還存在很多臟數據或者是非法的數據。我們需要先把這些有問題的數據過濾了之后，再進行采樣，這樣才能保證我們的數據是干凈的。采樣了之后，我們需要進行特征和字段的查找補全。因為數據往往是分開存儲的，比如用戶的基礎信息是一張表，用戶的行為數據又是一張表，商品的信息是一張表，各種各樣的數據存放在各種各樣的地方。我們有了樣本之后，還需要去查找很多的數據，才能把所有需要用到的字段搜集齊。

當我們搜集了所有需要的數據之后，我們才能開始真正樣本的制作，也就是使用這些我們查找以及搜集到的原始數據生成輸入模型的樣本特征。每一個特征可能都有自己獨特的生成邏輯，這也是一個龐大的工程。這一步做完還沒結束，還會需要把數據轉化成模型需要的格式。比如tfdata或者是tensor、json之類的。

這么一系列步驟，大公司一般都有一整套完整的自動調度流程， 工程師們不需要操心，只需要拿來用就好了。但是在中小型公司，可能就只有一些手動工具了，需要數據都需要手工去跑一些任務或者是腳本。跑的過程當中還有可能會失敗以及遇到各種問題，雖然說起來平平無奇，也沒什么價值，但這些事情都是需要工作量的。

新的特征

特征怎么做？在kaggle之類比賽當中，可能就是使用pandas寫兩個函數，或者是幾行處理的邏輯就搞定了。但實際上絕不是這么簡單。

我舉一個最簡單的例子好了，比如我們將年齡進行歸一化，做成一個標準化年齡的特征。這個簡單吧，我們就用比較簡單的最大最小值歸一化方法好了，公式是：

算法工程師為什么成天做數據，都做哪些數據？

歸一化之后，這個特征值會被縮放到0-1的區間里。但是這里面用到了兩個參數，一個是最大值，一個是最小值。這兩個參數怎么來？你可能會覺得這還不簡單，我們遍歷下數據不就知道了。但問題是這個數據你并不是只用一次，以后每次生成訓練數據都需要生成這個特征，難道每次跑的時候都手動遍歷一下數據找下最大最小值嗎？而且數據是在變化的，每一天用戶年齡的最大和最小值可能都不一樣，假如說我們要跑好幾天的訓練數據怎么辦？

設計一個新的特征是簡單的，但是里面的一些參數會讓事情變得復雜，我們往往需要設計復雜的機制來將新完成的特征加入流程。

效果分析

還有一塊數據處理的大頭在效果分析，效果分析有兩種，第一種是做一些之前沒有的指標以及相關的分析，或者是應老板的要求做一些業務指標的分析，達成我們的績效。

比如像是最基礎的CTR、CVR、收入等數據，也有像是老板臨時起意想要看的某些數據。比如分析一下某些特征的分布，比如看一下某個特定族群中樣本的數量或者是數據的情況，等等等等，不一而足。

第二種是我們模型做出來之后的效果分析，如果說模型的效果還，那還好。如果效果不好，問題就來了，我們怎么樣確定是哪里出了問題？是因為模型本身的性能不足呢？還是我們的特征不夠或者是特征當中存在問題呢？還是我們的數據質量不高呢？還是說什么地方存在bug呢？

算法不像是工程，工程當中絕大多數事情是確定的，結果不對一定是因為邏輯有bug，那么只要仔細測試，分析原因，總能解決。那種難以復現，找不到原因的問題非常罕見。但是算法不一樣，大多數情況下并沒有絕對的錯誤和正確，甚至沒有絕對的原因。我們扮演的角色更多地像是偵探，根據一些蛛絲馬跡推測導致問題的原因，然后用實驗嘗試著解決，在這個過程當中就涉及到大量的數據處理和分析的工作。

比如，如果你懷疑是某些特征分布有問題導致了模型效果不好，那么你需要分析特征的分布。如果你懷疑是數據存在bug，那么你需要設計方案，篩選數據，仔細甄別數據當中的問題，驗證自己的想法。如果你覺得是訓練數據量不夠，那么你需要增大訓練量，設計對比實驗……總之，想要排查問題都需要大量的數據分析，絕不僅僅是看看代碼，想一想就能有結論的。

感想

很多想要從事算法的人真正做了算法之后，往往會有幻滅感。會有一種強烈的面試造航母，入職擰螺絲的感覺。原因也很簡單，我們面試的時候問的是各種各樣的模型，各種先進的理念和方法，但是入職之后面臨的工作卻是各種各樣的數據分析以及數據準備。比如我當年大部分時間都在寫SQL做數據，我一度懷疑公司的職位安排。

但當我理解了這一切的運作機制之后，我就理解了。實際的工作場景和線上算法比賽不同，線上比賽我們可以使用各種各樣的trick來提升成績。還可以搞各種跨界混搭，比如今年的騰訊算法大賽的冠軍的做法就是把BERT應用在了用戶行為分析的場景下。但是在實際的場景當中，由于系統以及各方面的制約，這些想法都是很難實現的而且效果也難保證，最終還是要落實到基本的數據支撐上來。

打個不確切的比方，各種各樣的算法模型就好像是工具箱里的各式工具，我們僅僅了解工具是沒用的。最重要的是要理解使用工具的場景，從而可以根據需要選擇最合適的工具。但很遺憾的是，我們對數據以及場景的理解是很難量化的，所以面試的時候只能退而求其次問你工具的使用了，長此以往很多人本末倒置，搞錯了核心競爭力，出現對面試的種種非議也就不奇怪了。