如何構建有價值的真實世界資料科學專案
作者：Jonny Brooks-Bartlett
編譯：weakish
引言
大多數關於如何“完成”資料科學 任務 的文章通常討論的是如何編寫解決問題的演算法。例如，如何分類文字文件或預測財經資料。然而，這樣的 任務 僅僅是 完成一個數據科學專案 這一過程中的一小部分。即使你能完美寫出求解多類文字分類問題的演算法，你仍將面臨很多問題：它在商業上有實際價值嗎？這一問題當前有什麼解決方案，你做了什麼樣的評測能說服使用者信任你編寫的演算法的輸出？演算法部署到生產環境後，你能持續獲取反饋以瞭解演算法輸出是否仍然有用嗎？
我將在這篇文章中討論一些開發維護高效、可持續的資料科學專案的指導意見。這篇指南基於我在自己的資料科學專案中得到的教訓，還結合了我看到的其他人進行資料科學專案所犯的錯誤。其中一些經驗未必適用於所有資料科學家，因為不同的資料科學家工作範圍不同。我所處的團隊沒有專門的商業分析師、產品經理、資料科學經理。這意味著我本人需要承擔這些角色的部分職責，我經常在這方面做得不好。不過，對我而言，這是很有價值的學習體驗，我將在後文介紹我學到的一些東西。
特別提示： 不管你是否同意我的胡扯，你應該看下Warby Parker資料科學主管Max Shron的視訊 ofollow,noindex">Stakeholder-Driven Data Science at Warby Parker （利益相關者驅動的資料科學）。這是一個很棒的視訊，介紹了很多真實世界資料科學專案的情況。
成功專案應該滿足哪些條件？
我發現，在解決一個問題前，首先釐清怎樣才算成功是很有用的。（這裡我們假定已經清楚問題是什麼，但請不要低估辨識出需要解決的問題的難度。）這有助於我制定達到最終目標的策略。
- 你為何進行這個專案？例如，這個專案帶來了什麼價值，它為資料團隊更大的目標做了什麼貢獻？
- 誰是這個專案的主要利益相關者？
- 這一問題的當前解決方案是什麼？
- 是否存在可以快速實施的簡單高效的解決方案？
- 你是否努力獲取相關人員的注意和資訊？
- 你是否找人評估過你的方案的合理性？
- 你是否努力確保程式碼的魯棒性？
- 你是否努力確保專案容易理解，方便移交給別人維護？
- 如何在生產環境中驗證你的模型？
- 如何收集解決方案的反饋？
就我的經驗而言，如果這些問題都能找到合適的答案，那麼這個專案基本上就成了。當然，取決於專案的具體情況，這並不是確鑿無疑的，上面的列表也遠遠沒有窮盡成功的條件。但不管怎麼說，上面的列表是一個良好的開始。
如果你瞧不上我列出的問題，可以參考Kate Strachnyi的20個問題： https:// towardsdatascience.com/ 20-questions-to-ask-prior-to-starting-data-analysis-6ec11d6a504b
下面介紹的步驟有助於應對這些問題。
資料科學專案的五步方針
第一步：初步評估專案的潛在價值
- 為什麼進行這一步？ 這個問題有助於你設定專案的優先順序。你應該能夠恰當地回答為什麼一個專案應該在另一個專案之前完成。這個問題也讓我們更好地理解專案和團隊、公司的目標的一致性。此外，也為我們應該優化模型的哪些測度提供了指引。
- 這一步涉及什麼？ 大致評估下收益，例如，節省的資金，增加的收益，節省的人力。有人不主張進行這項評估，因為做這個評估很難，而且收益並不總是能夠量化。對此，我的迴應是：如果你或者利益相關者弄不清楚專案的價值，那麼為什麼要 浪費你或者利益相關者的時間 呢？評估的數值不必完美，大概估計下就行。這一步也包括判定誰是主要的利益相關者。
- 如果不做這一步會怎麼樣？ 我們可能花費大量時間進行一個無人獲益的專案。我曾經見過一個專案，需要資料科學團隊識別值得營銷團隊聯絡的最能帶來收益的客戶列表。建立模型之後，我們決定花幾個月的時間改進這一模型。儘管新模型給出了更好的結果，但營銷團隊調整了閾值，因為他們不在乎為每個客戶生成的評分，只打算聯絡固定數目的客戶。所以，花在改進模型上的時間很可能毫無意義。（當然，可能聯絡的固定數目的客戶實際上能帶來更多收益，因為模型更好了，但因為沒有測量這方面的資料，所以我們並不知道這點是否成立。）
- 這一步的輸出是什麼？ 專案價值的大概估計和簡短的專案總結。注意，取決於公司和專案的情況，可能只需說明資料模型能夠帶來可以觀測到的收益，而無需估計具體數值。不過這很大程度上取決於公司政治。
- 有用資源： A Simple way to Model ROI of any new Feature （建模新特性ROI的簡單方法）給出了一個簡單的公式：期望ROI = (惠及使用者 × 新使用量/增加的使用量 × 商業價值) - 開發成本。 Prioritizing data science work （為資料科學工作設定優先順序）和 Product and Prioritisation （產品和優先順序指定）這兩篇文章也值得一讀。
第二步：判定現有方法/建立基線模型
- 為什麼進行這一步？ 當前的解決方法提供了一個評測的目標。如果當前存在解決方法，所有有用的模型都應該勝過當前方法。如果面臨的問題當前尚無解決方案，那麼你應該開發一個基線模型。基本上，基線模型就是不用機器學習的方案。複雜方案很可能只能提供一點增值，所以你需要評估下建立更復雜的模型是否值得。
- 這一步涉及什麼？ 找利益相關者談下，他們當前是怎麼做的，取得了哪些成功。很可能他們並未測量成功程度，所以有時你需要自行估計/計算。建立基線模型不應該設計任何複雜、需要大費周折的方法。基線模型應該是相當迅速、原始的，甚至可能直接使用計數這樣簡單的方法。
- 這一步的輸出是什麼？ 基於基線量化評估成功模型（對利益相關者有用）需要達到什麼樣的表現。評估是否值得建立複雜模型。
- 如果不做這一步會怎麼樣？ 你可能浪費時間建立了一個複雜的模型，結果發現不值得投入這些時間提高這點精確度，甚至不能戰勝當前方法。我們建立自己的推薦引擎的時候就忽略了這一點。我們沒有檢查演算法是否優於實用的基線（推薦最流行的內容）。很可能推薦演算法沒有提供對得起投入的開發成本的價值。
- 有用資源 資料科學專案的第一步：建立常識基線 和總是從蠢模型開始，強調了這一點。
第三步：“團隊”討論
- 為什麼進行這一步？ 目前為止，我們已經得出結論，專案值得進行（第一步），有可行性（第二步），所以，是時候和相關人員談談了，比如工程師和其他資料科學家。應該編寫什麼程式碼，需要什麼資料，應該做哪些測試，使用哪些測度評估表現，嘗試哪些模型方法，這些你現在應該比較清楚了。你自己可能覺得需要做什麼一清二楚，但是和別人討論一下常常有助於找到你遺漏的東西或者可以改進的地方。不要低估讓不同視角的人蔘與討論的重要性。
- 這一步涉及什麼？ 至少和另一個數據科學家聊一下，展示你已經取得的結果。也許他們能告訴你如何改進你的想法。開始開發模型前的討論必不可少，因為寫好模型後通常就不怎麼方便大改了。同時，和你討論的資料科學家也許會評審你的程式碼，事先討論一下有助於他們瞭解上下文。和專案工程師聊下，他們負責產品化你的工作。他們可能需要知道可以期待什麼，也可能提一些有助於產品化程式碼的建議。
- 這一步的輸出是什麼？ 沒有什麼具體的輸出。這一步不過是在第一時間保證專案質量。確保相關人員瞭解專案。
- 如果不做這一步會怎麼樣？ 最好的情況，你獨自想出了怎麼做這個專案，並避開了所有的坑。然而，更可能的情況是你沒有考慮到所有事情，漏掉了一些重要的事情。會碰到的典型問題包括將模型轉移到生產環境時，難以遷移、處理儲存檔案。模型輸出缺乏標記，沒有給出最有用的格式。這是我開發一個模型時碰到的情況。我編寫的程式碼中，有很多API呼叫是不必要。在本地的小資料集上，模型執行得很好，但在生產環境中，載入資料很吃力。直到我求助一個工程師後才解決了問題（這個工程師幫助我查明瞭問題）。
第四步：模型研發
- 為什麼進行這一步？ 不用多說，最終解決問題靠的是模型。
- 這一步涉及什麼？ 這取決於具體的專案。需要注意的是，模型研發並不等於建立模型。有太多關於如何編寫機器學習演算法解決特定問題的文章了，所以我這裡就不多說了。我想強調一些有助於產生高質量產品程式碼的步驟。通常情況下你不是唯一一個看程式碼的人，所以 程式碼審閱 和 文件 對專案的壽命而言至關重要。在生產環境幾乎一定會碰到bug和意料之外的輸入，所以你可以通過 程式碼測試 來緩解這些問題，增強程式碼的魯棒性。這包括單元測試，整合測試，系統測試，使用者接受測試（UAT）。關於如何使程式碼便於產品化的規範，不同團隊可能有所不同，不過有一些東西是相通的：在隔離環境下工作（虛擬環境或Docker容器），記錄日誌，使用配置檔案。
- 這一步的輸出是什麼？ 一個共享的程式碼倉庫，其中包含解決專案所定義的問題所需的檔案和可以工作的模型。
- 如果不做這一步會怎麼樣？ 如果程式碼未經測試，邏輯上的錯誤可能直到部署到生產環境後才暴露出來。如果程式碼沒有經過他人評審或者沒有文件，你離職或者休年假的時候其他人很難接手。我之前做過的一些專案就不斷出問題。我現在還需要給9個月前“完工”的一個專案修bug. 這佔用了我做其他有價值的事情的時間，令所有專案相關人員沮喪。在開發階段額外花一點時間保證程式碼的魯棒性，長期來看，可以節省你很多時間。
- 資源 How to write a production-level code in Data Science? （如何編寫生產環境級別的資料科學程式碼？）是一篇全面的指南，覆蓋了我能想到的一切東西。如果你是一個編寫生產環境級別的程式碼的資料科學家，你應該讀一下這篇文章。另外推薦 Code Reviewing Data Science Work （資料科學工作的程式碼審閱）和 Doing Code Review Solo & Writing Good Code （自我審閱程式碼 & 寫好程式碼）這兩篇關於程式碼審閱的文章。後一篇文章介紹瞭如何通過自我審閱程式碼提高自己編寫的程式碼的質量，這並不能代替實際的程式碼審閱。 Code Documentation Guide （程式碼文件指南）介紹瞭如何恰當地編寫文件。我個人很喜歡numpy風格的docstring。關於程式碼測試，我推薦 How to unit test machine learning code （如何單元測試機器學習程式碼）這篇指南，還有semaphore的 Testing Python Applications with Pytest （使用Pytest測試Python應用），我自己一個專案開始編寫測試的時候參考了這篇教程。semaphore上還有一篇 Getting Started with Mocking in Python （Python偽造資料入門），介紹瞭如何為測試偽造資料。 Python unit testing with Pytest and Mock （使用Pytest和Mock進行Python單元測試）則是另一篇值得一讀的指南。
第五步：模型監測和反饋
- 為什麼進行這一步？ 這是為了確保產品在生產環境中的表現符合期望。解決方案的輸出應該是穩定可靠的。如果出現了錯誤，我們應該是第一個知道的。模型的表現比期望的差嗎？生產環境的資料和訓練資料的格式不一樣嗎？資料不正確嗎？自動化檢測可以節省大量手工檢視輸出、追查程式碼以確保一切符合期望的時間。為公司提供價值是我們的職責，所以我們應該測量解決方案的影響力。是否良好運作？需要調整嗎？創造了多少利潤？使用有多頻繁？我們可以向管理層報告這些，以顯示資料科學的商業價值。
- 這一步涉及什麼？ 在模型部署到生產環境後的一段時間內（也許是兩三週），主動地手工檢查所有一切運作良好。然後 自動化 檢測過程，也許可以建立一個控制面板和一套郵件預警系統，和/或一個異常檢測系統。也許利益相關者也需要進行監測，所以可能需要調整監測方案，使其對非技術同事更友好。至於反饋方面，可能涉及和利益相關者討論如何接受反饋？定量反饋還是定性反饋？你可以在產品中編寫記錄使用資料的程式碼，這樣不用明確要求利益相關者報告使用習慣。
- 這一步的輸出是什麼？ 確保模型恰當工作、提供解決方案使用量和價值的定性或定量反饋的方法和產品。可能也包括出錯時的通知/預警系統。
- 如果不做這一步會怎麼樣？ 如果沒有恰當地監測我們的產品，我們將承擔產品出錯時商業利益相關者喪失信任的風險，同時也可能導致商業損失，團隊嘗試修復問題也可能花掉大量時間。我曾經碰到過的一個情況是，我們建立的資料分析工具給出了離譜的圖表。結果發現是原始資料提供商搞砸了資料。但是，利益相關者在團隊之前發現了問題。之前模型研發階段描述過的魯棒性測試和自動預警系統本應該偵測到這個問題，但我們並沒有配備這些。當資料最終迴歸正常之後，利益相關者以為資料還是錯的。我們資料團隊花了2周時間檢查資料，最後得出結論資料沒有出錯！我們損失了2周的時間。自動化監測系統本可以將2周降至2分鐘！此外，如果我們不收集反饋，那我們就會對專案是否有用，甚至專案是否還在使用一無所知。我們曾在和市場團隊的一次會議中詢問“你們在使用這個模型嗎？”我們本不應該提出這個問題，因為 1) 在第一步和第二步，我們應該確保模型具有價值，並且超過了當前解決方案/基線模型的表現 2) 我們應該將監測系統作為專案的一部分，而不是在一次不相關的會議中詢問利益相關者是否使用我們的專案。這顯示了我們並沒有測量模型的影響力。
沒提到的步驟
我的好朋友Michael Barber提醒我遺漏了一個重要步驟： 評估 。模型評估是一個極為重要的部分，不恰當的評估可能導致模型在生產環境中發生意料之外的退化。這方面，Fast.ai的Rachel Thomas寫過一篇出色的文章 How (and why) to create a good validation set （如何/為何建立良好的驗證集）。
此外，我完全忽略了試驗。判定你的資料科學方案是否具備預想的影響力的最好方法之一是進行試驗，A/B測試。Julia Silge寫過一篇出色的文章 From Power Calculations to P-Values: A/B Testing at Stack Overflow （從功效計算到P值：StackOverflow的A/B測試）。
這裡我不會深入這兩方面的細節，因為這篇文章已經太長了。第三步和利益相關者討論的環節應當討論如何進行模型評估和A/B測試。
結語
上面介紹了我覺得進行一個成功的資料科學專案需要遵循的五大步驟。需要注意的是，資料科學家不一定要完全施行這5個步驟，因為有些團隊有專門的成員負責其中一些任務。例如，商業分析師或產品經理可能負責和利益相關者溝通，以決定一個專案是否有價值，需求是什麼。同時，不是所有的專案都需要這些步驟。如果專案是一次性分析，那麼建立持續檢測輸出的面板就毫無必要。
現實一點，你不需要遵循所有這些步驟以建立一個成功的資料科學專案。在大多數情形下，編寫一整套測試和文件，同時為利益相關者配置監測面板，一旦出現異常報警，不太實際。更可能的情況是，你需要權衡這些事情中哪些值得做，以便在（可能不合理）的截止日期前完成專案。我承認，我沒有一個專案完成了所有這些步驟，不過我當時意識到了自己在做什麼，以及為何在特定時刻這麼做是一個實用的決策。
我還想指出的另一件重要的事是這些步驟僅僅是一些有助於專案成功的指導原則。而想要成為一個 成功的資料科學家 ，還需要具備一些品質，掌握一些技能。我推薦閱讀 My two cents on what makes a good data scientist nowadays? （今時今日的優秀資料科學家需要具備什麼條件，我的一點看法）和 4 Must Have Skills Every Data Scientist Should Learn （資料科學家必備的4項技能）這兩篇文章。