機器學習模型的建立和部署，和一般的軟體專案有什麼不同嗎？為什麼需要特別拉出來討論呢？Google 在 2015 年發表的〈Hidden Technical Debt in Machine Learning Systems〉中介紹許多機器學習專案會遇到的技術債問題，而這些是傳統軟體開發所缺乏的。
大家應該很常看到這張圖，說明現實社會中的一個機器學習專案中，其實 ML code 只佔非常小的一部分，多數時間跟心力都耗費在如何蒐集和處理數據、系統的 infra 架構、如何監控等等。
接下來，讓我們來看看 ML 專案很容易遇到的一些技術債問題吧！
傳統軟體工程強調透過封裝和模組化設計來建立清晰的抽象邊界，以便於維護和修改程式碼。然而，一個機器學習模型會將各種特徵混在一起，產生複雜的交互影響，任何微小的變動都可能影響整個系統的行為，導致難以獨立改進模型的任一部分，Google 稱之為 CACE 原則（Changing Anything Changes Everything）——改變任何東西都會改變一切。
舉例來說，當一個模型使用到 x1、x2、⋯⋯、xn 等多個特徵時，若改變 x1 的資料分布，所有其他特徵的權重或使用方式可能都會跟著改變，更遑論如果我們增減一個特徵。除了輸入模型的資料特徵以外，模型的超參數（hyper-parameters）、模型和資料的挑選方式等等也都符合這個原則。
機器學習系統通常具有複雜的數據依賴關係，例如特徵工程（feature engineering）、數據預處理（data preprocessing）、模型訓練等環節都依賴不同的數據和處理流程。
數據依賴有兩種類型：
不穩定的資料依賴（Unstable Data Dependencies）：如果 ML 模型依賴的輸入資料隨著時間而變化，會導致系統難以維護，甚至可能出現錯誤。資料變化可能是隱性（implicit）的，例如輸入特徵是另一個模型的輸出，而此模型發生變化時，或是自然語言處理上常用的 tokenizer，在處理 tokens 時發生變化。
未充分利用的資料依賴（Underutilized Data Dependencies）：如果模型中包含對預測結果沒有幫助的輸入特徵，會增加系統的複雜性和維護成本，例如以下幾種特徵：
如果沒有妥善管理，例如版本控制或工作流程的管理工具等，會導致系統變得脆弱，難以維護和更新。因此，與程式碼一樣，資料和模型也應該納入版本控制，不僅可以幫助追蹤資料和模型的變化，並更容易地回復到之前的版本。
我們在之後會介紹 Netflix 和 Spotify 是如何建立資料和工作流程管理平台，來管理他們龐大又複雜的數據和處理流程。
機器學習系統還有一些常見的模式，但是這些是不良的設計方式，應該要極力避免，否則會讓系統變得複雜、不易維護或擴展。
隨著時間推移，ML 系統中可能會累積無用的程式碼和特徵，因此，資料團隊需要定期審查和刪除無用的程式碼和特徵，降低系統的複雜性和維護成本。
在認識到 ML 專案和一般軟體專案的不同，以及他們可能造成的技術債問題之後，我們會在明天介紹 Andrew Ng 在認為完整機器學習專案會包含的五個步驟。接著，在之後的文章中介紹各大科技公司的實際案例，學習他們如何解決這些問題的！
參考資料
謝謝讀到最後的你，如果喜歡這系列，別忘了按下喜歡和訂閱，才不會錯過最新更新。
如果有任何問題想跟我聊聊，或是想看我分享的其他內容，也歡迎到我的 Instagram（@data.scientist.min） 逛逛！
我們明天見！
iThome鐵人賽
看影片追技術