科技應用

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

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

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

繼續閱讀
全面轉向 CentOS Stream,憤怒了嗎?

全面轉向 CentOS Stream,憤怒了嗎?

去年底公佈 CentOS Stream 來替代 CentOS1,也就是說原先的 CentOS 的發佈版本終於迎來它的終焉之時。 簡言之,CentOS 原先作為 RHEL 釋出後的開源版本,如今將重新定位在 Fedora 與 RHEL 釋出之間,成為 RHEL 釋出前的版本,也因為這樣的位置重置,讓原先 CentOS 的用戶立馬就吵翻了天。 不開心! 為何? 先不論是否背叛了開源社群,或者是因為誰而促使這樣的狀況發生。造成這樣的不適感,筆者認為最大的原因有二: 已如理所當然的長期免費資源,如今不再這樣可口。 除 CentOS 6 與 CentOS 7 仍按照原先生命週期外,CentOS 8 並不會按照原先預期的約定,直接改止於 2021 年底。這讓已經投入 CentOS 8 轉換且以此展開產品發展計劃的個人或企業,直接面對這突如其來的變化,反應可想而知不會太好。 關於第二點,雖說按目前軟體發展的模式,尤其紅帽這類大型公司,在持續測試整合上的能力已經相當成熟,不管是相容性與主次版本的相關測試案例,應該都能提供對應的保障,但是一聽到是先於企業版本的發展版本時,誰又願意進一步嘗試或者是相信呢?CentOS Stream 並非突然在 2020 拔地而出,而是在 2019 年時便已經問世,開源使用者固然有關注的義務,然而突如其然的轉換聲明,使用者溝通上顯然不足。不過說到此處,基於第一點,說實在很難找到兩全的方法。或許紅帽能為一些先於RHEL釋出的新功能,提供一些開關,讓使用者對於過新的變化至少有個簡便濾除能力。

繼續閱讀
我可能不會需要微服務?!

我可能不會需要微服務?!

微服務所帶來的彈性,以及它與CI/CD,與敏捷等所帶來的效率,讓你心動不已嗎? 微服務和容器、CI/CD、Kubernetes、敏捷等概念有著互相增強彼此所帶來效益的能力。這幾年伴隨著各類技術的發展,台灣自然也沒少了這股熱潮,而這樣的趨勢仍然還在沸騰中。身為一個技術工作者,或許早已看不慣公司裡陳年的大系統,正想一展長才,響應潮流,而管理者或許因為數位轉型與創新的壓力,開始希望從這熱潮中,找尋成功的方程式。 微服務並不是去年才出來的概念,而自家的系統也不是今天才開始運行。先想想「值得嗎?」 微服務是首要之務嗎? 重構系統將其微服務化是一件極大的工程。相信大家對於微服務所帶來的好處朗朗上口,然而分散式系統的管理複雜度和資源的額外開支,在朗朗上口之餘,也必須認真對待。另外,在過程中可能帶來的業務穩定性衝擊與業務發展資源不足的問題。更重要的是,它所帶來的效益不見得如你所想像的!這幾年穿梭在各類系統架構中,常常必須苦惱不已地進行抉擇,分享幾個思考點,或許能夠在大家踏上旅程前,先想想是否已經可以無悔走上重構: 原先系統的狀態 向原先系統磨刀霍霍之前,先想想「目前原先系統修改的需求高,修改頻繁的發生嗎?」、「大多數新的實作是否仍然增加在原先系統,還是其他服務裡?」如果,原先系統已經處在維護狀態,或者是新的實作大都與原先系統無關,那麼或許更重要的是在流程或其他面向上的優化。 系統已經可預期或已出現容量瓶頸 原先的設計已經限制住系統本身處理當前或者是未來的使用量。如果時常進行尖峰調度,而且調度應變困難,抑或者調度也很難再處理使用量的增長。那麼首要之務,找出瓶頸的服務接口與對應功能類別。作為之後,首要改善之所。 工程資源 任何的改善變更都需要人。如果工程人員已經吃緊,而又另外增加重構改善等任務,那麼下場很可能是不減反增的技術債、業務進展發生開發瓶頸、與惡化的勞動條件。人永遠不是資源,而是企業成長的夥伴!持續性地超支所衍生的代價,恐怕會降低重構的成功機率,以及削減重構所帶來的效益。 原始設計是否良善 單體式(Monolith)架構其實也沒什麼罪惡。如果原始設計已經維持著良好結構,也能正確體現低耦合與高凝聚等特性。那麼它的後續維護其實不見得比較難。難以維護往往是因為求快的實作,導致軟體內部設計耦合度過高,牽一髮動全身,發生問題還無處找之類的狀況。因此,不管在任何時候都好好設計軟體,會讓自己後顧之憂少許多。一個隨便實作的微服務,其實也沒比良善實作單體服務高明到哪?更甚而是不僅要面對可怕的設計外,還要負擔分散式管理的複雜,恐怕問題只是雪上加霜。 如果面對一個既有系統時,已經發生容量問題,設計又差,時常又要新增功能,往往耗損在應對,而非新發展,那麼或許重構是幾乎是你首選了,盤點一下人力狀況和工作配比,為自己重構之路爭取一些支援,反而是你現在該煩惱的,而非是要重構或不重構了。 然而,世事總是讓人陷入兩難,大多數情況都是有點糟,但不是太糟,那麼?

繼續閱讀