今天休息一下，紀錄一下為什麼需要合作？

一個資料團隊的組成

先來看看 OpenAI GPT 4 的貢獻名單 ，從這個組織架上上可以發現團隊大致分成七個部分:

1. Pretraining
2. Long context
3. Vision
4. RL & alignment
5. Evaluation & analysis
6. Deployment
7. Additional Contribution

光是 Pretraining 的部分就可以再細分為

• Computer Cluster Scaling
• Data
• Distributed
• training infrastructure
• Hardware Correctness
• Optimization & Architecture
• Training run babysitting ...

可以看到一個可以簡化成 Chatbot API 的服務，是由一個這麼大的團隊合作來建立的，然而在台灣，部分的新創公司，很有可能都會仰賴一個 Data Scientist 來獨立完成這題目，即使在一些稍有規模的公司，建構這樣這樣的系統可能也不會有超過六個人的編制。如果有人是在一個完整分工的團隊去時做這樣的產品，那真的很幸福，代表老闆非常重視這個產品，但這就衍生下來一個問題，這個團隊的人要如何合作？

一個不成功的團隊合作案例

舉一個例子，曾經和團隊中的另一個資料科學家要合作一個序列模型，他負責實驗模型，而我負責寫 Pipeline 的程式碼，在驗證階段，我和他要了一個資料 csv 來驗生產 Pipeline 的 inference score 是否和實驗中的模型的 Score 一致，於是他傳給了我一個 Amazon S3 resourec 的網址: S3://experiment_bucket/example/experiment_data 給我，然後在整個驗證個結束後我們總共生成了以下檔案

• S3://experiment_bucket/example/experiment_data
• S3://experiment_bucket/example/experiment_data_v1
• S3://experiment_bucket/example/experiment_data_v2
• S3://experiment_bucket/example/experiment_data_v1_no_etl
• S3://experiment_bucket/example/experiment_data_etl_v2
  ...
  有時候是因為他那邊發現了一些 Bug 修正，我這邊需要更改，有時候是我發現了錯誤請他修正，有時候是他發現有其他更好的模型效果，而這樣的合作模式下，我們的資料就越來越亂，後來也不確定自己到底驗證到什麼版本，甚至有時候連他以為某一個版本已經套用了特定的 ETL，但其實還是沒有套用 ETL 的舊資料，這些溝通上的成本，就造成了團隊成員會對合作感到恐懼，認爲期弊大於利。

團隊合作的想像

我認為一個理想的團隊合作會有以下特性："每一個成員都可以知道整個專案的目標是什麼，並且知道怎麼進行，並可以完成自己所分配到的部分"，當然這裡可以再細分為兩種狀態：

1. 每個團隊中的成員彼此可以互相 backup，不只知道對方在做什麼，還可以隨時和對方交換工作
2. 每個團隊中的成員有上下游關係，上下游不用每次都額外溝通就知道如何合作

團隊合作的問題

由於我們團隊的特性我們希望理想的團隊合作是第二種，但我們遇到以下的問題

1. 每次和一個新的 DS 合作，就需要適應不同的合作方式
2. 同一個 Tech Stack (Airflow/ Flink/ Spark/ AWS Sagemaker) 每個人的使用方式都不一樣，舉 Model Serving Endpoint 為例，有人習慣錯誤全部吐 500，有人習慣吐 200 但是將錯誤資訊放在 Response 中
3. 為了適應不同合作方式，前一套系統的程式碼，不一定可以直接移到第二個使用，另外每一個人寫的程式碼，常常重複造輪子
4. 模型報告，分析報表對許多 Metrics 的定義與圖表呈現方式有很大的差異，導致每次解決需要重新理解報表意義

失敗的解決方式

起先我們嘗試定義了很多不同的 Protocol/ Idiomatic 來嘗試非強制性的規範大家的使用方法，然而這些做法並沒有很好的被實踐，原因是因為當專案有時程壓力時，大家會傾向回到自己熟悉的方法，這類依賴人為規範的方法很難好好實踐，於是我們轉向開始研究如何利用 MLOps 的系統來解決我們的問題

用一個高大上的 MLOps 詞雖然畫了一個大餅，有時候我也常想這樣跟 ML Platform 的差異到底是什麼，但是撇除掉詞彙外，不變的是我們如何解決上面遇到的這些問題，如何在合作中減少技術債生成並可以減少合作成本，加速產品迭代週期

一個好的 MLOps 平台我認為要有以下幾個元件:

• 一致的工作流程: 在不同的團隊成員負責資料收集、特徵提取、模型訓練和部署的情況下，事情很容易出錯。MLOps 建立了一個簡化的工作流程，確保每個人都知道自己的角色，並且從一個階段過渡到另一個階段是無縫的。
• 資料和模型的版本控制: 就像軟件代碼需要版本控制一樣，您的資料和機器學習模型也需要。改變僅一個特徵可能會顯著影響模型的性能。MLOps 解決方案通常提供強大的版本控制機制，更容易追踪更改、進行不同版本的實驗，並在需要時回滾到先前的狀態。
• 自動化測試和持續集成: 機器學習中的錯誤代價高昂。不正確標籤的資料或訓練不良的模型可能會導致錯誤的見解。MLOps 將自動化測試引入機器學習生命週期，確保模型在上線前達到預定義的質量標準。這減少了推送壞模型到生產環境的風險，節省了時間和名譽損失。
• 可擴展性: 您的第一個模型可能運行得很好在一台單一的機器上，但當您需要擴大以滿足不斷增長的業務需求時怎麼辦？MLOps 包括容器化和編排的最佳實踐，使您更容易擴展您的運營，而無需重新設計整個系統。
• 資料科學家和工程師之間的合作: 在傳統設置中，資料科學家通常與技術團隊的其他成員相對孤立。他們可能會在部署模型到生產系統時遇到困難，因為他們不熟悉生產級代碼或系統架構。MLOps 彌合了這一差距，促進資料科學家和 DevOps 或 ML 工程師之間的密切合作。
• 監控, 維護和observability: 部署模型只是開始。實際世界的資料會變動，模型會過時。MLOps 不僅促進部署，還包括監控工具，以跟踪您的模型性能隨時間的變化。這使得在必要時更容易更新或退役模型。
• 合規性和治理: 隨著對資料的審查日益加劇，維持資料使用方式、存儲地點以及模型如何建立和部署的透明記錄是至關重要的。MLOps 支持遵守各種法規，如 GDPR，通過維護機器學習生命週期的審計跟踪。

結論

常常在思考 DevOps, SRE, Plarform Enginner 這些角色的定義為什麼在每間公司都有一些不同，但有好像有個很模糊的區分，就像 Machine Learning Enginner, AI Engineer, Data Enginer Data Scientist, MLOps... 在很多公司好像各有其所職，但真要細分好像又沒有辦法說得很清楚各自的 Roles and Responsibility，我認為所有的職位，在最一開始，都是由一個單一的 Developer 負責，負責寫 Code 把服務做出來，負責部署，負責監控 Serving 中的服務的狀態，隨著服務變多，開始把部署跟監控的一些瑣碎事情自動化，最後想把自動化的工具分享出去，慢慢地開始平台化

回到結論，我認為 MLOps 的重點，不在於我們要用什麼工具，而是我們究竟遇到的什麼問題，或是想要解決什麼樣瑣碎的事情，從這出發，在回頭看看市面上有哪些開源專案或服務正式為了解決這些問題而生，這也是為何這系列文的標題寫為從 Data Scientist 到 MLOps 的心路歷程，接下來我們從第一大區塊 Researching 繼續寫下去