機器學習為什麼難以產品化？ - kdnuggests

當您向風險資本募籌投資時，它就是人工智慧；而你在招聘時它就是ML；在實施時，它是線性迴歸；當您除錯時，它是printf()。” — 史瓦茲男爵

2019年7月的一項研究發現，有 87％的資料科學專案沒有投入生產。有許多原因；缺乏領導力的支援、孤立的資料來源以及缺乏協作。除了這些問題之外，還有一些固有方面使資料科學和機器學習專案與其他軟體開發有所不同。

首先，資料科學，尤其是機器學習，存在於概率和不確定性的世界中。基於機器學習的支付欺詐模型的典型輸出如下：“此訂單被欺詐的概率為73％+/- 5％，置信區間為95％”。 而我們在業務方面的同行同事卻生活在確定性世界中，他們“希望阻止所有欺詐性訂單”。在這兩個世界之間進行轉換並非易事。

此外，資料科學專案中存在一種非線性在“傳統”軟體開發中不會發生。在開始構建模型之前，我們不知道模型的效能如何。可能需要一週，三個月的時間，或者可能無法獲得可接受的效能水平。這使得很難將一個好的專案計劃與企業希望看到的時間表和可交付成果同步地放在一起。

最後，在將模型釋出到生產環境時，模型信任的重要性很難被重視。傳統軟體與企業合作以實現模型進入生產時，我們正在進入一個業務領域，這裡有業務領域專家，如果希望使手動流程自動化或替換一組精心設計的業務規則（儘管這些規則並不完美）很容易被信任地實現，因為這些流程和業務規則是由對業務有深刻理解的人建立的(banq注：由DDD構建的)。但是，當你交付一個類似黑盒子的機器學習演算法軟體時，需要說服企業，這些軟體將取代他們目前的工作方式，這是一項多麼艱鉅的任務（因為你都沒有理由說服他們，你對黑盒子的可解釋性都可能不正確）。這個艱難尷尬過程是：讓擁有模型的業務人員承擔這種風險未知的切換帶來的盈虧，而作為資料科學家，我們需要說服他們將他們賴以生存的生計交到我們的模型中，這是何等艱難！(banq注：難度：手工作業->半自動的電腦作業 ->完全自動的電腦作業)

根據我們的經驗，可以通過以下因素成功實現廣泛領域的生產模型化：

1. 用例選擇
2. 業務調整
3. 敏捷（資料科學）開發

用例選擇

機器學習可以解決的問題很多。您在客戶成功，供應鏈，分銷，財務等方面擁有無數用例。

那麼，您將如何決定選擇哪種用例？

• 具有最大業務價值的一個？
• “低垂的果實”能帶來快速的勝利？
• 符合公司戰略目標的一個？

但關鍵的決定因素歸結為一件事：

我們對機器學習是解決此問題的最佳方法的信心有多大？

我們要確保最有效地利用資料科學家的時間。假設存在一個可以產生巨大價值的引人注目的問題，但是一些精心設計的業務規則可以為我們帶來80％的價值。讓資料科學團隊花費幾個月的時間來嘗試獲得額外的10％，這是對資源的最佳利用嗎？可能不會。

使用我們 的資料科學Zen 原則指導我們，我們可以將用例選擇標準分解為以下幾個部分：

1. 我們是否有足夠的乾淨，高質量的資料來對問題進行建模？
2. 我們是否要優化一個明確的客觀標準（或損失函式）？
3. 企業是否準備好將此流程自動化？
4. 它如何適應生產系統？該產品團隊有實施該產品的頻寬嗎？
5. 是否有成功的機器學習實現案例研究，研究論文或其他資源來解決此類問題？
6. 我們需要解決任何偏見或道德問題嗎？

如果對這些問題有任何疑問，我們將重新考慮這是否是我們團隊可以選擇的最佳專案。

無論您要投入什麼資源解決問題，如果沒有正確的用例，成功的機會就很少。

業務組合

確保與專案目標保持一致看起來既簡單又顯而易見。企業希望獲得更準確的預測。您有信心可以擊敗現有系統。

假設您建立了一個出色的模型並設定了一項日常工作來執行它。好吧，事實證明，企業需要能夠全天更新其預測。突然之間，您需要實時服務。

機器學習專案需要業務部門對系統如何工作有一定程度的瞭解。他們需要知道機器學習模型的固有優勢和劣勢，如何處理邊緣情況以及使用了哪些功能。

最重要的是，您需要知道如何使用模型。什麼是預期的輸出？預測將如何使用？如果模型不執行會發生什麼，是否需要回退機制？當您在開始開發之前就知道這些問題的答案時，它可以省去許多頭痛，緊張的討論和深夜的工作。

模型信任的問題再次出現。如果企業不信任您的模型輸出會怎樣？

您可以呈現所需的所有ROC曲線，F1分數和測試集效能，但是如果您的模型做出的前幾個預測不正確，是否有機會進行恢復？以前制定的基本業務規則並不完善，但是企業知道在哪些情況下效果很好，什麼時候效果不好，則可以相應地進行干預。您的模型（希望）會對運營產生影響，如果企業不信任它們，那麼它們將不會被使用。就那麼簡單。

關於模型信任的討論起來確實很不舒服，但必不可少。您需要預先了解業務才能在生產中使用您的模型。至少，需要由雙方決定並簽署帶有績效指標的評估期。

資料科學家和企業之間的期望差異導致許多資料科學專案的結束。 在花了幾個月的時間進行開發之前，需要進行對話 。模型的壽命可能取決於它。

敏捷資料科學發展或...

敏捷開發已成為軟體開發的事實上的標準，但尚未進入資料科學界（尚未）。

資料科學家會就此問題與企業會面，確定要優化的指標，並詢問他們如何獲得資料訪問許可權。然後，他們花了幾個月的時間來建立美觀，堅固的模型，並展示成品。

有效的方法是跳過概念驗證（POC），而這種驗證往往永遠不會離開資料科學家的膝上型電腦，而專注於建立最小可行產品（MVP）。

對於MVP，目標是儘快建立一個端到端的解決方案。您建立資料管道，從基本基線模型（也稱為線性迴歸或邏輯迴歸）開始，然後將預測提供給終端使用者。我們可以使用機器學習找到最佳下降時間的真實示例 。

核心原則 ：

專注於工作軟體

• 不要花時間微調可能永遠不會使用的模型。將其用於建立可行的， 可行的

客戶合作

• 大大縮短了上市時間，因此您的“客戶”將看到來自更復雜系統的輸出。您可以從那裡進行迭代和改進。

應對變化

• 最好在第二週比第二季度找出有效的方法。也許您打算與之整合的內部構建系統無法公開所需的資料。靈活地適應需求，並儘早並經常傳送工作程式碼。

資料科學專案的難點不是建模，通過關注MVP，您可以使工作系統投入生產，並更快地輸出預測。您將更快發現問題，並在數週而不是數月內為您的客戶提供嶄新的閃亮模型。

最後，我們的目標不是為了建立模型而建立模型。我們正在構建一個元件為模型的產品。我們可以從數十年的產品開發中吸取教訓，使我們到達那裡。