Tag: data scientist

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字幕，接著在齒輪裡面的字幕選擇繁體中文為翻譯語言，這樣就可以了。

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