我，機器學(xué)習(xí)工程師，決定跑路了

撰文｜OneFlow社區(qū)

AI/ML 大熱后，很多工程師跟著潮流學(xué)習(xí)新技術(shù)，再加上高薪誘惑，不少人就跳坑到機器學(xué)習(xí)的研究/工程職位，但進去后才知道這里并不是想象中那么美好，一入此坑深似海，你是不是也感同身受？

最近，Reddit 上的一位做了一年 ML 工程師的@hedy-m就吐槽，有太多人因為“酷”、“聰明”和“高薪”一窩蜂涌進機器學(xué)習(xí)領(lǐng)域，他也曾以為ML工作夢寐以求，但現(xiàn)在，他發(fā)現(xiàn)有錢難買我開心，準(zhǔn)備棄坑跑路了。

他給出的的理由是查看損失曲線、調(diào)整特征和參數(shù)的工作實在太耗費精力，太無聊，尤其是生產(chǎn)模型時，當(dāng)它們沒有產(chǎn)生預(yù)期的效果，他會不禁認為自己只要足夠努力，模型就會變得有效，但往往事與愿違，ML 模型效果難以捉摸，項目的交付難度無形中讓他壓力山大，他現(xiàn)在很厭惡花數(shù)個小時在“垃圾數(shù)據(jù)”中撞腦袋的機器學(xué)習(xí)工作中。

不過，他正在打軟件工程師的主意，當(dāng)處理更純粹的編程和工程任務(wù)時，他覺得自己會獲得更多工作樂趣。

在他訴苦后，江湖上大致有 ML“棄坑”派、MLOps“真香”派和技多不壓身派給出了觀點，有人勸他打消這種想法，這樣做一定是瘋了，也有勸他跳坑做自己感興趣的軟件工程的，另一部分人則建議使用 MLOps 工具幫他減輕當(dāng)前的工作壓力。

一時間，三大門派各抒己見，一頓輸出后，似乎讓這位工程師不知所措了......

1

機器學(xué)習(xí)“棄坑”派

實際上，@hedy-m 的抱怨在 ML 領(lǐng)域很常見。“棄坑”派網(wǎng)友表示很有共鳴，勸他去搞軟件工程。

基本上，不少機器學(xué)習(xí)項目需要為獲取相關(guān)資源和數(shù)據(jù)而四處奔走，你還需做耗時的數(shù)據(jù)處理工作，但最終 ML 項目的成功取決于你所擁有的數(shù)據(jù)甚至是運氣。模型沒有按預(yù)期工作總讓人感到沮喪，并且你還要為此負全部責(zé)任。

Reddit 網(wǎng)友 @knighttoken1 稱，如果你開始解決一個不可能或者非常困難的問題，無論如何嘗試使用不同的 ML 模型都不靈時（至少 ML 不是解決方案）。在這樣的項目中，很難不把個人價值與模型性能聯(lián)系起來。

“在 ML 工作中，你很容易工作 14 小時，同時失去友誼、社交和健康，最終仍然一無所獲”：）

此外，大部分 ML 工程師日常用的是知名模型或復(fù)現(xiàn)其他論文，創(chuàng)造性空間有限，難以獲得成就感，有人認為，要想在機器學(xué)習(xí)工作中做出好成績，還是要有 Phd 加持去做研究。當(dāng)你成為?ML 的大牛，輕松輸出各種相關(guān)論文時，生活就美滿幸福，但要想有影響力和創(chuàng)新性，自然也會承受各種壓力。

即便在大廠，只有極少數(shù)地方才會用到最前沿的ML研究，況且還是業(yè)務(wù)優(yōu)先。@TernaryJimbo 提到，在大廠 ML 團隊帶過后，現(xiàn)在討厭關(guān)于 ML 的一切，他轉(zhuǎn)到了更標(biāo)準(zhǔn)化的后端工作，只是把ML當(dāng)成一種業(yè)余愛好。

還有人提到，機器學(xué)習(xí)工程師還要努力展示與某些業(yè)務(wù) KPI 相關(guān)的直接商業(yè)價值，而模型的改進不一定會對業(yè)務(wù) KPI 產(chǎn)生直接影響，因為還有很多其他因素促成數(shù)據(jù)產(chǎn)品取得成功，由于涉及到如此多的不確定性，他們通常也不得不使用太花哨的東西，因此，舊招數(shù)不斷被重復(fù)使用。

相對而言，做軟件工程不確定性更小，優(yōu)秀的軟件工程師投入必要的時間，就會獲得積極的結(jié)果，而且對任何科技公司來說，軟件工程項目都是更成熟的核心業(yè)務(wù)。

2

MLOps“真香”派

機器學(xué)習(xí)工作中讓人很糟心的是，要處理混雜的數(shù)據(jù)，并且沒有稱心的編程工具，如果能改變這兩點不足，機器學(xué)習(xí)工程師的生產(chǎn)力將得到大幅提升。

網(wǎng)友 @CuriousRonin 的回復(fù)得到了最高贊。他認為，在許多情況下，當(dāng)你打算將代碼用于生產(chǎn)時，只有使用更高級別的框架才能節(jié)省大量時間，而不是將時間花在代碼和文檔、錯誤分析以及訓(xùn)完模型后的很多其他工作上。

不過使用 PyTorch ?Lightning 或 fast.ai 等更高級別的框架也有很多麻煩。有人提到，從 Fastai 部署 PyTorch 模型非常痛苦，因為人們必須了解 Docker、PyTorch、WebAPI/flask 和云容器服務(wù)、監(jiān)控......

因此，他建議使用 MLOps 工具。如果沒有良好的基礎(chǔ)設(shè)施，系統(tǒng)質(zhì)量和開發(fā)體驗就會一塌糊涂，而 MLOps 就像是編程用的 IDE 或 Git，這是行業(yè)中最有價值的東西。

有人補充，機器學(xué)習(xí)工程師的工作是弄清楚如何將模型產(chǎn)品化，并將其擴展到軟件工程師構(gòu)建的 Serving 平臺，如果發(fā)生模型漂移，還需要監(jiān)測和調(diào)整，而 MLOps 平臺可以做到這一點。

網(wǎng)友 @chief167 更直接，他說自己根本不喜歡 Azure、Snowflake 或 ?Databricks 進行部署，現(xiàn)在模型就緒后，使用 MLOps 平臺在 15 分鐘內(nèi)就可完成模型部署，API 就緒，完成監(jiān)控，拋出接口并完成整個過程，確實消除了所有痛苦。

在他看來，谷歌 GCP 和 AWS 比傳統(tǒng)玩家要好很多，但離專用平臺還差得很遠，還推薦使用 Datarobot、H2O、Teradata Vantage 等 MLOps 平臺。

目前，MLOps 主要被用于由 AI 技術(shù)驅(qū)動的組織中，一般由數(shù)據(jù)工程師或應(yīng)用工程師打造，不過在一些組織中，機器學(xué)習(xí)工程師也會承擔(dān) MLOps 工具的開發(fā)工作。

3

技多不壓身派

溫和的中庸派也發(fā)話了，俗話說，多門技術(shù)多條路，不要搞得這么決絕。

許多公司在軟件工程和 ML 這兩個角色之間還沒有過于明顯的區(qū)分，實際上，如果你在這兩方面都擁有成熟的經(jīng)驗，那你更有價值。

網(wǎng)友 @modernzen 現(xiàn)身說法，他目前的職位是機器學(xué)習(xí)工程師，但主要做的是軟件工程 + MLOps/DevOps 的工作，偶爾還會做數(shù)據(jù)科學(xué)任務(wù)。盡管他喜歡數(shù)學(xué)/統(tǒng)計/理論機器學(xué)習(xí)，但一直喜歡寫代碼勝過任何事情。

他將大部分時間都沉浸在編碼工作上，并且從不抱怨，只花 <10% 的工作時間在 fine-tuning 或調(diào)參的 ML/DS 任務(wù)上，這樣不至于對其感到厭倦。他建議在一個使用機器學(xué)習(xí)的團隊找到一份軟件工程師的工作，這樣即使大部分時間不直接使用 ML 模型，你仍然可以研究機器學(xué)習(xí)。

還有一位有 20 年軟件工程師經(jīng)驗的網(wǎng)友寬慰道，無聊或壓力可能不是技術(shù)領(lǐng)域的問題，更多與團隊或者項目有關(guān)。當(dāng)你看到軟件運行或輸出業(yè)務(wù)見解，并為用戶和企業(yè)帶來價值時會讓人感到滿足，開發(fā)項目也并不總是很順利。

聽了上述三大門派的觀點，你會選擇棄坑ML？繼續(xù)茍著？還是有其他選擇？

其他人都在看

資源依賴的“詛咒”?

“遠見者”特斯拉AI主管Karpathy

TVM：成為深度學(xué)習(xí)領(lǐng)域的“Linux”

對抗軟件系統(tǒng)復(fù)雜性：恰當(dāng)分層，不多不少

解讀Pathways（二）：向前一步是 OneFlow

OneFlow v0.7.0發(fā)布：全新分布式接口，LiBai、Serving等一應(yīng)俱全

歡迎下載體驗OneFlow v0.7.0最新版本：https://github.com/Oneflow-Inc/oneflow/https://github.com/Oneflow-Inc/oneflow/

關(guān)鍵詞： 機器學(xué)習(xí)