初創公司資料科學專案全流程指南，一位資深資料科學家的經驗談

大資料文摘出品

來源：medium

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

無論是管理人員還是創業公司中的不同團隊，都可能會發現資料科學專案與軟體開發之間的差異並不直觀。如果沒有明確的說明與解釋，可能會導致資料科學家與其同行之間的誤解和衝突。

來自學術界（或高度研究型的行業研究小組）的研究人員在初入初創公司或小型公司時可能會面臨各自的挑戰。他們可能會發現將新型輸入（例如產品和業務需求、更嚴格的基礎架構和計算約束以及客戶反饋）納入其研發過程中是很有挑戰性的。

這篇文章的目的是介紹我近年來在同事與我自己的工作過程中發現的特色專案流程。希望這可以幫助資料科學家和與他們合作的同事以其獨特方式來構建資料科學專案。

這個流程是建立在小型初創公司的基礎之上的，一小組資料科學家（通常是一到四位）一次由一個人負責管理短期中型專案。較大的團隊或機器學習優先的深度科技創業公司可能也會覺得這一結構有用，但大部分時候他們的流程會更長，結構也不盡相同。

圖1：初創公司的資料科學專案流程

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

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

• 界定範圍

• 研究

• （模型）開發

• 部署

我會嘗試按順序引導您完成每一項操作。

比起任何其他型別的專案，定義資料科學專案的範圍更重要。

1.1. 產品需求

專案應始終從產品需求開始（即使最初的想法是技術或理論上的）。該產品需求需要在一定程度上由產品/業務/客戶方面的關鍵人員進行背書。產品人員應該知道這個功能應該（大致）最終看起來如何，並且現有客戶或新客戶願意為此付費（或者它將阻止使用者流失/將增加訂閱數量/將推動其他產品的銷售等等）。

產品需求並非專案完整定義，而應該被視為問題或挑戰。例如：“我們的客戶需要一種方法來了解他們如何花費預算”，“我們無法讓老年使用者繼續服用他們的藥物。這導致了客戶流失增加“，或”如果產品能夠預測機場的高峰時段，那麼客戶將願意為此支付更多費用“。

1.2. 初期解決方案構思

在這裡，資料科學家與產品負責人、資料工程師以及任何其他利益相關者一起，為可能的解決方案提出了不同框架草案。這些方案會囊括專案的一般方法（例如，無監督聚類、基於提升樹的分類模型還是概率推理）和要使用的資料（例如，某一資料庫中的特定表、我們尚未監控或記錄的某些特定使用者行為還是外部資料來源）。

這通常還涉及一定程度的資料探索。這裡你不用太深入但一些最基本的資訊都能幫我們定下思考方向。

資料科學家應該帶頭領導這一過程，並且通常應負責提供大多數解決方案的構思。但我會建議所有參與此過程的人都進行方案構思。我曾有幸從後端開發人員、CTO或產品負責人那裡得到了最好的專案解決方案。不要先入為主假設那些並非來自理論背景的人無法參與這一階段的貢獻——新鮮的思想和觀點輸入總是有價值的。

1.3. 資料準備及可得性

團隊現在應該很瞭解解決問題需要哪些資料了（或者至少是初始資料集或資料來源）。因此，在進行下一階段的同時我們應當已經開始準備資料訪問許可權以及資料的使用探索了。

如果在研究階段時間不是很關鍵的話，這有時可能需要將大型資料集從生產資料庫轉儲到對應的臨時/探索環境中，或轉到離線儲存的空間（例如，物件儲存）。有的情況下，它也可能意味著將大型資料從很少訪問的儲存器拉回到表或文件形式，以實現快速查詢和複雜計算。無論如何，這個階段對整個專案都是很有必要的，並且經常會花費比預期更多的時間（因此這是啟動該階段的最佳時機）。

1.4. 範圍和關鍵績效指標

這一階段是關於決定專案範圍和關鍵績效指標。

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

然後應將這些KPI轉換為可衡量的模型指標。如果順利的話，這些將是非常量化的指標，例如“對於任何至少執行一週的廣告，以及任何有超過兩個月曆史資料的廣告客戶，預測其廣告在至少Y％的情況下點選率至少為X％“。但是，在某些情況下，必須使用不那麼精確量化的指標，例如“與原始查詢相比，用生成擴充套件查詢進行主題探索所需的時間將被縮短，並且/或著結果將得到改善”。當模型旨在輔助一些複雜的人體功能時，情況尤其如此。

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

最後，範圍界定在這裡特別重要。因為當研究過程中出現新的可能性或者當下研究的方法只能解決一部分的問題時，研究專案就會容易拖延，並且自然而然地會擴大規模和範圍。

範圍限制1：我發現明確地界定範圍更有成效。例如，如果已經確定基於多臂老虎機問題（Multi-Armed Bandit）的模型是最有效的方法，那麼您可以將專案範圍定義為一個兩週或三週的模型開發及迭代，無論其準確性如何都要部署模型（例如只要它超過了60％）。如果提高準確性是有價值的（在某些情況下它可能沒那麼重要），那麼接下來就可以把開發第二個模型作為一個單獨的專案。

範圍限制2：範圍限制的另一種型別是逐步增加模型的複雜度。例如，第一個專案可能旨在部署一個模型，該模型只需要為客戶服務人員提供一組備用的廣告詞庫和顏色庫；第二個則可能會嘗試建立一個模型，並給出一小組建議，讓戶可以看到自己的選擇；而最終專案可能會嘗試建議一個這樣的模型：突出顯示單個選項，並展示排名略低於它的幾個選項，併為每個選項新增點選率預測和人口覆蓋範圍。

這已經與軟體工程有很大不同，軟體工程通常只會迭代元件以擴大規模，而不是增加其複雜度。

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

1.5範圍和KPI標準

最後，產品負責人需要批准界定的範圍和KPI。資料科學家的工作是確保每個人都瞭解範圍的內容和優先順序順序，以及產品KPI與指導模型開發的指標之間的關係，包括指標與KPI的接近程度。明確說明這一點可以預防出現模型的使用者（包括產品人員和業務人員）在模型已經進入開發或者開發完成後才發現，開發的東西不是自己想要的。

關於範圍界定的一些意見

在許多地方，資料科學家急於開始挖掘資料並探索關於可行性解決方案的高階論文而忽略了界定範圍這一環節。然而，根據我的經驗，這幾乎總是導致因小失大，導致花費數週或數月的時間開發出來的高階模型最終卻無法滿足實際需求，或者無法達標一個具體的KPI。但如果按部就班地環環相扣，這些KPI其實是可以通過一些預先說明來明確定義的。

2.1 資料探索

有趣的部分開始了！在確定範圍之後開始這一階段的主要優勢在於，我們可以通過實際的KPI和模型效能度量指標的指導，來進行資料探索了。

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

到目前為止，資料工程應該已經提供了所需的初始資料集。然而，在此階段通常會發現資料中的一些缺陷，並且可能會將其他資料來源新增到資料集中。資料工程師應該為此做好準備。

最後，雖然此環節與文獻和解決方案綜述階段分離，但它們通常是並行或交替進行的。

2.2 文獻與解決方案綜述

這一階段回顧了學術文獻和現有的程式碼和工具。在探索和開發之間，以及對材料研究深入和快速地有所收穫、分析其使用的可能性之間，平衡同樣重要。

就學術文獻而言，在形式證明和前期文獻等方面研究要多深入，在很大程度上取決於時間限制和專案背景：我們是否要為公司的核心能力打下堅實的基礎，還是隻為了設計一個一次性問題的解決方案？我們是否打算在學術論文中發表關於這一主題的內容？你是否計劃成為該主題的團隊專家？

舉個例子，假設一個資料科學家著手一個專案來幫助銷售部門更好地預測銷售廣告的效果或者客戶流失，他感覺自己對隨機過程理論只是淺薄的理解，但許多類似問題的常見解決方案都是基於這一理論的。

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

在程式碼和實現的情況下，設定的理解深度取決於技術方面，其中一些可能僅在該過程的後期才發現，但其中許多也可以提前預測。

例如，如果生產環境僅支援Java和Scala程式碼為後端使用，並且因此預期解決方案將基於JVM語言，那麼資料科學家將不得不深入研究他在本階段發現的基於Python的實現。即使隨著他們進入模型開發階段，需要將它們轉換為JVM語言。

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

2.3可行性分析

根據可行性解決方案的建議，資料工程師和與之相關的開發人員需要在資料科學家的幫助下，估計該解決方案在生產中的形式和複雜性。產品需求以及建議解決方案的結構和特徵，都應有助於確定恰當的資料儲存空間、處理方式（流與批處理）、擴充套件能力（水平擴充套件和垂直擴充套件），以及粗略地估算成本。

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

2.4 專案範圍 & KPI實施

再次強調，產品經理需要對用技術語言所表述的建議解決方案是否滿足專案範圍及所定KPI進行稽核。易監測的產品表現指標可作為待選的技術標準，包括：響應時間（以及它與計算時間的關係）、資料及偶發中間運算新鮮度（與請求和批計算頻率相關）、特定域模型的域適應難度及成本（成本包括資料成本；多數情況下領域是指客戶域，但也可以是行業、語言、國家等等）、解決方案可模組化性（例如：資料結構和模型結構的特效能夠讓國家級模型分解為其下一層區域模型，或者是指將國家級模型整合為大陸級模型），以及其他各種指標。

3.1.模型開發 & 實驗框架建立

開始模型開發時所做設定的量級和複雜程度都嚴重依賴於基礎設施與資料科學家所能獲取的技術支援。在規模較小的情況下，或者在之前沒有支援過資料科學研究專案的公司，需要做的設定包括資料科學家新建程式碼儲存庫、建立本地Jupyter Notebook伺服器，或者申請更強大的雲機器以供運算。

在別的情況下，設定工作可能從自定義程式碼開始，以供更復雜的功能實現，例如資料和模型版本迭代，或者實驗跟蹤及管理。當一些外部產品或者服務能夠提供這類功能時（這樣的供應商越來越多了），一些設定工作隨其後而至：連線資料來源、分配資源以及設定自定義軟體包。

3.2. 模型開發

所需要的基礎設施到位後，萬眾期待的資料模型開發就可以開始了。模型的開發程度隨公司而異，並且依賴於資料科學家交付模型與產品實際部署的功能或服務之間的關係或區別。發現這些區別的方法有很多種，比如說譜分析。

頻譜分析的一個極端是指萬物皆模型：從資料整合和預處理，經過模型訓練（也許是週期性的）、模型部署、實際服務（可能將規模化）到持續的監督。另一個極端，就是指模型型別和超引數的選擇，常常還有後期資料預加工、特徵生成，這些都被視為模型的一部分。

一個公司在譜分析上的位置取決於很多因素：資料科學家偏好的研究語言、相關的工具庫和開源資源的可獲取性、公司內的生產語言、專門為資料科學家提供相關程式碼支援的資料工程師和開發人員是否存在、資料科學家的技術水平和工作方法。

如果資料科學家擁有全棧技能，並且能夠從資料工程師和開發人員那裡得到足夠的支援——或者另一個選項是，整個資料湖形成、整合、模型服務、規模化以及監測（可能還有版本迭代）的執行和自動化都有足夠的基礎設施支援——模型的定義將更加廣，並且通過模型開發的迭代，能夠實現端到端的解決方案。

這常常意味著首先需要建立完善的工作通道，從資料來源到可規模化的模型，在整個規劃中給資料預加工、特徵生成以及模型本身留著位置。隨後在資料科學這部分進行迭代，同時保證整體範圍與現有基礎設施的承載能力和部署能力契合。

這樣端到端的方法需要花費更長的時間設定，並且每次模型型別和引數的迭代都需要更長的時間測試，但是在後來的生產階段將大大節約時間，賺回成本。

我個人偏向於這種端到端的解決方案，但它在實施和維護的時候的確比較複雜，且並不總是適用。這種情況下，開始和結束階段的一些工作可以放到生產階段去做。

3.3 模型測試

開發模型時，需要使用預先決定的標準對其不同版本不斷進行測試（資料處理工作同步進行），這能夠對模型改善提供一個大致的估計，並且為資料科學家決定何時這個模型能夠滿足整體KPI檢查提供有效輸入。但是需要注意，這個檢測結果會有一些誤導性，比如說在大多數情況下，模型的準確性從50%上升到70%，比從70%上升到90%容易得到。

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

當測試結果顯示模型開發已經脫離軌道，我們常常需要深入調查其內部以及其結果，以找到改進的方案。但有時，表現之間的差距實在太大，所選擇的研究方向中不同的變化都達不到要求——一個方法的錯誤。這也許需要對研究方法做出修正，整個專案將從頭再來。這是資料科學專案最難接受的：推到重來的可能性

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

最終可能的結果之一，當然可能是專案取消。如果資料科學家確定所有的研究方法都已經嘗試過，且產品經理確定根據現有的產品資料無法真正實現一個有效的產品，那麼也許是時候轉向下一個專案了。 不要低估一個無可救藥專案出現的可能性，並且有足夠的勇氣結束掉這個專案：這是快速失敗法的重要的一環。

3.4. KPI檢查

如果事前決定的指標是唯一的KPI，並且在過程中也獲取了所有產品所需要的資料，那麼這一個環節形式大於實質，最終模型將呈現在大家面前，開發階段也宣告結束。但事實上並不總是如此。

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

比如，我們正在試圖解決一個複雜的任務，包括從一個巨大的語料庫中提取相關文件、發起請求。專案組也許將決定嘗試著增加結果集的質量，集中注意力在返回文件的內容和話題的不同之處上，因為客戶可能會覺得這個系統總是傾向於在最優結果中集中極其相似的文件。

模型開發程式中，將逐漸在結果中增加一些可量化內容變化的測試標準，每個模型以前20個返回文件之間的不同程度打分，然後發出一系列測試請求。也許你會測量在一些話題向量空間下文件話題之間的整體差別，或者僅僅只是特殊話題出現的次數，或者顯著組成分佈的平坦度。

甚至當資料科學家決定能夠大幅改善這個指標的模型後，產品經理和客戶服務人員肯定會使用大量測試。他們可能會發現難以量化但並不是不能解決的問題，例如一個模型可能會持續增加結果方差，因為總是推送不相關的話題；或者從不同渠道獲取相似話題的結果（例如新聞文章和推特，兩者使用的語言大不相同）。

當產品負責人確定模型已經達到了這個專案的所有目標（到達令人滿意的地步），那麼專案組可以繼續推進，開始產品化了。

解決方案產品化 & 監控機制

正如前面提到的，這個階段與各公司資料科學的研究方法、模型服務，以及幾個關鍵的技術因素密切相關。

產品化：在研究語言可以直接用於生產的情況下，我們要做的可能是調整模型程式碼使得程式碼更靈活；至於這個過程的複雜程度，則同時取決於對模型語言的分散式計算支援，以及其所使用的程式碼庫和定製的程式碼。

當研發語言和生產語言不同時，這可能還要涉及在生產語言包裝器中將模型程式碼打包，並編譯為二進位制檔案，或是在生產語言中重現相同的邏輯（或者找到這樣的重現方式）。

如果模型中不包含可伸縮資料的提取和處理方案（這是非常普遍的情況），那麼就需要進行額外設定。這意味著，例如，將執行在單核上的python函式轉換為管道流資料，或者將其轉換為定期執行的批量處理作業。在需要多次重複使用資料的情況下，有時需要設定快取層。

監控機制：最後，需要建立一種持續監控模型效能的機制；在極少數情況下，如果生產資料來源穩定，這個步驟可以被跳過，也不會造成大麻煩，但我要說的是，在大多數情況下，並不能十分確定源資料分佈的穩定性。那麼，設定這樣的效能檢查不僅可以幫助我們發現在開發和生產過程中可能遺漏的模型問題，更重要的是，在已經執行的模型的源資料分佈中的任何變化- -通常被稱為協變變化-可以隨時降低一個完美的模型的效能。

以我們的產品為例，那是一個通過檢測皮膚斑點來評估是否推薦使用者去看皮膚科醫生的app。當一款流行的新手機上市時，如果它配備的攝像頭與我們原有資料中的攝像頭引數有很大的不同，協變變化就有可能發生。

4.2. 解決方案部署

如果一切都設定得正確，那麼這個階段就是一句話，按下按鈕，新模型(以及它的任何程式碼)被部署到公司的生產環境中。

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

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

無論是以上哪個場景，都會增加部署模型的複雜性，複雜程度取決於公司的現有情況（例如，您是否已經將一些產品特性部署到客戶的子集中），它們可能需要後端團隊進行大量的額外開發。

當模型要部署到終端產品，如使用者電話或可穿戴裝置上時，這個任務將變得更加複雜，在這種情況下，模型部署可能要放到下一個應用程式中進行或者是作為韌體更新的一部分。

產生偏見：對於資料科學團隊來說，部分部署是一個棘手的問題，因為這種部署必然會帶來偏差，而且模型會持續積累這種偏差，終有一天原來的模型會依據這些具有特性的使用者資料進行工作。不同的產品型別和偏差的特徵，有可能會對模型的效能產生很大的、未知的影響，而且可能對那些用了在此期間積累的資料訓練出來的未來模型產生很大的影響。

例如，在裝置更新方面，那些較早更新應用程式/韌體的使用者往往屬於特定的人群（更年輕、更懂技術、收入更高等等）。

4.3. KPIs check

我在這裡又新增了一個KPI檢查，因為我認為在一個解決方案被認定為效能達標、已解決產品設計之初的問題、滿足客戶需求之前，不能被認定為已交付。

這個步驟是指，在部署之後的幾周內對資料結果進行篩選和分析。然而，當涉及到實際的客戶時，還必須要請產品或銷售人員，讓他們與客戶坐在一起，試圖瞭解模型在實際使用中的效果。

解決方案交付

當使用者和客戶都很滿意，產品人員就也成功地根據模型構建或調整了他們想要的產品。我們就成功了。祝酒，歡呼，舉杯同慶。

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

為模型設定了的健康檢查和持續的效能監控，可能會將我們帶回到專案中。

當某些東西看起來可疑時，通常我們首先檢視資料（例如協變變化），並根據我們所懷疑的能引起問題的各種情況，來模擬模型的反應。根據這些檢查的結果，我們可能需要花幾個小時修改程式碼、或者重新訓練模型、或者重新進入模型開發流程（如本文開頭的圖所示），在一些嚴重的情況下，我們需要返回到研究階段，嘗試完全不同的方向。

本文是對資料科學專案流程的建議。它也是非常具體的，但為了簡單性和可見性並不全面。而且顯然的，它不能一一覆蓋在實踐中存在的各種變體，它代表了我的經驗。

相關報導：

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