 |
VOOZH | about |
|
VOOZH | about |
典型的數據科學工作流程如下：第一步永遠是找出問題，然後收集相關數據，可能來自於資料庫或者開發記錄。視你所在機構的數據可用性而定，這可能就已經非常困難了，你必須先弄清楚誰能讓你有權訪問那些數據，然後弄清楚誰能確保你順利拿到那些數據。得到數據後，接著對其進行預處理，提取數據特徵，以期獲取有用信息，幫助解決問題。
從小處著手的主要原因在於，這個過程不是只進行一次，而是會疊代很多次。從本質上來說，數據科學項目本身是探究性的，所得結果在某種程度上是開放性的。目標可能很明確，但在剛開始的時候，常常不知道哪些數據可用，或者可用數據是否適合。畢竟，選擇採用機器學習這種方法，已經意味著你不能妄想只靠編寫一套程序就能解決問題。你必須採用一種數據驅動的方法。
在實踐中，這兩個不同之處意味著開發人員和數據科學家在一起工作時常常會出問題。標準的軟體工程實踐並不適合數據科學家的探究性工作模式，因為兩者致力於的目標不同。代碼檢查和分支—檢查—整合這套有序的工作流程，在數據科學家這邊完全行不通，只會拖慢他們的進度。同理，把探究性模式應用於開發系統也行不通。
我已經大致剖析了把數據科學引入軟體開發的典型架構。大家必須弄明白一個關鍵的概念，那就是這類架構需要不斷適應和改進(就像使用實時數據的所有數據驅動項目一樣)。能夠迅速疊代、嘗試新方法和在A/B測試中用實時數據測試結果，這些是最重要的。
原文翻譯：
本文作者MikioBraun在歐洲最大的時尚電商平台之一Zalando領導推薦和搜索功能交付團隊。Mikio擁有機器學習專業的博士學位，在搜索領域工作多年，
現在專注於搜索結果在電商領域的高效利用工作。
在過去幾年裡，數據科學已經被各行各業廣泛接納。數據科學起初在更大程度上來說是一個研究課題，源於科學家們為了理解人類智能、打造人工智慧而做出的努力。後來，事實證明它能帶來真正的商業價值。
舉個例子。Zalando公司是歐洲最大的時裝零售商之一，就在大量地利用數據科學來提供數據驅動的推薦和其他功能。在很多地方，包括產品頁面、目錄頁面、廣告郵件和重定向頁面上，都會為用戶提供「推薦」這樣的後端服務。
生成推薦
有很多種方法可以生成數據驅動的推薦。協同過濾程序會收集整個用戶群在產品瀏覽、願望清單和購買等方面的用戶行為，然後處理這些信息，確定哪些商品擁有類似的用戶模式。這種方法的優點在於計算機不必了解商品本身的任何信息，缺點是必須要有龐大的流量，不然無法獲得關於商品的充足信息。另一種方法只著眼於商品的各種屬性，比如推薦同一品牌或者顏色相近的其他商品。當然，有很多途徑可以延伸使用這些方法或者把它們綜合運用起來。
還有更簡單的一些方法，基本只通過計數來生成推薦，但在實際操作上，這類方法的複雜度幾乎沒有上限。例如，就個性化推薦而言，我們一直在研究對從各種角度對商品進行排序的機器學習排名方法。上圖顯示的是用於優化這一方法的成本函數，主要是為了說明數據科學有時具有的複雜程度。該函數採用包含正則項的對偶加權排名指標。雖然在數學上非常精確，但也非常抽象。這種方法不僅能用於電子商務領域的推薦，還能用於解決各種各樣的排名問題，前提是排名對象具備適合的特徵。
把數學方法引入產業界
那麼，如何將上面提到的這類非常正規的數學方法引入產品開發?數據科學和工程之間又是怎樣對接的?哪種組織和團隊架構最適合採用這種方法?這些是非常重要且合理的問題，因為它們決定了對一名數據科學家或者一整支數據科學家團隊的投資到最後是否真能取得回報。
在後文中，我將根據我個人從事機器學習研究工作和在Zalando公司領導數支數據科學家和工程師團隊的實戰經驗，對這些問題進行探討。
了解數據科學和軟體開發的區別
讓我們先著眼於數據科學系統和後端開發系統，看看如何才能把這兩個系統結合起來。
典型的數據科學工作流程如下：第一步永遠是找出問題，然後收集相關數據，可能來自於資料庫或者開發記錄。視你所在機構的數據可用性而定，這可能就已經非常困難了，你必須先弄清楚誰能讓你有權訪問那些數據，然後弄清楚誰能確保你順利拿到那些數據。得到數據後，接著對其進行預處理，提取數據特徵，以期獲取有用信息，幫助解決問題。將這些特徵輸入機器學習算法，再將得出的模型用測試數據進行評估，以預測模型用於未來數據的效果。
這一管道通常會一次性建設完畢，往往由數據科學家使用Python等程式語言，手動完成各個步驟。Python有很多的數據分析庫和數據可視化庫。根據數據量的大小，也可能使用Spark或Hadoop這樣的分布式計算系統，但數據科學家往往先從數據的一個子集著手。
為什麼先從小處著手?
從小處著手的主要原因在於，這個過程不是只進行一次，而是會疊代很多次。從本質上來說，數據科學項目本身是探究性的，所得結果在某種程度上是開放性的。目標可能很明確，但在剛開始的時候，常常不知道哪些數據可用，或者可用數據是否適合。畢竟，選擇採用機器學習這種方法，已經意味著你不能妄想只靠編寫一套程序就能解決問題。你必須採用一種數據驅動的方法。
這意味著該管道將會疊代和改進很多次，嘗試不同的數據特徵、不同的預處理方式、不同的機器學習算法，甚至可能回到原點，添加更多的數據源。
整個過程本質上是疊代的，常常具有高度的探究性。在模型表現看起來比較像樣後，就該準備用現實數據來測試了。這時便輪到開發系統出場。
區分開發系統和數據科學
開發系統和數據科學系統之間的最主要區別可能在於，開發系統是持續運行的實時系統。數據必須得到處理，模型必須不斷更新。輸入事件也常常被用來計算點擊率等關鍵績效指標。模型經常每隔幾小時就使用可用數據重新訓練一次，然後加載入開發系統中，通過採用REST架構的接口提供數據
出於性能和穩定性的考慮，那些系統常常用Java之類的程式語言編寫。
如果把開發系統和數據科學系統放在一起比較，就會得出以上這張圖。右上方是數據科學系統，使用Python這樣的程式語言或者Spark這樣的分布式計算系統，但通常包含手動觸發的一次性計算和為了優化系統而進行的疊代。其結果是一個模型，它本質上就是一堆描述學習模型的數字。然後，開發系統會加載該模型。開發系統會是一套更為傳統的的企業系統，用Java這樣的語言編寫，並且保持持續運行。
當然，上圖有點簡化。實際上，模型必須反覆訓練，因此還必須將某個版本的數據處理管道嵌入開發系統，以便時不時地更新模型。
請注意圖中的A/B測試，它會在實時系統中執行，對應的是數據科學系統中的評估步驟。通常來說，A/B測試和模型評估不完全具有可比性，因為在沒有真正把推薦商品顯示給用戶看的情況下，A/B測試很難模擬出線下推薦的效果，但A/B測試應該有助於模型性能的提升。
最後要注意的是，這整個系統不是建立後就「完事」。如同必須先疊代和精調數據科學系統的數據分析管道一樣，整個實時系統也需要隨著數據分布情況的變化進行疊代，並且為數據分析打開新的可能性。我認為，這種「外部疊代」既是最大的挑戰，也是最重要的挑戰，因為它將決定你能否持續改善系統，保證你最初對數據科學的投資不會付諸東流。
數據科學家和開發人員：合作模式
到目前為止，我們主要討論了各系統在軟體開發中的典型情況。人們對開發系統真正能夠達成的穩健度和高效性的期望高低不一。有時，直接部署一套用Python編寫的模型就足夠了，但探究部分和開發部分通常就此分道揚鑣。
如何協調數據科學家和開發人員之間的合作?這是一個重大的挑戰。從某種程度上來說，「數據科學家」還是一個新職業，但他們所做的工作明顯有別於開發人員所做的工作。這兩者很容易在溝通上存在誤解和障礙。
數據科學家的工作通常具有高度的探究性。數據科學項目常常始於一個模糊的目標，或者有關哪種數據和方法可用的設想。你往往只能試驗你的想法，洞悉你的數據。數據科學家會編寫大量代碼，但其中很大一部分代碼都是為了測試想法，並不會直接用在最終的解決方案中。
而開發人員把更多的精力用於編寫代碼。他們的目標就是編寫系統，打造具有所需功能性的程序。開發人員有時也從事探究性的工作，比如原型建造、概念驗證或者基準測試，但他們的主要工作就是寫代碼。
這些不同之處也在代碼日漸開發出來的方式上表現得非常明顯。開發人員常常儘量遵循一個明確定義的過程，其中涉及為獨立的工作流創建分支程序，接著對各個分支進行檢查，然後再併入主幹。開發人員可以並行工作，但需要把已核准的分支集成到主幹程序中，然後再從主幹上建立新的分支，如此往復。這一切是為了確保主幹能以有序的方式完成開發。
正如我上文所說，數據科學家也會編寫大量代碼，但這些代碼常常是為了探索和嘗試新的想法。所以，你可能會先開發出一個1.0版，但並不太符合你的預期，接著便有了2.0版，進而產生2.1和2.2版。然後你放棄了這個方向，又做出了3.0和3.1版。這時你意識到，如果把2.1版和3.1版的一些想法結合起來，就能得到更好的解決方案，因此有了3.3和3.4版，這便是最終的解決方案。
有意思的是，你會很想保留那些走進死胡同的版本，因為以後你可能還會再用到它們。你也可能會把其中一些令你滿意的成果加入一個日漸壯大的工具箱，它就像是你個人的機器學習庫。開發人員喜歡刪除「死亡代碼」(也是因為他們知道以後隨時都能重新恢復那些代碼，而且他們知道如何快速地做到這一點)，而數據科學家則喜歡保留代碼，以防萬一。
在實踐中，這兩個不同之處意味著開發人員和數據科學家在一起工作時常常會出問題。標準的軟體工程實踐並不適合數據科學家的探究性工作模式，因為兩者致力於的目標不同。代碼檢查和分支—檢查—整合這套有序的工作流程，在數據科學家這邊完全行不通，只會拖慢他們的進度。同理，把探究性模式應用於開發系統也行不通。
那麼，我們如何讓數據科學家和開發人員之間的合作對雙方都最有利?第一反應可能是把二者分開。例如，徹底分開代碼庫，讓數據科學家獨立工作，制定規範文檔，然後由開發人員加以實現。這種方法可行，但效率很低，而且容易出錯，因為重新實現可能引入錯誤，尤其是在開發人員不熟悉數據分析算法的情況下。另外，進行外部疊代以改善整個系統，也取決於開發人員是否有足夠的能力來實現數據科學家的規範文檔。
幸好，很多數據科學家也想成為更好的軟體工程師，很多軟體工程師也有心成為更好的數據科學家。因此，我們已經開始嘗試更加直接一點、有助於加快整個過程的合作模式。
例如，數據科學家和開發人員的代碼庫仍然可以分開，但數據科學家可通過一個明確定義的接口，把他們的算法和一部分的開發系統鉤連起來。顯然，與開發系統進行通信的代碼必須遵守更嚴格的軟體開發實踐，但仍然由數據科學家負責。這樣一來，他們不僅能在內部迅速疊代，還能在開發系統中疊代。
這種架構模式的具體實現方式的一種，便是採用微服務架構，並讓開發系統能夠查詢數據科學家的微服務以獲得建議。這樣一來，原本被數據科學家用於離線分析的整個管道也能同時用於執行A/B測試，甚至可在無需開發人員重新實現所有代碼的狀態下直接添加進開發系統。這也更強調數據科學家的軟體工程技能，但我們發現擁有那套技能的數據科學家越來越多。為了反映這一事實，Zalando公司已經把數據科學家的頭銜改為了「研究工程師(數據科學方向)」。
依靠像這樣的方法，數據科學家能夠迅速行動，用離線數據疊代，遵從軟體開發的具體要求疊代，整個團隊能把穩定的數據分析解決方案逐漸移植到開發系統中。
不斷適應和改進
到此為止，我已經大致剖析了把數據科學引入軟體開發的典型架構。大家必須弄明白一個關鍵的概念，那就是這類架構需要不斷適應和改進(就像使用實時數據的所有數據驅動項目一樣)。能夠迅速疊代、嘗試新方法和在A/B測試中用實時數據測試結果，這些是最重要的。
根據我的經驗來看，讓數據科學家和開發人員各自為政是無法做到這一點的。但同時，必須承認他們的工作模式不同，因為他們的目標不同：數據科學家的工作更具探究性，而開發人員更關注於打造軟體和系統。如果讓雙方以一種最適合這些目標的方式工作，並在他們之間定義一個明確的接口，就有可能把雙方結合在一起，迅速地嘗試新方法。這要求數據科學家具備更多的軟體工程技能，或者至少要有能夠架通兩個世界的工程師提供支持。
原文:What is hardcore data science—in practice?
