cs329s/課程01/了解機器學習產品-3

今天來談談,在機器學習系統開發的過程當中,除了那些已經熟悉的資料科學工具之外,那些可能被忽略的工具:像是資料驗證、資料標籤、模型監測、CI/CD 測試、部署、模型壓縮、推理效能優化、隱私等等,有哪些Python框架可以放進學習清單。文章的後半部也跟大家分享5個部署機器學習系統的迷思。

cs329s機器學習系統設計這堂課是史丹佛2021年1月新開設的一門課,講述除了機器學習理論之外,實務上在設計系統的時候所需要注意的各種主題。文章的內容是看完投影片跟課堂筆記,加上自己之前的開發經驗寫下來的。所有的教材請見官方網站

假如前兩篇你還沒讀過的話,歡迎先複習:

那些可能被忽略的Python框架

資料驗證:怎麼去測試資料的實用性和正確性?怎麼知道目前的資料採樣對於系統是正面或是負面的影響?舉例來說:在TensorFlow Data Validation就可以透過資料集在不同面向(Facets)的特徵進行多方面比較。像是某個欄位所需的值的範圍,透過檢查這些缺失或者超出範圍的值,使得開發者可以更快的知道資料集的狀況,進而改善資料集的品質以及可用性。

資料和模型的版本控制:怎麼對資料集和訓練過程的checkpoint做版本控制?每一行相互比較的Git,並不能作用在資料集和checkpoint的版本控制上。更不可能單純的把每一次的資料集複製成好幾份。當遇到需要合併(merge)資料集的時候,可以使用哪些工具?舉例來說:DVC

模型監測:要如何知道資料分布已經偏移了,偏移到需要重新訓練模型。舉例來說:Dessa公司的PM在Data Concil 19分享的一場演講提到,模型監測通常包含三元素:Python SDK + 排程 + 圖像化互動介面。透過這三個元素,透過持續觀察想優化的函式出來的值,以及幾個比較關鍵的統計特徵變化多少,來決定下一步的方向。(該場演講的投影片演講影片

標籤資料:如何可以快速的標示新的資料,以及更新既有的資料與標籤給新的模型?舉例來說:Snorkel這個library就提供三個主要的函式,協助開發者從少量的資料,快速的擴充其資料集。像是標示函數(labeling functions)、轉換函數(transformation functiona)跟切片函數(slicing functions)。關於這三個函數的詳細介紹,可以參考官方文件

(圖片來源:https://github.com/snorkel-team/snorkel)

CI/CD 測試:如何確認模型在變更之後,其行為符合期待?舉例來說:透過Argo和工作流程以及資料流互動,以達成基於DAG(Directed acyclic graph based)或是基於線性步驟(step based)的工作流程。在持續交付和迭代的過程當中,也支援Gitops、藍綠部署(Blue-Green)和金絲雀部署(Canary)。GitOps透過使用Git當作應用程序的單一事實來源來工作,在git上的程式碼更動時,會引發相對應的部署、維運相關的工作。透過GitOps,Kubernetes協調器會根據情況自動更新或回到前一個版本。其中藍綠部署的目的是減少發佈時的中斷時間,能夠快速撤回發佈。藍綠部署是準備兩套系統,在兩套之間進行切換,金絲雀策略是只有一套系統,逐漸替換這套系統裡面的服務。

部署:如何能夠最無痛的把模型部署完成?舉例來說:OctoML,使用的Apache TVM,特別專注在編譯來自不同深度學習框架的模型成最小的可部署模組,方便部署到各種不同的硬體端上。基於Apache TVM的框架上,OctoML則強調能夠簡單、快速地透過網頁UI或是API部署與地端、雲端或者edge端的硬體整合、且這些優化是基於分析這個模型將使用多少的記憶體和FLOPs的數據為基礎去做出的分析。以及Coral SOM(System-on-Module),針對在邊緣裝置優化的系統。

模型壓縮:如何將模型壓縮到某些檔案大小之下,以便於部署在特定的環境?舉例來說:像是NNIdistiller。還有一間Xnor.ai, 專注於做模型壓縮,已被蘋果用約200M美金買下。

推理效能優化:如何能夠加速模型推理、預測的時間?我們可以使用較低的精度嗎?縮小模型可能會加快推理速度嗎?舉例來說:TensorRT,一個用C++開發,針對在NVIDIA GPUs上的高效能推理框架。

隱私:如何在訓練模型的過程,仍然保持用戶的隱私?如何使資料處理的過程當中仍符合GDPR的規範?看看PySyft,出自資料安全和私有深度學習的Python框架。 PySyft使用聯合學習,差分隱私(Differential Privacy)和加密計算(Encrypted Computation)將模型訓練中的私人數據分離。想針對這部份瞭解更多的,也可以來上這一堂由Facebook在udacity開的課:Secure and Private AI

(圖片來源:https://www.udacity.com/course/secure-and-private-ai–ud185)

5個部署機器學習系統的迷思

迷思 #1. 部署是一個艱難的任務

如同我們在前面1-2所提到的,研究型的機器學習與業界的機器學習在實務上有哪些不同。這些不同之處,也是許多資料科學家從學術到業界,必須要克服的門檻。取決於他們加入的公司類型以及團隊的分工型態,在開發程式的職能上,這些資料科學家也必須要從過去專注在模型開發上,走到部署、產品化的技能學習。

因此,許多資料科學家所擔心的,便是怎麼樣部署模型。

事實上部署是一件不難的任務,並不是如你想像的這麼可怕。如果目標只是希望把一個模型部署上線,成為雲端服務的一部分。當熟悉這些工具以及平台之後,部署可能只花你不到一小時的時間。如果搭配上自動化,又是更快速的流程了。

但是,部署之後的可靠度這就是困難的了。假設模型上線之後,有數百萬個用戶會去使用它,不管是可靠度、系統回應時間、資源配置等等,這些系統上的監控以及調整,都需要適當的基礎架構當做基底。在臨時出現問題時,能夠及時通知合適的人做相對應的處理,並且在系統訊息上可以快速的查找問題的原因。

在訓練模型上的難度,與模型部署的難度是不同方向也不同程度上的比較。

如果有時間大家也可以看一下這一篇:Challenges in Deploying Machine Learning: a Survey of Case Studies,裡面談到,在部署模型的時候所要考慮的”整合,監控和更新”,以及部署後要照顧的層面還有:倫理、終端用戶的信任問題、安全問題。

迷思 #2. 一次只能部署一個或者兩個模型

在做學術研究的時候,大部分的情形是專注在小型的問題,或是特別特定的情境下所發展出來的模型。許多從學術背景出來的人,對於機器學習應用的想法,大多是支援在一個到兩個模型的情形之下。

然而在業界上,許多公司需要部署非常大量的模型。一個應用程式會有不同的功能,每個功能都有其獨立的模型。假設像是Uber這樣的公司,會需要預測司機需求、司機的可調用性、預計抵達時間、最優化的乘車價格、避免假帳號、避免假交易、推論客戶流失等等。假設這個產品在不同的國家或城市營運,這些不同的市場也會需要不同的模型。假設有20個國家和10個城市,每一種模型可能會需要200個不同的版本。實際上Uber所需要的模型大約是數千個模型。

以下這張圖表來自Netflix在InfoQ的一場演講,談論Human-Centric Machine Learning Infrastructure,這張投影片顯示光是在netflix裡面的深度學習模型種類就有多少種。

(圖片來源:https://www.youtube.com/watch?v=XV5VGddmP24)

迷思 #3. 如果什麼都不做,模型的表現也會一直維持不變

假設機器學習模型不隨著時間更新。該系統所呈現的效能是有機會隨著時間逐漸下降的。這是和一般的軟體系統相比十分不同的部分。

我們在1-2提到概念漂移的困擾,幾個月以前訓練好的模型,經過一陣子之後總是需要去檢查,是否有資料漂移的情形,是以多快的時間偏移等等。而這些數據,也是更新模型以及系統的依據。

迷思 #4. 不需要盡可能的常常更新模型

承襲上一個迷思,可能有些人會提出問題,像是”我應該多久更新一次?“但這個問題應該要調整成”我可以多久更新一次?”第一個問題的口氣比較像是在被動的等待別人給一個答覆。第二個問題比較偏向自己掌握主控權,只要環境允許,數據狀況也允許我就能推出一次更新。

在機器學習的領域,可能每隔幾個月,該問題就會有更新的演算法出現,這些新的算法每一次都提供我們一個更新的刺激去思考是不是有更好的解法。同時在模型的部署上,一個完善的模型部署系統,則是可以讓系統以非常短的時間之內迭代到下一個模型。舉例來說:Etsy每天部署50次,Netflix每天部署1000次,AWS每11.7秒部署一次。以下圖為例,微博的機器學習迭代周期為10分鐘,而且阿里巴巴和ByteDance等公司也是差不多維持在這樣的數據之間。

(圖片來源: https://www.youtube.com/watch?v=WQ520rWgd9A)

迷思 #5. 大部分的ML工程師不需要擔心規模以及系統擴展性

“規模”可以從很多層面來說。這一個迷思的破解我們從市場上的公司規模數據來做推論,假設一間大於100個員工規模的公司,其服務的規模也會相對應較大,對應到相對大型的客群。Stack Overflow的統計上,超過一半的公司是屬於100個員工等級以上的規模。也就是說,大部分的人都有機會去思考規模、以及系統擴展性的問題。

(圖片來源:https://insights.stackoverflow.com/survey/2020#work-company-size)

*註:這一份報告反映出的雖然只是開發人員的佔比,只是相對呈現市場的概況。若之後有針對ML職位的研究,也可以在這點上面做補充。

迷思 #6: 機器學習會對你的公司展開一夜成功的神奇魔法

當機器學習變成人人口中都談到的一個工具時,媒體也會開始圍繞著機器學習宣傳,能夠拉上邊的就盡可能去沾上邊。一些公司可能會想說ML可以奇蹟般地讓他們在一夜之間改善業務狀況。

是有可能像是魔法般的神奇。但是ㄧ夜之間帶來的業務轉變,則是真的想太多了。

許多公司從機器學習當中的獲益,像是能夠展示更好的搜尋結果、推薦更適切的商品、以更貼近市場的價格售出貨物等等。這些都只是在眾多業務當中能夠推動的一小步進展,實際上的改善還是需要從既有流程去追溯。機器學習的投資回報,取決於導入的成熟階段、模型在市場中運行的狀況越成熟、開發迭代週期越快等等。其中使用產品階段模型超過五年以上的公司當中,幾乎75%的公司可以在30天內部署模型。在剛開始使用機器學習管道的企業中,有60%的企業需要30天以上的時間來部署模型。

不管是推出新測試,或是回溯到前一個測試前的版本等等。這些系統迭代,也必須與商業策略調整一起搭配發生變化,才會對業務狀況發生影響。

結語

今天講了兩個部分:
(1)機器學習系統開發過程當中你可能忽略的工具
(2)5個部署機器學習系統的迷思。

希望當中有讓你學習到一些新知,也歡迎提出問題及想要瞭解更多的部分。

歡迎訂閱粉絲頁TG頻道。我們下次見。

cs329s/課程01/了解機器學習產品-2

前幾天發佈了<了解機器學習產品-1>,獲得還不錯的迴響。感覺像是機器學習系統這樣的主題,對大家來說也都是當前想要學習的。

如果是第一次看這個主題的朋友們,cs329s機器學習系統設計這堂課是史丹佛2021年1月新開設的一門課,講述除了機器學習理論之外,實務上在設計系統的時候所需要注意的各種主題。文章的內容是看完投影片跟課堂筆記,加上自己之前的開發經驗寫下來的。所有的教材請見官方網站

今天會談到的內容,是cs329s第一堂課的第二半部,主要是探討機器學習系統與軟體系統的不同。雖然這個主題上次在<<what’s MLOps?>>也曾經跟大家討論過這個題目,以及在導入MLOps的典型障礙,想複習的同學可以再點回去看。

今天從這堂課所切入的面向來討論吧!!

機器學習系統與一般軟體的比較

由於ML是軟體工程(SWE)的一部分,且軟體工程已經存在了幾十年,也因此有些人就在思考,把軟體工程當中,經得起考驗的幾個最佳實踐拿來應用在ML當中好了。而因此大家常聽到的MLOps也是從DevOps當中學習到很多重要的經驗。

在一般軟體開發的過程當中,程式和資料的邏輯是分開的,在關注點分離的基礎上,我們會希望盡量模組化和盡可能相互獨立。然而這樣的情形,在機器學習的系統當中就無法成立。舉凡資料整理的過程,會和資料欄位有很高的機會相互影響,在每一次的實驗,我們也希望儘可能地透過版本控制保留當下的訓練資料、參數、測試資料。怎麼樣的保留版本會對團隊合作是最方便回溯的,這些議題也會需要負責資料、負責模型、負責維運的同事們一起來看這個問題。

在實務上,從模型上線之後,團隊對於機器學習模型的關注度,就會相對降低。大部分的關注度會放在維運狀況、系統從預測到回傳結果的反應時間、新的數據和訓練集相比是否飄移或者傾斜、機器學習系統是否能很快速的更迭以適應外在的變化。

在這邊也補充一下資料飄移(data drift/concept drift): 在大多數跟數據相關的應用當中,例如統計、機器學習以及其他分析,新收集到的數據會隨著時間的推移而發展,這些發展可能會使得過去收集到的資料集,在數據分佈上會落在不同的區間,使得特徵值所代表的意義也會跟著變化。因此,為分析這些數據所建立的模型,隨著時間的過去變得過時的狀況。在機器學習和數據挖掘中,這種現象稱為概念漂移。

如同這一門課的老師Chip所說,機器學習系統的開發大概10%是機器學習,90%是軟體工程。(被Elon Musk按讚到底是什麼樣的心情!)

(圖片來源:課程教材)

版本控制

在Git上可以使用git diff去看程式碼的變動,可是對資料集要怎麼git diff? 對於資料集的版本控制,需不需要儲存中間的check point,這樣會佔據多少的儲存空間? 從版本控制上面拉下來的數據,要怎麼做合併(merge)? 選擇誰的版本做變更?

雖然目前市面上有幾個可以對資料做版本控制的工具,像是DVC、Delta Lake、Git FLS、…等等眾多工具。不過這幾個工具跟市面上現有的pipeline整合也還是有限,以下面這張表格來說,倘若舉出最重要的四五個功能,可能在現有的工具上都無法很全面的達成。

舉例來說,每一個工具不一定和各種資料型態都能合作得很好;不見得都與各家雲廠商的服務能夠接得上;如果是使用門檻比較低的,常常也比較缺乏功能的完善,需要使用者自己稍做一些開發,調整成適合自己團隊使用的模式;另外對大型資料的支援也不是每個工具都能夠做到。相信還有其他的層面,是這張表格沒有列舉出來的,歡迎大家集思廣益,分享其他做資料版本控制遇到的痛點。

(圖片來源:Comparing Data Version Control Tools — 2020)

測試資料

在測試資料的準備上,其正確性以及代表性可以透過以下幾個問題去思考:測試資料跟模型的使用情境是相符合的嗎?如果是音頻/影像/影片/文字的資料型態,”相符合”的這個部分可以怎麼去量化?以及怎麼知道資料的分佈是否相同以及改變?怎麼樣範圍內的資料改變我們可以忽視它,或是等一下再處理?

如果在測試模型的過程,發現模型和你想像的表現不同?就應該要馬上把它加入訓練集當中更新模型嗎?另外,針對每一個與原本預想不同的預測,有一個適當的流程去評估怎麼樣把他加入下一次的訓練資料?這個被新增進去的資料點是這個系統想要呈現的行為嗎?還是其實並不影響終端使用者的體驗?

在測試模型的時候,什麼樣情境的測試結果你可能會想要給予這個資料點更多的權重?也許這個資料點後面代表的是公司所在乎的VIP?抑或是這些資料點的失誤,可能會造成公司重大的金錢或名譽損失?

資料中毒

延續剛剛的測試資料是否應該回到訓練集裡面,作為下一次的訓練資料。由於當前的許多影像分類模型都是使用類似的架構去做修改,因而相對容易透過一些特定的模式,設計出一些讓模型訓練的過程受到干擾,但人眼無法識別出來的資料,讓模型的行為因此受到改變,也就是資料中毒(data poisoning)。

以下圖的例子來說,x原本在特徵空間裡面的值是h(x),加了一些擾動δ*,使得h(x+δ*)會變到畫面的左邊。這個擾動是人眼看不出的變動,但是在經過h的計算後,他的值可能會對應到跟原本的h(x)不同的特徵空間。這時候如果把h(x+δ*)也放進去訓練,本來X-victim應該被歸類為人類,但是因為模型被干擾了,所以被干擾之後,模型選擇分類的邊界也跟著被移動,X-victim就被模型歸類為青蛙了。

(圖片來源:Data Poisoning Attack的講解)

舉凡像是蓄意上傳某個公眾人物的照片,但是標註成別的標籤,讓其他使用者在搜尋這個標籤的圖片的時候,就會收到其他被模型錯誤標記的圖片。這樣的情境也會發生在一些個人化的模型上,舉例來說某些應用程式會針對每個使用者有其個人化、本地化的模型,再將匿名過後的模型共享,與其他使用者的模型合併,這是大家熟知的聯邦學習(Federated Learning)。

在這樣的狀況下,假設某一個使用者刻意標記某些有毒的數據,嘗試去污染這間公司的模型,這樣就使得其他使用者的權益受到影響。這些攻擊有時候其作用並不是真的要讓A類別完全變成B類別,只要讓跟他們有相關的數據,在模型預測的時候發生變化,達成他們想要達成的目的就夠了。(想想也是蠻可怕的對吧!)

較大的模型

截至2020年為止,許多的機器學習模型參數已經來到了數億等級,這意味著我們會需要較大的RAM來加載模型。但同時,也有越來越多的模型被使用在邊緣設備(edge device)上,那接下來需要權衡的,就會是邊緣設備的硬體、模型準度、以及使用者體驗的這三項了。

想像一下當你在打字的時候,建議字元如果在打字完後五秒才跳出,那乾脆不要跳出來好了。又或是因為邊緣設備的硬體侷限,使得每一次的模型在測試跟發佈都要耗費大量的時間去部署及更新,這也是想到就覺得累。

不過,科技也是基於人性的需求所帶來的改變。如果希望可以更快速的使用BERT,或是希望可以使用較小版本的BERT。可以透過幾個方式壓縮模型,像是修剪神經元(Neuron pruning)、刪除權重矩陣(Weight pruning)、將大型模型學習成較小的模型等等。2018年的BERT模型,其預訓練模型具有340M參數,大小為1.35GB。到2020年,BERT已在Google的英語搜索中被大家使用。

結語

本來想說上下兩篇就可以寫完,殊不知這一個段落展開也是蠻多內容的,可能需要到第三篇才能寫完第一堂課了。哈哈哈哈,我自己也沒想到是這樣的超展開。不管是文章長短、翻譯選字、內容深淺等等,如果有什麼建議再提出來一起討論。第一堂課的第三部分就下篇文章再跟大家分享了。

歡迎訂閱粉絲頁TG頻道

下次見:)

參考資料

資料飄移:A Primer on Data Drift

聯邦學習:用漫畫學習Federated LearningTargeted Backdoor Attacks on Deep Learning Systems Using Data PoisoningPoisoning attacks on Machine Learning

模型壓縮:Compressing BERT for faster predictionPruning BERT to accelerate inference

cs329s/課程01/了解機器學習產品-1

最近花了一些時間在看機器學習系統相關的內容,就發現了cs329s還有其研討會的線上資料。除了課程內容是最近蠻感興趣的議題之外,投影片本身也放了很多巧思在裡面,看得出教學團隊的用心。

課程介紹

史丹佛有許多機器學習相關的課程,而在2021年,有一堂從1月開始的課:CS329S:機器學習系統設計。目前只有投影片跟課程筆記有對外開放,所以你所看到的摘要就是從投影片跟課程筆記當中整理,加上一些個人的經驗跟陳述。所有的教材請見官方網站

課程總覽

什麼是機器學習系統設計?
定義介面, 演算法, 資料, 系統架構, 和硬體給機器學習系統以達到某些需求的過程。而這些需求包含:可靠的, 可擴展的, 可維護的, 適應性強的。

(圖片來源)

研究型 vs 產品型 機器學習系統

從這個表格可以看到,產業用機器學習以及研究型機器學習在乎的事情其實不太相同。舉例來說,從架設系統的目標、對於系統的要求、資料變動程度、對於模型與資料的公平性與可解釋性的要求也不同。

(圖片翻譯自課程教材)

在開發機器學習系統的過程當中,會牽涉到許多的利益關係者(stackholders)。每一個人都有自己的目標。舉凡ML工程師、銷售、產品經理、架構師和管理者,所看到的面相以及自身出發點可能都不同。下圖就是一個很好的例子。(*老師挑的圖也太可愛了吧!)

(圖片來源

而在產業當中也正是因為這些利益關係者的緣故,因此在開發的過程當中,可以感受到彼此的角力。反而對於使用者來說,真的體驗到的是這些不同角色溝通(吵架?)之後的結果。

對於系統要求的部分,基本上研究型的機器學習開發,會花大部分的時間在模型與算法的調整跟優化。實務上的機器學習,如果把一個模型訓練以及上線後的產品循環一起看,在模型訓練上的花費其實佔了很少的一部分,在上線之後,會使用到的資源及花費,包含模型部署、模型監測、模型擴展、預測資料紀錄等等。

在資料處理上,研究型的環境處理的資料屬於靜態,或者較少變動的。而產品型的模型則是持續會遇到不同類型的使用者資料,在模型上線後也需要持續的關注,是否有預測偏差、偏差了多少、是否需要重新訓練等等的問題。

這也是為什麼並不是每一個paper的模型在實務上都可以馬上使用的緣故。有非常多的細節在這當中會需要被調整跟溝通。

未來的模型英雄榜會是什麼樣子

在實作機器學習模型的時候,大家常常會說要去看leaderboard(英雄榜)。這一堂課程的課程討論題目是:(1)現在的英雄榜多專注在單一任務,應該也要出一個英雄榜給多任務的嗎?(2)機器學習模型越來越大。會如何影響這些模型在產品階段的可用性?

(圖片來源)

雖然這兩個問題並沒有最好的解答,不過這堂課的老師也提出了一個版本讓大家參考。是不是應該要更全面性的去評估一個模型與其系統,整個的模型表現、系統延遲、每一筆預測的花費、可解釋性、模型健壯性等等的評估都把它考量進去。

還有這個系統是不是容易被其他人拿去使用,需不需要針對不同的資料及以及場景修改這個系統。還有就是如果資料改變的時候,可以怎麼樣最快調整。

結語

這堂課我先摘要了第一部分,感謝大家容忍我破舊的中文翻譯,中間很多字都必須想很久,如果有什麼建議再提出來一起討論。第一堂課的第二部分就下篇文章再跟大家分享了。有興趣的話還是可以直接去看這堂課的原本資料,第一手資料最優 😀

歡迎訂閱粉絲頁TG頻道

下次見:)

機器學習應用的雲端服務架構最佳實踐

(圖片來源

隨著大家對雲服務的越來越熟悉以及ML應用程序在市場上的愈來愈普及,使用者們也開始發問:“我設計的架構是在對的方向上嗎?”。本文參考2020 AWS re:invent大會中,關於ML專案架構最佳實踐的一場演講。從AWS well architect的框架下,學習用機器學習的視角來看:設計機器學習應用的架構時,所需要考量的幾個最佳實踐。內容將綜合講者的演講內容以及筆者過去的開發經驗。

演講介紹

2020年的AWS re:invent是全遠端的方式進行,從2020年11月30號到12月18號以及2021年1月12號到1月14號。今天的文章架構靈感是來自Mohsen Ansari所分享的Architectural best practices for machine learning applications。想看該演講的朋友可以到活動網站免費註冊,在議程的地方搜尋這一場演講。

演講資訊:
Session ID: ARC312
Level: 300
Speaker: Mohsen Ansari
Session Name: Architectural best practices for machine learning applications

摘要及個人想法

8步驟從資料、建模到產品化你的ML產品

    1. Data ingestion:數據提取。
    2. Data preparation:資料準備。
    3. Feature Engineering:特徵工程。
    4. Model training:模型訓練。
    5. Model monitoring/re-training:模型監測、重新訓練。
    6. Model Inference:推斷結果,根據手上有的證據、線索推論出的推斷結果。
    7. Model deployment:模型部署。
    8. Model evaluation & tuning:模型評估與調整。

如果你是資料科學家、資料工程師,可能對於這8個步驟再熟悉不過。假設今天公司的業務從現在的量級,往上增加10倍、100倍,在這些步驟上面有可能哪些部分會受影響?假設團隊要加新的人進來的話,你會怎麼確保團隊的分工呢?

假設你是在DevOps部門,這些步驟可能還有些不太熟悉,你可以先參考前一篇文章what’s MLOps?,了解一下MLOps跟一般軟體開發的DevOps不同處有哪些,然後回來這篇繼續想:今天你要跟資料部門一起負責MLOps的話,是否能夠把你熟悉的系統架構、安全性、可靠性等等,來跟機器學習的產品循環相呼應?

好,接下來然後我們一起來看看以下內容。

透過ML視角去看雲端服務架構設計

看過AWS well architect (暫譯:AWS雲端服務架構完善設計)的開發者可能已經對這五點架構完善支柱有印象,其包含:Cost Optimization、Operational Excellence、Reliability、Security、Performance Efficiency。當ML遇到這5點,所展開的討論點就會包含:

  • 1. ML+成本最佳化(Cost Optimization): 目前使用到的服務是否有真正幫助到團隊做資源的最佳化?是否使用適當的託管工具讓團隊降低擁有成本?例如在時間應用、人力配置、開支等等。是否先從資料及當中取出小量資料試驗之後再進行大規模的訓練?或是有其他可以更快、更方便驗證模型的方式?是否基於業務形態而選擇適當的服務模式?例如需要全天候機,還是只有在尖峰時刻才需要把服務開啟?在定義成本的時候是否只考量單一研究步驟,還是有把整個商業流程推上線的成本放進考量?以及不會因為業務進行而可能會有相對應的延展性、擴張性而超出預算等等。
  • 2. ML+卓越營運(Operational Excellence): 在ML的模型訓練、部署的過程當中,是否有足夠的自動化以及數據監控,讓整個流程能夠持續改善,進而幫助到公司的商業價值。讓跨部門團隊能一起溝通模型為市場帶來的影響,讓受到影響的各部門都能因為這個ML模型的部署而受益。版本控制與自動化的模型部署,讓版本的釋出及退回有更加穩健的環境。定義事情發生的相對應措施,讓模型營運能更有系統地被多人一起維護等等。
  • 3. ML+可靠性(Reliability): 可靠性著重於確保工作負載如預期一樣正確且一致地執行預期功能,因此訓練一次後,需確定模型在不同環境(開發、測試、產品)的執行狀況都相同。彈性工作負載,快速從故障恢復也是可靠性所在乎的點,在模型部署後,需測試是否能乘載客戶用量。以及故障、人為意外的復原規劃,可以如何在最短時間內回到確切版本等等。
  • 4. ML+安全性(Security): 安全性著重於保護資訊與系統。特別是在某些國家受到個資法的保護下,有誰能夠訪問、有誰能夠觀看數據集、能觀看哪些內容等等的權限管理,就變成很重要的課題。這些課題也需要跟了解GDPR、HIPAA的專業人士一起審核,制定開發以及問題舉報流程。除了需管理誰能夠訪問數據之外,也須考量防止數據外洩、確保數據集的完整性。從取得數據、訓練到模型部署,若是在團隊上有不同層級的分工,也須確保各開發人員的數據採訪權限、是否有權限取得其計算資源、是否有權限執行部署、修改部署、或是在部署至產品階段的人為行為介入都能受到管控。部署到線上的模型,也需要有安全把關,並不是讓任何使用者都能夠不經登入任何直接呼叫到這個服務端點。
  • 5. ML+效能效率(Performance Efficiency): 效能效率著重於有效率地利用 IT 和運算資源,讓其能夠發揮最大效能。舉例來說,在ML的模型運算當中,模型的架構與計算機器的選用及配置是否已優化。模型在提供服務時,是否在效能上有足夠好的表現?舉例來說:延遲是否在服務情境中佔了很重要的服務體驗、即時性對於商業的維護成本帶來的影響為何,以及模型是否在合理的延遲範圍內提供回應等等。持續性監看及關注模型發佈後的狀況,也能夠協助在系統的維運上保持穩定度跟彈性。

結語

透過以上5點,希望大家對於機器學習的架構最佳實踐有了更多的想法及靈感。也許每間公司的業務形態、以及ML在業務當中佔的比重都不同,但是透過這些要點,能夠提供data team、DevOps team、Product owner有更多的討論那就有發揮到期價值了。

放上幾個學習資源:

也包含我會更新的粉絲頁Telegram頻道
大家下次見!

註記:
改了數次的標題
– 機器學習應用的雲端服務架構最佳實踐
– 機器學習應用程序服務的架構最佳實踐
– 機器學習應用程序服務架構的最佳實踐
– 機器學習應用的架構最佳實踐
– 機器學習服務的架構最佳實踐
想要有一個標題機器人來幫我決定💪

摘要:what’s MLOps?

(圖片來源:youtube)

2021的第一則MLOps post,整理3點來自倫敦的Luke Marsden在2020年3月的MLOps.community 的分享。

  1. 組成MLOps的元素:
    – 可重現的:要能夠可以重現9個月前的模型,並且誤差落在一定範圍內。
    – 可問責的:從訓練模型到發佈上線都要能夠追溯到是誰做的。
    – 可非同步合作的:在事情做到某一個階段之後,其他人能夠過了一陣子再接起來繼續完成。
    – 可持續性的:能夠自動化部署且在部署之後能夠監測模型的狀況。
  2. ML所需要的開發跟一般的軟體開發有什麼不同?

(圖片來源:youtube)

一般的軟體開發,大部分是專注在程式碼、測試、部署、以及之後的活動監測。而機器學習相關的開發則是除了程式碼之外,還必須要專注在資料流(包含彙整資料、整理資料格式)、透過版本控制記錄每一次模型訓練的資料、參數跟評測指標(metrics)的結果,以及部署跟之後的活動監測。也因此這會讓一般的DevOps無法馬上跨越門檻來當MLOps。

3. 導入MLOps的典型障礙:
– Jupyter notebooks
– 資料版本控制、資料分享
– 追蹤參數跟評測指標(metrics)
– 使用本地/雲端開發的執行一致性

如果看到這些典型障礙但是腦中沒有畫面的話,記得找身邊的資料科學家聊聊,請對方跟你分享他的日常開發生活。

這場演講很適合對於MLOps還沒有太多概念的朋友觀看,影片說明的部分大約每3分鐘左右都會加上時間軸說明,讓觀眾在看影片的過程當中可以保持專注,知道這個時間主要想傳達的概念是什麼。[點這裡看影片]

如果對於聽英文演講沒有問題的話,可以直接點開連結觀看。如果需要中文字幕的朋友,可以先開啟cc字幕,接著在齒輪裡面的字幕選擇繁體中文為翻譯語言,這樣就可以了。

歡迎提出看法一起討論,祝大家學習愉快 🙂