作者：Vincent Tatan

編譯：ronghuaiyang

正文共：3392 字 8 圖

預計閱讀時間：10 分鐘

導讀

為什么機器學習是你最大的噩夢。

你最大的機器學習噩夢

【凌晨3點】快來！我們的定價全搞砸了！我們以100美元的價格賣出了13000美元的相機！在亞馬遜的Best Prime Day上，機器學習出現了錯誤。

假設你是亞馬遜的一名ML工程師，您的團隊剛剛發布了一個新的RNN定價模型，該模型可以根據購買趨勢自動設置價格，你已經對該模型進行了無數次的回測和調優。你2年的努力終于產生了結果，預計每年將產生100萬的額外收入。

你太高興了，你預訂了一個昂貴的假期來慶祝。你在去Bahamas的路上，直到你收到…壞消息。

你的ML模型出了問題，所有商品的價格都錯了。你瘋狂地打開集成管理器進行回滾。但為時已晚，系統已經發貨了，你的“前沿ML模型”讓你的公司損失了300萬美元。

第二天，你決定改一下模型的Bug。你測試了模型。它看起來很好。價格分布有變化嗎？數據準備有問題嗎？或者來自最近下游數據的質量有變化？你拼命地絞盡腦汁，還是毫無頭緒。因此，你決定用虛擬機和不同的配置文件隔離每個下游數據，從頭重新構建模型，并逐個測試它們。你無法跟蹤每個版本的更新，直到幾個不眠之夜才解決了這個問題。

在數據或整體有變化的時候，最前沿的ML模型將成為你最大的噩夢

技術債

技術債是代碼實現過程中所作的權宜之計的持續成本。這是由于為早期軟件發布和更快的上市時間提供短期利益而采取的快捷方式造成的。技術債會累加。推遲工作以償還債務會導致成本增加、系統脆弱和創新率降低。

1992年，Ward Cunningham創造了這個術語來解釋產品涉眾的重構需求。對于你們中間那些還不明白的人。技術債是近藤麻理惠的對立面，他說"讓我們把臟衣服掃到床底下，問題就解決了"。

同樣，在人工智能和機器學習領域，我們都會增加技術債。我們喜歡做“忍者修復”，采取諸如硬編碼函數、糟糕的代碼和不負責任的復制-粘貼等捷徑。如果你趕在最后期限前完成任務或交付概念證明(POC)，這些都是非常好的和必要的。但如果沒有去還這些技術債，那就非常危險了。

不是所有的債都是壞的，但不去還債是會有復利的 ——

D Sculley，機器學習系統中的隱藏債務：
https://papers.nips.cc/paper/5656-hidd-techny-debt-in-machine-Learning-ystems.pdf

我們的AI和ML在數據上運行。錯誤的輸入，錯誤的輸出。你使用的特征越多，它就變得越不穩定，尤其是當這些特征依賴于系統的許多部分時。

你的不穩定的機器學習系統

想象一下使用CRM(客戶關系管理)系統構建價格歧視(類似于機票)的定價系統。定價系統的質量將高度依賴于來自CRM的數據，而缺少特征將破壞ML中的所有結果。

現在，假設它通過更互聯的ML和其他系統連接到更多上游流的特征。你的ML模型在最好的情況下是脆弱的，在最壞的情況下是破碎的，從而感染它的下游。

在一個以人工智能為基礎的快速發展的初創公司中，這已經成為一種常態，因為他們瘋狂地趕時間去實現他們的產品，并把它們展示給他們的利益相關者。我曾與一位在AI初創公司工作的朋友交談，他提到他們從未使用過適當的版本控制(Git)、問題跟蹤器(Jira)或任何開發Ops管理工具來開發他們的ML系統。令人震驚的是，許多人在沒有適當的DevOps和技術債務管理的情況下跳進ML/AI的炒作中。這和用牙簽造機器人是一樣的。

對于軟件工程來說，DevOps非常重要。但是對于ML產品，MLOps是不可分割的

4個最大的機器學習Pipelines的錯誤

1) 糾纏

ML系統是帶有數據的機器。通常很難做出孤立的改變(Changing Anything, Changing Everything——CACE)。這適用于特征工程、ML調優、正則化、數據采樣等。

讓我們假設你的定價模式在所有產品上都很有效，除了吸塵器(因為它很糟糕)。你通過提高清潔產品定價的敏感性來固定吸塵器的價格，但你發現你造成了與洗碗機的價格分配不匹配。真空吸塵器的價格分布并不適用于較窄的洗碗機的價格分布。現在需要創建可能影響其他產品的不同規則。

你會認識到數據和見解是相互糾纏的。不同的調優和模型公式將導致難以隔離的一般洞察力的變化。

糾纏的數據和系統會導致很難孤立和調試問題

2) 復雜的Pipelines

AI和ML系統由許多不同的工作流pipelines組成，它們依次負責復雜的工作。ML系統將由許多工程師構建，并與許多不同的系統和數據源互連。

在適當的ML pipelines中，你需要設計許多作業，包括抓取、生成數據、ETL、驗證數據清潔度、交叉驗證、監視性能和部署。很快，你的模型將變得非常復雜。如果沒有合適的工具和操作的標準，跨使用不同語言的多個系統和遺留系統進行簡單的更改將花費數小時。

復雜的pipelines會使你的工程工作緩慢且充滿bug。如果處理不好，你可能會花幾個小時來做一些簡單的修改。

3) 隱含的反饋回路

現實世界的系統最終會影響我們的數據。想象一下，你的銷售代表發布了一項營銷活動來接觸兒童，并積極地將他們包括在你的定價模型所使用的CRM系統中。

ML模型會感知到很大一部分顧客會購買玩具。因此，ML模型對玩具價格會提高，對昂貴產品會過度打折。然而，監控到你的價格飆升，你的競爭對手的定價模式也會自動填補市場的過高價格的玩具。你的系統也會這樣做，惡性循環就出現了。

隱藏的反饋循環給ML系統帶來了麻煩，而由于在ML系統之外相互鏈接數據依賴關系，使得調試更加困難

4) 不穩定的數據依賴

假設你的定價模式依賴于顧客的性別。如果一個男人瀏覽了化妝品，他很可能會買它作為禮物給他的妻子/女朋友，所以支付意愿更高。你的機器學習已經準備好根據性別來決定價格了。

然而，你的業務代表在上游CRM中添加了“性別”特征之外的標簽。如果看到的值不是男性或女性，你的ML系統會崩潰嗎？現在這個型號的化妝品價格是多少？與代碼依賴相比，這是非常脆弱的，因為這意味著當上游系統更新時，并提供未被懷疑的特下一個錯別字征時，你的模型可能會崩潰。

在特征工程和特征標注過程中，數據依賴會導致語義不匹配導致邏輯錯誤和質量下降。

還機器學習的技術債

技術債務是一種痛苦。作為Visa的前數據工程師和谷歌的數據科學家，我必須確保一個適當的可靠的渠道，保持透明和負責任。我需要一個標準的操作來管理機器學習的技術和數據方面，并確保質量不會隨著時間的推移而受到影響。

關于如何最小化MLOps技術債務，有三個小技巧

1) 測試你的代碼和數據

在科技行業，測試是最重要但也最乏味的職位之一。它仍然是非常重要的考慮測試來限制技術債務和確保ML生產質量。在DevOps中，我們了解了兩種類型的測試：單元測試(測試單一功能)和集成測試(測試集成的功能)。然而，在MLOps中，我們需要在服務于生產之前建立一個canary流程來測試ML Pipeline的質量。

這包括測試數據依賴性的可準備性，以識別不可見的數據(想象一下男性/女性性別的例子)。