敏捷程式設計是最常用的方法，它使開發團隊能夠將他們的軟體釋出到生產中，經常收集反饋並細化底層需求。為了讓敏捷在實踐中發揮作用，需要允許自動構建修改後的應用程式並將其釋出到生產中的流程——通常稱為持續整合/持續部署，或 CI/CD。CI/CD 透過定期讓實際使用者參與並反覆整合他們的反饋，使軟體團隊能夠構建複雜的應用程式，而不會冒錯過初始需求的風險。

資料科學麵臨著類似的挑戰。儘管資料科學團隊錯過初始要求的風險現在威脅較小（這將在未來十年發生變化），但將資料科學自動部署到生產中所固有的挑戰使許多資料科學專案陷入停頓。首先，將任何東西放入生產系統時往往需要 IT 參與。其次，驗證通常是一項未指定的手動任務（如果它存在的話）。第三，可靠地更新生產資料科學過程通常非常困難，它被視為一個全新的專案。

那資料科學可以從軟體開發中學到什麼？讓我們先看看軟體開發中 CI/CD 的主要方面，然後再深入研究哪些方面有相似之處以及資料科學家需要在哪些方面採取不同的轉變。

軟體開發中的 CI/CD

軟體開發的可重複生產流程已經存在一段時間了，持續整合/持續部署是當今普遍使用的標準。大規模軟體開發通常遵循高度模組化的方法。團隊處理部分程式碼庫並獨立測試這些模組（通常對這些模組使用高度自動化的測試用例）。

在 CI/CD 的持續整合階段，程式碼庫的不同部分被插入在一起，並再次自動地整體測試。理想情況下，這種整合工作經常完成（因此是“連續的”），以便可以立即發現不會影響單個模組但會破壞整個應用程式的副作用。在理想情況下，當我們擁有完整的測試覆蓋率時，我們可以確保幾乎立即捕獲由任何模組更改引起的問題。實際上，沒有任何測試設定是完整的，完整的整合測試可能每晚只執行一次。但我們可以嘗試靠近。

CI/CD 的第二部分，持續部署，是指將新構建的應用程式遷移到生產環境中。每分鐘更新數以萬計的桌面應用程式幾乎不可行（而且部署過程更復雜）。但是對於基於伺服器的應用程式，隨著越來越多的基於雲的工具可用，我們可以更頻繁地推出更改和完成更新；如果我們最終推出了一些有問題的東西，我們也可以快速恢復。部署的應用程式將需要持續監控可能的故障，但如果測試做得好，這往往不是問題。

資料科學中的 CI/CD

資料科學流程往往不是由不同的團隊獨立構建，而是由不同的專家協作構建：資料工程師、機器學習專家和視覺化專家。非常重要的是要注意，資料科學的建立與ML 演算法開發（即軟體工程）無關，而是與 ML 演算法在資料上的應用有關。演算法開發和演算法使用之間的這種差異經常引起混淆。

資料科學中的“整合”也指將底層部分整合在一起。在資料科學中，這種整合意味著確保特定工具包的正確庫與我們的最終資料科學過程捆綁在一起，並且，如果我們的資料科學建立工具允許抽象，則確保這些模組的正確版本也捆綁在一起。

但是，在整合階段，軟體開發和資料科學之間存在很大差異。在軟體開發中，我們構建的是正在部署的應用程式。也許在整合過程中刪除了一些除錯程式碼，但最終產品是在開發過程中構建的。在資料科學中，情況並非如此。

在資料科學建立階段，已經構建了一個複雜的過程，以最佳化組合和轉換資料的方式和資料。這種資料科學建立過程通常會迭代模型的不同型別和引數，甚至可能在每次執行時以不同的方式組合其中的一些模型。整合過程中發生的事情是將這些最佳化步驟的結果組合到資料科學生產過程中。換句話說，在開發過程中，我們生成特徵並訓練模型；在整合過程中，我們將最佳化的特徵生成過程和訓練好的模型結合起來。這種整合包括生產過程。

那麼什麼是資料科學的“持續部署”？如前所述，生產過程——即需要部署的整合結果——不同於資料科學的建立過程。實際部署則類似於軟體部署。我們希望自動替換現有的應用程式或 API 服務，理想情況下使用所有常見的優點，例如正確的版本控制以及在生產過程中捕獲問題時回滾到先前版本的能力。

資料科學生產過程的一個有趣的附加要求是需要持續監控模型效能——因為現實往往會改變！變更檢測對於資料科學流程至關重要。我們需要建立機制來識別我們的生產過程的效能何時惡化。然後我們要麼自動重新訓練和重新部署模型，要麼提醒我們的資料科學團隊注意這個問題，這樣他們就可以建立一個新的資料科學流程，重新觸發資料科學 CI/CD 流程。

因此，雖然監控軟體應用程式往往不會導致自動程式碼更改和重新部署，但這些是資料科學中非常典型的要求。這種自動整合和部署如何涉及（部分）原始驗證和測試設定取決於這些自動更改的複雜性。在資料科學中，測試和監控都是流程本身不可或缺的組成部分。我們較少關注測試我們的建立過程（儘管我們確實希望存檔/版本化解決方案的路徑），我們更關注持續測試生產過程。這裡的測試用例也是“輸入-結果”對，但比測試用例更可能由資料點組成。

這種監控差異也會影響部署前的驗證。在軟體部署中，我們確保我們的應用程式透過測試。對於資料科學生產過程，我們可能需要進行測試以確保仍然預測標準資料點屬於同一類（例如，“好”客戶繼續獲得較高的信用等級）並且仍然捕獲已知異常（例如，已知的產品故障仍被歸類為“故障”）。我們還可能希望確保我們的資料科學過程仍然拒絕處理完全荒謬的模式。簡而言之，我們希望確保引用典型或異常資料點或簡單異常值的測試用例繼續按預期處理。

MLOps、ModelOps 和 XOps

所有這些與 MLOps、ModelOps 或 XOps（正如 Gartner 所說的 DataOps、ModelOps 和 DevOps 的組合）有何關係？提到這些術語的人往往會忽略兩個關鍵事實：首先，資料預處理是生產過程的一部分（而不僅僅是投入生產的“模型”），其次，生產環境中的模型監控通常只是靜態和非反應性。

目前，許多資料科學堆疊僅解決資料科學生命週期的一部分。不僅其他部分必須手動完成，而且在許多情況下，技術之間的差距需要重新編碼，因此生產資料科學過程的全自動提取幾乎是不可能的。在人們意識到真正生產化資料科學不僅僅是將一個包裝精美的模型扔在牆上之前，每當組織試圖可靠地使資料科學成為其運營不可或缺的一部分時，我們將繼續看到失敗。

資料科學過程還有很長的路要走，但 CI/CD 提供了很多可以借鑑的經驗教訓。但是，用於資料科學的 CI/CD 和用於軟體開發的 CI/CD 之間存在兩個根本區別。首先，整合過程中自動建立的“資料科學生產過程”與資料科學團隊建立的不同。其次，生產中的監控可能會導致自動更新和重新部署。也就是說，部署週期可能由檢查生產中資料科學流程的監控流程自動觸發，只有當監控檢測到重大變化時，我們才會回到戰壕並重新啟動整個流程。