本文經原作者授權整理發布

算法工程師到底有什么特別之處？這個崗位真的比普通工程師高一等嗎？同為工程師，算法工程師為啥工資高幾倍？從普通工程師轉為算法工程師，會有多困難？算法真的那么難搞嗎？

不知道各位程序員朋友平時有沒有想過這些問題，不知道各位是怎么看待這些問題的，如果你心里對算法工程師也有著各種疑惑，你一定不能錯過今天的文章，本文的作者從兩個角度來解答了這些疑問。

在他看來：算法工程師首先要是個工程師，但是，算法工程師又不只是工程師。

是不是聽上去有些繞，但是又仿佛很有道理？先別忙著下結論，看完內容再評論。

上篇：論算法工程師首先是個工程師

引子

最近校招面試到吐，算法崗位有點太熱了，簡直心力憔悴。我們的面試分兩個部分，先是做一兩道編碼題，然后才是考察機器學習的知識。很多同學不理解，在網上 diss 我們，說什么機器學習基本沒有問。這種情況，一般是代碼做的太爛了，面試官都沒有興趣去了解機器學習部分。

機器學習算法崗位，很容易讓大家有個誤解，認為平時工作就是推推公式，調調參數。鑒于此，本文借用下我們團隊最近的一個重要項目：深度學習在搜索、推薦中的應用，來描述下平時我們是怎么干活的，看完之后，大家應該很容易理解為何我們要求有編碼能力。

其實，我們的編碼題真的很簡單，不用刷題也能做出來，看看其他公司出的題，已經有點類似面試造原子彈，進來賣茶葉蛋的蜜汁感覺。當然，他們有資本，可以通過這種方式選到很聰明的候選人。

回到正題，我們從去年年底開始探索深度學習在搜索、推薦中的應用，包括排序和召回。以前我們常常用和工程同學合作，對系統的理解，比如推薦引擎、搜索引擎來表達編碼能力的重要性，可能對于應屆生來講，有點模糊。這次的項目經歷可能更好一些。

先總結下指導思想

這大半年，我們踩了很多坑，特別是癡迷論文中的各種 fancy 結構，寄希望于換換模型拿到收益。最終都紛紛被打臉，反而是回歸到開始，從使用更多的樣本數據，改善樣本清洗、構造的邏輯，謹慎選擇經典的模型結構，對優化算法保持敬畏等等，拿到了不錯的收益。先來幾點務虛的雞湯，大概有以下幾點：

對比傳統模型，深度學習更需要大量的數據去學習，樣本數據的增加能明顯的改善模型的結果。

在初期，請忘記 paper 里面各式各樣的奇技淫巧。

一套有效的方案，其效果是多和少的問題，不是有和無的問題。

好好調參，比亂試各種論文 idea 有效。

深度學習真的可以自稱調參煉丹師，所以比別人試的更快，是煉丹師的核心競爭力。

Embedding 太神奇，請把主要精力花在這里，深度模型對 id 的理解可以震驚到你。

關心你的模型的計算效率，最終還是要上線的，繞不過去的性能問題。

訓練中的工程能力篇，就是各種踩坑各種填坑

樣本規模的問題

一開始，我們把現有基線的特征數據喂到了深度模型中，試過 dnn、dfm、lstm 等等，發現效果比 lr 還差。當時為了快速嘗試，將所有的數據 load 到了內存，限制了數據規模，而且有部分數據預處理的工作也是在 python 中處理，導致計算在 cpu 和 gpu 之間頻繁切換，gpu 利用率抖動很厲害。基于 tf 提供的性能工具，做了點分析后，判斷是特征預處理這部分移太耗時了。另外，模型的參數很大，但是樣本數不夠，急需增加樣本量。我們用 spark 將樣本數據構造成 tfrecord 的格式，整個構建過程對比原來基于 hive sql，再從 hdfs 拉到本地，快了近 10 倍，而且能用的樣本數據量大了很多，發現模型效果好了很多。

embedding id 量級過大的問題

深度學習是在圖像、語音等場景起家，經常在 nlp 的論文中，將幾十萬的 word 做 embedding 稱為大規模。工業界做 user 和 item embedding 的同學應該笑了。userid 和 itemid 非常容易過百萬、千萬的量級，導致生成 embedding lookup oom。可以參考我上篇文章：https://zhuanlan.zhihu.com/p/39774203。

Wide 模型帶來的稀疏模型訓練問題

大部分的 wide & deep 代碼實現，其實用的 tensor 都是 dense 的。tf 基于 PS 做的模型訓練，當你的特征規模在億級別時，網絡通信是個災難，加上 grpc 的垃圾性能，網卡利用率上不去，訓練的時間大部分都耗在通信上了。

但如果花點心思看看 tf 的源碼，解決方法其實很簡單，采用一些 sparse 的 op 就行。比如用 sparse_gather，就能解決網絡傳輸的問題。但這個不是徹底的解決方案，tf 在計算的時候又會把 sparse 的 tensor 轉成 dense 做。繼續看看源碼，會發現 tf 自身實現的 embedding_lookup_sparse。換個角度來理解，天然就能支持 sparse 的 wide 模型訓練。把 sparse 的 wide 模型理解成 embedding size 為 1 的情況，上層接個 pooling 做 sum，就是我們要的 wide 的 output 結果，方案很優雅。

分布式下訓練速度不能隨著 batch size 增加變快

這個問題，單純看性能分析還不好發現。還是去看下 TF 的代碼實現，其實是 TF 默認有個 dimension 壓縮的優化帶來的。TF 為了節省存儲，會對一個 batch 內的相同的 feature 做 hash 壓縮，這里會有個 distinct 的操作，在 batch size 大的時候，性能損耗很明顯。改下參數，就可以取消該操作，不好的地方是浪費點內存。

還有兩個核心問題：TF 不支持 sparse 模型和分布式下 work 的 checkpoint 問題，這里不展開了。

線上性能篇

真實線上場景與 batch size 的訓練的差異

真實排序的時候，一個用戶過來，需要精排的候選集可能有幾千。而我們在訓練的時候，基于 batchsize 方式組織的 predict 代碼。會將用戶側的 feature 復制幾千次，變成一個矩陣輸入到模型中。如果給 tf 自己做，這里就會有幾千次的 embedding lookup，非常的耗時。如果我們選擇在請求的一開始，就把用戶側的 lookup 做掉，然后去做點內存復制，就能大大減少 rt。

另外一個耗時大頭是 attention，這個解決方案也很多，比如用查表近似就可以。

還有一些是模型實現的細節不好導致性能很差，比如 DCN 的 cross 實現，一個簡單的交換律能帶來巨大的性能提升，參考：https://zhuanlan.zhihu.com/p/43364598

扯淡開始

上面很多工作，都是算法工程師和工程同學一起深入到代碼細節中去扣出來的，特別是算法工程師要給出可能的問題點。做性能 profile，工程的同學比我們在行，但是模型中可能的性能問題，我們比他們了解的多。當然也有很多同學 diss，上面這些都是工程沒有做好啊，工程好了不需要關心。但是，真正的突破必然是打破現有的體系，需要你沖鋒陷陣的時候自己不能上，別人憑什么聽你的，跟你干。大概率就是在后面維護點邊緣業務了。

難道機器學習理論不重要嗎

當然不是，這篇已經寫得太長了，只講兩個點。

總結

以上是生活随笔為你收集整理的python算法工程师需要会写什么_算法工程师到底在干嘛的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。