機器學習專案落地常遭遇模型佈署困難、使用者採用率低等問題,這並非單純的技術挑戰,更涉及產品策略、團隊協作和流程最佳化。要提升成功率,除了資料品質和模型效能,更需關注使用者需求、產品設計和高效能工程實踐。許多機器學習專案未能成功將模型佈署到生產環境,或佈署後未能達到預期效果,這凸顯了產品策略和跨團隊協作的重要性。構建成功的機器學習產品,需要整合產品、工程、資料科學等多個團隊,並採用精益方法和系統思維,才能有效應對現實世界的複雜性。
機器學習專案的失敗
儘管有許多頂級的Kaggle筆記本,機器學習專案在現實世界中失敗是很常見的。失敗可能以多種形式出現,包括:
- 無法將機器學習啟用的產品交付到生產環境
- 交付的產品是客戶不使用的
- 佈署的產品是客戶不信任的
這些挑戰可能來自於各個方面,包括資料品質、模型複雜度、佈署難度等。瞭解這些挑戰是構建成功的機器學習專案的關鍵一步。
解決機器學習專案的挑戰
為瞭解決機器學習專案的挑戰,我們需要從多個角度入手,包括工程、產品和交付。以下是幾個關鍵的原則和實踐:
- 精益交付:關注交付價值,減少浪費,提高效率
- 產品思維:從客戶需求出發,設計和交付滿足客戶需求的產品
- 敏捷工程:採用敏捷方法論,快速迭代,持續交付
透過採用這些原則和實踐,機器學習團隊可以提高交付成功的機器學習啟用的產品的機會,避免不必要的陷阱,找到一條更可靠的路徑來實作您的目標。
機器學習模型在生產環境中的挑戰
在將機器學習模型佈署到生產環境中時,會遇到許多挑戰。這些挑戰可能來自於多個方面,包括產品、交付和工程。瞭解這些挑戰是非常重要的,因為它們可能會影響模型的效能和整體的商業成果。
高層次視角:成功的障礙
從高層次視角來看,機器學習專案可能會因為以下幾個原因而失敗:
- 解決錯誤的問題或未能為使用者帶來價值:即使工程實踐正確,專案仍可能因為沒有解決正確的問題或未能為使用者帶來價值而失敗。這通常發生在團隊缺乏產品管理能力或與產品和商業目標不一致時。
- 模型在生產環境中的挑戰:許多機器學習專案在生產環境中都遇到挑戰。根據2021年Gartner的一項調查,只有53%的AI專案能夠從試驗階段進入生產階段,而且成功的專案需要平均9個月的時間。
- 模型佈署後的挑戰:一旦模型佈署到生產環境中,機器學習從業者可能會遇到許多挑戰,包括資料品質、延遲和分佈等問題。
長時間或缺失的反饋迴圈
在模型開發過程中,反饋迴圈往往很長且耗時。這可能會導致寶貴的時間被浪費在不重要的工作上。例如,開發人員可能需要手動執行訓練筆記本或指令碼,等待它完成,然後手動瀏覽日誌或列印陳述式來檢視模型的效能。這種方法不僅耗時且不夠有效。
解決方案
為瞭解決這些挑戰,需要採取多方面的方法,包括:
- 產品管理:確保團隊具有成熟的產品管理能力,能夠識別使用者的需求和痛點。
- 自動化:自動化模型的佈署和測試過程,以減少人工錯誤和提高效率。
- 資料品質:確保資料的品質和可靠性,以支援模型的訓練和佈署。
- 反饋迴圈:建立快速和有效的反饋迴圈,以便及時發現和解決問題。
透過採取這些措施,可以提高機器學習模型在生產環境中的成功率,同時也能夠減少失敗的風險和成本。
內容解密:
在這個章節中,我們討論了機器學習模型在生產環境中的挑戰,包括解決錯誤的問題、模型在生產環境中的挑戰、模型佈署後的挑戰和長時間或缺失的反饋迴圈。同時,我們也提出瞭解決這些挑戰的方法,包括產品管理、自動化、資料品質和反饋迴圈。這些方法可以幫助提高機器學習模型的成功率和效率。
圖表翻譯:
graph LR A[機器學習模型] --> B[生產環境] B --> C[挑戰] C --> D[解決錯誤的問題] C --> E[模型在生產環境中的挑戰] C --> F[模型佈署後的挑戰] C --> G[長時間或缺失的反饋迴圈] D --> H[產品管理] E --> I[自動化] F --> J[資料品質] G --> K[反饋迴圈]
這個圖表展示了機器學習模型在生產環境中的挑戰和解決方法的關係。它可以幫助讀者更好地理解這些挑戰和解決方法之間的聯絡。
機器學習系統的挑戰
在實際應用中,機器學習(ML)系統常面臨多個挑戰,包括缺乏從生產環境中學習的機制、程式碼品質問題、資料品質問題以及資料安全和隱私問題。
缺乏從生產環境中學習的機制
許多機器學習模型在佈署後,沒有機制可以從生產環境中收集資料和反饋。這使得團隊無法利用資料為中心的方法來改進模型品質。例如,沒有資料收集和標注機制,模型就無法學習到新的模式和關係。
程式碼品質問題
機器學習程式碼函式庫通常充滿了程式碼異味,例如變數命名不當、函式過長和過於複雜、緊密耦合的程式碼等。這使得程式碼難以理解和修改,從而增加了錯誤和漏洞的風險。隨著功能的增加,程式碼函式庫的複雜性和風險也會增加。
資料品質問題
資料品質問題是機器學習系統中的一個重大挑戰。例如,一項研究發現,數百個預測工具被開發來幫助醫院檢測COVID-19,但 none 都無法正常工作。資料品質問題包括資料洩露、錯誤標注和訓練資料與實際資料之間的分佈不對稱等。
資料安全和隱私問題
資料安全和隱私是機器學習系統中的一個重要挑戰。機器學習中有一些特殊的資料安全和隱私挑戰,例如資料中毒等。資料中毒是指攻擊者故意修改資料以影響模型的效能。
圖表翻譯:
graph LR A[資料收集] --> B[資料處理] B --> C[模型訓練] C --> D[模型佈署] D --> E[模型評估] E --> F[資料反饋] F --> A
圖表展示了機器學習系統的資料流程,從資料收集到模型佈署和評估,然後回到資料收集的迴圈中。
內容解密:
機器學習系統的挑戰包括缺乏從生產環境中學習的機制、程式碼品質問題、資料品質問題以及資料安全和隱私問題。這些挑戰會影響模型的效能和可靠性。因此,需要採取措施來解決這些挑戰,例如實作資料為中心的方法、改行程式碼品質、確保資料品質和安全性。
機器學習的挑戰:從道德問題到日常障礙
機器學習(ML)在各個領域都有著廣泛的應用,但其實,ML專案的成功並不容易。除了技術上的挑戰外,還有許多道德問題和日常障礙需要我們關注。
道德問題:有偏見的資料和不公平的結果
機器學習模型的訓練需要大量的資料,但如果這些資料中含有偏見或不公平的資訊,模型就可能學習到這些偏見並產生不公平的結果。例如,Amazon曾經開發了一個徵才工具,該工具會對含有「女性」一詞的履歷表進行懲罰。這個工具最終被廢棄,因為它的結果是有偏見的。
日常障礙:低效率的環境和高效率的環境
在ML專案中,日常障礙是指那些阻礙我們執行想法的瓶頸。這些瓶頸可能來自於我們的方法、工程實踐、合作流程或工作安排等方面。讓我們透過一個例子來瞭解這些瓶頸。
低效率環境中的故事
讓我們跟隨Dana,一位ML工程師,來看看她在低效率環境中的經歷。Dana的團隊正在遭受警示疲勞,這意味著他們經常忽略來自系統的警示。Dana需要手動檢查多個日誌和監控系統來排查問題,因為沒有聚合的日誌系統。她還需要手動測試模型來找到為什麼模型會對某個客戶產生特定的預測。
Dana的團隊缺乏有效的合作流程和工作安排,這使得他們很難解決問題和完成任務。這種低效率的環境不僅浪費了時間和資源,也使得團隊難以達到目標。
高效率環境中的故事
在高效率的環境中,Dana的團隊可以更有效地合作和完成任務。透過使用合適的工具和流程,Dana可以快速地排查問題和找到解決方案。團隊成員可以更好地合作,分享知識和經驗,從而提高整體的效率和生產力。
內容解密:
- 機器學習的挑戰包括道德問題和日常障礙。
- 低效率的環境會浪費時間和資源,難以達到目標。
- 高效率的環境可以提高整體的效率和生產力。
- 合適的工具和流程可以幫助團隊成員更好地合作和完成任務。
圖表翻譯:
graph LR A[低效率環境] --> B[警示疲勞] B --> C[手動檢查] C --> D[缺乏合作流程] D --> E[難以達到目標] F[高效率環境] --> G[合適工具和流程] G --> H[快速排查問題] H --> I[提高效率和生產力]
這個圖表展示了低效率環境和高效率環境之間的差異。在低效率環境中,警示疲勞和手動檢查會浪費時間和資源,難以達到目標。在高效率環境中,合適的工具和流程可以幫助團隊成員更好地合作和完成任務,從而提高整體的效率和生產力。
高效能開發環境的重要性
在軟體開發領域,高效能開發環境對於提升團隊的生產力和效率至關重要。讓我們以 Dana 的故事為例,來探討傳統開發環境和高效能開發環境之間的差異。
傳統開發環境的挑戰
在傳統開發環境中,Dana 面臨著許多挑戰。例如,她需要花費大量時間等待程式碼執行、手動測試和除錯。此外,團隊缺乏自動化測試和即時反饋機制,導致 Dana 需要花費更多時間來確保程式碼的正確性。
高效能開發環境的優勢
在高效能開發環境中,Dana 的工作流程發生了根本性的改變。每個故事卡都明確地定義了商業價值和完成的標準,讓 Dana 能夠專注於實作這些價值。透過與隊友的配對程式設計,Dana 能夠即時獲得反饋和知識分享,從而提高程式碼的品質和效率。
此外,高效能開發環境中的自動化測試和即時反饋機制讓 Dana 能夠快速驗證程式碼的正確性,減少了手動測試和除錯的時間。這些功能不僅提高了 Dana 的工作效率,也讓她能夠更快地實作商業價值和交付高品質的程式碼。
高效能開發環境的關鍵要素
高效能開發環境的關鍵要素包括:
- 自動化測試和即時反饋機制:能夠快速驗證程式碼的正確性,減少手動測試和除錯的時間。
- 配對程式設計和知識分享:能夠即時獲得反饋和知識分享,提高程式碼的品質和效率。
- 明確的商業價值和完成標準:能夠讓開發人員專注於實作商業價值和完成標準。
- 高效能的開發工具和基礎設施:能夠支援開發人員快速交付高品質的程式碼。
圖表翻譯:
此圖表示高效能開發環境的流程。商業價值是開發的起點,透過故事卡的定義和配對程式設計的合作,開發人員能夠實作商業價值。自動化測試和即時反饋機制能夠快速驗證程式碼的正確性,從而提高程式碼的品質和效率。最終,高品質的程式碼能夠實作商業價值和交付給客戶。
高效能開發環境的優勢
在高效能開發環境中,開發團隊可以快速迭代和佈署新的機器學習模型。這種環境下的開發流程通常包括以下步驟:
- 資料準備:開發人員可以快速存取生產資料和可擴充套件的計算資源。
- 程式碼提交:程式碼變更會經過一系列自動化的檢查和測試,包括持續整合和持續佈署(CI/CD)管線。
- 模型訓練:模型訓練可以在幾分鐘到幾小時內完成,取決於模型架構和資料量。
- 模型佈署:當模型訓練完成後,模型佈署管線會自動觸發,進行模型品質測試和檢查。
- 測試和驗證:如果模型品質達到門檻,新訓練的模型會被自動包裝和佈署到預生產環境,並進行後佈署測試。
這種高效能開發環境下的開發流程可以讓開發人員更有效率地工作,減少了開發時間和成本。
高效能開發環境的特點
高效能開發環境通常具有以下特點:
- 快速迭代:開發人員可以快速迭代和佈署新的機器學習模型。
- 自動化測試:自動化測試可以快速檢查模型品質和功能。
- 可擴充套件的計算資源:開發人員可以快速存取可擴充套件的計算資源。
- 高效能的CI/CD管線:CI/CD管線可以快速進行模型訓練、測試和佈署。
- 團隊合作:開發人員可以合作完成開發任務,減少了開發時間和成本。
高效能開發環境的優勢
高效能開發環境可以帶來以下優勢:
- 提高開發效率:開發人員可以快速迭代和佈署新的機器學習模型。
- 減少開發時間:開發時間可以減少,讓開發人員可以更快速地完成開發任務。
- 提高模型品質:自動化測試可以快速檢查模型品質和功能。
- 提高團隊合作:開發人員可以合作完成開發任務,減少了開發時間和成本。
圖表翻譯:
此圖表示高效能開發環境下的開發流程。開發人員提交程式碼後,會經過自動化測試、模型訓練、模型佈署和測試和驗證等步驟,最終佈署到生產環境。這個流程可以讓開發人員更有效率地工作,減少了開發時間和成本。
高效能環境與低效能環境下的任務反饋
在軟體開發中,環境的效能對於任務的完成速度和反饋有著顯著的影響。高效能環境和低效能環境下的任務反饋時間差異非常大,從幾秒鐘到幾分鐘甚至更長。
高效能環境
- 自動化測試:在高效能環境中,自動化測試可以在短短幾秒鐘到幾分鐘內完成。這使得開發人員可以快速地獲得測試結果,從而加速軟體的開發和除錯過程。
- 即時反饋:高效能環境提供了即時的反饋,讓開發人員可以快速地瞭解程式碼變更是否如預期般運作。這種即時反饋機制大大提高了開發效率和產品品質。
低效能環境
- 手動測試:在低效能環境中,測試過程可能需要手動進行,耗時更長。這不僅減慢了開發速度,也增加了出錯的可能性。
- 延遲反饋:低效能環境下的反饋可能會延遲,開發人員需要等待更長的時間才能知道程式碼變更是否有效。這種延遲不僅降低了開發效率,也可能導致專案延期。
手動測試流程
手動測試是確保機器學習(ML)訓練流程順暢執行的重要步驟。以下是手動測試流程的概述:
手動測試時間
手動測試的時間可以從幾分鐘到幾個小時不等,取決於測試的複雜度和資料的大小。
測試ML訓練流程
手動測試的主要目的是確保ML訓練流程從開始到結束都能夠順暢執行。這包括了資料的預處理、模型的訓練、模型的評估等步驟。
訓練煙霧測試
訓練煙霧測試是一種快速的測試,用於確認ML訓練流程是否能夠正常執行。這種測試通常只需要幾分鐘的時間。
完整模型訓練
完整模型訓練是指對整個ML模型進行訓練,包括了資料的預處理、模型的訓練、模型的評估等步驟。這種測試的時間可以從幾分鐘到幾個小時不等,取決於資料的大小和模型的複雜度。
內容解密:
手動測試流程的目的是確保ML訓練流程的可靠性和準確性。透過手動測試,可以發現和修復流程中的錯誤和問題,從而確保ML模型的品質和效能。
flowchart TD A[開始] --> B[資料預處理] B --> C[模型訓練] C --> D[模型評估] D --> E[結果輸出]
圖表翻譯:
上述流程圖展示了手動測試流程的步驟,從資料預處理到結果輸出。每個步驟都對應著ML訓練流程中的重要環節,透過這個流程圖,可以清晰地看到手動測試的過程和內容。
程式碼審查流程
在軟體開發過程中,程式碼審查是一個非常重要的步驟。它可以幫助開發者找出程式碼中的錯誤、提高程式碼的品質和可維護性。以下是幾種常見的程式碼審查流程:
即時反饋
即時反饋是指開發者在編寫程式碼的同時,立刻獲得其他開發者的反饋。這種方式通常透過 pair programming 或即時通訊工具實作。透過即時反饋,開發者可以快速地修正錯誤,提高程式碼的品質。
程式碼審查
程式碼審查是指開發者提交程式碼變更後,其他開發者進行審查和評估。這種方式通常透過 pull request 或 code review 工具實作。透過程式碼審查,開發者可以找出程式碼中的錯誤,提高程式碼的品質和可維護性。
實作即時反饋和程式碼審查
要實作即時反饋和程式碼審查,開發者可以使用以下工具和技術:
- Pair programming:開發者可以使用 pair programming 工具,如 Visual Studio Live Share 或 Google Cloud Source Repositories,實作即時反饋。
- 即時通訊工具:開發者可以使用即時通訊工具,如 Slack 或 Microsoft Teams,實作即時反饋。
- Pull request 工具:開發者可以使用 pull request 工具,如 GitHub 或 GitLab,實作程式碼審查。
- Code review 工具:開發者可以使用 code review 工具,如 Gerrit 或 Crucible,實作程式碼審查。
優點和挑戰
即時反饋和程式碼審查有以下優點:
- 提高程式碼品質:即時反饋和程式碼審查可以幫助開發者找出程式碼中的錯誤,提高程式碼的品質。
- 提高開發效率:即時反饋和程式碼審查可以幫助開發者快速地修正錯誤,提高開發效率。
- 提高團隊合作:即時反饋和程式碼審查可以幫助開發者之間進行溝通和合作,提高團隊合作。
但是,實作即時反饋和程式碼審查也有一些挑戰:
- 時間和成本:實作即時反饋和程式碼審查需要花費時間和成本。
- 技術和工具:實作即時反饋和程式碼審查需要使用適當的技術和工具。
- 文化和流程:實作即時反饋和程式碼審查需要建立適當的文化和流程。
圖表翻譯:
graph LR A[開發者提交程式碼變更] --> B[程式碼審查] B --> C[即時反饋] C --> D[修正錯誤] D --> E[提高程式碼品質] E --> F[提高開發效率] F --> G[提高團隊合作]
圖表翻譯:以上圖表展示了開發者提交程式碼變更後,程式碼審查和即時反饋的流程。開發者提交程式碼變更後,程式碼會進行審查和評估。透過即時反饋,開發者可以快速地修正錯誤,提高程式碼的品質和可維護性。最終,開發效率和團隊合作會得到提高。
高效反饋迴圈與任務完成時間
在軟體開發中,反饋迴圈(Feedback Loop)扮演著至關重要的角色。它使得開發人員能夠及時瞭解自己的工作成果是否符合預期,從而進行調整和最佳化。高效的反饋迴圈可以大大提升開發效率和軟體品質。
反饋迴圈的重要性
反饋迴圈的核心是讓開發人員能夠快速地知道自己的程式碼是否正確地執行,是否滿足需求,以及是否存在任何問題。這個過程可以分為幾個層面:
- 編碼階段: 在編寫程式碼的時候,開發人員需要知道自己的程式碼是否正確無誤。這可以透過單元測試、編譯器檢查等手段來實作。
- 測試階段: 在程式碼透過編譯和單元測試後,需要進行整體的功能測試,以確保軟體按照預期執行。
- 佈署階段: 軟體佈署到生產環境後,需要監控其執行狀態,確保它能夠正確地處理使用者請求和資料。
高效環境與低效環境
在高效的開發環境中,反饋迴圈是非常快速的。開發人員可以在幾秒鐘或幾分鐘內就知道自己的程式碼是否正確,是否有錯誤需要修正。這使得開發人員可以快速地進行調整和最佳化,從而大大提升開發效率。
相反,在低效的開發環境中,反饋迴圈可能需要幾個小時甚至幾天。這可能是由於測試環境的設定、佈署過程的複雜性等因素導致的。這種情況下,開發人員需要等待很長時間才能知道自己的程式碼是否正確,從而大大降低了開發效率。
監控與反饋
在軟體佈署到生產環境後,監控其執行狀態是非常重要的。這可以透過日誌分析、效能監控等手段來實作。監控可以提供即時的反饋,讓開發人員能夠快速地知道軟體是否存在問題,從而進行及時的調整和最佳化。
內容解密:
上述內容解釋了反饋迴圈在軟體開發中的重要性,包括其在不同階段的作用、 高效環境與低效環境的差異、以及監控和反饋的重要性。這些內容都圍繞著如何提高軟體開發的效率和品質,強調了快速的反饋迴圈在這個過程中的核心地位。
圖表翻譯:
flowchart TD A[編碼階段] --> B[測試階段] B --> C[佈署階段] C --> D[監控階段] D --> E[反饋迴圈] E --> A
此圖表展示了軟體開發的不同階段之間的關係,從編碼階段到監控階段,然後回到反饋迴圈,形成一個迴圈的過程。這個迴圈過程是軟體開發中非常重要的一部分,能夠確保軟體的品質和效率。
從低效能環境到高效能環境的轉變
在前面的章節中,我們探討了機器學習(ML)解決方案的常見陷阱和更有效的替代方法。現在,讓我們來看看如何將團隊從低效能環境轉變為高效能環境。
問題的根源:低效能環境
低效能環境通常是由於系統性問題引起的。著名經濟學家和工業工程師W. Edwards Deming曾說過:「一個壞的系統會戰勝一個好的個人。」這意味著,即使個人具有高超的技能和努力,如果系統存在缺陷,仍然會導致低效能和挫敗。
在低效能環境中,機器學習從業者經常面臨不必要的辛勞和重複工作,導致挫敗和可能的倦怠。這些問題表明我們的工作系統需要改進。
MLOps的侷限性
MLOps(Machine Learning Operations)是一種旨在提高機器學習模型佈署效率的方法論。然而,MLOps單獨不足以改善機器學習從業者的效能。為了有效地交付機器學習解決方案,需要一個更全面的方法。
系統思考和精益方法
系統思考是一種考慮整個系統的方法,包括其各個部分和相互關係。透過這種方法,我們可以識別出機器學習交付的關鍵實踐。精益方法是一種關注消除浪費和最大化價值的方法論。透過結合系統思考和精益方法,我們可以建立一個高效能的機器學習交付系統。
建立高效能環境
要建立高效能環境,需要關注以下幾個方面:
- 系統思考:考慮整個系統,包括其各個部分和相互關係。
- 精益方法:關注消除浪費和最大化價值。
- 自動化:自動化重複性任務和流程。
- 監控和反饋:實時監控和反饋機器學習模型的效能。
- 持續改進:不斷改進機器學習交付流程和系統。
透過這些方法,我們可以建立一個高效能的機器學習交付系統,從而提高機器學習從業者的效能和滿意度。
內容解密:
在這個章節中,我們探討瞭如何將團隊從低效能環境轉變為高效能環境。低效能環境通常是由於系統性問題引起的,需要一個全面的方法來改善。MLOps單獨不足以改善機器學習從業者的效能,需要結合系統思考和精益方法來建立一個高效能的機器學習交付系統。透過系統思考、精益方法、自動化、監控和反饋、持續改進等方法,我們可以建立一個高效能的機器學習交付系統,從而提高機器學習從業者的效能和滿意度。
graph LR A[低效能環境] -->|系統性問題|> B[挫敗和倦怠] B -->|需要改進|> C[系統思考和精益方法] C -->|自動化和監控|> D[高效能環境] D -->|持續改進|> E[機器學習從業者效能和滿意度提高]
圖表翻譯:
這個圖表展示了從低效能環境到高效能環境的轉變過程。首先,低效能環境由於系統性問題引起挫敗和倦怠。然後,透過系統思考和精益方法,我們可以改善機器學習交付系統。接下來,自動化和監控可以幫助我們建立一個高效能環境。最後,透過持續改進,我們可以提高機器學習從業者的效能和滿意度。
整合系統思維:打造高效的機器學習交付流程
在交付機器學習(ML)產品的過程中,各個子系統之間的協調運作至關重要。然而,單純地依靠MLOps實踐和ML平臺是不夠的。就像在軟體交付中,DevOps和平臺只能最佳化和管理部分子系統,其他子系統如軟體設計、使用者經驗和軟體交付生命週期同樣重要。
在機器學習中,MLOps和ML平臺不能替代軟體工程實踐(如自動測試、良好的設計等)和產品交付實踐(如使用者旅程對映、清晰的使用者故事等)。只有當這些實踐被整合到機器學習交付流程中時,才能真正發揮作用。
研究表明,成功的機器學習驅動的客戶端隨機控制試驗的關鍵因素是迭代、假設驅動的過程,與其他學科如產品開發、使用者經驗、電腦科學、軟體工程、因果推斷等緊密結合。這與我們的經驗相符,即交付成功的機器學習專案需要跨五個學科的多學科方法:產品、軟體工程、資料、機器學習和交付。
系統思維可以幫助我們瞭解這些學科之間的相互關係和互動作用。透過系統思維的視角,我們可以看到,交付機器學習產品是一個系統工程,需要考慮各個子系統之間的協調運作。
系統思維的核心
系統思維是一種幫助我們從個別部分轉向整體關係和互動作用的思維方式。它給我們提供了理解和改變不利於我們的結構的思維模型和工具,包括我們的思維模型和認知。
在交付機器學習產品的背景下,系統思維可以幫助我們:
- 整體性: 考慮機器學習交付流程的整體性,包括各個子系統之間的關係和互動作用。
- 迭代: 實作迭代、假設驅動的過程,與其他學科緊密結合。
- 多學科: 跨五個學科的多學科方法:產品、軟體工程、資料、機器學習和交付。
實踐系統思維
要實踐系統思維,需要:
- 定義系統: 清晰定義機器學習交付流程的系統邊界和目標。
- 識別子系統: 識別各個子系統,包括產品、軟體工程、資料、機器學習和交付。
- 分析關係: 分析各個子系統之間的關係和互動作用。
- 最佳化系統: 最佳化整體系統的效能,考慮各個子系統之間的協調運作。
透過系統思維的視角,我們可以更好地瞭解交付機器學習產品的複雜性,從而實作更高效的交付流程。
資料科學與機器學習產品交付的核心要素
資料科學和機器學習(ML)產品交付是一個複雜的過程,涉及多個核心要素的協同工作。這些要素包括:
- 資料:資料是機器學習的基礎,高品質的資料對於建立有效的模型至關重要。
- 機器學習實驗:機器學習實驗是指使用資料建立和訓練模型的過程,包括特徵工程、模型選擇和超引數調整等步驟。
- 軟體工程:軟體工程是指將機器學習模型整合到軟體系統中的過程,包括模型佈署、API設計和測試等步驟。
- 基礎設施和佈署:基礎設施和佈署是指將機器學習模型佈署到生產環境中的過程,包括選擇合適的硬體和軟體基礎設施、模型伺服器和監控系統等步驟。
- 使用者和客戶:使用者和客戶是指使用機器學習產品的終端使用者和客戶,包括他們的需求、反饋和體驗等方面。
- 產品設計和使用者經驗:產品設計和使用者經驗是指機器學習產品的設計和使用者經驗,包括使用者介面、使用者經驗和產品功能等方面。
這些要素之間存在著複雜的關係,例如資料品質會影響機器學習模型的效能,機器學習模型的效能會影響使用者經驗,基礎設施和佈署會影響模型的可擴充套件性和可靠性等。
資料科學與機器學習產品交付的系統思維
系統思維是一種認識到系統的各個部分之間存在著複雜關係的方法論。它認為,系統的各個部分之間存在著相互依賴和相互影響的關係,改變系統的一個部分可能會對其他部分產生連鎖反應。
在資料科學和機器學習產品交付中,系統思維尤為重要。因為資料科學和機器學習產品交付涉及多個核心要素的協同工作,改變其中一個要素可能會對其他要素產生連鎖反應。例如,改變資料品質可能會影響機器學習模型的效能,改變機器學習模型的效能可能會影響使用者經驗等。
機器學習專案的成功落地並非僅仰賴模型的準確度,更需考量整個系統的協同運作。本文深入剖析了機器學習專案失敗的常見原因,涵蓋了從產品定位、模型佈署到開發環境等多個導向。技術限制的深析指出,缺乏從生產環境中學習的機制、低效的反饋迴圈以及程式碼品質問題,都會顯著影響專案的成功率。此外,道德議題和日常障礙,例如資料偏差和低效能環境,亦是不可忽視的挑戰。文章提出了多種解決方案,包括匯入精益交付、產品思維、敏捷工程、自動化測試、高效能開發環境等,並強調系統思維和跨學科合作的重要性。玄貓認為,機器學習專案的成功關鍵在於將技術能力與商業目標緊密結合,並持續最佳化整個交付流程,方能將機器學習的潛力轉化為實際商業價值。接下來的幾年,隨著 MLOps 的發展和最佳實務的普及,預期機器學習專案的成功率將有所提升,但跨領域的整合能力仍將是決勝關鍵。