技術與實務

三個必須掌握的 MLOps 核心概念

三個必須掌握的 MLOps 核心概念

是否正在煩惱如何更有效地促進資料科學家、軟體工程師、和維運工程師之間的合作? 是否苦於找尋如何穩定地研發與交付機器學習模型服務? 是否正在找尋如何持續維持機器學習模型服務效能的方式? 如果曾經為以上的問題煩惱,或者是希望持續提升團隊交付機器學習服務的能力,那麼 MLOps 肯定是你不會錯過的議題。 機器學習模型並非是交付機器學習服務中 唯一 的工作,由上圖1,可以了解模型本身只不過佔據了實現模型服務的眾多任務中的一小部分而已。機器學習模型服務的開發,不僅僅涉及如何實現模型,還含括了軟體開發與後續維運的議題,因此相較於常見的軟體服務開發來說,複雜度更高也更容易產生技術債務的累積。MLOps 是希望能夠透過 DevOps 的優良實務作法來提升模型服務交付的水準,並且降低或免於技術債務的累積。DevOps 所提倡的持續整合與交付和溝通與協作,也讓習於沉浸在資料與模型實驗的資料科學家們有機會以全局的角度看待服務交付的議題,並且讓整個價值流上的其他人員可以更有效地與資料科學家們合作註2 三個核心概念 1. 版本控制不只侷限於程式碼 版本控制的基本目的是為變更建立可追蹤性,以便作為之後除錯與改善的基礎。 程式開發者透過 Git 之類的工具,為程式實作進行版本控制可能是相當直覺的作法,而這樣的作法,對於資料科學家或者是模型工程師來說,應該也不是太陌生的操作。透過對程式碼進行版本控制,可以妥善管理模型與資料處理的相關實作內容。但對於一個機器學習專案來說,只是管理程式碼實作則是遠遠不足的! :thinking: 試著想像一下機器學習專案可能會遭遇的場景! 首先,用來建立模型的資料會隨著時間的推移與相關的系統操作而持續發生變動。另外,在進行模型開發過程中,也會對資料進行處理與篩選,這些過程都會影響當下模型的實作與訓練結果(如精確率、召回率等)。為了能夠提供之後改善的基礎,以及提供模型建立的可再現性,環繞於模型建立的相關資訊都應該進行版本控制,當然也必須包含訓練完畢的模型本身。

繼續閱讀
為你的自動化基礎設施拉上保險系列之一

為你的自動化基礎設施拉上保險系列之一

作為基礎設施的編撰工具,Pulumi 額外提供了基於屬性測試 (Property testing) 概念的 Policy as Code 工具 (“CrossGuard”)。基於這個工具,專案團隊或者是組織可以為所有採用 Pulumi 所撰寫的基礎設施程式,建立獨立於所有 IaC 專案的普遍規則 (比方說資源區域、數量、網路設定、IAM 等),團隊亦可基於此再添加關於專案的額外限制。透過建立完成的可測試規則,開發者可以在本地端、持續整合流水線、以及在最後佈署前(已經產生基於各公雲或基礎設施服務的組態檔時)進行測試確認,避免需要透過人工檢閱比對,或者是已經佈署完畢後再進行確效,所產生的人力或資源的浪費。 本篇文章作為 Policy as Code 系列文章的起頭,會採用 Python 建立一個簡單的 Policy as Code 專案,為稍後建立基礎設施全面性的規則作暖身。 在開始之前 擁有一個 GCP 的帳號,更重要的是,它必須設定好如何付 $$ 安裝 Google Cloud SDK,並且確認已經設定好 application-default Python 為 3.

繼續閱讀
自動化建置靜態網站基礎設施之二

自動化建置靜態網站基礎設施之二

在自動化建置靜態網站基礎設施之一中,我們介紹了如何全面使用 Google 來打造靜態網站的基礎設施,但以一個單純作為靜態網站來說,起初的用戶量與使用情節必然是不太複雜,但全面使用 GCP 的解決方案也就代表了採用負載均衡與 CDN 等相關服務元件,而採用這些元件由於服務水準匹配的原因,也很難降低相關元件(e.g. 負載均衡)的等級,因此,即便流量再小,也必須支付一個月約莫 2x 美元的費用。因此,本文章將介紹利用 Cloudflare 來取代 GCP 的負載均衡與 CDN 相關服務,由於 Cloudflare 有提供免費級別的用量,這對於單純的初期靜態網站來說,應該十分夠用了!接下來,我們就來看看如何用 GCP + Cloudflare,並且基於 Pulumi 打造一個零元的靜態網站基礎設施吧! 在開始之前 擁有一個 GCP 的帳號,更重要的是,它必須設定好如何付 $$ 建立一個具有合適權限的服務帳號 安裝 Google Cloud SDK,並且確認已經設定好 application-default Python 為 3.

繼續閱讀
Lean Coffee

Lean Coffee

議程總是與會議內容不符? 會議冗長,重要的卻沒談到? 參加的人很多,意見卻少的可憐? 開到意識脫離? Lean Coffee 是由 Jim Benson 和 Jeremy Lightsmith 所發想,而發想後的最初實踐空間的確就在一間咖啡廳內!Lean Coffee 的議程安排是由參與者所共同決定,所以會議前,相關議題並不明確,但唯一明確的是聚集在一起的人,有共同的目標與興趣,也具備此目標下的相關討論背景知識。雖說議題是由會議進行過程決定,但議程的推進過程卻十足具有結構,並且能有效地針對提出的議題,產生結論與後續行動。 整個開會的基礎概念是基於敏捷、看板與 Lean ,並且以人為優先來考量整個會議的安排,民主式地抉擇討論,並且提高參與感和個人的貢獻,以便形塑真實的共識。 環境與工具 便於走動與張貼的環境,可以善用團隊常用的戰情室; 白報紙一張或白板一個; 建議人數 <= 10 人/組; 白板筆 x 三種顏色 ; 便利貼一包 x 兩種顏色; 點點貼紙 >= 30 點/組; 計時器; 安全可開放討論的氛圍。 流程 利用 3 ~ 5 分鐘的時間,讓參與者透過腦力激盪將感興趣的議題寫在便條紙上; 輪流到白板前,用一至兩句簡短的描述自己的主題; 將相同或者相似的主題進行整合; 一人三點進行議題投票; 將看板 (e.

繼續閱讀