[[256173]]

大數(shù)據(jù)文摘出品

來源：medium

編譯：小七、張南星、張秋玥、倪倪、夏雅薇

無論是管理人員還是創(chuàng)業(yè)公司中的不同團隊，都可能會發(fā)現(xiàn)數(shù)據(jù)科學(xué)項目與軟件開發(fā)之間的差異并不直觀。如果沒有明確的說明與解釋，可能會導(dǎo)致數(shù)據(jù)科學(xué)家與其同行之間的誤解和沖突。

來自學(xué)術(shù)界(或高度研究型的行業(yè)研究小組)的研究人員在初入初創(chuàng)公司或小型公司時可能會面臨各自的挑戰(zhàn)。他們可能會發(fā)現(xiàn)將新型輸入(例如產(chǎn)品和業(yè)務(wù)需求、更嚴格的基礎(chǔ)架構(gòu)和計算約束以及客戶反饋)納入其研發(fā)過程中是很有挑戰(zhàn)性的。

這篇文章的目的是介紹我近年來在同事與我自己的工作過程中發(fā)現(xiàn)的特色項目流程。希望這可以幫助數(shù)據(jù)科學(xué)家和與他們合作的同事以其獨特方式來構(gòu)建數(shù)據(jù)科學(xué)項目。

這個流程是建立在小型初創(chuàng)公司的基礎(chǔ)之上的，一小組數(shù)據(jù)科學(xué)家(通常是一到四位)一次由一個人負責(zé)管理短期中型項目。較大的團隊或機器學(xué)習(xí)優(yōu)先的深度科技創(chuàng)業(yè)公司可能也會覺得這一結(jié)構(gòu)有用，但大部分時候他們的流程會更長，結(jié)構(gòu)也不盡相同。

圖1：初創(chuàng)公司的數(shù)據(jù)科學(xué)項目流程

我將這個過程分為三個方面：產(chǎn)品、數(shù)據(jù)科學(xué)和數(shù)據(jù)工程。在許多情況下(我工作過的絕大多數(shù)地方)可能壓根沒有數(shù)據(jù)工程師來履行這些職責(zé)。這時數(shù)據(jù)科學(xué)家通常會與開發(fā)人員合作解決這些問題。或者，數(shù)據(jù)科學(xué)家可能會(自己)完成這些準備工作——他們就是傳說中的：全棧數(shù)據(jù)科學(xué)家!✨🦄✨。根據(jù)所處環(huán)境的不同，你可以隨時用數(shù)據(jù)科學(xué)家來替代數(shù)據(jù)工程師。

在時間軸上，我將這個過程分解為四個不同的階段：

• 界定范圍
• 研究
• (模型)開發(fā)
• 部署

我會嘗試按順序引導(dǎo)您完成每一項操作。

一、范圍界定

比起任何其他類型的項目，定義數(shù)據(jù)科學(xué)項目的范圍更重要。

[[256174]]

1. 產(chǎn)品需求

項目應(yīng)始終從產(chǎn)品需求開始(即使最初的想法是技術(shù)或理論上的)。該產(chǎn)品需求需要在一定程度上由產(chǎn)品/業(yè)務(wù)/客戶方面的關(guān)鍵人員進行背書。產(chǎn)品人員應(yīng)該知道這個功能應(yīng)該(大致)最終看起來如何，并且現(xiàn)有客戶或新客戶愿意為此付費(或者它將阻止用戶流失/將增加訂閱數(shù)量/將推動其他產(chǎn)品的銷售等等)。

產(chǎn)品需求并非項目完整定義，而應(yīng)該被視為問題或挑戰(zhàn)。例如：“我們的客戶需要一種方法來了解他們?nèi)绾位ㄙM預(yù)算”，“我們無法讓老年用戶繼續(xù)服用他們的藥物。這導(dǎo)致了客戶流失增加“，或”如果產(chǎn)品能夠預(yù)測機場的高峰時段，那么客戶將愿意為此支付更多費用“。

2. 初期解決方案構(gòu)思

在這里，數(shù)據(jù)科學(xué)家與產(chǎn)品負責(zé)人、數(shù)據(jù)工程師以及任何其他利益相關(guān)者一起，為可能的解決方案提出了不同框架草案。這些方案會囊括項目的一般方法(例如，無監(jiān)督聚類、基于提升樹的分類模型還是概率推理)和要使用的數(shù)據(jù)(例如，某一數(shù)據(jù)庫中的特定表、我們尚未監(jiān)控或記錄的某些特定用戶行為還是外部數(shù)據(jù)源)。

這通常還涉及一定程度的數(shù)據(jù)探索。這里你不用太深入但一些最基本的信息都能幫我們定下思考方向。

數(shù)據(jù)科學(xué)家應(yīng)該帶頭領(lǐng)導(dǎo)這一過程，并且通常應(yīng)負責(zé)提供大多數(shù)解決方案的構(gòu)思。但我會建議所有參與此過程的人都進行方案構(gòu)思。我曾有幸從后端開發(fā)人員、CTO或產(chǎn)品負責(zé)人那里得到了最好的項目解決方案。不要先入為主假設(shè)那些并非來自理論背景的人無法參與這一階段的貢獻——新鮮的思想和觀點輸入總是有價值的。

3. 數(shù)據(jù)準備及可得性

團隊現(xiàn)在應(yīng)該很了解解決問題需要哪些數(shù)據(jù)了(或者至少是初始數(shù)據(jù)集或數(shù)據(jù)來源)。因此，在進行下一階段的同時我們應(yīng)當已經(jīng)開始準備數(shù)據(jù)訪問權(quán)限以及數(shù)據(jù)的使用探索了。

如果在研究階段時間不是很關(guān)鍵的話，這有時可能需要將大型數(shù)據(jù)集從生產(chǎn)數(shù)據(jù)庫轉(zhuǎn)儲到對應(yīng)的臨時/探索環(huán)境中，或轉(zhuǎn)到離線存儲的空間(例如，對象存儲)。有的情況下，它也可能意味著將大型數(shù)據(jù)從很少訪問的存儲器拉回到表或文檔形式，以實現(xiàn)快速查詢和復(fù)雜計算。無論如何，這個階段對整個項目都是很有必要的，并且經(jīng)常會花費比預(yù)期更多的時間(因此這是啟動該階段的最佳時機)。

4. 范圍和關(guān)鍵績效指標

這一階段是關(guān)于決定項目范圍和關(guān)鍵績效指標。

我們應(yīng)首先在產(chǎn)品術(shù)語中定義KPI，但要比之前更詳細。例如，就上述三個產(chǎn)品需求而言，它們可能變成“客戶現(xiàn)在可以使用包含每個類別的CTR統(tǒng)計數(shù)據(jù)和預(yù)測值的數(shù)據(jù)儀表板”，或“65歲以上用戶錯過服用藥物的天數(shù)將在接下來的兩個季度中減少至少10%”，或”每周客戶將收到其機場高峰時間段的預(yù)測，區(qū)間精度至少為一小時，估計誤差至最多為±50%“。

然后應(yīng)將這些KPI轉(zhuǎn)換為可衡量的模型指標。如果順利的話，這些將是非常量化的指標，例如“對于任何至少運行一周的廣告，以及任何有超過兩個月歷史數(shù)據(jù)的廣告客戶，預(yù)測其廣告在至少Y%的情況下點擊率至少為X%“。但是，在某些情況下，必須使用不那么精確量化的指標，例如“與原始查詢相比，用生成擴展查詢進行主題探索所需的時間將被縮短，并且/或著結(jié)果將得到改善”。當模型旨在輔助一些復(fù)雜的人體功能時，情況尤其如此。

從技術(shù)上講，即使這些指標可以被非常嚴格地定義(并且在學(xué)術(shù)研究中，它們通常是如此)，但是如果資源和時間受限，我們可以通過使用人工反饋來近似估計。在這種情況下，每次反饋迭代可能需要更長的時間，因此我們通常會嘗試尋找其他硬度量指標來指導(dǎo)我們完成大多數(shù)即將進行的研究迭代。往往是幾次迭代或者需要重大改變時才進行一次比較大規(guī)模的反饋收集。

最后，范圍界定在這里特別重要。因為當研究過程中出現(xiàn)新的可能性或者當下研究的方法只能解決一部分的問題時，研究項目就會容易拖延，并且自然而然地會擴大規(guī)模和范圍。

• 范圍限制1：我發(fā)現(xiàn)明確地界定范圍更有成效。例如，如果已經(jīng)確定基于多臂老虎機問題(Multi-Armed Bandit)的模型是最有效的方法，那么您可以將項目范圍定義為一個兩周或三周的模型開發(fā)及迭代，無論其準確性如何都要部署模型(例如只要它超過了60%)。如果提高準確性是有價值的(在某些情況下它可能沒那么重要)，那么接下來就可以把開發(fā)第二個模型作為一個單獨的項目。
• 范圍限制2：范圍限制的另一種類型是逐步增加模型的復(fù)雜度。例如，第一個項目可能旨在部署一個模型，該模型只需要為客戶服務(wù)人員提供一組備用的廣告詞庫和顏色庫;第二個則可能會嘗試建立一個模型，并給出一小組建議，讓戶可以看到自己的選擇;而最終項目可能會嘗試建議一個這樣的模型：突出顯示單個選項，并展示排名略低于它的幾個選項，并為每個選項添加點擊率預(yù)測和人口覆蓋范圍。

這已經(jīng)與軟件工程有很大不同，軟件工程通常只會迭代組件以擴大規(guī)模，而不是增加其復(fù)雜度。

然而，產(chǎn)品價值度量函數(shù)可能是一個階梯函數(shù)，這意味著任何指標未達到X值的模型對客戶來說都沒用;在這些情況下，我們更傾向于使用迭代，直到收斂到最佳閾值。然而，雖然在某些情況下這個X值可能非常高，但我相信無論是產(chǎn)品人還是業(yè)務(wù)員，亦或是數(shù)據(jù)科學(xué)家都傾向于高估這一要求，就像很容易得出如下結(jié)論：任何準確度低于95%(95%只是舉例)的東西就沒有任何價值且賣不出去。然而，在許多情況下，雖然對產(chǎn)品假設(shè)的嚴格審核和挑戰(zhàn)有益于打造出有價值的產(chǎn)品，但這些產(chǎn)品在技術(shù)指標上要求可能沒那么苛刻(至少對于產(chǎn)品的第一次迭代而言是如此)。

5. 范圍和KPI標準

最后，產(chǎn)品負責(zé)人需要批準界定的范圍和KPI。數(shù)據(jù)科學(xué)家的工作是確保每個人都了解范圍的內(nèi)容和優(yōu)先級順序，以及產(chǎn)品KPI與指導(dǎo)模型開發(fā)的指標之間的關(guān)系，包括指標與KPI的接近程度。明確說明這一點可以預(yù)防出現(xiàn)模型的使用者(包括產(chǎn)品人員和業(yè)務(wù)人員)在模型已經(jīng)進入開發(fā)或者開發(fā)完成后才發(fā)現(xiàn)，開發(fā)的東西不是自己想要的。

關(guān)于范圍界定的一些意見：

在許多地方，數(shù)據(jù)科學(xué)家急于開始挖掘數(shù)據(jù)并探索關(guān)于可行性解決方案的高端論文而忽略了界定范圍這一環(huán)節(jié)。然而，根據(jù)我的經(jīng)驗，這幾乎總是導(dǎo)致因小失大，導(dǎo)致花費數(shù)周或數(shù)月的時間開發(fā)出來的高端模型最終卻無法滿足實際需求，或者無法達標一個具體的KPI。但如果按部就班地環(huán)環(huán)相扣，這些KPI其實是可以通過一些預(yù)先說明來明確定義的。

二、研究階段

[[256175]]

1. 數(shù)據(jù)探索

有趣的部分開始了!在確定范圍之后開始這一階段的主要優(yōu)勢在于，我們可以通過實際的KPI和模型性能度量指標的指導(dǎo)，來進行數(shù)據(jù)探索了。

在探索和開發(fā)之間總是要尋求平衡。即使在有明確KPI的情況下，探索一些看似無關(guān)的內(nèi)容也是很有價值的。

到目前為止，數(shù)據(jù)工程應(yīng)該已經(jīng)提供了所需的初始數(shù)據(jù)集。然而，在此階段通常會發(fā)現(xiàn)數(shù)據(jù)中的一些缺陷，并且可能會將其他數(shù)據(jù)源添加到數(shù)據(jù)集中。數(shù)據(jù)工程師應(yīng)該為此做好準備。

最后，雖然此環(huán)節(jié)與文獻和解決方案綜述階段分離，但它們通常是并行或交替進行的。

2. 文獻與解決方案綜述

這一階段回顧了學(xué)術(shù)文獻和現(xiàn)有的代碼和工具。在探索和開發(fā)之間，以及對材料研究深入和快速地有所收獲、分析其使用的可能性之間，平衡同樣重要。

就學(xué)術(shù)文獻而言，在形式證明和前期文獻等方面研究要多深入，在很大程度上取決于時間限制和項目背景：我們是否要為公司的核心能力打下堅實的基礎(chǔ)，還是只為了設(shè)計一個一次性問題的解決方案?我們是否打算在學(xué)術(shù)論文中發(fā)表關(guān)于這一主題的內(nèi)容?你是否計劃成為該主題的團隊專家?

舉個例子，假設(shè)一個數(shù)據(jù)科學(xué)家著手一個項目來幫助銷售部門更好地預(yù)測銷售廣告的效果或者客戶流失，他感覺自己對隨機過程理論只是淺薄的理解，但許多類似問題的常見解決方案都是基于這一理論的。

雖然是同樣的情況，但當所處環(huán)境不同時，反應(yīng)可能非常不同。如果他在一個算法交易公司工作，他理應(yīng)深入研究這個理論，甚至可能參加一個關(guān)于這個主題的在線課程，因為這與他的工作非常相關(guān);然而，如果他是為一家專注于肝臟X射線掃描中自動腫瘤檢測的醫(yī)學(xué)影像公司工作，我認為他應(yīng)該會快速找到適用的解決方案并繼續(xù)進行下一步。

在代碼和實現(xiàn)的情況下，設(shè)定的理解深度取決于技術(shù)方面，其中一些可能僅在該過程的后期才發(fā)現(xiàn)，但其中許多也可以提前預(yù)測。

例如，如果生產(chǎn)環(huán)境僅支持Java和Scala代碼為后端使用，并且因此預(yù)期解決方案將基于JVM語言，那么數(shù)據(jù)科學(xué)家將不得不深入研究他在本階段發(fā)現(xiàn)的基于Python的實現(xiàn)。即使隨著他們進入模型開發(fā)階段，需要將它們轉(zhuǎn)換為JVM語言。

最后，在回顧文獻時，請記住，不應(yīng)向團隊的其他成員只展示所選擇的一個研究方向(或幾個方向)。相反，也應(yīng)該對該領(lǐng)域和所有已經(jīng)驗證的解決方案進行簡要回顧，并解釋每個方向的優(yōu)點和缺點以及選擇理由。

3. 可行性分析

根據(jù)可行性解決方案的建議，數(shù)據(jù)工程師和與之相關(guān)的開發(fā)人員需要在數(shù)據(jù)科學(xué)家的幫助下，估計該解決方案在生產(chǎn)中的形式和復(fù)雜性。產(chǎn)品需求以及建議解決方案的結(jié)構(gòu)和特征，都應(yīng)有助于確定恰當?shù)臄?shù)據(jù)存儲空間、處理方式(流與批處理)、擴展能力(水平擴展和垂直擴展)，以及粗略地估算成本。

這是在此階段要執(zhí)行的一個重要檢查，因為某些數(shù)據(jù)和軟件工程可以與模型開發(fā)并行。此外，就工程而言，給出的建議解決方案可能是不充分的或成本太高，在這種情況下，應(yīng)盡快查明和處理。在模型開發(fā)開始之前考慮技術(shù)問題時，可以使用在研究階段獲得的知識，來提出可能更適合技術(shù)約束的替代解決方案。這就是研究階段還需對解決方案前景進行一些概述的另一個原因，而不僅僅是針對單個解決方案。

4. 項目范圍 & KPI實施

再次強調(diào)，產(chǎn)品經(jīng)理需要對用技術(shù)語言所表述的建議解決方案是否滿足項目范圍及所定KPI進行審核。易監(jiān)測的產(chǎn)品表現(xiàn)指標可作為待選的技術(shù)標準，包括：響應(yīng)時間(以及它與計算時間的關(guān)系)、數(shù)據(jù)及偶發(fā)中間運算新鮮度(與請求和批計算頻率相關(guān))、特定域模型的域適應(yīng)難度及成本(成本包括數(shù)據(jù)成本;多數(shù)情況下領(lǐng)域是指客戶域，但也可以是行業(yè)、語言、國家等等)、解決方案可模塊化性(例如：數(shù)據(jù)結(jié)構(gòu)和模型結(jié)構(gòu)的特性能夠讓國家級模型分解為其下一層區(qū)域模型，或者是指將國家級模型整合為大陸級模型)，以及其他各種指標。

三、開發(fā)階段

[[256176]]

1. 模型開發(fā) & 實驗框架建立

開始模型開發(fā)時所做設(shè)置的量級和復(fù)雜程度都嚴重依賴于基礎(chǔ)設(shè)施與數(shù)據(jù)科學(xué)家所能獲取的技術(shù)支持。在規(guī)模較小的情況下，或者在之前沒有支持過數(shù)據(jù)科學(xué)研究項目的公司，需要做的設(shè)置包括數(shù)據(jù)科學(xué)家新建代碼存儲庫、建立本地Jupyter Notebook服務(wù)器，或者申請更強大的云機器以供運算。

在別的情況下，設(shè)置工作可能從自定義代碼開始，以供更復(fù)雜的功能實現(xiàn)，例如數(shù)據(jù)和模型版本迭代，或者實驗跟蹤及管理。當一些外部產(chǎn)品或者服務(wù)能夠提供這類功能時(這樣的供應(yīng)商越來越多了)，一些設(shè)置工作隨其后而至：連接數(shù)據(jù)源、分配資源以及設(shè)置自定義軟件包。

2. 模型開發(fā)

所需要的基礎(chǔ)設(shè)施到位后，萬眾期待的數(shù)據(jù)模型開發(fā)就可以開始了。模型的開發(fā)程度隨公司而異，并且依賴于數(shù)據(jù)科學(xué)家交付模型與產(chǎn)品實際部署的功能或服務(wù)之間的關(guān)系或區(qū)別。發(fā)現(xiàn)這些區(qū)別的方法有很多種，比如說譜分析。

頻譜分析的一個極端是指萬物皆模型：從數(shù)據(jù)整合和預(yù)處理，經(jīng)過模型訓(xùn)練(也許是周期性的)、模型部署、實際服務(wù)(可能將規(guī)模化)到持續(xù)的監(jiān)督。另一個極端，就是指模型類型和超參數(shù)的選擇，常常還有后期數(shù)據(jù)預(yù)加工、特征生成，這些都被視為模型的一部分。

一個公司在譜分析上的位置取決于很多因素：數(shù)據(jù)科學(xué)家偏好的研究語言、相關(guān)的工具庫和開源資源的可獲取性、公司內(nèi)的生產(chǎn)語言、專門為數(shù)據(jù)科學(xué)家提供相關(guān)代碼支持的數(shù)據(jù)工程師和開發(fā)人員是否存在、數(shù)據(jù)科學(xué)家的技術(shù)水平和工作方法。

如果數(shù)據(jù)科學(xué)家擁有全棧技能，并且能夠從數(shù)據(jù)工程師和開發(fā)人員那里得到足夠的支持——或者另一個選項是，整個數(shù)據(jù)湖形成、整合、模型服務(wù)、規(guī)模化以及監(jiān)測(可能還有版本迭代)的運行和自動化都有足夠的基礎(chǔ)設(shè)施支持——模型的定義將更加廣，并且通過模型開發(fā)的迭代，能夠?qū)崿F(xiàn)端到端的解決方案。

這常常意味著首先需要建立完善的工作通道，從數(shù)據(jù)源到可規(guī)模化的模型，在整個規(guī)劃中給數(shù)據(jù)預(yù)加工、特征生成以及模型本身留著位置。隨后在數(shù)據(jù)科學(xué)這部分進行迭代，同時保證整體范圍與現(xiàn)有基礎(chǔ)設(shè)施的承載能力和部署能力契合。

這樣端到端的方法需要花費更長的時間設(shè)置，并且每次模型類型和參數(shù)的迭代都需要更長的時間測試，但是在后來的生產(chǎn)階段將大大節(jié)約時間，賺回成本。

我個人偏向于這種端到端的解決方案，但它在實施和維護的時候的確比較復(fù)雜，且并不總是適用。這種情況下，開始和結(jié)束階段的一些工作可以放到生產(chǎn)階段去做。

3. 模型測試

開發(fā)模型時，需要使用預(yù)先決定的標準對其不同版本不斷進行測試(數(shù)據(jù)處理工作同步進行)，這能夠?qū)δＰ透纳铺峁┮粋€大致的估計，并且為數(shù)據(jù)科學(xué)家決定何時這個模型能夠滿足整體KPI檢查提供有效輸入。但是需要注意，這個檢測結(jié)果會有一些誤導(dǎo)性，比如說在大多數(shù)情況下，模型的準確性從50%上升到70%，比從70%上升到90%容易得到。

圖2：模型的失敗將導(dǎo)致迭代，但方法論的錯誤將讓你從頭來過

當測試結(jié)果顯示模型開發(fā)已經(jīng)脫離軌道，我們常常需要深入調(diào)查其內(nèi)部以及其結(jié)果，以找到改進的方案。但有時，表現(xiàn)之間的差距實在太大，所選擇的研究方向中不同的變化都達不到要求——一個方法的錯誤。這也許需要對研究方法做出修正，整個項目將從頭再來。這是數(shù)據(jù)科學(xué)項目最難接受的：推到重來的可能性

另一個方法論錯誤的后果就是目標的改變。如果足夠幸運，那么也許只是在產(chǎn)品層面的微小變動，只需要把目標更簡單的表述出來就好。例如，舍棄掉生成文章的一句話總結(jié)功能，而是從文章中找出最能夠總結(jié)內(nèi)容的句子。

最終可能的結(jié)果之一，當然可能是項目取消。如果數(shù)據(jù)科學(xué)家確定所有的研究方法都已經(jīng)嘗試過，且產(chǎn)品經(jīng)理確定根據(jù)現(xiàn)有的產(chǎn)品數(shù)據(jù)無法真正實現(xiàn)一個有效的產(chǎn)品，那么也許是時候轉(zhuǎn)向下一個項目了。 不要低估一個無可救藥項目出現(xiàn)的可能性，并且有足夠的勇氣結(jié)束掉這個項目：這是快速失敗法的重要的一環(huán)。

4. KPI檢查

如果事前決定的指標是唯一的KPI，并且在過程中也獲取了所有產(chǎn)品所需要的數(shù)據(jù)，那么這一個環(huán)節(jié)形式大于實質(zhì)，最終模型將呈現(xiàn)在大家面前，開發(fā)階段也宣告結(jié)束。但事實上并不總是如此。

大多數(shù)情況下，事前確定的只是對真實產(chǎn)品需求的近似推理，但并不是最佳選項。因此，這個階段將是一個很好的機會，使用一些無法自動檢測的軟性指標來看產(chǎn)品是否滿足要求。如果這一步通過，那么產(chǎn)品和客戶滿意都能夠達到。如果你能另外直接檢測產(chǎn)品對于一個用戶產(chǎn)生的實際價值 ——例如，和一個設(shè)計合伙人共同工作——那么測試結(jié)果將是你對模型迭代最好的輸入。

比如，我們正在試圖解決一個復(fù)雜的任務(wù)，包括從一個巨大的語料庫中提取相關(guān)文檔、發(fā)起請求。項目組也許將決定嘗試著增加結(jié)果集的質(zhì)量，集中注意力在返回文檔的內(nèi)容和話題的不同之處上，因為客戶可能會覺得這個系統(tǒng)總是傾向于在最優(yōu)結(jié)果中集中極其相似的文檔。

模型開發(fā)進程中，將逐漸在結(jié)果中增加一些可量化內(nèi)容變化的測試標準，每個模型以前20個返回文檔之間的不同程度打分，然后發(fā)出一系列測試請求。也許你會測量在一些話題向量空間下文檔話題之間的整體差別，或者僅僅只是特殊話題出現(xiàn)的次數(shù)，或者顯著組成分布的平坦度。

甚至當數(shù)據(jù)科學(xué)家決定能夠大幅改善這個指標的模型后，產(chǎn)品經(jīng)理和客戶服務(wù)人員肯定會使用大量測試。他們可能會發(fā)現(xiàn)難以量化但并不是不能解決的問題，例如一個模型可能會持續(xù)增加結(jié)果方差，因為總是推送不相關(guān)的話題;或者從不同渠道獲取相似話題的結(jié)果(例如新聞文章和推特，兩者使用的語言大不相同)。

當產(chǎn)品負責(zé)人確定模型已經(jīng)達到了這個項目的所有目標(到達令人滿意的地步)，那么項目組可以繼續(xù)推進，開始產(chǎn)品化了。

四、開發(fā)階段

[[256177]]

1. 解決方案產(chǎn)品化 & 監(jiān)控機制

正如前面提到的，這個階段與各公司數(shù)據(jù)科學(xué)的研究方法、模型服務(wù)，以及幾個關(guān)鍵的技術(shù)因素密切相關(guān)。

產(chǎn)品化：在研究語言可以直接用于生產(chǎn)的情況下，我們要做的可能是調(diào)整模型代碼使得代碼更靈活;至于這個過程的復(fù)雜程度，則同時取決于對模型語言的分布式計算支持，以及其所使用的代碼庫和定制的代碼。

當研發(fā)語言和生產(chǎn)語言不同時，這可能還要涉及在生產(chǎn)語言包裝器中將模型代碼打包，并編譯為二進制文件，或是在生產(chǎn)語言中重現(xiàn)相同的邏輯(或者找到這樣的重現(xiàn)方式)。

如果模型中不包含可伸縮數(shù)據(jù)的提取和處理方案(這是非常普遍的情況)，那么就需要進行額外設(shè)置。這意味著，例如，將運行在單核上的python函數(shù)轉(zhuǎn)換為管道流數(shù)據(jù)，或者將其轉(zhuǎn)換為定期運行的批量處理作業(yè)。在需要多次重復(fù)使用數(shù)據(jù)的情況下，有時需要設(shè)置緩存層。

監(jiān)控機制：最后，需要建立一種持續(xù)監(jiān)控模型性能的機制;在極少數(shù)情況下，如果生產(chǎn)數(shù)據(jù)源穩(wěn)定，這個步驟可以被跳過，也不會造成大麻煩，但我要說的是，在大多數(shù)情況下，并不能十分確定源數(shù)據(jù)分布的穩(wěn)定性。那么，設(shè)置這樣的性能檢查不僅可以幫助我們發(fā)現(xiàn)在開發(fā)和生產(chǎn)過程中可能遺漏的模型問題，更重要的是，在已經(jīng)運行的模型的源數(shù)據(jù)分布中的任何變化- -通常被稱為協(xié)變變化-可以隨時降低一個完美的模型的性能。

以我們的產(chǎn)品為例，那是一個通過檢測皮膚斑點來評估是否推薦用戶去看皮膚科醫(yī)生的app。當一款流行的新手機上市時，如果它配備的攝像頭與我們原有數(shù)據(jù)中的攝像頭參數(shù)有很大的不同，協(xié)變變化就有可能發(fā)生。

2. 解決方案部署

如果一切都設(shè)置得正確，那么這個階段就是一句話，按下按鈕，新模型(以及它的任何代碼)被部署到公司的生產(chǎn)環(huán)境中。

部分部署：然而，有時為了測試模型的有效性(例如，減少用戶流失，或者是增加每個用戶每月的平均支出)，可能只需要對部分用戶/客戶進行部署。這樣就可以用可測量的KPI，直接對兩個(或多個)用戶庫之間的影響進行比較。

您可能不想將模型部署到每個人身上的另一個原因是，該模型的開發(fā)是為了滿足特定客戶或一組客戶的需求，或者它是高級功能或特定計劃的一部分。或者，模型可能對每個用戶或客戶都有附加一些個性化元素;這些可以通過一個考慮了客戶特征的單一模型來實現(xiàn)，但有時也需要為每個客戶訓(xùn)練和部署不同的模型。

無論是以上哪個場景，都會增加部署模型的復(fù)雜性，復(fù)雜程度取決于公司的現(xiàn)有情況(例如，您是否已經(jīng)將一些產(chǎn)品特性部署到客戶的子集中)，它們可能需要后端團隊進行大量的額外開發(fā)。

當模型要部署到終端產(chǎn)品，如用戶電話或可穿戴設(shè)備上時，這個任務(wù)將變得更加復(fù)雜，在這種情況下，模型部署可能要放到下一個應(yīng)用程序中進行或者是作為固件更新的一部分。

產(chǎn)生偏見：對于數(shù)據(jù)科學(xué)團隊來說，部分部署是一個棘手的問題，因為這種部署必然會帶來偏差，而且模型會持續(xù)積累這種偏差，終有一天原來的模型會依據(jù)這些具有特性的用戶數(shù)據(jù)進行工作。不同的產(chǎn)品類型和偏差的特征，有可能會對模型的性能產(chǎn)生很大的、未知的影響，而且可能對那些用了在此期間積累的數(shù)據(jù)訓(xùn)練出來的未來模型產(chǎn)生很大的影響。

例如，在設(shè)備更新方面，那些較早更新應(yīng)用程序/固件的用戶往往屬于特定的人群(更年輕、更懂技術(shù)、收入更高等等)。

3. KPIs check

我在這里又添加了一個KPI檢查，因為我認為在一個解決方案被認定為性能達標、已解決產(chǎn)品設(shè)計之初的問題、滿足客戶需求之前，不能被認定為已交付。

這個步驟是指，在部署之后的幾周內(nèi)對數(shù)據(jù)結(jié)果進行篩選和分析。然而，當涉及到實際的客戶時，還必須要請產(chǎn)品或銷售人員，讓他們與客戶坐在一起，試圖了解模型在實際使用中的效果。

4. 解決方案交付

當用戶和客戶都很滿意，產(chǎn)品人員就也成功地根據(jù)模型構(gòu)建或調(diào)整了他們想要的產(chǎn)品。我們就成功了。祝酒，歡呼，舉杯同慶。

解決方案交付，我認為此時項目已經(jīng)完成。然而，它仍以一種特殊的方式存在著——維護。

維護

為模型設(shè)置了的健康檢查和持續(xù)的性能監(jiān)控，可能會將我們帶回到項目中。

當某些東西看起來可疑時，通常我們首先查看數(shù)據(jù)(例如協(xié)變變化)，并根據(jù)我們所懷疑的能引起問題的各種情況，來模擬模型的反應(yīng)。根據(jù)這些檢查的結(jié)果，我們可能需要花幾個小時修改代碼、或者重新訓(xùn)練模型、或者重新進入模型開發(fā)流程(如本文開頭的圖所示)，在一些嚴重的情況下，我們需要返回到研究階段，嘗試完全不同的方向。

本文是對數(shù)據(jù)科學(xué)項目流程的建議。它也是非常具體的，但為了簡單性和可見性并不全面。而且顯然的，它不能一一覆蓋在實踐中存在的各種變體，它代表了我的經(jīng)驗。

相關(guān)報道：

https://towardsdatascience.com/data-science-project-flow-for-startups-282a93d4508d

【本文是51CTO專欄機構(gòu)大數(shù)據(jù)文摘的原創(chuàng)譯文，微信公眾號“大數(shù)據(jù)文摘（ id: BigDataDigest）”】

     

戳這里，看該作者更多好文