轉自 | AI前線
作者 | Shay Palachy
譯者 | Sambodhi
編輯 | Vincent
導讀：數據科學對初創公司有多重要？在初創公司中，數據科學項目流程有什麼說道嗎？作爲在數據科學領域身經百戰的老將 Shay Palachy，日前接受了一家名爲 BigPanda 的初創公司的邀請，讓他就該公司的數據科學項目發表自己的看法。作者在這篇文章中爲那些想打造一直屬於自己的數據科學團隊的創始人提供了一些非常有價值的建議。
最近，一家名爲 BigPanda 的初創公司邀請我對數據科學項目的結構和流程發表自己的看法，這讓我思考是什麼讓它們獨一無二。初創公司的經理和不同團隊可能會發現，數據科學項目和軟件開發之間存在差異，這種差異並不那麼直觀，而且令人困惑。如果沒有明確的說明和解釋，這些根本差異可能會引起數據科學家和同事之間的誤解和衝突。
分別來說，來自學術界（或高度研究型的行業研究小組）的研究人員在進入初創公司或小型公司時，可能會面臨各自的挑戰。他們可能會發現，將新類型的輸入（如產品和業務需求、更緊密的基礎設施和計算限制以及客戶反饋）納入他們的研究和開發過程中具有挑戰性。
這篇文章的目的是介紹我近年來在同事和我自己的工作過程中可識別的特殊項目流程。希望這可以幫助數據科學家和他的同伴們用發揮出他們獨特性的方式來構建數據科學項目。
這個流程是建立在小型初創公司的基礎之上的，一小組數據科學家（通常是一到四位）一次由一個人負責管理短期中型項目。較大的團隊或機器學習優先的深度科技創業公司可能也會覺得這一結構有用，但大部分時候他們的流程會更長，結構也不盡相同。
圖 1：初創公司的數據科學項目流程
我將縱向的流程分爲三個部分：產品，數據科學和數據工程。在許多情況下（包括我工作過的大多數地方），可能並沒有數據工程師來執行這些職責。在這種情況下，數據科學家通常負責與開發人員合作，幫助他解決這些方面的問題（如果他是全能大神：全棧數據科學家，那麼他自己就可以憑一己之力解決所有的問題）。因此，根據你的環境，每當提到數據工程師時，你都可以用數據科學家來取代之。
在橫向的時間軸上，我將這個過程分爲四個不同的階段：
範圍界定
研究
（模型）開發
部署
我試着按順序把每一個階段都講一遍。
定義數據科學項目的範圍比任何其他類型的項目都重要。
項目應始終從產品需求開始（即使最初想法是技術或理論上的），需要在某種程度上通過產品 / 業務 / 客戶成功人士進行驗證。產品人員應該知曉這個特徵大致最終應該是什麼樣子的，並且現有或新客戶願意爲此付費（防止客戶流失 / 推動訂閱 / 推動其他產品的銷售 / 等等）。
產品需求並非完整的項目定義，而應該作爲一個問題或挑戰。例如：“我們的客戶需要一種方法來了解如何使用他們的預算”或 “我們沒有設法讓老年客戶繼續服藥，這就增加了客戶的流失率” 或“客戶會爲一種能夠預測他們運營的機場高峯時段的產品支付更多的費用”。
這就是數據科學家與產品負責人、數據工程師和任何其他相關者一起，爲可能的解決方案提出不同的草圖的地方。這意味着通用方法 (例如，無監督聚類 vs 基於提升樹的分類 vs 概率推理）和要使用的數據（如，我們數據庫中的特定表，或者我們尚未監控或保存的某些特定用戶行爲，或外部數據源）。
這通常還涉及一定程度的數據探索。但在這步你不能深入研究，但任何有希望的“唾手可得的成果”都可以幫助打開思路和想法。
數據科學家應該領導這個進程，並且通常負責提供解決方案的思路，但我強烈建議你在構思解決方案時動員所有對該解決方案產生影響的人; 我有幸從後端開發人員、CTO 或產品負責人那兒得到了一個項目的最佳解決方案。不要認爲不同的、不太注重理論的背景會使人們無法參與這一階段，須知額外的想法和觀點總是有價值的。
團隊現在應該很瞭解解決問題需要哪些數據了（或者至少是初始數據集或數據來源）。因此，在進行下一階段的同時我們應當已經開始準備數據訪問權限以及數據的使用探索了。
如果在研究階段中，時間可用性不是很關鍵的話，那麼這有時可能需要將大型數據及從生產數據庫轉儲到臨時 / 探索的對應方，或者轉儲到較冷的存儲（如對象存儲）中。相反，它可能意味着將大型數據轉儲從非常冷的存儲拉回到表或文檔形式，以實現快速查詢和複雜的計算。無論如何，這一階段都需要在研究階段開始，並且經常會耗費比預期更多的時間，因此，這是啓動研究階段的最佳時機。
這一階段是關於共同決定項目的範圍和 KPI（Key Performance Indicators，關鍵績效指標）。
KPI 應當首先從產品的角度來定義，但要比之前更詳細；例如，就上述三種產品需求而言，它們可能會變成 “客戶現在可以使用帶有 CTR 統計數據和每個類別圖像的儀表板”，或 “在未來兩個季度內，65 歲以上的用戶錯過的服藥天數至少減少 10%”，或 “客戶都會收到每週的機場高峯時間的預測，預測的力度至少爲一個小時，近似值至少爲 ±50%”。
然後應將這些KPI轉換爲可衡量的模型指標。如果順利的話，這些將是非常量化的指標，例如“對於任何至少運行一週的廣告，以及任何有超過兩個月曆史數據的廣告客戶，預測其廣告在至少Y％的情況下點擊率至少爲X％“。但是，在某些情況下，必須使用不那麼精確量化的指標，例如“與原始查詢相比，用生成擴展查詢進行主題探索所需的時間將被縮短，並且/或着結果將得到改善”。當模型旨在輔助一些複雜的人體功能時，情況尤其如此。
從技術上講，即使這些指標也可以非常嚴格地定義（在學術研究中通常亦如此），但是根據資源和時間的限制，我們可能會通過人工反饋來近似地對它們進行定義。在這種情況下，每次反饋迭代可能需要花費更長的時間，因此，我們通常會試圖尋找額外的硬指標來指導我們完成大部分即將進行的研究迭代，往往是幾次迭代或者需要重大改變時才進行一次比較大規模的反饋收集。
最後，範圍界定在這裏特別重要。因爲當研究過程中出現新的可能性或者當下研究的方法只能解決一部分的問題時，研究項目就會容易拖延，並且自然而然地會擴大規模和範圍。
範圍界定 1：我發現明確地界定範圍更有成效。例如，如果已經確定基於多臂×××問題（Multi-Armed Bandit）的模型是最有效的方法，那麼您可以將項目範圍定義爲一個兩週或三週的模型開發及迭代，無論其準確性如何都要部署模型（例如只要它超過了60％）。如果提高準確性是有價值的（在某些情況下它可能沒那麼重要），那麼接下來就可以把開發第二個模型作爲一個單獨的項目。
範圍界定 2：範圍限制的另一個變體是使用越來越複雜的複雜性；例如，第一個項目的目標可能就是部署一個模型，這個模型只需爲你自己的客戶成功人士提供相當多的候選廣告措辭和顏色變化，第二種方法可能會嘗試構建一個模型，提供一組更少的建議，讓客戶能夠看到自己；最終的項目可能會嘗試突出顯示單個選項的模型，低於它的數量，併爲每個變化增加 CTR 預測和人口覆蓋範圍。
這已經與軟件工程有很大不同，軟件工程通常只會迭代組件以擴大規模，而不是增加其複雜度。
然而，產品價值度量函數可能是一個階梯函數，這意味着任何指標未達到X值的模型對客戶來說都沒用；在這些情況下，我們更傾向於使用迭代，直到收斂到最佳閾值。然而，雖然在某些情況下這個X值可能非常高，但我相信無論是產品人還是業務員，亦或是數據科學家都傾向於高估這一要求，就像很容易得出如下結論：任何準確度低於95％（95%只是舉例）的東西就沒有任何價值且賣不出去。然而，在許多情況下，雖然對產品假設的嚴格審覈和挑戰有益於打造出有價值的產品，但這些產品在技術指標上要求可能沒那麼苛刻（至少對於產品的第一次迭代而言是如此）。
最後，產品負責人需要批准界定的範圍和KPI。數據科學家的工作是確保每個人都瞭解範圍的內容和優先級順序，以及產品KPI與指導模型開發的指標之間的關係，包括指標與KPI的接近程度。明確說明這一點可以預防出現模型的使用者（包括產品人員和業務人員）在模型已經進入開發或者開發完成後才發現，開發的東西不是自己想要的。
這個階段在很多地方都被忽略了，數據科學家往往開始挖掘數據並探索關於可能解決方案的論文；然而根據我的經驗，這幾乎總是最槽糕的。跳過這一階段可能會導致花費數週或數月的時間來開發很酷的模型，而這些模型最終無法滿足實際需求；或者在一個非常特定的 KPI 中失敗，而這個 KPI 本可以通過某些預先設想來明確定義。
有趣的部分開始了！在確定範圍之後開始這一階段的主要優勢在於，我們可以通過實際的KPI和模型性能度量指標的指導，來進行數據探索了。
像往常一樣，在探索和開發之間要取得平衡；即時有明確的 KPI，在某種程度上探索一些看似無關的途徑也是有價值的。
到目前爲止，數據工程應該可以得到所需的初始數據集。但是，在這一階段中，經常會發現探索數據中的一些缺陷，並且可能會將其他數據源添加到工作集中。數據工程師應爲此做好準備。
最後，雖然此處與文獻和解決方案評審階段分開，但它們通常是並行完成的，或者是交替進行。
這一階段回顧了學術文獻和現有的代碼和工具。在探索和開發之間，以及對材料研究深入和快速地有所收穫、分析其使用的可能性之間，平衡同樣重要
就學術文獻而言，選擇在形式化證明和之前的文獻等方面有多深入，在很大程度上取決於時間限制和項目背景：我們是在爲公司的核心能力打下堅實的基礎，還是在爲一次性問題設計解決方案？我們打算在學術論文中發表關於這一主題的研究成果嗎？你打算成爲這個主題的團隊專家嗎？
例如，假設一個數據科學家着手一個項目，幫助銷售部門更好地預測潛在產量或客戶流失率，他覺得自己對隨機過程理論的理解很膚淺，而這些問題的許多常見解決方案都是監理在這個理論的基礎之上。對這種感覺的適當反應可能非常不同；如果他在一家算法交易公司工作，那麼他肯定會深入研究這一理論，甚至可能會參加一門關於這個主題的在線課程，因爲這與他的工作非常相關；另一方面，如果他在一家醫學影像公司工作，該公司專注於肝臟 X 射線掃描中腫瘤自動檢測，我認爲他應該會盡快找到一個可行的解決方案，然後繼續前進。
在代碼和實現的情況下，要達到的理解深度取決於技術方面，其中一些可能在過程的後期纔會被發現，但是，其中也有許多是可以提前預測的。
例如，如果生產環境僅支持爲後端使用部署 Java 和 Scala 代碼，那麼解決方案預計會以 JVM 語言提供，即使在這個研究階段，數據科學家也必須深入研究基於 Python 的實現，因爲隨着它們進入模型的開發階段，需要將它們轉換爲 JVM 語言。
最後，在回顧文獻時，請記住，不僅要向團隊的其他成員展示選定的研究方向（或幾個方向）。相反，應在作出選擇的同時，對該領域和所有經過審查的解決辦法作一次簡短的審查，解釋每一個方向的優點和缺點以及選擇的理由。
根據可行性解決方案的建議，數據工程師和與之相關的開發人員需要在數據科學家的幫助下，估計該解決方案在生產中的形式和複雜性。產品需求以及建議解決方案的結構和特徵，都應有助於確定恰當的數據存儲空間、處理方式（流與批處理）、擴展能力（水平擴展和垂直擴展），以及粗略地估算成本。
這是在這一階段執行的一個重要檢查，因爲一些數據和軟件工程可以與模型開發的同時開始。此外，從工程角度來看，建議的解決方案可能存在不足或者成本太高，在這種情況下，應儘快確定並處理。在模型開發開始之前考慮技術問題時，在研究階段獲得的只是可以用來建議更適合技術約束的替代解決方案。這也是爲什麼在研究階段還必須對解決方案前景進行一些概述，而不僅僅是在單個解決方案方向的另一個原因。
再次強調，產品經理需要對用技術語言所表述的建議解決方案是否滿足項目範圍及所定KPI進行審覈。易監測的產品表現指標可作爲待選的技術標準，包括：響應時間（以及它與計算時間的關係）、數據及偶發中間運算新鮮度（與請求和批計算頻率相關）、特定域模型的域適應難度及成本（成本包括數據成本；多數情況下領域是指客戶域，但也可以是行業、語言、國家等等）、解決方案可模塊化性（例如：數據結構和模型結構的特性能夠讓國家級模型分解爲其下一層區域模型，或者是指將國家級模型整合爲大陸級模型），以及其他各種指標。
開始模型開發時所做設置的量級和複雜程度都嚴重依賴於基礎設施與數據科學家所能獲取的技術支持。在規模較小的情況下，或者在之前沒有支持過數據科學研究項目的公司，需要做的設置包括數據科學家新建代碼存儲庫、建立本地Jupyter Notebook服務器，或者申請更強大的雲機器以供運算。
在別的情況下，設置工作可能從自定義代碼開始，以供更復雜的功能實現，例如數據和模型版本迭代，或者實驗跟蹤及管理。當一些外部產品或者服務能夠提供這類功能時（這樣的供應商越來越多了），一些設置工作隨其後而至：連接數據源、分配資源以及設置自定義軟件包。
所需要的基礎設施到位後，萬衆期待的數據模型開發就可以開始了。模型的開發程度隨公司而異，並且依賴於數據科學家交付模型與產品實際部署的功能或服務之間的關係或區別。發現這些區別的方法有很多種，比如說譜分析。
頻譜分析的一個極端是指萬物皆模型：從數據整合和預處理，經過模型訓練（也許是週期性的）、模型部署、實際服務（可能將規模化）到持續的監督。另一個極端，就是指模型類型和超參數的選擇，常常還有後期數據預加工、特徵生成，這些都被視爲模型的一部分。
一個公司在譜分析上的位置取決於很多因素：數據科學家偏好的研究語言、相關的工具庫和開源資源的可獲取性、公司內的生產語言、專門爲數據科學家提供相關代碼支持的數據工程師和開發人員是否存在、數據科學家的技術水平和工作方法。
如果公司有一個非常全棧的數據科學家，再加上專門的數據工程師和開發人員的足夠支持，或者，有足夠的現有技術設施，專門用於數據湖和聚合、模型服務、擴展和監控（以及可能還有版本控制）的操作和自動化。可以對模型進行更廣泛的定義，並且在模型開發的大部分迭代中都可以使用端到端解決方案。
這常常意味着首先需要建立完善的工作通道，從數據源到可規模化的模型，在整個規劃中給數據預加工、特徵生成以及模型本身留着位置。隨後在數據科學這部分進行迭代，同時保證整體範圍與現有基礎設施的承載能力和部署能力契合。
這樣端到端的方法需要花費更長的時間設置，並且每次模型類型和參數的迭代都需要更長的時間測試，但是在後來的生產階段將大大節約時間，賺回成本。
我個人偏向於這種端到端的解決方案，但它在實施和維護的時候的確比較複雜，且並不總是適用。這種情況下，開始和結束階段的一些工作可以放到生產階段去做。
開發模型時，需要使用預先決定的標準對其不同版本不斷進行測試（數據處理工作同步進行），這能夠對模型改善提供一個大致的估計，並且爲數據科學家決定何時這個模型能夠滿足整體KPI檢查提供有效輸入。但是需要注意，這個檢測結果會有一些誤導性，比如說在大多數情況下，模型的準確性從50%上升到70%，比從70%上升到90%容易得到。
圖 2：模型失敗需要迭代，但是方法失敗可能會讓你回到研究階段重來
當測試結果顯示模型開發已經脫離軌道，我們常常需要深入調查其內部以及其結果，以找到改進的方案。但有時，表現之間的差距實在太大，所選擇的研究方向中不同的變化都達不到要求——一個方法的錯誤。這也許需要對研究方法做出修正，整個項目將從頭再來。這是數據科學項目最難接受的：推到重來的可能性
另一個方法論錯誤的後果就是目標的改變。如果足夠幸運，那麼也許只是在產品層面的微小變動，只需要把目標更簡單的表述出來就好。
例如，捨棄掉生成文章的一句話總結功能，而是從文章中找出最能夠總結內容的句子。
最終可能的結果當然是項目取消，如果數據科學家確信已經探索了所有的研究途徑，並且產品經理確信無法圍繞現有績效構建有效產品，那麼可能是時候轉向另一個項目了。不要低估了確定一個無法挽救的項目的能力和做出結束項目的決定的勇氣，這是快速失敗方法論的關鍵部分。
如果事前決定的指標是唯一的KPI，並且在過程中也獲取了所有產品所需要的數據，那麼這一個環節形式大於實質，最終模型將呈現在大家面前，開發階段也宣告結束。但事實上並不總是如此。
大多數情況下，事前確定的只是對真實產品需求的近似推理，但並不是最佳選項。因此，這個階段將是一個很好的機會，使用一些無法自動檢測的軟性指標來看產品是否滿足要求。如果這一步通過，那麼產品和客戶滿意都能夠達到。如果你能另外直接檢測產品對於一個用戶產生的實際價值 ——例如，和一個設計合夥人共同工作——那麼測試結果將是你對模型迭代最好的輸入。
比如，我們正在試圖解決一個複雜的任務，包括從一個巨大的語料庫中提取相關文檔、發起請求。項目組也許將決定嘗試着增加結果集的質量，集中注意力在返回文檔的內容和話題的不同之處上，因爲客戶可能會覺得這個系統總是傾向於在最優結果中集中極其相似的文檔。
模型開發進程中，將逐漸在結果中增加一些可量化內容變化的測試標準，每個模型以前20個返回文檔之間的不同程度打分，然後發出一系列測試請求。也許你會測量在一些話題向量空間下文檔話題之間的整體差別，或者僅僅只是特殊話題出現的次數，或者顯著組成分佈的平坦度。
即使數據科學家確定了一個能顯著改進這一指標的模型，產品和客戶的成功人士也一定要查看測試查詢的重要樣本的實際結果；他們可能會發現難以量化但有可能解決的問題，例如推高一些反覆出現的非相關主題來增加結果差異的模型，或者通過包括來自不同來源的類似主題的結果（如，新聞文章 vs 推文，它們使用了非常不同的語言）。
當產品負責人確定模型已經達到了這個項目的所有目標（到達令人滿意的地步），那麼項目組可以繼續推進，開始產品化了。
正如前面提到的，這個階段與各公司數據科學的研究方法、模型服務，以及幾個關鍵的技術因素密切相關。
產品化：在研究語言可用於生產環境的情況下，這一階段可能需要調整模型代碼，使其以可擴展的方式工作；這一過程有多簡單或有多複雜，取決於模型語言的分佈式計算支持，以及所使用的特定庫和自定義代碼。
當研發語言和生產語言不同時，這可能還要涉及在生產語言包裝器中將模型代碼打包，並編譯爲二進制文件，或是在生產語言中重現相同的邏輯（或者找到這樣的重現方式）。
如果模型中不包含可伸縮數據的提取和處理方案（這是非常普遍的情況），那麼就需要進行額外設置。這意味着，例如，將運行在單核上的python函數轉換爲管道流數據，或者將其轉換爲定期運行的批量處理作業。在需要多次重複使用數據的情況下，有時需要設置緩存層。
監控機制：最後，需要建立一種持續監控模型性能的機制；在極少數情況下，如果生產數據源穩定，這個步驟可以被跳過，也不會造成×××煩，但我要說的是，在大多數情況下，並不能十分確定源數據分佈的穩定性。那麼，設置這樣的性能檢查不僅可以幫助我們發現在開發和生產過程中可能遺漏的模型問題，更重要的是，在已經運行的模型的源數據分佈中的任何變化- -通常被稱爲協變變化-可以隨時降低一個完美的模型的性能。
以我們的產品爲例，那是一個通過檢測皮膚斑點來評估是否推薦用戶去看皮膚科醫生的app。當一款流行的新手機上市時，如果它配備的攝像頭與我們原有數據中的攝像頭參數有很大的不同，協變變化就有可能發生。
如果一切都設置得正確，那麼這個階段就是一句話，按下按鈕，新模型(以及它的任何代碼)被部署到公司的生產環境中。
部分部署：然而，有時爲了測試模型的有效性（例如，減少用戶流失，或者是增加每個用戶每月的平均支出），可能只需要對部分用戶/客戶進行部署。這樣就可以用可測量的KPI，直接對兩個（或多個）用戶庫之間的影響進行比較。
您可能不想將模型部署到每個人身上的另一個原因是，該模型的開發是爲了滿足特定客戶或一組客戶的需求，或者它是高級功能或特定計劃的一部分。或者，模型可能對每個用戶或客戶都有附加一些個性化元素；這些可以通過一個考慮了客戶特徵的單一模型來實現，但有時也需要爲每個客戶訓練和部署不同的模型。
無論是以上哪個場景，都會增加部署模型的複雜性，複雜程度取決於公司的現有情況（例如，您是否已經將一些產品特性部署到客戶的子集中），它們可能需要後端團隊進行大量的額外開發。
當模型要部署到終端產品，如用戶電話或可穿戴設備上時，這個任務將變得更加複雜，在這種情況下，模型部署可能要放到下一個應用程序中進行或者是作爲固件更新的一部分。
產生偏見：對於數據科學團隊來說，部分部署是一個棘手的問題，因爲這種部署必然會帶來偏差，而且模型會持續積累這種偏差，終有一天原來的模型會依據這些具有特性的用戶數據進行工作。不同的產品類型和偏差的特徵，有可能會對模型的性能產生很大的、未知的影響，而且可能對那些用了在此期間積累的數據訓練出來的未來模型產生很大的影響。
例如，在設備更新方面，那些較早更新應用程序/固件的用戶往往屬於特定的人羣（更年輕、更懂技術、收入更高等等）。
我在這裏又添加了一個KPI檢查，因爲我認爲在一個解決方案被認定爲性能達標、已解決產品設計之初的問題、滿足客戶需求之前，不能被認定爲已交付。
這個步驟是指，在部署之後的幾周內對數據結果進行篩選和分析。然而，當涉及到實際的客戶時，還必須要請產品或銷售人員，讓他們與客戶坐在一起，試圖瞭解模型在實際使用中的效果。
用戶和客戶皆大歡喜。產品人員已經成功圍繞模型構建或調整了他們想要的產品。我們完成了目標，舉杯慶賀，雀躍歡呼，結局圓滿。
解決方案已經交付，我認爲此時項目已經完成。然而，它確實以一種特殊的方式存在着——那就是 “維護”。
爲模型設置了的健康檢查和持續的性能監控，可能會將我們帶回到項目中。
當某些東西看起來可疑時，通常我們首先查看數據（例如協變變化），並根據我們所懷疑的能引起問題的各種情況，來模擬模型的反應。根據這些檢查的結果，我們可能需要花幾個小時修改代碼、或者重新訓練模型、或者重新進入模型開發流程（如本文開頭的圖所示），在一些嚴重的情況下，我們需要返回到研究階段，嘗試完全不同的方向。
這是對數據科學項目流程的建議。它本身是非常具體的，這篇爲了簡單起見，限定了它的範圍，它顯然並不能涵蓋實踐中存在的這個流程的許多變化。僅僅是我的經驗所得，如有不足，還請見諒。
