前言
很開心能夠在此跟大家分享一些寫程式的經驗，會想要分享這個主題是因為 自己在寫程式的時候也有一些心路歷程，隨著自己走到不同的階段所在的地方會有不同的需求與目標，會改變我們寫程式的目的與習慣。如果各位同學現在是享受寫程式的感覺並且未來想要朝這條路走，可以來參考與討論看看，特別是想要做 Machine Learning 這塊的話，因為今天主要想要從這個面向來分享。
What is MLOps?
首先想跟大家分享什麼是 MLOps？這是來自於 Machine Learning Operations 的縮寫。會特別多加上 Operations，這個意義包含了日常工作的流程，包括機器學習服務的維運、監控成效、實驗、功能擴充等。在這句話我所提到的「機器學習服務」，代表著以機器學習為核心的產品，可以想像成我們在經營一家飲料店，飲料是核心，不過為了賣飲料我們必須做非常多產品的維護與流程優化。所以，MLOps 就是一個在維護機器學習服務的工作。
因為是維護，所以可能會跟同學們在寫論文、做報告以及在外面打機器學習比賽有不少差異。在過去我們接觸機器學習的場景大多是在學習不同的演算法套用到現有的資料，或者是類似的演算法不過在嘗試哪些 hyper parameters 是最好的，抑或是自建演算法等研究類的任務。這些都是在做機器學習沒錯，但未來機器學習工程師的任務，這樣的研究僅僅是一小部分。
我們可以看到 2015 年一篇文章所顯示的現象，在一包機器學習程式碼中，真正在做 ML 沒錯；但為了要做 ML 以及為了要確保 ML 有正常的服務狀態以及成效，在周圍需要若干前處理、探索、架設服務等任務。我舉一些例子：
- Data Collection: 在做報告以及打 kaggle 比賽，資料都是已經準備好的，但在現實的工作往往會涉及到如何收集資料。例如我要經營一家飲料店，消費明細一定要定期更新在資料庫裡面，並且品項、規格、什麼糖什麼冰都需要收集。倘若有會員系統可以跟消費者串聯，若還沒記得當天的天氣、溫度等，或許可以得到更多分析以及建模的資源。因此，要做 ML 之前收集資料是必須的。並且要收集這些資料也要滿足商業流程上的人性以及合邏輯性，我們總不能為了瞭解消費者行為所以在買一杯飲料還來個 10 大 Q&A，這樣可能生意就不好做了。
- Feature Extraction & Data Verification: 以前有個觀念是資料越豐富，ML 模型就有越多參考的資料，成效也就越好；但這並不是一個永恆的真理。我曾做過一個模型，目的預測某些標的物的股價，當時的資料是 2016 年，我在做模型的時候沒有特別把 year, month 這個資料移除，結果發現 month 與股價是成反比的狀態，原因是當時美國總統在 2016 年底結束，市場上對於這個結果表示意外，所以投資市場全數翻黑 ，因此這樣的資料讓模型認為 month 與股價有強烈的反比。然而這樣的邏輯在 2017 年去做 inference 就會有很大的誤差。這個例子是想要告訴大家，feature 在真正使用時其實是需要驗證的，當然除了量化分析之外，ML 應用場景的知識 (e.g. 投資市場) 來判斷也十分重要。
其他區塊我就不多贅述，但未來每個區塊都是不可或缺的部分。
實際上的工作流程
接下來想要談的是除了開發程式之外，工程師工作的日常還包含什麼，以我個人的經驗可以用這張圖說明，包含
- Discuss Business Demand: 除了著重研究的單位外，程式碼開發幾乎都來自於商業需求，可能是飲料推薦、季節活動應該如何行銷等營業上的需要。
- Assess demand by data: 在執行 ML 任務之前，評估需求是很重要的步驟，因為一個 ML 開發下去可能都需要幾週的時間，假設效益不高那麼可是很花成本的。當然除了效益評估之外，現有資源、需要花多久時間完成、怎麼執行，也是評估的一環。
- Create issue or ticket: 開任務單，進入專案管理環節。
- Design: 這裡的設計包含很多面向，大至系統架構，小至程式碼裡面的函數、物件怎麼設計也在此。很多時候我們接到一個任務就埋頭做下去，結果寫出來給主管或者其他 partners 看才發現跟其他人想的不一樣，或是發現有不少細節沒注意。這些可大可小的問題都可以在 Design 這個地方被縮小甚至解決。
- Start coding: 這個步驟就是真的在開發程式。而前面所說的 ML code, data verification, feature extraction 等 coding 面向都發生在這裡。因此這裡想表達的是開發程式之前需要做非常多的計畫、評估、多面向的縝密構思才能產生。
- Test: 這邊說的測試部分會與 5. Start coding 重疊，包括函數的單元測試、整個功能在測試環境執行看看是否符合預期。
- PR: 這可能是學生時代比較少碰到的，寫程式提 PR 好比交作業給老師 review，在工作上就是給團隊成員 review 看裡面有沒有沒注意到的細節、程式風格是否與團隊風格一致、或是其他問題等。這可能也會需要來回討論，不過這些時間也是確保程式碼的完整的。
- Deployment: 功能開發完成，未來絕對不會是在自己桌上這台電腦做運算，完整的自動化服務是必需要被部署在雲端上的，可能是 API 服務、資料 pipeline 等。這部分是另外一個學問，這裡不多做說明。
- Monitoring: 這裡可能會跟前一部分的 monitoring 有些重疊，可以說明的是有不同面向來監控。舉例來說，ML metric 的指標與商業指標有時候不太一樣。如果我們定義的 ML model 是預測哪些消費者願意收到飲料 DM，那麼這個 model 的 accuracy 可能很高；但老闆可能會問說為什麼 ML model 表現這麼好 但是怎麼沒比較賺錢？原因是我們最源頭在建立 model 的時候就問錯問題了！當然這是一個誇張的例子，有很多時候 ML metric 跟商業指標有相似但些微的差距，都需要定期監控以及思考如何縮短這個差距。
現在 v.s. 未來
熱愛寫程式的大家，在這裡讓大家思考一下現在是不是這樣做 ML 的？
notebook 或是幾個 scripts 寫到底、持續 hyper parameters tuning 等。但實際上的程式碼不會將 notebook 部署到營運環境，會上去的一定是有結構化的程式碼 (有時稱 production code)，並且會考量到運算資源、模型穩定性等維運的功夫。因此，未來工作模式會像下面這樣。大部分在前個階段介紹過，這邊想特別提的是
- 頻繁且快速 sync: 有時候我們會想要把一個東西做好做完整才提交，不過卻可能會碰到產出與對方設想的不一致。其實都有問題就快速提出來與大家討論可以提升效率也可以降低很多不必要的溝通成本、開發失誤等。
- Documentation (Coding as document): 文件化是一個重要的流程，其目的包含描述我們開發的功能與產品、如何使用等。至於使用什麼工具，當然是看未來團隊所使用的工具，不過這裡會想要強調 coding as document，大家或多或少看過某些網路上的 repo 裡面的 README.md 寫的很豐富，就像使用說明書一樣。這就是一種 coding as document，當然也包含各種函數或是檔案的 docstring。未來大家可以細細品嚐這個好處。
- 分享、回饋、調整: 與頻繁 sync 類似，有機會就分享自己現在在做的事情，得到回饋然後做調整，是一種集眾人智慧於一身的方式。過去我曾經覺得要分享一定是要等到把自己的東西做得很完整才可以拿出來 report，像是展現最好的一面；但有次我去參加一個 talk，那裡的主持人說其實不用到 100 分的準備，有什麼東西就拿出來分享，這可以加速資訊交流，也能夠快速得到也許我們花了數個工作天才想到 solution。在我們 team 裡面，也經常會有人分享跟開發無關的東西，包含看到不錯的 youtube 影片、IDE 新功能、新學習 app 分享等。推廣 sharing 文化我覺得讓團隊進步更會更好。
團隊策略
最後想要分享的是「策略」。我所理解的策略就是根據團隊的目標或價值來決定什麼任務現在要做，並且要怎麼做。未來大家會發現，在任何一個公司或者組織絕對有做不完的事情，人力有限，我們不可能每件事都做完，所以必須要做取捨。
以我的經驗來分享，因為主要是做 ML service，服務穩定且實現商業價值是最主要的，所以我們會根據 bug、新功能或者 known issue 來判斷。舉個例子
- bug: 如果客戶來我們家點飲料，不知道為什麼點了奶茶系統就是會 shutdown，那這肯定是要立刻修的 bug，不然就不用賣奶茶了
- feature: 點餐機上根據季節或者客戶特性推薦最適合的飲品
- known issue: 一個購物網站的負荷量有限，1 分鐘可以承受 1 萬次瀏覽，但可能無法承受 10 萬次。平常沒事，但等到雙 11 就會出事
除此之外，當我們要執行一項任務時，也會考量不同解決方式的成本。學生時期學到的通常是最好的 solution；但在工作上是情況可能會用短解的方式。例如，一個資料處理流程因為資料太多造成 OOM，因為時間壓力的關係可能會採抽樣但盡量不失真的方式解決。然後再開一個 OOM 的 known issue，有一天還是要真是的面對這個問題。
結論
前面林林總總說了很多，簡單總結一下想說的
- 在以前可能認為做 ML, AI 是在研究很酷炫的模型或者演算法，但大部分時間其實在基礎服務的維護與應用，甚至在推廣一個基本功能的商業應用
- 在企業開發其實比與 AI research、打 hackathon 或者人工智慧挑戰賽有很多差異，架構設計與實用性經常是主要考量
- 團隊策略與核心價值，有時候甚至要停下腳步思考個人的核心價值是什麼
- 努力、認真很重要，但聰明地做事，有時比 work hard 更關鍵
以上是我的簡單分享，如果有幫助到大家一點點的話那是我的榮幸！
