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