觀遠AI實戰 | 機器學習系統的工程實踐

觀遠資料發表於2019-01-16

觀遠AI實戰 | 機器學習系統的工程實踐

「觀遠AI實戰」 欄目文章由觀遠演算法天團傾力打造,觀小編整理編輯。這裡將不定期推送關於機器學習資料探勘,特徵重要性等乾貨分享。

本文8千多字,約需要16分鐘閱讀時間。

機器學習作為時下最為火熱的技術之一受到了廣泛的關注。我們每天開啟公眾號都能收到各種前沿進展、論文解讀、最新教程的推送。這些文章中絕大多數內容都跟酷炫的新模型、高大上的數學推導有關。但是Peter Norvig說過,“We don’t have better algorithms. We just have more data.”。在實際機器學習應用中,對最終結果起到決定性作用的往往是精心收集處理的高質量資料。

從表面看好像也不難,但略微深究就會發現機器學習系統與傳統的軟體工程專案有著非常大的差異。除了廣受矚目的模型演算法,良好的工程化思考與實現是最終達到機器學習專案成功的另一大關鍵因素。

谷歌在2015年發表的論文《Hidden Technical Debt in Machine Learning Systems》中就很好的總結了機器學習工程中的各種不佳實踐導致的技術債問題。主要有以下幾種:

系統邊界模糊

在傳統的軟體工程中,一般會進行細緻的設計和抽象,對於系統的各個組成部分進行良好的模組劃分,這樣整個系統的演進和維護都會處於一個比較可控的狀態。但機器學習系統天然就與資料存在一定程度的耦合,加上天然的互動式、實驗性開發方式,很容易就會把資料清洗、特徵工程、模型訓練等模組耦合在一起,牽一髮而動全身,導致後續新增新特徵,做不同的實驗驗證都會變得越來越慢,越來越困難。

資料依賴難以管理

傳統的軟體工程開發中,可以很方便的透過編譯器,靜態分析等手段獲取到程式碼中的各種依賴關係,快速發現不合理的耦合設計,然後藉助於單元測試等手段快速重構改進。在機器學習系統中這類程式碼耦合分析同樣不可或缺。除此之外還多了資料依賴問題。

比如銷售預測系統可能會對接終端POS系統資料,也會引入市場部門的營銷資料,還有倉儲、運輸等等多種資料來源。在大多數情況下這些資料來源都是不同部門維護的,不受資料演算法團隊的控制,指不定哪天就悄悄做了一個變更。如果變更很大,可能在做資料處理或者模型訓練時會直接丟擲錯誤,但大多數情況下你的系統還是能正常執行,而得到的訓練預測結果很可能就有問題了。

在一些複雜業務系統中,這些資料本身還會被加工成各種中間資料集,同時被幾個資料分析預測任務共享,形成複雜的依賴關係網,進一步加大了資料管理的難度。

相關文章