如何從先期的失敗中找到一條成功之路,本文試圖作了一番探討。——Caleb Kaiser寫于 2020 年 4 月 24 日。
成都創(chuàng)新互聯(lián)公司專注于萊州網(wǎng)站建設服務及定制,我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供萊州營銷型網(wǎng)站建設,萊州網(wǎng)站制作、萊州網(wǎng)頁設計、萊州網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)公司服務,打造萊州網(wǎng)絡公司原創(chuàng)品牌,更為您提供萊州網(wǎng)站排名全網(wǎng)營銷落地服務。2019 年初,我們幾個人嘗試構建一個端到端的機器學習(ML – Machine Learning)框架。我們從這次嘗試中得到的基本體會是,構建機器學習管道是一個令人沮喪的、毫無邏輯的體驗,而且我們應該可以構建更好的東西。
這次嘗試并沒有按照原先計劃地進行。
我將在本文對這次嘗試作一個詳盡地介紹,下面先介紹大致情況:
我們使用Kaggle數(shù)據(jù)集為機器學習管道的數(shù)據(jù)接收、訓練、部署等不同階段編寫了抽象。
我們將代碼庫開源并共享。一個月后,我們的項目登上了HN的首頁。每個人都喜歡那些改進機器學習用戶體驗的想法。
六個月后,我們只收獲了幾百顆GitHub星星,幾乎沒有人使用它。我們不得不將我們的傲氣擱到一邊,刪除了代碼庫中90%的代碼。
在經(jīng)歷了以上這些過程后,我們構建了一個更好的項目 - Cortex,我們的模型服務基礎設施。對于任何對機器學習研究和/或應用感興趣的人來說,我們想讓這個過程成為一種警示:
生產(chǎn)型機器學習系統(tǒng)確實需要更好的用戶體驗,但是機器學習生態(tài)系統(tǒng)是非常復雜和不斷變化的,這使得構建一個涵蓋大量用例的解決方案非常困難。
我們大多數(shù)人(Cortex的貢獻者)都有devops和web開發(fā)的背景,習慣于將應用程序的不同層抽象為單個接口的框架。
當我們進入機器學習時,每個人都被工具的支離破碎所震驚。我們想構建推薦引擎和聊天機器人(或者更確切地說,會話代理),但在這樣做的過程中,我們發(fā)現(xiàn)自己不得不在不同的環(huán)境之間(Jupyter Notebook、終端、AWS控制臺等等)跳躍。然后把包含有膠水代碼和TensorFlow樣板文件的整個文件夾寫到一起,用一個稱為“管道”的強力膠帶粘合起來。
如果我們可以用一個配置文件和命令粘合在一起來代替以上所有的步驟,比如:
$deployrecommendation_engine那顯然是個好的主意。
所以我們就這么做了。我們構建了這樣的一個框架,它使用Python轉換數(shù)據(jù),使用YAML構建管道,并使用一個CLI(命令行界面)控制所有步驟:
當你使用我們支持的窄技術堆棧,同時加上對API的限制,向它提供Kaggle數(shù)據(jù)集時,成為了一個非常好的框架。
然而,如果你想嘗試在現(xiàn)實世界中使用它,基本上很可能它不會與你的技術堆棧一起工作。毫無疑問這是一個問題。雖然這個問題的其中一部分原因歸結于我們的設計,但很大一部分原因實際上是因為構建端到端機器學習框架的固有局限,我們只是在構建了這個端到端機器學習框架之后才發(fā)現(xiàn)這一點。
簡單的一種說法是:對于端到端的框架來說,生產(chǎn)型機器學習生態(tài)系統(tǒng)太簡單,不可能既不靈活又正確無誤。
機器學習工程師希望使用更好的UX工具,這一點我們沒有錯。我們的錯誤在于我們以為可以構建一個覆蓋多個用例的端到端機器學習框架(特別在只有幾個貢獻者的情況下)。
有一件事很值得去做(而在項目的早期被我們忽略了),那就是思考一下曾經(jīng)給我們啟發(fā)的web框架,并記住他們第一次嶄露頭角的時候。
Rails、Django和Symfony,作為web應用的新MVC框架浪潮的一部分,它們都是在 2004 年到 2005 年間發(fā)布的。當時的web開發(fā)還不能稱為“穩(wěn)定”,尤其是考慮到自那以后它們是如何變得成熟的(在很大程度上要感謝那些框架),但是web開發(fā)人員所做的工作和現(xiàn)在相比仍然有高度的相似性。
事實上,Rails最早的口號之一是“你不是一片美麗而獨特的雪花”,正是基于這樣的一個事實:大多數(shù)web開發(fā)人員正在構建架構上類似的應用程序,這些應用程序可以在相同的配置上運行。
生產(chǎn)型機器學習系統(tǒng)還未發(fā)展到那個階段。一切仍在變化之中。數(shù)據(jù)科學家處理的數(shù)據(jù)類型、使用的模型體系結構、喜歡的語言/框架、應用程序的推斷要求,以及幾乎所有你能想象到的一切東西,都在不斷變化中。
而且,這個領域本身變化也很快。自 18 個月前Cortex首次發(fā)布以來:
PyTorch已經(jīng)從一個僅僅前景看好的項目發(fā)展成為最流行的機器學習框架,在此期間許多專門的機器學習訓練庫(如微軟的DeepSpeed)已經(jīng)發(fā)布出來。
OpenAI發(fā)布了有史以來的模型,可以運行帶有 15 億個參數(shù)的GPT-2。此后,谷歌、Salesforce、微軟和Nvidia都發(fā)布了更大的機型(有些是同一數(shù)量級的)。
大量初創(chuàng)企業(yè)已經(jīng)開始使用遷移學習(Transfer Learning)和預訓練模型來優(yōu)化和部署具有少量數(shù)據(jù)的模型(比如說,并非每個人現(xiàn)在都需要一個 100 節(jié)點的Spark群集)。
所有這些都在不斷變化中,所以試圖構建一個支持“合適”技術堆棧的端到端框架從一開始就注定了失敗。
每個人都會要求他們需要的“一個特性”,而沒有人有相同的要求。我們試圖構建一些通用的特性,但很快就發(fā)現(xiàn)這是不可行的,至少不是我們想象的那樣。
構建一個端到端的機器學習框架是很困難的,因為大部分的機器學習生態(tài)系統(tǒng)仍然是“蠻荒的西部”。然而,其中的“模型服務”已經(jīng)具有了穩(wěn)定性和一致性。
不管他們使用什么堆棧,大多數(shù)團隊都是通過先將模型封裝在API中,然后部署到云端(盡管他們不喜歡這樣做)來將其投入生產(chǎn),。
數(shù)據(jù)科學家不喜歡它,因為用于構建彈性web服務的工具,如 Docker、Kubernetes、EC2/GCE、負載均衡器等等,都不在他們的觸手可及之處。DevOps工程師對模型推斷的獨特之處感到惱火。
但是對我們來說,這是一個機會?!澳P妥鳛槲⒎?model-as-a-microservice)”的設計模式對所有團隊來說是一致的,而它提供的工具,因為它是基礎設施(而不是機器學習生態(tài)系統(tǒng))的一部分,所以非常穩(wěn)定。更有利的是,作為軟件工程師,我們在構建生產(chǎn)型web服務方面比在構建機器學習管道方面更有經(jīng)驗。
所以,我們想在模型服務上嘗試一下。我們應用了相同的設計原則,抽象了聲明性YAML配置和最小CLI背后的所有低層次的不同,并自動化了將一個經(jīng)過訓練的模型轉換為一個可伸縮的生產(chǎn)型web服務的過程:
通過專注于模型服務,我們可以對堆棧的其余部不加理會(只要模型有Python綁定,Cortex就可以為其服務)。因為Cortex可以插入任何堆棧,所以我們對Cortex在底層使用的工具有了話語權,這又使得構建更高級別的特性變得更加容易。
例如,自從發(fā)布用于模型服務的Cortex以來,我們增加了對GPU推斷、基于請求的自動縮放、滾動更新和預測監(jiān)視的支持。我們不需要為十幾個不同的容器運行時和集群編排器實現(xiàn)這些功能。Cortex在底層使用Docker和Kubernetes,用戶從來不需要接觸它們中的任何一下。
到目前為止,這種改變似乎正在發(fā)揮作用:
從哲學上講,網(wǎng)絡框架對我們?nèi)绾慰创鼵ortex有很大的影響。
Rails和Django之類的框架使得程序員的工作效率和幸福感倍增。要構建一個web應用程序,你不必擔心配置SQL數(shù)據(jù)庫、實現(xiàn)請求路由、或編寫自己的SMTP方法來發(fā)送電子郵件。所有這些都從直觀,簡單的界面中抽象出來。
簡而言之,這就是我們對Cortex的看法。數(shù)據(jù)科學家不必學習Kubernetes,他們應該專注于數(shù)據(jù)科學。軟件工程師們不必花上幾天的時間來研究如何避免5 GB的模型浪費他們的AWS賬單,他們應該可以自由地構建軟件。
希望隨著機器學習生態(tài)系統(tǒng)的成熟和穩(wěn)定,我們能夠將這一理念擴展到堆棧的其余部分。目前,模型服務是一個不錯的開始。
相關鏈接:https://towardsdatascience.com/we-tried-to-build-an-end-to-end-ml-platform-heres-why-it-failed-190c0f503536
新聞名稱:我們想研發(fā)一個機器學習框架,6個月后失敗了
轉載來源:http://www.rwnh.cn/article24/cjhjje.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供搜索引擎優(yōu)化、App設計、網(wǎng)站制作、定制開發(fā)、做網(wǎng)站、ChatGPT
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)