iT邦幫忙

2024 iThome 鐵人賽

DAY 2
0
AI/ ML & Data

從點子構想到部署上線:機器學習專案的一生系列 第 2

[Day 2] ML 系統中容易被忽略的技術債(Technical Debt)問題

  • 分享至 

  • xImage
  •  

機器學習模型的建立和部署,和一般的軟體專案有什麼不同嗎?為什麼需要特別拉出來討論呢?Google 在 2015 年發表的〈Hidden Technical Debt in Machine Learning Systems〉中介紹許多機器學習專案會遇到的技術債問題,而這些是傳統軟體開發所缺乏的。


大家應該很常看到這張圖,說明現實社會中的一個機器學習專案中,其實 ML code 只佔非常小的一部分,多數時間跟心力都耗費在如何蒐集和處理數據、系統的 infra 架構、如何監控等等。

https://ithelp.ithome.com.tw/upload/images/20240916/20152325NWYWdiSJJS.png

接下來,讓我們來看看 ML 專案很容易遇到的一些技術債問題吧!


糾纏(Entanglement)

傳統軟體工程強調透過封裝和模組化設計來建立清晰的抽象邊界,以便於維護和修改程式碼。然而,一個機器學習模型會將各種特徵混在一起,產生複雜的交互影響,任何微小的變動都可能影響整個系統的行為,導致難以獨立改進模型的任一部分,Google 稱之為 CACE 原則(Changing Anything Changes Everything)——改變任何東西都會改變一切。

舉例來說,當一個模型使用到 x1、x2、⋯⋯、xn 等多個特徵時,若改變 x1 的資料分布,所有其他特徵的權重或使用方式可能都會跟著改變,更遑論如果我們增減一個特徵。除了輸入模型的資料特徵以外,模型的超參數(hyper-parameters)、模型和資料的挑選方式等等也都符合這個原則。

數據依賴(Data Dependencies)帶來的挑戰

機器學習系統通常具有複雜的數據依賴關係,例如特徵工程(feature engineering)、數據預處理(data preprocessing)、模型訓練等環節都依賴不同的數據和處理流程。

數據依賴有兩種類型:

  • 不穩定的資料依賴(Unstable Data Dependencies):如果 ML 模型依賴的輸入資料隨著時間而變化,會導致系統難以維護,甚至可能出現錯誤。資料變化可能是隱性(implicit)的,例如輸入特徵是另一個模型的輸出,而此模型發生變化時,或是自然語言處理上常用的 tokenizer,在處理 tokens 時發生變化。

    • ML 系統的行為容易受到外部環境變化的影響,例如使用者行為變化、資料分佈變化等等。
    • 系統需要能夠監控這些變化並及時做出調整,否則會導致模型效能下降。
  • 未充分利用的資料依賴(Underutilized Data Dependencies):如果模型中包含對預測結果沒有幫助的輸入特徵,會增加系統的複雜性和維護成本,例如以下幾種特徵:

    • 遺留特徵 (Legacy Features):舊模型有使用的特徵,而隨著模型更新,已經再也不會用到,卻也沒有被捨棄。
    • 綁定特徵 (Bundled Features) :整包一起出現的特徵,但有些特徵可能沒有作用。例如在做聲音訊號處理時,可能會轉成 mfcc,但不是每個特徵都對模型有實質貢獻。
    • 有相關的特徵(correlated features):有些特徵彼此可能高度相關,但全部都被包含到模型中。

    如果沒有妥善管理,例如版本控制或工作流程的管理工具等,會導致系統變得脆弱,難以維護和更新。因此,與程式碼一樣,資料和模型也應該納入版本控制,不僅可以幫助追蹤資料和模型的變化,並更容易地回復到之前的版本。

    我們在之後會介紹 Netflix 和 Spotify 是如何建立資料和工作流程管理平台,來管理他們龐大又複雜的數據和處理流程。

ML 系統反模式 (Anti-Patterns)

機器學習系統還有一些常見的模式,但是這些是不良的設計方式,應該要極力避免,否則會讓系統變得複雜、不易維護或擴展。

  • 流水線叢林 (Pipeline Jungles):資料預處理流程混亂,缺乏整體規劃,難以測試和維護。
  • 失效的實驗性程式碼路徑 (Dead Experimental Codepaths):保留大量已測試過但被放棄的實驗性程式碼,導致程式碼庫難以理解和維護。

隨著時間推移,ML 系統中可能會累積無用的程式碼和特徵,因此,資料團隊需要定期審查和刪除無用的程式碼和特徵,降低系統的複雜性和維護成本。


在認識到 ML 專案和一般軟體專案的不同,以及他們可能造成的技術債問題之後,我們會在明天介紹 Andrew Ng 在認為完整機器學習專案會包含的五個步驟。接著,在之後的文章中介紹各大科技公司的實際案例,學習他們如何解決這些問題的!


參考資料

  • Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing systems 28 (2015).

謝謝讀到最後的你,如果喜歡這系列,別忘了按下喜歡和訂閱,才不會錯過最新更新。
如果有任何問題想跟我聊聊,或是想看我分享的其他內容,也歡迎到我的 Instagram(@data.scientist.min) 逛逛!
我們明天見!


上一篇
[Day 1] 系列文介紹和規劃大綱
下一篇
[Day 3] ML Project Lifecycle 的五個步驟 + Netflix 的 Match Cutting 案例說明
系列文
從點子構想到部署上線:機器學習專案的一生30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言