建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)
超過十余年行業(yè)經(jīng)驗，技術(shù)領先，服務至上的經(jīng)營模式，全靠網(wǎng)絡和口碑獲得客戶，為自己降低成本，也就是為客戶降低成本。到目前業(yè)務范圍包括了：成都網(wǎng)站設計、成都網(wǎng)站建設，成都網(wǎng)站推廣，成都網(wǎng)站優(yōu)化，整體網(wǎng)絡托管，成都微信小程序，微信開發(fā)，App定制開發(fā)，同時也可以讓客戶的網(wǎng)站和網(wǎng)絡營銷和我們一樣獲得訂單和生意！
2019年初，筆者幾個人嘗試構(gòu)建端到端ML框架。我們認為，構(gòu)建ML管道是一種令人沮喪的、脫節(jié)的體驗，我們完全可以構(gòu)建更好的東西。但事情并不像想象中那樣順利。
我們使用Kaggle數(shù)據(jù)集為ML管道的不同階段(數(shù)據(jù)攝取、培訓、部署等)進行了抽象，并公開了存儲庫來源并分享。一個月后，它登上了HN的頭版，改進機器學習的用戶體驗是很多人的關切點。半年后，它在GitHub擁有了幾百個“星星”，但幾乎沒有人使用它。痛定思痛，我們刪除了90%的代碼庫。
經(jīng)歷這一切之后，我們建立了一個更好的項目：Cortex(模型服務基礎設施)。但對于任何對機器學習和/或ML工具感興趣的人來說，這都是一個警醒你的故事：
“生產(chǎn)機器學習確實需要更好的UX，但是ML生態(tài)系統(tǒng)是復雜和多變的，這使得構(gòu)建一個覆蓋大量用例的工具非常困難?！?/p>
為什么需要端到端ML框架
大多數(shù)人(Cortex貢獻者)都有devops和web開發(fā)的背景，他們習慣于將應用程序的不同層抽象成單一接口的框架。
每個剛剛開始學習機器學習的人，都會感慨工具的脫節(jié)。你想建立推薦引擎和聊天機器人，在這一過程中你會發(fā)現(xiàn)自己在不同的環(huán)境之間來回跳轉(zhuǎn)——Jupyternotebooks、終端、AWS控制臺等。編寫粘合代碼和TensorFlow樣板的整個文件夾可以被稱為“管道”，這是很必要的。
如果可以用配置文件和命令來代替所有的修改和粘貼：
- $ deploy recommendation_engine
看起來還不錯。接著我們構(gòu)建一個工具，使用Python來轉(zhuǎn)換數(shù)據(jù)，使用YAML來構(gòu)建管道，使用CLI來控制一切：
當你給它一個Kaggle數(shù)據(jù)集，使用支持的狹窄堆棧，再加上在api上設置的限制時，它是一個非常棒的工具。但問題來了，如果嘗試在現(xiàn)實世界中使用它，那么它可能無法與堆棧一起工作。
雖然有些問題歸結(jié)于設計，但很大一部分問題實際上是構(gòu)建端到端工具的固有問題——只是在構(gòu)建之后才發(fā)現(xiàn)。
端到端ML框架的問題
簡單地說，機器學習生態(tài)系統(tǒng)產(chǎn)品對于端到端框架來說尚未成熟。ML工程師希望使用更好的UX工具，這當然無可厚非。但是試圖構(gòu)建一個涵蓋多個用例的端到端框架，那你就錯了，尤其是特別是在只有少數(shù)貢獻者的情況下。
web框架或許會給我們啟發(fā)，想想它們是什么時候開始嶄露頭角的吧。
Rails、Django和Symfony都是在2004年到2005年間發(fā)布的，它們都是web新MVC框架的一部分。雖然那時的web開發(fā)可能不是“穩(wěn)定的”，特別是考慮到它走向成熟的過程(這很大程度上要歸功于那些框架)，但是web開發(fā)人員所做的工作仍然有高度的相似性。
事實上，Rails最早的格言之一是“你不是美麗而獨特的雪花”，這是指大多數(shù)web開發(fā)人員都在構(gòu)建架構(gòu)上類似的應用程序，這些應用程序可以在相同的配置上運行。
機器學習產(chǎn)品還沒有到那個階段，一切仍在變化之中。數(shù)據(jù)科學家在他們處理的數(shù)據(jù)類型、使用的模型體系結(jié)構(gòu)喜歡的語言/框架、應用程序的推斷需求以及幾乎所有能想到的其他方面都有所不同。
更重要的是，該領域本身就變化迅速。我們可以看到，自從Cortex18個月前首次發(fā)布以來：
- PyTorch已經(jīng)從一個很有前途的項目變成了比較流行的ML框架，同時發(fā)布了許多專門的培訓庫(比如微軟的Deep Speed)。
- 大量初創(chuàng)公司已經(jīng)開始使用轉(zhuǎn)移學習和預培訓模型來微調(diào)和部署具有少量數(shù)據(jù)的模型(例如，現(xiàn)在不是每個人都需要100個節(jié)點的Spark集群)。
- Open AI發(fā)布了有史以來比較大的模型，15億參數(shù)的GPT-2。此后，谷歌、Salesforce、微軟和英偉達都發(fā)布了更大的型號。
變化從未停止，這意味著試圖構(gòu)建一個支持“正確”堆棧的端到端框架從一開始就注定要失敗。
每個人都會要求他們需要的“一個功能”，但是沒有人有相同的要求。我們嘗試了一段時間，但很快發(fā)現(xiàn)“用Django換ML”是不可行的，至少不是想象中的那種方式。
關注模型服務基礎設施
端到端是很困難的，因為ML生態(tài)系統(tǒng)的大部分就像“蠻荒之地”般尚未成型。然而，有一個領域是穩(wěn)定和一致的：模型服務。
不管使用什么堆棧，大多數(shù)團隊都是通過將模型包裝在API中并部署到云中來將模型投入生產(chǎn)的。但數(shù)據(jù)科學家不喜歡它，因為用于構(gòu)建可伸縮web服務的工具——docker、Kubernetes、EC2/GCE、負載均衡器等等——都不在他們的控制范圍之內(nèi)。
這是一個好機會。模型，即微服務的設計模式在團隊中是一致的，而作為基礎設施一部分的工具，也是非常穩(wěn)定的。同時，作為軟件工程師，在構(gòu)建生產(chǎn)web服務方面比ML管道更有經(jīng)驗。
所以，我們認為應該給模型這個機會。我們應用了相同的設計原則，抽象了聲明式Y(jié)AML配置和最小的CLI背后的所有低層爭論，并自動化了將經(jīng)過訓練的模型轉(zhuǎn)換為可伸縮的生產(chǎn)web服務的過程。
通過專門關注模型服務，我們可以不知道堆棧的其他部分(只要模型有Python綁定，Cortex就可以為它服務)。因為Cortex可以插入任何堆棧，開始對Cortex在底層使用的工具有自己的看法，這反過來又使它更容易構(gòu)建更高層次的功能。
例如，自從發(fā)布了用于模型服務的Cortex之后，增加了對GPU推理、基于請求的自動縮放、滾動更新和預測監(jiān)控的支持。不需要為十幾個不同的容器運行時和集群協(xié)調(diào)器實現(xiàn)這些特性。Cortex在引擎蓋下使用了Docker和Kubernetes，而且用戶根本不用操心它們。
到目前為止，這種方法似乎是有效的：
圖源: Star History
將web開發(fā)的經(jīng)驗應用到ML工具中
從哲學上講，web框架對如何看待Cortex有很大的影響。
像Rails和Django這樣的框架非常重視程序員的工作效率和幸福感。要構(gòu)建web應用程序，你不必擔心配置SQL數(shù)據(jù)庫、實現(xiàn)請求路由或編寫自己的SMTP方法來發(fā)送電子郵件。所有這些都被隱藏到直觀、簡單的接口之后。
Cortex也是同樣的。數(shù)據(jù)科學家不必學習Kubernetes，而是專注于數(shù)據(jù)科學。工程師們也不需要浪費幾天時間來研究如何避免5GB版本的把他們的AWS賬單搞到爆炸，他們可以自由地構(gòu)建軟件。
我們希望，隨著ML生態(tài)系統(tǒng)的成熟和穩(wěn)定，這樣的“哲學”會慢慢擴展到堆棧的其他部分。而現(xiàn)在，模型服務就是一個很好的起點。
本文題目：知道因為啥失敗嗎？構(gòu)建端到端ML框架的經(jīng)歷啟示錄
新聞來源：http://m.fisionsoft.com.cn/article/djigcoi.html
