Auto ML的衝擊下,現在大量ML演算法人員是否會在前者成熟後失業?
沒有任何衝擊,不會真覺得演算法工程師的日常就是調參吧。。。那這種演算法工程師就算不被AutoML替代,也是會被別人替代的。
就算代替日常調參,引數空間得設計吧,現在的論文一言不合就是各種奇怪的網路結構,引數空間是不是也有的調,這不就是換了個參去調麼。
這都不是關鍵,哪來這麼多GPU去搞AutoML啊,平時隨便訓點東西,稍微調調參,每個人十把個GPU是日常操作。你還想AutoML,那不得幾十上百個?
其實這也不是問題,如果這麼多GPU能創造出超過GPU價格+電費+機器的價值,也是可以的。但你忙了半天就漲了那麼幾個點,那就划不來了,有這個錢能多標多少資料了?我直接借鑑論文里人家發表的NAS不是也可以,那可是純免費的。
作者:劉斯坦
連結:
來源:知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。
-------------------------------------------------------------------------------------------------------------
連結:
來源:知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。
既然說到失業,那麼,這顯然是一個商業和社會範疇的問題,而不是科學技術範疇的問題,所以我只能從商業角度回答。
我的觀點是不會,但是從業者會越發焦慮。
其實,人在意識到某個技術並沒啥太大升值空間的時候,會提早脫離這個行業,並不會等到發生大規模裁員以後才做準備。剩下跑不掉被裁的,其實你做啥並沒啥太大關係,可能單純是年紀大了,熬夜熬不動。所以,社會學角度來看,ML 從業者並不會失業,但是,每天上班如上墳,進而產生大規模勸退。
這裡,我想澄清一個理解,Auto 的概念,我的理解就是,幫你把很煩惱的事情解決了,而不是幫你把重要的活和決策都做了。
這就才叫做 auto,google 放出他們的 kubernets 時候,已經在內部跑了很長時間自己的容器管理系統,並不是搞一個自動“雲”來讓世界每個人都能進Google 裝逼,啥都不用幹就能產出,碼農還是要寫點指令碼,搞點配置啥的,邏輯還是要自己寫。產生容器管理的重要痛點是,碼農不喜歡配環境,不喜歡自己琢磨服務釋出,不喜歡到處找機器和人家爭搶計算資源,這個是在長期的工作環境,自然而然出現的技術痛點,反正你做我做都一樣,導致大家都覺得這種活沒有去重複做的必要,這時候,會有一批牛人,把這種需求沉澱下來,成為一個通用的輪子,也就是廣義的 auto。
我再重申一點:auto 的目的是解決你很煩很不想做的事情,而不是取代你想做而且很爽的事情,商業角度才有失業的概念,科學角度沒有失業的概念。
但是機器學習不完全是這樣的,重要的原因是獎懲機制和合作機制,ml 模型的設計到產出,從我的角度來看,是個高度各自為政的行業,自己單幹更加爽,不是一個讓碼農覺得煩的事情,而是帶有賭#博性質的“爽” (當然風險也高,所以大家容易焦慮),因為這種活做好,往往是納入公司績效裡面的 ,做不好也不指望 auto 能比人強。我想說的是,做模型並不是負擔,網際網路是輕資產行業,從來不會因為工具成本而開發 auto 型別的工具,這個是學術界意淫的故事,公司只有當人力成本和業務複雜性達一定程度,才迫使他們開發 auto 的工具,或者也叫平臺化元件。
其實我一直覺得,按照早期工業界的演化,真正讓工業界演算法工程師煩的事情是部署,這個才是 auto ml 發揮的最強入手點,反正無論如何部署,最終都是一樣的結果,但是演算法模型越往後,都會和公司業務強烈耦合,你做和我做出來的公式說不定都不一樣,靈活性非常高,經常一個厲害的人幹完很多重要事情,用不著很多人合作搞。
尤其帶過演算法工程師的基層 leader,都知道,要管演算法工程師,相比開發管理來看,痛苦指數高好幾個數量級,經常被演算法和資料細節懟的不想管他們,他們愛咋設計咋設計,人和人之間都沒有交集,互相不信任對方的指標,各自為政自己單幹,單幹有時候還比合作產出快,沒有合作,就沒有複雜性和因為複雜性帶來的成本,從而,auto ml 在演算法層面,容易失去基本的商業價值。
-------------------------------------------------------------------------------------------------------------
連結:
來源:知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。
如果說,比起AutoML能讓ML演算法人員失業的論斷,我更相信,NAS能讓熱衷於排列組合的NN模型結構研究者失業。
讓我們從AutoML 解決問題的分類角度來分析一下這個問題。
1、狹義超參搜尋:算不上automl吧,一個子問題,比如決策樹用多大的列取樣,行取樣。 此類初級AutoML不會讓工程師失業,經驗豐富的ML工程師沒有太大的搜尋空間去試,閉著眼睛設定的引數都能搞定。並且這些引數也不是那麼重要,遠比資料和特徵的帶來的收益小。
2、NAS(神經架構搜尋): 也是現在大家研究比較多的廣義的超參搜尋, 此類AutoML會讓熱衷於排列組合的NN演算法研究者失業,不信你看efb系列模型,現在還有人質疑NAS搞出來的東西不能泛化嗎,efb已經有戰勝resnet的苗頭...各位熱衷於設計一個新的結構的模型,怕是手動擋再也打不過機器了。
3、AutoTable 寬表上的automl: 這是各大創業公司的pr的主戰場,特點就是別管技術深度怎麼樣,先把牛吹出來。此類AutoML不會讓演算法工程師失業,谷歌,第四正規化,H20, charlen等國內外知名公司都有落地的產品可以使用。不過話說回來,AutoTable其實是反NN潮流的,NN熱衷於從隱式特徵工程出發,相比起來,autoTable大概就NN眼中的皇帝用金鋤頭種地吧。 大規模稀疏資料上,這類演算法的發揮作用空間不大,提升有限,典型的場景如廣告,推薦等。不稀疏的資料呢,如銀行等,特點就是追求可解釋性,此類演算法搞出來的三階四階特徵別人也不敢用,所以十分尷尬。 這類問題最難的是自動特徵工程+特徵篩選, 神經網路聽到這個就笑了。這就是為啥autoTable是NN眼中的皇帝用金鋤頭種地。
但是,第三類automl不是完全沒作用的,只要你放棄讓他用金鋤頭種地,別想著一步到位搞定所有的問題。 退一步來講,打通資料和常用的EDA,做一些常用業務上的成熟特徵工程封裝,做一個不追求搞定NP難的特徵篩選演算法,做一個好用的演算法部署平臺,豈不是能極大減輕ML工程師的工作量,這個產品非常適合做2b演算法的廠子。
這三類裡面學術研究價值最大的是1,2 以及3中的部分問題。商業價值最大的是3。
總結起來:優秀的AutoML將會成為演算法工程師的發揮更大價值工具,比如NAS把模型研究者的排列組合工作轉化成搜尋空間設計,和更好的meta結構的設計。AutoTable把演算法工程師從 ETL,畫圖,梭#哈特徵,部署中解脫出來,更專注於業務問題的演算法抽象和定義,探索演算法的商業價值。
-------------------------------------------------------------------------------------------------------------
非常肯定地說: 不會!原因有三:
- AutoML的理論上的最佳化難題解決的還不到位,搜尋空間還要 專家來定義,注意真的是專家才能定義好;
- AutoML還有很多功能沒有探索完,單說NAS這一個坑,不同的任務不同的資料集 需要思考的東西差異性很大。比如底層視覺和目標檢測,loss的設計,評價方法的選擇都不一樣;
- AutoML本身自己還有 很多引數需要嘗試,做不到真正的一鍵解決所有問題。
所以,無論是做專案的同事還是科研人員,都Dark不必過分焦慮,還有很多路要走。 那現在paper這麼多,開源就是歌很有意義的事情了。
華為諾亞方舟實驗室昨天就 開源了自研的Automl演算法集VEGA,囊括了三年內實驗室大量的演算法相關同事的工作和心血( 20+ CVPR NIPS ICCV AAAI KDD等),歡迎大家試用,祝Automl早日可以真正的auto起來~
作者:王雲鶴
連結:
來源:知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。
-------------------------------------------------------------------------------------------------------------
在真正的通用人工智慧出現前,人在演算法設計中的作用都是不可替代的。
模型需要什麼樣的特徵?要靠人來設計和採集。
建模的目標是什麼?需要演算法工程師根據業務目標來設計。
你以為演算法工程師只是建模嗎?不是的,在一家小氣的公司,演算法工程師還要負責很多和數學有關的工作,比如設計最佳化演算法,包括但不限於線性,非線性規劃,遺傳演算法。
你以為模型只要有深度神經網路就夠了?扯淡吧。神經網路只適合有大量樣本且先驗知識不足的過程。實際過程中樣本少,但是先驗知識多的情況多的是,你需要用自己設計的結構去充分利用這些先驗。
你以為會演算法就夠了?你好歹有點資料統計分析能力。一般的相關性分析,交叉分析,因果分析,統計推斷等等,也得會啊
總之,現在的模型,還需要人來輔助進行目標確定,原理分析,特徵工程等,這些都是當前人工智慧的盲區。
作者:市民梁先生
連結:
來源:知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權,非商業轉載請註明出處。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69946223/viewspace-2702670/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 在Mac上訓練機器學習模型,蘋果WWDC釋出全新Create ML、Core ML 2Mac機器學習模型蘋果
- 國外機器學習工程師正面臨失業,為什麼他們還在堅持學習ML?機器學習工程師
- Etsy使用交錯新演算法實現更快的ML實驗演算法
- Atom在Vscode衝擊下被淘汰 - githubVSCodeGithub
- AI和ML如何幫助對抗網路攻擊?AI
- 04 ML 決策樹入門 ID3 演算法實現演算法
- .NET開發人員如何開始使用ML.NET
- ML 工程師需瞭解的 10 大演算法工程師演算法
- 什麼是資料中毒?如何防範攻擊者的AI和ML攻擊?AI
- ML-機器學習基礎機器學習
- ML-機器學習實踐機器學習
- ML學習路線
- 在系統中大量使用觀察者模式會有什麼不好的後果模式
- ML-資料分析模板
- 簡單理解:ML、DB、NLP
- [np-ml] Ridge Regression
- 03 ML KNN 實現的婚戀網站分類匹配KNN網站
- “reopen”域名在美國大量激增,如何看待“網路門牌”背後的攻擊價值?
- 現在企業會要求JAVA人員會怎樣的技術呢?Java
- 筆記:ML-LHY-22: Ensemble筆記
- PHP—ML 演算法,矩陣返回的物件,裡面的值如何取出來?PHP演算法矩陣物件
- 如何根據資料的分佈來選擇ML演算法? - Reddit演算法
- 改進AI/ML部署的5種方法AI
- 縮放Python ML:使用不同的工具來擴充套件Python ML工作負載的玩家部落格Python套件負載
- ML.NET技術研究系列-2聚類演算法KMeans聚類演算法
- 神奇女俠下海拍片?都是 ML 演算法搞的……這是如何做到的?演算法
- 專訪沈惠中:在我的平臺下Java高手即將失業Java
- 規則引擎與ML模型的比較 - xLaszlo模型
- Flink ML的新特性解析與應用
- ML-熵、條件熵、資訊增益熵
- ML-隱馬爾可夫模型隱馬爾可夫模型
- ML拍照購物功能整合教程分享
- Apache Flink ML 2.1.0 釋出公告Apache
- Apache Flink ML 2.2.0 釋出公告Apache
- spark Ml 機器學習之 線性迴歸Spark機器學習
- WWDC 2018:初探 Create ML
- [譯]Create ML教程:開始入門
- 超簡單整合HMS ML Kit 實現parental control