編者按：Deliveroo數據科學家Jonny Brooks-Bartlett分享了進行真實世界數據科學項目的經驗教訓。

引言

大多數關于如何“完成”數據科學任務的文章通常討論的是如何編寫解決問題的算法。例如，如何分類文本文檔或預測財經數據。然而，這樣的任務僅僅是完成一個數據科學項目這一過程中的一小部分。即使你能完美寫出求解多類文本分類問題的算法，你仍將面臨很多問題：它在商業上有實際價值嗎？這一問題當前有什么解決方案，你做了什么樣的評測能說服用戶信任你編寫的算法的輸出？算法部署到生產環境后，你能持續獲取反饋以了解算法輸出是否仍然有用嗎？

我將在這篇文章中討論一些開發維護高效、可持續的數據科學項目的指導意見。這篇指南基于我在自己的數據科學項目中得到的教訓，還結合了我看到的其他人進行數據科學項目所犯的錯誤。其中一些經驗未必適用于所有數據科學家，因為不同的數據科學家工作范圍不同。我所處的團隊沒有專門的商業分析師、產品經理、數據科學經理。這意味著我本人需要承擔這些角色的部分職責，我經常在這方面做得不好。不過，對我而言，這是很有價值的學習體驗，我將在后文介紹我學到的一些東西。

特別提示：不管你是否同意我的胡扯，你應該看下Warby Parker數據科學主管Max Shron的視頻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（產品和優先級指定）這兩篇文章也值得一讀。

第二步：判定現有方法/創建基線模型

圖片來源：Rama Ramakrishnan

為什么進行這一步？當前的解決方法提供了一個評測的目標。如果當前存在解決方法，所有有用的模型都應該勝過當前方法。如果面臨的問題當前尚無解決方案，那么你應該開發一個基線模型。基本上，基線模型就是不用機器學習的方案。復雜方案很可能只能提供一點增值，所以你需要評估下創建更復雜的模型是否值得。

這一步涉及什么？找利益相關者談下，他們當前是怎么做的，取得了哪些成功。很可能他們并未測量成功程度，所以有時你需要自行估計/計算。創建基線模型不應該設計任何復雜、需要大費周折的方法。基線模型應該是相當迅速、原始的，甚至可能直接使用計數這樣簡單的方法。

這一步的輸出是什么？基于基線量化評估成功模型（對利益相關者有用）需要達到什么樣的表現。評估是否值得創建復雜模型。

如果不做這一步會怎么樣？你可能浪費時間創建了一個復雜的模型，結果發現不值得投入這些時間提高這點精確度，甚至不能戰勝當前方法。我們創建自己的推薦引擎的時候就忽略了這一點。我們沒有檢查算法是否優于實用的基線（推薦最流行的內容）。很可能推薦算法沒有提供對得起投入的開發成本的價值。

有用資源Create a Common-Sense Baseline First（首先創建常識基線模型）和總是從蠢模型開始，強調了這一點。

第三步：“團隊”討論

為什么進行這一步？目前為止，我們已經得出結論，項目值得進行（第一步），有可行性（第二步），所以，是時候和相關人員談談了，比如工程師和其他數據科學家。應該編寫什么代碼，需要什么數據，應該做哪些測試，使用哪些測度評估表現，嘗試哪些模型方法，這些你現在應該比較清楚了。你自己可能覺得需要做什么一清二楚，但是和別人討論一下常常有助于找到你遺漏的東西或者可以改進的地方。不要低估讓不同視角的人參與討論的重要性。

這一步涉及什么？至少和另一個數據科學家聊一下，展示你已經取得的結果。也許他們能告訴你如何改進你的想法。開始開發模型前的討論必不可少，因為寫好模型后通常就不怎么方便大改了。同時，和你討論的數據科學家也許會評審你的代碼，事先討論一下有助于他們了解上下文。和項目工程師聊下，他們負責產品化你的工作。他們可能需要知道可以期待什么，也可能提一些有助于產品化代碼的建議。

這一步的輸出是什么？沒有什么具體的輸出。這一步不過是在第一時間保證項目質量。確保相關人員了解項目。

如果不做這一步會怎么樣？最好的情況，你獨自想出了怎么做這個項目，并避開了所有的坑。然而，更可能的情況是你沒有考慮到所有事情，漏掉了一些重要的事情。會碰到的典型問題包括將模型轉移到生產環境時，難以遷移、處理存儲文件。模型輸出缺乏標記，沒有給出最有用的格式。這是我開發一個模型時碰到的情況。我編寫的代碼中，有很多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項技能）這兩篇文章。