數(shù)據(jù)科學對初創(chuàng)公司有多重要?在初創(chuàng)公司中，數(shù)據(jù)科學項目流程有什么說道嗎?作為在數(shù)據(jù)科學領(lǐng)域身經(jīng)百戰(zhàn)的老將 Shay Palachy，日前接受了一家名為 BigPanda 的初創(chuàng)公司的邀請，讓他就該公司的數(shù)據(jù)科學項目發(fā)表自己的看法。作者在這篇文章中為那些想打造一直屬于自己的數(shù)據(jù)科學團隊的創(chuàng)始人提供了一些非常有價值的建議。

最近，一家名為 BigPanda 的初創(chuàng)公司邀請我對數(shù)據(jù)科學項目的結(jié)構(gòu)和流程發(fā)表自己的看法，這讓我思考是什么讓它們獨一無二。初創(chuàng)公司的經(jīng)理和不同團隊可能會發(fā)現(xiàn)，數(shù)據(jù)科學項目和軟件開發(fā)之間存在差異，這種差異并不那么直觀，而且令人困惑。如果沒有明確的說明和解釋，這些根本差異可能會引起數(shù)據(jù)科學家和同事之間的誤解和沖突。

分別來說，來自學術(shù)界(或高度研究型的行業(yè)研究小組)的研究人員在進入初創(chuàng)公司或小型公司時，可能會面臨各自的挑戰(zhàn)。他們可能會發(fā)現(xiàn)，將新類型的輸入(如產(chǎn)品和業(yè)務需求、更緊密的基礎(chǔ)設施和計算限制以及客戶反饋)納入他們的研究和開發(fā)過程中具有挑戰(zhàn)性。

因此，本文寫作目的就是介紹我和同事在近年來的工作中所發(fā)現(xiàn)的具有特色的項目流程。希望本文能夠幫助數(shù)據(jù)科學家與他們一起工作的人，以反映他們獨特性的方式來構(gòu)建數(shù)據(jù)科學項目。

這個流程是基于小型初創(chuàng)公司的想法建立起來的：一個由數(shù)據(jù)科學家(通常是一到四個人)組成的小團隊，一次只負責一個人領(lǐng)導的中小型項目。規(guī)模更大的團隊或那些以機器學習為先的高科技初創(chuàng)公司的團隊，可能會仍然認為這是一個有用的結(jié)構(gòu)，但在許多情況下，流程會更長，結(jié)構(gòu)也會有所不同。

 

 

我將流程分為三個并行運行的方面：產(chǎn)品、數(shù)據(jù)科學和數(shù)據(jù)工程。在許多情況下(包括我工作過的大多數(shù)地方)，可能并沒有數(shù)據(jù)工程師來執(zhí)行這些職責。在這種情況下，數(shù)據(jù)科學家通常負責與開發(fā)人員合作，幫助他解決這些方面的問題(如果他是全能大神：全棧數(shù)據(jù)科學家，那么他自己就可以憑一己之力解決所有的問題??????)。因此，根據(jù)你的環(huán)境，每當提到數(shù)據(jù)工程師時，你都可以用數(shù)據(jù)科學家來取代之。

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

♦ 范圍界定

♦ 研究

♦ (模型)開發(fā)

♦ 部署

我試著按順序把每一個階段都講一遍。

1. 范圍界定階段

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

1.1. 產(chǎn)品需求

項目應始終從產(chǎn)品需求開始(即使最初想法是技術(shù)或理論上的)，需要在某種程度上通過產(chǎn)品 / 業(yè)務 / 客戶成功人士進行驗證。產(chǎn)品人員應該知曉這個特征大致最終應該是什么樣子的，并且現(xiàn)有或新客戶愿意為此付費(或者防止客戶流失 / 推動訂閱 / 推動其他產(chǎn)品的銷售 / 等等)。

產(chǎn)品需求并非完整的項目定義，而應該作為一個問題或挑戰(zhàn)。例如：“我們的客戶需要一種方法來了解如何使用他們的預算”或 “我們沒有設法讓老年客戶繼續(xù)服藥，這就增加了客戶的流失率” 或“客戶會為一種能夠預測他們運營的機場高峰時段的產(chǎn)品支付更多的費用”。

1.2. 初步解決方案構(gòu)想

這就是數(shù)據(jù)科學家與產(chǎn)品負責人、數(shù)據(jù)工程師和任何其他涉眾一起，為可能的解決方案提出不同的草圖的地方。這意味著通用方法 (例如，無監(jiān)督聚類 vs 基于提升樹的分類 vs 概率推理)和要使用的數(shù)據(jù)(如，我們數(shù)據(jù)庫中的特定表，或者我們尚未監(jiān)控或保存的某些特定用戶行為，或外部數(shù)據(jù)源)。

這通常還涉及一定程度的數(shù)據(jù)探索。在這里你無法做到真正深入的研究，但是任何有前途的 “唾手可得的成果” 都可以幫助指導你的想法。

數(shù)據(jù)科學家應該領(lǐng)導這一過程，通常負責提供大多數(shù)解決方案的想法，但是，我會建議你使用所有參與構(gòu)思解決方案過程的所有人。我有幸從后端開發(fā)人員、CTO 或產(chǎn)品負責人那兒得到了一個項目的最佳解決方案。不要認為不同的、不太注重理論的背景會使人們無法參與這一階段，須知額外的想法和觀點總是有價值的。

1.3. 數(shù)據(jù)準備和可訪問性

團隊現(xiàn)在應該對希望用于探索可能的解決方案(或至少是第一個這樣的數(shù)據(jù)集或數(shù)據(jù)源)的數(shù)據(jù)有一個很好的了解。因此，在進行下一階段的同時，應該已經(jīng)開始提供數(shù)據(jù)訪問并為探索和使用做好準備的過程。

如果在研究階段中，時間可用性不是很關(guān)鍵的話，那么這有時可能需要將大型數(shù)據(jù)及從生產(chǎn)數(shù)據(jù)庫轉(zhuǎn)儲到臨時 / 探索的對應方，或者轉(zhuǎn)儲到較冷的存儲(如對象存儲)中。相反，它可能意味著將大型數(shù)據(jù)轉(zhuǎn)儲從非常冷的存儲拉回到表或文檔形式，以實現(xiàn)快速查詢和復雜的計算。無論如何，這一階段都需要在研究階段開始，并且經(jīng)常會耗費比預期更多的時間，因此，這是啟動研究階段的最佳時機。

1.4. 范圍與 KPI

這一階段是關(guān)于共同決定項目的范圍和 KPI(Key Performance Indicators，關(guān)鍵績效指標)。

KPI 應當首先從產(chǎn)品的角度來定義，但要比之前更詳細;例如，就上述三種產(chǎn)品需求而言，它們可能會變成 “客戶現(xiàn)在可以使用帶有 CTR 統(tǒng)計數(shù)據(jù)和每個類別圖像的儀表板”，或 “在未來兩個季度內(nèi)，65 歲以上的用戶錯過的服藥天數(shù)至少減少 10%”，或 “客戶都會收到每周的機場高峰時間的預測，預測的力度至少為一個小時，近似值至少為 ±50%”。

這些 KPI 應該轉(zhuǎn)換為可衡量的模型指標。運氣好的話，這些將是非常困難的指標，如 “預測廣告的預期 CTR(點擊率)，在至少 Y% 的情況下，對于任何運行至少一周的廣告，以及對于任何擁有兩個月歷史數(shù)據(jù)的客戶來說，CTR 至少為 x%”。然而，在某些情況下，必須使用更柔和的指標，如 “與原始查詢相比，使用生成的擴展查詢進行主題探索所需的時間將縮短，和或與或結(jié)果的質(zhì)量將得到改善”。當模型用于輔助某些復雜的人類功能時，這點尤為正確。

從技術(shù)上講，即使這些指標也可以非常嚴格地定義(在學術(shù)研究中通常亦如此)，但是根據(jù)資源和時間的限制，我們可能會通過人工反饋來近似地對它們進行定義。在這種情況下，每次反饋迭代可能需要花費更長的時間，因此，我們通常會試圖尋找額外的硬指標來指導我們完成大部分即將進行的研究迭代，每隔幾次迭代或者發(fā)生重大變化才會得到一次成本更高的反饋。

最后需要強調(diào)的是，范圍在這里特別重要，因為研究項目有一種拖延的趨勢，當研究過程中出現(xiàn)新的可能性時，或者當檢查的方法僅部分滿足需求時，研究項目的規(guī)模和范圍會自然地擴大。

范圍限制 1：我發(fā)現(xiàn)，明確限制范圍會更為有效;例如，如果你認為基于 Multi-Armed Bandit 的模型是最有前途的方法，那么你可以從它開始，你可以將項目范圍定義為模型開發(fā)的單個兩 / 三周迭代，無論準確性如何都進行部署模型(如，只要它超過 60%)。然后，如果準確性方面的改進有價值(在某些情況下，結(jié)果可能不那么重要)，那么開發(fā)第二個模型可能被認為是一個獨立的項目。

范圍限制 2：范圍限制的另一個變體是使用越來越復雜的復雜性;例如，第一個項目的目標可能就是部署一個模型，這個模型只需為你自己的客戶成功人士提供相當多的候選廣告措辭和顏色變化，第二種方法可能會嘗試構(gòu)建一個模型，提供一組更少的建議，讓客戶能夠看到自己;最終的項目可能會嘗試突出顯示單個選項的模型，低于它的數(shù)量，并為每個變化增加 CTR 預測和人口覆蓋范圍。

這已經(jīng)與軟件工程有了很大的不同，在軟件工程中，組件通常是為了增加規(guī)模而不是增加復雜性而迭代的。

然而，metric-to-product-value 函數(shù)可能是一個階躍函數(shù)，這意味著在某個 X 值下執(zhí)行的任何模型對客戶都沒有用處;在這些情況下，我們寧愿選擇迭代，直到該閾值被抑制。然而，雖然這個 X 在某些情況下可能非常高，但我認為產(chǎn)品 / 業(yè)務人員和數(shù)據(jù)科學家都傾向于高估這一步驟的高度;很容易說明，準確率低于 95%(例如)的任何東西都沒有價值，不能出售。然而。在許多情況下，對產(chǎn)品假設的仔細檢查和挑戰(zhàn)可能會產(chǎn)生非常有價值的產(chǎn)品，這些產(chǎn)品在技術(shù)上可能沒有那么苛刻的要求(至少在產(chǎn)品的第一次迭代中是這樣)。

1.5. 范圍和 KPI 的批準

最后，產(chǎn)品負責人需要批準范圍并定義 KPI。數(shù)據(jù)科學家的工作就是確保每個人都了解范圍的含義：包含哪些內(nèi)容以及優(yōu)先級，產(chǎn)品 KPI 和模型開發(fā)過程中指導他的更難指標之間的關(guān)系，包括字母接近前者的程度。明確地說明這一點可以防止出現(xiàn)模型的消費者(產(chǎn)品和業(yè)務人員)在模型開發(fā)期間或者之后才知道優(yōu)化了錯誤的指標的局面。

關(guān)于范圍的總論

這個階段在很多地方都被忽略了，數(shù)據(jù)科學家急切地開始挖掘數(shù)據(jù)并探索關(guān)于可能解決方案的論文;然而根據(jù)我的經(jīng)驗，這幾乎總是最槽糕的。跳過這一階段可能會導致花費數(shù)周或數(shù)月的時間來開發(fā)很酷的模型，而這些模型最終無法滿足實際需求;或者在一個非常特定的 KPI 中失敗，而這個 KPI 本可以通過某些預先設想來明確定義。

2. 研究階段

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

這就是樂趣的開始!在確定范圍之后開始這一階段的主要優(yōu)勢是，我們的探索現(xiàn)在可以由我們決定的實際硬 KPI 和模型指標來指導。

像往常一樣，在探索和開發(fā)之間要取得平衡;即時有明確的 KPI，在某種程度上探索一些看似無關(guān)的途徑也是有價值的。

到目前為止，數(shù)據(jù)工程應該可以得到所需的初始數(shù)據(jù)集。但是，在這一階段中，經(jīng)常會發(fā)現(xiàn)探索數(shù)據(jù)中的一些缺陷，并且可能會將其他數(shù)據(jù)源添加到工作集中。數(shù)據(jù)工程師應為此做好準備。

最后，雖然此處與文獻和解決方案評審階段分開，但它們通常是并行完成的，或者是交替進行。

2.2. 文獻與解決方案評審

在這一階段中，將回顧學術(shù)文獻以及現(xiàn)有的代碼和工具。平衡也很重要;在探索和開發(fā)之間，在深入研究錯綜復雜的材料之間，在快速提取有用信息和可能的用途之間。

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

例如，假設一個數(shù)據(jù)科學家著手一個項目，幫助銷售部門更好地預測潛在產(chǎn)量或客戶流失率，他覺得自己對隨機過程理論的理解很膚淺，而這些問題的許多常見解決方案都是監(jiān)理在這個理論的基礎(chǔ)之上。對這種感覺的適當反應可能非常不同;如果他在一家算法交易公司工作，那么他肯定會深入研究這一理論，甚至可能會參加一門關(guān)于這個主題的在線課程，因為這與他的工作非常相關(guān);另一方面，如果他在一家醫(yī)學影像公司工作，該公司專注于肝臟 X 射線掃描中腫瘤自動檢測，我認為他應該會盡快找到一個可行的解決方案，然后繼續(xù)前進。

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

例如，如果生產(chǎn)環(huán)境僅支持為后端使用部署 Java 和 Scala 代碼，那么解決方案預計會以 JVM 語言提供，即使在這個研究階段，數(shù)據(jù)科學家也必須深入研究基于 Python 的實現(xiàn)，因為隨著它們進入模型的開發(fā)階段，需要將它們轉(zhuǎn)換為 JVM 語言。

最后，在回顧文獻時，請記住，不僅要向團隊的其他成員展示選定的研究方向(或幾個方向)。相反，應在作出選擇的同時，對該領(lǐng)域和所有經(jīng)過審查的解決辦法作一次簡短的審查，解釋每一個方向的優(yōu)點和缺點以及選擇的理由。

2.3. 技術(shù)有效性檢查

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

這是在這一階段執(zhí)行的一個重要檢查，因為一些數(shù)據(jù)和軟件工程可以與模型開發(fā)的同時開始。此外，從工程角度來看，建議的解決方案可能存在不足或者成本太高，在這種情況下，應盡快確定并處理。在模型開發(fā)開始之前考慮技術(shù)問題時，在研究階段獲得的只是可以用來建議更適合技術(shù)約束的替代解決方案。這也是為什么在研究階段還必須對解決方案前景進行一些概述，而不僅僅是在單個解決方案方向的另一個原因。

2.4. 范圍和 KPI 的驗證

同樣，產(chǎn)品經(jīng)理需要批準建議的解決方案，現(xiàn)在用更技術(shù)性的術(shù)語來表述，符合范圍和定義的 KPI。通常具有容易檢測到的產(chǎn)品含義的可能技術(shù)標準是相應時間(及其與計算時間的關(guān)系)、數(shù)據(jù)的新鮮度以及有時緩存的中間計算(與查詢和批處理計算頻率相關(guān))、針對特定領(lǐng)域模型(域通常是客戶，但也可以是行業(yè)、語言、國家等)和解決方案可組合型(如，數(shù)據(jù)和模型結(jié)構(gòu)是否允許容易地將國別模型分解成區(qū)域模型，或者將幾個這樣的模型組合成大陸模型)的難度和成本，盡管還存在很多其他模型。

3. 開發(fā)階段

3.1. 模型開發(fā)和實驗框架的建立

開始模型開發(fā)所需設置的數(shù)量和復雜性，在很大程度上取決于數(shù)據(jù)科學家可用的基礎(chǔ)設置和技術(shù)支持的數(shù)量。在較小的地方，以及尚未用于支持數(shù)據(jù)科學研究項目的地方，設置可能會為數(shù)據(jù)科學家打開一個新的代碼存儲庫并啟動本地 Jupyter Notebook 服務器，或者請求更強大的云機器來運行計算。

在其他情況下，可能需要為更復雜的功能編寫定制代碼(如數(shù)據(jù)和模型版本控制或?qū)嶒灨�蹤和管�?。當這個功能被一些外部產(chǎn)品或服務替代時(現(xiàn)在這類產(chǎn)品或服務越來越多了)，可能會出現(xiàn)以鏈接數(shù)據(jù)源、分配資源和設置自定義軟件包的形式進行的一些設置。

3.2. 模型開發(fā)

有了所需的基礎(chǔ)設施，實際的模型開發(fā)就可以真正開始了。這里所要開發(fā)的模型的范圍因公司而異，取決于數(shù)據(jù)科學家要交付的模型與要部署在生產(chǎn)中的服務或特征之間的關(guān)系和差異。在某種程度上發(fā)現(xiàn)差異的各種方法，可以通過考慮范圍來獲得。

在這個范圍的一端是一切都是模型的情況：從數(shù)據(jù)聚合和預處理，到模型訓練(可能是周期性的)，模型部署，服務(可能具備擴展性)和持續(xù)監(jiān)控。另一方面，只考慮模型類型和超參數(shù)的選擇，通常也考慮高級數(shù)據(jù)預處理和特征生成，才能被認為是模型。

公司在這一范圍上的位置取決于很多因素：數(shù)據(jù)科學家的首選研究語言;相關(guān)庫和開源可用性，支持公司的生產(chǎn)語言;有專門負責數(shù)據(jù)科學相關(guān)代碼的數(shù)據(jù)工程師和開發(fā)人員;以及數(shù)據(jù)科學家的技術(shù)能力和工作方法。

如果公司有一個非常全棧的數(shù)據(jù)科學家，再加上專門的數(shù)據(jù)工程師和開發(fā)人員的足夠支持，或者，有足夠的現(xiàn)有技術(shù)設施，專門用于數(shù)據(jù)湖和聚合、模型服務、擴展和監(jiān)控(以及可能還有版本控制)的操作和自動化�？梢詫δＰ瓦M行更廣泛的定義，并且在模型開發(fā)的大部分迭代中都可以使用端到端解決方案。

這通常意味著首先構(gòu)建完整的管道，從數(shù)據(jù)源一直到可擴展的服務模型，并為數(shù)據(jù)預處理、特征生成和模型本身提供簡單的占位符。然后對數(shù)據(jù)科學部分進行迭代，同時將范圍限制在現(xiàn)有基礎(chǔ)上可用和可部署的部分。

這種端到端方法可能需要更多的時間來設置，并且模型類型和參數(shù)的每次迭代都需要更長的時間來進行測試，但是它節(jié)省了以后在產(chǎn)品化階段所花費的時間。

就我個人而言，我很喜歡它，但是它的實現(xiàn)和維護過于復雜，而且并不總是合適的。在這種情況下，管道開始和結(jié)束的某些部分會被留到產(chǎn)品化階段中。

3.3. 模型測試

在開發(fā)模型時，應該根據(jù)預先確定的硬指標連續(xù)測試模型的不同版本(以及伴隨模型的數(shù)據(jù)處理管道)。這樣就得到了對進展的粗略估計，并允許數(shù)據(jù)科學家確定模型何時運行良好，足以保證進行全面的 KPI 檢查。請注意，這可能具有誤導性，例如，在許多情況下，準確度從 50% 提到到 70%，要比從 70% 提到到 90% 容易得多。

 

 

當測試表明模型不準確時，我們通常會研究它及其輸出以指導改進。然而，有時候性能上的差距很大，所選的研究方向的不同變化都達不到預期的效果——這是一個接近失敗的結(jié)果。這就可能需要改變研究方向，將項目送回研究階段。這是數(shù)據(jù)科學項目最難以接受的方面：回溯的可能性。

接近失敗的另一個可能結(jié)果就是目標的改變。幸運的是，這可能是產(chǎn)品方面的小問題，但在技術(shù)上以更簡單的方式重申了這一目標。

例如，與其試圖生成一篇文章的一句話摘要，不如選擇文章中最能概括文章的句子。

最終可能的結(jié)果當然是項目取消;如果數(shù)據(jù)科學家確信已經(jīng)探索了所有的研究途徑，并且產(chǎn)品經(jīng)理確信無法圍繞現(xiàn)有績效構(gòu)建有效產(chǎn)品，那么可能是時候轉(zhuǎn)向另一個項目了。不要低估了確定一個無法挽救的項目的能力和做出結(jié)束項目的決定的勇氣;這是快速失敗方法論的關(guān)鍵部分。

3.4. KPI 檢查

如果預先確定的硬指標是唯一的 KPI，并且準確地補貨了所有的產(chǎn)品需求，那么，當推出最終模型、宣告開發(fā)階段結(jié)束時，這個階段可以更正式一些。通常情況并非如此。

在更常見的情況下，硬指標很好地近似了實際的產(chǎn)品需求，但并不是完美的。因此，這一階段是確保無法自動檢查的軟指標也能得到滿足的機會，這是與產(chǎn)品和客戶的成功一起完成的。如果你還可以直接檢查客戶的實際價值，例如，當你與設計伙伴一起工作時，這是你所能找到的迭代最佳指南。

例如，假設我們正在處理一項復雜的任務，比如，給定一個查詢，從一個巨大的語料庫中提取相關(guān)的文檔。團隊可能已經(jīng)決定嘗試提高結(jié)果集的質(zhì)量，重點關(guān)注返回文檔的內(nèi)容和主題的差異，因為客戶認為系統(tǒng)傾向于在頂級結(jié)果中局級非常相似的文檔。

對于結(jié)果集中的內(nèi)容差異，模型開發(fā)可能已經(jīng)取得一些可衡量的指標，給定一組測試查詢，每個模型根據(jù)它返回的前 20 個文檔的變化程度來評分。也許你可以測量某些主題向量空間中文檔主題之間的總距離，或者僅僅測量唯一主題的數(shù)量或重要單詞分布的平整度。

即使數(shù)據(jù)科學家確定了一個能顯著改進這一指標的模型，產(chǎn)品和客戶的成功人士也一定要查看測試查詢的重要樣本的實際結(jié)果;他們可能會發(fā)現(xiàn)難以量化但有可能解決的問題，例如推高一些反復出現(xiàn)的非相關(guān)主題來增加結(jié)果差異的模型，或者通過包括來自不同來源的類似主題的結(jié)果(如，新聞文章 vs 推文，它們使用了非常不同的語言)。

當產(chǎn)品人員確信模型符合項目的既定目標(達到令人滿意的程度)時，團隊就可以繼續(xù)將其進行產(chǎn)品化。

4. 部署階段

4.1. 解決方案產(chǎn)品化和監(jiān)控設置

如前所述，這一階段取決于公司中數(shù)據(jù)科學研究和模型服務的方法，以及幾個關(guān)鍵的技術(shù)因素。

產(chǎn)品化：在研究語言可用于生產(chǎn)環(huán)境的情況下，這一階段可能需要調(diào)整模型代碼，使其以可擴展的方式工作;這一過程有多簡單或有多復雜，取決于模型語言的分布式計算支持，以及所使用的特定庫和自定義代碼。

當研究語言和生產(chǎn)語言不同時，這可能還涉及到將模型代碼包裝在生產(chǎn)語言包裝器中，將其編譯為低級二進制文件或用生產(chǎn)語言實現(xiàn)相同的邏輯(或找到這樣的實現(xiàn))。

還需要設置可擴展的數(shù)據(jù)接收和處理，在這種情況下(非常常見)，這并非模型的一部分。這可能意味著，例如，將運行在單個核心上的 Python 函數(shù)轉(zhuǎn)換為管道流數(shù)據(jù)，或者轉(zhuǎn)換為周期性運行的批處理作業(yè)。在重要數(shù)據(jù)重用的情況下，有時候還會設置緩存層。

監(jiān)控：最后，建立了一種持續(xù)監(jiān)控模型性能的方法;在極少數(shù)情況下，當生產(chǎn)數(shù)據(jù)的源不變時，也許可以安全地跳過，但是我想說的是，在大多數(shù)情況下，你并不能確定源數(shù)據(jù)分布的穩(wěn)定性。因此，設置這樣的性能檢查，不僅可以幫助我們發(fā)現(xiàn)模型中在開發(fā)和產(chǎn)品化過程中可能遺漏的問題，更重要的是，還可以發(fā)現(xiàn)源數(shù)據(jù)分布的變化，通常稱為 “協(xié)變量變化”(covariate shift)，可以及時降低完美模型的性能。

以我們的產(chǎn)品為例，我們的產(chǎn)品是一個檢測皮膚斑點的 App，它會評估是否推薦用戶去看皮膚科醫(yī)生。當一款流行的新手機上市時，我們的數(shù)據(jù)可能會發(fā)生寫向量變化，因為這款新手機配備的攝像頭與我們數(shù)據(jù)中的攝像頭有很大的不同。

4.2. 解決方案部署

如果一切設置都正確的話，那么這個階段可以總結(jié)為，希望按下一個按鈕，將新模型(以及為其服務的任何代碼)部署到公司的生產(chǎn)環(huán)境中。

部分部署：但是，為了測試該模型的有效性(例如，減少客戶流失或增加每個用戶的平均月支出)，可能會將模型部署到只有部分用戶 / 客戶的環(huán)境中。這樣就可以能夠直接比較用戶群中的兩個(或更多)組之間的任何可測量的 KPI 的影響。

你可能不希望將模型部署到每個人的另一個原因是，它是為了滿足特定客戶或一群客戶的需求而開發(fā)的，或者它是高級功能或者特定計劃的一部分�；蛘撸�該模型可能具有針對每個用戶或客戶的個性化元素;這有時可以通過實際考慮客戶特征的單一模型來實現(xiàn)，但有時需要為每個客戶實際訓練和部署不同的模型。

無論如何，所有這些場景都增加了部署模型的復雜性，并且取決于公司現(xiàn)有的基礎(chǔ)設施(例如，如果你已經(jīng)將某些產(chǎn)品功能部署到客戶子集中)，那么就可能需要你的后端團隊進行大量的額外開發(fā)。

當模型要部署在終端產(chǎn)品上時，如用戶電話或可穿戴設備，這個階段會變得更加復雜，在這種情況下，模型部署可能只會作為部署的下一個 App 或固件更新的一部分來進行。

產(chǎn)生偏差：最后，由于另一個原因，對于數(shù)據(jù)科學團隊來說，所有部分部署的案例實際都是一個緊迫問題。這自然會在模型將開始積累的未來數(shù)據(jù)中引入偏差，模型將開始由具有可能獨特特征的用戶自己對數(shù)據(jù)進行操作。根據(jù)產(chǎn)品和特定的偏差特征，這可能會對模型在野外的性能產(chǎn)生很大的影響，也可能對未來模型在此期間積累的數(shù)據(jù)進行訓練產(chǎn)生很大的影響。

例如，在設備更新方面上，較早更新 App / 固件的用戶往往屬于特定的人群(更年輕、更精通技術(shù)、更高收入等等)。

4.3. KPI 檢查

我在此添加了另一個 KPI 檢查，因為我認為在部署和實際使用后驗證了解決方案的性能和對產(chǎn)品和客戶需求的成功相應之前，不能將其標記為已交付。

這可能意味著在部署之后的幾周內(nèi)，對結(jié)果數(shù)據(jù)進行篩選和分析。然而，當真正客戶實際參與進來時，這還必須涉及到產(chǎn)品或客戶成功人士，與客戶一起試圖了解模型對他們使用產(chǎn)品的實際影響。

4.4. 解決方案交付

用戶和客戶皆大歡喜。產(chǎn)品人員已經(jīng)成功圍繞模型構(gòu)建或調(diào)整了他們想要的產(chǎn)品。我們完成了目標，舉杯慶賀，雀躍歡呼，結(jié)局圓滿。

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

維護

在為模型設置健康檢查和持續(xù)的性能監(jiān)控之后，這些可以觸發(fā)項目工作的短暫爆發(fā)。

當某些東西似乎看上去很可疑的時候，我們通常會首先查看數(shù)據(jù)(如協(xié)變量變化)，并且還可能會模擬模型對我們懷疑引起問題的各種情況的反應。這些檢查的結(jié)果可以讓我們在幾個小時的少量代碼改動、模型的重新訓練和完整的模型開發(fā)迭代之間做任何事情(如本文開頭圖中所示)，嚴重的情況下，有時還需要回到研究階段嘗試完全不同的方向。

最后的話

這是對數(shù)據(jù)科學項目流程的建議。它也是非常具體的，為了簡單起見，它的范圍也是有限的，顯然并不能涵蓋實踐中存在的這個流程的許多變化。這也是我的經(jīng)驗所得。

關(guān)于這一主題還有另一個卓越的觀點，我建議讀者閱讀我朋友 Ori 撰寫的關(guān)于數(shù)據(jù)科學的敏捷軟件開發(fā)的文章!

作者：Shay Palachy 譯者：劉志勇

請參閱：

https://towardsdatascience.com/data-science-agile-cycles-my-method-for-managing-data-science-projects-in-the-hi-tech-industry-b289e8a72818

原文鏈接：

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

標簽： 安全 代碼 服務器 數(shù)據(jù)庫

版權(quán)申明：本站文章部分自網(wǎng)絡，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。