谷歌“數據科學家的基本技能”。結果最多的是一長串專業術語，名為hard skills。Python、代數、統計和SQL是一些最流行的方法。后來，就出現了軟技能-溝通、商業頭腦、團隊合作精神等。

讓我們假裝你是一個擁有以上所有能力的超人。你從五歲開始編寫代碼，你是Kaggle特級大師，你的會議論文肯定會獲得最佳論文獎。你知道嗎？您的項目仍然有很高的機會努力達到成熟并成為成熟的商業產品。

最近的研究估計，超過85%的數據科學項目未能達到生產。這些研究為失敗提供了許多原因。我從來沒有看到所謂的基本技能被作為一個潛在的原因提到過一次。

我是說以上技巧不重要嗎？當然，我不是。硬技能和軟技能都至關重要。關鍵是它們是必要的，但不是充分的。而且，它們很受歡迎，出現在每一個谷歌搜索上。因此，機會是你已經知道你是否需要提高你的數學水平或團隊合作。

我想談談與流行的硬技能和軟技能相輔相成的技能。我稱它們為工程技能。它們對于與真正的客戶一起構建真正的產品特別有用。遺憾的是，工程技術很少教給數據科學家。他們帶著經驗來的。大多數初級數據科學家缺乏這些。

工程技能與數據工程領域無關。我使用術語工程技能來區分他們與純粹的科學或研究技能。根據劍橋詞典，Engineering是指運用科學原理設計和建造機器、結構和其他項目。在本文中，工程是將科學轉化為產品的使能器組件。如果沒有適當的工程，模型將繼續在預定義的數據集上執行。但他們永遠無法接觸到真正的顧客。

外賣：

重要且經常被忽視的技能有：

1. 簡單化. Make sure your code and your models are simple, but not simplistic.
2. 魯棒性. Your assumptions are wrong. Take a breath and continue to code.
3. 模塊化. Divide and conquer. Dig down to the smallest problem and then find an open-source to solve it.
4. 水果采摘. Don’t focus only on low-hanging fruits. But make sure you have always something to pick.

簡單化

“實體不應該不必要地乘以”--奧卡姆的威廉?！?em>簡單是終極的復雜”--萊昂納多·達·芬奇?！?em>一切都應該盡可能簡單，而不是更簡單”--阿爾伯特·愛因斯坦?！?em>這是我的口頭禪之一--專注和簡單”--史蒂夫·喬布斯。

我本可以用簡單的引文填滿整頁。研究人員、設計師、工程師、哲學家和作家稱贊簡單，并表示簡單有其自身的價值。他們的理由變了，但結論是一樣的。你達到完美不是在沒有什么可添加的時候，而是在沒有什么可刪除的時候。

軟件工程師絕對意識到簡單性的價值。關于如何使軟件更簡單的書籍和文章數不勝數。我記得親吻原則--保持簡單，愚蠢--甚至在我的一門本科課程上教過。簡單的軟件維護成本更低，更容易更改，更不容易出現bug。對此有廣泛的共識。

在數據科學中，情況就大不相同了。有許多文章，例如，“簡單性的優點：關于算法交易中的ML模型”byKristian Bondo Hansenor“Alfredo Gemma的簡單性在數據科學革命中的作用”。但它們是一個例外，而不是規則。數據科學家的主流往好里說并不關心，往壞里說更喜歡復雜的解決方案。

在繼續討論為什么數據科學家通常不關心，為什么他們應該關心，以及如何處理這些問題之前，讓我們看看簡單性意味著什么。根據劍橋詞典，是容易理解或做的品質，是平平淡淡的品質，沒有不必要的或額外的東西或裝飾。

我發現定義簡單性的最直觀的方法是通過negativa，作為復雜性的對立面。根據同一詞典，復雜性是由許多相互聯系的部分或元素組成的；復雜。雖然我們不能總是說某件事很簡單，但我們通?？梢哉f某件事很復雜。我們的目標不是復雜，也不是創造復雜的解決方案。

在數據科學中尋求簡單性的原因與在所有工程學科中的原因相同。更簡單的解決方案要便宜得多?，F實生活中的產品不是Kaggle比賽。需求是不斷修改的。當復雜的解決方案需要適應新的條件時，它很快就變成了維護的噩夢。

很容易理解為什么數據科學家，尤其是應屆畢業生，更喜歡復雜的解決方案。他們剛從學院來。他們已經完成了論文，甚至可能發表了一篇論文。一份學術出版物的評判標準是準確性、數學的高雅性、新穎性和方法論，而很少是實用性和簡單性。

一個把精確度提高0.5%的復雜想法對任何學生來說都是巨大的成功。同樣的想法對于一個數據科學家來說是失敗的。即使它的理論是合理的，它也可能隱藏潛在的假設，這些假設將被證明是錯誤的。在任何情況下，增量改進都不值得復雜性的代價。

那么，如果你、你的老板、你的同事或你的下屬喜歡復雜的“最佳”解決方案，該怎么辦？如果是你的老板，你很可能注定要失敗，你最好開始找一份新工作。在其他情況下，保持簡單，愚蠢。

魯棒性

俄羅斯文化有一個“沃斯”的概念。維基百科將其描述為“盲目信任神圣的天意，指望純粹的運氣”。Avos是卡車司機決定超載的幕后黑手。它隱藏在任何非魯棒的解決方案后面。

什么是穩健性？或者具體地說，什么是數據科學中的健壯性？與我們的討論最相關的定義是“算法的魯棒性是它對假設模型和現實之間的差異的敏感性”，來自Mariano Scain論文。對現實的不正確假設是數據科學家問題的主要來源。它們也是上面那位卡車司機的問題來源。

細心的讀者可能會說，健壯性也是一個算法在執行過程中處理錯誤的能力。他們會是對的。但它與我們的討論不太相關。它是一個具有定義良好的解決方案的技術主題。

在大數據和深度之前的世界里，建立強大系統的必要性是顯而易見的。特征和算法的設計都是手工完成的。測試通常是在數百個，也許數千個例子上進行的。即使是最聰明的算法創建者也從未假設他們能想到所有可能的用例。

大數據時代是否改變了健壯性的本質？我們為什么要關心我們是否可以使用代表所有可以想象的場景的數百萬數據樣本來設計、訓練和測試我們的模型呢？

它發現魯棒性仍然是一個重要的尚未解決的問題。每年頂級期刊都會發表關于算法魯棒性的論文來證明這一點，例如“提高深度神經網絡的魯棒性”和“基于模型的魯棒深度學習”。數據的數量沒有轉化為質量。用于培訓的信息量并不意味著我們可以覆蓋所有的用例。

而如果牽涉到人，現實總會出乎意料，難以想象。我們大多數人都很難說出午飯吃什么，更不用說明天了。數據很難幫助預測人類的行為。

那么，怎樣做才能使您的模型更加健壯呢？第一個選擇是閱讀適當的論文并實施他們的想法。這樣很好。但這些論文并不總是可以概括的。通常，你不能把一個想法從一個領域復制到另一個領域。

我想提出三個一般做法。遵循這些實踐并不能保證健壯的模型，但它大大降低了脆弱解決方案的機會。

性能安全裕度。安全裕度是任何工程的基礎。通常的做法是為了安全起見，采取需求并添加20-30%。一部能裝1000kg的電梯，輕松就能裝1300kg。而且，它被測試為容納1300kg而不是1000kg。工程師為意外情況做準備。

在數據科學中，安全邊際的等價物是什么？我認為這是KPI或成功標準。即使發生了意想不到的事情，你仍然會在門檻之上。

這種做法的重要后果是，您將停止追逐增量改進。如果您的模型將KPI增加1%，您就不可能健壯。在所有的統計顯著性測試中，環境中的任何微小變化都將扼殺您的努力。

過度測試。忘記單一的測試/訓練/驗證部門。您必須在所有可能的組合上交叉驗證您的模型。你有不同的用戶嗎？按照用戶ID劃分，做幾十次。你的數據隨時間變化嗎？根據時間戳進行劃分，并確保每天在驗證組中出現一次。用隨機值“垃圾郵件”您的數據，或者在您的數據點之間交換某些特性的值。然后在臟數據上測試。

我發現假設我的模型有錯誤非常有用，直到證明不是這樣。

關于數據科學和ML測試的兩個有趣的來源--亞歷克斯·古德的博客“用Python進行機器學習，一種測試驅動的方法”。

不要在沙子上建造城堡。減少對其他未測試組件的依賴。不要在另一個高風險且未經驗證的組件上構建模型。即使該組件的開發人員發誓不會發生任何事情。

模塊化

模塊化設計是所有現代科學的基本原則。它是分析方法的直接結果。分析方法是一個將大問題分解成小塊的過程。分析方法是科學革命的基石。

你的問題越小越好。這里的“更好”不太好。這是必須的。它將節省大量的時間、精力和金錢。當一個問題很小，定義明確，并且不附帶大量假設時，解決方案是準確的，易于測試。

大多數數據科學家都熟悉軟件設計中的模塊化。但是即使是最優秀的程序員，他們的python代碼非常清晰，也經常不能將模塊化應用到數據科學本身。

失敗很容易證明。模塊化設計需要一種方法將幾個較小的模型組合成一個大模型。目前還沒有這樣的機器學習方法。

但我發現有一些實用的指導方針是有用的：

• 遷移學習。遷移學習簡化了現有解決方案的使用。你可以把它看作是把你的問題一分為二。第一部分創建低維特征表示。第二部分直接對相關KPI進行優化。
• 開源。盡可能使用開箱即用的開源解決方案。它使您的代碼按定義是模塊化的。
• 忘記最佳。很容易從零開始構建一個為您的需求優化的系統，而不是修改現有的解決方案。但只有當您能夠證明您的系統的性能顯著優于現有系統時，它才是合理的。
• 模型集成。不要害怕采取幾種不同的方法，把它們扔進一個鍋里。這是大多數Kaggle比賽獲勝的原因。
• 劃分數據。不要試圖創造“一個偉大的模式”，雖然理論上，這可能是可能的。例如，如果你處理預測客戶行為，不要為一個全新的客戶和一個已經使用你的服務一年的人建立同樣的模型。

CheckCompositional Deep learning，了解關于深度學習構建塊的更多細節。為了科學證明，readPruned神經網絡是驚人的模塊化。

水果采摘

產品經理和數據科學家之間一直存在著緊張關系。產品經理希望數據科學家專注于低垂的果實。他們的邏輯很清楚。他們說，企業只關心水果的數量和它們生長的地方。水果越多，我們做得越好。他們拋出了各種各樣的流行語--帕累托、MVP、最好的是好的敵人等等。

另一方面，數據科學家指出，低掛的水果腐敗快，味道不好。換句話說，解決簡單的問題影響有限，治標不治本。通常，這是學習新技術的借口，但通常它們是對的。

就我個人而言，我在兩種觀點之間移動。讀過p之后。泰爾的零對一確信低垂的果實是浪費時間。在初創企業呆了將近七年后，我確信創造一個低級的MVP是正確的第一步。
最近，我開發了自己的方法，將這兩個極端統一起來。一個數據科學家的典型環境是一個動態的、怪異的世界，樹在四面八方生長。樹木一直在切換方向。它們可以倒著生長，也可以側著生長。

最好的水果確實在頂端。但是如果我們花太多時間建造梯子，樹就會移動。因此，最好的是瞄準頂部，但要不斷監測頂部在哪里。

從隱喻到實踐，在漫長的發展過程中，事情總是有可能發生變化。原來的問題會變得無關緊要，新的數據源會出現，原來的假設會被證明是錯誤的，KPI會被替換等等。

目標是最好的，但記住在每隔幾個月推出一個工作產品的同時也要做到這一點。產品可能不會帶來最好的水果，但你會更好地感受到水果是如何生長的。