記2021

新年快樂 🙂 藉由回顧、感謝、期許三部分跟大家分享過去一年的生活,也一起展望這個代表勇氣、活力的虎年吧!

Winter View from the Front Window

回顧

於是,這一篇文章拖延到農曆新年期間發佈。倒也是個好時機來回顧以及思考未來這一年的方向。住台灣的時候,我們過兩次年,一次是國曆年,一次是農曆年。搬到了歐洲,這樣的習慣其實沒有改變,每年的國曆新年與農曆新年期間,同時也是企業還在重新給目標的時候,心情大概是一種知道要出發,但也沒真的認真出發的心態。總是要農曆年過了,這些思緒才變得沉著下來。

假若要出一張充滿資料點的總結,過去的我總是可以輕易地說在這期間,寫了多少篇文字、講了多少研討會、去過多少地方等等。真心想記錄的,是那些挑起我心情起伏的事件。像是:
(1) 最德國的是:搬到一間在柏林郊區的木屋裡,取得永居卡。
(2) 最震撼的是:到波蘭參觀了兩個世界遺產:集中營與鹽礦。
(3) 最寫作:出版第二本技術的英文書30篇鐵人賽文章
(4) 最少女:跟前同事定期相約去吃早午餐。
(5) 最悲傷:失去姑丈。
(6) 最感動:在瑞士跟高中同學聚會。
(7) 最愛吃:去vegas出差的時候連吃兩餐鼎泰豐。
(8) 最一探究竟:成為公司年度大會(re:Invent)新產品發佈的一員。
(9) 最傻眼:在埃及被飯店服務生嗆德文很差、被潛水教練嗆你有事嗎。
(10) 最寧靜:晚上在埃及的飯店聽著海的聲音。

仔細看看,這一年其實也完成了好多在人生目標上想完成的事,好多時候都覺得真的超好玩、超好笑、超幸運,人生在好多面向都展開了更寬廣的一面。大概就是在玩遊戲的過程不知道為什麼就開了一張新的地圖的概念。

在公司年度大會(re:Invent)協助新產品發佈的一員也是如此。在跟主管聊天的時候,她詢問的當下我也是一口答應。體驗就像一個很愛看迪士尼電影的粉絲,總是看很多遍然後會想知道所有細節的那種。今年則是成為製作電影的那個角色,有機會站在另一端去看這個世界。不僅僅是在過程當中滿足以前想知道的好奇心,也跟好幾個資深的同事跨國合作。到Vegas出差的時候和同事聚餐,其中一位同事感嘆地說“在這裡的人都不簡單”,才有意識到原來當初的一個衝動,可以帶著我到這麼遠,跟這些群星一起合作 🙂

如果回頭看年初的自己,可能沒有想過會是這樣的一年。而日子還是沒有改變太多。不知道是自己長大了,抑或是過去的自己把夢想想得太大了。

感謝

除了工作上、旅行上的夢想。這一年與自己身邊的人,有了更深刻的相處與感觸。

隨著在柏林生活第三年,交友圈的輪廓也漸漸清晰,常常能體會出外靠朋友的美好。柏林是一個人口流動很高的城市,數一數可能誰要換到其他城市工作、可能誰的簽證到期要回台灣、可能誰的求學計畫取消了等等。在遠端生活的期間,能夠累積下來的朋友圈,真的讓人倍感溫馨。感謝那些飯局、窩在朋友家客廳的時光、線上聊天的時光,讓疫情間的生活能夠有些調劑。

最近剛看完松浦彌太郎的“寫給凌晨五點的你”。這是一本集結松浦彌太郎在他的專欄裡的好幾篇文章,這些文章在晚上八點到凌晨五點,讓他的讀者可以在深夜時段閱讀。談論生活、也談論人際關係。裡面有一章節寫道:好好說再見,即使再也不見。這裡在說的是把握每一次說再見的機會,把它當成是表達感激、好好跟對方道謝的機會。

看到這一篇的時候,一瞬間許多回憶湧上,覺得自己一直是一個不擅長說再見的人,也很不擅長表達感謝的一個人。不管是那些一起生活、工作、上學的朋友、前輩,或是那些很照顧我的親戚長輩們。現在想想,其實還可以更好的表達心裡的感謝跟珍惜。

期許

然而,前一篇記2020的關鍵字:#遠距面試與工作 #寫作 #冥想 也是輕鬆套到2021。想必,也會繼續延伸到2022年底吧。

另一個2022年的關鍵字:#賦能。

期許這一年的自己仍然可以透過各種管道,協助在德國工作的台灣人在資料科學職涯遇到困難的人,能夠找到適合他們的資源。OKR的O已經有了,接下來就是展列出K跟R了 !!

好的,這就是這一次的回顧。歡迎大家告訴我:去年跟今年的版本你比較喜歡哪一種?我可能會參考,也可能不會,就先這樣囉 🙂

2021 Memory Collections

一位女子在科技產業的7年之癢。

*圖為2019年在印度舉辦的Data Platform Summit的所有女性講者合影。

2021年國際婦女節就是今天,柏林人也因此賺到一天假期。

這個節日訂定在每年的3月8日,象徵著世界各地婦女為改善生活而進行的歷史性旅程。雖然已經取得了很多成就,但旅程很長,還有許多議題是各地的女生仍然在努力當中的。

舉例像是工作環境當中的性別不平等、同工不同酬。像是生活中的,獲得知識的權益、婚後或者生小孩之後的身份轉換等等。這些題目不僅是台灣,世界各地的婦權團體也都還在努力爭取中。

從2014年夏天開始工作,不知不覺今年也要邁入7年之癢了。到底to tech or not to tech。今天也趁這個假日,寫下一些從自己一個在科技業工作的女生視角,跟大家分享一些自己的經驗,也希望可以帶給一些還在十字路口觀望的小女生一些想法。

背景

Q1. 你現在的工作是什麼呢?是什麼原因讓你選擇現在這一份工作?

專注於ML專長的Solution Architect。這個角色可能對許多人來說是相對陌生的。那先從之前的經驗開始談起好了。

從數學與資訊的系所畢業之後,擔任了網站後端工程師、資料科學相關的顧問與資料科學家。每一個階段都是屬於程式開發的職位,在這大約4年多的時間,換了3份工作,大概也是屬於大家所說的定性不高的年輕人。

在這段時間,比較專注在技術開發上的學習,這段時間的學習也讓自己在後續的位置可以有穩健的基底向上發展。

找到海外的工作之後,就搬來柏林擔任資料科學家,升遷到senior的位置之後,在可見的未來觀察到,在當時的公司內的發展與學習也是很有限的。

後來開始跟不同的獵人頭與身邊的connection 談過之後,也很順利的拿到一些像是(1)農業科技新創DS部門開發主管、(2)法務顧問公司的AI事業商業跟技術開發負責人等等的offer,也有機會拿到(3)某間在我心中是神之領域的研究中心開發人員面試機會。

跟這些公司面試的過程當中,就是很有趣的歷程,學習到很多不同產業的知識,也感受到平常就要好好經營人脈的重要性,每一扇門後面都是一個全新的世界。如果他們是單獨出現,都是很吸引人的機會跟題目。但是當這些全部放在一起的時候,考驗的就是對自己夠不夠瞭解,也考驗“自己眼中的好”與“別人眼中的好”的權衡。

在過去的工作內容大部分是做in house的開發人員,所待的公司大部分都是新創與中型公司,面對的產業跟可能會遇到的問題相對有限。

目前手上的這一份工作。在相對大型的跨國企業當中,替客戶提供ML專案的架構規劃。同時也必須作公開演講與技術內容產出。這個新角色除了要面對客戶之外,魔法師等級的同事和會遇見的客戶案例也是很吸引人的點。

Solution Architect這個工作大部分是存在公有雲廠商的公司,例如Google/Microsoft/Amazon、其上下游的夥伴公司,像是Accenture/Avanade,以及有使用雲作為開發環境的公司的比較會有這樣的職位。要討論這個位置的細節應該可以之後重新寫一篇了。

在選擇這個機會的當下,也有要承擔的風險:像是技術stack與過去的經驗有些許的不同(從Azure雲換到AWS雲),需要重新學習。在COVID期間換工作,當時柏林有相當多公司因為COVID裁員、倒閉、採取短工時,且當時疫苗的進度也尚未明朗,不知道整體的市場是不是又會因為疫情有所波動,進而受到影響。另外,也必須遠端onboard,透過遠端工作跟同事學習工作上需要學習的技能,現在回頭看真的是多重風險的一個選擇。

Image by Free-Photos from Pixabay

Q2. 當初是如何對程式開發感興趣的?

寫程式,和寫文章、畫畫ㄧ樣,都是屬於能夠把腦中的想法具象化的方式。對我來說這是很具有能量的一件事情,透過寫程式可以把想做的自動化,就可以少掉很多費力的事。這些事情可以不一定是自己想完成的事情,開發出來的產品也幫助很多不同族群的人,有機會接觸到原本沒有機會認識的世界。

喜歡技術與程式開發這件事情的想法很單純。後來隨著時間過去,從申請學校的時候會看見女生的同儕是相對少的,開始工作之後也發現女生的工程師在職場是相對稀有的。這時候才發現到,原來這個產業的性別比例是這樣。

Q3. 在國外所看見的資訊系所/資訊業的性別差異狀況是如何?

2012年在瑞典UU交換的時候,覺得系上修課同學的男女比例跟台灣比是相對平均一些的。一部分是來自於各系所跨系選課是很常見的事情,許多同學來資訊所上課,也是想要把寫程式的這個能力應用到他們各自的主修上。

2018年後到德國柏林工作,也參與過不少以女性為主的社群活動。來自各國的女生,個性上會相對願意直接去陳述表達個人的經驗感受,也會彼此分享在遇到什麼樣的狀況下可以有什麼樣的行動。

許多社群討論會讓大家有分享經驗的橋段,接著很容易不小心對話狀態就會停留在”我也遇到xxx”的取暖階段。如果希望生活發生變化,除了取暖之餘,大家也可以嘗試盡量讓團體的對話可以繼續發展到”what’s next”,”what can we do next time”等等的主題,讓參與的人可以帶著行動出去這個活動的門。

Q4. 曾經在工作場所會因為身為女生而面臨的挑戰?

如果都只有講負面的,好像不太平衡。我個人是蠻享受去研討會的時候,女廁排隊人數幾乎都是小於3人,進去廁所、整理頭髮之後出來,對面男廁的隊伍都還是好長一列(笑)

談到挑戰的話,許多人會談到面試的時候會被問到不相干的問題。我自己則觀察到,相對於同樣職稱的男同事,我會需要花更多的力氣去贏得其他人的信任的狀況。

所謂挑戰,其實只是表達在你想完成的事情的過程當中,有些事情不如你所預期了。可能是因為是女生而遭受不公平的言論,也可能是要上市一個產品,但市場發展不如預期。有太多因素會使得事情發展與你想的不同。

很多時候女孩們都會不小心走心,然後就往心裡去,陷入一個情緒的漩渦。我會建議在情緒過後,去找幾個能夠信任的外部人士談論這件事情。

在業界更有經驗的前輩,會提供他們的視角,告訴你這件事情除了x之外,可以完成的方式還有y跟z。以及這件事情你可控跟不可控的因素有哪些。讓自己在難過之餘,知道自己還有哪些資源可以運用,知道哪些事情是在自己努力之餘可以有所變化,有些則是可以let it go。

雖然這題在談挑戰,但我想說,女孩們比起男生,也可以更沒有社會包袱的去談論自己的沮喪與難過。不要錯失了這個優勢 🙂

Image by Free-Photos from Pixabay

Q5. 在學術或工作生涯中,有沒有任何導師幫助過妳的成長?

有,在開始工作之後,受到社群很多很多很多的幫助。

我覺得身為女生的科技業從業人員,搬到國外生活。不管是台灣,或者當地的朋友當中,很難會有一個前輩是真的剛好都體驗過現在遇到的事情。

舉例來說,第一次在海外講課一週的時候,需要在很短的時間內調整課程內容,讓不同程度的學生都能夠從課程當中有所學習。

可能有一些朋友是企業講師,在備課很有經驗,可以詢問怎麼調整課程內容給不同程度的學生。可能也有一些朋友是跟你在同個的時區,可以在你難過的時候接起電話,聽你說這件事情讓你多沮喪,一起討論可能有的文化差異點,然後再提供旁觀者的意見與鼓勵。

不要期待有一個人從上帝視角理解一切,比你還懂發生了什麼事情,一次就解決這個煩惱。而是自己要學會去拆分這些問題,可能有的問題會有哪些,嘗試從不同層面去思考、克服這個問題。

最近的一次換工作,我也詢問了好幾個前輩的經驗,包含在德國工作的、不在德國工作的。台灣的朋友、德國這邊的社群朋友。工作形態類似,但是不同職稱的。同職稱不同公司的。而這些人當中,大概12個當中只有1個是女生。(哭)

在技術圈遇到的困難,很多時候就是必須接受,要找到另一個女生的mentor是有一定的難度,但並不表示你就要放棄眼前的這個挑戰。切分問題,展開行動。

Q6. 為什麼想談WIT(women in tech)?

這個問題,除了身邊的男性工程師問過我之外,我自己也問過自己。到底為什麼要談這件事,因為在我自己的擔任工程師的路上,就是直接開始走,好像沒有想過為什麼要當工程師。

直到我從一群男生的工程師當中找到答案。

幾個不同的朋友圈裡面的工程師都會去討論一件事情,工程師這份工作到底可以做到幾歲、工程師的中年職涯發展。接下來就會開啟一串中年危機討論串。這些討論中反映的是什麼?這些工程師,認識了太少50, 60歲以上還待在技術圈的前輩,所以也開始懷疑、開始焦慮。覺得好像沒看到有人這樣做,就覺得自己也不知道該怎麼前進了。

同樣的,世界上也有一群小女生,可能高中,可能大學,也可能是更小的年紀。她們在生活圈、報章媒體當中沒有看見很多女生在科技圈,在沒有role model的情況下,會開始懷疑、開始焦慮,不知道應不應該做這個選擇。

也因此,談論women in tech的對話,能夠讓這些事情有更多的討論、對話以及分享。讓這些小女生可以因為這些談論而更有勇氣繼續追求自己想做的事情。

並不是說這一場談論發生,明天工程師男女比就會1:1。這些對話也可以讓大家更有意識地去思考,當自己身在有資源、有話語權的一方的同時,是否也同樣地去照顧到了身邊的其他人,確保這些人的聲音被聽見、權益被維護。

這些其他人可以是,不同性別、文化、飲食習慣、個性、宗教,甚至來自不同地方(天龍國/不天龍國?)。

Image by Karolina Grabowska from Pixabay

Q7. 給想要從事技術職業的女性什麼建議/技巧?

在技術的崗位上,除了前面已經提過的,找同業前輩諮詢經驗,切分問題,展開行動之外。我覺得也必須要:

(1)發出聲量,不害怕困難的對談:
在會議舉行前,提前準備內容,透過準備會議讓自己在會議中發言的自信心提升。也會讓與會者與會議主持者知道你對這件事情的在乎,以及工作上的專業。

可以不用在每一場會議當中都要發言與提問,但至少在自己覺得重要的議題,可以提出自己的見解。不用把對方的反問和拒絕視為針對個人,嘗試理解對方立場,練習不同的表達方式去陳述心裡的想法。

和自己的主管的會議當中,也盡量去詢問工作的反饋,如果有想要在公司裡面升遷也主動去溝通。不要覺得自己是一顆等待別人發現的星星,大部分的狀況是老闆忙到不知道你是一顆會發光的星星。這些對話也不可能由其他同事幫你發起。所以,這些與績效、升遷等等的話題,雖然困難,可是還是要練習起來!

(2)讓專業說話:

前面在Q4談到,女生會比男生同事,常會遇到需要做更多的事情去爭取信任。在這過程當中,如果對方只是故意拒絕你提出的意見,或是不相信你在專業領域上的經驗。

可以在開口之前先準備對方可能會問的數據點,實際執行時會遇到的困難點。而對方拒絕你的請求時,也請對方具體回應實際拒絕的原因。而不是讓對話停留在拒絕,然後就結束了這場對話。

這些拒絕背後可能是時間或是其他資源的不足,或是這個方案還不是目前的優先順序。在自己可付出的範圍內,也可以先幫對方多做一些,讓對方可以用較小的成本去幫你完成這些事情。

許多問題的背後,其實大部分都不是技術問題。

在準備這些資料點,以及先幫對方多做一些的時候(技術、文件都可能)。其實是建立在技術掌握能力以及商業敏銳度上。

當你可以在自己的位置上做得很好,同時又能夠站在更高的立場去看當下要溝通的事情,對方常常會因為你的專業而給予你更多的信任,之後也會願意繼續與你合作。

結尾

雖然這些只是我個人的經驗,並不代表全~世界的女生都是這樣子思考。但還是希望可以帶給正在徬徨的少女們一些幫助。各位women跟women的朋友們,感謝大家看到這邊。不知道身邊的開發者們有沒有類似的經驗想提出來分享呢?

歡迎留言,或者用任何方式告訴我你的想法囉 🙂

3/8婦女節快樂,大家下次見。

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頻道

下次見:)

讀:上流兒童

讀:上流兒童

(圖片來源

前情提要。

當初買”上流兒童”的時候,同時也買了”斜槓青年”、”我輩中人“、”下流老人“。在看書的時候,我自己也非常喜歡那些呈現當下社會狀態的作品。創作本身也反映出了當下社會的價值觀、作者居住地的文化等等。在閱讀這些社會觀察的作品同時,我也在想,現在這一代的社會正在被什麼樣的價值觀影響。我們會以什麼樣的方式邁向下一個10年、20年。後來看到這篇文章(現場|透視「上流兒童」,進行「父母」的社會學想像)也用了這四本來做介紹,覺得是相當有趣的巧合 🙂

關於本書。

書中從主角陳勻嫻,一個媽媽的口吻與視角來陳述大部分的場景。她從小家境普通,長大逐漸欣羨上流社會的豪奢生活。婚後與丈夫楊定國一同築起的家庭也屬小康,從小孩得到機會讓家裡的小孩就讀貴族私立學校開始,開啟了她有機會踏入這個私立學校的媽媽交友圈,也讓她的價值觀改變了不少。隨著時間軸的發展,主角與她的小孩與她的先生也被捲入了從前沒有想過的風暴當中。

個人想法。

後來看完這本書的時候,覺得書名跟內容有點不符期待。例如”斜槓青年”、”我輩中人“、”下流老人“,都是在陳述其人生階段會遇到的故事,而”上流兒童”這本書反而比較像是在陳述母親在兒子進入上流學校後的生活體驗,而不是從兒童的視角出去看這個故事。

當中印象深刻的部分,大概是看這本書的過程,那種強烈的壓迫感讓人忍不住在看了一個段落之後,因為覺得當天無法再看更多內容,就放下書去休息。這些壓迫感一部分來自故事的進展,快到有點不太真實,許多書中主角的決定並沒有太多的陳述就執行了,於是讀者馬上要承受這個選擇所帶來的後果。也可能是作者想要呈現一種主角在做決定的過程,其實也沒考量太多的一種氛圍。另一部分壓迫感則是來自於社會對於一個母親的期待,以及書中的主角對於這些期待的負面想法,所營造出來的低氣壓。

這本書談論到的幾個社會議題:(1)父母對教育資源的焦慮感、(2)社會上對於母親的角色定位、(3)媽媽在小孩成長過程給予的自我投射。

(1)父母對教育資源的焦慮感

家庭環境的確會造成不同程度對於健康、教育等等方面的影響。也因此許多家長花了很多努力上小孩去上私立或者貴族學校。這也是近幾年教育改革一直在談論的問題。根據研究指出社會階級對於教育資源的影響程度的問題也包含:
– 高社會階層的人比低社會階層的人受教育程度更高。
– 高社會階層的人往往受過更好的教育,收入較高,因此他們也更有能力為子女提供教育優勢。
– 教育不平等是導致世代相傳的階級鴻溝永久化的因素之一。

這樣的煩惱也不僅僅是發生在台灣,身邊的印度同事也談論到,他和葡萄牙籍的太太也在溝通是否應該把小孩送去當地托兒所(德國),還是國際托兒所。即便這兩者選擇的金錢成本在德國並沒有差距非常大,但他仍然考慮到小孩與其原生家庭文化的延續,也考慮到小孩上小學之後和德國學生的相處融洽程度。

這樣的焦慮感來自父母自己給自己的期許,覺得應該要給小孩最好的。也可能是社會給的期許,例如,每個國家的家人、朋友都覺得你應該要把小孩養成靠近自己國家文化的那一方。但是其實也都沒有最佳的解答。

(2)社會上對於母親的角色定位

除了這本<<上流兒童>>之外,作者在之前也寫了<<你的孩子不是你的孩子>>。這兩本的故事陳述,母親的角色都佔了蠻大的篇幅。

在台灣社會裡面,談到養兒育女的許多課題,第一件事情都是去問母親有沒有按照建議好好做,而許多父親的角色則是偏向家裡的經濟支柱,社會則不會把養育小孩的這個話題拿去問父親。假設父親不曉得孩子生活的細節,大部分的人並不會給予責備。但如果是母親不知道細節,則常常被責難。這樣的文化造就了”成為母親”與”罪惡感”的連結:彷彿永遠都做不夠一樣

日劇媽咪們的心機中提到,職業媽媽之間彼此也有鄙視鏈。例如家境好的會鄙視家境不好的,家境好先生或其家庭又有權力的會鄙視家境好先生其家庭沒有權力的,家境好先生或其家庭又有權力的心裡其實又很羨慕那種事業其實超強,能有自己事業一片天的媽媽。意外的是,大家會去批評一般職業媽媽晚下班沒有陪小孩,但是卻不會去批評那位事業強的職業媽媽。社會上的雙重標準其實也存在媽媽群組之間。

在台灣電影日常對話裡,可以看到一個同志媽媽,為了社會的眼光去跟一個男生結婚、生小孩,卻沒有意願照顧小孩。因此小孩在長大的過程當中是對家庭很憤怒的,直到長大後這個小孩成為一個導演,去跟她的媽媽(那個遲到的母親)去談開這段親子關係。

(圖片來源)

這些不同的母親與小孩的關係,其實應該更廣泛地被看見與討論,所謂家庭是否一定需要父親母親、是否小孩的成就一定是要來自成績、當親子的關係不健康的時候有哪些社會資源可以協助改善等等。這些問題都太少被討論。以至於當社會對於家庭與教育的價值在同一框架下的時候,父親、母親、小孩、家庭這些名詞背後的意涵就變得很狹隘。

(3)媽媽在小孩成長過程給予的自我投射

因為小孩在貴族學校上課的成績不錯,因此陳勻嫻(主角)也會向小孩提及他的行為會影響到整個家庭的狀況,希望他好好表現。即是很典型的母憑子貴。前面已提到父母對於小孩的教育資源都有焦慮感,但是在書中感受到楊定國(主角的先生)對小孩子的教育以及生活狀況相較來說沒有這麼大的情緒投入。對於小孩的成績也相較不在意。

母憑子貴這樣的劇情大家可能從宮廷劇中就已經是耳熟能詳,當一個媽媽的價值是透過孩子的成就而彰顯,便失去了她在個人生活上自我實現的能力。有些人其實樂於這樣的狀況,有些人則是會因為這樣的投射,而失去了自我。對小孩的成就過度期待的狀況,就會是很不健康的親子關係。

看到這樣的狀況時,其實是讓人感到傷心的一件事情。這反映出來的是主角在社會上是沒有情緒支持,自信心也是過度低落的。不管是主角夫妻之間的溝通、親子之間的溝通、或是其他社會眼光等等的原因導致如此。

結語

談到這幾點,大家可能已經能感受到這真的是一本會讓人情緒陷入黑色旋渦的一本書。雖然過去只看過你的孩子的影集,還沒看過小說本身。但這本書跟你的孩子影集一般,讓人心情都不是很好。可能看完之後再過一陣子,會比較能夠再回頭思考裡面的內容。

最後附上幾個連結,有時間可以看看:
誰是上流兒童?專訪吳曉樂:我的幸福,長的跟別人不太一樣
巷仔口社會學:當幼兒發展成為母親的風險事業
龍應台:藉愛勒索,是勒索,不是愛

以及來自美國與英國,對於社會階級與教育資源影響的研究報導:
Yes, the Rich Are Different
The Guardian: ‘Working-class children get less of everything in education – including respect’

今天就寫到這邊囉 🙂

職場上的無意識偏見

Unconscious Bias @ Work, Diversity & Inclusion 

在歐洲工作,Bias、Diversity 以及 Inclusion 常常是被拿來討論的題目,今天跟大家分享一個6分鐘的短影片,談談在生活當中每個人都可能無意識對身邊的人說的話,像是打招呼、談論今天的穿著、討論工作的分配等等。然而這些話的背後,可能包含沒有意識到的偏見。

無意識的偏見(或隱性偏見)是人們無意識地歸因於另一個人或一群人的潛在態度和刻板印象,這些態度和刻板印象影響他們對一個人或一群人的理解和互動方式。

這些偏見也不一定要是跨國家、跨性別的合作才可能發生,即便是在同一個國家的工作文化內也可能會因為這樣不禮貌的溝通,可能引發一些工作上的不愉快。花一些時間想一想,自己在生活當中是否也會把一些自己的偏見加諸在別人身上。

如果看完影片還有時間的話,也歡迎看看這一篇<<12 UNCONSCIOUS BIAS EXAMPLES AND HOW TO AVOID THEM IN THE WORKPLACE>> https://builtin.com/diversity-inclusion/unconscious-bias-examples

下次見 🙂

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

(圖片來源

隨著大家對雲服務的越來越熟悉以及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字幕,接著在齒輪裡面的字幕選擇繁體中文為翻譯語言,這樣就可以了。

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

記2020

記2020

(2021第一場雪, 柏林)

3秒版本:2020 宅力再度提升。
5秒版本:#遠距面試與工作 #寫作 #冥想
3500字版本:

一年前的這個時候,大家期盼著2020這個年度,光是附誦幾次就覺得好像魔法般會帶來好運。不知道為什麼當初心裡覺得2020年是比2000年更充滿力量的一年。現在回頭看,大概就是寫好的wish list被揉成一團,然後在你面前被燒毀,灰燼也被丟到不知道哪裡去的遠方。一切像是在嘲笑人類的渺小,像是在說怎麼這麼天真。

2020的最後一天,柏林依舊實施著lock down,酒精販售到下午兩點,嚴格禁止大家聚會及施放煙火。我跟Sam在客廳桌子拼著買來的樂高玩具,窗外從11點就開始有零星的煙火施放著,顯然大家也是沒有在管柏林政府的公告。臉書上的柏林社團,放著好幾張警察在街口值班的照片。外面的天氣大概2度,為了管制大家在跨年夜的活動,這些員警必須放下與家人相處的時間,在寒冷的夜巡邏。

擔任柏林的警察在平日就已經是一件不容易的事,每個禮拜都有不同主題的遊行,總是需要大量人力在場注意安全以及維護秩序。城市的運輸量也很可觀,從歐洲各個城市經由鐵路、航空、自駕來到這裡的旅客,背景不同,來到城市的目的也不相同。柏林的大麻也是游移在邊緣,某些地鐵站也是許多柏林人心照不選的交易點。走過亞歷山大廣場也時常看到配槍的員警在巡邏。除了城市人口組成相對其他城市年輕,所帶來的瘋狂與躁動,也包含柏林是當前德國的首都。因此,柏林的警察是一個能相對輕鬆意識到的存在。是好,也不太好。

||如果Covid在台灣也爆發了,現在在街上加班巡邏的,就會是在台灣當警察的表弟跟國小跟高中同學了。

我希望不。

住在歐洲,大家時常把文化衝擊(culture shock)放在嘴邊,大家一般提到的大概是飲食差異、語言意境的差異。而在COVID期間,無法忽視的文化衝擊則是”自由主義“在生命當中的優先順序。當2020年1月從台灣回來,我跟Sam就持續的關注COVID的新聞,當歐洲的新聞都還只是把這個歸類到流感的疾病的時候,家裡已經有存放了一些口罩跟消毒用品,相信其他旅歐的亞洲人也是如此。大家心裡面的陰影,是來自過去SARS的經驗,大家都寧可自己過分準備了。

自由意志主義(Libertarianism):主張把人的政治自由及自主權最大化,並強調選擇自由、自由結社、個人判斷的重要性。儘管大多自由意志主義者會對政治權威及國家公權力持懷疑態度,但他們對於該反對哪些既有經濟及政治制度存有內部分歧。各個自由意志主義學派對於公權力及私權力的合法職能存有不同看法,不過他們往往會要求限制或廢除具有強制性的社會制度。(引用wiki: https://zh.wikipedia.org/wiki/自由意志主義 )

自由意志在歐洲這個文化體當中,在這次的防疫期間更是發揮到極致。找到機會便上街集會,要求政府不要再要求大家戴口罩,要求政府不要再限制大家集會。一方面心裡覺得這些人怎麼只顧著自己的自由,一方面也是必須認清,自由意志的追求不也是大家來到歐洲一部分的原因嗎?一件事情的正與反,是無法彼此割捨的。

寫到這裡,還沒開始寫起去年習得了什麼新的生活習慣。腦子裡的記憶,的確跟2020一樣混亂,需要倒出來好好整理。

# 遠端面試與工作

遠端協作、遠端溝通對於我來說並不是一個陌生的名詞,在2020之前,不乏與其他人合作專案、線上開會的經驗。從3月底到12月之間,這段待在家的日子,則是以更深刻的方式體會了遠端合作。包含歷經了遠端面試、線上的onboard、以及與商業思維學院的小組跨時區的密切協作。

由於這一段不小心寫了2000多字,於是我就重構出去了這一篇:
(點圖片另開分頁閱讀)

# 寫作

另一項在這一年無心插柳的技能大概就是寫作了。從來沒有想過會把寫作放在年度總結裡面,但是在寫這篇文章的時候,把手上的手記、鐵人賽文章、近期寫的第二本書稿加起來,竟然也有11萬多字。分佈大概是:手記2萬字,中文夾雜;鐵人賽8萬多字,中文;書稿1萬字,英文。覺得還是蠻驚人的里程碑!!

  • 重點:先寫下來再說

去年買了一堆寫作的書,其中一本”welcome to the writer’s life”,裡面第一章寫說開始寫,不管你現在想寫的是什麼。後來我就把那本書放回去書櫃了。

2020的手記是在柏林誠品*買的一本自然花草風格的本子,大概是可以把自己行事曆寫上去的那種,原本的目的是要每天寫個30字當日感想。但我沒有很好的使用習慣,使得每次打開手記都已經是週六或週日了。甚至有一次打開,跟上一次的書寫時間已經間隔了三個月。

開始寫。就是這一句讓我每一次打開本子就直接開始寫,捨棄責備自己為什麼忘記寫的心態。每次寫一寫就發現不知不覺就到睡覺時間了。手記裡面裝的東西除了有當年度想完成的事情,有時候紀錄一下唐綺陽的當月運勢,有時候也是寫當下的心情,可能是期待、煩惱、也可能是一些想不透的事情。

沒有目的的書寫,回頭來看倒是有一種紓壓的作用。沒有人會去苛責你中文跟英文混在一起,那就是當下腦袋的狀態。寫下來,也提供自己整理,重整的機會。過一段時間回來看,開心的回憶會轉變成感恩與珍惜,難過或者是挑戰則是會轉變成養分,時間真的是神奇的魔法師。

過了一年,看來是該打開放在書櫃的那本寫作書來讀看看第二章寫什麼了:)

(左邊:2020手記;右邊:只讀了第一章節的寫作工具書)

*註,柏林沒有誠品,只有Dussmann das KulturKaufhaus。因為它是跟誠品很像的綜合性書店,裡面有書、禮品、CD、也有少數文青生活用品。是柏林少數營業時間開到深夜,且週日也開的書店。

  • 重點:文章永遠都不完美

ithome的鐵人賽,是技術社群每年都有的一場活動,由ithome主辦,參與者會在連續30天內發佈30篇文章。對於我來說,上台講研討會是相對簡單的事,但是寫部落格有一種莫名的恐懼。好幾篇文章從2015開始寫草稿,然後就不曾完成過,更別說要連續30天寫30篇了。

這次因為前同事們的邀約,一起把鐵人賽挑戰完畢。好幾次想提早寫完,存檔讓後面幾天的自己輕鬆一些。然而恐懼感轉變成拖延症,總是當天才把稿件寫到一個完整度,壓線送出。

連續30天強迫把文章放上去之後,好像人生也沒有因此而發生什麼憾事。反而因此有幾個讀者聯繫說想看什麼樣的內容,以及該專欄帶給他們什麼樣的啟發跟新的想法。如果不發佈上去,大概永遠就0個讀者吧。

決定把2021的寫作金句從”先寫下來再說”改成“先發佈再說”。

  • 重點:不需要把壓力都放在自己肩上

2019年底跟其他MVP(Microsoft Most Valuable Professional)合著了人生的第一本技術類英文書,2020年也有其他MVP邀約一起寫第二本,於是第二本書的寫稿旅程也就此展開。合作的作者數量從16人降到4人,負責的章節內容也從1章/全書17章變成2.5章/全書9章,也因為如此,覺得落在肩上的責任又更大了。

即便是第二次撰寫英文書稿了,但是在書寫的時候,總是可以感覺到自己英文字彙的貧脊。還沒交稿件的時候,很擔心其他合著作者會覺得我的英文不通順,或是語境沒有掌握得很好。

換個方式,把煩惱的時間拿去思考,例如說:什麼樣的內容是可以最幫助到讀者的?或是什麼樣的呈現方式對於讀者來說是最好學習?要在什麼時候再度複習這個章節的重要概念等等。這樣其實對於作品的完成度可以更提高。而英文寫作的順暢度,跟其他一起合作的英文母語者一起溝通,像是pair programming一樣,是可以在團隊當中學習的。

把這些煩惱都塞在自己的腦袋裡的時候,不僅寫不出東西,這些恐懼還常常跟夜色融為一起,彷彿催狂魔到來一般,讓人無法呼吸。

回頭看看上面三點不難發現,自己常常是寫作的過程最大的心魔,在別人還沒看到作品,連評語都還沒出現的時候,就已經把自己嚇到躲在衣櫥裡了。等到內容交出去之後,才察覺世界很開闊,但怎麼沒想說一開始就放開手好好做呢? 🙂

# 冥想

2020的lockdown對於很多人來說是難過的一年,不僅僅是活動空間受到拘束、無法到處踏青,連帶的心理上也生病了。人類是群居的動物,也是社交的動物。在這之前,大概是沒有體認過,原來和另外一個人面對面相處、和廣闊的大自然相處,是可以帶來多少能量。即便家裡頭有Sam、小貓跟幾盆植物,家裏待久了也很想念可以四處旅行的日子。

在4月的時候Nelly介紹冥想21天的引導練習,於是就跟著一腳踏入冥想的世界了。本該是連續21天的練習,本著懶散的劣根性,做六七天休息一天的練習。完成了一個循環後也連續做了兩個循環,然後就保持著這樣的習慣到現在。

(圖片來源:rachaelrayshow)

||我把冥想練習的spotify播放清單連同最近在聽的Lebron James的冥想課清單一起放在文章後面。需要的朋友可以自己去試看看喔。

從一開始覺得冥想就是坐著發呆,到練習幾個月之後,逐漸地能夠透過冥想放鬆自己。當說到冥想,腦海中可以馬上聯想到“放鬆、冷靜以及重整”。透過專注在觀察自己身心當下的狀態,像是情緒、煩惱、雜念等等,發現原來平時心裡頭有這麼多念頭同時干擾著自己在做決定。因為對於自身的感知放大了,對於外在世界欲加在身上的聲音也會相對減小。這樣的平靜在這一年,幫助我度過了幾個原本覺得會過度緊張或者過度焦慮的關卡。

生活上的正向習慣,是會一個帶動另一個習慣的養成。因為對自身的感受度提升了,也能更快意識到身體上的不適,例如水的攝取、久坐後需要的伸展、或是心理上現在是因為什麼樣的原因感受到負面的情緒起伏等等。這些事情是以往會因為忙碌而錯過的事情,如今透過這些感知,更快速地察覺到自己的狀態,更在乎當下。

專注於當下的生活,連帶著讓生活的幸福度上升許多。包含跟朋友、跟伴侶的相處,更深度的對話,花時間去了解彼此的需求,聽聽在生活上發生的事情,讓雙方的想法都能夠有機會提出跟被了解。依照Mei的說法,讓自己跟朋友或者伴侶更同步(syncronization)了。

特別是在年底,柏林的冬天是寒冷且夜長的,有一群好朋友可以相互打擾,是再溫暖不過的事。這年過去,大家都體認到許多事情真的急切不了,也不是煩惱就能夠解決。透過好好的跟身邊的人相處,好好的專注在手上要做的事情,不知不覺漫長的日子一天一天過去了,心裡依舊能夠感受到平靜、舒適。

寫到這裡的時候,柏林剛好飄起了今年的第一場雪,現在的生活跟羅蘭的<<好長的冬天>>好相似,這個冬天就像是過不完一般漫長,然而2021也在這時候到來了。

# 結尾

談論起新的一年,最喜歡的是一位葡萄牙朋友在歐洲剛跨完年的時候,發的動態:”嗨,在美國的朋友,跟你說,2021也沒有你想得這麼不同。來自2021的問候。“ 

對於許多人來說,新年的到來也許象徵著一種救贖,或者我們讓自己相信,新的一年會有新的轉機,過去一年的無聊、無助、慌張、焦慮、緊張等等的情緒,都可以跟著新年的到來跟著翻頁。

2021帶給你的想像又是什麼呢,你想在這一年做些什麼呢?

(圖片來源:readingrockets)

||想看更多

MLOps 新聞室 https://t.me/MLOps_News
* 關於MLOps 與 ML solution architect
* 中文、英文內容

歐洲碼農的新手村任務 https://ppt.cc/f5fuox
* 第12屆 iT 邦幫忙鐵人賽系列文章
* 海外求職、工程師個人品牌

#推薦閱讀/觀看

1. 給想要從警察視角了解歐洲生活的朋友:

1.1 Police | Berlinale Special 2020

1.2 柏林犬 Dogs of Berlin | Netflix

2. 2020 world news, 給錯過去年大事的朋友:

3. meditation, 給想要練習冥想的朋友:

3.1 豐盛冥想21天

3.2 Lebron James on Calm App