一個數據科學負責人眼中的數據科學：太無聊了！
數據科學家的工作是否如你想像一般，每天建模型，調整參數，充滿了樂趣和挑戰？在 Dessa 的數據科學負責人 Ian Xiao 看來，或許並非如此。他認為，數據科學家的工作往往是非常「無聊的」，在決定踏上這條道路之前，我們必須對此做好心理準備，建立自己的應對機制。以下是他的全文。
Julian Howard 在 Unsplash 上的照片
TLDR：很多人選擇數據科學（或機器學習）中令人興奮的東西來激勵自己和他人。但我們必須面對一個現實：真正的工作往往是「無聊的」——與人們認為浪漫的東西相比是無聊的。感到無聊會造成緊張，它最終會導致數據科學領域工程師的高流動性。我想和大家分享我的實際工作以及如何應對「數據科學的枯燥」。我希望能幫助你——一個有抱負的數據科學家，去設定正確的期望。所以，一旦你決定從事數據科學的職業，你就要長期從事這項工作。享受它吧！
分享你的方法？我想強調的是，每個人都需要有一個應對機制。花 2 分鐘告訴我你的故事，也許接下來我們可以分享我們各自的應對方式，應該很有趣。
1.故事時間
我年輕英俊的表弟 Shawn 最近來到了加拿大，他來這裡攻讀計算機科學碩士學位。和許多學生一樣，Shawn 對機器學習很有熱情，他想在兩年後畢業時成為一名數據科學家（或從事任何與 ML 有關的工作）。
作為一個真正關心 Shawn 前途的哥哥，我決定分享從我的數據科學生涯中學到的最謹慎的知識——這不是《哈佛商業評論》所描述的「21 世紀最性感的工作」，它枯燥乏味，令人筋疲力盡，令人沮喪——就像其他職業一樣。
我有義務告訴 Shawn 真相，即使真相令人失望。這將有助於他對自己的職業選擇做出明智的決定（更重要的是，我將避免凌晨 3 點接到我母親和叔叔的電話，他們肯定會給我上關於家庭、責任和誠實的課）。
作為一個聰明、自驅、充滿好奇的年輕人，Shawn 想讓我詳細說明「無聊」具體指的是什麼，於是我寫下了這篇文章。
此外，我們還討論了 ML 的主要趨勢，以及如何在這個領域脫穎而出。我將在一些後續文章中分享這一點。如果你感興趣，請接著往下看。
2.設置一些上下文
作為一名數據科學經理，我正在財富 100 強企業帶領團隊部署 ML 系統，管理客戶關係，並做一些技術工作。
這裡先談談一些更重要的定義。ML 系統是一種解決業務領域問題的解決方案，它有一個 ML 組件，並且具有與人類或機器一起工作所需要的所有其他非 ML 系統內容。
部署意味著獲得驅動實際業務操作的解決方案。例如，設置用於訓練和驗證 ML 模型的實驗不是部署；設置通過電子郵件發送每月產品報價的推薦引擎是部署。部署 ML 系統面臨的問題與構建一個好的 ML 模型截然不同。如果你感興趣的話，可以在這裡閱讀更多內容。
也就是說，我指的不是那些加入谷歌（google）或其他高科技公司，成為初級開發人員和技術經理的人。這些公司確實做得很好，但我認為它們只代表「前 1%」。其他財富 100 強企業往往在技術成熟度、應用速度以及對工具和工程人才的投資方面落後。
3.讓我們開始吧
簡而言之，當我說數據科學很無聊時，我指的是當人們意識到浪漫的期望和現實之間的差距時的那種壓抑感。
大多數年輕的數據科學家希望把大部分時間花在構建和改進神秘的 ML 模型上，或者將時間花在用絢麗的可視化技術展示開創性的商業見解上。當然，這些確實是你工作的一部分。
但是，隨著企業成熟度的提高，他們更加註重實際的經營價值。這意味著企業希望部署更多的 ML 系統；他們不太關心他們有多少新模型或漂亮的報表。因此，數據科學家被要求做非 ML 工作。這讓他們感到很無聊。
讓我們進一步具體化數據科學中的「無聊」是什麼樣子，如果我給你展示我從周一到周五的典型一天，你將發現那是非常無聊的。因此，我將把我的工作分類，突出展示預期與現實的對比，並分享我的應對機制。
我將使用「我們」為主語，因為這些例子是從和團隊的經驗集合中提取的。這些例子可能並不詳盡，但我認為它們會說明問題。
3.1設計（佔據 5-10% 的時間）
這指的是我們整個集體一起努力獲得「高」智力來解決問題和提出高明的想法。這些想法可以包括新的模型架構、數據特性和系統設計等。很快，我們就會陷入低谷，因為由於時間限制和優先順序的原因，我們需要採用最簡單（通常也是最無聊）的解決方案。
期望：我們實現的想法，可以在著名的 ML 期刊，如 NIPS，谷歌的人工智慧研究博客等上面刊登，甚至可能贏得下一個諾貝爾獎。
現實：我們執行的事情能很好地完成工作。我們為一些值得裝幀的漂亮白板畫拍照。
應對機制：1）和我領域外的朋友一起喝酒時繼續談論瘋狂的想法；他們可以殘忍地讓我停止這些瘋狂、愚蠢的想法；2）把瘋狂和聰明的想法作為輔助項目來做；3）結果是，大多數瘋狂的想法並沒有真正起作用或者只是比簡單的想法稍微好一點。所以 KISS 原則（保持簡單愚蠢，Keep-It-Simple-Stupid）總是給我安慰和結束。
3.2 編碼（會花費 20-70% 的時間，具體取決於角色）
這裡沒什麼好說的。在這個階段，我們戴上耳機，喝點咖啡，伸展手指，鎖定屏幕，打出漂亮的代碼行，讓魔術發生。
我們的代碼通常分為五類，各個代碼行數佔總代碼行數的百分比為：數據管道（50-70%）、系統和集成（10-20%）、ML 模型（5-10%）、支持調試和演示的分析（5-10%）。這與其他人的觀察結果大致一致。
Sergey Karayev 的模型代碼在其全套深度學習課程中所佔的比例
如你所見，我們大部分時間都在處理無聊的非 ML 內容。儘管 ML 組件非常關鍵，但現代的框架和編碼語言（例如 Keras, XGBoost, Python 的 sklearn 等）已經將許多複雜的東西抽象出來了。這意味著實現我們需要的結果不需要沉重的代碼庫；工作流已經很好地標準化和優化了（做低級優化是不同的，但它可能只是 1% 的情況）。
預期：你將花費大部分時間開發和優化 ML 組件，其他人將負責其餘部分。
現實：沒有人希望 1）做你不想做的事情，2）你把所有的好東西都留給自己，3）你在一個已經很好優化的工作流程上花費了不相稱的時間。
應對機制：我們都會根據自己領域的專業知識做出決策，並在對他人發揮支持作用的同時成為自己領域的主要開發人員（例如，貢獻想法、進行實際開發或 QA）。這樣做可以讓我們在向他人學習的同時發揮自己的優勢。更重要的是，它有助於避免為了做「性感的工作」而產生矛盾。
3.3 QA、Debug 和修復 Sh*t（至少 65% 的時間）
在我看來，這是任何技術開發工作中最無聊、最痛苦的部分，開發 ML 系統也不例外。
在 ML 中，有兩種類型的「bug」：糟糕的結果和傳統的軟體問題。糟糕的結果是指低分數模型（例如，準確性或精確性）或不敏感的預測（例如，基於商業經驗的概率非常不準確）。代碼沒什麼問題，只是結果不合理或不夠好。傳統的軟體問題包括諸如代碼損壞或系統配置等問題。
預期：我們只需要處理糟糕的結果，並想出更聰明的方法來建立更好的模型。這件事情還是有點吸引人的，看到由於一些好的想法而提高表現是非常值得的。
實際情況：在我們花在 QA /debug/apply 修復上的時間中，大約 70-90% 是在傳統的軟體問題上。通常，在建立端到端的模型訓練和驗證流程之後，我們可以相當快地獲得足夠好的結果。然後，我們經常將建模的優先順序降低，以關注系統問題。
應對機制：我使用 github 的 Issue 特性將其遊戲化並保留一個「獎盃板」。當我關閉 issue 時，我會立刻分泌多巴胺。看到我們「征服」的問題，我感到更加自豪。當然，我更自豪的是，當我點擊「go」時，一切都神奇地運行起來——這在大學裡的編程作業中只發生過一次。我將終生記住這種感覺。如果它在現實生活中再次發生，很可能是出了問題。
3.4 應對突發事件（10-50% 的時間）
對於任何交付團隊的經理來說，這都是一場噩夢，而不是數據科學。不管時間線是怎麼安排的，總會有事情發生，讓你偏離正軌。具體來說，這些突發事件可以分為三類：a）外部問題，如範圍更改、上游系統依賴性和客戶投訴；b）內部團隊問題，如惱人的 bug 需要比預期長得多的時間才能解決；人們需要過渡來適應新的工作內容得到新的工作；人員配備，性格衝突等，C）我自己的無知等等其它問題。
期望：從頭到尾按部就班；來自客戶、老闆和團隊的熱烈掌聲和擁抱。
現實：意想不到的事情通常發生在最不方便的時候。沒有什麼萬全的辦法來避免這些問題，這令人沮喪。
應對機制：1）將項目的時間線乘以 2-2.5 倍，以便在涉及到深層次的技術問題或跨團隊活動時留出足夠的緩衝空間；2）在內部設定進度時要有緊迫感；3）我在腦海中大聲發誓，好吧，在適當的情況下，有時會口頭髮誓；4）呼吸、微笑和傾聽，5）與團隊一起探索所有可能的選擇，並根據可行性、需要的努力和阻力確定優先順序，6）如果這些都不起作用，不要等待，尋求幫助！7）執行。其中許多機制本身並不是應對機制，但它們是良好的做法，且一直運作良好。
4.總結
我想強調的是，每個人都需要有一個應對機制。
所有這些都是想告訴你，現實世界的數據科學是困難的。有志於從事 ML 職業的人應該認識到，除了建立模型之外還有很多事情要做。你最終會感到無聊和沮喪，就像你對任何職業一樣。這是正常的。但最重要的是，你應該建立一個應對機制，這樣你就可以長期留在這個遊戲中，享受一路上的小獎勵和最後的勝利。
via：https://towardsdatascience.com/data-science-is-boring-1d43473e353e?gi=bc4e3668bb57
